Android 应用 Loaders 全面详解及源码浅析

1 背景

在Android中任何耗时的操作都不能放在UI主线程中,所以耗时的操作都需要使用异步实现。同样的,在ContentProvider中也可能存在耗时操作,这时也该使用异步操作,而3.0之后最推荐的异步操作就是Loader。它可以方便我们在Activity和Fragment中异步加载数据,而不是用线程或AsyncTask,他的优点如下:

  • 提供异步加载数据机制;
  • 对数据源变化进行监听,实时更新数据;
  • 在Activity配置发生变化(如横竖屏切换)时不用重复加载数据;
  • 适用于任何Activity和Fragment;

PS:由于在我们现在的多个项目中都大量的使用了Loader来处理数据加载(而且由于粗心跳过几个坑,譬如Loader ID重复导致数据逻辑异常、多线程中restartLoader导致Loader抛出异常(最后保证都在UI线程中执行即可)等),所以接下来我们进行下使用及源码浅析。

PPPS:前方高能,文章巨长,请做好心理准备(您可以选择通过左上角目录点击索引到感兴趣的章节直接查看,或者,或者,或者直接高能往下看)。

2 基础使用实例

该基础实例讲解完全来自于官方文档,详细可以点击我查看英文原文

既然接下来准备要说说他的使用强大之处了,那不妨我们先来一张图直观的感性认识下不用Loader(左)与用Loader(右)对我们开发者及代码复杂度和框架的影响吧,如下:

10-11-1

2-1 Loader API概述说明

如下是我们开发中常用的一些Loader相关接口:

Class/Interface Description
LoaderManager 一个与Activity、Fragment关联的抽象类,用于管理一个或多个Loader实例。每个Activity或Fragment只能有一个LoaderManager,而一个LoaderManager可以有多个Loader。
LoaderManager.LoaderCallbacks 用于和LoaderManager交互的回调接口。譬如,可以使用onCreateLoader()创建一个新的Loader。
AsyncTaskLoader 抽象的Loader,提供一个AsyncTask继承实现。
CursorLoader AsyncTaskLoader的子类,用于向ContentResover请求返回一个Cursor。该类以标准游标查询实现了Loader协议,使用后台线程进行查询,使用这个Loader是从ContentProvider加载异步数据最好的方式。

2-2 在应用中使用Loader

在我们开发的一个App里,使用Loader时常规的步骤包含如下一些操作需求:

  • 一个Activity或Fragment;
  • 一个LoaderManager实例;
  • 一个CursorLoader,从ContentProvider加载数据;
  • 一个LoaderManager.LoaderCallbacks实现,创建新Loader及管理已存在Loader;
  • 一个组织Loader数据的Adapter,如SimpleCursorAdapter;

下面我们看下具体流程。

2-2-1 启动一个Loader(initLoader)

一个Activity或Fragment中LoaderManager管理一个或多个Loader实例,每个Activity或Fragment只有一个LoaderManager,我们可以在Activity的onCreate()或Fragment的onActivityCreated()里初始化一个Loader。例如:

可以看见上面的initLoader()方法有三个参数:

  • 第一个参数代表当前Loader的ID;
  • 第二个参数代表提供给Loader构造函数的参数,可选;
  • 第三个参数代表LoaderManager.LoaderCallbacks的回调实现;

上面initLoader()方法的调用确保了一个Loader被初始化和激活的状态,该方法的调运有如下两种结果:

  • 如果代表该Loader的ID已经存在,则后面创建的Loader将直接复用已经存在的;
  • 如果代表该Loader的ID不存在,initLoader()会触发LoaderManager.LoaderCallbacks回调的onCreateLoader()方法创建一个Loader;

可以看见通过initLoader()方法可以将LoaderManager.LoaderCallbacks实例与Loader进行关联,且当Loader的状态变化时就被回调。所以说,如果调用者正处于其开始状态并且被请求的Loader已经存在,且已产生了数据,那么系统会立即调用onLoadFinished()(在initLoader()调用期间),所以你必须考虑到这种情况的发生。

当然了,intiLoader()会返回一个创建的Loader,但是你不用获取它的引用,因为LoadeManager会自动管理该Loader的生命周期,你只用在它回调提供的生命周期方法中做自己数据逻辑的处理即可。

2-2-2 重启一个Loader(restartLoader)

通过上面initLoader()方法介绍我们可以知道initLoader调运后要么得到一个ID已存在的Loader,要么创建一个新的Loader;但是有时我们想丢弃旧数据然后重新开始创建一个新Loader,这可怎么办呢?别担心,要丢弃旧数据调用restartLoader()即可。例如,SearchView.OnQueryTextListener的实现重启了Loader,当用户查询发生变化时Loader需要重启,如下:

上面方法的参数啥的和再上面的init方法类似,就不再罗嗦了。

2-2-3 使用LoaderManager Callbacks

LoaderManager.LoaderCallbacks是LoaderManager的回调交互接口。LoaderManager.LoaderCallbacks包含如下三个方法:

  • onCreateLoader()
    实例化并返回一个新创建给定ID的Loader对象;
  • onLoadFinished()
    当创建好的Loader完成了数据的load之后回调此方法;
  • onLoaderReset()
    当创建好的Loader被reset时调用此方法,这样保证它的数据无效;

2-2-3-1 onCreateLoader说明

当你尝试使用一个Loader(譬如通过initLoader()方法),它会检查给定Loader的ID是否存在,如果不存在就触发LoaderManager.LoaderCallbacks里的onCreateLoader()方法创建一个新Loader。创建新Loader实例典型的做法就是通过CursorLoader类创建,不过你也可以自定义一个继承自Loader的子类来实现自己的Loader。

下面的例子中我们通过onCreateLoader()回调创建一个CursorLoader实例,使用CursorLoader的构造方法创建实例时需要一些参数去查询一个ContentProvider。具体参数如下:

  • uri
    准备获取内容的URI。
  • projection
    要返回的列key list,null表示返回所有列,但是返回所有列很多时候会降低性能;
  • selection
    要返回的行过滤,也就是SQL中的WHERE语句,null代表返回uri指定的所有行;
  • selectionArgs
    用来替换上面selection中包含的“?”;
  • sortOrder
    结果的行排序,也就是SQL中的ORDER BY,传递null则无序;

2-2-3-2 onLoadFinished说明

当创建好的Loader完成数据加载时回调此方法,我们要确保该方法在Loader释放现有维持的数据之前被调用。在这里我们应该移除所有对旧数据的使用(因为旧数据不久就会被释放),但是不用释放旧数据,因为Loader会帮我们完成旧数据的释放。

Loader一旦知道App不再使用旧数据就会释放掉。例如,如果数据来自CursorLoader里的一个Cursor,我们不应该自己在代码中调用close()方法;如果一个Cursor正在被放置到一个CursorAdapter时我们应当使用swapCursor()进行新数据交换,这样正在被放置的旧的Cursor就不会被关掉,也就不会导致Adapter的加载异常。

2-2-3-3 onLoaderReset说明

当实例化好的Loader被重启时该方法被回调,这里会让Loader的数据置于无效状态。这个回调方法其实就是为了告诉我们啥时候数据要被释放掉,所以我们应该在这个时候移除对它的引用。如下移除实例:

2-2-4 Loader使用实例实战

下面这个实例是一个Fragment,模拟的是用ListView显示通讯录的实时匹配查询结果,使用CursorLoader管理通讯录Provider查询。如下源码,比较简单,注释也很丰富了,所以不过多解释:

到此整个Loader基础使用就介绍完了,关于Loader的高级功能,譬如自定义Loader等内容这里先不贴代码说明,因为在这里一下子说完都会觉得蒙圈,而且接受难度也比较大,所以我们在上面这些基础铺垫之后乘热先来源码浅析,有了源码浅析把持住全局结构后再去用Loader的高级用法就会觉得得心应手许多。

3 源码浅析

和上面的基本使用介绍一样,关于Loader的源码浅析过程会涉及到Activity、Fragment、LoaderManager、Loader、AsyncLoader、CursorLoader等类。所以我们分析的过程还是和以前一样,依据使用顺序进行分析。

我们在分析之前先来看一个Loader框架概要图,如下:

10-11-2

通过上面图和前面的基础实例你会发现Loader的框架和各个类的职责都很明确。Activity和Fragment管理LoaderManager,LoaderManager管理Loader,Loader得到数据后触发在LoaderManager中实现的Loader的callback接口,LoaderManager在接收到Loader的callback回传调运时触发我们Activity或Fragment中实现的LoaderManager回调callback接口,就这样就实现了Loader的所有功能,而我们平时写代码一般只用关心LoaderManager的callback实现即可;对于自定义Loader可能还需要关心AsyncTaskLoader子类的实现。

3-1 Activity及Fragment中LoadManager的管理浅析

首先我们都知道,在使用Loader的第一步就是在Activity或者Fragment中获取LoaderManager实例,所以我们先来看下Activity和Fragment是如何管理这些LoaderManager的。

先来看看Fragment中的LoaderManager,如下:

从上面可以看出,Fragment在其生命周期内会控制LoaderManager(LoaderManager其实控制了Loader)的doStart、doDestroy等方法,也就是说我们在Fragment中只管通过getLoaderManager方法来获取LoaderManager实例,然后使用就行,别的Fragment都会帮我们处理OK的。

接下来看看Activity中的LoaderManager,如下:

通过上面的分析可以发现,Activity其实真正的管理了Activity及Fragment的LoaderManager(Fragment也会管理一部分自己LoaderManager的周期),而LoaderManager又管理了Loader,可以发现他们各自的管理范围都是十分的清晰明了的。

3-2 LoadManager及其实现类LoadManagerImpl的浅析

上面分析Activity及Fragment中获取LoaderManager实例时已经知道,我们获取的LoaderManager实例其实就是LoaderManagerImpl对象,而LoaderManagerImpl又是LoaderManager类的子类,所以接下来我们来分析这两个父子类。

先看下抽象父类LoaderManager,如下:

可以看见LoaderManager抽象类只是定义了一些规范接口而已,那么接着我们看下抽象类LoaderManager的实现类LoaderManagerImpl,如下:

我勒个去!好长,好累!通过上面粗略的分析你会发现和我们上面基础实例介绍LoaderManager的方法时描述的一样,每个方法都有自己的特点,发挥着各自的作用,LoaderManager的实质是将Loader对象转换为LoaderInfo来进行管理,也就是管理了所有的Loader对象。

3-3 Loader及其实现类的浅析

上面分析了Activity及Fragment管理了LoaderManager的相关方法,LoaderManager管理了Loader的相关方法,那么接下来我们就来看看这个被管理的终极目标Loader是咋回事,还有他的子类咋回事。

先来看看我画的一张关系图,如下:

10-11-3

我去,这图现在看可能有些吓人,我们还是先来慢慢分析一下再说吧。

3-3-1 Loader基类源码浅析

我们先来看看这个Loader基类吧,该类核心方法及内部类结构图如下:

10-11-4

代码分析如下:

通过上面粗略的分析可以发现,Loader基类无非也就是一个方法接口的定义类,组织预留了一些方法供LoaderManager去调运处理,同时需要子类实现其提供的一些onXXX方法,以便LoaderManager调运Loader的方法时可以触发Loader子类的实现逻辑。

3-3-2 AsyncTaskLoader抽象子类源码浅析

上面既然说了Loader类的作用主要是规定接口,同时供LoaderManager管理,那LoaderManager管理的Loader自然需要做一些事情,也就是说我们需要继承Loader实现一些逻辑操作。然而好在系统API已经帮我们实现了一些简单的封装实现,我们这里就先来看下Loader的直接子类AsyncTaskLoader吧,先来看下该抽象子类的方法及内部类粗略图,如下:

10-11-5

代码分析如下:

可以看见上面继承Loader的AsyncTaskLoader其实质是提供了一个基于AsyncTask工作机制的Loader(子类LoadTask继承AsyncTask<Void, Void, D>,并且实现了Runable接口,功能十分强大。),但是不可直接用,因为其为abstract抽象类,所以我们需要继承实现它才可以使用,然而好在系统API已经帮我们提供了他现成的子类CursorLoader,但CursorLoader同时也限制了Loader的泛型数据为Cursor类型。当然了,我们如果想要Loader自己的类型数据那也很简单—继承实现AsyncTaskLoader即可,后面会给出例子的。

3-3-3 CursorLoader子类源码浅析

有了上面继承自Loader的抽象AsyncTaskLoader,接下来我们就来看看SDK为我们提供的抽象AsyncTaskLoader实现类CursorLoader,我们先来粗略看看该类的方法图,如下:

10-11-6

具体代码分析如下:

可以发现,CursorLoader的封装大大简化了应用开发者代码的复杂度;它完全就是一个异步的数据库查询瑞士军刀,没有啥特别需要分析的地方,所以不再过多说明。

3-4 Loaders相关源码浅析总结

通过上面我们的源码分析和分析前那副图可以总结如下结论:

  • 一次完整的数据加载流程为Activity调用LoaderManager的doStart()方法,然后LoaderManager调用Loader的startLoading()方法,然后Loader调运AsyncTaskLoader的doingBackground()方法进行耗时数据加载,然后AsyncTaskLoader回调LoaderManager的complete数据加载完成方法,接着LoaderManager回调我们在Activity中实现的callback中的onLoadFinish()方法。
  • Acivity和Fragment的生命周期主动管理了LoaderManager,每个Activity用一个ArrayMap的mAllLoaderManager来保存当前Activity及其附属Frament的唯一LoaderManager;在Activity配置发生变化时,Activity在destory前会保存mAllLoaderManager,当Activity再重新创建时,会在Activity的onAttcach()、onCreate()、performStart()方法中恢复mAllLoaderManager。
  • LoaderManager给Activity提供了管理自己的一些方法;同时主动管理了对应的Loader,它把每一个Loader封装为LoadInfo对象,同时它负责主动调运管理Loader的startLoading()、stopLoading()、,forceLoad()等方法。
  • 由于整个Activity和Fragment主动管理了Loader,所以关于Loader的释放(譬如CursorLoader的Cursor关闭等)不需要我们人为处理,Loader框架会帮我们很好的处理的;同时特别注意,对于CursorLoader,当我们数据源发生变化时Loader框架会通过ContentObserver调用onContentChanged的forceLoad方法重新请求数据进行回调刷新。

好了,至此你会发现Loader真的很牛叉,No!应该是Google的工程师真的很牛叉,架构真的很赞,值得推荐。

4 应用层开发之Loader进阶实战

上面对于Loader的基础使用及源码框架都进行了简单分析,有了上面的铺垫我们再回过头来看看我们开发中的一些高级技巧,通过这些高级技巧不仅是对前面源码分析的实例验证,也是对自己知识的积累。

4-1 ContentPorvider情况下的CurSorLoader自动刷新

在我们使用CurSorLoader时大家都会考虑一种情况的处理—–当数据库发生变化时如何自动刷新当前UI。呵呵,我们先来说说这个原理,数据库在数据改变时通过ContentPorvider和ContentResolver发出通知,接着ContentProvider通知Cursor的观察者数据发生了变化,然后Cursor通知CursorLoader的观察者数据发生了变化,接着CursorLoader通过ContentProvider加载新数据,完事调用CursorAdapter的changeCursor()用新数据替换旧数据显示。

这个过程具体的实现步骤如下:

  1. 对获取的Cursor数据设置需要监听的URI(即,在ContentProvider的query()方法或者Loader的loadingBackground()方法中调用Cursor的setNotificationUri()方法);
  2. 在ContentProvider的insert()、update()、delete()等方法中调用ContentResolver的notifyChange()方法;

通过上面两步我们就能享受CurSorLoader的自动数据刷新功能了;可以发现,所谓的CurSorLoader自动刷新无非就是观察者模式的框架而已,所以不再过多说明。

特别注意:

有些人觉得为了方便可能会将上面第一步对于Cursor设置监听直接写在了ContentProvider的query()方法中,如下:

这里要提醒的是,这种写法在某些场合下是不值得推荐的(譬如大规模上千次并发平凡的调运query操作场合),因为效率极低,他会频繁的通过Binder进行通信,导致system_server不停的调运GC操作,以至于会使系统卡顿。

PS:因为我以前跳过一次这个坑,平时使用应用没啥问题,但是当进行压力测试时却发现LogCat一直在不停的打印GC,同时导致当前系统卡顿,杀掉应用后系统就不卡了,所以基本怀疑问题就出在了应用中,于是通过很多办法去查找(譬如dempsys content去查看个数),最终发现罪魁祸首是这个监听频繁调运导致的,随将其挪到loadingBackground中不再卡顿。

4-2 不使用ContentPorvider且自定义Loader的情况下自动刷新

我们目前的项目其实都使用了ContentPorvider实现,所以就是上面讲的那些情况。但是你一定会问,如果我们应用的数据不用于应用间共享,使用ContentProvider那得多麻烦啊?我先告诉你,是很麻烦,但是Android提供的CursorLoader的API必须使用ContentProvider才能实现数据加载和自动刷新。

这时候你指定会说,那还说个屁!哎,别急,你看看下面这段代码是否会有所感触呢,如下:

咦?是不是上面代码很奇怪,异步操作的方法中没有使用ContentProvider,而是直接读取了数据库。握草!这不就是我们刚刚想要的需求么,它没有使用ContentProvider提供Cursor数据,同时实现了数据变化自动更新功能。

简单解释下上面代码的原理吧,我们自定义的NoProviderLoader中定义的ForceLoadContentObserver是Loader的一个内部类,上面源码分析已经解释过了,当数据变化时会调运该类的onChange()方法,实质是调运了Loader的forceLoad()方法,所以能够自动刷新,不多解释了。

4-3 Loader自定义之AsyncTaskLoader衍生

可能看到这里你更加会举一反三的反驳一句了,上面搞了半天都是和数据库Cursor相关的东东,难道Loader就不能异步处理别的数据结构么?答案是能,因为你可能已经注意到了Loader和AsyncTaskLoader都是泛型类;既然这样,那我们找猫画虎一把呗,仿照CursorLoader自定义一个自己的异步加载试试,具体实现如下(哈哈,想了又想,这里还是直接给出官方的自定义AsyncTaskLoader好点,毕竟权威些,详细点我查看官方自定义实现Demo):

官方对于查询已安装App列表的Loader实现,支持新App安装后自动刷新的功能,实现如下:

强大的一逼!这下满技能,不解释,自己看。

4-4 进阶总结

通过前面基础实例、源码分析、进阶演示你会发现Loader的真的非常好用,非常牛逼,牛逼的我不想再解释啥了,自己体会吧。

PS:之前看见微博上有人讨论AsyncTaskLoader与AsyncTask的区别,这下彻底明朗了,看完源码我们再回过头来总结性的说说他们二者区别,如下:

class 优势 劣势
AsyncTaskLoader 会自动刷新数据变化;会自动处理Activiy配置变化造成的影响;适合处理纯数据加载; 不能实时通知UI刷新;不能在onLoadFinished时主动切换生命周期(譬如replace Fragment);
AsyncTask 可以与UI实时交互及replace操作; 不会自动处理Activiy配置变化造成的影响;

好了,该撕逼的也撕了,该装逼的也装了,该分析的也分析了,该学习的也学到了,接下来就是看自己如何带着Loader去叱诧风云了。

1 收藏 评论

可能感兴趣的话题



直接登录
跳到底部
返回顶部