Android 分析实现性能优化之启动速度优化

目录

• 启动方式
• 冷启动（启动优化目标）
• 热启动
• 温启动
• 启动流程中可优化的环节
• 检测工具
• 启动时间检测
• Logcat Displayed
• adb 命令统计
• CPU profile
• API level >= 26
• API level < 26
• StrictMode 严苛模式
• 优化点
• 黑白屏问题

本文主要探讨以下几个问题：

• 启动方式
• 启动流程中可优化的环节
• 检测工具
• 优化点
• 黑白屏问题

启动方式

应用有三种启动状态，每种状态都会影响应用向用户显示所需的时间：冷启动、温启动与热启动

冷启动（启动优化目标）

冷启动是指应用从头开始启动：系统进程在冷启动后才创建应用进程。发生冷启动的情况包括应用自设备启动后或系统终止应用后首次启动。

热启动

在热启动中，系统的所有工作就是将 Activity 带到前台。只要应用的所有 Activity 仍驻留在内存中，应用就不必重复执行对象初始化、布局加载和绘制。

温启动

温启动包含了在冷启动期间发生的部分操作；同时，它的开销要比热启动高。有许多潜在状态可视为温启动。例如：

• 用户在退出应用后又重新启动应用。进程可能未被销毁，继续运行，但应用需要执行 onCreate() 从头开始重新创建 Activity。
• 系统将应用从内存中释放，然后用户又重新启动它。进程和 Activity 需要重启，但传递到 onCreate() 的已保存的实例savedInstanceState对于完成此任务有一定助益。
• …

启动流程中可优化的环节

启动流程中开发者可优化的环节不多，咱们可以从APP启动流程中寻找下

APP启动过程如下：

• 点击桌面App图标，Launcher进程采用Binder IPC向system_server进程发起startActivity请求；
• system_server进程接收到请求后，向zygote进程发送创建进程的请求；
• Zygote进程fork出新的子进程，即App进程；
• App进程，通过Binder IPC向sytem_server进程发起attachApplication请求；
• system_server进程在收到请求后，进行一系列准备工作后，再通过binder IPC向App进程发送scheduleLaunchActivity请求；
• App进程的binder线程（ApplicationThread）在收到请求后，通过handler向主线程发送LAUNCH_ACTIVITY消息；
• 主线程在收到Message后，通过反射机制创建目标Activity，并回调Activity.onCreate()等方法。
• 到此，App便正式启动，开始进入Activity生命周期，执行完onCreate/onStart/onResume方法，UI渲染结束后便可以看到App的主界面。

所以，我们能优化的阶段只有 Application.onCreate() —> Activity.onWindowFocusChanged()

检测工具

启动时间检测

启动的时间怎样算是合适的？怎样一个时间范围内用户是感觉流畅的？Android Vitals在您的应用出现以下情况时将其启动时间视为过长：

• 冷启动用了 5 秒或更长时间
• 温启动用了 2 秒或更长时间
• 热启动用了 1.5 秒或更长时间

那APP启动用了多长时间？用什么区检测？

Logcat Displayed

在 Android 4.4（API 级别 19）及更高版本中，logcat 包含一个输出行，其中包含名为 Displayed 的值。此值代表从启动进程到在屏幕上完成对应 Activity 的绘制所用的时间。

adb 命令统计

adb shell am start -S -W [packageName]/[activityName]

C:\Users\****>adb shell
generic_x86_arm:/ $ am start -S -W com.miss.misslink/.MainActivity
Stopping: com.miss.misslink
Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.miss.misslink/.MainActivity }
Status: ok
LaunchState: COLD
Activity: com.miss.misslink/.MainActivity
TotalTime: 941
WaitTime: 961
Complete

WaitTime：包括前一个应用Activity pause的时间和新应用启动的时间；
ThisTime：表示一连串启动Activity的最后一个Activity的启动耗时；
TotalTime：表示新应用启动的耗时，包括新进程的启动和Activity的启动，但不包括前一个应用Activity pause的耗时。

我们一般只用 TotalTime，可以很清楚的知道APP的启动时间。那我们如何判断是哪些方法耗时太多导致APP启动时间过长呢？

CPU profile

API level >= 26

要在应用启动过程记录CPU活动，需要做以下操作

1.依次选择 Run > Edit Configurations

2.勾选 Trace Java Methods（跟踪 Java 方法：在运行时检测应用，以在每个方法调用开始和结束时记录一个时间戳。系统会收集并比较这些时间戳，以生成方法跟踪数据，包括时间信息和 CPU 使用率。）

3. 依次选择 Run > Profile，将您的应用部署到搭载 Android 8.0（API 级别 26）或更高版本的设备上

主要分析的地方有3个： Flame Chart、 Top Down 、bottom up。

API level < 26

对于API低于26的，我们可以调用 Debug API，调用起点 Application构造函数

public class MyApplication extends Application {
    
    public MyApplication() {
        //  没有指定绝对路径，就是相对路径，相对 sdcard
        Debug.startMethodTracing("miss");
    }
    
}

调用终点 Activity.onWindowFocusChanged()

    @Override
    public void onWindowFocusChanged(boolean hasFocus) {
        super.onWindowFocusChanged(hasFocus);
        Debug.stopMethodTracing();
    }

如此一来会在 sdcard 路径下生成 miss 文件，双击打开即可

StrictMode 严苛模式

StrictMode是一个开发人员工具，它可以检测出我们可能无意中做的事情，并将它们提请我们注意，以便我们能够修复它们。StrictMode最常用于捕获应用程序主线程上的意外磁盘或网络访问。帮助我们让磁盘和网络操作远离主线程，可以使应用程序更加平滑、响应更快

	//	Application onCreate 中使用
    @Override
    public void onCreate() {
        if (BuildConfig.DEBUG) {
            //线程检测策略
            StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
                    .detectDiskReads()   //读、写操作
                    .detectDiskWrites()
                    .detectNetwork()   // or .detectAll() for all detectable problems
                    .penaltyLog()
                    .penaltyDeath()
                    .build());
            StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
                    .detectLeakedSqlLiteObjects()   //Sqlite对象泄露
                    .detectLeakedClosableObjects()  //未关闭的Closable对象泄露
                    .penaltyLog()  //违规打印日志
                    .penaltyDeath() //违规崩溃
                    .build());
        }

优化点

• 合理的使用异步初始化、延迟初始化、懒加载机制。
• 启动过程避免耗时操作，如数据库 I/O操作不要放在主线程执行。
• 类加载优化：提前异步执行类加载。
• 合理使用IdleHandler进行延迟初始化。
• 简化布局
• 第三方库有些是有优化插件的，比如ARouter

黑白屏问题

当系统加载并启动 App 时，需要耗费相应的时间，这样会造成用户会感觉到当点击 App 图标时会有 “延迟” 现象，为了解决这一问题，Google 的做法是在 App 创建的过程中，先展示一个空白页面，让用户体会到点击图标之后立马就有响应。
如果你的application或activity启动的过程太慢，导致系统的BackgroundWindow没有及时被替换，就会出现启动时白屏或黑屏的情况（取决于Theme主题是Dark还是Light）。消除启动时的黑/白屏问题，大部分App都采用自己在Theme中设置背景图的方式来解决。

然后在Activity的onCreate方法，把Activity设置回原来的主题

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        setTheme(R.style.AppTheme);
        super.onCreate(savedInstanceState);
    }

这么做，只是提高启动的用户体验。并不能做到真正的加快启动速度。

总结：启动速度优化也会涉及到布局优化与卡顿优化，包括内存抖动等问题。优化是一条持续的道路，很多时候我们会发现通过各种检测手段花费了大量的精力去对代码进行修改得到的优化效果可能并不理想。因为优化就是一点一滴积累下来的，我们平时在编码的过程中就需要多注意自己的代码性能。

到此这篇关于Android 分析实现性能优化之启动速度优化的文章就介绍到这了,更多相关Android 性能优化内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！