详细讲解Android中使用LoaderManager加载数据的方法

mAllLoaderManagers保存着一个Activity所拥有的所有LoaderManager，其key为String类型的who变量。若从Activity调用getLoaderManager，那么所得LoaderManager的who标签为(root):

   public LoaderManager getLoaderManager() {
     if (mLoaderManager != null) {
       return mLoaderManager;
     }
     mCheckedForLoaderManager = true;
     mLoaderManager = getLoaderManager("(root)", mLoadersStarted, true);
     return mLoaderManager;
   }

若从Fragment中使用getLoaderManager，则所得LoaderManager的who标签会根据Fragment的层级不同而不同，在Activity中处于最顶级的Fragment的who标签为：

android:fragment:X
X为序号。

而属于Fragment的Fragment所活的的LoaderManager who标签就成为了：

android:fragment:X:Y
甚至更大的深度。

2.LoaderManager状态量mLoadersStarted
在开篇分析的时候分析过LoaderManager内部保存了一个mStarted状态，很多操作会根据这个状态做不同处理。通过上边的分析也能看出，Fragment中获取LoaderManager最终是通过Activity获取的，在LoaderManager构造时，就将一个状态量mLoadersStarted传递了进去，这个状态量交给LoaderManager自行管理。

而无论是Fragment还是Activity，都有mLoadersStarted这样一个状态量，在onStart生命周期后为true，onStop后为false。所以在onStart生命周期后做initLoader操作就会使Loader一经初始化就开始运行了。

3.Fragment和Activity的生命周期
Fragment和Activity能够对LoaderManager产生影响的生命周期是一样的。

onStart

系统在onStart阶段会获取LoaderManager，如果成功获取，则调用LoaderManager的doStart()，这里需要特别说明的是，虽然所有LoaderManager都是保存在Activity中，但是在Activity的onStart生命周期其也只是会获取属于自己的(root)标签LoaderManager，而并不是将所有保存在mAllLoaderManagers里的Manager全部遍历一遍。

onStop（performStop）

处于onStop生命周期，但是系统内部是通过performStop调用的。在这里，同样会获取属于自己的LoaderManager，如果Activity是因为配置改变出发的onStop（旋转屏幕），则调用LoaderManager的doRetain()接口，如果不是，就调用LoaderManager的doStop()接口。