Context实现类创建过程源码分析记录

此文章纯粹个人看源码时的记录,所以只关注我需要的东西,如果读者观看时涉及到不了解的知识点,建议自己看源码或者评论中提问

image.png

小技巧:在看安卓源码的时候,看到使用IActivityManager就知道这是应用进程在跨进程找AMS”办事“了,AMS给应用进程跨进程”回复“会用IApplicationThread,而IApplicationThread的操作都会通过handler发给ActivityThread来做。
所以对application、activity等的启动无从入手的话,可以直接去ActivityThread去看各种handle开头的方法。

1、Application和其内部ContextImpl创建过程

从ActivityThread的main()方法开始

IActivityManger和IApplicationThread这两个binder机制类相当于两国交流的外交官,属于沟通的桥梁,并不是真正做事的人,就不单独画出来了。比如IApplicationThread中各种操作最终都是发消息让ActivityThread来做。


Application和其内部ContextImpl创建过程.png

2、Activity和其内部ContextImpl创建过程

在看这块源码过程中产生了一个疑问,AMS对application和activity的创建是没有直接代码上的先后顺序的,那么到底一个app启动时是先创建根activity还是application呢?
查阅一些文章和启动相关源码,发现四大组件任意一个在启动时会先检查程序进程是否创建,如果没有会先请求zygote创建,zygote 会fork出一个新进程并分配pid,进程创建完就会走ActivityThread的main方法(文中第一张图),此时算是进入这个应用程序的大门。
举个例子,activity的创建检查并创建进程的地方在:com.android.server.am.ActivityStackSupervisor#startSpecificActivityLocked-----AMS.startProcessLocked
至此,对四大组件为什么能叫四大组件的原因更明白了几分,它们不止是拥有context这个访问系统的权限凭证,更是能向系统请求创建进程的大佬。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容