让你了解数据加载的生命周期

发表于 5年以前 | 总阅读数：1760 次

原文链接 : Making loading data lifecycle aware

创建动态应用需要动态数据，但我希望在 UI 线程加载数据前就已经把事情搞定（因为一些性能问题或其他类似的）。这样的讨论会因为情况/需求的不同而永远不会停止，但不妨只关注一种情况：只在加载 Activity/Fragment 的数据时使用 Loader。与 Loader 相关的讨论往往离不开 CursorLoader，但 Loader 可比 Cursor 厉害多了。

Loader 需要 API 11 或更高版本的 API，而且是 Support v4 库的组成，将最新的特性及 Bug 的修复带给 API 4 和更高版本的机器。

为什么 Loader 这么特别

一般情况下，设备配置只在屏幕旋转（涉及重新开始整个 Activity）时发生改变，原因之一是持有 Activity/View 的引用可能会导致内存泄漏。而 Loader 最大的优点就是能保存配置的改变。当 Activity 返回，你之前花费较大开销检索的数据依然在那。数据被组织成队列以被投递，所以你不会因为设备配置发生变化而丢失数据

更好的是：Loader 不会引起内存泄漏，因为一旦请求 Loader 的 Activity/Fragment 被永久销毁，Loader 也会随之被清理，也就意味着 Loader 不会在 Activity/Fragment 被销毁后继续加载数据，增加 App 负担。

Loader 的这两个优点完美匹配了 Activity/Fragment 这类具有生命周期的组件，使得你只需要考虑在生命周期的哪个时期开始/结束加载数据。

我不信，我不信

可能来个例子会好理解点，不妨假设我们正将普通的 AsyncTask 变为 Loader 的等价物，把这个类命名为：AsyncTaskLoaders。

public static class JsonAsyncTaskLoader extends
    AsyncTaskLoader<List<String>> {
  // You probably have something more complicated
  // than just a String. Roll with me
  private List<String> mData;
  public JsonAsyncTaskLoader(Context context) {
    super(context);
  }
  @Override
  protected void onStartLoading() {
    if (mData != null) {
      // Use cached data
      deliverResult(mData);
    } else {
      // We have no data, so kick off loading it
      forceLoad();
    }
  }
  @Override
  public List<String> loadInBackground() {
    // This is on a background thread
    // Good to know: the Context returned by getContext()
    // is the application context
    File jsonFile = new File(
      getContext().getFilesDir(), "downloaded.json");
    List<String> data = new ArrayList<>();
    // Parse the JSON using the library of your choice
    // Check isLoadInBackgroundCanceled() to cancel out early
  return data;
}
  @Override
  public void deliverResult(List<String> data) {
    // We’ll save the data for later retrieval
    mData = data;
    // We can do any pre-processing we want here
    // Just remember this is on the UI thread so nothing lengthy!
    super.deliverResult(data);
  }
}

上面的代码看起来和 AsyncTask 很像，但我们可以将返回的结果保存在对象变量中，并在配置改变时通过在 onStartLoading() 方法中调用 deliverResult() 立刻返回。但有人可能会注意到：如果我们要缓存数据的话，为什么不调用 forceLoad() 呢？因为这样才能让我们避免不断地重新加载数据。

这样还不够好 - 如果数据发生了改变呢？

我们简单的范例没有成功实现的是：我们没有被限制读取数据次数为一次 - Loader 是放入 BroadcastReceiver，ContentObserver（一些 CursorLoader 能处理的类），FileObserver，或 OnSharedPreferenceChangeListener。突然你的 Loader 就能意识到其他地方发生的改变，并重新加载对应的数据。为前面的 Loader 添加一个 FileObserver：

public static class JsonAsyncTaskLoader extends
    AsyncTaskLoader<List<String>> {
  // You probably have something more complicated
  // than just a String. Roll with me
  private List<String> mData;
  private FileObserver mFileObserver;
  public JsonAsyncTaskLoader(Context context) {
    super(context);
  }
  @Override
  protected void onStartLoading() {
    if (mData != null) {
      // Use cached data
      deliverResult(mData);
    }
    if (mFileObserver == null) {
      String path = new File(
          getContext().getFilesDir(), "downloaded.json").getPath();
      mFileObserver = new FileObserver(path) {
          @Override
          public void onEvent(int event, String path) {
            // Notify the loader to reload the data
            onContentChanged();
            // If the loader is started, this will kick off
            // loadInBackground() immediately. Otherwise,
            // the fact that something changed will be cached
            // and can be later retrieved via takeContentChanged()
          }
      };
      mFileObserver.startWatching()
    }
    if (takeContentChanged() || mData == null) {
      // Something has changed or we have no data,
      // so kick off loading it
      forceLoad();
    }
  }
  @Override
  public List<String> loadInBackground() {
    // This is on a background thread
    File jsonFile = new File(
        getContext().getFilesDir(), "downloaded.json");
    List<String> data = new ArrayList<>();
    // Parse the JSON using the library of your choice
    return data;
  }
  @Override
  public void deliverResult(List<String> data) {
    // We’ll save the data for later retrieval
    mData = data;
    // We can do any pre-processing we want here
    // Just remember this is on the UI thread so nothing lengthy!
    super.deliverResult(data);
  }
  protected void onReset() {
    // Stop watching for file changes
    if (mFileObserver != null) {
      mFileObserver.stopWatching();
      mFileObserver = null;
    }
  }
}

于是通过钩入 onStartLoading() 回调开始我们的处理，并在 onReset() 结束，我们可以完美地异步处理依赖的数据。我们将 onStopLoading() 作为回调的结束，但 onReset() 确保我们完全地覆盖整个回调的生命周期（甚至是生命周期中发生的配置改变）。

你可能注意到在 onStartLoading() 中使用的 takeContentChanged() - 这是 Loader 注意到某些数据发生改变（例如调用 onContentChanged（））而此时 Loader 已经停止，因此即使已经有缓存好的新数据，仍需要完成一次数据加载。

Note：在加载新数据之前我们依然传递酒的，缓存好的数据 - 确保 App 能表现正常，并在必要时改变 onStartLoading()。例如，你可能检查 takeContentChanged() 并立刻丢弃缓存的返回结果，而不是传递他们。

与 App 其他部分协作：LoaderManager

当然，即便是最好的 Loader，如果没有与什么东西相关也没用。而 Activity 与 Fragment 需要的关联点往往是某种形式的 LoaderManager。通过调用 FragmentActivity 的 getSupportLoaderManager() 或 Fragment 的 getLoaderManager() 就可以获取 LoaderManager 的实例。

几乎在任何情况下，你只需要调用一个方法：initLoader()，这个方法一般在 onCreate()/onActivityCreated() 中调用 - 基本上只要你需要加载一些数据时就要调用。调用时会传入一个唯一的 id (只在 Activity/Fragment 中唯一 - 而不是全局唯一），传入可选的 Bundle ，及一个 LoaderCallback 的回调。

Note: 别在 Fragment 的 onCreate() 方法中调用 initLoader() - 只在 onActivityCreated() 中调用，不然的话你使用的 Loader 将会是各个 Fragment 间共享的 Loader，就像 Lint 请求中提醒的那样，相关内容可以看这篇 Google+ 的博文。你可能会注意到 LoaderManager 中的 restartLoader() 方法，这个方法能让你强行进行重新加载。大多数情况下，如果 Loader 掌管着它的监听这个方法都必要，但如果你想要传入一个不同的 Bundle，它就变得必要了，因为那你会发现你之前使用的已存在的 Loader 已经被销毁，而一个新的 onCreateLoader() 的调用已经完成。

我们提到在上面的实例实现 FileObserver 时使用 onReset() 方法而不是 onStopLoading() - 这样我们才能知道它何时与正常的生命周期交互。仅仅通过调用 initLoader()，我们就钩入 Activity/Fragment 的生命周期，而且 onStopLoading() 会在相应的 onStop() 方法被调用时被调用。然而，onReset() 只在你在 Activity/Fragment 完全被销毁时特定/自动调用 destroyLoad() 方法时才会被调用。

LoaderCallbacks

LoaderCallback 是所有事务真正发生的地方，具体有三个回调：

onCreateLoader() — 构造具体的 Loader 实例
onLoadFinished() — 传递数据
onLoaderReset() — 清理引用以重设 Loader 数据

所以前面的例子会变成：

// A RecyclerView.Adapter which will display the data
private MyAdapter mAdapter;
// Our Callbacks. Could also have the Activity/Fragment implement
// LoaderManager.LoaderCallbacks<List<String>>
private LoaderManager.LoaderCallbacks<List<String>>
    mLoaderCallbacks =
    new LoaderManager.LoaderCallbacks<List<String>>() {
      @Override
      public Loader<List<String>> onCreateLoader(
          int id, Bundle args) {
        return new JsonAsyncTaskLoader(MainActivity.this);
      }
      @Override
      public void onLoadFinished(
          Loader<List<String>> loader, List<String> data) {
        // Display our data, for instance updating our adapter
        mAdapter.setData(data);
      }
      @Override
      public void onLoaderReset(Loader<List<String>> loader) {
        // Loader reset, throw away our data,
        // unregister any listeners, etc.
        mAdapter.setData(null);
        // Of course, unless you use destroyLoader(),
        // this is called when everything is already dying
        // so a completely empty onLoaderReset() is
        // totally acceptable
      }
    };
@Override
protected void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstanceState);
  // The usual onCreate() — setContentView(), etc.
  getSupportLoaderManager().initLoader(0, null, mLoaderCallbacks);
}

当然，没有硬性要求说必须使用 LoaderManager，即便你会发现这样做会更方便和省时间。你可以去看 FragmentActivity 和 LoaderManager 的源码以了解其内在的机制。

上面说的都很对，但我并不需要后台线程

AsyncTaskLoader 尝试简化摆脱后台线程需要完成的操作，但如果你已经自己实现了后台线程处理事务的功能，或通过 EventBus 这样的订阅模型处理事务，AsyncTaskLoader 提供的功能都显得很多余。不妨看看加载一个位置改变的例子，例子中没有将所有代码放入 Activity/Fragment 中：

public static class LocationLoader extends Loader<Location>
    implements GoogleApiClient.ConnectionCallbacks,
    GoogleApiClient.OnConnectionFailedListener,
    LocationListener {
  private GoogleApiClient mGoogleApiClient;
  private Location mLastLocation;
  private ConnectionResult mConnectionResult;
  public LocationLoader(Context context) {
    super(context);
  }
  @Override
  protected void onStartLoading() {
    if (mLastLocation != null) {
      deliverResult(mLastLocation);
    }
    if (mGoogleApiClient == null) {
      mGoogleApiClient = 
            new GoogleApiClient.Builder(getContext(), this, this)
            .addApi(LocationServices.API)
            .build();
      mGoogleApiClient.connect();
    }
  }
  @Override
  protected void onForceLoad() {
    // Resend the last known location if we have one
    if (mLastLocation != null) {
      deliverResult(mLastLocation);
    }
    // Try to reconnect if we aren’t connected
    if (!mGoogleApiClient.isConnected()) {
      mGoogleApiClient.connect();
    }
  }
  @Override
  public void onConnected(Bundle connectionHint) {
    mConnectionResult = null;
    // Try to immediately return a result
    mLastLocation = LocationServices.FusedLocationApi
        .getLastLocation(mGoogleApiClient);
    if (mLastLocation != null) {
      deliverResult(mLastLocation);
    }
    // Request updates
    LocationServices.FusedLocationApi.requestLocationUpdates(
        mGoogleApiClient, new LocationRequest(), this);
  }
  @Override
  public void onLocationChanged(Location location) {
    mLastLocation = location;
    // Deliver the location changes
    deliverResult(location);
  }
  @Override
  public void onConnectionSuspended(int cause) {
    // Cry softly, hope it comes back on its own
  }
  @Override
  public void onConnectionFailed(
      @NonNull ConnectionResult connectionResult) {
    mConnectionResult = connectionResult;
    // Signal that something has gone wrong.
    deliverResult(null);
  }
  /**
   * Retrieve the ConnectionResult associated with a null 
   * Location to aid inrecovering from connection failures.
   * Call startResolutionForResult() and then restart the
   * loader when the result is returned.
   * @return The last ConnectionResult
   */
  public ConnectionResult getConnectionResult() {
    return mConnectionResult;
  }
  @Override
  protected void onReset() {
    LocationServices.FusedLocationApi
        .removeLocationUpdates(mGoogleApiClient, this);
    mGoogleApiClient.disconnect();
  }
}

我们可以在上面的代码中注意到三个主要的组件：

onStartLoading() 启动订阅进程（在例子中，通过连接 GooglePlay Service 完成）
当我们获得返回的结果，调用 deliverResult()
最后在 onReset()中关闭连接并清理引用

此时 Loader 框架不知道 GooglePlay Service 的任何细节，但我们能够将其逻辑封装在一个地方，并依赖一个单独的 onLoadFinished() 得到更新后的位置。这种形式的封装当然有助于避免与位置数据提供者耦合 - 你剩余的代码不需要关心位置对象到底是如何得到，来自何方。

Note: 在这种情况下，数据加载失败将以返回空位置的形式报告，这个信号会使监听此加载活动的 Activity/Fragment 调用 getConnectionResult() 方法并处理该结果。需要提醒的一点是：onLoadFinished() 方法中包含对 Loader 的引用，因此你能在那个时期检索 Loader 的任何状态

Loader: 只读取数据

所以 Loader 在生命周期中只有一个目的：给你提供最新的信息，它通过观察设备的配置改变并添加其数据观测者完成该目的。这意味着 Activity/Fragment 不需要关注这些细节。（当然，你的 Loader 也不需要了解数据将会怎么被使用！）

如果你已经在使用保留的 Fragment（调用了 setRetainInstance(true) 的 Fragment）在配置发生改变时保存数据，强烈建议你改为使用 Loader。保留 Fragment，在了解整个 Activity 的生命周期后，应该被视作完全独立的实体，当 Loader 直接关联到一个 Activity 或 Fragment 的生命周期中（甚至子 Fragment！）而且更适合检索当前需要显示的数据时。例如你需要动态添加或删除一个 Fragment - Loader 允许你将加载进程关联到其生命周期中，而且始终避免配置改变摧毁了已加载的数据。

这个关注点也意味着你能够在 UI 之外进行数据加载的测试。这里的例子只传入 Context，但你能确切地传入到任何需要的类中（或模拟方法！）去减少测试。成为完全的事件驱动，当然可以在任意时刻判断当前 Loader 的状态及只为测试暴露某些额外的状态。