android启动应用,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 系列文章

[img]

相关问答

Q1: Android应用程序启动流程总结

AMS主要功能：

AMS是Android中最核心的服务，主要负责系统中四大组件的启动、切换、调度及应用进程的管理和调度等工作。还负责启动或杀死应用程序的进程。

WMS主要功能：

为所有窗口分配Surface。

管理Surface的显示顺序、尺寸、位置。

管理窗口动画。

输入系统相关：WMS是派发系统按键和触摸消息的最佳人选，当接收到一个触摸事件，它需要寻找一个最合适的窗口来处理消息。

PWS主要功能：

PMS 用来管理跟踪所有应用APK，包括安装，卸载，解析，控制权限等。

SystemServer也是一个进程，包括AMS、PMS、WMS等等。

zygote意为“受精卵“。Android是基于Linux系统的，而在Linux中，所有的进程都是由init进程直接或者是间接fork出来的，zygote进程也不例外。

App进程是用户点击桌面icon时，通过Launcher进程请求SystemServer，再调用Zygote孵化的。

①点击启动一个App，Launcher进程采用Binder IPC向ActivityManagerService发起startActivity请求；

②ActivityManagerService接收到请求后，向zygote进程发送创建进程的请求；

③Zygote进程fork出新的子进程，即App进程；

④App进程通过Binder IPC向sytem_server进程发起绑定Application请求；

⑤system_server进程在收到请求后，进行一系列准备工作后，再通过binder IPC向App进程发送scheduleLaunchActivity请求；

⑥App进程的binder线程（ApplicationThread）在收到请求后，通过handler向主线程发送LAUNCH_ACTIVITY消息；

⑦主线程在收到Message后，通过发射机制创建目标Activity，并回调Activity.onCreate()等方法。

⑧到此，App便正式启动，开始进入Activity生命周期，执行完onCreate/onStart/onResume方法，UI渲染结束后便可以看到App的主界面。

备注：

Launcher，PMS，Zygote，App进程是三个独立的进程，相互通信就需要使用进程间通信机制。与Zygote通信是使用的socket通信，Launcher，PMS，App进程间使用的是Binder机制。

Q2: Android App 开机自启动

article class="_2rhmJa"

Android 设备开机自启动的可以用广播实现，因为 Android 设备开机时会发送一条开机广播 "android.intent.action.BOOT_COMPLETED"。接收后实现启动就完成了。

接下来是准备工作

如果按照上面的全部步骤后操作后，重启没有自动启动程序，怎么办呢？是怎么回事呢？

*那么首先请检查一下你的手机是不是安装了360等安全助手之类的软件，如果有，请在软件的自启动软件管理中将app设置为允许

*我的手机没有安装这些软件，但是手机中自带了安全助手，有的手机系统设置里面自带了自启动软件管理的功能 ，所以在这里将我们的app设置为允许开机启动），重启手机，测试是否成功。

然而并没有成功

接收不到BOOT_COMPLETED广播可能的原因

(1)、BOOT_COMPLETED对应的action和uses-permission没有一起添加

(2)、应用安装到了sd卡内，安装在sd卡内的应用是收不到BOOT_COMPLETED广播的

(3)、系统开启了Fast Boot模式，这种模式下系统启动并不会发送BOOT_COMPLETED广播

(4)、应用程序安装后重来没有启动过，这种情况下应用程序接收不到任何广播，包括BOOT_COMPLETED、ACTION_PACKAGE_ADDED、CONNECTIVITY_ACTION等等。

Android3.1之后，系统为了加强了安全性控制，应用程序安装后或是(设置)应用管理中被强制关闭后处于stopped状态，在这种状态下接收不到任何广播，除非广播带有FLAG_INCLUDE_STOPPED_PACKAGES标志，而默认所有系统广播都是FLAG_EXCLUDE_STOPPED_PACKAGES的，所以就没法通过系统广播自启动了。所以Android3.1之后

(1)、应用程序无法在安装后自己启动

(2)、没有ui的程序必须通过其他应用激活才能启动，如它的Activity、Service、Content Provider被其他应用调用。

存在一种例外，就是应用程序被adb push you.apk /system/app/下是会自动启动的，不处于stopped状态。

并不太懂 我的APP启动后 已经收到广播

第一种方式 我再模拟器上 测试 可以 android 9.0版本

桌面设置也会把你的app当成一个桌面主题，还有一个选项是系统桌面，你需要设置成自己的app

如果找不到桌面设置选项，可以从手机设置–应用程序-查看所有应用程序（包括系统的应用程序），找到桌面程序之类的字眼的应用，清楚其默认设置。

Q3: Android应用自启动机制

一般应用自启动是通过开机广播实现。 1.系统开机后，系统产生并发送开机广播，同时设置开机广播的Flag为FLAG_excluds_stopped_packages,即对于之前未启动过的应用不发送开机广播。 2.系统刚开机时，检查应用之前是否启动是通过读取存储中的配置文件(package-restriction.xml)中应用的stopped属性来判断的。 3.当上一次打开应用，10秒后，系统会将应用的stopped属性设置为false，写入配置文件。 当上一次关闭应用，10秒后，系统会将应用的stopped属性设置为true，写入配置文件。 总结:在应用打开或关闭后，系统刷新应用状态到配置文件中会有10秒的延时。