前言

这个性能优化系列的文章：
1、用浅显易懂的讲解方式，讲解一门技术的实用价值
2、详细书写源码的追踪，源码截图，绘制类的结构图，尽量详细地解释原理的探究过程
3、提供Github 的 可运行的Demo工程,但是我所提供代码，更多是提供思路，抛砖引玉，请酌情cv
4、集合整理原理探究过程中的少量坑，或者者demo的运行过程中的注意事项
5、用gif图，最直观地展现demo运行效果**

假如觉得细节太细，直接跳过看结论就可。
本人能力有限，如若发现形容不当之处，欢迎留言批评指正。

作者：波澜步惊
链接：https://www.songma.com/p/99eeb71f5433
学到老活到老，路漫漫其修远兮。与众君共勉 !

引子

app性能优化，是每一个高阶开发者必备技能，但是现在网络上关于性能优化的文章大多即没有成文案例，又没有知识体系详情，让需要理解此项技术的人无从下手学习。本系列文章，将先讲解案例 ，让你看到效果，再详解细节，让你知晓原理。希望对大家有帮助。

案例

app性能优化，自然是存在问题，而后才优化，那么如何去诊断出这些问题呢？自然是有手段。

Q：我们如何得知我们自己的app启动花费了多少时间？
A：adb 命令。步骤如下：

• 确保设施连接到电脑；
• 启动cmd窗口
• 输入如下命令：adb shell am start -W [app包名]/[launcherActivity的全类名]
  在android29模拟器上的结果为：
  

vivo真机，那么结果是：

这里会出现3个time：

thisTime：am start 命令可能会启动多个Activity，假如启动多个，thisTime则是指 最后一个Activity的启动时间，假如启动的是1个，那么thisTime等于TotalTime.

TotalTime：新的应用的Activity启动的耗时。

WaitTime: AMS将当前Activity从onResume转向onPause，再启动新应用Activity的总时长，包含了TotalTime在内，所以WaitTime比TotalTime要长。

当然你也可以加上-S -R 10 ，连续启动10次，而后自己计算平均启动时长。

adb shell am start -S -R 10 -W packagename/.MainActivity

这里的3个时间，我们大概可以看出自己的app启动具体花费了多少时间。通常启动时间可以通过肉眼观察得到，但是具体到确切数值，还是需要借助命令行的。那么接下来的问题，假如发现app启动耗时不理想，比方非常极端的情况，我们在Activity的onCreate中加入了少量耗时操作，

或者者你把耗时操作放到onResume中：

那么：

这里就是启动时间就会整个拖慢4000MS.

上面的这是我在模拟UI线程中执行耗时操作的极端情况。在实际的项目中，可能这些拖慢Activity启动时间的少量耗时任务都是错综复杂的，这时候应该如何解决？
所有的启动任务按照两个维度分为四类：
必要： 比方我们的launcher是WelcomeActivity，它会自动结束，而后下一个是MainActivity，假如是MainActivity所必需的少量参数需要提前获取，那么这个获取这些参数的任务就是必要任务。
耗时：按照消耗时间的长短做大致区分，不耗时，一般是微量计算，很快能执行完，不会耽误主线程太多时间。 耗时长的，一般是第三方SDK的初始化，或者者执行网络请求。

这4类分别有不同的解决方式：

• 必要且耗时
  这种，第三方SDK初始化，比方Tinker,需要在欢迎页面就知道要不要合并补丁包，这个是必需的，也是耗时的，或者者 极光推送SDK初始化。相似这种，采用异步线程去解决,此处建议直接new Thread去执行，而不是在启动Activity里面就用线程池，由于线程池的初始化也是要耗费时间的，还不如 new Thread去执行Runnable.
  异步执行的好处是，不会给UI线程带来时间上的推迟，给客户比较好的欢迎页面的体验。
• 必要不耗时
  这种，放在onCreate或者者onResume里面无妨。
• 不必要不耗时
  针对这种不必要的，但是不耗时的，我们可以容忍它在启动Activity，但是也还是放到 new Thread中去执行比较好，启动时间，能节省就节省。
• 不必要且耗时
  比方，数据上报的SDK初始化，下一个Activity并不要求你肯定要初始化完成。这个就不要放在启动Activity了。直接放在第一次数据上报的代码里去初始化就可。

另外，经验之谈：针对必要且耗时的任务，假如数量非常多，直接用一个线程去执行，但是启动页Activity同样会停留很久，这个时候，可以给所有任务区分一个轻重缓急，在重要任务执行完毕之后，就进入下一个Activity，不必等待非重要任务的结果。(根据这个思路，相信各位大佬都能写出自己的实现代码，我就不多嘴了).

最后提一下, 有些情况下启动app，会出现显著白屏，而后再出现我们写的UI布局。 这是由于 AMS在启动我们的Activity的时候，会先显示一个默认白色的window，而后再出现我们写的UI布局，假如由于我们自身app的启动耗时过长，导致白屏时间太长，体验就非常不好。这种有两种处理方案：

1、设置Activity的theme，将背景色设置为透明。

<style name="AppTheme" parent="Theme.AppCompat.Light.DarkActionBar">    <item name="android:windowIsTranslucent">true</item>    <item name="android:windowNoTitle">true</item></style>

2、将Activity的theme设置为一张图片，但是最好跟启动页的背景图一致，否则在出现启动页真正Ui的时候会比较突兀。

<style name="splash" parent="AppTheme.NoActionBar">        <item name="android:windowBackground">@drawable/bg_splash</item>        <item name="android:windowFullscreen">true</item></style>

结语

启动速度优化，是app体验优化的第一道门，将它做好了将会直接提升到我们app的客户体验。但是，真正能做的，远不止这么简单。比方: 假如启动页的UI比较复杂，在UI绘制上也是耗费少量时间导致体验不好，甚至会卡慢，但是这又是UI 美眉要求的，还不能改，咋办？ 只能自己在绘制上做少量优化了。下一盘文章详解。

视频案例教程

【关注我，个人简介有Android高级进阶群，群里有免费分享】