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

对比：

（编辑：威海站长网）

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