Android开发：跨Activity高效处理CursorAdapter及数据同步问题

刚好之前做过类似重度依赖SQLite的Android应用，来给你捋捋这两个问题的实用解决方案：

首先得纠正一个可能的误区：你的场景根本不需要传递完整的数据集，最优解是传递查询标识而非整个数据集合，具体分析如下：

• 优先用Intent传递必要标识：点击TableA的列表项时，只需要把该条目的id通过Intent传给子Activity即可。子Activity拿到这个id后，直接执行SQL查询 SELECT * FROM TableB WHERE valueRef = ? 获取对应关联数据。这种方式既避免了Intent传大数据的性能问题，也符合Android组件解耦的设计原则。
• 不推荐使用全局对象：全局对象（比如Application子类里的变量）虽然能存数据，但很容易引发内存泄漏——如果子Activity被销毁但全局对象还持有它的引用，或者数据集过大长期占用内存，都会导致问题。而且全局对象的生命周期和应用绑定，数据状态难以管理，比如应用退到后台被系统回收后，数据就丢失了。
• 关于Intent传值的性能：如果真的有特殊场景需要传递大数据集，Intent的putExtra确实会有性能瓶颈——数据需要序列化/反序列化，而且Intent有大小限制（一般几十KB级别），超过后会抛出TransactionTooLargeException。所以还是那句话，让目标组件自己去数据库取数据才是最优解。

这里有几个可行的方案，按推荐程度排序：

• 方案1：CursorLoader + ContentProvider（官方推荐）
  这是Android官方针对数据库数据展示的标准方案。首先创建TableB时要设置级联删除，避免脏数据：

  CREATE TABLE TableB (
      id INTEGER PRIMARY KEY,
      valueRef INTEGER NOT NULL REFERENCES TableA(id) ON DELETE CASCADE
  );
  

  这样删除TableA的条目时，对应的TableB数据会自动被删除。然后用ContentProvider封装数据库操作，删除数据后调用getContentResolver().notifyChange(uri, null)通知数据变化。CursorLoader会自动监听这个通知，重新查询数据并更新CursorAdapter，ListView就能自动同步刷新了。
• 方案2：发送本地广播
  在删除TableA条目的代码中，发送一个自定义广播（比如ACTION_TABLE_A_DELETED）。在展示TableB的子Activity里注册广播接收器，收到广播后重新执行查询，调用cursorAdapter.swapCursor(newCursor)更新ListView。注意要在Activity的onDestroy方法中注销广播接收器，避免内存泄漏。
• 方案3：在onResume中刷新数据
  这是最简单的方案，不需要额外监听逻辑。当从TableA页面返回子Activity时，子Activity的onResume方法会被调用，在这个方法里重新查询TableB的数据，更新CursorAdapter即可。缺点是不管数据有没有变化都会触发刷新，但对于小数据集来说完全够用。

内容的提问来源于stack exchange，提问作者neuronalbit