super_marie的博客

从WMS角度分析Activity启动流程

书接上回，在 AMS侧解析Activity启动 篇章中，我们大致梳理了 Activity 启动过程中涉及到堆栈的整体流程，本篇再让我们从 Activity 生命周期的角度来梳理整个流程顺着上一篇 解析Activity启动-堆栈篇 的流程，在启动Activity时，会在 函数中调用 函数对发起者Activity触发 Pause 动作，那么我们就按照启动顺序，进行逐一分析首先是调用起点，剔除与Pause流程无关的代码；可以看到，只有在对应 stack中存在 时，才会去触发进行Pause流程，很好理解，

从堆栈角度看Activity的启动

Logd框架梳理1. 整体框架Android P的logd总体框架图如下所示：和旧版本方案的差异，主要就是去掉了logger驱动，引入了logd进程，将logbuffer放到了用户空间logd部分各模块功能如下图表所示：模块功能LogReader线程监听 /dev/socket/logdr,将日志发送给client端logListener线程监听 /dev/socket/logdw，将日志保存到logBuffer中，还会在有日志存入时通知 LogReade

当一个输入事件经过上面的层层判断，确认了处理者并且完成处理之后，就会调用 `finishInputEvent()` 函数结束输入事件的调用，那么在结束输入事件的处理时又会有哪些处理逻辑，最终如何将 **InputDipatcher** 对象中存储在等待处理反馈队列 **waitQueue** 中的输入事件给删除的呢？接下来就让我们从 `finishInputEvent()` 函数入手，开始逐一分析

经过上面的分析，此时 **InputMessage** 对象借由 **server** 端 **InputChannel** 的 **Socket** 对象发送到了 **Client** 端 InputChannel 的 **Socket** 处，而 **Client** 端 **InputChannel** 添加了 **Socket** 的监听，当 存在消息时，就会调用 `NativeInputEventReceiver::handleEvent()` 函数进行处理，那么接下来我们就从此处开始进行梳理接

经过 part 1的分析，我们可以知晓**InputDispatcher**对象是如何获取到输入事件的，那么接下来就让我们来梳理一下，当 **InputDispatcher** 获取到输入事件后，是如何进行分发的

InputReader 事件获取事件分发①. InputReader 事件获取⑴ `processEventsLocked()`1. `processEventsForDeviceLocked()`2. `process()`3. `process()`4. `processKey()`ⅰ`getListener()`Ⅱ `notifyKey()`⑵. `flush()`1. `notify()`总结：事件分发经过前两篇的分析，我们先来简单简述一下事件分发的流程：当有键盘事件发生，InputR

InputChannel在前面一章，我们分析了 InputManager 的创建和启动，并且详细分析了 在 InputReader 线程中，用来获取 事件的 EventHub 的创建以及事件获取的流程。那么接下来在介绍键盘事件的分发流程之前，先来梳理一下 InputChannel 的注册流程。在一个 Activity 启动时，会通过与该Activity关联的ViewRoot对象来和 InputManager 建立一个连接，这个连接就是 InputChannel，而这个 InputChannel

文章目录InputManagerService和输入事件①. InputManagerService的创建1. `InputManagerService()`2. `nativeInit()`3. `NativeInputManager()`4. `InputManager()`5. InputReader 和 InputDispatcher 线程的创建：5.1.1. `createInputDispatcher()`5.1.2. `InputDispatcher()`5.2.1. `createInp

经过前面几篇文章得分析，可以大致知晓从native层往下是如何进行SM的获取，那么这篇文章将着手从JAVA层开始梳理service服务端如何添加服务到SM中的addService()整体流程简介照例先给出整个流程的时序图addService整个流程的示意图如下：AMS启动本篇以AMS的addService为例进行梳理分析，其他的服务也都是大同小异，这里简单说一下AMS服务的启动AMS是由SystemServer进行开启的，我们从AMS开启入手。代码路径：androi.

首先需要说明的是，本篇文章是从native层开始进行Service Manager的获取回到Binder的框架图，本质上Service的底层实体就是一个BBinder实体，而Clinet客户端想要调用某个service端，需要拿到对应service端的代理接口，也就是BpBinder对象。如上面的框架图，Client端想要和Service端进行通信，那么就需要使用defaultServiceManager()方法获取到IServiceManager对象，一旦拥有了IServiceManag..

Service Manager的用处在正式展开叙述之前，我们需要先说明一下为什么要进行Service Manager的启动和获取。回到binder-框架认知中的整体框架图可知：客户端想要和服务端进行通信，首先需要和对应服务端建立连接，那么客户端是怎么知道，并且完成和服务端进行连接的呢？这就需要用到Service Manager服务了，其实对应客户端和服务端的连接通信都是通过Service Manager来建立的，之所以Service Manager可以实现相关需求，原因如下：Service M

通过上两个篇章,对于Binder的整体框架,以及其中驱动层的逻辑梳理之后,接下来需要对Binder的JNI层注册进行一个梳理1. Zygote进程的启动解析init.rc文件Zygote是由init进程通过解析对应的init.zygote.rc文件进行创建的,这里可以看一下 init.zygote32.rc 文件文件路径:android/system/core/rootdir/init.zygote32.rc//这里会去找app_process文件夹下的app_main.cpp文件.

通过Binder框架图示,对于Binder的整体流程有了一个基本的认知后,接下来就可以深入每一个部分进行逐一的探究,首先先来探究:Binder的所谓一次拷贝究竟是什么?这个一次拷贝又是发生在何处?1 一次拷贝的原理解析1.1 内核空间和用户空间的数据交互如上篇 binder-框架认知 中 3.1章节 所陈述的,在Linux中,用户进程和内核空间是隔离的,而内核空间和用户空间之间的相互访问只能通过系统调用(System Call)进行,对于用户空间和内核空间之间的数据交互,常用的是以下的几个函数:.

BinderBinder是什么?1. Binder的概念对于Binder有以下这几种解释:Binder机制是Android系统独有的IPC方式，也是Android系统的核心Linux内核中的驱动文件（/dev/binder）在应用层的开发中，它是一个实现了IBinder接口的一个类,从而具备跨进程通讯的能力从Android Framework的角度来看，它连接了Client、Server、Service Manager和Binder驱动程序。形成一套C/S的通信模式实际上,抛去实

HandlerHandler定义Handler本质上是线程间的一个消息传递和处理的机制Handler通信实现的方案本质上是内存共享的方案同一个进程内存是共享的Handler是整个app通信的框架，在ActivityThread里面感受到，整个App都是用它来进行线程间的协调那么以上的这些结论是怎么得来的呢?Handler流程我们通常使用Handler的方式class Test { Handler mHandler = new Handler() {