关于android:Android性能优化一之启动加速35

一、前言

随着我的项目版本的迭代，App的性能问题会逐步裸露进去，而好的用户体验与性能体现严密相干，从本篇文章开始，我将开启一个Android利用性能优化的专题，从实践到实战，从入门到深挖，手把手将性能优化实际到我的项目中，欢送继续关注！
那么第一篇文章我就从利用的启动优化开始，依据理论案例，打造闪电般的App启动速度。

二、初识启动减速

利用的启动分为冷启动、热启动、温启动，而启动最慢、挑战最大的就是冷启动：零碎和App自身都有更多的工作要从头开始！ 利用在冷启动之前，要执行三个工作：

1. 加载启动App；
2. App启动之后立刻展现出一个空白的Window；
3. 创立App的过程；

而这三个工作执行结束之后会马上执行以下工作：

1. 创立App对象；
2. 启动Main Thread；
3. 创立启动的Activity对象；
4. 加载View；
5. 安排屏幕；
6. 进行第一次绘制；

而一旦App过程实现了第一次绘制，零碎过程就会用Main Activity替换曾经展现的Background Window，此时用户就能够应用App了。

[图片上传失败…(image-df49a0-1640595066640)]

作为一般利用，App过程的创立等环节咱们是无奈被动管制的，能够优化的也就是Application、Activity创立以及回调等过程。

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

1. 利用提前展现进去的Window，疾速展现进去一个界面，给用户疾速反馈的体验；
2. 防止在启动时做密集惨重的初始化（Heavy app initialization）；
3. 定位问题：防止I/O操作、反序列化、网络操作、布局嵌套等。

备注：方向1属于治标不治本，只是外表上快；方向2、3能够实在的放慢启动速度。 接下来咱们就在我的项目中理论利用。

三、启动减速之主题切换

依照官网文档的阐明：应用Activity的windowBackground主题属性来为启动的Activity提供一个简略的drawable。 Layout XML file:

[图片上传失败…(image-e2b87e-1640595066640)]

Manifest file:

[图片上传失败…(image-967a31-1640595066640)]

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

四、启动减速之Avoid Heavy App Initialization

通过代码剖析咱们能够失去App启动的业务工作流程图：

[图片上传失败…(image-a48ae6-1640595066640)]

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

• MultiDex以及Tinker的初始化，最先执行；对于MultiDex的优化本文不再赘述，参考我之前Multidex的系列文章。
• Application中次要做了各种三方组件的初始化;

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

• 思考异步初始化三方组件，不阻塞主线程；
• 提早局部三方组件的初始化；实际上咱们粗粒度的把所有三方组件都放到异步工作里，可能会呈现WorkThread中尚未初始化结束但MainThread中曾经应用的谬误，因而这种状况倡议提早到应用前再去初始化；
• 而如何开启WorkThread同样也有考究，这个话题在下文详谈。

我的项目批改：

1. 将友盟、Bugly、听云、GrowingIO、BlockCanary等组件放在WorkThread中初始化；
2. 提早地图定位、ImageLoader、自有统计等组件的初始化：地图及自有统计提早4秒，此时利用曾经关上；而ImageLoader 因为调用关系不能异步以及过久提早，初始化从Application提早到SplashActivity；而EventBus因为再Activity中应用所以必须在Application中初始化。

留神：闪屏页的2秒停留能够利用，把耗时操作提早到这个工夫距离里。

五、启动减速之Diagnosing The Problem

本节咱们理论定位耗时的操作，在开发阶段咱们个别应用BlockCanary或者ANRWatchDog找耗时操作，简单明了，然而无奈失去每一个办法的执行工夫以及更具体的比照信息。咱们能够通过Method Tracing或者DDMS来取得更全面具体的信息。 启动利用，点击 Start Method Tracing，利用启动后再次点击，会主动关上方才操作所记录下的.trace文件，倡议应用DDMS来查看，性能更加不便全面。

[图片上传失败…(image-b61ad7-1640595066640)]

左侧为产生的具体线程，右侧为产生的时间轴，上面是产生的具体方法信息。留神两列：Real Time/Call（理论产生工夫），Calls+RecurCalls/Total（产生次数）；上图咱们能够失去以下信息：

• 能够直观看到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

比照： MX3晋升35%

Nexus6P晋升39%

• 命令含意：
  ThisTime:最初一个启动的Activity的启动耗时；
  TotalTime:本人的所有Activity的启动耗时；
  WaitTime: ActivityManagerService启动App的Activity时的总工夫（包含以后Activity的onPause()和本人Activity的启动）。

七、问题：

1、还能够持续优化的方向？

• 我的项目里应用Retrofit网络申请库，FastConverterFactory做Json解析器，TraceView中看到FastConverterFactory在创立过程中也比拟耗时，思考将其换为GsonConverterFactory。然而因为类的继承关系短时间内无奈间接替换，作为优化点临时遗留；
• 能够思考依据理论状况将启动时局部接口合并为一，缩小网络申请次数，升高频率；
• 雷同性能的组件只保留一个，例如：友盟、GrowingIO、自有统计等性能反复；
• 应用ReDex进行优化；试验Redex发现Apk体积的确是小了一点，然而启动速度没有变动，或者须要持续钻研。

2、异步、提早初始化及操作的根据？ 留神一点：并不是每一个组件的初始化以及操作都能够异步或提早；是否能够取决组件的调用关系以及本人我的项目具体业务的须要。保障一个准则：能够异步的都异步，不能够异步的尽量提早。让利用先启动，再操作。

3、通用利用启动减速套路？

• 利用主题疾速显示界面；
• 异步初始化组件；
• 梳理业务逻辑，提早初始化组件、操作；
• 正确应用线程；
• 去掉无用代码、反复逻辑等。

4、其它

• 将启动速度放慢了35%不代表之前的代码都是问题，从业务角度上将，代码并没有谬误，实现了业务需要。然而在启动时这个重视速度的阶段，疏忽的细节就会导致性能的瓶颈。
• 开发过程中，对外围模块与利用阶段如启动时，应用TraceView进行剖析，尽早发现瓶颈。

相干视频：

【2021最新版】Android studio装置教程+Android（安卓）零基础教程视频（适宜Android 0根底，Android初学入门）_哔哩哔哩_bilibili

Android高级UI性能优化——FlowLayout流式布局我的项目实战长_哔哩哔哩_bilibili

Android高级UI性能优化——View的Measure原理利用与xml解析过程原理解说_哔哩哔哩_bilibili

Android高级UI性能优化——LayoutInflater.inflate函数意义与参数阐明_哔哩哔哩_bilibili

Android高级UI性能优化——ViewPager嵌套Fragment UI 模式性能优化_哔哩哔哩_bilibili