这些天跟聊了下启动页优化问题,这是一个老生常谈的问题了。
1、App启动方式:
a、冷启动;应用被杀死,后台没有对应的进程的启动
b、热启动;后台有应用进程的启动
我们需要启动页优化,主要也是针对冷启动时候优化。
在冷启动过程中我们应用是这样子执行的:
由以上图我们可以知道,如果我们要优化启动速度点话,重点要把主线程在Application、启动Acitivity上的耗时减少以此达到优化目的。
2、启动时白屏和黑屏
设置启动Activity的theme的style包含windowBackground,他将会在启动Activity在onCreate的时候加载,并且给Window设置背景图
代码设置如下:
但是往往我们这样子设置后,就是背景图展示特别长,换言之我们只是解决白屏和黑屏的问题,但是本质没有解决启动耗时长的问题,不过这种以空间换时间做法也不失为一种解决方案,至少让用户启动的时候可以看到一个界面。
3、启动耗时分析:
a、SDK初始化耗时,此处我们要对每个sdk初始化处进行时间计量,看他耗时为多少,另外一个app往往集成了多个SDK,切勿以量小而不为,例如一个sdk平均耗时100ms,如果集成了10个sdk的,就是1s的时间,这就时间还是挺大的。
b、业务冗杂;这里主要要说明的是冷启动后,各种各样的弹窗,各种弹窗齐刷刷的带来的绘制卡顿是非常明显的,所以此时最好对这种业务进行优先级排序。
c、网络确定;例如开机广告,冷启动app的时候,我们还要去请求网络看看是否有广告素材,由这个结果来决定app的下一步,这是非常慢的,更夸张的时候有些广告是视频广告,导致用户冷启动一次app至少花费10s的时间;当然除了开机广告,结合业务需要我们有各种各样的网络确定的过程;我们可以这一次获取下一次需要网络确认的数据,以此达到下一次冷启动应用的时候就不需要等待网络确定而直接进入下一步
4、总结
对阻碍启动优化的业务(SDK)进行优先级排序,对于那些不重要的业务(SDK)参与延迟处理,例如我们可以合理利用Looper中的Idle机制,把一些不重要的事情放入Idle处理;
我们要梳理启动过程中主线程所操作的事情,并且对sdk初始化进行时间打点,对业务优先级进行排序,合理善用本地文件、内存缓存避免多次网络确认;不提前初始化或者请求暂时使用不到的业务;能够不在主线程处理的业务在子线程处理,给主线程腾出更多的时间和空间。