Framework activity启动流程
初一十五不吃饭 人气:0引言
今天在电脑上翻出了很久之前整理笔记Framework
源码面试,Flutter
,以及一部分面试专题。拿出来温习一下。
今天先讲Framework
源码篇:
1.Framework
源码面试:Activity
启动流程
2.Framework
源码面试:Binder
面试
3.Framework
源码面试:Handler
面试
4.Framework
源码面试:事件分发机制
5.Framework
源码面试:onMeasure
测量原理
6.Framework
源码面试:Android
屏幕刷新机制
Framework源码面试:activity启动流程
面试的时候,面试官经常同你随便侃侃Activity
的启动模式,但Activity
启动牵扯的知识点其实很多,并非能单单用四个启动模式就能概括的,
默认的启动模式的表现会随着Intent Flag
的设置而改变,因此侃Activity
启动模式大多走流程装逼,最多结合项目遇到的问题,随便刁难一下面试者,并不太容易把控,也许最后,面试官跟面试者的答案都是错了,
比如在Service
中必须通过设置FLAG_ACTIVITY_NEW_TASK
才能启动Activity
,这个时候启动Activit
会有什么样的表现呢?就这一个问题,答案就要分好几个场景:
Activity
的taskAffinity
属性的Task
栈是否存在- 如果存在,要看
Activity
是否存已经存在于该Task
- 如果已经存在于该
taskAffinity
的Task
,要看其是不是其rootActivity
- 如果是其
rootActivity
,还要看启动该Activity
的Intent
是否跟当前intent
相等
不同场景,所表现的行为都会有所不同,再比如singleInstance
属性,如果设置了,大家都知道只有一个实例,将来再启动会复用,但是如果使用Intent.FLAG_ACTIVITY_CLEAR_TASK
来启动,仍然会重建,并非完全遵守singleInstance
的说明,还有不同Flag
在叠加使用时候也会有不同的表现,单一而论Activity
启动模式其实是很难的。本文也仅仅是涉及部分启动模式及Flag
,更多组合跟场景要自己看源码或者实验来解决了。
1.1面试连环炮之说说 Android 的四种启动模式
standard
这是 Activity
的默认启动模式,每次激活 Activity
的时候都会创建一个新的 Activity
实例,并放入任务栈中。
使用场景:基本绝大多数地方都可以用。
singleTop
这可能也是非常常用的 launchMode
了。如果在任务的栈顶正好存有该 Activity
的实例,则会通过调用 onNewIntent()
方法进行重用,否则就会同 standard 模式一样,创建新的实例并放入栈顶。即便栈中已经存在了该 Activity 的实例,也会创建新的实例,即:A -> B ->A,此时栈内为 A -> B -> A,但 A -> B ->B ,此时栈内为 A -> B。一句话概述就是:当且仅当启动的 Activity
和上一个 Activity
一致的时候才会通过调用 onNewIntent()
方法重用 Activity
。
使用场景:资讯阅读类 APP 的内容界面。
singleTask
这个 launchMode
专门用于解决上面 singleTop
的另外一种情况,只要栈中已经存在了该 Activity
的实例,就会直接调用 onNewIntent()
方法来实现重用实例。重用时,直接让该 Activity
的实例回到栈顶,并且移除之前它上面的所有 Activity
实例。如果栈中不存在这样的实例,则和 standard
模式相同。即: A ->B -> C -> D -> B,此时栈内变成了 A -> B。而 A -> B -> C,栈内还是 A -> B -> C。
使用场景:浏览器的主页面,或者大部分 APP 的主页面。
singleInstance
在一个新栈中创建该 Activity
的实例,并让多个应用共享该栈中的该 Activity
实例。一旦该模式的 Activity
实例已经存在于某个栈中,任何应用再激活该 Activity
时都会重用该栈中的实例,是的,依然是调用 onNewIntent()
方法。其效果相当于多个应用共享一个应用,不管是谁激活,该 Activity 都会进入同一个应用中。但值得引起注意的是:singleInstance
不要用于中间页面,如果用户中间页面,跳转会出现很难受的问题。 这个在实际开发中我暂未遇到过,不过 Android 系统的来电页面,多次来电均是使用的同一个 Activity
。
四种模式的背书式理解记忆讲完了,你认为这样就结束了吗?
对,我也一度是这样认为的。
1.2.面试连环炮之说说 Intent标签起什么作用呢? 简单说一说
我们除了需要知道在 AndroidManifest.xml
里面设置 android:launchMode
属性,我们还需要了解下面这几个Intent
标签的用法。
在 Android 中,我们除了在清单文件 AndroidManifest.xml
中配置 launchMode
,当然可以用 Intent
标签说事儿。启动 Activity
,我们需要传递一个 Intent
,完全可以通过设置 Intent.setFlags(int flags)
来设置启动的 Activity
的启动模式。
需要注意的是:通过代码来设置 Activity
的启动模式的方式,优先级比清单文件设置更高。
FLAG_ACTIVITY_NEW_TASK
这个标识会使新启动的Activity
独立创建一个Task
。FLAG_ACTIVITY_CLEAR_TOP
这个标识会使新启动的Activity
检查是否存在于Task
中,如果存在则清除其之上的Activity
,使它获得焦点,并不重新实例化一个Activity
,一般结合FLAG_ACTIVITY_NEW_TASK
一起使用。FLAG_ACTIVITY_SINGLE_TOP
等同于在launcherMode
属性设置为singleTop
。
1.2.Android 的启动原理,他的流程是什么样的
总的流程图:
1.2.1.进程A与AMS的交互过程
此处以跨进程启动Activity
分析一下源码流程:
①A调用startActivity
时,需要与AMS交互,此时需要需要获取到AMS的代理对象Binder也就是上图的AMP,
通过ActivityManagerNative.getDefault()
获得,并调用AMP的startActivity
方法,然后会通过mRemote.transact
方法进行Binder通信,在AMS的onTransact
方法里面会获取到请求的Activity
参数信息:
mRemote.transact(START_ACTIVITY_TRANSACTION,data,reply,0); @Override public boolean onTransact(int code, Parcel data, Parcel reply, int flags){ switch(code){ case START_ACTIVITY_TRANSACTION:{ startActivity(app,callingPackage,intent,...) } } }
②AMS里面的startActivity
方法最主要会去调用startSpecificActivityLocked
函数,在此函数里面会去判断目标进程是否已经存在,并且目标向AMS注册过它自己的ApplicationThread
也就是上图ATP代理对象,如果这两个条件都满足会去调用realStartActivityLocked
方法,这个方法我们后面再看。如果上述条件不满足时,会去调用mService.startProcessLocked(r.processName,...)
方法启动进程。
startProcessLocked
方法首先调用Process.start("android.app.ActivityThread",)
方法会向Zygote
发送一个启动进程的请求,并告知Zygote
进程启动之后,加载ActivityThread
这个类的入口main
函数,启动完成后返回进程的pid,并向AMS的Handler发送一个延迟消息,为的是要求目标进程启动后,10秒钟内需要向AMS报告,不然的话AMS就会清除目标进程的相关信息。Process.start
方法会去调用startViaZygote(processClass,)
函数,这个函数主要做了两件事,一件就是打开通往Zygote
的Socket
,第二件事就是通过Socket
发送启动进程参数。Zygote
端主要逻辑是在runOnce
函数,函数内调用Zygote.forkAndSpecialize(...)
创建子进程,创建完成之后就分别在父进程和子进程里面做各自的事情.
父进程通过hanleParentProc(pid)
把子进程的pid
通过Socket
发送给AMS
子进程调用handleChildProc
函数,做一些通用的初始化,比如启用Binder
机制;执行应用程序的入口函数,也就是ActivityThread
的Main
函数.
ActivityThread
的main
函数,里面会创建一个ActivityThread
对象,并调用thread.attach(false)
,为的是向AMS报到,上面第一条里面有提到。attach
方法里面,其实是一个跨进程的调用,首先通过
IActivityManager mgr = ActivityManagerNative.getDefault();
获取到AMS的Binder代理对象,然后调用
mgr.attachApplication(mAppThread);
mAppThread
是应用端的一个Binder对象ApplicationThread
,也就是最上面一张图的ATP,这样AMS端就可以调用应用端了。
attachApplication
方法里面,最主要有两个方法,一个是通过传入的ApplicationThread
对象,调用bindApplication
初始化Application
对象,另一个就是通过
mStactSupervisor.attachApplicationLoacked(app);
初始化挂起的Activity
对象。
- 在
attachApplicationLoacked
函数里,会调用
ActivityRecord hr = stack.topRunningActivityLocked(null);
其中要明白AMS里面有两个栈,一个是Launch
桌面栈,一个就是非桌面栈mFocusedStack
,此处的stack
就是mFocusedStack
,它会将栈顶的ActivityRecord
返回出来,我们的目标Activity
早就放置在了栈顶,只是一直没有初始化。然后调用方法,来启动Activity
如果我们不是启动另外一个进程,而是同一进程,那么这第二大部分就不会存在了,而是直接调用realStartActivityLocked
方法。
realStartActivityLocked(hr,app,true,true);
写到这里是不是有很多码牛的小伙伴们已经坚持不下去了。还剩最后几个步骤
① realStartActivityLocked
函数会调用app.thread.scheduleLaunchActivity(new Intent(r.intent),...)
;也就是通过之前注册的Binder对象ATP,调用scheduleLaunchActivity
函数,在scheduleLaunchActivity
函数里面:
ActivityClientRecord r = new ActivityClientRecord(); ... sendMessage(H.LAUNCH_ACTIVITY,r);
封装了一个ActivityClientRecord
消息,然后丢到主线程的Handler(mH)里。
②在主线程里面
final ActivityClientRecord r = (ActivityClientRecord)msg.obj ; r.packageInfo = getPackageInfoNoCheck(...); handleLaunchActivity(r,null);
getPackageInfoNoCheck
函数主要是用来生成一个LoadedApk
对象,它用来保存我们的apk信息,因为后面我们需要一个ClassLoader
去加载Apk里面的Activity
类,所以这里提前准备好。
③handleLaunchActivity
里面分为两个部分,一个是performLaunchActivity
函数,一个是handleResumeActivity
函数。
performLaunchActivity
Activity activity = mInstrumentation.newActivity(...); //返回之前创建好的 Application app = r.packageInfo.makeApplication(false,mInstrumentation); //生成ContextImpl Context appContext = createBaseContextForActivity(r,activity); //给activity绑定上下文和一些初始化的工作,如createPhoneWindow activity.attach(appContext,...); mInstrumentation.callActivityOnCreate(activity,r.state); //生命周期的OnCreate activity.performStart(); //生命周期的OnStart return activity
④ handleResumeActivity
:
-> r.activity.performResume() -> mInstrumentation.callActivityOnResume(this); -> activity.onResume()
加载全部内容