Android性能优化之启动加速35%

一、前言

随着项目版本的迭代，App的性能问题会逐渐暴露出来，而好的用户体验与性能表现紧密相关，从本篇文章开始，我将开启一个Android应用性能优化的专题，从理论到实战，从入门到深挖，手把手将性能优化实践到项目中，欢迎持续关注!

那么第一篇文章我就从应用的启动优化开始，根据实际案例，打造闪电般的App启动速度。

二、初识启动加速

来看一下Google官方文档《Launch-Time Performance》(https://ldeveloper.android.com/topic/performance/launch-time.html)对应用启动优化的概述;

应用的启动分为冷启动、热启动、温启动，而启动最慢、挑战最大的就是冷启动：系统和App本身都有更多的工作要从头开始!

应用在冷启动之前，要执行三个任务：

• 加载启动App;
• App启动之后立即展示出一个空白的Window;
• 创建App的进程;

而这三个任务执行完毕之后会马上执行以下任务：

• 创建App对象;
• 启动Main Thread;
• 创建启动的Activity对象;
• 加载View;
• 布置屏幕;
• 进行第一次绘制;

而一旦App进程完成了第一次绘制，系统进程就会用Main Activity替换已经展示的Background Window，此时用户就可以使用App了。

作为普通应用，App进程的创建等环节我们是无法主动控制的，可以优化的也就是Application、Activity创建以及回调等过程。

同样，Google也给出了启动加速的方向：

• 利用提前展示出来的Window，快速展示出来一个界面，给用户快速反馈的体验;
• 避免在启动时做密集沉重的初始化(Heavy app initialization);
• 定位问题：避免I/O操作、反序列化、网络操作、布局嵌套等。

备注：方向1属于治标不治本，只是表面上快;方向2、3可以真实的加快启动速度。

接下来我们就在项目中实际应用。

三、启动加速之主题切换

按照官方文档的说明：使用Activity的windowBackground主题属性来为启动的Activity提供一个简单的drawable。

Layout XML file:

Manifest file:

这样在启动的时候，会先展示一个界面，这个界面就是Manifest中设置的Style，等Activity加载完毕后，再去加载Activity的界面，而在Activity的界面中，我们将主题重新设置为正常的主题，从而产生一种快的感觉。不过如上文总结这种方式其实并没有真正的加速启动过程，而是通过交互体验来优化了展示的效果。

备注：截图同样来自官方文档《Launch-Time Performance》。

四、启动加速之Avoid Heavy App Initialization

通过代码分析我们可以得到App启动的业务工作流程图：

这一章节我们重点关注初始化的部分：在Application以及首屏Activity中我们主要做了：

• MultiDex以及Tinker的初始化，最先执行;
• Application中主要做了各种三方组件的初始化;

项目中除听云之外其余所有三方组件都抢占先机，在Application主线程初始化。这样的初始化方式肯定是过重的:

• 考虑异步初始化三方组件，不阻塞主线程;
• 延迟部分三方组件的初始化;实际上我们粗粒度的把所有三方组件都放到异步任务里，可能会出现WorkThread中尚未初始化完毕但MainThread中已经使用的错误，因此这种情况建议延迟到使用前再去初始化;
• 而如何开启WorkThread同样也有讲究，这个话题在下文详谈。

项目修改：

• 将友盟、Bugly、听云、GrowingIO、BlockCanary等组件放在WorkThread中初始化;
• 延迟地图定位、ImageLoader、自有统计等组件的初始化：地图及自有统计延迟4秒，此时应用已经打开;而ImageLoader
• 因为调用关系不能异步以及过久延迟，初始化从Application延迟到SplashActivity;而EventBus因为再Activity中使用所以必须在Application中初始化。

注意：闪屏页的2秒停留可以利用，把耗时操作延迟到这个时间间隔里。

五、启动加速之Diagnosing The Problem

本节我们实际定位耗时的操作，在开发阶段我们一般使用BlockCanary或者ANRWatchDog找耗时操作，简单明了，但是无法得到每一个方法的执行时间以及更详细的对比信息。我们可以通过Method Tracing或者DDMS来获得更全面详细的信息。

启动应用，点击 Start Method Tracing，应用启动后再次点击，会自动打开刚才操作所记录下的.trace文件，建议使用DDMS来查看，功能更加方便全面。

左侧为发生的具体线程，右侧为发生的时间轴，下面是发生的具体方法信息。注意两列：Real Time/Call(实际发生时间)，Calls+RecurCalls/Total(发生次数);

（编辑：衡阳站长网）

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