qq_34231329的博客

在上一篇文章中，我们分析了一个Service是怎么启动的，这次我们再来看看一个Service是如何被停止的，什么情况下Service会被重建以及它的重建过程

在之前的文章中，我们已经分析过了四大组件中Activity和ContentProvider的启动流程，这次我们就来讲讲四大组件之一的Service是如何启动和绑定的

我们在之前的几篇Activity启动流程分析中已经了解了Activity一半的生命周期，接下来这篇文章我们就来分析一下Activity销毁相关的生命周期

本篇分析了Activity启动的两条路径，在两条路径归一后，Activity是怎样启动的，Activity启动时的生命周期变换是怎样执行的

在上一篇文章中，我们分析了Activity启动流程中的一小部分，基本上可以算是Activity启动的前置准备工作，本篇文章我们将会分析App进程启动的主要流程

作为一名Android开发，我们最熟悉并且最常打交道的当然非四大组件中的Activity莫属，这次我们就来讲讲一个Activity是怎样启动起来的

我们在上一片文章Android源码分析 - Framework层的Binder（客户端篇）中，分析了客户端是怎么向服务端通过驱动发起请求，然后再接收服务端的返回的。本篇文章，我们将会以服务端的视角，分析服务端是怎么通过驱动接收客户端的请求，处理，然后再返回给客户端的。上篇文章我们是以作为服务端分析的，本篇文章我们还是围绕着它来做分析，它也是一个比较特殊的服务端，我们正好可以顺便分析一下它是怎么成为驱动的的是在独立的进程中运行的，它是由进程从文件中解析并启动的，......

本篇以分支作为基础解析我们在之前的文章中，从驱动层面分析了是怎样工作的，但驱动只涉及传输部分，待传输对象是怎么产生的呢，这就是层的工作了。我们要彻底了解的工作原理，不仅要去看驱动层，还得去看层以及应用层（）我们还是以第一次见到的地方开始分析，我们选取方法来分析（这个方法既有入参也有返回），抛除掉它缓存和的部分，最核心的代码就一句BinderInternal.getContextObject我们从开始看起，这个函数是一个函数，他被实现在中ProcessState我们在这里可以发现一个比较关键的类，它是

本篇以android-11.0.0_r25作为基础解析PC启动会通过BIOS引导，从0x7c00处找到以0xaa55为结尾的引导程序启动。而Android通常使用在移动设备上，没有PC的BIOS，取而代之的是BootLoader。在CPU上电复位完成后，会从一个固定的地址加载一段程序，即BootLoader，不同的CPU可能这个地址不同。BootLoader是一段引导程序，其中最为常见的为U-boot，它一般会先检测用户是否按下某些特别按键，这些特别按键是uboot在编译时预先被约定好的，用于进入调试模式。

本篇以android-11.0.0_r25作为基础解析上一篇文章Android源码分析 - init进程，我们分析了Android第一个用户进程init进程的启动过程和之后的守护服务init进程启动了很多服务，例如Zygote，ServiceManager，MediaServer，SurfaceFlinger等，我们平常写Android应用都是使用Java语言，这次我们就先从Java世界的半边天：Zygote进程 开始分析Zygote意为受精卵，它有两大作用，一是启动SystemServer，二是孵化启动A

本篇以android-11.0.0_r25作为基础解析上一篇文章Android源码分析 - Zygote进程，我们分析了Android 进程的启动和之后是如何接收消息创建App进程的在上一章中，我们说了，的一大作用就是启动，那么是怎么启动的呢？启动后又做了些什么呢？我们分上下两篇来分析，本篇介绍是如何启动的主要是用来创建系统服务的，譬如我们熟知的，都是由它创建的我们从上一篇文章的开始，类的源码路径为之前在c++代码中JNI调用Java函数的时候，带了参数，在这里就会通过这个参数判断是否启动，接下来调用方法

本篇以android-11.0.0_r25作为基础解析上一篇文章Android源码分析 - SystemServer（上）我们分析了进程是怎么被启动起来的，今天这篇，我们来分析进程启动后做了什么我们上一章中讲到，进程出子进程后，最终调用了方法，源代码在中，我们来看看做了什么构造方法非常简单，就是先new了一个对象，然后调用它的方法，我们先看一下构造方法工厂模式首先，先从系统属性中获取工厂模式级别，有三种属性：它们被定义在中紧接着便开始执行方法可以看到，方法主要做了以下工作其中，创建这一步是由完成的

本篇无源码分析，只对Binder做通信过程和基础架构的介绍是中最重要的一种进程间通信机制，基于开源的George Hoffman当时任Be公司的工程师，他启动了一个名为的项目，在Be公司被ParmSource公司收购后，由Dinnie Hackborn继续开发，后来成为管理的进程的基础。在Hackborn加入谷歌后，他在的基础上开发出了(以下简称)，用来完成的进程通信。作为一名开发，我们每天都在和打交道，虽然可能有的时候不会注意到，譬如：它们都和有着莫切关系，当碰到上面的场景，或者一些疑难问题的时候，理解机

本篇以aosp分支，kernel分支作为基础解析上一篇文章Android源码分析 - Binder概述我们大概了解了一下选用的原因，以及的基本结构和通信过程。今天，我们便开始从驱动层代码开始分析的机制驱动部分代码不在项目中，所以我们需要单独一份驱动代码由于我的开发设备是pixel2，查了内核版本号为，对应的分支为，所以今天的分析我们也是基于此分支我是从清华大学镜像站的代码，高通的设备，所以地址为：https://aosp.tuna.tsinghua.edu.cn/android/kernel/msm.git

本篇以aosp分支，kernel分支作为基础解析上一篇文章Android源码分析 - Binder驱动（上），我们已经了解了驱动设备是如何注册的，并且分析了和操作函数，接下来我们继续分析驱动中最重要的部分我们先简单介绍一下函数，这个函数是用来控制设备的，函数原型如下：第一个参数为设备的文件描述符第二个参数为命令码，它由驱动方自定义，用户通过命令码告诉设备驱动想要它做什么后面为可选参数，具体内容和有关，是传入驱动层的参数内核是这么定义一个命令码的这样，一个命令就变成了一个整数形式的命令码了，为了使用起来方便

本篇以aosp分支，kernel分支作为基础解析上一篇文章Android源码分析 - Binder驱动（中），我们分析了中的写操作部分，了解了请求的发起与调度，接下来我们就进行驱动的最后一部分分析，我们还是先从后的命令码开始binder_thread_read这是进行读操作的函数，这个函数也是比较长，我们同样将它分成几个部分：在此之前我们需要先看一下之前提到的，在中的域成员，前面我们只是注释了这个域表示线程状态，这里我们介绍一下它有哪些取值：这一部分先检查是否有可用的待处理，如果有的话进入到下一部分，