手把手讲解 性能优化案例（1）启动速度优化

前言

手把手讲解系列文章，是我写给各位看官，也是写给我自己的。
文章可能过分详细，但是这是为了帮助到尽量多的人，毕竟工作5,6年，不能老吸血，也到了回馈开源的时候.
这个系列的文章：
1、用通俗易懂的讲解方式，讲解一门技术的实用价值
2、详细书写源码的追踪，源码截图，绘制类的结构图，尽量详细地解释原理的探索过程
3、提供Github 的 可运行的Demo工程,但是我所提供代码，更多是提供思路，抛砖引玉，请酌情cv
4、集合整理原理探索过程中的一些坑，或者demo的运行过程中的注意事项
5、用gif图，最直观地展示demo运行效果

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

学到老活到老，路漫漫其修远兮。与众君共勉 !

---

引子

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

案例

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

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

• 确保设备连接到电脑；
• 启动cmd窗口
• 输入如下命令：adb shell am start -W [app包名]/[launcherActivity的全类名]
  在android29模拟器上的结果为：
  image.png
  
  vivo真机，那么结果是：
  image.png
  
  这里会出现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，将背景色设置为透明。

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

---

结语

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