Android启动优化

Android启动优化

上周优化了公司产品的启动速度，所以做一个简单的记录。

启动速度检测

• adb shell am start -W -n packageName/SplashActivityPath
• adb shellscreenrecord –bugreport /sdcard/lanch.mp4–bugreport: 录屏，按帧播放
• 查看已有logcat日志:ActivityManager: Displayed packageName/.StartupTiming: +768ms
• 通过hook LauncherActivity的点击事件统计
• 记录Application的attachBaseContext调用时间为初始时间，目标Activity渲染结束为终止时间

代码耗时检测

• 通过traceView可以知道方法的执行时间，所有使用traceview查找拖慢启动速度的元凶

• traceView使用方式

  • 在代码中通过Debug.startMethodTracing(fileName)和Debug.stopMethodTrace限定要检测的代码范围
    
    • 通过 adb pull /sdcard/fileName pcFilePath 将trace文件保存在pc端
    • 打开Android Device Monitor，导入trace文件，查看具体的方法执行时间
  • Android Device Monitor中手动设置检测代码范围
    
    • 选中进程，点击start method profiling, 要结束的话再次点击该按钮
  • DDMS中手动设置
    
    • ddms中选择进程，如果不可选，打开tools->Android-enable adb integrations，打开失败的话start adb
    • 点击DDMS中cpu部分的start method profiling, 要结束的话再次点击该按钮

  通用优化策略

  • 在自定义Application的onCreate方法中尽量少做操作，能在后台进行初始化的都在后台初始化，建议在onCreate方法中启动IntentService做初始化操作

  • 如果有相关的ui操作要初始化，把代码移动到第一个启动页面，在该页面渲染完后在执行初始化操作

     Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() {
        @Override
        public boolean queueIdle() {
            //执行页面渲染完后的操作
            return false;
        }
    });

  • 如果要初始化的内容在产品中使用的频率的低，则在使用前再初始化，没必要专门提前初始化
  • 如果在自定义Application中要用到广播的话，建议用LocalBroastReceiver代替EventBus
  • 如果使用了MultiDex的话，判断sdk版本并进行预加载优化
  • 在SplashActivity中设置启动时的背景图