Android性能优化之启动加速35%

命令含义：

• ThisTime:最后一个启动的Activity的启动耗时;
• TotalTime:自己的所有Activity的启动耗时;
• WaitTime: ActivityManagerService启动App的Activity时的总时间(包括当前Activity的onPause()和自己Activity的启动)。

七、问题：

1、还可以继续优化的方向?

• 项目里使用Retrofit网络请求库，FastConverterFactory做Json解析器，TraceView中看到FastConverterFactory在创建过程中也比较耗时，考虑将其换为GsonConverterFactory。但是因为类的继承关系短时间内无法直接替换，作为优化点暂时遗留;
• 可以考虑根据实际情况将启动时部分接口合并为一，减少网络请求次数，降低频率;
• 相同功能的组件只保留一个，例如：友盟、GrowingIO、自有统计等功能重复;
• 使用ReDex进行优化;实验Redex发现Apk体积确实是小了一点，但是启动速度没有变化，或许需要继续研究。

2、异步、延迟初始化及操作的依据?

注意一点：并不是每一个组件的初始化以及操作都可以异步或延迟;是否可以取决组件的调用关系以及自己项目具体业务的需要。保证一个准则：可以异步的都异步，不可以异步的尽量延迟。让应用先启动，再操作。

3、通用应用启动加速套路?

• 利用主题快速显示界面;
• 异步初始化组件;
• 梳理业务逻辑，延迟初始化组件、操作;
• 正确使用线程;
• 去掉无用代码、重复逻辑等。

4、其它

• 将启动速度加快了35%不代表之前的代码都是问题，从业务角度上将，代码并没有错误，实现了业务需求。但是在启动时这个注重速度的阶段，忽略的细节就会导致性能的瓶颈。
• 开发过程中，对核心模块与应用阶段如启动时，使用TraceView进行分析，尽早发现瓶颈。

（编辑：威海站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!