Android开发者都经历过APP UI开发不当 会造成overDraw，导致APP UI渲染过慢，但是很多人却没听过overLoad，overLoad一般是由于开发者在主线程操作耗时操作，导致程序变慢 甚至出现的anr的现象，那么android早已为这种现象提供完美的解决方案，就是今天给大家说的Loader机制。
一 Loader
Android的装载器（loader）是从Android 3.0新引入的API , 主要完成单线程耗时数据异步装载功能，并在数据有更新自动通知UI刷新的作用。业内也叫加载器，装载机。
Loader用途
Loader一般用在Activity和fragment异步加载数据，无需重新启动一个线程来执行数据加载，异步加载可以用asyncTask, 但是loader自带数据结果监听机制，可以方便优雅的进行UI更新。
作用和优点：
提供异步加载数据功能；
对数据源变化进行监听，实时更新数据；
在Activity配置发生变化（如横竖屏切换）时不避免数据重复加载；
适用于任何Activity和Fragment；
加载耗时数据常用方式
android开发者都知道不能再UI线程里去执行耗时操作，甚至在4.0里已经无法在主线程里去访问网络，那么一般加载耗时操作有以下办法。
1 2B加载
2 普通加载
3 文艺加载
为何说1和2是不可取呢，我们从Loader源码看起，文章结束会知道答案。
二 Loader实现
Loader源码在android.content下面，可见它的份量有多重，loader机制包括LoaderManager，Loader，LoaderCallbacks三部分，
LoaderManager 来管理我们的laoder实例，获取，初始化，重启一个loader,
Loader 来执行我们的异步操作，有开始，完成，后台加载中等接口实现
LoaderCallbacks 来执行我们的loader回调，主要是绑定分发Loader，完成加载，重置数据等。
流程如下图：
1 LoaderManager
LoaderManager是抽象类，负责管理一组Loader,主要定义执行Loader的一些抽象方法，类结构如下图：
从上图看以看出，Ta里面主要初始化loader,获取 重启,销毁一个loader，也包含一个内部成员变量LoaderCallback回调，主要方便我们在上层写回调实现累操作，但真正是由他的实现类LoaderManagerImpl去完成操作的,
LoaderManagerImpl 记录着一组LoaderInfo信息，（ps：Activity也同等拥有activityInfo一样，只不过记录是Activityrecord来完成，其实谷歌很多源码都是相同的），并且持有LoaderManager.LoaderCallbacks， mLoader等成员，负责对Loader和LoaderCallbacks的对应回调，内部基于观察者模式实现，源码不在解读;
2 Loader
Loader是具体来操作任务的类，负责去调用不同渠道的数据接口，比如数据库，contentProvider, 文件等。
从大致的UML图我可以了解loader持有一个内部观察者，和一些注册注销观者的内部方法，并且已经暴露出来的加载操作的状态步骤的方法，包括加载中，取消加载，强制加载，内容发生改变等，
在平常的开发中，谷歌为我们提供了laoder的子类，AsyncTaskLoader，CursorLoader等子类， 源码不在介绍，现在说下他们的不同点。CursorLoader也是AsyncTaskLoader的子类，主要负责数据库查询的异步加载，AsyncTaskLoader可用来所有异步加载。
2.1 AsyncTaskLoader
AsyncTaskLoader继承了Loader, 除了拥有loader的功能，还有executePendingTask()， dispatchOnCancelled（），onLoadInBackground()等方法，最神奇的是他拥有AsyncTask的实例，并且实现Runnable,这是他能进行异步的原因所在。对AsyncTask不熟悉的请自我补脑，看如下代码，
笔者看了源码，AsyncTaskLoader拥有AsyncTask，在自身实例化后开启一个线程，自我进行executePendingTask()，此方法里其实就在执行asyncTask的mTask.executeOnExecutor(mExecutor,(Void[])null);�来实现AsyncTaskLoader的自我监听机制，当然自身轮询和通信是离不开Handler的 因为整个android的通讯就是建立在Handler（底层binder）基础上，这里不再分析。
2.2 CursorLoader
CursorLoader是AsyncTaskLoader的子类，内部持有ForceLoadContentObserver变量，观察者来实现对数据源的数据更新，执行加载数据操作，最重要的当然是离不开查询操作，内部主要代码：
三 怎么使用loader
1 启动一个Loader
Activity初始化在oncreate()初始化，一个Activity或Fragment中LoaderManager管理一个或多个Loader实例，每个Activity或Fragment只有一个LoaderManager，我们可以在Activity的onCreate()或Fragment的onActivityCreated()里初始化一个Loader。例如：
getLoaderManager().initLoader(0, null, new DataLoaderCallback());
可以看见上面的initLoader()方法有三个参数：
第一个参数代表当前Loader的ID ,用来区分哪个loader；
第二个参数代表提供给Loader构造函数的参数，Bundle对象类型 ，可选；
第三个参数代表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 实现LoaderManager.Callbacks回调
LoaderManager.LoaderCallbacks是LoaderManager的回调交互接口。LoaderManager.LoaderCallbacks包含以下三个方法：
onCreateLoader()
实例化并返回一个新创建给指定ID的Loader对象；第一启动时调用
onLoadFinished()
load完成之后回调此方法；每次都调用
onLoaderReset()
当创建好的Loader被reset时调用此方法，会清空已绑定数据，此时CreatLoader会重新执行
3 Loader使用实例
1》 初始化loader
getLoaderManager().initLoader(0, null, new DataLoaderCallback());
2》实现callback接口，注册自我监听回调
当然你也可以用来绑定谷歌提供的CursorLoader ,在Loader创建的时候被调用，这里使用一个ContentProvider获取数据，所以使用CursorLoader返回数据
3》 继承Loader，构造自我的数据绑定，和数据适配
在这里我们模拟了构造一组数据，当然你也可以在loadInBackgruond去读文件，访问网络，查询数据库
4 拓展
1》 用来自动刷新ContentPorvider
在我们使用CurSorLoader时大家都会考虑一种情况的处理—–当数据库发生变化时如何自动刷新当前UI，数据库在数据改变时通过ContentPorvider和ContentResolver发出通知，接着ContentProvider通知Cursor的观察者数据发生了变化，然后Cursor通知CursorLoader的观察者数据发生了变化，CursorLoader又通过ContentProvider加载新数据，完成后调用CursorAdapter的changeCursor()用新数据替换旧数据显示。
这个过程具体的实现步骤如下：
对获取的Cursor数据设置需要监听的URI（即，在ContentProvider的query()方法或者Loader的loadingBackground()方法中调用Cursor的setNotificationUri()方法）；
在ContentProvider的insert()、update()、delete()等方法中调用ContentResolver的notifyChange()方法；
通过上面两步我们就能实现CurSorLoader的自动数据刷新功能了；可以发现，所谓的CurSorLoader自动刷新也是对文章开头说的观察者模式，所以不再过多说明。
2》不使用ContentPorvider的自动刷新
四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的释放（譬如Cursor要要主动关闭游标的等，文件流要置空等）不需要我们人为处理，Loader会帮我们很好的处理的；同时特别注意，对于CursorLoader，当我们数据源发生变化时Loader框架会通过ContentObserver调用onContentChanged的forceLoad方法重新请求数据进行回调刷新。
五 总结
通过前面基础实例、源码分析、拓展你会发现Loader很强大，例如在普通展现某个android手机有多少应用程序，加载已安装app时候，其实loader就能排上用场。
详细见谷歌对Loader介绍：
https://developer.android.com/reference/android/content/AsyncTaskLoader.html。
PS：顺便说下AsyncTaskLoader与AsyncTask的区别，看完源码我们再回过头来总结性的说说他们二者区别，如下：
最主要是加载数据，使用loader我们无须关注数据何时改变了，也无需关注activity的生命周期，做到数据不被重复多次加载情况，activty销毁数据自动释放的作用，做到一次加载多次使用的效果，我们可以依据需求，拿着loader变活灵通，这里的博大精深还需要你自己体会。
案例：https://github.com/NeglectedByBoss/Loader
更多文章请猛戳
第一时间获取大佬技术文章和行业动态请关注微信公众号！
