Android启动优化之PreLoader

本文探讨了Android启动优化中的PreLoader框架,分析了其应用场景,如预加载地址、启动页数据、预加载下一页面数据和下拉刷新预加载。作者建议谨慎在Application.onCreate中做太多事,提倡在UI真正显示后再请求数据,并提醒注意网络环境和服务器状态。此外,文章提到了预加载任务的管理,包括线程池、Handler和单例设计,并建议读者自行实现类似功能以加深理解。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

学习自

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.youkuaiyun.com/qq_36523667/article/details/80028168

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

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


打包预加载

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

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


preloader的使用方法

开启预加载任务

int preLoaderId = PreLoader.preLoad(new Loader());
Intent intent = new Intent(this, PreLoadBeforeLaunchActivity.class);
intent.putExtra("preLoaderId", preLoaderId);
startActivity(intent);

//预加载任务:模拟网络接口请求获取数据
class Loader implements DataLoader<String> {
	@Override
	public String loadData() {
		//此方法在线程池中运行,无需再开子线程去加载数据
		try {
			Thread.sleep(600);
		} catch (InterruptedException ignored) {
		}
		return "data from network server";
	}
}


新的Activity中监听


PreLoader.listenData(preLoaderId, new Listener());

//数据加载完成后,会调用DataListener.onDataArrived(...)来处理加载后的数据
class Listener implements DataListener<String> {
	@Override
	public void onDataArrived(String data) {
		//此方法在主线程中运行,无需使用Handler切换线程运行
		Toast.makeText(activity, data, Toast.LENGTH_SHORT).show();
	}
}

这样的设计还是比较巧妙的。还有就是线程的切换和线程池的使用也帮助使用者减轻了一定的工作。


刷新数据,DataLoader会重新加载一遍数据,加载完成后,所有的DataListener的回调方法会被执行

PreLoader.refresh(preLoaderId);


在使用完成后可以对预加载任务进行销毁(如:在onDestroy中)

PreLoader.destroy(preLoaderId);

总体来说这个框架设计的还是较为合理的。


斗胆揣测下设计思路

维护一个加载类的单例,这不用说,因为这是全局性的功能。

内部有一个线程池。页面任何地方都可以开启一个预加载任务。

内部有一个MainLooper的Handler。

一个预加载任务的标识是唯一id。

所以内部有一个HashMap维护预加载任务。

任何地方都可以根据id拿到预加载的任务。这个任务可能是已完成的,我们拿着数据去更新UI就好了。也可能是没有完成的,在他完成以后,会回调我们的更新UI的操作接口实现。


建议

先自己试着实现一个类似的。然后与这个框架相互印证。建议不是okhttp级别的框架慎用。。。


抱歉

本人部分理念与该框架冲突,不是鸡蛋里挑骨头,本人纯属胡说八道。这个框架真心是非常优秀的框架,在这里膜拜框架开发者一波,也推荐大家去star。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值