猿人部落 › 主页 › 资讯 › 查看内容

Android性能调优：App启动速度优化

2019-7-26 17:51 发布者: 蚂蚁部落评论 0 查看 890

一、App启动分类 1.冷启动 Cold start 在启动应用前，体系还没有App的任何进程。比如装备开机后应用的第一次启动，体

一、App启动分类

1.冷启动 Cold start

在启动应用前，体系还没有App的任何进程。比如装备开机后应用的第一次启动，体系杀掉应用进程 (如：体系内存吃紧引发的 kill 和用户自动产生的 kill) 后的再次启动等。那么天然这种方式下，应用的启动时间最长。

2.热启动 Warm start
当应用中的 Activities 被烧毁，但在内存中常驻时，应用的启动方式就会变为暖启动。相比冷启动，暖启动过程镌汰了对象初始化、UI的布局和渲染。启动时间更短。但启动时，体系依然会展示一个空缺配景，直到第一个 Activity 的内容出现为止。

3.温启动 Lukewarm start
用户退出您的应用，但随后重新启动。该过程大概已继承运行，但应用步伐必须通过调用onCreate（）重新开始重新创建运动。体系从内存中驱逐您的应用步伐，然后用户重新启动它。进程和Activity必要重新启动，但使命可以从生存的实例状态包转达到onCreate（）中。

启动速率优化紧张是针对冷启动方式。下面看下冷启动的时间会做哪些工作。

#二、冷启动
应用发生冷启动时，体系有三件使命要做：

加载启动App；
App启动之后立刻展示出一个空缺的Window；
创建App的进程；

创建App进程后，会立刻实行以下使命：

初始化应用中的对象 (比如 Application 中的工作)；
启动主线程 (UI 线程) ；
创建第一个 Activity；
加载内容视图 (Inflating) ；
盘算视图在屏幕上的位置排版 (Laying out)；
举行第一次绘制 (draw)。

只有当应用完成第一次绘制，体系当前展示的空缺配景才会消散，才会被 Activity 的内容视图更换掉。也就是这个时间，用户才气和我们的应用开始交互。下图展示了冷启动过程体系和应用的一个工作时间流：

三、优化思绪

作为寻常应用，App进程的创建等环节我们是无法自动控制的。开辟职员唯一能做的就是**在Application 和第一个 Activity 中，镌汰 onCreate() 方法的工作量，从而紧缩冷启动的时间。**像应用中嵌入的一些第三方 SDK，都发起在 Application 中做一些初始化工作，开辟职员不妨采取懒加载的情势移除这部门代码，而在真正必要用到第三方 SDK 时再举行初始化。

Google也给出了启动加速的方向：

1、使用提前展示出来的Window，快速展示出来一个界面，给用户快速反馈的体验；
2、克制在启动时做麋集极重的初始化（Heavy app initialization）；
3、定位题目：克制I/O操纵、反序列化、网络操纵、布局嵌套等

四、精确丈量评估启动性能的方法

1.display time

从Android KitKat版本开始，Logcat中会输出从步伐启动到某个Activity表现到画面上所耗费的时间。这个方法比力得当丈量步伐的启动时间。

2.reportFullyDrawn

我们通常来说会使用异步懒加载的方式来提拔步伐画面的表现速率，这通常会导致的一个题目是，步伐画面已经表现，但是内容却还在加载中。为了衡量这些异步加载资源所淹灭的时间，我们可以在异步加载完毕之后调用activity.reportFullyDrawn()方法来告诉体系此时的状态，以便获取整个加载的耗时。

3.Traceview

告诉我们每一个方法实行了多长时间.这个工具可以通过 Android Device Monitor 大概从代码中启动。

3.1 Android Device Monitor启动

启动应用，点击 Start Method Tracing，应用启动后再次点击，会自动打开刚才操纵所记录下的.trace文件，发起使用DDMS来检察，功能更加方便全面。

3.2 代码启动

①在onCreate开始和末端打上trace

    Debug.startMethodTracing("GithubApp");
	...
	Debug.stopMethodTracing();

注意加读写权限

运行步伐, 会在sdcard上天生一个"GithubApp.trace"的文件.

②通过adb pull将文件导出到本地

adb pull /sdcard/GithubApp.trace ~/temp

③打开DDMS分析trace文件
④分析trace文件

在下方的方法区点击"Real Time/Call", 按照方法每次调用耗时降序排.
耗时凌驾500ms都是值得注意的.
看左边的方法名, 可以看到耗时大户就是我们用的几大平台的初始化方法, 特殊是Bugly, 还加载native的lib, 用ZipFile操纵-等.
点击每个方法, 可以看到其父方法(调用它的)和它的全部子方法(它调用的).
点击方法时, 上方的该方法实行时间轴会闪动, 可以看该方法的实行线程及相对时长.

4.Systrace

在onCreate方法内里添加trace.beginSection()与trace.endSection()方法来声明必要跟踪的起止位置，体系会资助统计中心履历过的函数调用耗时，并输出报表。

5.adb下令盘算 App 的启动时间

adb shell am start -W packageName/packageName.activity

比方：

adb shell am start -W com.media.painter/com.media.painter.PainterMainActivity
Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.media.painter/.PainterMainActivity }
Status: ok
Activity: com.media.painter/.PainterMainActivity
ThisTime: 355
TotalTime: 355
WaitTime: 365
Complete

（注意 Android 5.0 之前的手机是没有 WaitTime 这个值的）

WaitTime 就是总的耗时，包罗前一个应用 Activity pause 的时间和新应用启动的时间；
ThisTime 表现一连串启动 Activity 的末了一个 Activity 的启动耗时；
TotalTime 表现新应用启动的耗时，包罗新进程的启动和 Activity 的启动，但不包罗前一个应用 Activity pause 的耗时。
开辟者一样寻常只要关心 TotalTime 即可，这个时间才是自己应用真正启动的耗时。

五、优化方案

1.主题切换

通过主题设置，不表现启动时的白屏配景。有以下几种方案：

1.1 直接不表现白屏，直到步伐初始化完毕直接表现第一个Activity

大概

然后设置给第一个activity

如果将主题设置到Application，那全部的Activity的主题都会改变

然后在MainActivity中在加载布局之前，重新设置主题

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

如许相称于把白屏变成透明的，隐蔽起来了，但是会有一种点击图标后卡住了，过了好几秒才进入App的感觉。这种方案用户体验很差。

1.2把白屏当成闪屏页用

可以通过主题中的 windowBackground 属性，自界说应用启动时的窗口配景。窗口配景表现的内容，Google保举两种方案，一种是表现Logo，一种使用了 placeholder ，与主界面的 UI 框架保持同等，给用户产生一种应用启动非常快的视觉感受。

①表现Logo使用方式:

drawable/branded_launch_screens:

android:opacity=”opaque”参数是为了防止在启动的时间出现配景的闪耀。

界说style:

大概直接使用一张图片

然后将这个主题设置给启动的 Activity。

②使用placeholder：

模仿了一个高度为25dp的状态栏和一个高度为56dp的标题栏。
drawable/placeholder_ui

界说style:

然后将这个主题设置给启动的 Activity。

③还可以适度团结 Activity 内容视图使用动画过渡效果。

2.克制Application的onCreate举行太多的工作

在Application初始化的地方做太多繁重的事变是大概导致严肃启动性能题目的首恶之一。Application内里的初始化操纵不竣事，其他恣意的步伐操纵都无法举行。Application的onCreate中会做大量第三方组件的初始化工作，着实很多组件是必要做区别对待的，有些可以做耽误加载，有些可以放到其他的地方做初始化操纵，特殊必要注意包罗Disk IO操纵，网络访问等严肃耗时的使命，他们会严肃壅闭步伐的启动。

注意点：

项目是多进程架构，只在主进程实行Application的onCreate()；
流程梳理，延后实行；
异步加载、延时加载、懒加载

示比方下，Application以及首屏Activity中我们紧张做了：

怎样判定第三方的库是不是能放在子线程内里：

必要初始化的第三方一样寻常分为两种, 一种是第三方平台的SDK(推送, 分享, 反馈, 统计等) 这个可以通过看其SDK文档, 团结业务需求思量. 比方分享, 反馈一样寻常不是必须要应用一开启就能用的, 这类业务一样寻常层级比力深, 有富足的来由让它们在背景异步初始化. 别的一种第三方是第三方的库, 一样寻常来说, 发起阅读其源码, 相识着实现原理, 再决定是否放在背景初始化.

项目修改：

将友盟、Bugly、听云、GrowingIO、BlockCanary等组件放在WorkThread中初始化；

耽误舆图定位、ImageLoader、自有统计等组件的初始化：舆图及自有统计耽误4秒，此时应用已经打开；而ImageLoader由于调用关系不能异步以及过久耽误，初始化从Application耽误到SplashActivity；而EventBus由于再Activity中使用以是必须在Application中初始化。

3.克制首个Activity的onCreate举行太多的工作

使用耽误加载。确保在Activity的页面表现出来之后再举行加载数据，克制过早或过晚的加载导致页面空缺时间过长。可采取以下代码实现耽误加载。在Activity的onCreate方法中：

getWindow().getDecorView().post(new Runnable() {
  @Override
  public void run() {
    myHandler.post(mLoadingRunnable);
  }
});

4.MultiDex初次启动优化

4.1题目

随着代码数目的膨胀，工程自己的代码加上引用的第三方库的代码中方法数目会凌驾65536的限定。是由于DEX文件格式限定，一个DEX文件中method个数采取使用原生范例short来索引文件中的方法，也就是4个字节共计最多表达65536个method，field/class的个数也均有此限定。 Google为构建凌驾65K方法数的应用提供官方支持的方案：MultiDex。

但是在Dalvik下MultiDex有个题目：5.0以下某些低端机遇出现ANR大概长时间卡顿不进入引导页，而罪魁罪魁是MultiDex.install(Context context)的dexopt过程耗时过长。因此必要在初次启动时做特殊处理处罚。

而5.0以上会使用ART，在ART下MultiDex是不存在这个题目的，这紧张是由于ART下采取Ahead-of-time (AOT) compilation技能，体系在APK的安装过程中会使用自带的dex2oat工具对APK中可用的DEX文件举行编译并天生一个可在本地呆板上运行的文件，如许能进步应用的启动速率，只是在安装过程中举行了处理处罚如许会影相应用的安装速率。

4.2管理思绪

1、在Application.attachBaseContext(Context base)中，判定是否初次启动，以及体系版本是否小于5.0，如果是，跳到2；否则，直接实行MultiDex.install(Context context)。

2、开启一个新进程，在这个进程中实行MultiDex.install(Context context)。实行完毕，叫醒主进程，自身竣事。主进程在开启新进程后，自身是挂起的，直到被叫醒。

3、叫醒的主进程继承实行初始化操纵。

末了

如果你看到了这里，以为文章写得不错就点个赞呗？如果你以为那边值得改进的，请给我留言。肯定会认真查询，修正不敷。谢谢。

盼望读到这的您能转发分享和关注一下我，以后还会更新技能干货，谢谢您的支持！

末了针对Android开辟的偕行，小编这边给各人整理了一些资料，此中分享内容包罗但不限于 【高级UI、性能优化、移动架构师、NDK、肴杂式开辟（ReactNative+Weex）微信小步伐、Flutter等全方面的Android进阶实践技能】 盼望能资助各人学习提拔进阶，也节省各人在网上搜刮资料的时间来学习，也是可以分享给身边好友一起学习的！

转发+点赞+关注，关注微信公众号【Android开辟之家】获取小编为各人收录的进阶资料和口试题库

Android架构师之路很漫长，一起共勉吧！