liuwg1226的专栏

为了方便自己和大家的阅读以及对 Android 知识体系的全面了解，特写出本篇引导文章。一　Android框架层1.1 系统启动流程Android系统启动系列1　进程基础Android系统启动系列2　init进程Android系统启动系列3　zygote进程Android系统启动系列4　SystemServer进程上Android系统启动系列5　SystemServer进程下Android系统启动系列6　AMS的启动Android系统启动系列7　进程创建流程Android系统启动系列8　

分析源码为 android 12。

在 android framework 框架中 activity 和 window 是相互关联的，而他们的管理者 AMS 和 WMS 是怎么来实现这种关联关系的，答案就是通过 token。首先大家需要了解一下 LayoutParams，当然属性很多，简单了解即可：这里就说到了 token 的问题，应用窗口程序和子窗口均需要获取到 Activity 的 token。那么 token 是什么呢？

本文是对全局手势识别进行分析，那什么是全局手势呢？简单来说就是在任何界面都需要识别的手势，比如：在任何界面从手机屏幕左侧滑动，当前的界面会退出 (类似 back 键)。我们知道，在 Android 系统中一个 Activity 在显示时，当对屏幕触摸事件进行响应时，经过了许多逻辑处理，详细分析可以参考之前对 IMS 原理分析的一系列文章：中的输入系统章节。接下来对全局手势事件注册监听及处理进行分析。目前使用10.0代码分析。

Android 系统服务进程 system_server，进入消息循环前的最后一步，就是调用 AMS 的 systemReady() 方法。今天我们分析一下这里的流程。

一 概述之前写过几篇 Input 系统相关的分析，但是比较零散，本篇开始准备基于 Android 11 代码看一下 Android Input 子系统，首先来学习下 Linux 下的 INotify 与 Epoll 机制，这两个机制主要是对 Input 子系统下的文件节点的增删和文件节点发生的事件进行监听。二 INotify机制INotify 是 Linux 提供给用户态监听内核文件系统变化的机制，可以监听文件/目录的增删等。INotify 的用法很简单，首先需要调用如下代码创建一个文件描述符：in

一　概述从上一篇文章 Android Input系统6 事件处理全过程 中，我们知道当输入事件从 InputDispatcher 通过 server 端 InputChannel 将输入事件发送给应用程序的 client 端，其实最终事件被发送到了 java 层的 ViewRootImpl 中。对于 java 层的按键分发从 ViewRootImpl.java 的 deliverInputEvent 开始，代码如下：private void deliverInputEvent(QueuedInputE

一　概述二 定义ContentProvider，即内容提供者，是 Android 四大组件之一三 作用进程间进行数据交互 & 共享，即跨进程通信四 原理ContentProvider 的底层是采用 Android 中的 Binder 机制五 具体使用关于 ContentProvider 的使用主要介绍以下内容：5.1 统一资源标识符（URI）定义：Uniform Resource Identifier，即统一资源标识符作用：唯一标识 ContentProvider &a

一　概述Activity 的启动分为不同进程间和相同进程的启动。由于进程间 Activity 启动流程包括了相同进程 Activity 启动的流程。因此本文只分析不同进程间，比如点击 Launcher 桌面图标启动 Activity 的整个过程。在阅读本篇文章之前，建议同学们先了解下 AMS 相关的数据结构和管理机制，可参考 Android四大组件系列1　AMS相关数据结构。本篇文章接上一篇文章 Android四大组件系列2　Activity启动流程（上）继续分析。上一篇文章我们分析了 startAct

一　概述在本系列的前面文章中，我们介绍了 PackageInstaller 的初始化和安装 APK 过程、PMS 处理 APK 的安装和 PMS 的创建过程，这些文章中经常会涉及到一个类，那就是 PackageParser，它用来在 APK 的安装过程中解析 APK，那么 APK 是如何被解析的呢？这篇文章会给你答案。二　引入PackageParserAndroid 系统中有很多包，比如应用程序的 APK，Android 运行环境的 JAR 包（比如 framework.jar）和组成 Android

一　概述PMS的创建过程分为两个部分进行讲解，分别是SyetemServer处理部分和PMS构造方法。其中SyetemServer处理部分和AMS和WMS的创建过程是类似的，可以将它们进行对比，这样可以更好的理解和记忆这一知识点。二　SyetemServer处理部分PMS是在SyetemServer进程中被创建的，SyetemServer进程用来创建系统服务，不了解它的可以查看Android系统启动流程（三）解析SyetemServer进程启动过程这篇文章。从SyetemServer的入口方法mai

在上一篇文章 Android包管理机制2 PackageInstaller安装APK 中，我们学习了 PackageInstaller 是如何安装 APK 的，最后会将 APK 的信息交由 PMS 处理。那么 PMS 是如何处理的呢？这篇文章会详细分析其中的细节。一　PackageHandler处理安装消息APK 的信息交由 PMS 后，PMS 通过向 PackageHandler 发送消息来驱动 APK 的复制和安装工作。先来查看 PackageHandler 处理安装消息的调用时序图。接着上一

一　概述在本系列上一篇文章 Android包管理机制1 PackageInstaller 初始化 中我们学习了 PackageInstaller 是如何初始化的，这一篇文章我们接着学习 PackageInstaller 是如何安装 APK 的。本系列文章的源码基于 Android8.0。二　PackageInstaller中的处理紧接着上一篇的内容，在 PackageInstallerActivity 调用 startInstallConfirm 方法初始化安装确认界面后，这个安装确认界面就会呈现给用

一　概述包管理机制是 Android 中的重要机制，是应用开发和系统开发需要掌握的知识点之一。包指的是 Apk、jar 和 so 文件等等，它们被加载到 Android 内存中，由一个包转变成可执行的代码，这就需要一个机制来进行包的加载、解析、管理等操作，这就是包管理机制。包管理机制由许多类一起组成，其中核心为 PackageManagerService（PMS），它负责对包进行管理，如果直接讲 PMS 会比较难以理解，因此我们需要一个切入点，这个切入点就是常见的 APK 的安装。讲到 APK 的安

一　概述ClientLifecycleManager 是管理 Activity 生命周期的，在 ActivityTaskManagerService 里面提供 getLifecycleManager 来获取此对象，其中 mLifecycleManager 是在 ActivityTaskManagerService 的构造方法里面初始化的。ActivityTaskManagerService.javapublic class ActivityTaskManagerService extends IAct

本章节思维导图如上。主要讲述了 surafce 测试程序 demo 的第3步中的提交 Buffer 阶段。解锁定（最关键）并提交 Buffer 的过程。一　概述该部分代码是在上一章节中 Surface 测试程序源码的精简版，保存了最关键的流程，如下所示：#include <cutils/memory.h>#include <utils/Log.h>#include <binder/IPCThreadState.h>#include <binder/Pr.

本章节思维导图如上。主要讲述了 surafce 测试程序 demo 的第3步中的获取 Buffer，锁定（最关键）并写入 Buffer 的过程。一　概述该部分代码是在上一章节中 Surface 测试程序源码的精简版，保存了最关键的流程，如下所示：#include <cutils/memory.h>#include <utils/Log.h>#include <binder/IPCThreadState.h>#include <binder/Proces.

一　概述在分析 Choreographer 机制之前，同学们需要先了解一些关于 Android 显示系统的一些基础概念和背景。可以参考 Android图形显示系统1　概述我们知道 Google 在 Android 4.1 系统中对 Android Display 系统进行了优化：在收到 VSync 信号后，将马上开始下一帧的渲染。即一旦收到 VSync 通知，CPU 和 GPU 就立刻开始计算，然后把数据写入 buffer。本篇文章重点分析 Choreographer，以及 Choreographer

一　概述我们知道 Handler 与 Looper、MessageQueue 共同实现了线程间消息传递。MessageQueue 的底层实现是利用管道和 epoll 机制来实现的。当我们查看 Looper.loop() 方法时，会发现其中有一个无限循环。那么这其中的原因又是啥呢。当调用 Looper.prepare() 方法时，我们知道会创建一个 Looper 对象，在 Looper 的构造函数中，同时也创建了 MessageQueue，而在 MessageQueue 的构造函数中又调用了 native

一　概述在Android平台上，要执行异步工作时，我们常常会用到AsyncTask。这个类可以算是历史悠久，早在Android 1.5版时，它就存在了。AsyncTask的使用方法比较简单，无非是创建一个AsyncTask派生类对象，重写其doInBackground()函数，然后在合适时机调用这个对象的execute()或executeOnExecutor()函数即可。private static class MyTask extends AsyncTask<Void, Void, Void&

一　概述在文章 Android消息机制1　(Java层) 中讲解了 Java 层的消息处理机制，其中 MessageQueue 类里面涉及到多个 native 方法，除了 MessageQueue 的 native 方法，native 层本身也有一套完整的消息机制，用于处理 native 的消息，如下图Native 层的消息机制。在整个消息机制中，MessageQueue 是连接 Java 层和 Native 层的纽带，换言之，Java 层可以向 MessageQueue 消息队列中添加消息，Nat

一　概述在整个 Android 的源码世界里，有两大利剑，其一是 Binder IPC 机制，另一个便是消息机制(由 Handler/Looper/MessageQueue 等构成)。关于 Binder 我们已经详细介绍过了，今天我们来分析 Android 的消息机制，Android 中有大量的消息驱动方式来进行交互，比如 Android 的四大组件 Activity，Service，Broadcast 和 ContentProvider 的启动过程的交互，都离不开消息机制，Android 某种意义上也可

一　概述我们再次回顾下上一篇文章 Android图形显示系统5　图像缓冲区(上) 描述的图像缓冲区。１．Android 图形缓冲区由哪些部分组成Android 的图形缓冲区由 Surface，BufferQueue，Layer，GraphicBuffer 四部分组成。BufferQueue 中的 slots 数组最多能存储 64 个 GraphicBuffer，而 GraphicBuffer 就是真正被分配内存，并能存储图形数据的缓冲区２．Surface 和 Layer 分别是什么Surface

一　概述前面两篇文章介绍了图像生产者和图像消费者，终于到了最后一篇——图像缓冲区，这三者一起构成了一个完整的 Android 图像显示系统。Android 中的图像生产者 OpenGL，Skia，Vulkan 将绘制的数据存放在图像缓冲区中，Android 中的图像消费 SurfaceFlinger 从图像缓冲区将数据取出，进行加工及合成。那么图像缓冲区是什么呢？它是如何创建出来的呢？又要如何使用它呢？它的存储原理是什么呢？读完这篇文章，你就能回答这些问题了。1.1 图像缓冲区在讲解图像的生产者时，多

一　概述在上一篇文章 Android图形显示系统2　图像消费者中，详细的讲解了图像消费者，我们已经了解了 Android 中的图像元数据是如何被 SurfaceFlinger，HWComposer 或者 OpenGL ES 消费的，那么，图像元数据又是怎么生成的呢？这一篇文章就来详细介绍 Android 中的图像生产者—— SKIA，OPenGL ES，Vulkan，他们是 Android 中最重要的三支画笔。二　SkiaSkia 是谷歌开源的一款跨平台的 2D 图形引擎，目前谷歌的 Chrome 浏

一　概述在上一篇文章 Android图形显示系统2　图像消费者中，详细的讲解了图像消费者，我们已经了解了 Android 中的图像元数据是如何被 SurfaceFlinger，HWComposer 或者 OpenGL ES 消费的，那么，图像元数据又是怎么生成的呢？这一篇文章就来详细介绍 Android 中的图像生产者—— SKIA，OPenGL ES，Vulkan，他们是 Android 中最重要的三支画笔。二　OpenGL ES什么是 OpenGL 呢？OpenGL 是一套图像编程接口，对于开发者

一　概述对于Android开发者来说，我们或多或少有了解过Android图像显示的知识点，刚刚学习Android开发的人会知道，在Actvity的onCreate方法中设置我们的View后，再经过onMeasure，onLayout，onDraw的流程，界面就显示出来了；对Android比较熟悉的开发者会知道，onDraw流程分为软件绘制和硬件绘制两种模式，软绘是通过调用Skia来操作，硬绘是通过调用Opengl ES来操作；对Android非常熟悉的开发者会知道绘制出来的图形数据最终都通过GraphiB

一　概述接上篇文章对代码进行分析该部分代码是在上一章节中 Surface 测试程序源码的精简版，保存了最关键的流程，如下所示：#include <cutils/memory.h>#include <utils/Log.h>#include <binder/IPCThreadState.h>#include <binder/ProcessState.h>#include <binder/IServiceManager.h>#incl.

一 frameBuffer与Android当我们的程序想要在屏幕上显示内容时，我们的机制是直接向 FrameBuffer（后面简称FB）写入内容来实现。接下来谈谈 Android 使用 FB 的策略：如果只有一个 FB，当 APP 写入速度大于 LCD 显示速度时没问题；当 APP 写入速度小于等于 LCD 显示速度时，就会产生卡顿和闪烁，为了解决这个问题，一般采用2个以上 FB。以2个 FB 为例，APP 写入 FB0，LCD 此时渲染 FB1，FB0 写入结束后，LCD 渲染 FB0，此时 APP.

一 概述上一篇文章我们讲述了Android View事件分发机制。如果你对View的事件分发还不熟悉，建议先去看一下 一文读懂Android View事件分发机制 它是我们今天滑动冲突解决的理论基础！如果你已经对View的事件分发机制了然于胸，那么我们就根据View的事件分发机制，来给大家详细聊一下滑动冲突！二 滑动冲突的常见场景与处理思路当我们内外两层View都可以滑动时候，就会产生滑动冲突！常见的滑动冲突场景：1.外层与内层滑动方向不一致，外层ViewGroup是可以横向滑动的，内层Vie

一 概述Android View 虽然不是四大组件，但其并不比四大组件的地位低。而View的核心知识点事件分发机制则是不少刚入门同学的拦路虎。ScrollView嵌套RecyclerView(或者ListView)的滑动冲突这种老大难的问题的理论基础就是事件分发机制。事件分发机制面试也会经常被提及，如果你能get到要领，并跟面试官深入的灵魂交流一下，那么一定会让面试官对你印象深刻，抛出爱的橄榄枝想想都有点小激动呢。那么就让我们从浅入深，由表及里的去看事件分发机制，全方位，立体式，去弄懂这个神秘的事件分发

一、概述上两篇文章对EventBus和使用详细分析了。了解到EventBus是发布/订阅者模式，适用于Android和Java的发布/订阅事件总线。主要功能是替代Intent、Handler、BroadCast在Activity、Fragment、Service线程之间传递消息。它能够简化应用组件间的通信，解耦(有效分离)事件的发送者和接收者，避免复杂和容易出错的依赖和生命周期问题，开销小，代码更优雅。EventBus的官网原理图我们再看一遍，发布者通过EventBus发布事件，订阅者通过EventB

一、概述我们在上一篇文章中介绍了EventBus普通事件和粘性事件的使用，对EventBus也有了一个大概的了解，但是我们对事件和发布者订阅者的关系有没有弄清楚呢？继续来深入了解。EventBus使用的是发布/订阅者模式：发布者通过EventBus发布事件，订阅者通过EventBus订阅事件，当发布者发送事件时，订阅该事件的订阅者的事件处理方法将被调用。从图中看出，发布者发送一个事件时，则该事件将会同时传递给一个或多个该事件的订阅者。什么是发布/订阅者模式？订阅者(Subscriber)把自己想

一　概述EventBus是适用于Android和Java的发布/订阅事件总线。主要功能是替代Intent、Handler、BroadCast在Activity、Fragment、Service线程之间传递消息。EventBus能够简化应用组件间的通信，解耦(有效分离)事件的发送者和接收者，避免复杂和容易出错的依赖和生命周期问题，开销小，代码更优雅。Andorid组件间通信，可能都是用Handler消息机制或者广播机制来实现通信，但是它们代码量大，组件上容易产生耦合 。为什么选择使用EventBus来做通

一　概述在手机客户端尤其是 Android 应用的开发过程中，我们经常会接触到“硬件加速”这个词。由于操作系统对底层软硬件封装非常完善，上层软件开发者往往对硬件加速的底层原理了解很少，也不清楚了解底层原理的意义，因此常会有一些误解，如硬件加速是不是通过特殊算法实现页面渲染加速，或是通过硬件提高 CPU/GPU 运算速率实现渲染加速。本文尝试从底层硬件原理，一直到上层代码实现，对硬件加速技术进行简单介绍，其中上层实现基于Android 10.0。二　了解硬件加速对App开发的意义对于 App 开发者，

一　概述上篇分析了自定义 View 绘制流程及其常用方法：Android View绘制4　Draw过程（上），本篇将从代码的角度深入分析硬件加速绘制与软件绘制。通过本篇文章，你将了解到：1、软件绘制流程2、硬件加速绘制流程2、LayerType 对绘制的影响3、Canvas 从哪里来到哪里去4、绘制流程全家福二　软件绘制流程上篇说过在ViewRootImpl->draw(xx)里软件绘制与硬件加速绘制分道扬镳：上图是Window 区分硬件加速绘制与软件绘制的入口。由易到难，先

一　概述上篇分析了自定义View绘制流程及其常用方法：Android 自定义View之Draw过程(上)本篇将以硬件加速绘制与软件绘制入口为切入点，通过本篇文章，你将了解到：1、什么是硬件加速2、硬件加速的开启与关闭3、硬件加速绘制与软件绘制分道扬镳的地方4、初步认识LayerType什么是硬件加速Android 3.0 之前，绘制操作通过CPU完成的，而在Android 3.0（含）之后，Android 2D 渲染管道支持硬件加速，也就是说Canvas绘制操作会使用GPU渲染。硬件加

一　概述Android 展示之三部曲：Measure(测量)---->Layout(摆放)---->Draw(绘制)前边我们已经分析了：Measure(测量)---->Layout(摆放)，他们最主要的任务是：确定View/ViewGroup可绘制的矩形区域。接下来将会分析，如何在这给定的区域内绘制想要的图形。Draw 过程涉及知识较多，分为上中下三篇通过本篇文章，你将了解到：1、为什么要自定义View2、一个简单的Demo3、View Draw过程4、ViewGro

在上篇文章：Android 自定义View之Measure过程，我们分析了Measure过程，本次将会掀开承上启下的Layout过程神秘面纱，通过本篇文章，你将了解到：1、关于Layout 简单类比2、一个简单Demo3、View Layout过程4、ViewGroup Layout过程5、View/ViewGroup 常用方法分析6、为什么说Layout是承上启下的作用关于Layout 简单类比在上篇文章的比喻里，我们说过：老王给三个儿子，大王（大王儿子：小小王）、二王、三王分配了具体

一　MeasureSpec对于测量我们来说几个知识点,了解这几个知识点，之后的实例分析你才看得懂。1、MeasureSpec 的理解对于View的测量，肯定会和MeasureSpec接触，MeasureSpec是两个单词组成，翻译过来“测量规格”或者“测量参数”，很多博客包括官方文档对他的说明基本都是“一个MeasureSpec封装了从父容器传递给子容器的布局要求”,这个MeasureSpec 封装的是父容器传递给子容器的布局要求，而不是父容器对子容器的布局要求，“传递” 两个字很重要，更精确的说法应