蜂巢APP启动优化实践

性能优化任重道远，虽然道路坎坷，但我们从来没有停下脚步。

文章目录

蜂巢APP启动优化实践
前言
一、启动性能
二、优化方法步骤
- 1.查看目前启动时间
- 2.梳理耗时任务
- - Application：
  - 闪屏页Welcome：
  - 主页MainActivity：
  - 首页IndexFragment：
- 检验优化效果：
- - 第一种方法 adb 命令：
  - 第二种方法 Profile工具：
总结

前言

时间过得很快，接触蜂巢移动版项目已经一年半了，期间项目进行过很多新功能开发，比如华为云会议，即时通讯等等。随着项目阶段的不同，也逐步进行过项目架构调整和优化，主要保证App性能，并逐渐向主流App靠拢。比如进行项目基础架构重构，引入懒加载，统一、整合、优化图片加载框架和网络框架，迁移到AndroidX, 进程保活，部分业务逻辑代码结构、实现方式调整优化，资源优化等。
这一年半见证了蜂巢App快速发展，从最初的20+M急剧增长到目前的60+M，业务越来越复杂，app体积也越来越大，性能问题也随之而来。比如启动性能，今天就简单记录一下优化过程。

一、启动性能

今天只说冷启动，因为这个是最耗时的。今天所说的冷启动过程是指从用户点击app图标到进入主页完全展示出来这段时间。基础知识大家可以自行查阅，本文重点在实践过程。
提前透露一下优化成果，启动时间减少了2S左右。

二、优化方法步骤

1.查看目前启动时间

因为我们这次关注的过程是创建进程 + Application初始化+ 闪屏页Welcome初始化到界面显示的过程+主页MainActivity初始化到界面显示的过程+主页fragment显示完毕的过程，所以采用了Android Studio中 Profile 工具进行一个粗略的启动时间计算。为了方便，选取的截止时间点是ViewPager的onLayout()回调时刻。如下图，没有优化前的截图：

红框中的 00:07.170 就是这次的启动时间。好了，我们开工吧。

2.梳理耗时任务

Profile 可以清楚的看到每个过程的每个任务的CPU耗时，也就是执行耗时。不熟悉这个工具的同学可以自行查阅资料。通过分析，找到了耗时点，然后根据业务需要，确定相应的优化策略。比如哪些可以异步，哪些可以延迟，甚至哪些可以移除，哪些需要优化等。经过分析，按照启动顺序进行优化。

Application：

由于项目引入的三方库比较多，三方库各种初始化逻辑不可控，有的时候会发现Application OnCreate() 执行多次，根据重要紧急程度区分异步策略，以及删除一些无用逻辑等，最终如下：

 @Overridepublic void onCreate() {super.onCreate();if (Apputil.isMainProcess(this)) {// Debug.startMethodTracing();context = getApplicationContext();initMyAsync();initsaveinfo();initdatabase();initfontsize();initNetworkCallback();KLog.init(BuildConfig.LOG_DEBUG);getAppBackground(); // 判断前后台切换HuaweiCloudUtil.getInstance().registerHuawei(Myapplication.this);ThreadPoolUtil.execute(new Runnable() {@Overridepublic void run() {HuaweiCloudUtil.getInstance().initHuawei(Myapplication.this, BuildConfig.APPLICATION_ID);initMulti();// 初始化数据库SQLiteHelper.copyDatabaseFile(context);// 初始化定位getBdLocationHelper();// 初始化App目录initAppDir();initAppDirsecond();// 初始化图片加载 缓存initLruCache();// 监听屏幕截图// ListeningScreenshots();int launchCount = PreferenceUtils.getInt(context, Constants.APP_LAUNCH_COUNT, 0);// 记录app启动的次数PreferenceUtils.putInt(context, Constants.APP_LAUNCH_COUNT, ++launchCount);initMap();initLanguage();disableAPIDialog();disableWatchdog();//集成博睿监控，测试环境不监控if (ConsValues.URL.indexOf("https://m.95538.cn") > -1) {Bonree.withApplicationToken("8b742681-787b-421f-828e-897016fcefb1").withConfigUrl("https://monitor.95538.cn/config/").start(context);}//个推消息推送PushManager.getInstance().initialize(context, GetuiPushService.class);PushManager.getInstance().registerPushIntentService(context, GetuiIntentService.class);//非wifi情况下，主动下载x5内核QbSdk.setDownloadWithoutWifi(true);//设置开启优化方案,在调用TBS初始化、创建WebView之前进行如下配置HashMap map = new HashMap();map.put(TbsCoreSettings.TBS_SETTINGS_USE_SPEEDY_CLASSLOADER, true);map.put(TbsCoreSettings.TBS_SETTINGS_USE_DEXLOADER_SERVICE, true);QbSdk.initTbsSettings(map);//x5内核初始化接口QbSdk.initX5Environment(getApplicationContext(), null);}});INSTANCE = this;// 在7.0的设备上，开启该模式访问相机或裁剪居然不会抛出FileUriExposedException异常，记录一下// StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder().detectAll().penaltyLog().build());// StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder().detectAll().penaltyLog().build());}}

闪屏页Welcome：

闪屏页中主要任务：

网络获取闪屏页图片并展示
闪屏页展示完毕后自动登录（蜂巢自动登录以及即时通讯自动登录）

由于自动登录过程比较耗时，牵扯到多个异步接口回调以及数据读写，还是比较耗时的。之前采用的是串行方式，逻辑简单；
此次改造成了并行方式，两个接口同时发起，通过EVENTBUS 发送消息进行接口协调控制，以最短的时间完成闪屏页的使命。同时，接口中一些数据存储采用异步方式。

主页MainActivity：

MainActivity中部分任务进行了延迟初始化，部分方法进行了异步方式。主要目的是为了给ViewPager+Fragment 初始化让路。

首页IndexFragment：

这块是修改最多的地方，可以说基本重写了。同时也是最费时费力的地方，因为这块业务逻辑比较复杂。主要目的是减少过度绘制耗时，主要修改的地方如下：

布局结构优化，大大减少了布局层级和复杂度，同时减少了view的个数
header头实现方式重写
常用应用实现方式重写
消息角标数量实现方式重写
不紧急的任务进行延迟初始化，延迟缓存更新，异步方法执行等

同时采用了Android Studio自带的Inspect工具检查，可以发现一部分问题并进行整改，比如下图：

由于其他方面等限制，此次启动优化就告一段落。

检验优化效果：

第一种方法 adb 命令：

首先采用adb shell am start -S -W packagename/packagename.XXActivity 方式对比。我分别测量了启动闪屏页Welcome和主页MainActivity时间，经过多次测量取平均值。

优化前

页面	平均时间（单位ms）
闪屏页Welcome	2911
主页MainActivity	3898

优化后

页面	平均时间（单位ms）
闪屏页Welcome	2083
主页MainActivity	3171

总共优化时间=2911-2083+3898-3171 =1555ms
这个时间仅仅是个大概时间，并不准确，也只是为了介绍一个粗略方法。

第二种方法 Profile工具：

刚开始的时候我们说了，计算启动时间选取的截止时间点是ViewPager的onLayout()回调时刻。这次我们再次对优化后的版本进行计算。

红框时间是00:05.153
总共优化时间=7.170-5.153 =2.017s

注意：这里的7.170s 5.153s 并不是真实的应用启动时间，因为Profile进行调试的时候需要进行很多工作，而且这个是Debug版本，本身就会启动慢。真正的Release版本是经过字节对齐等优化的，启动时间要小于这些时间。但是两者的时间差值是准确的

总结

此次的启动优化取得了一定的成效，Release版本速度明显比之前有所改善，接近2s。随着业务增加以及app体积的不断增加，保持良好的性能是一个艰巨的任务，加油，打工人！