大佬教程收集整理的这篇文章主要介绍了详解Android.activity销毁流程的工作原理,大佬教程大佬觉得挺不错的,现在分享给大家,也给大家做个参考。
继续我们的源码解析,上一篇文章我们介绍了Activity的启动流程,一个典型的场景就是Activity a 启动了一个Activity b,他们的生命周期回调方法是: @H_404_1@
而我们根据源码也验证了这样的生命周期调用序列,那么Activity的销毁流程呢?它的生命周期的调用顺序又是这样的呢?
这里我们我做一个简单的demo,让一个Activity a启动Activity b,然后在B中调用finish()方法,它们的生命周期执行顺序是:
好吧,根据我们测试的生命周期方法的回调过程开始对Activity销毁流程的分析,一般而言当我们需要销毁Activity的时候都会调用其自身的finish方法,所以我们的流程开始是以finish方法开始的。
一:请求销毁当前Activity
首先我们在自己的Activity调用了finish方法,它实际上调用的是Activity的finish方法:
然后我们可以发现其调用了finish方法的重载方法,并且传递了一个参数值:
private void finish(Boolean finishTask) { if (mParent == null) { int resultCode; Intent resultData; synchronized (this) { resultCode = mResultCode; resultData = mResultData; } if (false) Log.v(tag,"Finishing self: token=" + mToken); try { if (resultData != null) { resultData.prepareToLeaveProcess(); } if (ActivitymanagerNative.getDefault() .finishActivity(mToken,resultCode,resultData,finishTask)) { mFinished = true; } } catch (remoteexception E) { // Empty } } else { mParent.finishFromChild(this); } }
好吧,这个参数值似乎并没什么用。。。这里就不在讨论了,然后调用了ActivitymanagerNative.getDefault().finishActivity方法,好吧,根据上一篇文章的介绍,我们知道了ActivitymanagerNative是一个Binder对象,这里调用的方法最终会被Activitymanagerservice执行,所以这了的finishActivity最终被执行的是Activitymanagerservice.finishActivity方法,好吧,我们来看一下Activitymanagerservice的finishActivity方法的执行逻辑。。。
@Override public final Boolean finishActivity(IBinder token,int resultCode,Intent resultData,Boolean finishTask) { ... res = tr.stack.requestFinishActivityLocked(token,"app-request",truE); ... }
这里我们可以发现,经过一系列逻辑判断之后,最终调用了ActivityStack的requestFinishActivityLocked方法,这里应该就是执行finish Activity的逻辑了。
final Boolean requestFinishActivityLocked(IBinder token,String reason,Boolean oomAdj) { ActivityRecord r = isInStackLocked(token); if (DEBUG_RESULTS || DEBUG_STATES) Slog.v(tag_STATES,"Finishing activity token=" + token + " r=" + ",result=" + resultCode + ",data=" + resultData + ",reason=" + reason); if (r == null) { return false; } finishActivityLocked(r,reason,oomAdj); return true; }
这个方法体里面又调用了finishActivityLocked方法,那我们继续看一下finishActivityLocked方法的实现:
final Boolean finishActivityLocked(ActivityRecord r,Boolean oomAdj) { ... startPausingLocked(false,false,falsE); ... return false; }
好吧,在这里调用了startPausingLocked方法,看名字应该是开始要执行Activity的onPause方法请求了,然后我们看一下startPausingLocked方法的实现:
final Boolean startPausingLocked(Boolean userLeaving,Boolean uiSleeping,Boolean resuming,Boolean dontWait) { ... try { EventLog.writeEvent(EventLogTags.AM_PAUSE_ACTIVITY,prev.userId,System.identityHashCode(prev),prev.shortComponentName); mservice.updateUsageStats(prev,falsE); prev.app.thread.schedulePauseActivity(prev.appToken,prev.finishing,userLeaving,prev.configChangeFlags,dontWait); } catch (Exception E) { // Ignore exception,if process died other code will cleanup. Slog.w(tag,"Exception thrown during pause",E); mPausingActivity = null; mLastPausedActivity = null; mLastNoHistoryActivity = null; } ... }
这样从应用程序调用finish方法,Activitymanagerservice接收请求并执行startPausingLocked方法。
二:执行当前Activity的onPause方法
在方法startPausingLocked中我们调用了:prev.app.thread.schedulePauseActivity这里实际上调用的是IApplicationThread的schedulePauseActivity方法,IApplicationThread也是一个Binder对象,它是ActivityThread中ApplicationThread的Binder client端,所以最终会调用的是ApplicationThread的schedulePauseActivity方法,好吧我们看一下ActivityThread的schedulePauseActivity方法的具体实现:
public final void schedulePauseActivity(IBinder token,Boolean finished,Boolean userLeaving,int configChanges,Boolean dontReport) { sendmessage( finished ? H.PAUSE_ACTIVITY_FINISHING : H.PAUSE_ACTIVITY,token,(userLeaving ? 1 : 0) | (dontReport ? 2 : 0),configChanges); }
然后调用了ActivityThread的sendmessage方法:
private void sendmessage(int what,Object obj,int arg1,int arg2) { sendmessage(what,obj,arg1,arg2,falsE); }
private void sendmessage(int what,int arg2,Boolean asynC) { if (DEBUG_messaGES) Slog.v( TAG,"scheDULE " + what + " " + mH.codeToString(what) + ": " + arg1 + " / " + obj); message msg = message.obtain(); msg.what = what; msg.obj = obj; msg.arg1 = arg1; msg.arg2 = arg2; if (asynC) { msg.setAsynchronous(true); } mH.sendmessage(msg); }
最终@L_206_6@mH发送异步消息,然后在mH的handleMessge方法中处理异步消息并调用handlePauseActivity方法:
private void handlePauseActivity(IBinder token,Boolean dontReport) { ActivityClientRecord r = mActivities.get(token); if (r != null) { //Slog.v(tag,"userLeaving=" + userLeaving + " handling pause of " + r); if (userLeaving) { performUserLeavingActivity(r); } r.activity.mConfigChangeFlags |= configChanges; performPauseActivity(token,finished,r.isPreHoneycomb()); // Make sure any pending writes are Now committed. if (r.isPreHoneycomb()) { QueuedWork.waitToFinish(); } // Tell the activity manager we have paused. if (!dontReport) { try { ActivitymanagerNative.getDefault().activityPaused(token); } catch (remoteexception eX) { } } mSomeActivitiesChanged = true; } }
好吧,这里回调了performPauseActivity方法,上篇文章中我们已经分析过了这段代码:
在handlePauseActivity方法中我们调用了ActivitymanagerNative.getDefault().activityPaused(token)方法,好吧又是回调Activitymanagerservice的方法,这样最终会调用Activitymanagerservice的activityPaused方法:
@Override public final void activityPaused(IBinder token) { final long origId = Binder.clearCallingIdentity(); synchronized(this) { ActivityStack stack = ActivityRecord.getStackLocked(token); if (stack != null) { stack.activityPausedLocked(token,falsE); } } Binder.restoreCallingIdentity(origId); }
这样,我们继续看一下activityPausedLocked方法的实现:
final void activityPausedLocked(IBinder token,Boolean timeout) { ... completePauseLocked(true); ... }
里面又经过一系列的逻辑判断之后,开始执行completePauseLocked方法:
private void completePauseLocked(Boolean resumeNext) { ... mStackSupervisor.resumeTopActivitiesLocked(topStack,null,null); ... }
这样栈顶Activity的onPause操作就执行完成了,接下来就就是开始执行上一个Activity的onResume操作了。。。
三:执行上一个Activity的onResume操作 @H_404_1@
这样调用了ActivityStackSupervisor.resumeTopActivitiesLocked方法。。,又开始调用这个方法,通过上一篇文章的介绍,我们知道这个方法实际上是执行Activity的初始化,我们看一下其具体的调用过程:
好吧,这个过程其实上一篇文章中已经做了介绍,这里不做过多的分析了,通过这样调用过程我们最终执行了当前栈顶Activity上一个Activity的onRestart方法,onStart方法,onResume方法等,下面我们将调用栈顶Activity的onStop方法,onDestory方法。
四:执行栈顶Activity的销毁操作
我们在ActivityThread.handleResumeActivity方法中调用了Looper.myQueue().addIdleHandler(new Idler()),下面看一下这个方法的实现:
private class Idler implements messageQueue.IdleHandler { @Override public final Boolean queuEIDle() { ActivityClientRecord a = mNewActivities; Boolean stopProfiling = false; if (mBoundApplication != null && mProfiler.profileFd != null && mProfiler.autoStopProfiler) { stopProfiling = true; } if (a != null) { mNewActivities = null; IActivitymanager am = ActivitymanagerNative.getDefault(); ActivityClientRecord prev; do { if (LOCALLOGV) Slog.v( TAG,"ReporTing idle of " + a + " finished=" + (a.activity != null && a.activity.mFinished)); if (a.activity != null && !a.activity.mFinished) { try { am.activityIdle(a.token,a.createdConfig,stopProfiling); a.createdConfig = null; } catch (remoteexception eX) { // Ignore } } prev = a; a = a.nextIdle; prev.nextIdle = null; } while (a != null); } if (stopProfiling) { mProfiler.stopProfiling(); } ensureJitEnabled(); return false; } }
内部有一个queuEIDle的回调方法,当它被添加到messageQueue之后就会回调该方法,我们可以发现在这个方法体中调用了ActivitymanagerNative.getDefault.activityIdle方法,通过上一篇文章以及上面的讲解,我们应该知道这了最终调用的是Activitymanagerservice.activityIdle方法,好吧,这里看一下activityIdle方法的具体实现:
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,config); if (stopProfiling) { if ((mProfileProc == r.app) && (mProfileFd != null)) { try { mProfileFd.close(); } catch (IOException E) { } clearProfilerLocked(); } } } } Binder.restoreCallingIdentity(origId); }
可以发现这里又调用了ActivityStackSupervisor.activityIdleInternalLocked方法,然后我们看一下activityIdleInternalLocked方法的具体实现:
final ActivityRecord activityIdleInternalLocked(final IBinder token,Boolean fromTimeout,Configuration config) { .... stack.destroyActivityLocked(r,true,"finish-idle"); .... }
可以看到这里调用ActivityStack.destroyActivityLocked方法,可以看一下其具体实现:
final Boolean destroyActivityLocked(ActivityRecord r,Boolean removeFromApp,String reason) { ... r.app.thread.scheduleDestroyActivity(r.appToken,r.finishing,r.configChangeFlags); ... }
好吧,这里又开始执行IApplicationThread.scheduleDestoryActivity方法,上文已经做了说明这里最终调用的是ActivityThread.scheduleDestroyActivity方法,好吧,看一下ActivityThread.scheduleDestryActivity方法的实现:
public final void scheduleDestroyActivity(IBinder token,Boolean finishing,int configChanges) { sendmessage(H.DESTROY_ACTIVITY,finishing ? 1 : 0,configChanges); }
这里有开始执行sendmessage方法,通过一系列的调用sendmessage方法最终调用了handleDestroyActivity方法:
private void handleDestroyActivity(IBinder token,Boolean getNonConfigInstancE) { ActivityClientRecord r = performDestroyActivity(token,finishing,configChanges,getNonConfigInstancE); if (r != null) { cleanUpPendingRemoveWindows(r); WindowManager wm = r.activity.getWindowManager(); View v = r.activity.mDecor; if (v != null) { if (r.activity.mVisibleFromServer) { mNumVisibleActivities--; } IBinder wtoken = v.getWindowToken(); if (r.activity.mWindowAdded) { if (r.onlyLocalrequest) { // Hold off on removing this until the new activity's // window is being added. r.mPendingRemoveWindow = v; r.mPendingRemoveWindowManager = wm; } else { wm.removeViewImmediate(v); } } if (wtoken != null && r.mPendingRemoveWindow == null) { WindowManagerGlobal.geTinstance().closeAll(wtoken,r.activity.getClass().getName(),"Activity"); } r.activity.mDecor = null; } if (r.mPendingRemoveWindow == null) { // If we are delaying the removal of the activity window,then // we can't clean up all windows here. Note that we can't do // so later either,which means any windows that aren't closed // by the app will leak. Well we try to warning them a lot // about leaking windows,because that is a bug,so if they are // using this recreate facility then they get to live with leaks. WindowManagerGlobal.geTinstance().closeAll(token,"Activity"); } // mocked out contexts won't be participaTing in the normal // process lifecycle,but if we're running with a proper // ApplicationContext we need to have it tear down things // cleanly. Context c = r.activity.getBaseContext(); if (c instanceof ContextImpl) { ((ContextImpl) C).scheduleFinalCleanup( r.activity.getClass().getName(),"Activity"); } } if (finishing) { try { ActivitymanagerNative.getDefault().activityDestroyed(token); } catch (remoteexception eX) { // If the system process has died,it's game over for everyone. } } mSomeActivitiesChanged = true; }
可以看到这里调用了performDestroyActivity方法,用来执行Avtivity的onDestroy方法:
private ActivityClientRecord performDestroyActivity(IBinder token,Boolean getNonConfigInstancE) { ... r.activity.performStop(); ... minstrumentation.callActivityOnDestroy(r.activity); ... }
然后调用了Activity.performStop()方法,查看performStop方法:
然后调用了instrumentation.callActivityOnStop()方法:
我们继续看一下instrumentation.callActivityOnDestroy()。。。。又是通过instrumentation来调用Activity的onDestroy方法:
然后看一下Activity的performDestroy()方法的实现:
final void performDestroy() { mDestroyed = true; mWindow.destroy(); mFragments.dispatchDestroy(); onDestroy(); mFragments.doLoaderDestroy(); if (mVoiceInteractor != null) { mVoiceInteractor.detachActivity(); } }
O(∩_∩)O哈哈~,终于回调了Activity的onDestroy方法。。。。
总结:
Activity的销毁流程是从finish方法开始的
Activity销毁过程是:onPause C> onRestart C> onStart C> onResume C> onStop C> onDestroy
Activity的销毁流程是ActivityThread与Activitymanagerservice相互配合销毁的
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持编程小技巧。
以上是大佬教程为你收集整理的详解Android.activity销毁流程的工作原理全部内容,希望文章能够帮你解决详解Android.activity销毁流程的工作原理所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错,欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。