Android 勇闯高阶性能优化之启动优化篇

???? 背景

用户不会在乎你的项目是不是过大，里面是不是有很多初始化的逻辑。他只在乎你-慢了。

所以咱们这篇文章有两个目的：

启动速度提升(用户眼中的大神就是你)

优化代码逻辑和规范(别让自己成为继任者中的xx)

今天咱们就来了解一下应用启动内部机制和启动速度优化。

???? 启动内部机制

应用有三种启动状态：

• 冷启动；
• 温启动；
• 热启动。

???? 冷启动

冷启动是指应用从头开始：冷启动发生在设备启动后第一次启动应用程序 (zygote>fork>app) ，或系统关闭应用程序后。

在冷启动开始时，系统有三个任务。 这些任务是：

• 加载和启动应用程序。
• 启动后立即显示应用程序的空白启动页面。
• 创建应用程序进程。

一旦系统创建了应用程序进程，应用程序进程就负责接下来的阶段：

• 创建应用的实体。
• 启动主线程。
• 创建主页面。
• 绘制页面上的view。
• 布局页面。
• 执行首次的绘制。

如下图：

• displayed time：初始显示时间
• reportfullydrawn()：完全显示的时间

注意：在创建 application 和创建 activity 期间可能会出现性能问题。

???? 创建 application

当应用程序启动时，空白启动页面保留在屏幕上，直到系统首次完成应用程序的绘制。

如果你重写了application.oncreate()，系统将调用application 上的oncreate()方法。之后，应用程序生成主线程，也称为ui线程，并将创建主activity的任务交给它。

???? 创建activity

应用进程创建你的activity后，activity会执行以下操作：

• 初始化值。
• 调用构造函数。
• 调用 activity 当前生命周期状态的回调方法，如 activity.oncreate()。

注意：oncreate() 方法对加载时间的影响最大，因为它执行开销最高的工作：加载ui的布局和渲染，以及初始化activity运行所需的对象。

???? 热启动

热启动时，系统将应用从后台拉回前台，应用程序的 activity 在内存中没有被销毁，那么应用程序可以避免重复对象初始化，ui的布局和渲染。

如果 activity 被销毁则需要重新创建。

和冷启动的区别： 不需要创建 application。

???? 温启动

温启动介于冷启动和热启动中间吧。例如：

用户按返回键退出应用，然后重新启动。进程可能还没有被杀死，但应用必须通过调用oncreate（）重新创建 activity。

系统回收了应用的内存，然后用户重新运行应用。应用进程和activity都需要重新启动。

咱们看看他们共同消耗多长时间。

???? 查询的启动时间

???? 初始显示时间(time to initial display)

在 android 4.4（api 级别 19）及更高版本中，logcat 包含一个输出行，其中包含一个名为 displayed 的值。 此值表示启动流程和完成在屏幕上绘制相应活动之间经过的时间量。 经过的时间包含以下事件序列：

• 启动进程。
• 初始化对象。
• 创建并初始化activity。
• 加载布局。
• 第一次绘制你的应用程序。

注意这里查看日志需要如下操作：

报告的日志行类，如下图：

//冷启动
i/activitytaskmanager: displayed com.scc.demo/.actvitiy.mainactivity: +1s355ms
//温启动(进程被杀死)
i/activitytaskmanager: displayed com.scc.demo/.actvitiy.mainactivity: +1s46ms
//热启动
i/activitytaskmanager: displayed com.scc.demo/.actvitiy.mainactivity: +289ms
i/activitytaskmanager: displayed com.scc.demo/.actvitiy.mainactivity: +253ms

图例讲解：

第一个时间，冷启动时间：+1s355ms；

然后我们在后台杀死进程，再次启动应用；

第二个时间，温启动时间：+1s46ms；

这里咱们在后台杀死进程所以：应用进程和activity需要重新启动。

第三个时间：热启动时间：+289ms 和 +253ms；

按返回键，仅退出activity。所以耗时比较短。

当然整体看这个应用开启时间并不长，因为 demo 的 application 和 activity 都没有进行太多的操作。

???? 完全显示时间(time to full display)

你可以使用 reportfullydrawn() 方法来测量应用程序启动和所有资源和视图层次结构的完整显示之间经过的时间。在应用程序执行延迟加载的情况下，这可能很有价值。在延迟加载中，应用程序不会阻止窗口的初始绘制，而是异步加载资源并更新视图层次结构。

这里我在activity.oncreate()中加了个工作线程。并在里面调用reportfullydrawn() 方法。代码如下：

@override
public void oncreate(@nullable bundle savedinstancestate) {
    super.oncreate(savedinstancestate);
    log.e(this.getclass().getname(), "oncreate");
    setcontentview(r.layout.activity_main);
    ...
    new thread(new runnable() {
        @override
        public void run() {
            try {
                thread.sleep(3000);
                reportfullydrawn();
            } catch (interruptedexception e) {
                e.printstacktrace();
            }
        }
    }).start();
}

报告的日志行类，如下图：

i/activitytaskmanager: fully drawn com.scc.demo/.actvitiy.mainactivity: +3s970ms
i/activitytaskmanager: fully drawn com.scc.demo/.actvitiy.mainactivity: +3s836ms
i/activitytaskmanager: fully drawn com.scc.demo/.actvitiy.mainactivity: +3s107ms
i/activitytaskmanager: fully drawn com.scc.demo/.actvitiy.mainactivity: +3s149ms

图例讲解：

然后你会发现界面出来好一会才打这个日志。看到这里我觉得好多人已经知道怎么去优化启动速度了。

???? 性能迟缓分析

看到上面的实验其实三种启动情况，受我们影响的方面在于 application 和 activity 。

???? application 初始化

当你的代码覆盖 application 对象并在初始化该对象时执行繁重的工作或复杂的逻辑时，启动性能可能会受到影响。 产生的原因包括：

• 应用程序的初始oncreate（）函数。如：执行了不需要立即执行的初始化。
• 应用程序初始化的任何全局单例对象。如：一些不必要的对象。
• 可能发生的任何磁盘i/o、反序列化或紧密循环。

解决方案

无论问题在于不必要的初始化还是磁盘i/o，解决方案都是延迟初始化。换句话说，你应该只初始化立即需要的对象。不要创建全局静态对象，而是转向单例模式，应用程序只在第一次需要时初始化对象。

此外，考虑使用依赖注入框架（如hilt）

???? activity初始化

活动创建通常需要大量高开销工作。 通常，有机会优化这项工作以实现性能改进。

产生的原因包括：

• 加载大型或复杂的布局。
• 阻止在磁盘或网络 i/o 上绘制屏幕。
• 加载和解码bitmap。
• vectordrawable 对象。
• activity 初始化任何全局单例对象。
• 所有资源初始化。

解决方案如下。

???? 布局优化

• 通过减少冗余或嵌套布局来扁平化视图层次结构。
• 布局复用(< include/>和 < merge/> )
• 使用viewstub，不加载在启动期间不需要可见的 ui 部分。

???? 代码优化

• 不必要的初始化还是磁盘i/o，延迟初始化
• 资源初始化分类，以便应用程序可以在不同的线程上延迟执行。
• 动态加载资源和bitmap

关于这两块的优化后续会有单独的文章去写。

???? 阻塞实验

???? application 阻塞 2秒， activity 阻塞 2秒

???? sccapp.class

public class sccapp extends application {
    @requiresapi(api = build.version_codes.p)
    @override
    public void oncreate() {
        super.oncreate();
        string name = getprocessname();
        mlog.e("processname:"+name);
        getprocessname("com.scc.demo");
        try {
            thread.sleep(2000);
        } catch (interruptedexception e) {
            e.printstacktrace();
        }
    }
}

???? mainactivity.class

public  class mainactivity extends activitybase implements view.onclicklistener {
    @override
    public void oncreate(@nullable bundle savedinstancestate) {
        super.oncreate(savedinstancestate);
        log.e(this.getclass().getname(), "oncreate");
        setcontentview(r.layout.activity_main);
        ...
        try {
            thread.sleep(2000);
        } catch (interruptedexception e) {
            e.printstacktrace();
        }
        new thread(new runnable() {
            @override
            public void run() {
                try {
                    thread.sleep(3000);
                    reportfullydrawn();
                } catch (interruptedexception e) {
                    e.printstacktrace();
                }
            }
        }).start();
    }
}

报告的日志，如下：

//冷启动
i/activitytaskmanager: displayed com.scc.demo/.actvitiy.mainactivity: +5s458ms
i/activitytaskmanager: fully drawn com.scc.demo/.actvitiy.mainactivity: +8s121ms
//温启动(进程被杀死)
i/activitytaskmanager: displayed com.scc.demo/.actvitiy.mainactivity: +5s227ms
i/activitytaskmanager: fully drawn com.scc.demo/.actvitiy.mainactivity: +7s935ms
//热启动
i/activitytaskmanager: displayed com.scc.demo/.actvitiy.mainactivity: +2s304ms
i/activitytaskmanager: fully drawn com.scc.demo/.actvitiy.mainactivity: +5s189ms
i/activitytaskmanager: displayed com.scc.demo/.actvitiy.mainactivity: +2s322ms
i/activitytaskmanager: fully drawn com.scc.demo/.actvitiy.mainactivity: +5s169ms

???? 将appliacation 和activity阻塞的2秒都放在工作线程去操作

这个就是把代码放在如下代码中执行即可，就不全部贴出来了。

        new thread(new runnable() {
            @override
            public void run() {
                ...
            }
        }).start();

运行结果如下：

//冷启动
i/activitytaskmanager: displayed com.scc.demo/.actvitiy.mainactivity: +1s227ms
i/activitytaskmanager: fully drawn com.scc.demo/.actvitiy.mainactivity: +3s957ms
//温启动(进程被杀死)
i/activitytaskmanager: displayed com.scc.demo/.actvitiy.mainactivity: +1s83ms
i/activitytaskmanager: fully drawn com.scc.demo/.actvitiy.mainactivity: +3s828ms
//热启动
i/activitytaskmanager: displayed com.scc.demo/.actvitiy.mainactivity: +324ms
i/activitytaskmanager: fully drawn com.scc.demo/.actvitiy.mainactivity: +3s169ms
i/activitytaskmanager: displayed com.scc.demo/.actvitiy.mainactivity: +358ms
i/activitytaskmanager: fully drawn com.scc.demo/.actvitiy.mainactivity: +3s207ms

???? app 启动黑/白屏

android 应用启动时，尤其是大型应用, 经常出现几秒钟的黑屏或白屏，黑屏或白屏取决于主界面 activity 的主题风格。

???? 优雅的解决黑白屛

android 应用启动时很多大型应用都会有一个广告(图片及视频)页或闪屏页(2-3s)。这并不是开发者想要放上去的，而是为了避免上述启动白屏导致用户体很差。当然你可以珍惜这2-3秒做一个异步加载或者请求。

写到这里。应用启动模式、启动时间、启动速度优化算是完事了。当然后面如果有更好的优化方案还会继续补充。

到此这篇关于android 勇闯高阶性能优化之启动优化篇的文章就介绍到这了,更多相关android 启动优化内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！