老罗的android之旅 博客,从源码角度分析Activity的生命周期时序怎么触发的(onCreate onStart onResume onPause onStop onDestroy)(附测试代...

【转载请注明出处:5分钟告诉你,Activity的生命周期怎么触发的(onCreate onStart onResume onPause onStop onDestroy)(附测试代码) CSDN 王智博】

前言

试想一下,如果从Activity A 跳转到Activity B,A和B的生命周期分别是怎么过的?

我们初学Android时候都接触过声明周期,当时给的解释是,onCreate是Activity创建时候,onStart是Activity可见,onResume是Activity可交互,onPause是Activity不可交互,onStop是Activity不可见,onDestroy是Activity销毁。

所以我们可以猜一下,大概是A先变成不可交互状态,然后B开始创建,然后B可见了,之后是A先不可见还是B先可交互呢??

所以我们大概猜测一下声明周期的变化应该是 A.onPause(不可交互) -> B.onCreate(创建) -> B.onStart(可见) -> A.onStop(不可见)   -> B.onResume(可交互)

那么正确吗?

验证

我们简单的在声明周期里面打印log来看下效果,代码不是太复杂,我就不展开讲了,源码在

github:https://github.com/samwangzhibo/LoveStudy (不会使用github导入代码的同学,戳这)

@Override

protected void onStart() {

super.onStart();

Log.e(TAG, TAG + " onStart");

}

@Override

protected void onResume() {

Log.e(TAG, TAG + " onResume");

super.onResume();

}

效果如下:A.onPause  -> B.onCreate -> B.onStart -> B.onResume  -> A.onStop

fafeb03c1ea5195ce4b44c9cc931f50e.png

直接给结论

1.onPasue的由来

当从A调用startActivity开启B的时候,首先会通过ServiceManager那里取到ActivityManageService(以下简写为AMS)的binder,通过IPC通信告诉AMS A想要启动B,AMS说可以,然后发现他俩在同一进程(那我就不给你创建进程和activityThread了),然后AMS告诉A说,你可以休息了(applicationThread.schedulePauseActivity(),通过applicationThread 这个匿名binder,没有在serviceManager注册),然后A就onPause了(activityThread.performPauseActivity -> Instrumentation.callActivityOnPasue -> Activity.perfromPause  -> onPause)

2.onCreate的由来

A在onPause之后,会通知AMS,它已经pause了,然后AMS Process.start创建B的进程(如果不是在同一进程的话),在这个场景的话,B和A在同一进程,AMS会调用主线程的performLauchActivity方法(applicationThread.scheduleLauchActivity  ->  send(Lauch_Activity)),然后会创建一个Activity(通过反射),然后attach关联上上下文(创建phoneWindow),之后调用Instrument的callActivityOnCreate、Activity的performCreate,这个方法里面调用onCreate()。

onCreate干了啥?

onCreate里面必须要写的一个方法就是setContentView(layout_xml),实际上是调用PhoneWindow里面的setContentView,首先就是确保DecorView是否存在(不存在就创建它),之后调用LayoutInflater的inflate方法解析layout布局文件,生成View树,然后add到DecorView上面。这个时候DecorView已经装载好了,phoneWindow(展示的容器)也有了,就差一个东风让视图渲染出来了。

3.onStart的由来

ActivityStack通知B的主线程(scheduleResumeActivity -> handleResumeActivity -> Activity.performResume),通过Instrumentation先后调用onStart和onResume,最后把DecorView装载到Window上(WindowManagerImpl.addView),并生成ViewRootImpl对象(WindowManagerGlobal.addView),然后调用ViewRootImpl的requestLayout,最后调用performTraversal,执行视图树的遍历,包括performMeasure、performLayout、performDraw。

视图的绘制流程我放在单独的篇幅介绍:

5分钟告诉你,Activity的视图绘制流程(onMeasure、onLayout、onDraw的调用和参数解释)

4.onResume的由来

由上步可以看出,是在performActivityResume里面,在onStart之后调用的onResume

5.onStop的由来

ActivityStack调用application的scheduleStopActivity,然后调用ActivityThread的performActivityStopInner,Activity的performStop,最后还是老套路,调用Instrumentation的callActivityOnStop,然后回调Activity的onStop

6.onDestroy

ActivityStack调用application的scheduleDestroyActivity,同上最后会调用Instrumentation的callActivityOnDestroy,然后调用Activity的onDestroy

由此可以看出来ActivityStack不仅管理着多个Activity的顺序,还管理着每个Activity的生命周期。

类调用关系时序图

dea6d3f75bc097b4d72690cf4392cb85.png

关于Android 9.0

Android 9.0部分代码做了修改,抽取出 ActivityThread里面的生命周期代码,用ClientLifecycleManager 事务的方式对生命周期进行管理,降低了ActivityThread和Activity 生命周期的耦合度

1.取消了ActivityThread里面编号110之前对于生命周期处理的Message,新增事务关键字

53ca2f3b6af81f3bc3b353a35b8496f0.png

beecbc7b43fbe74f03e34ca5d3266d7b.png

2.ActivityThread继承了ClientTransactionHandler,将原先放在ActivityThread里面的handleLaunchActivity、handlerStartActivity等等抽取出来,放到ClientTransactionHandler类中,作为抽象方法。

3.新增了ClientLifecycleManager、ClientTransactionHandler、ClientTransaction、TransactionExecutor、TransactionExecutorHelper、ClientTransactionItem

ClientLifecycleManager:作为ActivityStackSupervisor和ClientTransaction的桥梁

ClientTransactionHandler: 由ActivityThread实现。

ClientTransaction:管理ClientTransactionItem

TransactionExecutor:执行ClientTransactionItem

TransactionExecutorHelper:协助TransactionExecutor执行ClientTransactionItem

ClientTransactionItem:真正执行生命周期的类,每一个生命周期对应一个Item(onStart除外,原因不详)

b1fe3c7af42239afd5e72746dd2db2fe.png

时序图:

2be38f4589a09a7a4ddb6ff3f50cf2a0.png

思考:

A跳转到B其实就是Activity的启动过程,在这个过程分析中,我们发现了ActivityThread(app的主线程)、H(主线程处理消息的handler)、ApplicationThread(app作为service端的匿名binder对象)、SystemServer(系统的服务进程)、AMS(SystemServer中的一个服务,管理Activity和Service)、WMS(SystemServer中的管理窗口和视图的Service)、PMS(SystemServer中管理包信息的Service,app启动需要从它那里读取配置),其中IPC通信还需要用到Binder、binder还需要从ServerManager里面获取、AMS还要和ActivityStack合作,然后通知主线程进入Activity的生命周期、Activity实际上又是由Instrumentation来调用它自己的onCreate、onStart、onResume等生命周期的。

所以ActivityThread、ApplicationThread、AMS、WMS、PMS、Binder、ServerManager、ActivityStack、Activity、Instrumentation又分别有什么用?请看楼主其他的文章,后面会陆续的讲解。

完整Android学习路径 请戳我的Android学习之旅(持续更新中...)

从源码角度分析Activity的生命周期怎么触发的(onCreate onStart onResume onPause onStop onDestroy)(附测试代码)

基于AIDL的 Activity、Service跨进程观察者模式实现与源码解读

走进源码,Android面试最常见Handler、Looper、Message问题总结与解答

Android面试---ListView原理及fling分析

5分钟告诉你,Activity的视图绘制流程(onMeasure、onLayout、onDraw的调用和参数解释)

参考

《老罗的Android之旅》阅读笔记——Activity启动过程

Android应用程序启动过程源代码分析

Android9.0 Activity启动原理差异解析

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值