Android机能优化之启动加快35%

上图我们可以获得以下信息：

• 可以直寓目到MainThread的时刻轴很长，声名大大都使命都是在MainThread中执行;
• 通过Real Time/Call 降序分列可以看到措施中的部门代码确实很是耗时;
• 在下一页可以看出来部门三方SDK也较量耗时;

即即是耗时操纵，可是只要正确产生在WorkThread就没题目。因此我们必要确认这些要领执行的线程以及产生的机缘。这些操纵假如产生在主线程，也许不组成ANR的产生前提，可是卡顿是再算不免的!团结上章节图App冷启动营业事变流程图中营业操纵以及说明图，再次查察代码我们可以看到：部门耗时操纵譬喻IO读取等确实产生在主线程。究竟上在traceview里点击执行函数的名称不只可以跟踪到父类及子类的要领耗时，也可以在要领执行时刻轴中看到详细在哪个线程以及耗时的界面闪动。

说明到部门耗时操纵产生在主线程，那我们把耗时操纵都改到子线程是不是就万事大吉了?非也!!

卡顿不能都靠异步来办理，错误的行使工程线程不只不能改进卡顿，反而也许加剧卡顿。是否必要开启事变线程必要按照详细的机能瓶颈来源详细说明，有的放矢，不行一概而论;

而怎样开启线程同样也有学问：Thread、ThreadPoolExecutor、AsyncTask、HandlerThread、IntentService等都各有利弊;譬喻凡是环境下ThreadPoolExecutor比Thread越发高效、上风明明，可是特定场景下单个时刻点的示意Thread会比ThreadPoolExecutor好：同样的建设工具，ThreadPoolExecutor的开销明明比Thread大;

正确的开启线程也不能包治百病，譬喻执行收集哀求会建设线程池，而在Application中正确的建设线程池势必也会低落启动速率;因此耽误操纵也必不行少。

通过对traceview的具体跟踪以及代码的具体比对，我发明卡顿产生在：

• 部门数据库及IO的操纵产生在首屏Activity主线程;
• Application中建设了线程池;
• 首屏Activity收集哀求麋集;
• 事变线程行使未配置优先级;
• 信息未缓存，一再获取同样信息;
• 流程题目：譬喻闪屏图每次下载，当次行使;

以及其余细节题目：

• 执行无用老代码;
• 执行开拓阶段行使的代码;
• 执行一再逻辑;
• 挪用三方SDK里可能Demo里的多余代码;

项目修改：

1. 数据库及IO操纵都移到事变线程，而且配置线程优先级为THREAD_PRIORITY_BACKGROUND，这样事变线程最多能获取到10%的时刻片，优先担保主线程执行。

2. 流程梳理，延后执行;

现实上，这一步对项目启动加快最有结果。通过流程梳剃头明部门流程挪用机缘偏早、失误等，譬喻：

更新等操纵无需在首屏尚未展示就挪用，造成资源竞争;

挪用了IOS为了规避考核而做的开关，造成收集哀求麋集;

自有统计在Application的挪用里建设数目牢靠为5的线程池，造成资源竞争，在上图traceview成果声名图中最后一行可以看到编号12执行5次，耗时排名火线;此处线程池的建设是须要但可以延后的。

修改告白闪屏逻辑为下次见效。

3.其余优化;

• 去掉无用但被执行的老代码;
• 去掉开拓阶段行使但线上被执行的代码;
• 去掉一再逻辑执行代码;
• 去掉挪用三方SDK里可能Demo里的多余代码;
• 信息缓存，常用信息只在第一次获取，之后从缓存中取;
• 项目是多历程架构，只在主历程执行Application的onCreate();

通过以上三步及三方组件的优化：Application以及首屏Activity回调时代主线程就没有耗时、争抢资源等环境了。另外还涉及机关优化、内存优化等部门技能，因对付应用冷启动一样平常不是瓶颈点，这里不睁开详谈，可按照现实项目现实处理赏罚。

六、比拟结果：

通过ADB呼吁统计应用的启动时刻：adb shell am start -W 首屏Activity。

平等前提下行使MX3及Nexus6P，启动5次，较量优化前与优化后的启动时刻;

优化前：

MX3

Nexus6P

优化后：

MX3

Nexus6P

比拟：

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!