android热启动

① android启动优化概述

Android启动应用, 按 官方说法 分为冷启动, 温启动和热启动.
具体的定义可以看官方文档, 简单地说

一般我们只需要关注冷启动即可.

要想启动快, 硬件性能必然有影响, 在硬件一定的前提下, 我们要尽量 降低启动应用时CPU的负载 , 让CPU有更多的算力投入到启动流程中:

在做好一些基本原则后, 接着看具体的流程优化点

在应用进程创建后, 首先必然是加载类, 此时一些静态变量就会初始化了, 因此我们应该

类加载完毕后就是创建 Application 实例了, 因此我们应该

之后会先创建 ContentProvider 和执行 ContentProvider.onCreate() , 因此我们应该

跟接着就会执行 Application.onCreate() 等方法, 因此我们应该

接着就进入 Activity 环节.
同样第一步会是创建实例, 因此我们应该

在 Activity 进程生命周期后, 第一步就是渲染(inflate)布局, 我们应该

在应用启动的瞬间, 系统服纳亏务会先展示一个空白窗口哪茄歼, 等待应用第一帧绘制完毕后, 再从该窗口切换到应用, 如果启动耗时较长, 就会明显看到白屏, 对于这一点, 常见的操作有

可以使用IdleHandler, 在主线程空闲时再执行某些不重要的操作

实际上异步初始化只是不阻塞主线程, 但是子线程一样会占用CPU资源, 让主线程的执行时间变少, 所以不应该盲目地将所有工作放到子线程.

优化做到最后, 就是在系统流程上做文章了

原理是将启动时加载的类放到主dex，提升了这些类的内聚，让更多的类满足pre-verify的条件，在安装时就做了校验和优化，以减少首次加载的耗时，从而优化冷启动耗时。
Redex 初探与 Interdex：Andorid 冷启动优化

应用启动过程中会从apk压缩包中读取文件, 该优化的原理是利用Linux中的Pagecache机制, 让启动过程会用到的文件尽可能进入缓存中, 减少磁盘IO次数
支付宝 App 构建优化解析：通过安装包重排布优化 Android 端启动性能

在Dalvik VM(Android5.0以前)加载类的时候会有一个类校验过程, 它需要校验方李冲法的每一个指令, 是一个比较耗时的过程, 可以通过Hook去掉类加载过程中的类验证过程. 不过对于ART(Android5.0之后)来说, 这个过程在安装时已经做了, 所以用处不大.

不进入冷启动, 就不用优化了~

这个Android Studio自带的工具, 可以看到启动过程中详细的方法执行流程, 但是采集数据本身会影响方法执行, 所以不能准确判断每个方法的耗时, 但是仍可以判断哪个方法相对来说耗时.

这个工具的好处是可以自定义事件, 可以指定需要采集的数据集, 可以看到线程间的状态等.

启动优化的一个关键点在于定义启动结束的点, 以及如何测量启动时间.

在Android4.4以上, 系统进程会提供一个类似 ActivityManager: Displayed ***: +3s534ms 的日志, 表示从启动进程到首次绘制完毕所用的时间.

应用可以在任何时候调用该方法, 触发系统打印类似 system_process I/ActivityManager: Fully drawn {package}/.MainActivity: +1s54ms 的日志

应用可以通过 ViewTreeObserver 来监听绘制前回调来判断第一帧的绘制时机, 或者直接在控件树的末尾加一个简单的View, 它 onDraw 调用时即表示页面(差不多)绘制完毕.

应用启动过程可以参考 Android Vitals Series' Articles 系列文章

② Android 性能优化 05---App启动优化

其实启动框架就是一个任务调度系统，是手淘启动的“大管家”。
管家要做的事情就是把它们的关系梳理得明明白白，有条不紊，合理安排位置、调度时间，袭哗同时提升硬件资源的利用率。

总结下来无非就是两点：

有向无环图[拓扑排序]

可用方案
APT，字节码插桩，利用ContentProvider
面试题LeakCanary 为什么不需要在Application中手动初始化？

①点击桌面App图标，Launcher进程采用Binder IPC向system_server进程发起 startActivity请求；
②system_server进程接收到请求后，向zygote进程发送创建进程的请求；
③Zygote进程fork出新的子进程，即App进程；
④App进程，通过Binder IPC向sytem_server进程发起attachApplication请求；
⑤system_server进程在收到请求后，进皮禅顷行一系列准备工作后，再通过binder IPC 向App进程发送scheleLaunchActivity请求；
⑥App进程的binder线程（ApplicationThread）在收到请求后，通过handler向主 线程发送LAUNCH_ACTIVITY消息；
⑦主线程在收到Message后，通过反射机制创建目标Activity，并回调 Activity.onCreate()等方法。
⑧到此，App便正式启动，开始进入Activity生命周期，执行完 onCreate/onStart/onResume方法，UI渲染结束后便可以看到App的主界面。

应用有三种启动状态，每种状态都会影响应用向用户显示所需的时间：冷启动、温启动与热启动。

adb命令启动应用，一般会输入三个值：ThisTime、TotalTime与WaitTime。
1.WaitTime：包括前一个应用Activitypause的时间和新应用启动的时间；
2.ThisTime：表示一连串启动Activity的最后一个Activity的启动耗时；
3.TotalTime：表示新应用启动的耗时，包括新进程的启动和Activity的启动，但不包括前一个应用Activitypause
的耗时。

StrictMode是一个开发人员工具，它可以检测出我们可能无意中做的事情，并将它们提请我们注意，以便我 们能够修复它们。 StrictMode最常用于捕获应用程序主线程上的意外磁盘或网络访问。帮助我们让磁盘和网络操作远离主线程， 可以使应用程序更加平滑、响应更快

当系统加载并启动 App 时，需要耗费相应的时间，这样会造成用户会感觉到当点击 App 图标时会有 “延迟” 现象，
为了解决这一问题，Google 的做法是燃陆在 App 创建的过程中，先展示一个空白页面，让用户体会到点击图标之后立
马就有响应。
如果你的application或activity启动的过程太慢，导致系统的BackgroundWindow没有及时被替换，就会出现启动
时白屏或黑屏的情况（取决于Theme主题是Dark还是Light）。

消除启动时的黑/白屏问题，大部分App都采用自己在Theme中设置背景图的方式来解决。

然后在Activity的onCreate方法，把Activity设置回原来的主题。

这么做，只是提高启动的用户体验。并不能做到真正的加快启动速度。

③ Android性能优化第（八）篇---App启动速度优化之耗时检测处理

应用的启动速度缓慢这是很多开发者都遇到的一个问题，比如启动缓慢导致的黑屏，白屏问题，大部分的答案都是做一个透明的主题，或者是做一个Splash界面，但是这并没有从根本上解决这个问题。那么如何从根本上解决这个问题或者做到一定程度的缓解？

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

2、热启动：当启动应用时，后台已有该应用的进程，比如按下home键，这种在已有进程的情况下，这种启动会从已有的进程中来启动应用，这种启动方式叫热启动。

3、温启动 ：当启动应用时，后台已有该应用的进程，但是启动的入口Activity被干掉了，比如按了back键，应用虽然退出了，但是该应用的进程是依然会保留在后台，这种启动方式叫温启动。

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

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

这里面涉及到三个时间，ThisTime、TotalTime 和 WaitTime。WaitTime 是 startActivityAndWait 这个方法的调用耗时，ThisTime 是指调用过程中最后一个 Activity 启动时间到这个 Activity 的 startActivityAndWait 调用结束。TotalTime 是指调用过程中第一个 Activity 的启动时间到最后一个 Activity 的 startActivityAndWait 结束。如果过程中只有一个 Activity ，则 TotalTime 等于 ThisTime。

总结:如果只关心某个应用自身启动耗时，参考TotalTime；如果关心系统启动应用耗时，参考WaitTime；如果关心应用有界面Activity启动耗时，参考ThisTime。

从我们Application开始到首页显示出来，这个过程，我们应该注意一些什么，将这个过程细分一下，会有下面的时间点需要注意。

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

因为上面这些阶段全部都是在主线程中执行的，任何不经意的操作都可能拖慢应用的启动速度。所以我们不应在Application以及Activity的生命周期回调中做任何费时操作，具体指标大概是你在onCreate，onResume，onStart等回调中所花费的总时间最好不要超过400ms，否则用户在桌面点击你的应用图标后，将感觉到明显的卡顿。但是有些 不得以的任务 又必须在UI显示之前执行。所以我们要将 任务 划分优先级。

对于首页渲染完成后，开始加载，或者延迟加载，延迟加载的目的就是界面先显示出来，然后加载，但是你觉得要延迟多久呢？在 Android 的高端机型上,应用的启动是非常快的 , 这时候只需要 Delay 很短的时间就可以了, 但是在低端机型上,应用的启动就没有那么快了,而且现在应用为了兼容旧的机型,往往需要 Delay 较长的时间,这样带来体验上的差异是很明显的。延迟加载有一种方式。

极力推荐用第二种，在窗口完成以后进行加载，这里面的run方法是在onResume之后运行的。关于这种懒加载机制，参考 Android应用启动优化:一种DelayLoad的实现和原理(上篇) ，给出了详细的解释。

通过上面我们知道一种懒加载机制，所以我们可以将Application中和首页的onCreate中的有些耗时任务，放到首页渲染完毕后加载。如何找出这些耗时任务，TraceView就派上用场了，TraceView的用法，移步我的前面的博客 Android性能优化第（六）篇---TraceView 分析图怎么看？

比如在首页的onCreate中我们进行了用户启动上报，这个进行懒加载是不是分分钟减少139毫秒呢？

在比如在Application里面用到了GSON，将String转化成json,我将这个移动到懒加载里面，是不是又减少了100毫秒呢？

在比如，有些Application中做了支付SDK的初始化，用户又不会一打开App就要支付，放在Application中加载干嘛？

此处我们这里举得例子是优化了139毫秒和100毫秒的，其实真正耗时的任务有的有1秒多，都被我优化完了，所以trace图中看不到了，就举个了这两个例子，还有SharedPreferences也是耗时大户，经过检测保存一个boolean变量耗时120+毫秒以上。

利用TraceView可以清楚我们每一个方法的耗时时间，极大的帮助了我们做优化工作。

五、优化思路总结
1、UI渲染优化，去除重复绘制，减少UI重复绘制时间，打开设置中的GPU过度绘制开关，各界面过度绘制不应超过2.5x；也就是打开此调试开关后，界面整体呈现浅色，特别复杂的界面，红色区域也不应该超过全屏幕的四分之一；
2、根据优先级的划分，KoMobileApplication的一些初始化工作能否将任务优先级划分成3,在首页渲染完成后进行加载，比如：PaySDKManager。
3、主线程中的所有SharedPreference能否在非UI线程中进行，SharedPreferences的apply函数需要注意，因为Commit函数会阻塞IO，这个函数虽然执行很快，但是系统会有另外一个线程来负责写操作，当apply频率高的时候，该线程就会比较占用CPU资源。类似的还有统计埋点等，在主线程埋点但异步线程提交，频率高的情况也会出现这样的问题。
4、检查BaseActivity,不恰当的操作会影响所有子Activity的启动。
5、对于首次启动的黑屏问题，对于“黑屏”是否可以设计一个.9图片替换掉，间接减少用户等待时间。
6、对于网络错误界面，友好提示界面，使用ViewStub的方式，减少UI一次性绘制的压力。
7、任务优先级为2，3的，通过下面这种方式进行懒加载的方式

8、Multidex的使用，也是拖慢启动速度的元兇，必须要做优化。后面有空专门写一篇Multidex。

相关链接：

Android应用启动优化:一种DelayLoad的实现和原理(上篇)http://androidperformance.com/2015/11/18/Android-app-lunch-optimize-delay-load.html

Android性能优化之加快应用启动速度http://www.open-open.com/lib/view/open1452821612355.html

手机淘宝性能优化全记录http://www.open-open.com/lib/view/open1452488209370.html

Android客户端性能优化（魅族资深工程师毫无保留奉献）http://blog.tingyun.com/web/article/detail/155#rd

Please accept mybest wishes for your happiness and success !

④ 如何优化 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大点，包括系统影响的耗时。

下面是测量一个应用冷启动和热启动的时间：
冷启动：


热启动：




以上就是本文的全部内容，希望对大家学习Android软件编程有所帮助。

⑤ Activity的启动流程

开发中我们会调用startActivity来启动一个Activity，最终会调到 startActivityForResult ：

Instrumentation 是Android系统里面的一套控制方法或者“钩子”。这些钩子可以在正常的生命周期（正常是由操作系统控制的）之外控制Android控件的运行。

Application和Activity的所有生命周期中，都会先调用Instrumentation提供的相应方法（如callActivityOnCreate，callApplicationOnCreate，newActivity，callActivityOnNewIntent）

Instrumentation.execStartActivity

ActivityTaskManager.getService()返回了一个IActivityTaskManager，拿到的是ATMS的代理对象，跨进程调用了ATMS的startActivity方法。

ActivityStarter.startActivityMayWait

ActivityStarter中做了一系列的调用（收集Intent信息，处理startActivityForResult，做一些校验判断等），最终进入startActivityUnchecked。

startActivityUnchecked

startActivityUnchecked中处理了关于Activity启动模式的处理，接着真正的resume我们的Activity

这里会先判断应用进程是否创建，创建了就进入 realStartActivityLocked ，没创建就会调用 ActivityManagerInternal.startProcess

①热启动realStartActivityLocked

接着看ActivityThread中接收并处理消息的handleMessage

前面realStartActivityLocked方法中通过addCallback，传入参数LaunchActivityItem。executeCallbacks方法中取出callbacks集合中的LaunchActivityItem，并调用其execute方法

handleLaunchActivity

②冷启动创建应用进程ActivityManagerInternal.startProcess

ActivityManagerInternal的实现类是AMS中的LocalService，AMS通过Socket与Zygote通信，fork出App进程，app进程创建后，会执行ActivityThread的main方法（Android进程入口方法）

调用ActivityThread的attach

[4]thread.bindApplication 这是一个binder通信的过程

ActivityThread内部的Handler接收到BIND_APPLICATION消息

回到上面attachApplicationLocked的mAtmInternal.attachApplication，调用ATMS的attachApplication

看到了似曾相识的realStartActivityLocked，后面流程和之前一样。Activity启动流程分析完毕。

总结

1）与Activity管理有关的类：

ActivityRecord ：历史栈中的一个条目，代表一个Activity

TaskRecord ：内部维护了一个ArrayList<ActivityRecord> ，来保存ActivityRecord

ActivityStack ：内部维护了一个ArrayList<TaskRecord>，用来管理TaskRecord

ActivityStackSupervisor ：用来管理ActivityStack的

2）Activity启动流程

⑥ 使用adb查看别人家APP的数据

1.说明
2.使用adb命令获取指定应用的包名和Activity名称
3.使用adb命令启动/关闭APP
4.使用adb命令把手机中的apk导到电脑上
5.查看apk中的AndroidManifest.xml文件
6.使用adb命令进行数据备份
7.查看数据
8.结语

查看其它APP数据的前提是该APP默认开启数据备份，也就是allowBackup属性。
想问一下大家在平时的开发中对应用的安全性有很在意么？有可能大家会想到加密、混淆、apk加固，但还有一些其他细节的东西需要大家去了解。今天就介绍一下android:allowBackup属性。这个属性在开发的过程中通常是默认开启的，Google起初是为了防止数据丢失，留下了这个功能，但是这个属性也容易造成一些隐私数据的泄露。如果你想关闭可以把它设置为false。那么这个属性在哪里设置呢，就在AndroidManifest.xml文件中的application标签中。

要备份APP的数据，首先我们要知道这个APP的包名才可以进行备份。

在手机或模拟器上面运行APP，然后输入命令： adb shell mpsys activity top #
这时会输出很多东西，你可以用查找功能Ctrl+F，找到TASK，下图红框中就是要找的包名

命令： adb logcat| findstr START
然后在手机或模拟器上点击你想要获取的应用，这时就会在cmd中出现相应的包名和类名了。

启动APP的命令： adb shell am start -W -n package/activity

命令窗口通过adb shell 进入android 的Linux命令界面，输入am help看到如下信息：

它会展示出在不同场景下（比如start-activity、start-service等）不同参数代表的意义一些参数的意义，情况太多了这里就不细说了。

回到正题，后面的package和activity就是上面获取包名第二种方法中提到的cmp，比如我们要启动谷歌地图： adb shell am start -W -n com.google.android.apps.maps/com.google.android.maps.MapsActivity

在这里我们再做一个延伸， 用命令做APP的冷启动和热启动操作，然后记录启动的时间
我们看到上图中有三个数字ThisTime、TotalTime和WaitTime，这三个数字就是本次启动APP所花费的时间。
热启动时退出退出APP的命令： adb shell input keyevent 3 ，这就相当于按了手机的home键，然后我们再执行启动APP的命令，这样就完成了热启动。

我们看到热启动花费的时间比冷启动少了很多，一套冷、热启动的流程我们就走完了。接下来就看我们怎么去优化了，让它们变的更少。所以我们在平时做启动优化的时候可以把自己的APP和一些优秀的APP做一下对比看看还差多少。

上面已经说过了一种退出APP的方法了，接下来这个命令是相当于杀掉当前的APP进程。
命令： adb shell am force-stop package
这时候再使用启动命令，就相当于冷启动了。

有的时候我们在手机上查看和操作apk不是特别方便，而且通过文件管理找apk也很难找。接下来就介绍怎么用adb命令把手机中的apk导到电脑上。

通过包名获取apk在手机中的存储路径，命令 adb shell pm path package

导出apk文件，到当前目录下
命令： adb pull 路径

这一步就要看一下apk中有哪些东西了，主要还是看一下AndroidManifest.xml文件当中的allowBackup设置。
我平常用的方法就是吧apk文件的后缀该成zip，然后就可以看到里面的东西了。下面的是谷歌地图的apk的构成。

下面来看一下AndroidManifest.xml文件，会看到都是乱码，但是关键的信息还是可以获取的，我们目前想要的就是下图红框中的allowBackup属性，像谷歌的APP肯定是把它设置成false的，所以我们没办法备份它的信息的。

那么我们怎么看一个应用的allowBackup属性设置成true还是false呢，我的观察和实践出来的方法是看allowBackup后面有没有小方框，有就代表设置了true。如果有哪位大神知道好的可靠的方法还请留言告知。

下面是其他apk中的AndroidManifest.xml文件，后面带了个小方框。

在了解到APP可以备份之后，我们就可以开始做坏事了，哈哈。
备份的命令： adb backup -nosystem -all -noapk -noshared -f data.ab package

[-system | -nosystem] 是否备份系统
[-apk | -noapk] 是否备份apk安装文件
[-shared | -noshared] 是否备份手机存储空间
-f *.ab 存档格式一定要是.ab
package：包名

在运行命令之后，手机或模拟器会出现一个页面要求你输入备份密码，这个密码你可以随便输入，但你要记住，在后面查看ab文件的时候会用到。

输入密码，点击【备份我的数据】之后就开始备份了，备份完成之后会有提示，这时就是生产一个ab文件了。

ab文件大家很少接触，这里使用abe工具（链接： https://pan..com/s/1NPbhtF1fyJcHOm1CXwi9Dg

写这篇文章还是提醒大家在平时的开发中要注重APP数据的安全问题，毕竟数据还是相当重要的。
如果有哪里写的不对的地方，请指出，我会及时改正。

⑦ 如何加快Android应用启动速度

• 应用的启动

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

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

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

• 应用启动的流程

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

• 减少应用启动时的耗时

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

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

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