Android启动优化之PreLoader

学习自

http://www.wanandroid.com/blog/show/2089

preloader框架

看起来不错（如果希望精确掌控自己项目，慎用或者研究透了preloader再用，本文分析的很粗浅），所以我冒昧地简单分析一下他的可以借鉴的地方

提供的几个应用场景（我们从中也可以得知启动优化的一些技巧）

1.Application.onCreate中预加载地址，在需要用到地址的地方拿到我们预加载的地址并使用

个人分析：个人对Application.onCreate中做太多事持保留态度。因为启动优化一个核心就是不让Applicaiton.onCreate中做太多事，为了让UI界面更早的渲染出来，以一些默认数据或者IO缓存数据进行提前的替代。所以这一点我持一个保留态度。

2.启动页中预加载app主页数据

个人分析：这一点是非常可取的。但是不是说有个splash延迟一段时间我们就可以肆无忌惮地在Application.onCreate做很多事了。事实上，启动页的延迟时间足够地短也是用户期待的！

3.startActivity之前预加载下一页面数据

个人分析：还是一样的道理，UI界面的加载依然会因此受到延迟。这不是真正的预加载。我个人理解的预加载是在点击进入下一页面之前就进行的预加载。再回到他的做法，确实他大大提前了数据加载的时机（在onCreate被回调前有大量的操作要做），以至于用户可以几乎流畅地看到他希望请求的最新数据。但是假如是弱网环境呢？假如是服务器处于高并发状态带宽受限的情况呢？所以我们如果对产品要求极度严格的话，UI中的默认数据或者IO缓存数据，是绝对不可缺少的一（然后新老数据在UI上的 切换要尽量柔和）。所以我的观点是在Activity的UI真正显示后再去进行数据的请求。怎么拿到UI真正绘制完成的的时机呢？可以看

https://blog.csdn.net/qq_36523667/article/details/80028168

4.下拉刷新和上拉加载前，我们就提前加载下一页数据

个人分析：这是一个很好的做法。

打包预加载

预加载还有一个注意点，就是打包。不打包，进行网络请求的不妥之处就不再赘述。

采用预加载技术，需要对整个app的所有请求和预加载请求都了然于心，确定哪些是可以打包的，哪些是没办法打包的。

preloader的使用方法

开启预加载任务

int preLoaderId = PreLoader.preLoad(new Loader());
Intent intent =