【项目优化】App启动优化实战

前言

某次在开发阶段,发现App启动过程中既然有3-4s的白屏时间,瞬间慌了,到底干了些什么???

分析

启动时间统计

# 完整命令
adb [-d|-e|-s ] shell am start -S -W
com.example.app/.MainActivity
-c android.intent.category.LAUNCHER
-a android.intent.action.MAIN
# 常用命令
adb shell am start -W packageName/Activity类全路径(启动Activity)
# -c和-a参数是可选的,允许您为intent指定

启动时间如下(小米5s)-Debug环境:

ThisTime TotalTime WaitTime
4357 4357 4384

看到数据还是很惊讶的,立马下载了个线上版本,用上述命令统计了下启动时间 -Release环境:

ThisTime TotalTime WaitTime
1279 1279 1304

心中终于松了一口气,既然是这个版本出的问题,那就开始查原因。

ThisTime:最后一个启动的Activity的启动耗时;

TotalTime:自己的所有Activity的启动耗时(多个Activity,如果只启动一个Activity的时候TotalTime=ThisTime);

WaitTime: ActivityManagerService启动App的Activity时的总时间

如果只关心某个应用自身启动耗时,参考TotalTime;如果关心系统启动应用耗时,参考WaitTime;如果关心应用有界面Activity启动耗时,参考ThisTime

详情计算说明可参考:https://www.zhihu.com/question/35487841

官方指导

官方指导:launch-time

官方译文:应用启动时长

从指导文章中可以看出,App启动时长过长,基本就是做了很多耗时的操作,比如在Application的onCreate中做了很多初始化导致。

找问题瓶颈

我们需要知道到底哪些操作引起了耗时,我们需要去分析Application中都做了哪些耗时操作,于是找了以下一些工具:

  • Method Tracing
  • Android Profiler
  • Systrace(待研究)
  • BlockCanary
  • 自己手动统计

经过一些尝试后发现,只有Systrace和自己手动统计能满足自己需求,后面细说。

自己手动统计

没有好的方法只能用笨方法,虽然要改造原有代码,但好在灵活性较高,快速出结果:

    public static void traceMethod(String source, Action0 func) {
        if (PropertyUtils.isProduct()) {
            func.call();
        } else {
            long startTime = System.currentTimeMillis();
            func.call();
            long endTime = System.currentTimeMillis();
            LogUtils.w("Method Measure: source:[" + source + "][" + (endTime - startTime) + "]");
        }
    }

将你需要统计时长的方法,经过traceMethod进行一层包装,在log中进行参看。这个方式是否笨拙,但是有效简单。后续如有其他方式可以再替换。

时长数据

[getComponent().inject]--[278]
[RouterManager.init]--[0]
[EnvironmentController.getInstance().init(provider)]--[1]
[UIManager.init(this)]--[0]
[UtilsManager.init(this)]--[7]
[DRImageLoader.init(this)]--[242]
[initLibs]--[252]
[initViewBinding]--[61]
[initRouter]--[923] —>37
[TinkerHelper.initTinker()]--[2]
[initAppComponent()]--[0]
[initARouter()]--[1]
[initCrashHandler()]--[2]
[initLibs()]--[654]
[SDKInitializer.initialize(this)]--[60]
[initPushSdk()]--[47]
[initStatisticsTools()]--[256]
[initOnAppProcess()]--[11]

[Application onCreate]—[2405]

时长分析

超过100的都应该优化

initRouter—923ms->37ms

if (PropertyUtils.isDebugOpen()) {           // 这两行必须写在init之前,否则这些配置在init过程中将无效
    ARouter.openLog();     // 打印日志
    ARouter.openDebug();   // 开启调试模式(如果在InstantRun模式下运行,必须开启调试模式!线上版本需要关闭,否则有安全风险)
}
ARouter.init(this);

罪魁祸首就是下面两行代码,也不知道干了啥,去掉后时间降到37ms

 ARouter.openLog();     // 打印日志
 ARouter.openDebug();

initLibs()— 654ms

这个方法里面做了很多依赖库的初始化,再进行细分看下各个依赖库的init耗时

[DRCustomerNetController.getInstance().init()]--[78]
[initUBT()]--[215]
[initCustomerId()]--[0]
[initResourceConfig()]--[3]
[RongYunManager.init()]--[281]
[PlatformManager.init()]--[101]
[getRouterService.init()]--[1]

需要优化的几个地方:

  • initUBT
  • RongYunManager.init
  • PlatformManager.init

initUBT—215ms

牵扯到UBT组件,后续再优化

RongYunManager.init—281ms

移至子线程

PlatformManager.init—101ms

移至子线程

getComponent().inject—278ms

牵扯到组件实例生成,暂不处理

DRImageLoader.init--242ms

不可移至子线程,初始化移至第一次调用

必须在Application中进行调用,底层fresco的imageView在实例化的时候就会去检测

initStatisticsTools--256ms

移至子线程

优化后结果

ThisTime TotalTime WaitTime
2838 2838 2850

[getComponent().inject]--[230]
[RouterManager.init]--[0]
[EnvironmentController.getInstance().init(provider)]--[0]
[UIManager.init(this)]--[1]
[UtilsManager.init(this)]--[6]
[DRImageLoader.init(this)]--[78]
[initLibs]--[89]
[initViewBinding]--[63]
[initRouter]--[33]
[TinkerHelper.initTinker()]--[1]
[initAppComponent()]--[0]
[initCrashHandler()]--[1]
[ISPMUBTProtocol.init()]--[252]
[initUBT()]--[260]
[initCustomerId()]--[0]
[initResourceConfig()]--[6]
[initAppEnv()]--[269]
[getRouterService.init()]--[2]
[initLibs()]--[273]
[SDKInitializer.initialize(this)]--[44]
[initPushSdk()]--[42]
[initOnAppProcess()]--[12]
Method Measure:Application onCreate耗时:805
Method Measure:initOnWorkThread耗时:653

优化后发现Application的onCreate还耗时800多毫秒,主要是由于UBT、Component、Image的初始化导致,暂无较好优化方案,后续观察;

还有个很奇怪的现象就是App启动要2838,减去Application的805,还剩2000+的时间,这部分时间是谁消耗的,暂无定论,猜测是一些static和单例导致的。由于没有办法去监控,先优化到这样子。

优化方案

  • 异步初始化(比如一些非必须的组件可以放在子线程进行初始化)
  • 延迟初始化(一般的launchActivity会有几秒的启动屏,可以在里面做一些初始化操作,比如ImageLoader的init)
  • 懒加载,用到才初始化(有很多组件并不是应用启动时候就要使用,这个可以参考Dagger)

实现代码如下:


    /**
     * 在App线程进行初始化
     */
    private void initOnAppProcess() {
        TinkerHelper.initTinker();
        initRouter();
        DRCustomerNetController.getInstance().init();
        initAppComponent();
        initCrashHandler();
        initComponentService();
        //资源下发配置
        initResourceConfig();
        SDKInitializer.initialize(this);
        DRPushManager.initPushSdk();
        initGrowingio();
        registerActivityLifecycleCallbacks(new PageLifecycleCallbacks());
    }

    /**
     * 非阻塞的,在子线程进行初始化
     */
    private void initOnWorkThread() {
        new Thread() {
            @Override
            public void run() {
                long startTime = System.currentTimeMillis();
              //不与主线程争抢资源
                            android.os.Process.setThreadPriority(android.os.Process.THREAD_PRIORITY_BACKGROUND);
                //self lib
                initPlatform();
                //third lib
                RongYunManager.getInStance().init(innerInstance, AppConstans.RONG_CLOUD_APP_KEY);
                initBugly();
                long endTime = System.currentTimeMillis();
                LogUtils.d("Method Measure:initOnWorkThread耗时:" + (endTime - startTime));
            }
        }.start();
    }

后记

发现小米设备的启动要2s+之后,又用其他设备尝试了下基本在1s以内,通过systrace捕获发现小米中bindApplication就用了1.5s左右。后续有编译了个release版本重新运行了结果如下:

ThisTime TotalTime WaitTime
835 835 849

看到这个结果还是很欣慰的(提速了35%),看来release版本还是做了一些优化,小米系统坑啊!

你可能感兴趣的:(【项目优化】App启动优化实战)