面试官：说一说Android启动优化

概述应用的启动速度对一个APP来说至关重要，会直接影响到用户体验，如果启动速度过慢会导致用户的流失，本文就启动速度优化分析，为优化启动速度提供一些思路。1、应用启动分类应用有三种启动状态，每种状态都会影响应用向用户显示所需的时间：冷启动、温启动和热启动。在冷启动中，应用从

应用的启动速度对一个APP来说至关重要，会直接影响到用户体验，如果启动速度过慢会导致用户的流失，本文就启动速度优化分析，为优化启动速度提供一些思路。

1、应用启动分类

应用有三种启动状态，每种状态都会影响应用向用户显示所需的时间：冷启动、温启动和热启动。在冷启动中，应用从头开始启动。在另外两种状态中，系统需要将后台运行的应用带入前台。

1.1、冷启动

app冷启动可以分为两个阶段

第一阶段

1、加载并启动app

2、启动后立即显示一个空白的启动窗口

3、创建app进程

第二阶段

1、创建app对象

2、启动主线程

3、创建主Activity

4、加载布局

5、布置屏幕

6、首帧绘制

一旦应用进程完成首帧绘制，系统进程就会换掉当前显示的后台窗口，替换为主Activity。此时，用户可以开始使用应用

冷启动中，作为开发者，能干预的部分主要是Application的OnCreate阶段和Activity的onCreate阶段，如下图：

1.2、热启动

热启动时，系统将activity放到前台。如果应用程序的所有activity存在内存中，则应用程序可以避免重复对象初始化、渲染、绘制 *** 作

1.3、温启动

温启动时，由于app的进程仍然存在，执行的是冷启动的第二阶段

1、创建app对象

2、启动主线程

3、创建主Activity

4、加载布局

5、布置屏幕

6、首帧绘制

温启动常见场景：

1、用户退出应用后又重启应用。进程可能继续运行。但应用从调用Activity的onCreate方法开始重新执行

2、内存不足，系统将应用杀死，然后用户重新启动。进程和Activity需要重启，但传递到onCreate的已保存的实例bundle对于完成启动有一定帮助

接下来来看下如何获得启动时间~

2、获取启动时间2.1、使用adb命令获取

adb shell am start -W [packagename]/[packagename.xxActivity]

adb shell am start -W com.tg.test.gp/com.test.demo.MainActivityStarting: Intent { act=androID.intent.action.MAIN cat=[androID.intent.category.LAUNCHER] cmp=com.tg.test.gp/com.test.demo.MainActivity }Status: okLaunchState: ColDActivity: com.tg.test.gp/com.test.demo.MainActivityThisTime: 1344TotalTime: 1344WaitTime: 1346Complete

ThisTime: 最后一个Activity启动耗时

TotalTime: 启动时经历的所有Activity总耗时

WaitTime: AMS启动所有Activity的总时间（包括启动目标应用前的）

2.2、使用代码打点

public class LaunchTimer {    private static long sTime;    public static voID startRecord() {        sTime = System.currentTimeMillis();    }    public static voID endRecord() {        endRecord("");    }    public static voID endRecord(String msg) {        long cost = System.currentTimeMillis() - sTime;        LogUtils.i(msg + "cost " + cost);    }}

该方式一般为Application初始化attachBaseContext方法打启动开始时间戳，应用用户可 *** 作界面完全展示可 *** 作后打结束时间戳，两时间差即为启动耗时

但这种方式并不优雅，如果启动逻辑复杂，方法很多的情况下，最好采用aop进行优化。

3、应用启动优化分析工具3.1、TraceVIEw

TracevIEw是AndroID自带的性能分析工具，可图形化展示方法调用时间，调用栈，还可以查看所有线程信息，对分析方法耗时，调用链是非常好的工具

使用方法是采用代码埋点的方式：

1、在开始收集的位置，执行DeBUG.startMethodTracing("app_trace"),其中参数为自定义文件名

2、在结束收集的位置，执行DeBUG.endMethodTracing()

文件生成路径为/sdcard/AndroID/data/包名/files/文件名.trace，使用AndroID Studio可以打开该文件

举个例子：

我们来看下testAdd这个方法的耗时

public class MainActivity extends AppCompatActivity {    @OverrIDe    protected voID onCreate(Bundle savedInstanceState) {        super.onCreate(savedInstanceState);        setContentVIEw(R.layout.activity_main);        testAdd(3, 5);    }    private voID testAdd(int a, int b) {        DeBUG.startMethodTracing("app_trace");        int c = a + b;        Log.i("Restart", "c =  a + b = " + c);        DeBUG.stopMethodTracing();    }}

运行程序后，找到/sdcard/AndroID/data/com.restart.perference/files/app_trace.trace文件，在AndroIDStudio中双击它，是可以解析出文件中的信息的，打开后如下：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-R2s1gpZz-1616421092820)(https://upload-images.jianshu.io/upload_images/25094154-7d9a059e870d906c.image?imagemogr2/auto-orIEnt/strip%7CimageVIEw2/2/w/1240)]

下面来看下，CallChart, FlameChart, top Down, Bottom Up分别是怎么用的。首先要选择好时间区域，像本案例中，因为程序很简单，能分析的区域比较小，选中它后，可得到下图：

Call Chart得到的图形中，可以看到程序整个调用栈，同时可以看到方法耗时。

比如图中的testAdd方法，先后调用了DeBUG.startMethodTracing、Log.i、DeBUG.stopMethodTracing方法。同时从图中可以看出startMethodTracing方法比stopMethodTracing方法耗时长。在实际优化中，找到哪个方法耗时长，针对性优化是非常有作用的。

分析时，第三方程序，系统代码我们一般是优化不了的，CallChart非常贴心地用颜色帮我们区分哪些是我们自己写的代码。橙色的是系统API，蓝色一般是第三方API，绿色的才是我们自己写的。比如图中的testAdd方法，我们自己写的是可以通过调整优化的。

Flame Chart是Call Chart的倒序图，作用相似，图形如下：

top Down可以看到每个方法内部调用了哪些方法，以及每个方法的耗时，耗时占比，相比于Call Chart的图形查找，top Down则是更具体，有具体的方法耗时数据

图中的Total代表方法总共的耗时，self代表方法内非方法调用的代码耗时，Children代表方法内调用的其他方法的耗时。

同样以testAdd方法为例，testAdd方法总耗时为3840us，占程序运行时间97%，testAdd方法中自身代码耗时为342us，占比为8.65%，testAdd方法中调用的其他方法总共耗时3498us，占比88.52%

private voID testAdd(int a, int b) {        DeBUG.startMethodTracing("app_trace");//算到Children中        int c = a + b;//这一句是算在self耗时中，耗时其实很短        Log.i("Restart", "c =  a + b = " + c);//算到Children中        DeBUG.stopMethodTracing();//算到Children中}

Bottom Up是top Down的倒序图，可以看方法是被哪个方法调用的

TraceVIEw中还有个选项值得注意，

在右上角有个Wall Clock Time和Thread Time的选项，其中Wall Clock Time的意思是方法执行的实际耗时，而Thread Time指的是cpu耗时。我们平时说的优化更多的是优化cpu时间，当有IO *** 作时，用Thread Time来分析耗时更合理

此外，使用TraceVIEw需要关注TraceVIEw的运行时开销，因为它自身耗时较长，就有可能会带偏我们的优化方向。

3.2、Systrace

Systrace结合AndroID内核的数据，生成HTML报告

systrace在AndroID/sdk/platform-tools/systrace目录中。使用前需要安装python，因为systrace是用python生成HTML

报告的，命令如下：

python systrace.py -b 32768 -t 10 -a 包名 -o perference.HTML sched gfx vIEw wm am app

具体参数可参考：developer.android.google.cn/studio/prof…

执行命令后，打开报告,显示如下

要使用Chrome浏览器打开，否则可能会显示白屏。如果使用Chrome也显示白屏，可在Chrome浏览器中输入Chrome:tracing, 再Load文件进去显示

查看图时，A键是左移，D键右移， S键缩小，W键放大

4、常用优化4.1、启动加载常见优化策略

一个应用越大，涉及模块越多，包含的服务甚至进程就会越多，如网络模块的初始化，底层数据初始化等，这些加载都需要提前准备好，有些不必要的就不要放到应用中。通常可以从以下四个维度整理启动的各个点：

1、必要且耗时：启动初始化，考虑用线程来初始化

2、必要不耗时：不用处理

3、非必要耗时，数据上报、插件初始化，按需处理

4、非必要不耗时：直接去掉，有需要的时候再加载

将应用启动时要执行的内容按上述分类，按需实现加载逻辑。那么常见的优化加载策略有哪些呢？

异步加载：耗时多的加载放到子线程中异步执行

延迟加载: 非必须的数据延迟加载

提前加载：利用ContentProvIDer提前进行初始化

下面分别介绍异步加载和延迟加载的一些常用处理

4.2、异步加载

异步加载，简单来说，就是使用子线程异步加载。在实际场景中，启动时常常需要对各种第三方库做初始化 *** 作。通过将初始化放到子线程中进行，可以大大加快启动。

但是通常，有些业务逻辑是要再第三方库的初始化后才能正常运行的，这时候如果只是简单的放到子线程中跑，不做限制就很可能出现在没初始化完成就跑业务逻辑，导致异常。

这种较为复杂的情况下，可以采用CountDownLatch处理，或者是使用启动器的思想处理。

CountDownLatch使用

class MyApplication extends Application {    // 线程等待锁    private CountDownLatch mCountDownLatch = new CountDownLatch(1);    // cpu核数    private static final int cpu_COUNT = Runtime.getRuntime().availableProcessors();    // 核心线程数    private static final int CORE_POol_SIZE = Math.max(2, Math.min(cpu_COUNT - 1, 4));    voID onCreate() {		ExecutorService service = Executors.newFixedThreadPool(CORE_POol_SIZE);        service.submit(new Runnable() {            @OverrIDe public voID run() {            	//初始化weex，因为Activity加载布局要用到需要提前初始化完成                initWeex();                mCountDownLatch.countDown();            }        });        service.submit(new Runnable() {            @OverrIDe public voID run() {            	//初始化BUGly,无需关心是否在界面绘制前初始化完                initBUGly();            }        });        //提交其他库初始化，此处省略。。。		try {            //等待weex初始化完才走完onCreate            mCountDownLatch.await();		} catch (Exception e) {            e.printstacktrace();		}    }}

使用CountDownLatch在初始化的逻辑不复杂的情况下推荐使用。但如果初始化的几个库之间又有相互依赖，逻辑复杂的情况下，则推荐使用加载器的方式。

启动器

启动器的核心如下：

充分利用cpu多核能力，自动梳理并顺序执行任务；代码Task化，将启动任务抽象成各个task；根据所有任务依赖关系排序生成一个有向无环图；多线程按照线程优先级顺序执行

具体实现可参考：github.com/NoEndToLF/A…

4.3、延迟加载

有些第三方库的初始化其实优先级并不高，可以按需加载。或者是利用IDleHandler在主线程空闲的时候进行分批初始化。

按需加载可根据具体情况实现，这里不做赘述。这里介绍下使用IDleHandler的使用

    private MessageQueue.IDleHandler mIDleHandler = new MessageQueue.IDleHandler() {        @OverrIDe        public boolean queueIDle() {            //当return true时，会移除掉该IDleHandler，不再回调，当为false，则下次主线程空闲时会再次回调            return false;        }    };

使用IDleHandler做分批初始化，为什么要分批？当主线程空闲时，执行IDleHandler，但如果IDleHandler内容太多，则还是会导致卡顿。因此最好是将初始化 *** 作分批在主线程空闲时进行

public class DelayInitdispatcher {    private Queue<Task> mDelayTasks = new linkedList<>();    private MessageQueue.IDleHandler mIDleHandler = new MessageQueue.IDleHandler() {        @OverrIDe        public boolean queueIDle() {            //每次执行一个Task，实现分批进行            if(mDelayTasks.size()>0){                Task task = mDelayTasks.poll();                new dispatchRunnable(task).run();            }            //当为空时，返回false，移除IDleHandler            return !mDelayTasks.isEmpty();        }    };    //添加初始化任务    public DelayInitdispatcher addTask(Task task){        mDelayTasks.add(task);        return this;    }    //给主线程添加IDleHandler    public voID start(){        Looper.myQueue().addIDleHandler(mIDleHandler);    }}

4.4、提前加载

上述方案中初始化最快的时机都是在Application的onCreate中进行，但还有更早的方式。ContentProvIDer的onCreate是在Application的attachBaseContext和onCreate方法中间进行的。也就是说它比Application的onCreate方法更早执行。所以可以利用这点来对第三方库的初始化进行提前加载。

androIDx-startup使用

如何使用：第一步，写一个类实现Initializer,泛型为返回的实例，如果不需要的话，就写Unitclass TimberInitializer : Initializer<Unit> {    //这里写初始化执行的内容，并返回初始化实例    overrIDe fun create(context: Context) {        if (BuildConfig.DEBUG) {            Timber.plant(Timber.DeBUGTree())            Timber.d("TimberInitializer is initialized.")        }    }    //这里写初始化的东西依赖的另外的初始化器，没有的时候返回空List    overrIDe fun dependencIEs(): List<Class<out Initializer<*>>> {        return emptyList()    }}第二步，在AndroIDManifest中声明provIDer，并配置Meta-data写初始化的类<provIDer    androID:name="androIDx.startup.InitializationProvIDer"    androID:authoritIEs="com.test.pokedex.androIDx-startup"    androID:exported=“false"    //这里写merge是因为其他模块可能也有同样的provIDer声明，做合并 *** 作    tools:node="merge">    //当有相互依赖的情况下，写顶层的初始化器就可以，其依赖的会自动搜索到    <Meta-data        androID:name="com.test.pokedex.initializer.TimberInitializer"        androID:value="androIDx.startup" /></provIDer>

4.5、其他优化

1、在应用中，增加启动默认图或者自定义一个theme，在Activity首先使用一个默认的界面解决部分启动短暂黑白屏问题。如androID:theme="@style/theme.AppStartLoad"

5、小结

1、冷启动、温启动、热启动主要进行的处理及他们的区别

2、如何获取启动时间，介绍了使用adb命令和代码打点这两种方式

3、如何使用工具找到程序中耗时较长的代码，介绍TraceVIEw和Systrace的使用

4、常见的启动优化方式及实现介绍（异步加载，延迟加载，提前加载等），关键思想：异步、延迟、懒加载

总结

以上是内存溢出为你收集整理的面试官：说一说Android启动优化全部内容，希望文章能够帮你解决面试官：说一说Android启动优化所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。