享学课堂诚邀作者:周周
转载请声明出处!
前言
手把手讲解系列文章,是我写给各位看官,也是写给我自己的。 文章可能过分详细,但是这是为了帮助到尽量多的人,毕竟工作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模拟器上的结果为:
![e3a143f75af70ed21af38a1e1938047d.png](https://i-blog.csdnimg.cn/blog_migrate/639af4bd768cc2929ca85947f2fcba93.jpeg)
vivo真机,那么结果是:
![44be1364ca2a00da1b2b9c9edbcc060e.png](https://i-blog.csdnimg.cn/blog_migrate/9c4a8f25d22fcf538c6e7c762a985d85.jpeg)
这里会出现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中加入了一些耗时操作,
![ed45b90b7d10753b218a45d196a8d85f.png](https://i-blog.csdnimg.cn/blog_migrate/d81dcf7eda5e4f14c4c83907f529e047.jpeg)
或者你把耗时操作放到onResume中:
![54ee4cfec44607d7608a26efc8a0d2bf.png](https://i-blog.csdnimg.cn/blog_migrate/efaf2dff7fe7f3ae1c979b40e0fd2045.jpeg)
那么:
![39625f8c834ec0a380525228dede0419.png](https://i-blog.csdnimg.cn/blog_migrate/da11eecf0856df0890af88fdd65d0e7b.jpeg)
这里就是启动时间就会整个拖慢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启动白屏优化
最后提一下, 有些情况下启动app,会出现明显白屏,然后再出现我们写的UI布局。 这是因为 AMS在启动我们的Activity的时候,会先显示一个默认白色的window,然后再出现我们写的UI布局,如果因为我们自身app的启动耗时过长,导致白屏时间太长,体验就非常不好。这种有两种解决方案:
1、设置Activity的theme,将背景色设置为透明。
2、将Activity的theme设置为一张图片,但是最好跟启动页的背景图一致,否则在出现启动页真正Ui的时候会比较突兀。
#结语
启动速度优化,是app体验优化的第一道门,将它做好了将会直接提升到我们app的用户体验。但是,真正能做的,远不止这么简单。比如: 如果启动页的UI比较复杂,在UI绘制上也是耗费一些时间导致体验不好,甚至会卡顿,但是这又是UI 美眉要求的,还不能改,咋办? 只能自己在绘制上做一些优化了。下一盘文章详解。
你的赞和关注是我继续创作的动力~