2024年安卓最新熬了3天3夜——深入探究Android应用启动起点，高级测试面试题及答案-CSDN博客

本文链接：https://blog.csdn.net/2401_84563287/article/details/138552848

总结

Android架构学习进阶是一条漫长而艰苦的道路，不能靠一时激情，更不是熬几天几夜就能学好的，必须养成平时努力学习的习惯。所以：贵在坚持！

上面分享的字节跳动公司2020年的面试真题解析大全，笔者还把一线互联网企业主流面试技术要点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节。

就先写到这，码字不易，写的很片面不好之处敬请指出，如果觉得有参考价值的朋友也可以关注一下我

①「Android面试真题解析大全」PDF完整高清版+②「Android面试知识体系」学习思维导图压缩包阅读下载，最后觉得有帮助、有需要的朋友可以点个赞

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

从代码可知，此处有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 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从睡梦中醒来，开始创建进程，细节不赘述了，感兴趣的童鞋可以搜下相关资料，在网上有很多教程。