浅谈App的启动优化

671次阅读  |  发布于1年以前

1 . 应用启动的方式

在Android中，应用启动一般可分为三种：冷启动、温启动、热启动。

那么什么是冷启动、温启动和热启动呢？下面我们来简单看一下它们的定义：

由于冷启动相对于其他启动方式多了进程的创建（Zygote进程fork创建进程）以及应用的资源加载和初始化（Application的创建及初始化），所以相对来说会比较耗时，所以我们一般说的App启动优化一般指的都是App的冷启动优化。

2 . 优化方案

App启动优化的本质就是：启动速度和体验的优化。

这就好比早些年你去饭店吃饭，你想要点餐但等了半天都没有服务人员过来，可能就等得不耐烦直接走开了。同样的，对于APP来说，如果用户点击App后长时间都打不开，用户就很可能失去耐心而卸载应用。

所以启动速度是用户对我们App的第一体验。如果启动速度过慢，用户第一印象就会很差，这样即使你功能做出花来，用户也不会愿意去使用。

其实要想优化App的启动体验，关键就是要让用户更快地获取到应用的内容（流畅，不卡顿、不等待），那么我们应该怎么做呢？

2.1 案例分析

这里我们还是先以之前说的去饭店吃饭为例来展开讨论。现在的饭店竞争是尤为的激烈，为了能够提高顾客的体验、留住顾客，真的是使出了浑身解数，除了口味之外，服务品质也是被摆在了越来越重要的位置。

就比方说：

以上的改进措施，都是这些年餐饮行业在竞争下，不断提高服务质量的产物。可以说谁的服务质量落下了，谁就有可能被淘汰。

其实我们仔细分析一下上面所列举的，不难看出有很多是可以让我们借鉴的。

（1）案例1

分析：饭店提供了点餐的二维码，本质上是将一件被动等待转变为主动请求的一种过程，客观上减少了等待的时间，从而提高了速度。

类比：这对应我们的应用程序，就像原先一些耗时不必要的三方库需要被动等待其初始化完毕程序才会继续进行，转变为先不初始化这部分耗时的三方库，等真正用到时再进行初始化；又类似我们应用程序的游客模式，无需被迫进行一堆复杂的用户注册过程，就可以直接进入程序使用，待涉及一些用户信息功能的时候再提示用户注册。

（2）案例2

分析：热门餐馆同时提供排队取号和提前点餐服务，本质上是将原先无法同时进行的操作（需要先排上队等到座位，才能扫描座位号点餐）变成了可同时进行的操作，将串行任务转化为并行任务，从而节省了时间。

类比：这对应我们的应用程序，就是将一些原本在主线程串行执行的耗时资源/数据加载，改为在子线程中并发执行。这在几个耗时任务耗时差距不大的时候优化尤为明显。

（3）案例3

分析：在顾客排队等待的时候，提供零食、茶水、棋牌以及美甲等服务，本质上就是让顾客提前享受本餐馆的服务，从而缓解顾客等待的焦虑。

类比：这对应我们的应用程序，就是开屏启动页。在Android12上，Google强制增加了这个开屏页，就是为了让用户提前看到你的应用页面，让用户产生应用启动很流畅的假象，从而提高用户的启动体验。

（4）案例4

分析：设置倒计时免单服务，本质上就是给等待加上了进度条上限以及超时赔偿。俗话说最让人害怕的是等待，比等待更让人害怕的是看不见尽头的等待。而为等待设置上限，可以极大地缓解顾客等待的焦虑，毕竟等待超时了也是会有补偿的。

类比：这对应我们的应用程序，就是一些应用（比如游戏）初次启动会非常耗时，所以它们通常会在启动页增加一个初始化/加载进度条页面，来告诉用户啥时候能加载完，而不是无止境未知的等待。

通过分析，我们可以看到（1）、（2）两种操作是从技术的角度来实现的优化，而（3）、（4）两种操作则更多的是从业务的角度去实现的优化。

2.2 优化策略

从上面的案例分析，我们可以得出，应用启动优化，我们可以分别从技术和业务的角度来进行决策。

2.2.1 技术优化

（1）针对启动流程任务进行梳理。

（2）非必要不执行。

（3）数据结构优化，减小初始化时间。

2.2.2 业务优化

（1）业务流程整合。

（2）业务流程拆分调整。

2.3 优化方向

在优化之前，让我们先来分析一下冷启动的过程：

Zygote创建应用进程 -> AMS请求ApplicationThread -> Application创建 -> attachBaseContext > onCreate -> ActivityThread启动Activity -> Activity生命周期(创建、布局加载、屏幕布置、首帧绘制)

以上过程，只有Application和Activity的生命周期这两个阶段对我们来说是可控的，所以这就是我们的优化方向。

3 . 优化措施

3.1 启动流程优化

1.依据之前我们列举的技术优化策略，首先需要对启动的所有任务流程进行梳理，然后对其执行方式进行优化。

2.第三方SDK初始化优化。

3.使用任务执行框架。

这里我们还可以使用一些第三方的任务启动框架，对启动流程进行优化。下面我就拿我开源的XTask 简单介绍一下：

这里我们模拟了三种类型的任务：

优化前

/**
 * 优化前的写法, 这里仅是演示模拟，实际的可能更复杂
 */
private void doJobBeforeImprove(long startTime) {
    new TopPriorityJob(logger).doJob();
    for (int i = 0; i < 4; i++) {
        new SingleJob((i + 1), logger).doJob();
    }
    new LongTimeJob(logger).doJob();
    log("任务执行完毕，总共耗时:" + (System.currentTimeMillis() - startTime) + "ms");
}

执行结果：

由于所有的任务都是执行在主线程，串行执行，所以花了大约1865ms。

27Svq.md.png

优化后

/**
 * 优化后的写法, 这里仅是演示模拟，实际的可能更复杂
 */
private void doJobAfterImprove(final long startTime) {
    ConcurrentGroupTaskStep groupTaskStep = XTask.getConcurrentGroupTask();
    for (int i = 0; i < 4; i++) {
        groupTaskStep.addTask(buildSingleTask(i));
    }
    XTask.getTaskChain()
            .addTask(new MainInitTask(logger))
            .addTask(groupTaskStep)
            .addTask(new AsyncInitTask(logger))
            .setTaskChainCallback(new TaskChainCallbackAdapter() {
                @Override
                public void onTaskChainCompleted(@NonNull ITaskChainEngine engine, @NonNull ITaskResult result) {
                    log("任务完全执行完毕，总共耗时:" + (System.currentTimeMillis() - startTime) + "ms");
                }
            }).start();
    log("主线程任务执行完毕，总共耗时:" + (System.currentTimeMillis() - startTime) + "ms");
}

@NonNull
private XTaskStep buildSingleTask(int finalI) {
    return XTask.getTask(new TaskCommand() {
        @Override
        public void run() throws Exception {
            new SingleJob((finalI + 1), logger).doJob();
        }
    });
}

执行结果：

由于只有优先级最重要的任务在主线程执行，其他任务都是异步执行，所以主线程任务执行消耗57ms，所有任务执行消耗1267ms。

3.2 IO优化

3.网络请求优化。

4.磁盘IO优化

3.3 线程优化

我们在开发应用的过程中，都或多或少会使用到线程。当我们创建一个线程时，需要向系统申请资源，分配内存空间，这是一笔不小的开销，所以我们平时开发的过程中都不会直接操作线程，而是选择使用线程池来执行任务。

但问题就在于如果线程池设置不对的话，很容易被人滥用，引发内存溢出的问题。而且通常一个应用会有多个线程池，不同功能、不同模块乃至是不同三方库都会有自己的线程池，这样大家各用各的，就很难做到资源的协调统一，劲不往一处使。

3.3.1 线程优化分析

1.线程池耗时分析。

要想进行线程优化，首先我们就需要了解线程池在使用过程中，哪些地方比较耗时。

2.线程池执行分析。

然后再让我们看看线程池的执行逻辑：

我们知道，一个线程池通常由一个核心线程池和一个阻塞队列组成。那么当我们调用线程池去执行一个任务的时候，线程池是如何执行的呢？

核心线程池 -> 阻塞队列 -> 最大线程数(新建线程） -> RejectedExecutionHandler（拒绝策略）

其中核心线程池的最大线程数并不是设置的越大越好，为什么这么说？因为CPU的处理能力是有限的，四核的CPU一次也只能同时执行四个任务，如果核心线程池数设置过大，那么各任务之间就会互相竞争CPU资源，加大CPU的调度消耗，这样反而会降低线程池的执行效率。

一般来说，核心线程池的最大线程数满足下面的公式：

最佳核心线程数目 = （（线程等待时间 + 线程CPU时间）/ 线程CPU时间 ）* CPU数目

（1）线程等待时间所占比例越高，需要越多线程。（2）线程CPU时间所占比例越高，需要越少线程。

这里我们考虑两种最常见的情况：

3.3.2 线程优化目标

通过上面对线程池的分析，我们可以知道：

因此，我们线程优化的目标是：

（1）拥有可以统筹全局的统一的线程池。（2）能根据机器的性能来控制数量，合理分配线程池大小。（3）能够根据业务的优先级进行调度，优先级高的先执行。

3.3.3 线程优化具体措施

1.建立主线程池+副线程池的组合线程池，由线程池管理者统一协调管理。主线程池负责优先级较高的任务，副线程池负责优先级不高以及被主线程池拒绝降级下来的任务。

这里执行的任务都需要设置优先级，任务优先级的调度通过PriorityBlockingQueue队列实现，以下是主副线程池的设置，仅供参考：

2.使用Hook的方式，收集应用内所以使用newThread方法的地方，改为由线程池管理者统一协调管理。

3.将所有提供了设置线程池接口的第三方库，通过其开放的接口，设置为线程池管理者管理。没有提供设置接口的，考虑替换库或者插桩的方式，替换线程池的使用。

3.4 闪屏优化

闪屏优化属于启动用户体验的优化。毕竟谁也不想使用页面一闪一闪的应用。

1.设置自定义闪屏页。

设置自定义的闪屏页可以提高我们启动的"视觉速度"。通常会设置一个背景，然后把logo居中显示，可以使用xml文件来布局（注意，该图片不可展示动画，并且展示时间也不可控）。这种方式可以给用户一种启动非常快的感觉，不仅解决了启动白屏的问题，并且展示了品牌logo也有助于提升品牌认知。

(1) 使用xml自定义一张带有logo的图片。

<?xml version="1.0" encoding="utf-8"?>
<layer-list xmlns:android="http://schemas.android.com/apk/res/android"
    android:opacity="opaque">
    <item android:drawable="?attr/xui_config_color_splash_bg"/>

    <item android:bottom="?attr/xui_config_app_logo_bottom">
        <bitmap
            android:gravity="center"
            android:src="?attr/xui_config_splash_app_logo"/>
    </item>

    <item android:bottom="?attr/xui_config_company_logo_bottom">
        <bitmap
            android:gravity="bottom"
            android:src="?attr/xui_config_splash_company_logo"/>
    </item>
</layer>

(2) 把这张图片通过设置主题的android:windowBackground属性方式显示为启动闪屏。

<style name="XUITheme.Launch.Demo">
    <item name="android:windowBackground">@drawable/xui_config_bg_splash</item>
    <item name="xui_config_splash_app_logo">@drawable/ic_splash_app_logo_xui</item>
    <item name="xui_config_splash_company_logo">@drawable/ic_splash_company_logo_xuexiang</item>
</style>

(3) 在manifest中将主页的主题设置为刚才带启动图片的Launch主题。

<activity
    android:name=".activity.MainActivity"
    android:theme="@style/XUITheme.Launch.Demo">
</activity>

(4) 代码执行到主页面的onCreate的时候设置为程序正常的主题，这样就切回到正常主题背景了。

public class BaseActivity extends XPageActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        setTheme(R.style.AppTheme);
        super.onCreate(savedInstanceState);
    }
}

2.使用Android12提供的启动画面Splash Screen。

https://developer.android.google.cn/guide/topics/ui/splash-screen

3.如果是因为某些不可抗拒的原因（例如一些大型游戏的首次加载），导致第一次启动非常慢的话，可以在主页面进入之前，增加一个进度条加载页面。这样的好处就是要告诉用户，到底需要多久才能加载完毕，给用户一个明确的信息，缓解用户的等待焦虑。

4.减少首页的跳转层次。除非某些不可抗拒的原因（比如广告作为一项重要收入来源），尽量不要设置启动页（SplashActivity），因为打开和关闭任何一个Activity都是需要消耗时间的，每多一个Activity的跳转就意味着我们主页面的打开时间会被延长。

3.5 主页面优化

主页面的启动和显示也是app启动非常重要的一部分。

3.5.1 布局优化

布局优化的核心就是：提高页面渲染的速度，防止页面过度渲染导致耗时。

3.5.2 页面数据预加载

一般来说，我们喜欢在每个页面内部才开始加载和显示数据，因为这样写可能更容易让人看懂，利于以后的维护。但是如果等页面UI布局初始化完毕后，我们才去加载数据的话，势必会增加页面启动显示的时间。

因为每个页面（Activity）的启动本身就是比较耗时的过程，我们可以将需要显示的数据进行预加载（即页面启动和数据加载同时进行，串行->并行），这样等页面UI布局初始化完毕后，我们就可以拿着预加载的数据直接渲染显示了，这样可以减少数据加载的等待，从而达到加快页面显示的目的。

这里我们可以参考开源预加载库：PreLoader

3.6 系统调度优化

3.7 GC 优化

启动过程中应当减少GC的次数。因为GC会暂停程序的执行，从而会带来延迟的代价。那么我们应当如何避免频繁的GC呢？

3.8 Webview启动优化

如果你的应用使用到了Webview，可以按需对Webview进行优化。

3.9 应用瘦身

对应用瘦身，可以最直接地加快资源加载的速度，从而提高应用启动的效率。

3.10 资源重排

利用Linux的IO读取策略，PageCache和ReadAhead机制，按照读取顺序重新排列，减少磁盘IO次数。具体可参见《支付宝 App 构建优化解析：通过安装包重排布优化 Android 端启动性能》 这篇文章。这种技术门槛较高，一般应用都不会用到。

3.11 类重排

类重排的实现通过ReDex的Interdex调整类在Dex中的排列顺序。调整Dex中类的顺序，把启动时需要加载的类按顺序放到主dex里。具体实现可以参考[《Redex初探与Interdex：Andorid冷启动优化》] 这篇文章。

4 . 如何进行优化

上面讲了那么多应用启动优化的策略和措施，可能有些人就会问了：那么具体到我们每个不同的项目上，我们应该如何进行优化呢？

以下是我个人的优化步骤，仅供参考：

最后

讲了这么多，还是希望大家在平时开发的过程中，多重视一些应用启动优化的相关技巧，这样等别人让你优化应用启动的时候，也就不会那么手足无措了。

Copyright© 2013-2020

All Rights Reserved 京ICP备2023019179号-8