性能优化之启动加速35%

为普通应用，App进程的创建等环节我们是无法主动控制的，可以优化的也就是Application、Activity创建以及回调等过程。

同样，Google也给出了启动加速的方向：

• 利用提前展示出来的Window，快速展示出来一个界面，给用户快速反馈的体验;
• 避免在启动时做密集沉重的初始化(Heavy app initialization);
• 定位问题：避免I/O操作、反序列化、网络操作、布局嵌套等。

备注：方向1属于治标不治本，只是表面上快;方向2、3可以真实的加快启动速度。

接下来我们就在项目中实际应用。

三、启动加速之主题切换

按照官方文档的说明：使用Activity的windowBackground主题属性来为启动的Activity提供一个简单的drawable。

Layout XML file:


 

章节我们重点关注初始化的部分：在Application以及首屏Activity中我们主要做了：

• MultiDex以及Tinker的初始化，最先执行;
• Application中主要做了各种三方组件的初始化;

项目中除听云之外其余所有三方组件都抢占先机，在Application主线程初始化。这样的初始化方式肯定是过重的:

• 考虑异步初始化三方组件，不阻塞主线程;
• 延迟部分三方组件的初始化;实际上我们粗粒度的把所有三方组件都放到异步任务里，可能会出现WorkThread中尚未初始化完毕但MainThread中已经使用的错误，因此这种情况建议延迟到使用前再去初始化;
• 而如何开启WorkThread同样也有讲究，这个话题在下文详谈。

项目修改：

• 将友盟、Bugly、听云、GrowingIO、BlockCanary等组件放在WorkThread中初始化;
• 延迟地图定位、ImageLoader、自有统计等组件的初始化：地图及自有统计延迟4秒，此时应用已经打开;而ImageLoader
• 因为调用关系不能异步以及过久延迟，初始化从Application延迟到SplashActivity;而EventBus因为再Activity中使用所以必须在Application中初始化。

（编辑：孝感站长网）

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