《Android内核剖析》笔记第6章应用框架Framework概述-CSDN博客

本文链接：https://blog.csdn.net/m0_62289956/article/details/136861093

本章主要是介绍其中的应用框架层（Application Framework），前面的章节已经提到android是基于多进程设计的，先看看如下手稿图（mac下没找到顺手的UML画图工具），其类名基于4.2.2版本：

从上图中可以看出，核心包括了3+X个进程：

servicemanager守护进程：系统启动时自动启动，通过init.rc设置，主要用来加载binder驱动，实现SystemServer与APP进程之间的消息传递，进而实现IPC中转调用；
surfaceflinger守护进程：系统启动时自动启动，通过init.rc设置，他也是一个驱动，每个窗口都对应一个Surface，该驱动的作用就是把各个Surface显示在同一个屏幕上；
SystemServer进程：该进程是zygote孵化出的第一个进程（详见第9章的描述），可以理解为应用框架的服务端，用来提供各种系统服务，核心的包括窗口管理服务WindowManagerService、活动管理服务ActivityManagerService等；
IActivityManager：管理所有应用程序中的Activity，其实现类是ActivityManagerService；当前台应用APP需要启动某个Activity时，需要先通过binder机制请求IActivityManager，OK之后再回调APP进程中的ActivityThread.ApplicationThread进行真正的Activity加载；
IWindowManager：定义应用窗口各种操作的接口，其实现类是WindowManagerService，基于Binder框架实现各窗口的叠放次序、隐藏或显示；当系统接收到按键或触控事件之后驱动会中转到WindowManagerService，之后他回调APP进程中的PhoneWindow.W实现对各类消息的分发；
IWindowSession：定义应用窗口和应用之间的会话，其实现类是Session；该会话是由IWindowManager负责open并维护的，他负责与APP直接打交道，通过binder机制实现IPC调用，APP通过它实现对IWindowManager的间接调用；
请大家思考一个问题：为什么APP不直接与IWindowManager打交道呢，还要通过IWindowSession来进行一次中转，这样不是反而让系统架构变得更复杂了吗？

其实我也有这个疑问，目前我的理解是IWindowSession中加入了对输入法InputMethod的处理，他实现应用部分窗口和输入法窗口的整合；而IWindowManager是不关心是否有输入法的，在他眼中只有窗口，而窗口里面具有展示的是什么他是不关心的；

APP所在进程：每个APP应用启动后都会是一个独立进程，这就是X的原因，有多少个应用，X就是多少；
Context：Activity/Service组件的基类，可以理解为上下文或者场景，其实现类为ContextImpl；当我们调用startActivity()时就会通过binder机制远程调用到IActivityManager；
Activity：android系统的4大基础组件之一，是应用程序的最小单元类，可以理解为一个页面的控制类，如同java服务端我们所说的action；
IApplicationThread：应用进程提供给系统服务回调的binder接口，执行具体的Activity加载，其实现类为ActivityThread.ApplicationThread；
ActivityThread：应用程序执行的主线程类，每个应用有且只有一个ActivityThread实例，入口为static main()函数，他所在的线程即为UI线程或主线程；
Window：提供通用的窗口操作API的基类；注意：Wms中管理的窗口指的是View，并不是这个Window，这里的Window只是一个抽象类，android系统不仅仅可以在手机上运行，在其他设备上也可以运行，此时他们的窗口操作的实现可以完全不一样；
PhoneWindow：继承至Window，即适用于手机上窗口操作的实现类；
PhoneWindow.DecorView：继承于FrameLayout，他是应用窗口展示的顶级View容器（Top Level），即应用中自己加入的各种View控件其实都是DecorView的child；
ViewParent：定义了View的父辈所需的各类操作API接口，其实现类是 ViewRootImpl/ViewGroup；