区块链技术博客
www.b2bchain.cn

Activity.finish() 之后 10s 才 onDestroy ?求职学习资料

本文介绍了Activity.finish() 之后 10s 才 onDestroy ?求职学习资料,有助于帮助完成毕业设计以及求职,是一篇很好的资料。

对技术面试,学习经验等有一些体会,在此分享。

Android 复习笔记目录

  1. 唠唠任务栈,返回栈和生命周期
  2. 唠唠 Activity 的生命周期
  3. 扒一扒 Context
  4. 为什么不能使用 Application Context 显示 Dialog?
  5. OOM 可以被 try catch 吗?
  6. Activity.finish() 之后十秒才回调 onDestroy ?

本文永久更新地址: https://xiaozhuanlan.com/topic/2916834507

目录

  • 没有及时回调的 onStop/onDestroy
  • 从 Activity.finish() 说起
  • 是谁指挥着 onStop/onDestroy 的调用?
  • 谁让 onStop/onDestroy 延迟了 10s ?

没有及时回调的 onStop/onDestroy

交流群里碰到一个很有意思的问题,调用 Activity.finish() 之后 10s 才回调 onDestroy() 。 由此产生了一些不可控问题,例如在 onDestroy() 中释放资源不及时,赋值状态异常等等。我之前倒没有遇到过类似的问题,但是 AOSP 总是我们最好的老师。从 Activity.finish() 开始撸了一遍流程,找到了问题的答案。

在读源码之前,我们先来复现一下 10s onDestroy 的场景。写一个最简单的 FirstActivity 跳转到 SecondActivity 的场景,并记录下各个生命周期和调用 finish() 的时间间隔。

class FirstActivity : BaseLifecycleActivity() {      private val binding by lazy { ActivityFirstBinding.inflate(layoutInflater) }     var startTime = 0L      override fun onCreate(savedInstanceState: Bundle?) {         super.onCreate(savedInstanceState)         setContentView(binding.root)          binding.goToSecond.setOnClickListener {             start<SecondActivity>()             finish()             startTime = System.currentTimeMillis()         }     }      override fun onPause() {         super.onPause()         Log.e("finish","onPause() 距离 finish() :${System.currentTimeMillis() - startTime} ms")     }      override fun onStop() {         super.onStop()         Log.e("finish","onStop() 距离 finish() :${System.currentTimeMillis() - startTime} ms")     }      override fun onDestroy() {         super.onDestroy()         Log.e("finish","onDestroy() 距离 finish() :${System.currentTimeMillis() - startTime} ms")     } }

SecondActivity 是一个普通的没有进行任何操作的空白 Activity 。点击按钮跳转到 SecondActivity,打印日志如下:

FirstActivity: onPause,onPause() 距离 finish() :5 ms SecondActivity: onCreate SecondActivity: onStart SecondActivity: onResume FirstActivity: onStop,onStop() 距离 finish() :660 ms FirstActivity: onDestroy,onDestroy() 距离 finish() :663 ms

可以看到正常情况下,FirstActivity 回调 onPause 之后,SecondActivity 开始正常的生命周期流程,直到 onResume 被回调,对用户可见时,FirstActivity 才会回调 onPause 和 onDestroy 。时间间隔也都在正常范围以内。

我们再模拟一个在 SecondActivity 启动时进行大量动画的场景,源源不断的向主线程消息队列塞消息。修改一下 SecondActivity 的代码。

class SecondActivity : BaseLifecycleActivity() {      private val binding by lazy { ActivitySecondBinding.inflate(layoutInflater) }      override fun onCreate(savedInstanceState: Bundle?) {         super.onCreate(savedInstanceState)         setContentView(binding.root)          postMessage()     }      private fun postMessage() {         binding.secondBt.post {             Thread.sleep(10)             postMessage()         }     } }

再来看一下日志:

FirstActivity: onPause, onPause() 距离 finish() :6 ms SecondActivity: onCreate SecondActivity: onStart SecondActivity: onResume FirstActivity: onStop, onStop() 距离 finish() :10033 ms FirstActivity: onDestroy, onDestroy() 距离 finish() :10037 ms

FirstActivity 的 onPause() 没有受到影响。因为在 Activity 跳转过程中,目标 Activity 只有在前一个 Activity onPause() 之后才会开始正常的生命周期。而 onStoponDestroy() 整整过了 10s 才回调。

对比以上两个场景,我们可以猜测,当 SecondActivity 的主线程过于繁忙,没有机会停下来喘口气的时候,会造成 FirstActivity 无法及时回调 onStoponDestroy 。基于以上猜测,我们就可以从 AOSP 中来寻找答案了。

接下来就是大段的枯燥的源码分析了。带着问题去读 AOSP,可以让这个过程不是那么 “枯燥”,而且一定会有很多不一样的收获。

从 Activity.finish() 说起

以下源代码基于 Android 9.0 版本。

> Activity.java  public void finish() {     finish(DONT_FINISH_TASK_WITH_ACTIVITY); }

重载了带参数的 finish() 方法。参数是 DONT_FINISH_TASK_WITH_ACTIVITY ,含义也很直白,不会销毁 Activity 所在的任务栈。

> Activity.java  private void finish(int finishTask) {     // mParent 一般为 null,在 ActivityGroup 中会使用到     if (mParent == null) {         ......         try {             // Binder 调用 AMS.finishActivity()             if (ActivityManager.getService()                     .finishActivity(mToken, resultCode, resultData, finishTask)) {                 mFinished = true;             }         } catch (RemoteException e) {         }     } else {         mParent.finishFromChild(this);     }     ...... }

这里的 mParent 大多数情况下都是 null ,不需要考虑 else 分支的情况。一些大龄 Android 程序员可能会了解 ActivityGroup,在此种情况下 mParent 可能会不为 null。(因为我还年轻,所以没有使用过 ActivityGroup,就不过多解释了。)其中 Binder 调用了 AMS.finishActivity() 方法。

> ActivityManagerService.java  public final boolean finishActivity(IBinder token, int resultCode, Intent resultData,         int finishTask) {     ......     synchronized(this) {         // token 持有 ActivityRecord 的弱引用         ActivityRecord r = ActivityRecord.isInStackLocked(token);         if (r == null) {             return true;         }         ......         try {             boolean res;             final boolean finishWithRootActivity =                     finishTask == Activity.FINISH_TASK_WITH_ROOT_ACTIVITY;             // finishTask 参数是 DONT_FINISH_TASK_WITH_ACTIVITY,进入 else 分支             if (finishTask == Activity.FINISH_TASK_WITH_ACTIVITY                     || (finishWithRootActivity && r == rootR)) {                 res = mStackSupervisor.removeTaskByIdLocked(tr.taskId, false,                         finishWithRootActivity, "finish-activity");             } else {                 // 调用 ActivityStack.requestFinishActivityLocked()                 res = tr.getStack().requestFinishActivityLocked(token, resultCode,                         resultData, "app-request", true);             }             return res;         } finally {             Binder.restoreCallingIdentity(origId);         }     } }

注意方法参数中的 token 对象,在上一篇文章 为什么不能使用 Application Context 显示 Dialog? 中详细介绍过,Token 是 ActivityRecord 的静态内部类,它持有外部 ActivityRecord 的弱引用。继承自 IApplicationToken.Stub ,是一个 Binder 对象。ActivityRecord 就是对当前 Activity 的具体描述,包含了 Activity 的所有信息。

传入的 finishTask() 方法的参数是 DONT_FINISH_TASK_WITH_ACTIVITY,所以接着会调用 ActivityStack.requestFinishActivityLocked() 方法。

> ActivityStack.java  final boolean requestFinishActivityLocked(IBinder token, int resultCode,         Intent resultData, String reason, boolean oomAdj) {     ActivityRecord r = isInStackLocked(token);     if (r == null) {         return false;     }      finishActivityLocked(r, resultCode, resultData, reason, oomAdj);     return true; }      final boolean finishActivityLocked(ActivityRecord r, int resultCode, Intent resultData,         String reason, boolean oomAdj) {         // PAUSE_IMMEDIATELY 为 true,在 ActivityStackSupervisor 中定义     return finishActivityLocked(r, resultCode, resultData, reason, oomAdj, !PAUSE_IMMEDIATELY); }

最后调用的是一个重载的 finishActivityLocked() 方法。

> ActivityStack.java  // 参数 pauseImmediately 是 false final boolean finishActivityLocked(ActivityRecord r, int resultCode, Intent resultData,         String reason, boolean oomAdj, boolean pauseImmediately) {     if (r.finishing) { // 重复 finish 的情况         return false;     }      mWindowManager.deferSurfaceLayout();     try {         // 标记 r.finishing = true,         // 前面会做重复 finish 的检测就是依赖这个值         r.makeFinishingLocked();         final TaskRecord task = r.getTask();         ......         // 暂停事件分发         r.pauseKeyDispatchingLocked();          adjustFocusedActivityStack(r, "finishActivity");          // 处理 activity result         finishActivityResultsLocked(r, resultCode, resultData);          // mResumedActivity 就是当前 Activity,会进入此分支         if (mResumedActivity == r) {             ......             // Tell window manager to prepare for this one to be removed.             r.setVisibility(false);              if (mPausingActivity == null) {                 // 开始 pause mResumedActivity                 startPausingLocked(false, false, null, pauseImmediately);             }             ......         } else if (!r.isState(PAUSING)) {             // 不会进入此分支             ......         }          return false;     } finally {         mWindowManager.continueSurfaceLayout();     } }

调用 finish 之后肯定是要先 pause 当前 Activity,没毛病。接着看 startPausingLocked() 方法。

> ActivityStack.java      final boolean startPausingLocked(boolean userLeaving, boolean uiSleeping,             ActivityRecord resuming, boolean pauseImmediately) {         ......         ActivityRecord prev = mResumedActivity;          if (prev == null) {             // 没有 onResume 的 Activity,不能执行 pause             if (resuming == null) {                 mStackSupervisor.resumeFocusedStackTopActivityLocked();             }             return false;         }         ......          mPausingActivity = prev;         // 设置当前 Activity 状态为 PAUSING         prev.setState(PAUSING, "startPausingLocked");         ......          if (prev.app != null && prev.app.thread != null) {             try {                 ......                 // 1. 通过 ClientLifecycleManager 分发生命周期事件                 // 最终会向 H 发送 EXECUTE_TRANSACTION 事件                 mService.getLifecycleManager().scheduleTransaction(prev.app.thread, prev.appToken,                         PauseActivityItem.obtain(prev.finishing, userLeaving,                                 prev.configChangeFlags, pauseImmediately));             } catch (Exception e) {                 mPausingActivity = null;             }         } else {             mPausingActivity = null;         }         ......         // 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 我在之前的一篇文章 从源码看 Activity 生命周期(上篇) 做过详细介绍。它会向主线程的 Handler H 发送 EXECUTE_TRANSACTION 事件,调用 XXXActivityItemexecute()postExecute() 方法。execute() 方法中会 Binder 调用 ActivityThread 中对应的 handleXXXActivity() 方法。在这里就是 handlePauseActivity() 方法,其中会通过 Instrumentation.callActivityOnPause(r.activity) 方法回调 Activity.onPause()

> Instrumentation.java  public void callActivityOnPause(Activity activity) {     activity.performPause(); }

到这里,onPause() 方法就被执行了。但是流程没有结束,接着就该显示下一个 Activity 了。前面刚刚说过会调用 PauseActivityItemexecute()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() 方法。

“`java

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

Android 复习笔记目录

  1. 唠唠任务栈,返回栈和生命周期
  2. 唠唠 Activity 的生命周期
  3. 扒一扒 Context
  4. 为什么不能使用 Application Context 显示 Dialog?
  5. OOM 可以被 try catch 吗?
  6. Activity.finish() 之后十秒才回调 onDestroy ?

本文永久更新地址: https://xiaozhuanlan.com/topic/2916834507

目录

  • 没有及时回调的 onStop/onDestroy
  • 从 Activity.finish() 说起
  • 是谁指挥着 onStop/onDestroy 的调用?
  • 谁让 onStop/onDestroy 延迟了 10s ?

没有及时回调的 onStop/onDestroy

交流群里碰到一个很有意思的问题,调用 Activity.finish() 之后 10s 才回调 onDestroy() 。 由此产生了一些不可控问题,例如在 onDestroy() 中释放资源不及时,赋值状态异常等等。我之前倒没有遇到过类似的问题,但是 AOSP 总是我们最好的老师。从 Activity.finish() 开始撸了一遍流程,找到了问题的答案。

在读源码之前,我们先来复现一下 10s onDestroy 的场景。写一个最简单的 FirstActivity 跳转到 SecondActivity 的场景,并记录下各个生命周期和调用 finish() 的时间间隔。

class FirstActivity : BaseLifecycleActivity() {      private val binding by lazy { ActivityFirstBinding.inflate(layoutInflater) }     var startTime = 0L      override fun onCreate(savedInstanceState: Bundle?) {         super.onCreate(savedInstanceState)         setContentView(binding.root)          binding.goToSecond.setOnClickListener {             start<SecondActivity>()             finish()             startTime = System.currentTimeMillis()         }     }      override fun onPause() {         super.onPause()         Log.e("finish","onPause() 距离 finish() :${System.currentTimeMillis() - startTime} ms")     }      override fun onStop() {         super.onStop()         Log.e("finish","onStop() 距离 finish() :${System.currentTimeMillis() - startTime} ms")     }      override fun onDestroy() {         super.onDestroy()         Log.e("finish","onDestroy() 距离 finish() :${System.currentTimeMillis() - startTime} ms")     } }

SecondActivity 是一个普通的没有进行任何操作的空白 Activity 。点击按钮跳转到 SecondActivity,打印日志如下:

FirstActivity: onPause,onPause() 距离 finish() :5 ms SecondActivity: onCreate SecondActivity: onStart SecondActivity: onResume FirstActivity: onStop,onStop() 距离 finish() :660 ms FirstActivity: onDestroy,onDestroy() 距离 finish() :663 ms

可以看到正常情况下,FirstActivity 回调 onPause 之后,SecondActivity 开始正常的生命周期流程,直到 onResume 被回调,对用户可见时,FirstActivity 才会回调 onPause 和 onDestroy 。时间间隔也都在正常范围以内。

我们再模拟一个在 SecondActivity 启动时进行大量动画的场景,源源不断的向主线程消息队列塞消息。修改一下 SecondActivity 的代码。

class SecondActivity : BaseLifecycleActivity() {      private val binding by lazy { ActivitySecondBinding.inflate(layoutInflater) }      override fun onCreate(savedInstanceState: Bundle?) {         super.onCreate(savedInstanceState)         setContentView(binding.root)          postMessage()     }      private fun postMessage() {         binding.secondBt.post {             Thread.sleep(10)             postMessage()         }     } }

再来看一下日志:

FirstActivity: onPause, onPause() 距离 finish() :6 ms SecondActivity: onCreate SecondActivity: onStart SecondActivity: onResume FirstActivity: onStop, onStop() 距离 finish() :10033 ms FirstActivity: onDestroy, onDestroy() 距离 finish() :10037 ms

FirstActivity 的 onPause() 没有受到影响。因为在 Activity 跳转过程中,目标 Activity 只有在前一个 Activity onPause() 之后才会开始正常的生命周期。而 onStoponDestroy() 整整过了 10s 才回调。

对比以上两个场景,我们可以猜测,当 SecondActivity 的主线程过于繁忙,没有机会停下来喘口气的时候,会造成 FirstActivity 无法及时回调 onStoponDestroy 。基于以上猜测,我们就可以从 AOSP 中来寻找答案了。

接下来就是大段的枯燥的源码分析了。带着问题去读 AOSP,可以让这个过程不是那么 “枯燥”,而且一定会有很多不一样的收获。

从 Activity.finish() 说起

以下源代码基于 Android 9.0 版本。

> Activity.java  public void finish() {     finish(DONT_FINISH_TASK_WITH_ACTIVITY); }

重载了带参数的 finish() 方法。参数是 DONT_FINISH_TASK_WITH_ACTIVITY ,含义也很直白,不会销毁 Activity 所在的任务栈。

> Activity.java  private void finish(int finishTask) {     // mParent 一般为 null,在 ActivityGroup 中会使用到     if (mParent == null) {         ......         try {             // Binder 调用 AMS.finishActivity()             if (ActivityManager.getService()                     .finishActivity(mToken, resultCode, resultData, finishTask)) {                 mFinished = true;             }         } catch (RemoteException e) {         }     } else {         mParent.finishFromChild(this);     }     ...... }

这里的 mParent 大多数情况下都是 null ,不需要考虑 else 分支的情况。一些大龄 Android 程序员可能会了解 ActivityGroup,在此种情况下 mParent 可能会不为 null。(因为我还年轻,所以没有使用过 ActivityGroup,就不过多解释了。)其中 Binder 调用了 AMS.finishActivity() 方法。

> ActivityManagerService.java  public final boolean finishActivity(IBinder token, int resultCode, Intent resultData,         int finishTask) {     ......     synchronized(this) {         // token 持有 ActivityRecord 的弱引用         ActivityRecord r = ActivityRecord.isInStackLocked(token);         if (r == null) {             return true;         }         ......         try {             boolean res;             final boolean finishWithRootActivity =                     finishTask == Activity.FINISH_TASK_WITH_ROOT_ACTIVITY;             // finishTask 参数是 DONT_FINISH_TASK_WITH_ACTIVITY,进入 else 分支             if (finishTask == Activity.FINISH_TASK_WITH_ACTIVITY                     || (finishWithRootActivity && r == rootR)) {                 res = mStackSupervisor.removeTaskByIdLocked(tr.taskId, false,                         finishWithRootActivity, "finish-activity");             } else {                 // 调用 ActivityStack.requestFinishActivityLocked()                 res = tr.getStack().requestFinishActivityLocked(token, resultCode,                         resultData, "app-request", true);             }             return res;         } finally {             Binder.restoreCallingIdentity(origId);         }     } }

注意方法参数中的 token 对象,在上一篇文章 为什么不能使用 Application Context 显示 Dialog? 中详细介绍过,Token 是 ActivityRecord 的静态内部类,它持有外部 ActivityRecord 的弱引用。继承自 IApplicationToken.Stub ,是一个 Binder 对象。ActivityRecord 就是对当前 Activity 的具体描述,包含了 Activity 的所有信息。

传入的 finishTask() 方法的参数是 DONT_FINISH_TASK_WITH_ACTIVITY,所以接着会调用 ActivityStack.requestFinishActivityLocked() 方法。

> ActivityStack.java  final boolean requestFinishActivityLocked(IBinder token, int resultCode,         Intent resultData, String reason, boolean oomAdj) {     ActivityRecord r = isInStackLocked(token);     if (r == null) {         return false;     }      finishActivityLocked(r, resultCode, resultData, reason, oomAdj);     return true; }      final boolean finishActivityLocked(ActivityRecord r, int resultCode, Intent resultData,         String reason, boolean oomAdj) {         // PAUSE_IMMEDIATELY 为 true,在 ActivityStackSupervisor 中定义     return finishActivityLocked(r, resultCode, resultData, reason, oomAdj, !PAUSE_IMMEDIATELY); }

最后调用的是一个重载的 finishActivityLocked() 方法。

> ActivityStack.java  // 参数 pauseImmediately 是 false final boolean finishActivityLocked(ActivityRecord r, int resultCode, Intent resultData,         String reason, boolean oomAdj, boolean pauseImmediately) {     if (r.finishing) { // 重复 finish 的情况         return false;     }      mWindowManager.deferSurfaceLayout();     try {         // 标记 r.finishing = true,         // 前面会做重复 finish 的检测就是依赖这个值         r.makeFinishingLocked();         final TaskRecord task = r.getTask();         ......         // 暂停事件分发         r.pauseKeyDispatchingLocked();          adjustFocusedActivityStack(r, "finishActivity");          // 处理 activity result         finishActivityResultsLocked(r, resultCode, resultData);          // mResumedActivity 就是当前 Activity,会进入此分支         if (mResumedActivity == r) {             ......             // Tell window manager to prepare for this one to be removed.             r.setVisibility(false);              if (mPausingActivity == null) {                 // 开始 pause mResumedActivity                 startPausingLocked(false, false, null, pauseImmediately);             }             ......         } else if (!r.isState(PAUSING)) {             // 不会进入此分支             ......         }          return false;     } finally {         mWindowManager.continueSurfaceLayout();     } }

调用 finish 之后肯定是要先 pause 当前 Activity,没毛病。接着看 startPausingLocked() 方法。

> ActivityStack.java      final boolean startPausingLocked(boolean userLeaving, boolean uiSleeping,             ActivityRecord resuming, boolean pauseImmediately) {         ......         ActivityRecord prev = mResumedActivity;          if (prev == null) {             // 没有 onResume 的 Activity,不能执行 pause             if (resuming == null) {                 mStackSupervisor.resumeFocusedStackTopActivityLocked();             }             return false;         }         ......          mPausingActivity = prev;         // 设置当前 Activity 状态为 PAUSING         prev.setState(PAUSING, "startPausingLocked");         ......          if (prev.app != null && prev.app.thread != null) {             try {                 ......                 // 1. 通过 ClientLifecycleManager 分发生命周期事件                 // 最终会向 H 发送 EXECUTE_TRANSACTION 事件                 mService.getLifecycleManager().scheduleTransaction(prev.app.thread, prev.appToken,                         PauseActivityItem.obtain(prev.finishing, userLeaving,                                 prev.configChangeFlags, pauseImmediately));             } catch (Exception e) {                 mPausingActivity = null;             }         } else {             mPausingActivity = null;         }         ......         // 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 我在之前的一篇文章 从源码看 Activity 生命周期(上篇) 做过详细介绍。它会向主线程的 Handler H 发送 EXECUTE_TRANSACTION 事件,调用 XXXActivityItemexecute()postExecute() 方法。execute() 方法中会 Binder 调用 ActivityThread 中对应的 handleXXXActivity() 方法。在这里就是 handlePauseActivity() 方法,其中会通过 Instrumentation.callActivityOnPause(r.activity) 方法回调 Activity.onPause()

> Instrumentation.java  public void callActivityOnPause(Activity activity) {     activity.performPause(); }

到这里,onPause() 方法就被执行了。但是流程没有结束,接着就该显示下一个 Activity 了。前面刚刚说过会调用 PauseActivityItemexecute()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() 方法。

“`java

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

Android 复习笔记目录

  1. 唠唠任务栈,返回栈和生命周期
  2. 唠唠 Activity 的生命周期
  3. 扒一扒 Context
  4. 为什么不能使用 Application Context 显示 Dialog?
  5. OOM 可以被 try catch 吗?
  6. Activity.finish() 之后十秒才回调 onDestroy ?

本文永久更新地址: https://xiaozhuanlan.com/topic/2916834507

目录

  • 没有及时回调的 onStop/onDestroy
  • 从 Activity.finish() 说起
  • 是谁指挥着 onStop/onDestroy 的调用?
  • 谁让 onStop/onDestroy 延迟了 10s ?

没有及时回调的 onStop/onDestroy

交流群里碰到一个很有意思的问题,调用 Activity.finish() 之后 10s 才回调 onDestroy() 。 由此产生了一些不可控问题,例如在 onDestroy() 中释放资源不及时,赋值状态异常等等。我之前倒没有遇到过类似的问题,但是 AOSP 总是我们最好的老师。从 Activity.finish() 开始撸了一遍流程,找到了问题的答案。

在读源码之前,我们先来复现一下 10s onDestroy 的场景。写一个最简单的 FirstActivity 跳转到 SecondActivity 的场景,并记录下各个生命周期和调用 finish() 的时间间隔。

class FirstActivity : BaseLifecycleActivity() {      private val binding by lazy { ActivityFirstBinding.inflate(layoutInflater) }     var startTime = 0L      override fun onCreate(savedInstanceState: Bundle?) {         super.onCreate(savedInstanceState)         setContentView(binding.root)          binding.goToSecond.setOnClickListener {             start<SecondActivity>()             finish()             startTime = System.currentTimeMillis()         }     }      override fun onPause() {         super.onPause()         Log.e("finish","onPause() 距离 finish() :${System.currentTimeMillis() - startTime} ms")     }      override fun onStop() {         super.onStop()         Log.e("finish","onStop() 距离 finish() :${System.currentTimeMillis() - startTime} ms")     }      override fun onDestroy() {         super.onDestroy()         Log.e("finish","onDestroy() 距离 finish() :${System.currentTimeMillis() - startTime} ms")     } }

SecondActivity 是一个普通的没有进行任何操作的空白 Activity 。点击按钮跳转到 SecondActivity,打印日志如下:

FirstActivity: onPause,onPause() 距离 finish() :5 ms SecondActivity: onCreate SecondActivity: onStart SecondActivity: onResume FirstActivity: onStop,onStop() 距离 finish() :660 ms FirstActivity: onDestroy,onDestroy() 距离 finish() :663 ms

可以看到正常情况下,FirstActivity 回调 onPause 之后,SecondActivity 开始正常的生命周期流程,直到 onResume 被回调,对用户可见时,FirstActivity 才会回调 onPause 和 onDestroy 。时间间隔也都在正常范围以内。

我们再模拟一个在 SecondActivity 启动时进行大量动画的场景,源源不断的向主线程消息队列塞消息。修改一下 SecondActivity 的代码。

class SecondActivity : BaseLifecycleActivity() {      private val binding by lazy { ActivitySecondBinding.inflate(layoutInflater) }      override fun onCreate(savedInstanceState: Bundle?) {         super.onCreate(savedInstanceState)         setContentView(binding.root)          postMessage()     }      private fun postMessage() {         binding.secondBt.post {             Thread.sleep(10)             postMessage()         }     } }

再来看一下日志:

FirstActivity: onPause, onPause() 距离 finish() :6 ms SecondActivity: onCreate SecondActivity: onStart SecondActivity: onResume FirstActivity: onStop, onStop() 距离 finish() :10033 ms FirstActivity: onDestroy, onDestroy() 距离 finish() :10037 ms

FirstActivity 的 onPause() 没有受到影响。因为在 Activity 跳转过程中,目标 Activity 只有在前一个 Activity onPause() 之后才会开始正常的生命周期。而 onStoponDestroy() 整整过了 10s 才回调。

对比以上两个场景,我们可以猜测,当 SecondActivity 的主线程过于繁忙,没有机会停下来喘口气的时候,会造成 FirstActivity 无法及时回调 onStoponDestroy 。基于以上猜测,我们就可以从 AOSP 中来寻找答案了。

接下来就是大段的枯燥的源码分析了。带着问题去读 AOSP,可以让这个过程不是那么 “枯燥”,而且一定会有很多不一样的收获。

从 Activity.finish() 说起

以下源代码基于 Android 9.0 版本。

> Activity.java  public void finish() {     finish(DONT_FINISH_TASK_WITH_ACTIVITY); }

重载了带参数的 finish() 方法。参数是 DONT_FINISH_TASK_WITH_ACTIVITY ,含义也很直白,不会销毁 Activity 所在的任务栈。

> Activity.java  private void finish(int finishTask) {     // mParent 一般为 null,在 ActivityGroup 中会使用到     if (mParent == null) {         ......         try {             // Binder 调用 AMS.finishActivity()             if (ActivityManager.getService()                     .finishActivity(mToken, resultCode, resultData, finishTask)) {                 mFinished = true;             }         } catch (RemoteException e) {         }     } else {         mParent.finishFromChild(this);     }     ...... }

这里的 mParent 大多数情况下都是 null ,不需要考虑 else 分支的情况。一些大龄 Android 程序员可能会了解 ActivityGroup,在此种情况下 mParent 可能会不为 null。(因为我还年轻,所以没有使用过 ActivityGroup,就不过多解释了。)其中 Binder 调用了 AMS.finishActivity() 方法。

> ActivityManagerService.java  public final boolean finishActivity(IBinder token, int resultCode, Intent resultData,         int finishTask) {     ......     synchronized(this) {         // token 持有 ActivityRecord 的弱引用         ActivityRecord r = ActivityRecord.isInStackLocked(token);         if (r == null) {             return true;         }         ......         try {             boolean res;             final boolean finishWithRootActivity =                     finishTask == Activity.FINISH_TASK_WITH_ROOT_ACTIVITY;             // finishTask 参数是 DONT_FINISH_TASK_WITH_ACTIVITY,进入 else 分支             if (finishTask == Activity.FINISH_TASK_WITH_ACTIVITY                     || (finishWithRootActivity && r == rootR)) {                 res = mStackSupervisor.removeTaskByIdLocked(tr.taskId, false,                         finishWithRootActivity, "finish-activity");             } else {                 // 调用 ActivityStack.requestFinishActivityLocked()                 res = tr.getStack().requestFinishActivityLocked(token, resultCode,                         resultData, "app-request", true);             }             return res;         } finally {             Binder.restoreCallingIdentity(origId);         }     } }

注意方法参数中的 token 对象,在上一篇文章 为什么不能使用 Application Context 显示 Dialog? 中详细介绍过,Token 是 ActivityRecord 的静态内部类,它持有外部 ActivityRecord 的弱引用。继承自 IApplicationToken.Stub ,是一个 Binder 对象。ActivityRecord 就是对当前 Activity 的具体描述,包含了 Activity 的所有信息。

传入的 finishTask() 方法的参数是 DONT_FINISH_TASK_WITH_ACTIVITY,所以接着会调用 ActivityStack.requestFinishActivityLocked() 方法。

> ActivityStack.java  final boolean requestFinishActivityLocked(IBinder token, int resultCode,         Intent resultData, String reason, boolean oomAdj) {     ActivityRecord r = isInStackLocked(token);     if (r == null) {         return false;     }      finishActivityLocked(r, resultCode, resultData, reason, oomAdj);     return true; }      final boolean finishActivityLocked(ActivityRecord r, int resultCode, Intent resultData,         String reason, boolean oomAdj) {         // PAUSE_IMMEDIATELY 为 true,在 ActivityStackSupervisor 中定义     return finishActivityLocked(r, resultCode, resultData, reason, oomAdj, !PAUSE_IMMEDIATELY); }

最后调用的是一个重载的 finishActivityLocked() 方法。

> ActivityStack.java  // 参数 pauseImmediately 是 false final boolean finishActivityLocked(ActivityRecord r, int resultCode, Intent resultData,         String reason, boolean oomAdj, boolean pauseImmediately) {     if (r.finishing) { // 重复 finish 的情况         return false;     }      mWindowManager.deferSurfaceLayout();     try {         // 标记 r.finishing = true,         // 前面会做重复 finish 的检测就是依赖这个值         r.makeFinishingLocked();         final TaskRecord task = r.getTask();         ......         // 暂停事件分发         r.pauseKeyDispatchingLocked();          adjustFocusedActivityStack(r, "finishActivity");          // 处理 activity result         finishActivityResultsLocked(r, resultCode, resultData);          // mResumedActivity 就是当前 Activity,会进入此分支         if (mResumedActivity == r) {             ......             // Tell window manager to prepare for this one to be removed.             r.setVisibility(false);              if (mPausingActivity == null) {                 // 开始 pause mResumedActivity                 startPausingLocked(false, false, null, pauseImmediately);             }             ......         } else if (!r.isState(PAUSING)) {             // 不会进入此分支             ......         }          return false;     } finally {         mWindowManager.continueSurfaceLayout();     } }

调用 finish 之后肯定是要先 pause 当前 Activity,没毛病。接着看 startPausingLocked() 方法。

> ActivityStack.java      final boolean startPausingLocked(boolean userLeaving, boolean uiSleeping,             ActivityRecord resuming, boolean pauseImmediately) {         ......         ActivityRecord prev = mResumedActivity;          if (prev == null) {             // 没有 onResume 的 Activity,不能执行 pause             if (resuming == null) {                 mStackSupervisor.resumeFocusedStackTopActivityLocked();             }             return false;         }         ......          mPausingActivity = prev;         // 设置当前 Activity 状态为 PAUSING         prev.setState(PAUSING, "startPausingLocked");         ......          if (prev.app != null && prev.app.thread != null) {             try {                 ......                 // 1. 通过 ClientLifecycleManager 分发生命周期事件                 // 最终会向 H 发送 EXECUTE_TRANSACTION 事件                 mService.getLifecycleManager().scheduleTransaction(prev.app.thread, prev.appToken,                         PauseActivityItem.obtain(prev.finishing, userLeaving,                                 prev.configChangeFlags, pauseImmediately));             } catch (Exception e) {                 mPausingActivity = null;             }         } else {             mPausingActivity = null;         }         ......         // 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 我在之前的一篇文章 从源码看 Activity 生命周期(上篇) 做过详细介绍。它会向主线程的 Handler H 发送 EXECUTE_TRANSACTION 事件,调用 XXXActivityItemexecute()postExecute() 方法。execute() 方法中会 Binder 调用 ActivityThread 中对应的 handleXXXActivity() 方法。在这里就是 handlePauseActivity() 方法,其中会通过 Instrumentation.callActivityOnPause(r.activity) 方法回调 Activity.onPause()

> Instrumentation.java  public void callActivityOnPause(Activity activity) {     activity.performPause(); }

到这里,onPause() 方法就被执行了。但是流程没有结束,接着就该显示下一个 Activity 了。前面刚刚说过会调用 PauseActivityItemexecute()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() 方法。

“`java

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

部分转自互联网,侵权删除联系

赞(0) 打赏
部分文章转自网络,侵权联系删除b2bchain区块链学习技术社区 » Activity.finish() 之后 10s 才 onDestroy ?求职学习资料
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

b2b链

联系我们联系我们