文章已获得原作者诚迈科技资深研发工程师-朱立民授权
承接上文
三、耗时分析
通过上述方式修改完代码后，抓取到如下log片段：
分析该log片段时间戳可得出各阶段大概耗时情况，即
1、launcher处理阶段耗时约270ms
2、music应用本身数据加载耗时约300ms
3、根据测试同学提供的启动耗时1122ms减去前两项，得到应用数据渲染时间约550ms。
根据移动开发经验可得知渲染时间显然过长了，于是先分析这部分耗时问题出在哪里。
●和框架同学沟通渲染相关的逻辑没有修改，另外在原始系统版本验证同样耗时约550ms
●既然研发同学没有修改，那问题可能就出在了测试流程中。仔细分析验证视频，发现music应用的背景图片显示有个渐变的过程，而测试启动耗时截止时间是等背景页面全部渲染完毕，所以初步判断问题就出在这里了。
为了验证上述判断，把背景图片换成纯色背景后录制视频截图如下，果然没有了背景图片渐变效果。至此，找到了应用数据渲染时间显得过长的原因。同时也推断出手机在录制视频的时候，遇到偏黑色背景会自动调整亮度。
四、解决方案
测试流程优化
针对录制视频导致深色背景图片显示渐变效果的问题，通过将终点帧数改为"本地音乐"文案显示这一阵，经测量后music应用冷启动时间从1122.2ms缩减到911.4ms
应用优化
在解决冷启动时间不达标问题的过程中，大概总结了如下这些优化方案。对比自己的应用哪些地方可以优化就修改，本文提到的music应用启动时间经过这一步优化后，冷启动时间进一步缩减到835.6ms。
1、布局优化，减少嵌套、重叠；
2、布局优化，不需要首次（冷启动）加载的布局，可以用state来控制，通过if条件来修改；
3、线程加载无必要任务；（用TaskPool或者Worker）
4、延时加载，使用List、Grid以及Swiper等控件时，配合LazyForEach数据懒加载；
5、去掉大的背景图加载，替换为纯色背景；
6、使用image的地方，如果能用text替换的就替换；
7、拥有分布式能力的App，单独做一个按钮来“启动加载”分布式功能；或是暂时去掉分布式功能；
8、删除icon.png、startIcon.png，如果影响视觉，可以修改app_icon.png质量，并修改代码
“icon”: “$media:app_icon”,
“label”: “$string:EntryAbility_label”,
“startWindowIcon”: “$media:app_icon”,
app_icon大小尽量为114*114，最好不要超过256*256；
9、去掉无必要的资源、图片、冗余代码等，以下几种扫描方法可供参考；
●在devecodeveco studio终端中执行deveco clean-resources --unused
●在devecodeveco studio中执行Code ->Code CleanUp
●在deveco studio中执行Alt+Shift+H,扫描代码
10、去掉无效的import；
在deveco studio中执行Code ->Optimizes imports(Ctrl+Alt+O)
11、尽量使用svg，不使用png、jpg；
12、如果需要使用大图，尽量用jpg，不用png；
框架层优化
目前只调研了一些可参考的框架层优化方案，由于没有实际落地，后续再补充。
五、参考链接
OpenHarmony 4.0 Release官方文档：