继续来研究Android Framework层相关的一些东东,这里是以Android8.0版本的源码进行梳理的,关注的还是其核心流程,不是彻底分析,了解了核心流程是为了了期其大概的原理。

Android系统启动:

这里具体就不分析代码了,因为重点是来分析AMS相关的代码,这里以流程图的方式来展现一下整个的启动,毕境对于一个组件的启动得要建立在整个Android系统启动基础之上的,另外这块的具体源码也不敢看,还没达到这种能直接分析底层的能力,所以先从大局观来了解其流程,下面开始:

接着就启动Linux内核了:

然后再启动init进程:

接着则启动咱们熟知的Zygote进程了:

接下来则启动各种服务了:

而其中当启动了AMS服务之后,则就会启动Launch应用程序了,如下:

我们知道以上服务最终都得到ServiceManager进行注册,因为其实都是一个Binder通信的过程,所以再来复习一下ServiceManager的启动流程。

Binder机制ServiceManager启动:

那知道了ServiceManager何时启动的,接下来重点来看一下咱们这次要研究的AMS(ActivityManagerService)它是怎么注册ServiceManager上的。

AMS注册流程:

其中ServiceManager就是一个服务端的角色,而AMS则是一个客户端的角色。

应用程序启动:

在知道了AMS服务器注册过程之后,接下来则看一下一个Android应用是如何启动的,先来贴一张流程图:

好,接下来分析一下相关的源码,看一下是否如流程图所示,这里还是采用在线的androidxref.com上来进行源码分析,我电脑本地木有下载,省点事:

首先来看一下Zygote进程的启动:

然后它里面有一个main主入口函数:

也就是之前Android系统启动流程图这块所示:

最后则开启死循环来等待Ams的请求,如下:

其实也就是对应这个流程:

好,接下来再来分析一个应用是如何启动的,按流程图上的来:

那就定位到AMS中:

然后:

其中可以看到里面会传要启动应用的各种信息:

然后跟进去瞅一眼:

也就是到了这一步:

流程也就到了这:

其中可以看到设置了一系列的参数:

然后再下一步:

对应代码:

注意上面是“Zygote主模式”,好,如果这个条件不匹配,则会继续往下执行,如下:

好,如果连接成功,则流程会走到了:

而最终的代码在这:

此时我们所熟知的ActivityThread的main()方法就会被调用了,然后整个应用就启动了。

Activity启动:

根Activity启动:

这里先回顾一下整个Android系统启动流程的这一步,串一下:

此时我们点击Launch应用中的某个图标,则会启动该应用的根Activity,其整个流程先看一下流程图:

好,依据此流程来看一下对应的源代码:

此时就会创建Application:

最终会调到这:

走进去瞅一下它的细节:

然后再跟进去:

而对于一些Activity的其它生命周期的启动都是通过ActivityThread中的Handler来实现的:

普通Activity启动:

Intrumentation.execStartActivity()【未跨进程】:

对于Activity的启动我们肯定得要调用startActivity()方法,所以咱们就从这个方法为入口逐一来剖析其里面的机理,还是很复杂的,下面开始:

所以接下来看一下Instrumentation的启动细节:

ActivityManagerProxy.startActivity()【未跨进程】:

而这个ActivityManagerNative在之前https://www.cnblogs.com/webor2006/p/11811650.html分析Binder机制见过,如下:

其实它也是一个典型的AIDL的Binder通信,打开再来瞅一下:

然后它里面还有一个Proxy:

此时就会调用到Proxy中的startActivity()方法进行Binder通讯了:

此时就会通过Binder驱动调用它的Stub的onTransact()的方法,如下:

ActivityManagerService.startActivity()【开始跨进程了】:

此时就会调用ActivityManagerService的startActivity方法,因为它是ActivityManagerNative的具体实现类:

此时,就到了跨进程访问了,在这之前都是在本进程的逻辑,好接下来继续分析:

ActivityStackSupervisor.startActivityMyWait():

其中看注释说明,是切换到用户app的栈了,我们知道Android的Activity是以栈的形式来管理的,所以它是比较核心的了,可以大致看一下它里面有一些栈的管理:

这个栈的管理在之后的分析中还会有提及到,先有个大致印象,先来关注主流程:

而其实又是一个AIDL的过程,进去稍看一下它的细节:

而看一下它具体的实现:

就是从ServiceManager中来找到package相关的服务,标准的AIDL的调用过程,那IPackageManager的具体实现类是哪个呢?其实是这个,也就是继承了IPackageManager中的抽象类Stub的实现类,其实是它:

PackageManagerService.resolveIntent():扫描app,注册组件

那看一下它的resolveIntent()方法:

查看一下这个方法的细节:

然后回到resolveIntent()方法来,则会看到有一个根据优先级来选择最佳的ResolveInfo,如下:

好,这里还得再来说一下PackageManagerService这个很重要的服务,主要是管理包的一些信息,我们知道在apk安装到系统中时,会在/data/app之类的系统目录下存在,而该服务则会扫描注册在清单中的一些包信息,那么看一下构造方法就能找到一些相关的信息,如下:

所以可以看到该服务器就是来扫描一些包的信息用的,而这构造函数的调用是在这里:

所以这也是为啥在之前这块可以看到拿服务就是用的"package"这个key,回忆下:

其实Android的很多核心服务都是这样会往ServiceManager去注册的。

ActivityStackSupervisor.startActivityLocked():验证intent、Class、Permission等,保存将要启动的Activity的Record

好,接下来接着主流程继续:

那看一下它的细节,可以看到各种异常检测,这里截其中一小部分:

最终生成一个ActivityRecord对像来保存相关信息:

ActivityStackSupervisor.startActivityUncheckedLocked():检查将要启动的Activity的launchMode和启动Flag,根据launcheMode和Flag配置task

该方法的实现代码也比较多,就瞅一下它的大致细节既可:

里面真的是非常之复杂,也看不懂,有个大体的了解,重点是了解整个主流程的过程,好继续,直接跳到这方法的最后:

ActvityStack.startActivityLocked:任务栈历史栈配置

它是专门来维护任务栈的进出的,而上面的ActivityStackSupervisor是维护各个栈的信息,职责不一样,那下面来看一下该方法的细节:

在最后:

此时又回到了ActivityStackSupervisor了,如下:

也就是如下:

ActivityStack.resumeTopActivityInnerLocked():查找要进入暂停的Activity

这个里面实现的代码理非常之多,只看核心的,在要跳转到新的Activity之前,先会把一些Activity给暂停了,瞅一下这块的核心流程:

然后在跳到新Activity之前,会先暂停当前的Activity,如下:

ActivityStack.startPausingLocked():通过ipc告诉要暂停的Activity进入暂停

此时看一下这个方法的细节:

而prev.app.thread其实就是ActivityThread,而它里面其实是一个IPC的过程,如下:

此时就会到了ActivityThread中的消息处理中心了,如下:

ActivityThread.handlePauseActivity():

下面具体看一下它的实现:

1、正式让之前的Activity暂停:

2、告诉AMS已经暂停完成:

回到这个方法继续执行,就会发现:

而最终会调到ActivityManagerService,如下:

ActivityManagerService.activityPaused():

然后就会调用到ActivityStack.activityPausedLocked()方法。

ActivityStack.activityPausedLocked():

其中这个方法有一个resumeNext参数,传的true,这里想一想就明白其意思,暂停了当前显示的Activity之后,那肯定得要将要跳转的Activity给显示呀,而这个参数就是控制要显示跳转的Activity的逻辑的,如下:

ActivityStackSuperVisor.resumeTopActivitiesLocked():

ActivityStack.resumeTopActivityLocked():验证是否该启动的Activity所在进程和app是否存在,若存在,直接启动,否则,准备创建该进程。

然后在这个方法里面则会有一个关键的逻辑判断,在启动新的Activity时,先判断是否该Activity是在同一个进程:

如果为ture则代码要启动的Activity为同一个进程,这里就不细看了,如果条件不满足则代表进程不存在,需要创建进程,这里瞅一下,如下:

ActivityStackSuperVisor.startSpecificActivityLocked():该进程不存在,创建进程

好,又回到了这个栈管理类了,看一下它的细节:

ActivityManagerService.startProcessLocked():通过Process.start(“android.app.ActivityThread”)启动进程

ActivityThread.main():

当进程被启动之后,则该进程的ActivityThread.main()方法就会被执行,这块就比较熟了。主要是创建一个Looper。

ActivityThread.attach():

IActivityManager.attachApplication():

而上面的attach的具体实现:

会调用IActivityManager.attachApplication()方法了,此时就会调用ActivityServiceManager.attachApplication(),如下:

然后往这个方法找一下,会有如下核心代码:

ActivityStackSuperVisor.attachApplicationLocked():准备启动应用,先查找MainActivity

此时又回到了这个栈管理大管家,瞅下:

ActivityStackSuperVisor.realStartActivityLocked():IPC通知ActivityThread

ActivityThread.scheduleLaunchActivity():

其中performLaunchActivity方法就是来创建要启动的Activity,稍微看一下细节:

至此关于Activity的启动的主流程就分析完了,太TM复杂了。。可以看到Android底层的代码有很多C/S架构、分模块的思想,真的是博大精深。。

Service启动:

接下来再来分析Android的另一大组件的启动---Service,先来贴一下大体的主流程图:

好,下面来瞅一下源码:

具体细节就不看了,最终会调到ActivityThread的这块:

还有其它相关的一些跟服务相关的东东在里面,大致贴一下:

最新文章

  1. Android开发--apk的生成
  2. SQL 递归树 子父节点相互查询
  3. hihocoder1241 Best Route in a Grid
  4. form表单 无法提交js动态添加的表单元素问题。。
  5. [工作积累] error: bad class file magic (cafebabe) or version (0033.0000)
  6. 理解C#值类型和引用类型
  7. 多平台响应键盘事件!(适用于Cocos2dx 3.0 alpha以上版本号)
  8. Laravel中的队列处理
  9. Nodejs开源项目里怎么样写测试、CI和代码测试覆盖率
  10. tensorflow bias_add应用
  11. 关于ORACLE的SQL语句拼接、替换、截取、排序,联表等...~持续汇总~
  12. Docker学习(转)
  13. tomcat 绑定域名 防止恶意域名绑定
  14. CSS等高布局的7种方式
  15. 学习笔记:Javascript 变量 包装对象
  16. python 爬取网页基础 requests使用
  17. Spring(二十二):Spring 事务
  18. Windows下面安装和配置MySQL(5.6.20)
  19. VMWare共享文件
  20. protoc-gen-go: error:bad Go source code was generated: 163:6: illegal UTF-8 encoding (and 2915 more errors)

热门文章

  1. 20165313-bof进阶
  2. mac os 配置
  3. Spring的JdbcTemplate使用教程
  4. centos 安装mysql8.0.16
  5. 适合 ASP.NET Core 的超级-DRY开发
  6. Linux手动安装新版本Python教程(CentOS)
  7. 第十二节:Asp.Net Core 之分布式缓存(SQLServer和Redis)
  8. Lua代码编写规范
  9. Linux学习笔记之RAID笔记
  10. InstantiationAwareBeanPostProcessor 分析