- 原文作者 : Ian Lake
- 译文出自 : 开发技术前线 www.devtf.cn
- 转载声明: 本译文已授权开发者头条享有独家转载权，未经允许，不得转载!
- 译者 : chaossss
- 校对者: desmond1121
- 状态 : 完成
创建动态应用需要动态数据，但我希望在 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 的状态及只为测试暴露某些额外的状态。
Note: 当有一个 LoaderTestCase 是为框架类设计的，如果你想要在 support v4 库的 Loader 完成相同的工作，你将需要利用 LoaderTestCase 源码开发一个支持库。这当然有助于你在不用 LoaderManager 的情况下与 Loader 交互。
值得一提的是，现在 Loader 是活性的数据接收器。它们不负责改变依赖的数据，但它们覆盖对应组件的生命周期，并关注配置改变，从而为 UI 获取最新数据。
##开发更好的 App 加入 Google + 和我们一起讨论这个问题，关注 Android Development Patterns 以了解更多！