Loader 知识梳理(1) - LoaderManager初探

一、概述

刚开始学习Loader的时候，只是使用CursorLoader把它当作加载封装在ContentProvider中的数据的一种方式，但是如果我们学会了如何取定义自己的Loader，那么将不仅仅局限于读取ContentProvider的数据，在谷歌的蓝图框架中，就有一个分支是介绍如何使用Loader来实现数据的异步读取：

https://github.com/googlesamples/android-architecture/tree/todo-mvp-loaders/

我们现在来学习一下Loader的实现原理，这将帮助我们知道如何自定义自己的Loader来进行异步数据的加载。

二、Activity和LoaderManager的桥梁 - FragmentHostCallback

如果我们把Loader比喻为异步任务的执行者，那么LoaderManager就是这些执行者的管理者，而LoaderManager对于Loader的管理又会依赖于Activity/Fragment的生命周期。
在整个系统当中，LoaderManager和Activity/Fragment之间的关系是通过FragmentHostCallback这个中介者维系的，当Activity或者Fragment的关键生命周期被回调时，会调用FragmentHostCallback的对应方法，它再通过内部持有的LoaderManager实例来控制每个LoaderManager内的Loader。
在FragmentHostCallback当中，和Loader有关的成员变量包括：

    /** The loader managers for individual fragments [i.e. Fragment#getLoaderManager()] */
    private ArrayMap mAllLoaderManagers;
    /** Whether or not fragment loaders should retain their state */
    private boolean mRetainLoaders;
    /** The loader manger for the fragment host [i.e. Activity#getLoaderManager()] */
    private LoaderManagerImpl mLoaderManager;
    private boolean mCheckedForLoaderManager;
    /** Whether or not the fragment host loader manager was started */
    private boolean mLoadersStarted;

• mAllLoaderManagers：和Fragment关联的LoaderManager，每个Fragment对应一个LoaderManager。
• mRetainLoaders：Fragment的Loader是否要保持它们的状态。
• mLoaderManager：和Fragment宿主关联的LoaderManager。
• mCheckedForLoaderManager：当Fragment的宿主的LoaderManager被创建以后，该标志位变为true。
• mLoadersStarted：Fragment的宿主的Loader是否已经启动。

FragmentHostCallback的doXXX和Activity的对象关系

下面是整理的表格：

• restoreLoaderNonConfig <- onCreate
• reportLoaderStart <- performStart
• doLoaderStart <- onStart/retainNonConfigurationInstances
• doLoaderStop(true/false) <- performStop/retainNonConfigurationInstances
• retainLoaderNonConfig <- retainNonConfigurationInstances
• doLoaderDestroy <- performDestroy
• doLoaderRetain <- null

其中有个函数比较陌生，retainNonConfigurationInstances，我们看一下它的含义：

    NonConfigurationInstances retainNonConfigurationInstances() {
        Object activity = onRetainNonConfigurationInstance();
        HashMap children = onRetainNonConfigurationChildInstances();
        FragmentManagerNonConfig fragments = mFragments.retainNestedNonConfig();
        
        //由于要求保存loader的状态，所以我们需要标志loader，为此，我们需要在将它交给下个Activity之前重启一下loader
        mFragments.doLoaderStart();
        mFragments.doLoaderStop(true);
        ArrayMap loaders = mFragments.retainLoaderNonConfig();

        if (activity == null && children == null && fragments == null && loaders == null
                && mVoiceInteractor == null) {
            return null;
        }

        NonConfigurationInstances nci = new NonConfigurationInstances();
        nci.activity = activity;
        nci.children = children;
        nci.fragments = fragments;
        nci.loaders = loaders;
        if (mVoiceInteractor != null) {
            mVoiceInteractor.retainInstance();
            nci.voiceInteractor = mVoiceInteractor;
        }
        return nci;
    }

我们看到，它保存了大量的信息，最后返回一个NonConfigurationInstances，因此我们猜测它和onSaveInstance的作用是类似的，在attach方法中，传入了lastNonConfigurationInstances，之后我们就可以通过getLastNonConfigurationInstance来得到它，但是需要注意，这个变量在performResume之后就会清空。
通过ActivityThread的源码，我们可以看到，这个方法是在onStop到onDestory之间调用的。

//调用onStop()
r.activity.performStop(r.mPreserveWindow);
//调用retainNonConfigurationInstances
r.lastNonConfigurationInstances = r.activity.retainNonConfigurationInstances();
//调用onDestroy().
mInstrumentation.callActivityOnDestroy(r.activity);

总结下来，就是一下几点：

• 在onStart时启动Loader
• 在onStop时停止Loader
• 在onDestory时销毁Loader
• 在配置发生变化时保存Loader

三、LoaderManager/LoaderManagerImpl的含义

通过上面，我们就可以了解系统是怎么根据Activity/Fragment的生命周期来自动管理Loader的了，现在，我们来看一下LoaderManagerImpl的具体实现，这两个类的关系是：

• LoaderManager：这是一个抽象类，它内部定义了LoaderCallbacks接口，在loader的状态发生改变时会通过这个回调通知使用者，此外，它还定义了三个关键的抽象方法，调用者只需要使用这三个方法就能完成数据的异步加载。
• LoaderManagerImpl：继承于LoaderManager，真正地实现了Loader的管理。

四、LoaderManager的接口定义

public abstract class LoaderManager {
    /**
     * Callback interface for a client to interact with the manager.
     */
    public interface LoaderCallbacks {
        /**
         * Instantiate and return a new Loader for the given ID.
         *
         * @param id The ID whose loader is to be created.
         * @param args Any arguments supplied by the caller.
         * @return Return a new Loader instance that is ready to start loading.
         */
        public Loader onCreateLoader(int id, Bundle args);

        /**
         * Called when a previously created loader has finished its load.  Note
         * that normally an application is not allowed to commit fragment
         * transactions while in this call, since it can happen after an
         * activity's state is saved.  See {@link FragmentManager#beginTransaction()
         * FragmentManager.openTransaction()} for further discussion on this.
         * 
         * 
This function is guaranteed to be called prior to the release of
         * the last data that was supplied for this Loader.  At this point
         * you should remove all use of the old data (since it will be released
         * soon), but should not do your own release of the data since its Loader
         * owns it and will take care of that.  The Loader will take care of
         * management of its data so you don't have to.  In particular:
         *
         * 

         * 
 
The Loader will monitor for changes to the data, and report
         * them to you through new calls here.  You should not monitor the
         * data yourself.  For example, if the data is a {@link android.database.Cursor}
         * and you place it in a {@link android.widget.CursorAdapter}, use
         * the {@link android.widget.CursorAdapter#CursorAdapter(android.content.Context,
         * android.database.Cursor, int)} constructor without passing
         * in either {@link android.widget.CursorAdapter#FLAG_AUTO_REQUERY}
         * or {@link android.widget.CursorAdapter#FLAG_REGISTER_CONTENT_OBSERVER}
         * (that is, use 0 for the flags argument).  This prevents the CursorAdapter
         * from doing its own observing of the Cursor, which is not needed since
         * when a change happens you will get a new Cursor throw another call
         * here.
         * 
 The Loader will release the data once it knows the application
         * is no longer using it.  For example, if the data is
         * a {@link android.database.Cursor} from a {@link android.content.CursorLoader},
         * you should not call close() on it yourself.  If the Cursor is being placed in a
         * {@link android.widget.CursorAdapter}, you should use the
         * {@link android.widget.CursorAdapter#swapCursor(android.database.Cursor)}
         * method so that the old Cursor is not closed.
         * 
         *
         * @param loader The Loader that has finished.
         * @param data The data generated by the Loader.
         */
        public void onLoadFinished(Loader loader, D data);

        /**
         * Called when a previously created loader is being reset, and thus
         * making its data unavailable.  The application should at this point
         * remove any references it has to the Loader's data.
         *
         * @param loader The Loader that is being reset.
         */
        public void onLoaderReset(Loader loader);
    }
    
    /**
     * Ensures a loader is initialized and active.  If the loader doesn't
     * already exist, one is created and (if the activity/fragment is currently
     * started) starts the loader.  Otherwise the last created
     * loader is re-used.
     *
     * 
In either case, the given callback is associated with the loader, and
     * will be called as the loader state changes.  If at the point of call
     * the caller is in its started state, and the requested loader
     * already exists and has generated its data, then
     * callback {@link LoaderCallbacks#onLoadFinished} will
     * be called immediately (inside of this function), so you must be prepared
     * for this to happen.
     *
     * @param id A unique identifier for this loader.  Can be whatever you want.
     * Identifiers are scoped to a particular LoaderManager instance.
     * @param args Optional arguments to supply to the loader at construction.
     * If a loader already exists (a new one does not need to be created), this
     * parameter will be ignored and the last arguments continue to be used.
     * @param callback Interface the LoaderManager will call to report about
     * changes in the state of the loader.  Required.
     */
    public abstract  Loader initLoader(int id, Bundle args,
            LoaderManager.LoaderCallbacks callback);

    /**
     * Starts a new or restarts an existing {@link android.content.Loader} in
     * this manager, registers the callbacks to it,
     * and (if the activity/fragment is currently started) starts loading it.
     * If a loader with the same id has previously been
     * started it will automatically be destroyed when the new loader completes
     * its work. The callback will be delivered before the old loader
     * is destroyed.
     *
     * @param id A unique identifier for this loader.  Can be whatever you want.
     * Identifiers are scoped to a particular LoaderManager instance.
     * @param args Optional arguments to supply to the loader at construction.
     * @param callback Interface the LoaderManager will call to report about
     * changes in the state of the loader.  Required.
     */
    public abstract  Loader restartLoader(int id, Bundle args,
            LoaderManager.LoaderCallbacks callback);

    /**
     * Stops and removes the loader with the given ID.  If this loader
     * had previously reported data to the client through
     * {@link LoaderCallbacks#onLoadFinished(Loader, Object)}, a call
     * will be made to {@link LoaderCallbacks#onLoaderReset(Loader)}.
     */
    public abstract void destroyLoader(int id);

    /**
     * Return the Loader with the given id or null if no matching Loader
     * is found.
     */
    public abstract  Loader getLoader(int id);

    /**
     * Returns true if any loaders managed are currently running and have not
     * returned data to the application yet.
     */
    public boolean hasRunningLoaders() { return false; }
}

这一部分，我们先根据源码的注释对这些方法有一个大概的了解：

• public Loader onCreateLoader(int id, Bundle args)

• 当LoaderManager需要创建一个Loader时，回调该函数来要求使用者提供一个Loader，而id为这个Loader的唯一标识。

• public void onLoadFinished(Loader loader, D data)

• 当之前创建的Loader完成了任务之后回调，data就是得到的数据。

• 回调时，可能Activity已经调用了onSaveInstanceState，因此不建议在其中提交Fragment事务。

• 这个方法会保证数据资源在被释放之前调用，例如，当使用CursorLoader时，LoaderManager会负责cursor的关闭。

• LoaderManager会主动监听数据的变化。

• public void onLoaderReset(Loader loader)

• 当先前创建的某个Loader被reset时回调。

• 调用者应当在收到该回调以后移除与旧Loader有关的数据。

• public abstract Loader initLoader(int id, Bundle args, LoaderManager.LoaderCallbacks callback)

• 用来初始化和激活Loader，args一般用来放入查询的条件。

• 如果id对应的Loader之前不存在，那么会创建一个新的，如果此时Activity/Fragment已经处于started状态，那么会启动这个Loader。

• 如果id对应的Loader之前存在，那么会复用之前的Loader，并且忽略Bundle参数，它仅仅是使用新的callback。

• 如果调用此方法时，满足2个条件：调用者处于started状态、Loader已经存在并且产生了数据，那么onLoadFinished会立刻被回调。

• 这个方法一般来说应该在组件被初始化调用。

• public abstract Loader restartLoader(int id, Bundle args, LoaderManager.LoaderCallbacks callback)

• 启动一个新的Loader或者重新启动一个旧的Loader，如果此时Activity/Fragment已经处于Started状态，那么会开始loading过程。

• 如果一个相同id的loader之前已经存在了，那么当新的loader完成工作之后，会销毁旧的loader，在旧的Loader已经被destroyed之前，会回调对应的callback。

• 因为initLoader会忽略Bundle参数，所以当我们的查询需要依赖于bundle内的参数时，那么就需要使用这个方法。

• public abstract void destroyLoader(int id)

• 停止或者移除对应id的loader。

• 如果这个loader之前已经回调过了onLoadFinished方法，那么onLoaderReset会被回调，参数就是要销毁的那个Loader实例。

• public abstract Loader getLoader(int id)

• 返回对应id的loader。

• public boolean hasRunningLoaders()

• 是否有正在运行，但是没有返回数据的loader。

五、LoaderInfo

LoaderInfo 包装了 Loader，其中包含了状态变量提供给 LoaderManager，并且在构造时候传入了 LoaderManager.LoaderCallbacks