APP启动优化分析的一些总结
启动性能问题导致的表现结果可能会类似,但是引起问题产生的根源可能不一样,性能问题一旦发生,需要及时找到问题所在,传统的调试方式耗时而繁琐,因此,开发人员可以借助性能分析工具(比如:友盟u-apm)来帮助定位问题代码位置,之后根据自己本身的项目特点去制定相应的优化策略。本文简单介绍启动性能检测工具以及一些启动优化的建议。
启动分析
这里推荐使用友盟+u-apm的启动分析功能,它的优势在于全周期监控启动性能表现。
启动耗时趋势:监控各版本应用的首次启动、热启动、冷启动耗时情况,整体评估应用的启动耗时是否符合预期;
启动性能拆解:通过U-APM预置或手动埋点的方式定义启动阶段拆解规则,监控各步骤的耗时分析;
慢启动设备分析:采集全量设备的启动情况,自定义慢启动阈值,跟踪慢启动设备详情。
启动崩溃:采集首次启动、热启动、冷启动、慢启动下的应用崩溃信息,观测用户在启动阶段的体验情况。
App 启动优化
启动窗口优化
启动自己的窗口需要的时间要比直接显示系统的启动窗口所花的时间要长,这就会导致用户在使用的时候,点击图标启动 App时有一定的延迟,表现在点击图标过了一段时间才进行窗口动画进入 App,我们要尽量避免这种情况
1、不要禁止系统默认的启动窗口:即不要在主题里面设置 android:windowDisablePreview 为 true
2、自己定制启动窗口的内容,比如将启动页主题背景设置成闪屏页图片,或者尽量使闪屏页面的主题和主页一致。
3、合并闪屏和主页面的 Activity
线程优化
线程优化主要是减少 CPU 调度带来的波动,让启动时间更稳定。如果启动过程中有太多的线程一起启动,会给 CPU 带来非常大的压力,尤其是比较低端的机器。过多的线程同时跑会让主线程的 Sleep 和 Runnable 状态变多, 增加了应用的启动速度,优化的过程中要注意:
1、控制线程数量 – 线程池
2、检查线程间的锁 ,防止依赖等待
3、使用合理的启动架构
系统调度优化
应用启动的时候,如果主线程的工作过多,也会造成主线程过于繁忙,下面几个系统调度相关的点需要注意:
1、启动过程中减少系统调用,避免与 AMS、WMS 竞争锁。启动过程中本身 AMS 和 WMS 的工作就很多,且 AMS 和 WMS 很多操作都是带锁的,如果此时 App 再有过多的 Binder 调用与 AMS、WMS 通信,SystemServer 就会出现大量的锁等待,阻塞关键操作
2、启动过程中不要启动子进程,如果好几个进程同时启动,系统负担则会加倍,SystemServer 也会更繁忙
3、启动过程中除了 Activity 之外的组件启动要谨慎,因为四大组件的启动都是在主线程的,如果组件启动慢,占用了 Message 通道,也会影响应用的启动速度
GC 优化
启动过程中减少 GC 的次数
1、避免进行大量的字符串操作,特别是序列化和反序列化
2、频繁创建的对象需要考虑复用
3、转移到 Native 实现
类重排
类重排的实现通过 ReDex 的 Interdex 调整类在 Dex 中的排列顺序。Interdex 优化不需要去分析类引用,它只需要调整 Dex 中类的顺序,把启动时需要加载的类按顺序放到主 dex 里,这个工作我们完全可以在编译过程中实现,而且这个优化可以提升启动速度,优化效果从 facebook 公布的数据来看也比较可观,性价比高。
主页面布局优化
应用主界面布局优化是老生常谈了,综合起来无非就是下面两点,这个需要结合具体的界面布局去做优化,网上也有比较多的资料可以查阅
1、通过减少冗余或者嵌套布局来降低视图层次结构
2、用 ViewStub 替代在启动过程中不需要显示的 UI 控件
3、使用自定义 View 替代复杂的 View 叠加
闲时调用
IdleHandler:当 Handler 空闲的时候才会被调用,如果返回 true, 则会一直执行,如果返回 false,执行完一次后就会被移除消息队列。比如,我们可以将从服务器获取推送 Token 的任务放在延迟 IdleHandler 中执行,或者把一些不重要的 View 的加载放到 IdleHandler 中执行
类加载优化
可以在 systrace 生成的文件中看到 verifyClass 过程,因为需要校验方法的每一个指令,所以是一个比较耗时的操作。
以上就是关于app启动优化的总结。总的来说,在性能优化中首先要找出问题根源,其次才是优化方案,如果盲目的进行优化只能是治标不治本,大家不妨使用友盟+u-apm分析问题根源的所在,进而进行彻底的优化。
上一篇: 煤炭价格指数,及对应网站汇总
下一篇: 战略论