当前位置: 移动技术网 > IT编程>移动开发>Android > Android启动优化之PreLoader解析

Android启动优化之PreLoader解析

2018年11月05日  | 移动技术网IT编程  | 我要评论

csbug,kb2699988,秦始皇朝攻略

android启动优化之preloader解析。

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真正绘制完成的的时机呢?

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 {
	@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 {
	@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级别的框架慎用。。

如对本文有疑问,请在下面进行留言讨论,广大热心网友会与你互动!! 点击进行留言回复

相关文章:

验证码:
移动技术网