}
…
// mPausingActivity 在前面已经赋值,就是当前 Activity
if (mPausingActivity != null) {
…
if (pauseImmediately) { // 这里是 false,进入 else 分支
completePauseLocked(false, resuming);
return false;
} else {
// 2. 发送一个延时 500ms 的消息,等待 pause 流程一点时间
// 最终会回调 activityPausedLocked() 方法
schedulePauseTimeout(prev);
return true;
}
} else {
// 不会进入此分支
}
}
这里面有两步重点操作。第一步是注释 1 处通过 ClientLifecycleManager 分发生命周期流程。第二步是发送一个延时 500ms 的消息,等待一下 onPause 流程。但是如果第一步中在 500ms 内已经完成了流程,则会取消这个消息。所以这两步的最终逻辑其实是一致的。这里就直接看第一步。
mService.getLifecycleManager().scheduleTransaction(prev.app.thread, prev.appToken,
PauseActivityItem.obtain(prev.finishing, userLeaving,
prev.configChangeFlags, pauseImmediately));
ClientLifecycleManager
它会向主线程的 Handler H 发送 EXECUTE_TRANSACTION 事件,调用 XXXActivityItem
的 execute()
和 postExecute()
方法。execute()
方法中会 Binder 调用 ActivityThread
中对应的 handleXXXActivity()
方法。在这里就是 handlePauseActivity()
方法,其中会通过 Instrumentation.callActivityOnPause(r.activity)
方法回调 Activity.onPause()
。
Instrumentation.java
public void callActivityOnPause(Activity activity) {
activity.performPause();
}
到这里,onPause()
方法就被执行了。但是流程没有结束,接着就该显示下一个 Activity 了。前面刚刚说过会调用 PauseActivityItem
的 execute()
和 postExecute()
方法。execute()
方法回调了当前 Activity.onPause()
,而 postExecute()
方法就是去寻找要显示的 Activity 。
PauseActivityItem.java
public void postExecute(ClientTransactionHandler client, IBinder token,
PendingTransactionActions pendingActions) {
try {
ActivityManager.getService().activityPaused(token);
} catch (RemoteException ex) {
throw ex.rethrowFromSystemServer();
}
}
Binder 调用了 AMS.activityPaused()
方法。
ActivityManagerService.java
public final void activityPaused(IBinder token) {
synchronized(this) {
ActivityStack stack = ActivityRecord.getStackLocked(token);
if (stack != null) {
stack.activityPausedLocked(token, false);
}
}
}
调用了 ActivityStack.activityPausedLocked()
方法。
ActivityStack.java
final void activityPausedLocked(IBinder token, boolean timeout) {
final ActivityRecord r = isInStackLocked(token);
if (r != null) {
// 看这里
mHandler.removeMessages(PAUSE_TIMEOUT_MSG, r);
if (mPausingActivity == r) {
mService.mWindowManager.deferSurfaceLayout();
try {
// 看这里
completePauseLocked(true /* resumeNext /, null / resumingActivity */);
} finally {
mService.mWindowManager.continueSurfaceLayout();
}
return;
} else {
// 不会进入 else 分支
}
}
}
上面有这么一行代码 mHandler.removeMessages(PAUSE_TIMEOUT_MSG, r)
,移除的就是之前延迟 500ms 的消息。接着看 completePauseLocked()
方法。
ActivityStack.java
private void completePauseLocked(boolean resumeNext, ActivityRecord resuming) {
ActivityRecord prev = mPausingActivity;
if (prev != null) {
// 设置状态为 PAUSED
prev.setState(PAUSED, “completePausedLocked”);
if (prev.finishing) { // 1. finishing 为 true,进入此分支
prev = finishCurrentActivityLocked(prev, FINISH_AFTER_VISIBLE, false,
“completedPausedLocked”);
} else if (prev.app != null) {
// 不会进入此分支
} else {
prev = null;
}
…
}
if (resumeNext) {
// 当前获取焦点的 ActivityStack
final ActivityStack topStack = mStackSupervisor.getFocusedStack();
if (!topStack.shouldSleepOrShutDownActivities()) {
// 2. 恢复要显示的 activity
mStackSupervisor.resumeFocusedStackTopActivityLocked(topStack, prev, null);
} else {
checkReadyForSleep();
ActivityRecord top = topStack.topRunningActivityLocked();
if (top == null || (prev != null && top != prev)) {
mStackSupervisor.resumeFocusedStackTopActivityLocked();
}
}
}
…
}
这里分了两步走。注释1 处判断了 finishing
状态,还记得 finishing 在何处被赋值为 true
的吗?在 Activity.finish() -> AMS.finishActivity() -> ActivityStack.requestFinishActivityLocked() -> ActivityStack.finishActivityLocked()
方法中。所以接着调用的是 finishCurrentActivityLocked()
方法。注释2 处就是来显示应该显示的 Activity ,就不再追进去细看了。
再跟到 finishCurrentActivityLocked()
方法中,看这名字,肯定是要 stop/destroy 没跑了。
ActivityStack.java
/*
-
把前面带过来的参数标出来
-
prev, FINISH_AFTER_VISIBLE, false,“completedPausedLocked”
*/
final ActivityRecord finishCurrentActivityLocked(ActivityRecord r, int mode, boolean oomAdj,
String reason) {
// 获取将要显示的栈顶 Activity
final ActivityRecord next = mStackSupervisor.topRunningActivityLocked(
true /* considerKeyguardState */);
// 1. mode 是 FINISH_AFTER_VISIBLE,进入此分支
if (mode == FINISH_AFTER_VISIBLE && (r.visible || r.nowVisible)
&& next != null && !next.nowVisible) {
if (!mStackSupervisor.mStoppingActivities.contains®) {
// 加入到 mStackSupervisor.mStoppingActivities
addToStopping(r, false /* scheduleIdle /, false / idleDelayed */);
}
// 设置状态为 STOPPING
r.setState(STOPPING, “finishCurrentActivityLocked”);
return r;
}
…
// 下面会执行 destroy,但是代码并不能执行到这里
if (mode == FINISH_IMMEDIATELY
|| (prevState == PAUSED
&& (mode == FINISH_AFTER_PAUSE || inPinnedWindowingMode()))
|| finishingActivityInNonFocusedStack
|| prevState == STOPPING
|| prevState == STOPPED
|| prevState == ActivityState.INITIALIZING) {
boolean activityRemoved = destroyActivityLocked(r, true, “finish-imm:” + reason);
…
return activityRemoved ? null : r;
}
…
}
注释 1 处 mode
的值是 FINISH_AFTER_VISIBLE
,并且现在新的 Activity 还没有 onResume
,所以 r.visible || r.nowVisible
和 next != null && !next.nowVisible
都是成立的,并不会进入后面的 destroy 流程。虽然看到这还没得到想要的答案,但是起码是符合预期的。如果在这就直接 destroy 了,延迟 10s 才 onDestroy 的问题就无疾而终了。
对于这些暂时还不销毁的 Activity 都执行了 addToStopping(r, false, false)
方法。我们继续追进去。
ActivityStack.java
void addToStopping(ActivityRecord r, boolean scheduleIdle, boolean idleDelayed) {
if (!mStackSupervisor.mStoppingActivities.contains®) {
mStackSupervisor.mStoppingActivities.add®;
…
}
…
// 省略的代码中,对 mStoppingActivities 的存储容量做了限制。超出限制可能会提前出发销毁流程
}
这些在等待销毁的 Activity 被保存在了 ActivityStackSupervisor
的 mStoppingActivities
集合中,它是一个 ArrayList<ActivityRecord>
。
整个 finish 流程就到此为止了。前一个 Activity 被保存在了 ActivityStackSupervisor.mStoppingActivities
集合中,新的 Activity 被显示出来了。
问题似乎进入了困境,什么时候回调 onStop/onDestroy
呢?其实这个才是根本问题。上面撸了一遍 finish() 并看不到本质,但是可以帮助我们形成一个完整的流程,这个一直是看 AOSP 最大的意义,帮助我们把零碎的上层知识形成一个完整的闭环。
回到正题来,在 Activity 跳转过程中,为了保证流畅的用户体验,只要前一个 Activity 与用户不可交互,即 onPause() 被回调之后,下一个 Activity 就要开始自己的生命周期流程了。所以 onStop/onDestroy
的调用时间是不确定的,甚至像文章开头的例子中,整整过了 10s 才回调。那么,到底是由谁来驱动 onStop/onDestroy
的执行呢?我们来看看下一个 Activity 的 onResume 过程。
直接看 ActivityThread.handleResumeActivity()
方法,相信大家对生命周期的调用流程也很熟悉了。
ActivityThread.java
public void handleResumeActivity(IBinder token, boolean finalStateRequest, boolean isForward,
String reason) {
…
// 回调 onResume
final ActivityClientRecord r = performResumeActivity(token, finalStateRequest, reason);
…
final Activity a = r.activity;
…
if (r.window == null && !a.mFinished && willBeVisible) {
…
if (a.mVisibleFromClient) {
if (!a.mWindowAdded) {
a.mWindowAdded = true;
// 添加 decorView 到 WindowManager
wm.addView(decor, l);
} else {
a.onWindowAttributesChanged(l);
}
}
} else if (!willBeVisible) {
…
}
…
// 主线程空闲时会执行 Idler
Looper.myQueue().addIdleHandler(new Idler());
}
handleResumeActivity()
方法是整个 UI 显示流程的重中之重,它首先会回调 Activity.onResume()
, 然后将 DecorView 添加到 Window 上,其中又包括了创建 ViewRootImpl,创建 Choreographer,与 WMS 进行 Binder 通信,注册 vsync 信号,著名的 measure/draw/layout。这一块的源码真的很值得一读,不过不是这篇文章的重点,后面会单独来捋一捋。
在完成最终的界面绘制和显示之后,有这么一句代码 Looper.myQueue().addIdleHandler(new Idler())
。IdleHandler
不知道大家是否熟悉,它提供了一种机制,当主线程消息队列空闲时,会执行 IdleHandler 的回调方法。至于怎么算 “空闲”,我们可以看一下 MessageQueue.next()
方法。
MessageQueue.java
Message next() {
…
int pendingIdleHandlerCount = -1;
int nextPollTimeoutMillis = 0;
for (;😉 {
// 阻塞方法,主要是通过 native 层的 epoll 监听文件描述符的写入事件来实现的。
// 如果 nextPollTimeoutMillis = -1,一直阻塞不会超时。
// 如果 nextPollTimeoutMillis = 0,不会阻塞,立即返回。
// 如果 nextPollTimeoutMillis > 0,最长阻塞nextPollTimeoutMillis毫秒(超时),如果期间有程序唤醒会立即返回。
nativePollOnce(ptr, nextPollTimeoutMillis);
synchronized (this) {
Message prevMsg = null;
Message msg = mMessages;
if (msg != null && msg.target == null) {
// msg.target == null表示此消息为消息屏障(通过postSyncBarrier方法发送来的)
// 如果发现了一个消息屏障,会循环找出第一个异步消息(如果有异步消息的话),所有同步消息都将忽略(平常发送的一般都是同步消息)
do {
prevMsg = msg;
msg = msg.next;
} while (msg != null && !msg.isAsynchronous());
}
if (msg != null) {
if (now < msg.when) {
// 消息触发时间未到,设置下一次轮询的超时时间
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
} else {
// 得到 Message
mBlocked = false;
if (prevMsg != null) {
prevMsg.next = msg.next;
} else {
mMessages = msg.next;
}
msg.next = null;
msg.markInUse(); // 标记 FLAG_IN_USE
return msg;
}
} else {
nextPollTimeoutMillis = -1;
}
…
/*
-
两个条件:
-
1. pendingIdleHandlerCount = -1
-
2. 此次取到的 mMessage 为空或者需要延迟处理
*/
if (pendingIdleHandlerCount < 0
&& (mMessages == null || now < mMessages.when)) {
pendingIdleHandlerCount = mIdleHandlers.size();
}
if (pendingIdleHandlerCount <= 0) {
// 没有 idle handler 需要运行,继续循环
mBlocked = true;
continue;
}
if (mPendingIdleHandlers == null) {
mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
}
mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
}
// 下一次 next 时,pendingIdleHandlerCount 又会被置为 -1,不会导致死循环
for (int i = 0; i < pendingIdleHandlerCount; i++) {
final IdleHandler idler = mPendingIdleHandlers[i];
mPendingIdleHandlers[i] = null; // release the reference to the handler
boolean keep = false;
try {
// 执行 Idler
keep = idler.queueIdle();
} catch (Throwable t) {
Log.wtf(TAG, “IdleHandler threw exception”, t);
}
if (!keep) {
synchronized (this) {
mIdleHandlers.remove(idler);
}
}
}
// 将 pendingIdleHandlerCount 置零
pendingIdleHandlerCount = 0;
nextPollTimeoutMillis = 0;
}
}
在正常的消息处理机制之后,额外对 IdleHandler 进行了处理。当本次取到的 Message 为空或者需要延时处理的时候,就会去执行 mIdleHandlers
数组中的 IdleHandler 对象。其中还有一些关于 pendingIdleHandlerCount 的额外逻辑来防止循环处理。
所以,不出意外的话,当新的 Activity 完成页面绘制并显示之后,主线程就可以停下歇一歇,来执行 IdleHandler
了。再回来 handleResumeActivity()
中来,Looper.myQueue().addIdleHandler(new Idler())
,这里的 Idler
是 IdleHandler
的一个具体实现类。
ActivityThread.java
private class Idler implements MessageQueue.IdleHandler {
@Override
public final boolean queueIdle() {
ActivityClientRecord a = mNewActivities;
…
}
if (a != null) {
mNewActivities = null;
IActivityManager am = ActivityManager.getService();
ActivityClientRecord prev;
do {
if (a.activity != null && !a.activity.mFinished) {
try {
// 调用 AMS.activityIdle()
am.activityIdle(a.token, a.createdConfig, stopProfiling);
a.createdConfig = null;
} catch (RemoteException ex) {
throw ex.rethrowFromSystemServer();
}
}
prev = a;
a = a.nextIdle;
prev.nextIdle = null;
} while (a != null);
}
…
return false;
}
}
Binder 调用了 AMS.activityIdle()
。
ActivityManagerService.java
public final void activityIdle(IBinder token, Configuration config, boolean stopProfiling) {
final long origId = Binder.clearCallingIdentity();
synchronized (this) {
ActivityStack stack = ActivityRecord.getStackLocked(token);
if (stack != null) {
ActivityRecord r =
mStackSupervisor.activityIdleInternalLocked(token, false /* fromTimeout */,
false /* processPausingActivities */, config);
…
}
}
}
调用了 ActivityStackSupervisor.activityIdleInternalLocked()
方法。
ActivityStackSupervisor.java
final ActivityRecord activityIdleInternalLocked(final IBinder token, boolean fromTimeout,
boolean processPausingActivities, Configuration config) {
ArrayList finishes = null;
ArrayList startingUsers = null;
int NS = 0;
int NF = 0;
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数Android工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Android移动开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Android开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录大纲截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且后续会持续更新
如果你觉得这些内容对你有帮助,可以添加V获取:vip204888 (备注Android)
最后
今天关于面试的分享就到这里,还是那句话,有些东西你不仅要懂,而且要能够很好地表达出来,能够让面试官认可你的理解,例如Handler机制,这个是面试必问之题。有些晦涩的点,或许它只活在面试当中,实际工作当中你压根不会用到它,但是你要知道它是什么东西。
最后在这里小编分享一份自己收录整理上述技术体系图相关的几十套腾讯、头条、阿里、美团等公司2021年的面试题,把技术点整理成了视频和PDF(实际上比预期多花了不少精力),包含知识脉络 + 诸多细节,由于篇幅有限,这里以图片的形式给大家展示一部分。
还有 高级架构技术进阶脑图、Android开发面试专题资料,高级进阶架构资料 帮助大家学习提升进阶,也节省大家在网上搜索资料的时间来学习,也可以分享给身边好友一起学习。
【算法合集】
【延伸Android必备知识点】
【Android部分高级架构视频学习资源】
**Android精讲视频领取学习后更加是如虎添翼!**进军BATJ大厂等(备战)!现在都说互联网寒冬,其实无非就是你上错了车,且穿的少(技能),要是你上对车,自身技术能力够强,公司换掉的代价大,怎么可能会被裁掉,都是淘汰末端的业务Curd而已!现如今市场上初级程序员泛滥,这套教程针对Android开发工程师1-6年的人员、正处于瓶颈期,想要年后突破自己涨薪的,进阶Android中高级、架构师对你更是如鱼得水,赶快领取吧!
一个人可以走的很快,但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎扫码加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
仅要懂,而且要能够很好地表达出来,能够让面试官认可你的理解,例如Handler机制,这个是面试必问之题。有些晦涩的点,或许它只活在面试当中,实际工作当中你压根不会用到它,但是你要知道它是什么东西。
最后在这里小编分享一份自己收录整理上述技术体系图相关的几十套腾讯、头条、阿里、美团等公司2021年的面试题,把技术点整理成了视频和PDF(实际上比预期多花了不少精力),包含知识脉络 + 诸多细节,由于篇幅有限,这里以图片的形式给大家展示一部分。
还有 高级架构技术进阶脑图、Android开发面试专题资料,高级进阶架构资料 帮助大家学习提升进阶,也节省大家在网上搜索资料的时间来学习,也可以分享给身边好友一起学习。
[外链图片转存中…(img-3xG1EW7L-1712777274048)]
【算法合集】
[外链图片转存中…(img-zwtyd1pY-1712777274048)]
【延伸Android必备知识点】
[外链图片转存中…(img-KF5T9w7j-1712777274049)]
【Android部分高级架构视频学习资源】
**Android精讲视频领取学习后更加是如虎添翼!**进军BATJ大厂等(备战)!现在都说互联网寒冬,其实无非就是你上错了车,且穿的少(技能),要是你上对车,自身技术能力够强,公司换掉的代价大,怎么可能会被裁掉,都是淘汰末端的业务Curd而已!现如今市场上初级程序员泛滥,这套教程针对Android开发工程师1-6年的人员、正处于瓶颈期,想要年后突破自己涨薪的,进阶Android中高级、架构师对你更是如鱼得水,赶快领取吧!
一个人可以走的很快,但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎扫码加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
[外链图片转存中…(img-UJbc6Xi5-1712777274049)]