发动优化的意图
APP发动如果得到很好的优化，增强用户体会添加用户流量；如果app发动时刻过长影响用户体会，从而会形成流失用户。所以做发动优化是有有必要的。
谷歌官方针对以下三种发动办法做了详细的介绍，详细能够参阅developer.android.com/topic/perfo…。
从官网得知APP发动所需的时刻为：冷发动时刻>温发动时刻>热发动时刻
发动分三种:
-
冷发动
当运用在设备开机或许系统主动 kill APP 进程之后，用户点击桌面icon图标发动，称之为冷发动。
-
温发动
温发动是APP进程还存活，由于内存缺乏Activity被回收了，当再次发动APP时就会重新履行Activity生命周期，布局制作等操作。
-
热发动
当后台存在该运用的进程或许服务时，用户点击icon图标发动，称之为热发动。一般是用户按了home键回到桌面，或许回来键没有杀进程，或许app本身做了进程重启的机制。
冷发动
冷发动的的进程：
- 加载和发动APP
- 显示一个白色的Window窗口
- 创立APP进程
- 创立Application
- 创立MainActivity
- 加载布局
- 首帧制作
运用的发动进程
冷发动发动流程——当点击app的发动图标时，安卓系统会从Zygote进程中fork创立出一个新的进程分配给该运用，之后会顺次创立和初始化Application类（attachBaseContext()–>OnCreate()）、创立MainActivity类、加载主题款式Theme中的 windowBackground等特点设置给MainActivity以及装备Activity层级上的一些特点、再inflate布局、当onCreate/onStart/onResume办法都走完了，最终才进行contentView的measure/layout/draw显示在界面上，所以直到这儿，运用的第一次发动才算完成，这时分看到的界面也便是首帧。
大致流程如下：
- 点击桌面图标，Launcher会发动程序默许的Acticity，之后再按照程序的逻辑发动各种Activity。
- 发动Activity经过运用程序框架层的ActivityManagerService服务发动(Service也是由ActivityManagerService来发动的)。ActivityManagerService是一个非常重要的接口，它担任发动和办理Activity和Service。
- 无论是经过Launcher来发动Activity，还是经过Activity内部调用startActivity接口来发动新的Activity，都经过Binder进程间通讯进入到ActivityManagerService进程中，并且调用ActivityManagerService.startActivity接口。
- ActivityManagerService调用ActivityStack.startActivityMayWait来做准备要发动的Activity的相关信息。
- ActivityStack告诉ApplicationThread要进行Activity发动调度了，这儿的ApplicationThread代表的是调用ActivityManagerService.startActivity接口的进程，关于经过点击运用程序图标的情形来说，这个进程便是Launcher了，而关于经过在Activity内部调用startActivity的情形来说，这个进程便是这个Activity地点的进程了。
- ApplicationThread不履行真实的发动操作，它经过调用ActivityManagerService.activityPaused接口进入到ActivityManagerService进程中，看看是否需求创立新的进程来发动Activity。
- 关于经过点击运用程序图标来发动Activity的情形来说，ActivityManagerService在这一步中，会调用startProcessLocked来创立一个新的进程，而关于经过在Activity内部调用startActivity来发动新的Activity来说，这一步是不需求履行的，由于新的Activity就在原来的Activity地点的进程中进行发动。
- ActivityManagerServic调用ApplicationThread.scheduleLaunchActivity接口，告诉相应的进程履行发动Activity的操作。
- ApplicationThread把这个发动Activity的操作转发给ActivityThread，ActivityThread经过ClassLoader导入相应的Activity类，然后把它发动起来。
所以相应的优化计划
- 削减 onCreate办法的工作量。
- 不要让Application参与事务逻辑。
- 不要在Application中做耗时操作，一些初始化操作能够开启子线程来完成。
- 不要以静态变量办法在Application中保存数据。
- 布局优化/mainThread尽量延迟初始化。
- 发动画面的初始化能够运用设置主题布景的办法，速度回更快。
发动主题优化
冷发动阶段:
- 加载并发动运用程序。
- 发动后当即显示运用程序空白的发动窗口。
- 创立运用程序进程。
发动主题优化，便是运用程序在冷发动的时分(1~2阶段)，设置发动窗口的主题。由于现在 App 运用发动都会先进入一个闪屏页(LaunchActivity) 来展现运用信息。
默许主题状况
如果咱们对App没有做处理(设置了默许主题)，并且在 Application 的onCreate()初始化了其它第三方的服务(假设需求加载2000ms)，那么系统默许会在发动运用程序的时分发动空白窗口 （发生一个白屏），直到 App 运用程序的进口 Activity 创立成功，视图制作完毕。( 大概是onWindowFocusChanged办法回调的时分 )
处理白屏或黑屏问题
在默许主题的状况下并且Application初始化服务耗时过长就会呈现白屏。如果呈现白屏或黑屏闪现，检查设置Style的Theme。
通明主题优化
<style name="AppTheme2" parent="Theme.AppCompat.Light.DarkActionBar">
......
<item name="android:windowIsTranslucent">true</item>
<item name="android:windowNoTitle">true</item>
</style>
为了处理发动窗口白屏问题，许多开发者都是运用通明主题来处理这个问题，但是治标不治本。尽管处理了上面这个问题，但是依然有些缺乏。已经测试尽管无白屏了，不过从点击到App依然存在视觉延迟。
设置闪屏图片主题
<style name="AppTheme1" parent="Theme.AppCompat.Light.DarkActionBar">
<item name="android:windowBackground">@drawable/icon_bg</item>//闪屏页图片
<item name="android:windowFullscreen">true</item>
<item name="android:windowContentOverlay">@null</item>
</style>
为了更顺滑无缝联接闪屏页，能够在发动 Activity 的 Theme中设置闪屏页图片（如上面代码），这样发动窗口的图片就会是闪屏页图片，而不是白屏。这样设置的话，就会在冷发动的时分，展现闪屏页的图片，等App进程初始化加载进口 Activity (也是闪屏页) 就能够无缝联接。其实这种办法并没有真实的加速运用进程的发动速度，而只是经过用户视觉作用带来的优化体会。
代码优化
当然上面运用设置主题的办法优化用户体会作用治标不治本，要害还在于对代码的优化。首先咱们能够核算一下运用冷发动的时刻。
发动耗时的丈量办法
- 经过adb 指令核算发动耗时时刻
- 手动埋点核算时刻差
adb 指令核算
adb指令 : adb shell am start -S -W 包名/发动类的全限定名 ， -S 表明重启当时运用
更多的ADB指令
G:\AS_Project_Work\Demo>adb shell am start -S -W com.lu.demo/com.lu.demo.MainActivity
Stopping: com.lu.demo
Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.lu.demo/.MainActivity }
Status: ok
Activity: com.lu.demo/.MainActivity
ThisTime: 508
TotalTime: 508
WaitTime: 586
Complete
ThisTime : 最终一个 Activity 的发动耗时(例如从 LaunchActivity – >MainActivity「adb指令输入的Activity」 , 只核算 MainActivity 的发动耗时)。 TotalTime : 发动一连串的 Activity 总耗时.(有几个Activity 就核算几个)。 WaitTime : 运用进程的创立进程 + TotalTime 。
ThisTime<=TotalTime<=WaitTime
这时运用就发动了(留意：此时是冷发动)，当我点击home将运用切到后台之后，再次履行adb shell am start -W 包名/发动类的全限定名的指令，这时能够发现，这三个时刻都缩短了，并且提示Warning: Activity not started, its current task has been brought to the front表明当前发动是一个热发动。
G:\AS_Project_Work\Demo>adb shell am start -W com.lu.demo/com.lu.demo.MainActivity
Stopping: com.lu.demo
Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.lu.demo/.MainActivity }
Warning: Activity not started, its current task has been brought to the front
Status: ok
Activity: com.lu.demo/.MainActivity
ThisTime: 508
TotalTime: 508
WaitTime: 586
Complete
手动埋点核算时刻差
手动埋点在什么机遇开端核算时刻，什么时分完毕核算时刻？一般会在 Application attachBaseContext 中开端埋点核算开端时刻，然后在 Activity 中第一个 View 中preDraw 时完毕埋点核算完毕时刻，两者之差便是发动耗时时刻。从上面的发动进程得知，一般会在 Application attachBaseContext 中开端埋点核算开端时刻，然后在发动MainActivity 中第一个 View 中preDraw 时完毕埋点核算完毕时刻。参照发动进程下面开端代码实现：
//Application.java
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
//开端核算发动时刻（埋点）
LaunchTime.startRecord();
}
//MainActivity.java
TextView text = findViewById(R.id.text);
text.getViewTreeObserver().addOnPreDrawListener(new ViewTreeObserver.OnPreDrawListener() {
@Override
public boolean onPreDraw() {
// 完毕核算发动时刻(埋点)
LaunchTime.stopRecord("TextView preDraw");
return true;
}
});
//LaunchTime.java
public class LaunchTime {
private static final String TAG = LaunchTime.class.getSimpleName();
private static long startTime = 0;
//开端记载计时
public static void startRecord() {
startTime = System.currentTimeMillis();
}
//中止计时 打印出时刻差
public static void stopRecord(String tag) {
//打印日志
Log.e(TAG, tag + "CostTime:" + (System.currentTimeMillis() - startTime));
}
}
//打印日志
06-1267 21:38:37.230 1701-1701/? E/LaunchTime: TextView preDrawCostTime:398
手动核算发动耗时时刻是比较精确的办法，能够带到线上运用，不过需求留意完毕埋点的机遇，这个机遇也能够挑选 addOnDrawListener 但是这个是在API16以上才干运用。
优异的发动优化文章
总结
- 记载发动优化日后好温习。
- 了解APP发动进程，更好设置优化计划。
- 了解主题发动优化计划处理白屏黑屏闪现等问题。
- 代码优化及发动耗时丈量办法，计划挑选。
