深入探究Android应用启动起点

背景

开发者文档中提到,Android应用有三种启动状态,每种状态都会影响应用向用户显示所需的时间:冷启动、温启动或热启动。三种启动状态中,冷启动耗时最久,系统和App有较多初始化的工作。如果启动时间过长,可能会导致用户在应用商店打低分,甚至完全弃用app,所以冷启动速度是各个app非常重要的性能指标之一。

在冷启动速度优化的工作中,打点是非常重要的一环,统计点位该如何选,以及为什么要这么选,有很多细节值得探究,本文主要深入探究Android端app层如何选择进程创建的起点。

三个时机简述

本文中涉及的3个App层进程创建时间的起点:Application ,Process.getStartElapsedRealTime,/proc/self/stats starttime。

简单介绍下3个进程创建时间起点:

  • Application :Application构造方法;
  • Process.getStartElapsedRealTime:Framework中记录的进程创建的起点,此接口有版本限制,Android N以下版本无法使用;
  • /proc/self/stats starttime:内核中记录的进程创建的起点。

3个进程创建时间起点时序如下:/proc/self/stats starttime 早于 Process.getStartElapsedRealTime 早于 Application

这三个时机哪个更好?哪个能指导优化工作?哪个更接近用户点击桌面创建进程的起始点?带着几个问题,继续往下看。

深入分析

详细看下三个时机:

  • Application **时机**

Applciation的构造方法,Android Java代码可以最先埋点的时机,Android开发童鞋对此时机都会比较熟悉,不过多赘述。

  • Process.getStartElapsedRealTime**时机**

    时序总览图:

Process.getStartElapsedRealTime的赋值接口为handleBindApplication接口,赋值时机为App进程进入Java世界后,进程attach到ActivityManagerService,再通过binder call返回到App进程时。原理细节可继续阅读源码解析。

源码解析:

Android 8.1.0的源码中一段说明(Process.java):
487    /**
488     * Return the {@link SystemClock#elapsedRealtime()} at which this process was started.
489     */
490    public static final long getStartElapsedRealtime() {
491        return sStartElapsedRealtime;
492    }

从源码的说明中可知,Process.getStartElapsedRealTime代表程序创建开始的时间,
SystemClock#elapsedRealtime表示距离boot的真实时间,看下其赋值时机(ActivityThread.java):
5429    private void handleBindApplication(AppBindData data) {...
5436        // Note when this process has started.
5437        Process.setStartTimes(SystemClock.elapsedRealtime(), SystemClock.uptimeMillis());

handleBindApplication是在ActivityThread主线程H的消息处理中被调用的,
H作为ActivityThread的内部类,是主线程处理消息的Handler。
234    final H mH = new H();

 这个消息是谁发的,什么时候发的呢?了解Android App的入口函数及创建过程的同学,可能不难解答这个问题。
App的创建,Java层调用的入口为ActivityThread main方法,看下:
6459    public static void main(String[] args) {...
6478        Looper.prepareMainLooper();
6479
6480        ActivityThread thread = new ActivityThread();
6481        thread.attach(false);...
6494        Looper.loop();

 从代码中看,main方法中主要是准备主线程消息Looper,执行ActivityThread attach方法,然后主线程开始消息循环。
看下ActivityThread attach:
6315    private void attach(boolean system) {
6318        if (!system) {
6328            final IActivityManager mgr = ActivityManager.getService();
6329            try {
6330                mgr.attachApplication(mAppThread);
6331            } catch (RemoteException ex) {
6332                throw ex.rethrowFromSystemServer();
6333            }

 从代码可知,此处有binder调用,调用AMS的attachApplication,此调用是在system_server进程,执行如下操作。
看下ActivityManagerService处理过程:
7215    public final void attachApplication(IApplicationThread thread) {
7216        synchronized (this) {
7219            attachApplicationLocked(thread, callingPid);
7221        }
7222    }
6911    private final boolean attachApplicationLocked(IApplicationThread thread,
6912            int pid) {…
7102                thread.bindApplication(processName, appInfo, providers,
7103                        app.instr.mClass,
7104                        profilerInfo, app.instr.mArguments,
7105                        app.instr.mWatcher,
7106                        app.instr.mUiAutomationConnection, testMode,
7107                        mBinderTransactionTrackingEnabled, enableTrackAllocation,
7108                        isRestrictedBackupMode || !normalMode, app.persistent,
7109                        new Configuration(getGlobalConfiguration()), app.compat,
7110                        getCommonServicesLocked(app.isolated),
7111                        mCoreSettingsObserver.getCoreSettingsLocked(),
7112                        buildSerial);

 比较关键的调用:thread.bindApplication, thread是Binder对象,这个地方又有binder调用,看看执行者:
690    private class ApplicationThread extends IApplicationThread.Stub {
899        public final void bindApplication(String processName, ApplicationInfo appInfo,
900                List<ProviderInfo> providers, ComponentName instrumentationName,
901                ProfilerInfo profilerInfo, Bundle instrumentationArgs,
902                IInstrumentationWatcher instrumentationWatcher,
903                IUiAutomationConnection instrumentationUiConnection, int debugMode,
904                boolean enableBinderTracking, boolean trackAllocation,
905                boolean isRestrictedBackupMode, boolean persistent, Configuration config,
906                CompatibilityInfo compatInfo, Map services, Bundle coreSettings,
907                String buildSerial)
A 
pplicationThread执行sendMessage(H.BIND_APPLICATION, data);

将消息发送出去,此部分的执行为App进程的binder线程池里,是如何切换至主线程执行的呢?
2605    private void sendMessage(int what, Object obj, int arg1, int arg2, boolean async) {
2609        Message msg = Message.obtain();...
2617        mH.sendMessage(msg);
2618    }  

 通过mH,将消息发送到主线程的Looper,主线程执行,
1462    private class H extends Handler {
1473        public static final int BIND_APPLICATION = 110;
1580        public void handleMessage(Message msg) {
1653                case BIND_APPLICATION:
1656                    handleBindApplication(data);
1658                    break;

handleBindApplication就是Process.getStartElapsedRealTime获取对进程创建的起点,后续逻辑就是Application的初始化的工作,由此可见Process.getStartElapsedRealTime时机是比Application时机早,在Application构造方法中打断点情况如下:

/proc/self/stats starttime时机

/proc/self/stats starttime时机是kernel层记录的进程创建起点,为3个时机中最早的。详细看下:

proc/pid/stat用于获取某一个进程的统计信息,内容形式如下:

在proc/pid/stat统计信息中,starttime为第22个元素。starttime的值什么含义,以及是如何计算出来的呢?看下fs/proc/array.c的do_task_stat()

从内核代码中可知:start_time取值为task的real_start_time,先看下nesc_to_clock_t方法:

div_u64_rem方法为无符号除法操作:除数是无符号64bit,被除数是无符号32,remainder为余数。

从计算过程来看,是把real_start_time除以1000000000/100=10000000,real_start_time单位是什么呢?看下数据结构task_struct定义:

    struct timespec start_time;      
    struct timespec real_start_time;

task_struct中有两个时间:start_time 和 real_start_time,其中后者包含睡眠时间,两个时间单位均为ns,/proc/self/stats starttime取的值为real_start_time:

struct timespec
{
__time_t tv_sec;        /* Seconds. */
long   tv_nsec;       /* Nanoseconds. */
};

由此可见,real_start_time单位为ns,如果将real_start_time除以1000000000/100=10000000,换算完单位为10ms,比如/proc/self/stats starttime读取到的值为100,则需换算为100*10ms=1000ms。而我们启动速度日常大概率会以ms为计算精度,/proc/self/stats starttime会损失一定的精度,内核为何会做此种处理呢?

在内核的时间统计方式中,有个单位为jiffies,jiffies是内核中的一个全局变量,用来记录自系统启动以来产生的节拍数。简单描述就是1s内,内核发起的时钟中断次数,kernel中就使用这个来对程序的运行时间进行统计。而/proc/self/stats starttime统计单位正是jiffies,代表应用程序冷启动后经过了多少个内核时钟。

那我们该如何科学的统计以及换算/proc/self/stats starttime的值呢?Linux 系统上Man proc有下面一段解释:

(22) starttime %llu

The time the process started after system boot. In kernels before Linux 2.6, this value was expressed in jiffies. Since Linux 2.6, the value is expressed in clock ticks (divide by sysconf(_SC_CLK_TCK)).

The format for this field was %lu before Linux 2.6.

在内核态的常量USER_HZ我们无法获取,但可以通过在用户态通过sysconf(_SC_CLK_TCK)获取到其值。

计算公式如下:

/proc/self/stats starttime * 1000 / sysconf(_SC_CLK_TCK),单位ms

可能有些同学会说,sysconf(_SC_CLK_TCK)的值是100,直接用/proc/self/stats starttime * 10即可,但需考虑内核的升级或内核定制场景,使用sysconf(_SC_CLK_TCK)获取并参与计算为最稳妥的方式。

再一个问题,/proc/self/stats starttime 是来自task_struct real_start_time,这个时间初始化是在什么时候呢?答案就是task_struct数据结构被创建的时候,也就是进程被创建的时候,即 zygote fork时机,fork系统调用会把子进程的数据结构task_struct、线程栈等数据结构初始化,感兴趣的同学可以去看内核的fork源码。

总结

通过上述的详细分析,已经对三个时机有较为详细的了解。在实际App工程中,建议结合使用Application 时机和/proc/self/stats starttime时机作为应用程序启动的起点。

  • Application 时机是Android Java代码可以最先埋点的地方,通过此起点,再结合冷启动的结束点位,可明确知晓工程代码的详细耗时,对于指导日常优化工作有较大意义;

  • /proc/self/stats starttime时机为三个时机中最早的,其中有工程代码不可控的耗时,涉及到进程数据结构、线程栈等初始化工作,但是此时机会更接近用户的实际感受,可以最大程度用来衡量用户启动体验;

  • Process.getStartElapsedRealTime由于有版本的限制,在Android N以下版本无法获取,无法兼顾大盘所有的用户机器,此值的指导价值就没那么大,优化工作中,重中之重是优化中低端机器的性能体验,如果Android N以下机型无法获取,则会有大量的低端机器的启动性能不在统计范围内。

  • 可能有的童鞋还会有一个疑问,为什么说/proc/self/stats starttime更接近用户的实际启动体验,而不是用户的全部启动体验呢?熟悉应用程序启动过程的同学就会比较了解这个问题,Android应用程序启动是从用户点击桌面图标开始,点击图标的第一响应是在Launcher进程,通过ActivityManagerService将创建进程信息传给zygote,zygote再执行fork,中间经历了两次跨进程通信,一次是Launcher进程通过Binder调用进入system_server进程,一次是system_server进程通过socket将创建进程信息传给zygote,zygote从睡梦中醒来,开始创建进程,细节不赘述了,感兴趣的童鞋可以搜下相关资料,在网上有很多教程。


https://mp.weixin.qq.com/s/P-I43_71iwutjbLASUZx8A

Android 深色模式适配原理分析

从Android10(API 29)开始,在原有的主题适配的基础上,Google开始提供了Force Dark机制,在系统底层直接对颜色和图片进行转换处理,原生支持深色模式。深色模式可以节省电量、改善弱势及强光敏感用户的可视性,并能在环境亮度较暗的时候保护视力,更是夜间活跃用户的强烈需求。对深色模式的适配有利于提升用户口碑。

发布于:7天以前  |  93次阅读  |  详细内容 »

百度APP-Android H5首屏优化实践

百度App自2016年上半年尝试Feed流业务形态,至2017年下半年,历经10个版本的迭代,基本完成了产品形态的初步探索。在整个Feed流形态的闭环中,新闻详情页(文中称为落地页)作为重要的组成部分,如果打开页面后,loading时间过长,会严重影响用户体验。因此我们针对落地页这种H5的首屏展现速度进行了长期优化,本文会详细阐述整个优化思路和技术细节

发布于:16天以前  |  138次阅读  |  详细内容 »

Android 10分区存储介绍及百度APP适配实践

Google于 2019年9月3日发布了Android10 release版本,为了更好的保护用户数据并限制设备冗余文件增加,Android 10版本变更了设备外部存储访问方式,外部存储新特性称为分区存储(Scoped Storage), 分区存储遵循以下三个原则对外部存储文件访问方式重新设计,便于用户更好的管理外部存储文件

发布于:17天以前  |  143次阅读  |  详细内容 »

深入探究Android应用启动起点

开发者文档中提到,Android应用有三种启动状态,每种状态都会影响应用向用户显示所需的时间:冷启动、温启动或热启动。三种启动状态中,冷启动耗时最久,系统和App有较多初始化的工作。如果启动时间过长,可能会导致用户在应用商店打低分,甚至完全弃用app,所以冷启动速度是各个app非常重要的性能指标之一。

发布于:17天以前  |  142次阅读  |  详细内容 »

一文搞懂Android JetPack组件原理之Lifecycle、LiveData、ViewModel与源码分析技巧

Lifecycle、LiveData和ViewModel作为AAC架构的核心,常常被用在Android业务架构中。在京东商城Android应用中,为了事件传递等个性化需求,比如ViewModel间通信、ViewModel访问Activity等等,以及为了架构的扩展性,我们封装了BaseLiveData和BaseViewModel等基础组件,也对Activity、Fragement和ViewHolder进行了封装,以JDLifecycleBaseActivity、LifecycleBaseFragment和LifecycleBaseViewHolder等组件强化了View层功能,构建出了各业务线统一规范架构的基石。

发布于:28天以前  |  155次阅读  |  详细内容 »

Android 记一次解决问题的过程

之前我写过一篇文章,介绍我在GitHub开源的滑动控件 ConsecutiveScroller 是如何实现布局吸顶功能的。有兴趣的朋友可以去看一下:Android滑动布局ConsecutiveScrollerLayout实现布局吸顶功能。

发布于:1月以前  |  227次阅读  |  详细内容 »

Android内存异常机制(用户空间)_NE

常见的Android稳定性异常,有内核异常和Android层异常。内核异常也就是常说的“kernel panic”,简称KE异常;Android层异常又分为java层crash和Native层crash,简称JE、NE异常。 上篇文章介绍了JE异常的抓取机制和处理方式,本文再讲一下NE异常。

发布于:2月以前  |  533次阅读  |  详细内容 »

Android-模块化-面向接口编程

随着业务的发展,工程的逐渐增大与开发人员增多,很多工程都走向了模块化、组件化、插件化道路,来方便大家的合作开发与降低业务之间的耦合度。现在就和大家谈谈模块化的交互问题,首先看下模块化的几个优势。

发布于:2月以前  |  839次阅读  |  详细内容 »

Android SurfaceView 播放gif

Android SurfaceView 是Android系统中的高级组件,它有自己的绘制界面,可以在一个独立的线程进行UI的绘制, 因此不会阻塞主线程,这也是我们使用SuefaceView播放gif图片的原因。

发布于:3月以前  |  633次阅读  |  详细内容 »

Android Studio 生成so文件 及调用

so文件是C、C++的函数库,在Android中 调用这些库,使用的是JNI( Java Native interface) JNI 可以使Java程序调用本地程序或者库(一般是使用C、C++ 或者汇编语言编写)。 这篇文章 会介绍 使用Android Studio 如何生成so文件,及如何使用so

发布于:3月以前  |  838次阅读  |  详细内容 »

Android 保活从入门到放弃:乖乖引导用户加白名单吧(附7大机型加白示例)

IM在Android上的保活问题经常在即时通讯网的论坛和技术群里被讨论,自从Android 8.0后系统大大降低了后台运行应用的保活容忍度(详见《Android P正式版即将到来:后台应用保活、消息推送的真正噩梦》),保活从黑科技横行的时代进入了技术蛮荒阶段,真要实现保活,技术难度越来越大。

发布于:3月以前  |  841次阅读  |  详细内容 »

安居客 Android APP 走向平台化 | 开发者说·DTalk

安居客 Android App 距离上次的模块化/组件化重构已经两年多了,重构之后很好的支撑了两年多以来的业务发展。但这个世界总是在向前走的,没有任何一种架构能够一劳永逸的解决所有问题,外部环境的不断变化相应的也要求项目架构做出改变,以此来应对环境变化所带来的挑战。

发布于:3月以前  |  620次阅读  |  详细内容 »

Android View 体系竟然还能这么理解?

很多小伙伴可能在学习view的绘制流程源码的时候有点抓不住重点,所以在分析代码的时候绕来绕去脑袋晕乎乎的。今天我就来给大家化繁为简,只关注它最核心的东西。

发布于:3月以前  |  806次阅读  |  详细内容 »

移动端常见崩溃指标

崩溃分析,是将 Android 和 iOS 平台常见的 APP 崩溃问题进行归类分析,帮助企业根据崩溃指标快速发现、定位问题。

发布于:3月以前  |  824次阅读  |  详细内容 »

最多阅读

简化Android的UI开发 11月以前  |  289992次阅读
Android设计与开发工作流 11月以前  |  2818次阅读
Google Enjarify:可代替dex2jar的dex反编译 1年以前  |  2703次阅读
30分钟搭建一个android的私有Maven仓库 1年以前  |  2470次阅读
Android多渠道打包工具:apptools 1年以前  |  2263次阅读
Google Java编程风格规范(中文版) 1年以前  |  2257次阅读
Android UI基本技术点 1年以前  |  2225次阅读
Android权限 - 第一篇 1年以前  |  2190次阅读
Stetho 1年以前  |  2113次阅读
2015 Google IO带来的新 Android 开发工具 1年以前  |  2004次阅读
你应该知道的布局和属性 1年以前  |  1978次阅读
MVP在Android平台上的应用 1年以前  |  1952次阅读
听FackBook工程师讲*Custom ViewGroups* 1年以前  |  1950次阅读
Gradle小知识#3:任务的顺序 1年以前  |  1922次阅读