【FrameWork】①系统服务及应用进程相关，android开发学习网

• 简答：首先启动zygote，再启动SystemServer，然后启动桌面

• 答题技巧：

• 回答出zygote如何启动：init->zygote->native世界->java世界

• 回答出SystemServer是怎么启动的

• 回答出系统服务是怎么启动的

3. 怎么添加一个系统服务

• 关键词

• 方便

• 开放

• IPC 跨进程通信

• 如何使用系统服务

• 根据服务名称获取服务

• 原理如图10

• 系统服务如何注册

• addService传入服务名和Binder对象

• 图11

• 什么时候注册的系统服务

• SystemServer启动时注册的

• 图12

• 独立进程的系统服务

• 以surfaceflinger为例，这是一个native实现的系统服务

• 不管是独立进程的服务还是SystemServer的服务，都需要向SeviceManager注册

• 图13

• 启动binder机制

• 打开binder驱动

• 映射内存，分配缓冲区

• 启动binder线程，进入binder loop

答题要点

• 答题关键点

• 为什么要添加系统服务：给别人用的

• 如何让别人使用：弃用binder机制ipc通信，注册开放出去，让其他调用者可以使用

• 具体有那些事要干

• 添加系统服务时机：SystemServer启动时注册

• 服务端要做的事

• 启用binder机制

• 服务初始化工作

• binder注册到ServiceManager

• 应用端要做哪些事

• 系统服务调用方式Context.getSystemSevice

• 如果自己
  添加服务，也要与系统服务调用保持一致，需要为服务注册serviceFeature

4. 系统服务和bind的应用服务有什么区别

启动方式上的区别

• 系统服务大多数运行在SystemServer中，如AMS WMS PMS

• 图14

• 应用服务：最终会调到AMS中，AMS负责Service的管理和调度，servcie启动和加载由应用端负责

• 图15

注册方式上的区别

• 系统服务：binder实体对象注册到ServiceManager中，只有系统服务才能注册到ServiceManager中

• 应用服务：与系统服务不同，应用服务需要应用bindService，而且需要AMS去请求它

• 图16

使用方式上的区别

• 系统服务：

• 图17

• 应用服务

• 图18

5. ServiceManager的启动和工作原理

ServiceManager的启动流程是怎样的？

• 启动进程

• 启用binder机制：打开binder驱动，映射内存

• 发布自己的服务：

• 等待并响应请求：loop循环，读请求处理请求

怎么获取ServiceManager的binder对象？

• 根据0号handle值，创建一个BpBinder

怎么向ServiceManager添加服务？

怎么从ServiceManager获取服务？

• 先获取ServiceManager的binder对象

• 然后发起getService调用

应用进程相关

---

1. 应用进程是怎么启动的

考察点：

• 了解Linux下进程启动的方式

• 熟悉应用进程启动的基本流程

• 深入理解应用进程启动的原理

什么时候触发的进程启动？

• 查找组件所在进程

• 如果没有启动，就调用AMS的startProcessLocked来发起启动

应用的启动

• AMS向zygote发起启动应用进程的请求之后，会返回进程pid给AMS

• 应用进程启动好之后亲自告诉AMS自己启动好了

• ActivityThread并不是一个线程，它只是一个类

• 图20

题解

• 应用进程是什么时候启动的

• 启动应用组件，如Activity、Service会先判断应用所在进程是否启动，如果没有启动，就会先启动进程

• 进程启动由谁发起

• 由AMS向zygote发起请求，通过socket进行通信

• zygote fork出应用进程，执行ActivityThread的入口main函数，入口函数的java类名是AMS通过socket发给zygote的

• 进程启动之后向AMS报告，注册Application Thread整个启动才算结束，只有向AMS报告，进程才是可用的

• 图22

2. 应用是怎么启用binder机制的

考察点：

• 了解binder是用来干什么的？

• -> 跨进程通信

• 应用里面哪些地方用到了binder机制？

• -> 系统服务，发广播，启动Activity，凡涉及到应用组件的基本都涉及到binder机制

• 应用的大致启动流程是怎样的？

• -> 由AMS向zygote发起请求 -> zygote fork出应用进程 -> 进程启动之后向AMS报告，注册Application Thread -> 进程可用

• 一个进程是怎么启用binder机制的？

• 如下题解

题解

• 首先回答binder启动时机：应用进程启动好之后就支持binder了

• 然后回答如下4点

• 打开binder驱动

• 映射内存，分配缓冲区

• 注册binder线程

• 进入binder loop

3. 谈谈对Application的理解

考察点：

• 了解Application的作用（初级）

• 熟悉Application的类继承关系以及生命周期（中级）

• 深入理解Application的初始化原理（高级）

作用：

• 保存应用进程内的全局变量

• 由于Application比其他四大组件要早，所以可以进行一些初始化操作，SDK init等，

• 提供应用上下文

• 注意：Application与进程相关，有几个进程，就有几个Application

继承关系： Application - ContextWrapper

生命周期：

• 启动

• 构造函数 new Application()

• attchBaseContext

• onCreate

• 结束

• onTerminate()，只在模拟器中有用，不在本题讨论范围

Application怎么初始化

• ActivityThread.attch()->

• 图24

• 总结：

• 如上图，先调用ActivityThread.attch()函数，最终是通过反射创建了Application实例

• 然后会准备上下文 application.attchBaseContext()

• 最后调用了application Oncreate函数

• 整体流程如图25

• 注意：

• 不要在Application的生命周期中执行耗时操作，因为这可能会阻塞应用的UI线程（code过程要小心了，Application onCreate中耗时的操作如sdk耗时的初始化操作要避免）

• Application中静态变量的bug

• 例

• 在Application中声明变量static String name

• MainActivity中初始化name的值

• TestActivity中获取name的值

• 问题：假设应用进程被杀死，切回应用的时候，系统会重建应用并恢复TestActivity，此时name并没有被初始化，所以name为null，这回引发一些异常

4. 谈谈对Context的理解

讲的不错的一篇文章：https://juejin.cn/post/6864346705081401352

考察点

• 了解Context的作用

• 是应用组件的上下文

• 访问特定资源类

• 应用层调用： 启动Activity，发送广播，接收intents

• 图26

inActivity中初始化name的值

• TestActivity中获取name的值

• 问题：假设应用进程被杀死，切回应用的时候，系统会重建应用并恢复TestActivity，此时name并没有被初始化，所以name为null，这回引发一些异常

4. 谈谈对Context的理解

讲的不错的一篇文章：https://juejin.cn/post/6864346705081401352

考察点

• 了解Context的作用

• 是应用组件的上下文

• 访问特定资源类

• 应用层调用： 启动Activity，发送广播，接收intents

• 图26