android

Android性能优化

Posted by jjx on August 21, 2016

合理管理内存

节制地使用Service

如果应用程序当中需要使用Service来执行后台任务的话，请一定要注意只有当任务正在执行的时候才应该让Service运行起来。另外，当任务执行完之后去停止Service的时候，要小心Service停止失败导致内存泄漏的情况。 当我们启动一个Service时，系统会倾向于将这个Service所依赖的进程进行保留，这样就会导致这个进程变得非常消耗内存。并且，系统可以在LRU cache当中缓存的进程数量也会减少，导致切换应用程序的时候耗费更多性能。严重的话，甚至有可能会导致崩溃，因为系统在内存非常吃紧的时候可能已无法维护所有正在运行的Service所依赖的进程了。 为了能够控制Service的生命周期，Android官方推荐的最佳解决方案就是使用IntentService

当界面不可见时释放内存

当用户打开了另外一个程序，我们的程序界面已经不再可见的时候，我们应当将所有和界面相关的资源进行释放。在这种场景下释放资源可以让系统缓存后台进程的能力显著增加，因此也会让用户体验变得更好。 那么我们如何才能知道程序界面是不是已经不可见了呢？其实很简单，只需要在Activity中重写onTrimMemory()方法，然后在这个方法中监听TRIM_MEMORY_UI_HIDDEN这个级别，一旦触发了之后就说明用户已经离开了我们的程序，那么此时就可以进行资源释放操作了，如下所示：

@Override
public void onTrimMemory(int level) {
    super.onTrimMemory(level);
    switch (level) {
    case TRIM_MEMORY_UI_HIDDEN:
        // 进行资源释放操作
        break;
    }
}

当内存紧张时释放内存

除了刚才讲的TRIM_MEMORY_UI_HIDDEN这个回调，onTrimMemory()方法还有很多种其它类型的回调，可以在手机内存降低的时候及时通知我们。我们应该根据回调中传入的级别来去决定如何释放应用程序的资源：

  • TRIM_MEMORY_RUNNING_MODERATE 表示应用程序正常运行，并且不会被杀掉。但是目前手机的内存已经有点低了，系统可能会开始根据LRU缓存规则来去杀死进程了。
  • TRIM_MEMORY_RUNNING_LOW 表示应用程序正常运行，并且不会被杀掉。但是目前手机的内存已经非常低了，我们应该去释放掉一些不必要的资源以提升系统的性能，同时这也会直接影响到我们应用程序的性能。
  • TRIM_MEMORY_RUNNING_CRITICAL 表示应用程序仍然正常运行，但是系统已经根据LRU缓存规则杀掉了大部分缓存的进程了。这个时候我们应当尽可能地去释放任何不必要的资源，不然的话系统可能会继续杀掉所有缓存中的进程，并且开始杀掉一些本来应当保持运行的进程，比如说后台运行的服务。

以上是当我们的应用程序正在运行时的回调，那么如果我们的程序目前是被缓存的，则会收到以下几种类型的回调：

  • TRIM_MEMORY_BACKGROUND 表示手机目前内存已经很低了，系统准备开始根据LRU缓存来清理进程。这个时候我们的程序在LRU缓存列表的最近位置，是不太可能被清理掉的，但这时去释放掉一些比较容易恢复的资源能够让手机的内存变得比较充足，从而让我们的程序更长时间地保留在缓存当中，这样当用户返回我们的程序时会感觉非常顺畅，而不是经历了一次重新启动的过程。
  • TRIM_MEMORY_MODERATE 表示手机目前内存已经很低了，并且我们的程序处于LRU缓存列表的中间位置，如果手机内存还得不到进一步释放的话，那么我们的程序就有被系统杀掉的风险了。
  • TRIM_MEMORY_COMPLETE 表示手机目前内存已经很低了，并且我们的程序处于LRU缓存列表的最边缘位置，系统会最优先考虑杀掉我们的应用程序，在这个时候应当尽可能地把一切可以释放的东西都进行释放

避免在Bitmap上浪费内存

当我们读取一个Bitmap图片的时候，有一点一定要注意，就是千万不要去加载不需要的分辨率。在一个很小的ImageView上显示一张高分辨率的图片不会带来任何视觉上的好处，但却会占用我们相当多宝贵的内存。需要仅记的一点是，将一张图片解析成一个Bitmap对象时所占用的内存并不是这个图片在硬盘中的大小，可能一张图片只有100k你觉得它并不大，但是读取到内存当中是按照像素点来算的，比如这张图片是15001000像素，使用的ARGB_8888颜色类型，那么每个像素点就会占用4个字节，总内存就是15001000*4字节，也就是5.7M，这个数据看起来就比较恐怖了。

使用优化过的数据集合

Android API当中提供了一些优化过后的数据集合工具类，如SparseArray，SparseBooleanArray，以及LongSparseArray等，使用这些API可以让我们的程序更加高效。传统Java API中提供的HashMap工具类会相对比较低效，因为它需要为每一个键值对都提供一个对象入口，而SparseArray就避免掉了基本数据类型转换成对象数据类型的时间。

知晓内存的开支情况

我们还应当清楚我们所使用语言的内存开支和消耗情况，并且在整个软件的设计和开发当中都应该将这些信息考虑在内。可能有一些看起来无关痛痒的写法，结果却会导致很大一部分的内存开支，例如：

  • 使用枚举通常会比使用静态常量要消耗两倍以上的内存，在Android开发当中我们应当尽可能地不使用枚举。
  • 任何一个Java类，包括内部类、匿名类，都要占用大概500字节的内存空间。
  • 任何一个类的实例要消耗12-16字节的内存开支，因此频繁创建实例也是会一定程序上影响内存的。
  • 在使用HashMap时，即使你只设置了一个基本数据类型的键，比如说int，但是也会按照对象的大小来分配内存，大概是32字节，而不是4字节。因此最好的办法就是像上面所说的一样，使用优化过的数据集合。

谨慎使用抽象编程

许多程序员都喜欢各种使用抽象来编程，认为这是一种很好的编程习惯。当然，这一点不可否认，因为的抽象的编程方法更加面向对象，而且在代码的维护和可扩展性方面都会有所提高。但是，在Android上使用抽象会带来额外的内存开支，因为抽象的编程方法需要编写额外的代码，虽然这些代码根本执行不到，但是却也要映射到内存当中，不仅占用了更多的内存，在执行效率方面也会有所降低。当然这里我并不是提倡大家完全不使用抽象编程，而是谨慎使用抽象编程，不要认为这是一种很酷的编程方式而去肆意使用它，只在你认为有必要的情况下才去使用。

尽量避免使用依赖注入框架

现在有很多人都喜欢在Android工程当中使用依赖注入框架，比如说像Guice或者RoboGuice等，因为它们可以简化一些复杂的编码操作

上去确实十分诱人，我们甚至可以将findViewById()这一类的繁琐操作全部省去了。但是这些框架为了要搜寻代码中的注解，通常都需要经历较长的初始化过程，并且还可能将一些你用不到的对象也一并加载到内存当中。这些用不到的对象会一直占用着内存空间，可能要过很久之后才会得到释放，相较之下，也许多敲几行看似繁琐的代码才是更好的选择。

内存分析工具

Android最佳性能实践(二)——分析内存的使用情况 - 郭霖的专栏 - 博客频道 - CSDN.NET

高性能编码优化

下面来看一些我们可以避免创建对象的场景：

  • 如果我们有一个需要拼接的字符串，那么可以优先考虑使用StringBuffer或者StringBuilder来进行拼接，而不是加号连接符，因为使用加号连接符会创建多余的对象，拼接的字符串越长，加号连接符的性能越低。
  • 在没有特殊原因的情况下，尽量使用基本数据类来代替封装数据类型，int比Integer要更加高效，其它数据类型也是一样。
  • 当一个方法的返回值是String的时候，通常可以去判断一下这个String的作用是什么，如果我们明确地知道调用方会将这个返回的String再进行拼接操作的话，可以考虑返回一个StringBuffer对象来代替，因为这样可以将一个对象的引用进行返回，而返回String的话就是创建了一个短生命周期的临时对象。
  • 正如前面所说，基本数据类型要优于对象数据类型，类似地，基本数据类型的数组也要优于对象数据类型的数组。另外，两个平行的数组要比一个封装好的对象数组更加高效，举个例子，Foo[]和Bar[]这样的两个数组，使用起来要比Custom(Foo,Bar)[]这样的一个数组高效得多。

静态优于抽象

如果你并不需要访问一个对象中的某些字段，只是想调用它的某个方法来去完成一项通用的功能，那么可以将这个方法设置成静态方法，这会让调用的速度提升15%-20%，同时也不用为了调用这个方法而去专门创建对象了，这样还满足了上面的一条原则。另外这也是一种好的编程习惯，因为我们可以放心地调用静态方法，而不用担心调用这个方法后是否会改变对象的状态（静态方法内无法访问非静态字段）。

使用增强型for循环语法

增强型for循环（也被称为for-each循环）可以用于去遍历实现Iterable接口的集合以及数组，这是jdk 1.5中新增的一种循环模式。当然除了这种新增的循环模式之外，我们仍然还可以使用原有的普通循环模式，只不过它们之间是有效率区别的，我们来看下面一段代码：

多使用系统封装好的API

Java语言当中其实给我们提供了非常丰富的API接口，我们在编写程序时如果可以使用系统提供的API就应该尽量使用，系统提供的API完成不了我们需要的功能时才应该自己去写，因为使用系统的API在很多时候比我们自己写的代码要快得多，它们的很多功能都是通过底层的汇编模式执行的。 比如说String类当中提供的好多API都是拥有极高的效率的，像indexOf()方法和一些其它相关的API，虽说我们通过自己编写算法也能够完成同样的功能，但是效率方面会和这些方法差的比较远。这里举个例子，如果我们要实现一个数组拷贝的功能，使用循环的方式来对数组中的每一个元素一一进行赋值当然是可行的，但是如果我们直接使用系统中提供的System.arraycopy()方法将会让执行效率快9倍以上。

布局优化技巧

重用布局文件

Android系统中已经提供了非常多好用的控件，这让我们在编写布局的时候可以很轻松。但是有些时候我们可能需要反复利用某个已经写好的布局，如果你总是使用复制粘贴的方式来进行布局重用，这显然是一种很笨的做法。而Android当然也已经充分考虑到了布局重用的重要性，于是提供了include和merge这两个非常有用的标签，下面我们就来逐个学习一下。

include

include标签可以允许在一个布局当中引入另外一个布局，那么比如说我们程序的所有界面都有一个公共的部分，这个时候最好的做法就是将这个公共的部分提取到一个独立的布局文件当中，然后在每个界面的布局文件当中来引用这个公共的布局。 这里举个例子吧，我们应该都知道，目前几乎所有的软件都会有一个头布局，头布局中可以包含界面的标题、返回按钮、以及其它一些操作功能等。那这样的一个头布局，有些软件是使用ActionBar来实现的，但是由于ActionBar的灵活性不太好，因而也有很多软件会选择自己去编写实现。那如果自己去实现的话，由于这个头布局是在所有界面都要使用的，显然我们不可能在每个界面当中都去写一遍这个头布局的代码，因此这种情况下使用include标签就非常合适了。

merge

merge标签是作为include标签的一种辅助扩展来使用的，它的主要作用是为了防止在引用布局文件时产生多余的布局嵌套。大家都知道，Android去解析和展示一个布局是需要消耗时间的，布局嵌套的越多，那么解析起来就越耗时，性能也就越差，因此我们在编写布局文件时应该让嵌套的层数越少越好。

仅在需要时才加载布局

有的时候我们会遇到这样的场景，就是某个布局当中的元素非常多，但并不是所有元素都一起显示出来的，而是普通情况下只显示部分常用的元素，而那些不常用的元素只有在用户进行特定操作的情况下才会显示出来。

那么我们如何才能让这些不常用的元素仅在需要时才去加载呢？Android为此提供了一种非常轻量级的控件，ViewStub。ViewStub虽说也是View的一种，但是它没有大小，没有绘制功能，也不参与布局，资源消耗非常低，将它放置在布局当中基本可以认为是完全不会影响性能的。

参考链接

Android最佳性能实践(四)——布局优化技巧 - 郭霖的专栏 - 博客频道 - CSDN.NET

绘制中的性能问题

Android渲染机制

大家自己编写App的时候，有时会感觉界面卡顿，尤其是自定义View的时候，大多数是因为布局的层次过多，存在不必要的绘制，或者onDraw等方法中过于耗时。那么究竟需要多快，才能给用户一个流畅的体验呢？那么就需要简单了解下Android的渲染机制，一图胜千言：

Android系统每隔16ms发出VSYNC信号，触发对UI进行渲染，那么整个过程如果保证在16ms以内就能达到一个流畅的画面。那么如果操作超过了16ms就会发生下面的情况：

如果系统发生的VSYNC信号，而此时无法进行渲染，还在做别的操作，那么就会导致丢帧的现象，（大家在察觉到APP卡顿的时候，可以看看logcat控制太，会有drop frames类似的警告）。这样的话，绘制就会在下一个16ms的时候才进行绘制，即使只丢一帧，用户也会发现卡顿的~~（ps:上面标识不应该是32ms么，咋是34ms，难道我错过了什么）。

好了，很多朋友会不会奇怪为什么是16ms，16ms意味着着1000/60hz，相当于60fps，那么只要解释为什么是60fps，好在这个问题，网上有解答：

这是因为人眼与大脑之间的协作无法感知超过60fps的画面更新。12fps大概类似手动快速翻动书籍的帧率，这明显是可以感知到不够顺滑的。24fps使得人眼感知的是连续线性的运动，这其实是归功于运动模糊的 效果。24fps是电影胶圈通常使用的帧率，因为这个帧率已经足够支撑大部分电影画面需要表达的内容，同时能够最大的减少费用支出。但是低于30fps是 无法顺畅表现绚丽的画面内容的，此时就需要用到60fps来达到想要的效果，当然超过60fps是没有必要的（据说Dart能够带来120fps的体验）。

好了，有了对Android渲染机制基本的认识以后，那么我们的卡顿的原因就在于没有办法在16ms内完成该完成的操作，而主要因素是在于没有必要的layouts、invalidations、Overdraw。渲染的过程是由CPU与GPU协作完成，下面一张图很好的展示出了CPU和GPU的工作，以及潜在的问题，检测的工具和解决方案。

如果你对上图感到不理解，没关系，你只要知道问题：

  • 通过Hierarchy Viewer去检测渲染效率，去除不必要的嵌套
  • 通过Show GPU Overdraw去检测Overdraw，最终可以通过移除不必要的背景以及使用canvas.clipRect解决大多数问题。

Overdraw的检测

对于性能优化，那么首先肯定是去发现问题，那么对么overdraw这个问题，还是比较容易发现的。 按照以下步骤打开Show GPU Overrdraw的选项：

设置 -> 开发者选项 -> 调试GPU过度绘制 -> 显示GPU过度绘制

好了，打开以后呢，你会发现屏幕上有各种颜色，此时你可以切换到需要检测的程序，对于各个色块，对比一张Overdraw的参考图

那么如果你发现你的app上深红色的色块比较多，那么可能就要注意了，接下来就开始说如果遇到overdraw的情况比较严重我们该则么处理。

  • Overdraw 的处理方案一：移除不必要的background
  • Overdraw 的处理方案二：clipRect的妙用

修改前：

protected void onDraw(Canvas canvas)
    {

        super.onDraw(canvas);

        canvas.save();
        canvas.translate(20, 120);
        for (Bitmap bitmap : mCards)
        {
            canvas.translate(120, 0);
            canvas.drawBitmap(bitmap, 0, 0, null);
        }
        canvas.restore();

    }

修改后：

 protected void onDraw(Canvas canvas)
    {

        super.onDraw(canvas);

        canvas.save();
        canvas.translate(20, 120);
        for (int i = 0; i < mCards.length; i++)
        {
            canvas.translate(120, 0);
            canvas.save();
            if (i < mCards.length - 1)
            {
                canvas.clipRect(0, 0, 120, mCards[i].getHeight());
            }
            canvas.drawBitmap(mCards[i], 0, 0, null);
            canvas.restore();
        }
        canvas.restore();

    }

好了，说完了Overdraw的检测与处理，那么还剩下一个layouts、invalidations过慢的问题，那么这类问题主要可能是你的XML层级过多导致的，当然也有很好的工具可以用来检测，那么就是Hierarchy Viewer。

减少不必要的层次：巧用Hierarchy Viewer

1、Hierarchy Viewer工具简介

Android SDK中包含这个工具，不过大家肯定也不陌生了~~~

那么就简单说一下它在哪，如何使用，以及真机无法使用该工具该怎么解决。

Hierarchy Viewer在哪？

然后手机打开此Activity，打开Android Device Moniter，切换到Hierarchy Viewer视图，可以看到：

点击LinearLayout，然后点击Profile Node，你会发现所有的子View上面都有了3个圈圈， （取色范围为红、黄、绿色），这三个圈圈分别代表measure 、layout、draw的速度，并且你也可以看到实际的运行的速度，如果你发现某个View上的圈是红色，那么说明这个View相对其他的View，该操作运行最慢，注意只是相对别的View，并不是说就一定很慢。

参考链接
Android UI性能优化实战 识别绘制中的性能问题 - Hongyang - 博客频道 - CSDN.NET

更新

性能问题常见原因

性能问题一般归结为三类：

  1. UI卡顿和稳定性:这类问题用户可直接感知，最为重要；

  2. 内存问题：内存问题主要表现为内存泄露，或者内存使用不当导致的内存抖动。如果存在内存泄露，应用会不断消耗内存，易导致频繁gc使系统出现卡顿，或者出现OOM报错；内存抖动也会导致UI卡顿。

  3. 耗电问题：会影响续航，表现为不必要的自启动，不恰当持锁导致系统无法正常休眠，系统休眠后频繁唤醒系统等；

UI卡顿常见原因和分析方法

下面分别介绍出现这些问题的常见原因以及分析这些问题的一般步骤。

1.卡顿常见原因

1）人为在UI线程中做轻微耗时操作，导致UI线程卡顿；

2） 布局Layout过于复杂，无法在16ms内完成渲染；

3）同一时间动画执行的次数过多，导致CPU或GPU负载过重；

4） View过度绘制，导致某些像素在同一帧时间内被绘制多次，从而使CPU或GPU负载过重；

5） View频繁的触发measure、layout，导致measure、layout累计耗时过多及整个View频繁的重新渲染；

6） 内存频繁触发GC过多（同一帧中频繁创建内存），导致暂时阻塞渲染操作；

7） 冗余资源及逻辑等导致加载和执行缓慢；

8）工作线程优先级未设置为

Process.THREAD_PRIORITY_BACKGROUND 导致后台线程抢占UI线程cpu时间片，阻塞渲染操作；

9） ANR；

卡顿分析解决的一般步骤

1）解决过度绘制问题

在设置->开发者选项->调试GPU过度绘制中打开调试，看对应界面是否有过度绘制，如果有先解决掉：

2) 检查是否有主线程做了耗时操作：

严苛模式（StrictMode），是Android提供的一种运行时检测机制，用于检测代码运行时的一些不规范的操作，最常见的场景是用于发现主线程的IO操作。应用程序可以利用StrictMode尽可能的发现一些编码的疏漏。

  • 开启 StrictMode

  • 对于应用程序而言，Android 提供了一个最佳使用实践：尽可能早的在

android.app.Application 或 android.app.Activity 的生命周期使能 StrictMode，onCreate()方法就是一个最佳的时机，越早开启就能在更多的代码执行路径上发现违规操作。

  • 监控代码
public void onCreate() {
 if (DEVELOPER_MODE) {
 StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
 .detectAll() .penaltyLog() .build());
     StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
 .detectAll() .penaltyLog() .build());
 }
     super.onCreate();
}

如果主线程有网络或磁盘读写等操作，在logcat中会有”D/StrictMode”tag的日志输出，从而定位到耗时操作的代码。

3）如果主线程无耗时操作，还存在卡顿，有很大可能是必须在UI线程操作的一些逻辑有问题，比如控件measure、layout耗时过多等，此时可通过Traceview以及systrace来进行分析。

4）Traceview：Traceview主要用做热点分析，找出最需要优化的点。

打开DDMS然后选择一个进程，接着点击上面的“Start Method Profiling”按钮（红色小点变为黑色即开始运行），然后操作我们的卡顿UI,然后点击”Stop Method Profiling”,会打开如下界面：

内存性能分析优化

导出内存文件，利用MAT分析

耗电量优化建议

电量优化主要是注意尽量不要影响手机进入休眠，也就是正确申请和释放WakeLock，另外就是不要频繁唤醒手机，主要就是正确使用Alarm。

一些好的代码实践

  1. 节制地使用Service

  2. 当界面不可见时释放内存

  3. 当内存紧张时释放内存

  4. 避免在Bitmap上浪费内存

Android客户端性能优化（魅族资深工程师毫无保留奉献）

Android性能优化之加快应用启动速度

通常来说，在安卓中应用的启动方式分为两种：冷启动和热启动。

1、冷启动：当启动应用时，后台没有该应用的进程，这时系统会重新创建一个新的进程分配给该应用，这个启动方式就是冷启动。

2、热启动：当启动应用时，后台已有该应用的进程（例：按back键、home键，应用虽然会退出，但是该应用的进程是依然会保留在后台，可进入任务列表查看），所以在已有进程的情况下，这种启动会从已有的进程中来启动应用，这个方式叫热启动。

特点

1、冷启动：冷启动因为系统会重新创建一个新的进程分配给它，所以会先创建和初始化Application类，再创建和初始化MainActivity类（包括一系列的测量、布局、绘制），最后显示在界面上。

2、热启动：热启动因为会从已有的进程中来启动，所以热启动就不会走Application这步了，而是直接走MainActivity（包括一系列的测量、布局、绘制），所以热启动的过程只需要创建和初始化一个MainActivity就行了，而不必创建和初始化Application，因为一个应用从新进程的创建到进程的销毁，Application只会初始化一次。

上面说的启动是点击app的启动图标来启动的，而另外一种方式是进入最近使用的列表界面来启动应用，这种不应该叫启动，应该叫恢复。

应用启动的流程

在安卓系统上，应用在没有进程的情况下，应用的启动都是这样一个流程：当点击app的启动图标时，安卓系统会从Zygote进程中fork创建出一个新的进程分配给该应用，之后会依次创建和初始化Application类、创建MainActivity类、加载主题样式Theme中的windowBackground等属性设置给MainActivity以及配置Activity层级上的一些属性、再inflate布局、当onCreate/onStart/onResume方法都走完了后最后才进行contentView的measure/layout/draw显示在界面上，所以直到这里，应用的第一次启动才算完成，这时候我们看到的界面也就是所说的第一帧。

所以，总结一下，应用的启动流程如下：

Application的构造器方法——>attachBaseContext()——>onCreate()——>Activity的构造方法——>onCreate()——>配置主题中背景等属性——>onStart()——>onResume()——>测量布局绘制显示在界面上。

测量应用启动的时间

在上面这个启动流程中，任何一个地方有耗时操作都会拖慢我们应用的启动速度，而应用启动时间是用毫秒度量的，对于毫秒级别的快慢度量我们还是需要去精确的测量到到底应用启动花了多少时间，而根据这个时间来做衡量。

什么才是应用的启动时间

从点击应用的启动图标开始创建出一个新的进程直到我们看到了界面的第一帧，这段时间就是应用的启动时间。

我们要测量的也就是这段时间，测量这段时间可以通过adb shell命令的方式进行测量，这种方法测量的最为精确，命令为：

adb shell am start -W [packageName]/[packageName.MainActivity]

执行成功后将返回三个测量到的时间：

1、ThisTime:一般和TotalTime时间一样，除非在应用启动时开了一个透明的Activity预先处理一些事再显示出主Activity，这样将比TotalTime小。
2、TotalTime:应用的启动时间，包括创建进程+Application初始化+Activity初始化到界面显示。
3、WaitTime:一般比TotalTime大点，包括系统影响的耗时。

减少应用启动时的耗时

针对冷启动时候的一些耗时，如上测得这个应用算是中型的app，在冷启动的时候耗时已经快700ms了，如果项目再大点在Application中配置了更多的初始化操作，这样将可能达到1s，这样每次启动都明显感觉延迟，所以在进行应用初始化的时候采取以下策略：

1、在Application的构造器方法、attachBaseContext()、onCreate()方法中不要进行耗时操作的初始化，一些数据预取放在异步线程中，可以采取Callable实现。

2、对于sp的初始化，因为sp的特性在初始化时候会对数据全部读出来存在内存中，所以这个初始化放在主线程中不合适，反而会延迟应用的启动速度，对于这个还是需要放在异步线程中处理。

3、对于MainActivity，由于在获取到第一帧前，需要对contentView进行测量布局绘制操作，尽量减少布局的层次，考虑StubView的延迟加载策略，当然在onCreate、onStart、onResume方法中避免做耗时操作。

遵循上面三种策略可明显提高app启动速度。

参考:减少应用启动耗时