SS诞生后,便和生父Zygote分道扬镳,它有了自己的历史使命。它的使命是什么呢?其代码如下所示:
~~~
pid =Zygote.forkSystemServer();
if(pid == 0) { //SS进程返回0,那么下面这句话就是SS的使命:
handleSystemServerProcess(parsedArgs);
}
~~~
SS调用handleSystemServerProcess来承担自己的职责。
**ZygoteInit.java**
~~~
private static void handleSystemServerProcess(
ZygoteConnection.ArgumentsparsedArgs)
throws ZygoteInit.MethodAndArgsCaller {
//关闭从Zygote那里继承下来的Socket。
closeServerSocket();
//设置SS进程的一些参数。
setCapabilities(parsedArgs.permittedCapabilities,
parsedArgs.effectiveCapabilities);
//调用ZygoteInit函数。
RuntimeInit.zygoteInit(parsedArgs.remainingArgs);
}
~~~
好了,SS走到RuntimeInit了,它的代码在RuntimeInit.java中,如下所示:
**RuntimeInit.java**
~~~
public static final void zygoteInit(String[]argv)
throws ZygoteInit.MethodAndArgsCaller {
//做一些常规初始化
commonInit();
//①native层的初始化。
zygoteInitNative();
intcurArg = 0;
for (/* curArg */ ; curArg < argv.length; curArg++) {
String arg = argv[curArg];
if (arg.equals("--")) {
curArg++;
break;
} else if (!arg.startsWith("--")) {
break;
} else if (arg.startsWith("--nice-name=")) {
String niceName = arg.substring(arg.indexOf('=') + 1);
//设置进程名为niceName,也就是"system_server"
Process.setArgV0(niceName);
}
}
//startClass名为"com.android.server.SystemServer"
String startClass = argv[curArg++];
String[] startArgs = new String[argv.length - curArg];
System.arraycopy(argv, curArg, startArgs, 0, startArgs.length);
//②调用startClass,也就是com.android.server.SystemServer类的main函数。
invokeStaticMain(startClass, startArgs);
}
~~~
对于上面列举出的两个关键点,我们一个一个地分析。
1. zygoteInitNative分析
先看zygoteInitNative,它是一个native函数,实现在AndroidRuntime.cpp中。
**AndroidRuntime.cpp**
~~~
static voidcom_android_internal_os_RuntimeInit_zygoteInit(
JNIEnv* env,jobject clazz)
{
gCurRuntime->onZygoteInit();
}
//gCurRuntime是什么?还记得我们在本章开始说的app_process的main函数吗?
int main(int argc, const char* const argv[])
{
AppRuntime runtime;// 就是这个。当时我们没顾及它的构造函数,现在回过头看看。
}
//AppRuntime的定义
class AppRuntime : public AndroidRuntime
static AndroidRuntime* gCurRuntime = NULL; // gCurRuntime为全局变量。
AndroidRuntime::AndroidRuntime()
{
SkGraphics::Init();//Skia库初始化
SkImageDecoder::SetDeviceConfig(SkBitmap::kRGB_565_Config);
SkImageRef_GlobalPool::SetRAMBudget(512 * 1024);
gCurRuntime= this; //gCurRuntime被设置为AndroidRuntime对象自己
}
~~~
由于SS是从Zygote fork出来的,所以它也拥有Zygote进程中定义的这个gCurRuntime,也就是AppRuntime对象。那么,它的onZygoteInit会干些什么呢?它的代码在App_main.cpp中,我们一起来看:
**App_main.cpp**
~~~
virtual void onZygoteInit()
{
//下面这些东西和Binder有关系,但读者可以先不管它。
sp<ProcessState> proc = ProcessState::self();
if(proc->supportsProcesses()) {
proc->startThreadPool();//启动一个线程,用于Binder通信。
}
}
~~~
一言以蔽之,SS调用zygoteInitNative后,将和Binder通信系统建立联系,这样SS就能够使用Binder了。关于Binder的知识,在第6章中将详细介绍,读者朋友现在不必关注。
2. invokeStaticMain分析
再来看第二个关键点invokeStaticMain。代码如下所示:
**RuntimeInit.java**
~~~
private static void invokeStaticMain(StringclassName, String[] argv)
throws ZygoteInit.MethodAndArgsCaller {
......//注意我们的参数,className为"com.android.server.SystemServer"
Class<?> cl;
try {
cl = Class.forName(className);
}catch (ClassNotFoundException ex) {
throw new RuntimeException(
"Missing class wheninvoking static main " + className,
ex);
}
Method m;
try {
//找到com.android.server.SystemServer类的main函数,肯定有地方要调用它
m = cl.getMethod("main", new Class[] { String[].class });
}catch (NoSuchMethodException ex) {
......
}catch (SecurityException ex) {
......
}
int modifiers = m.getModifiers();
if(! (Modifier.isStatic(modifiers) && Modifier.isPublic(modifiers))) {
......
}
//抛出一个异常,为什么不在这里直接调用上面的main函数呢?
throw new ZygoteInit.MethodAndArgsCaller(m, argv);
}
~~~
invokeStaticMain竟然抛出了一个异常,它是在哪里被截获呢?原来是在ZygoteInit的main函数中。请看这段代码:
注意:我们所在的进程是system_server。
**ZygoteInit.java**
~~~
....
if (argv[1].equals("true")) {
//SS进程中,抛出一个异常MethodAndArgsCaller
startSystemServer();
......
catch(MethodAndArgsCaller caller) {
//被截获,调用caller的run函数
caller.run();
}
~~~
再来看看MethodAndArgsCaller的run函数。
~~~
public void run() {
try {
//这个mMethod为com.android.server.SystemServer的main函数
mMethod.invoke(null, new Object[] { mArgs });
} catch(IllegalAccessException ex) {
......
}
}
~~~
抛出的这个异常最后会导致com.android.server.SystemServer类的main函数被调用。不过这里有一个疑问,为什么不在invokeStaticMain那里直接调用,而是采用这种抛异常的方式呢?我对这个问题的看法是:
- 这个调用是在ZygoteInit.main中,相当于Native的main函数,即入口函数,位于堆栈的顶层。如果不采用抛异常的方式,而是在invokeStaticMain那里调用,则会浪费之前函数调用所占用的一些调用堆栈。
关于这个问题的深层思考,读者可以利用fork和exec的知识。对这种抛异常的方式,我个人觉得是对exec的一种近似模拟,因为后续的工作将交给com.android.server.SystemServer类来处理。
3. SystemServer的真面目
ZygoteInit分裂产生的SS,其实就是为了调用com.android.server.SystemServer的main函数,这简直就是改头换面!下面就来看看这个真实的main函数,代码如下所示:
**SystemServer.java**
~~~
public static void main(String[] args) {
......
//加载libandroid_servers.so
System.loadLibrary("android_servers");
//调用native的init1函数。
init1(args);
}
~~~
其中main函数将加载libandroid_server.so库,这个库所包含的源码文件在文件夹framework/base/services/jni下。
(1)init1分析
init1是native函数,在com_android_server_SystemServer.cpp中实现。来看看它,代码如下所示:
**com_android_server_SystemServer.cpp**
~~~
extern "C" int system_init();
static voidandroid_server_SystemServer_init1(JNIEnv* env, jobject clazz)
{
system_init();//调用另外一个函数。
}
~~~
system_init的实现在system_init.cpp中,它的代码如下所示:
**system_init.cpp**
~~~
extern "C" status_t system_init()
{
//下面这些调用和Binder有关,我们会在第6章中讲述,这里先不必管它。
sp<ProcessState> proc(ProcessState::self());
sp<IServiceManager> sm = defaultServiceManager();
sp<GrimReaper>grim = new GrimReaper();
sm->asBinder()->linkToDeath(grim, grim.get(), 0);
charpropBuf[PROPERTY_VALUE_MAX];
property_get("system_init.startsurfaceflinger", propBuf,"1");
if(strcmp(propBuf, "1") == 0) {
//SurfaceFlinger服务在system_server进程创建
SurfaceFlinger::instantiate();
}
......
//调用com.android.server.SystemServer类的init2函数
AndroidRuntime* runtime = AndroidRuntime::getRuntime();
runtime->callStatic("com/android/server/SystemServer","init2");
//下面这几个函数调用和Binder通信有关,具体内容在第6章中介绍。
if (proc->supportsProcesses()) {
ProcessState::self()->startThreadPool();
//调用joinThreadPool后,当前线程也加入到Binder通信的大潮中
IPCThreadState::self()->joinThreadPool();
}
returnNO_ERROR;
}
~~~
init1函数创建了一些系统服务,然后把调用线程加入Binder通信中。不过其间还通过JNI调用了com.android.server.SystemServer类的init2函数,下面就来看看这个init2函数。
(2)init2分析
init2在Java层,代码在SystemServer.java中,如下所示:
**SystemServer.java**
~~~
public static final void init2() {
Threadthr = new ServerThread();
thr.setName("android.server.ServerThread");
thr.start();//启动一个ServerThread
}
~~~
启动了一个ServerThread线程。请直接看它的run函数。这个函数比较长,大概看看它干了什么即可。
**SystemServer.java::ServerThread的run函数**
~~~
public void run(){
....
//启动Entropy Service
ServiceManager.addService("entropy",new EntropyService());
//启动电源管理服务
power =new PowerManagerService();
ServiceManager.addService(Context.POWER_SERVICE, power);
//启动电池管理服务。
battery= new BatteryService(context);
ServiceManager.addService("battery", battery);
//初始化看门狗,在拓展部分将介绍关于看门狗的知识
Watchdog.getInstance().init(context,battery, power, alarm,
ActivityManagerService.self());
//启动WindowManager服务
wm =WindowManagerService.main(context, power,
factoryTest !=SystemServer.FACTORY_TEST_LOW_LEVEL);
ServiceManager.addService(Context.WINDOW_SERVICE,wm);
//启动ActivityManager服务
(ActivityManagerService)ServiceManager.getService("activity"))
.setWindowManager(wm);
......//总之,系统各种重要服务都在这里启动
Looper.loop(); //进行消息循环,然后处理消息。关于这部分内容参见第5章。
}
~~~
init2函数比较简单,就是单独创建一个线程,用以启动系统各项服务,至此,读者或许能理解SS的重要性了吧?
- **Java世界的核心Service都在这里启动,所以它非常重要。**
* * * * *
**说明**:本书不对这些Service做进一步分析,今后有机会再做做专门介绍。
* * * * *
- 前言
- 第1章 阅读前的准备工作
- 1.1 系统架构
- 1.1.1 Android系统架构
- 1.1.2 本书的架构
- 1.2 搭建开发环境
- 1.2.1 下载源码
- 1.2.2 编译源码
- 1.3 工具介绍
- 1.3.1 Source Insight介绍
- 1.3.2 Busybox的使用
- 1.4 本章小结
- 第2章 深入理解JNI
- 2.1 JNI概述
- 2.2 学习JNI的实例:MediaScanner
- 2.3 Java层的MediaScanner分析
- 2.3.1 加载JNI库
- 2.3.2 Java的native函数和总结
- 2.4 JNI层MediaScanner的分析
- 2.4.1 注册JNI函数
- 2.4.2 数据类型转换
- 2.4.3 JNIEnv介绍
- 2.4.4 通过JNIEnv操作jobject
- 2.4.5 jstring介绍
- 2.4.6 JNI类型签名介绍
- 2.4.7 垃圾回收
- 2.4.8 JNI中的异常处理
- 2.5 本章小结
- 第3章 深入理解init
- 3.1 概述
- 3.2 init分析
- 3.2.1 解析配置文件
- 3.2.2 解析service
- 3.2.3 init控制service
- 3.2.4 属性服务
- 3.3 本章小结
- 第4章 深入理解zygote
- 4.1 概述
- 4.2 zygote分析
- 4.2.1 AppRuntime分析
- 4.2.2 Welcome to Java World
- 4.2.3 关于zygote的总结
- 4.3 SystemServer分析
- 4.3.1 SystemServer的诞生
- 4.3.2 SystemServer的重要使命
- 4.3.3 关于 SystemServer的总结
- 4.4 zygote的分裂
- 4.4.1 ActivityManagerService发送请求
- 4.4.2 有求必应之响应请求
- 4.4.3 关于zygote分裂的总结
- 4.5 拓展思考
- 4.5.1 虚拟机heapsize的限制
- 4.5.2 开机速度优化
- 4.5.3 Watchdog分析
- 4.6 本章小结
- 第5章 深入理解常见类
- 5.1 概述
- 5.2 以“三板斧”揭秘RefBase、sp和wp
- 5.2.1 第一板斧--初识影子对象
- 5.2.2 第二板斧--由弱生强
- 5.2.3 第三板斧--破解生死魔咒
- 5.2.4 轻量级的引用计数控制类LightRefBase
- 5.2.5 题外话-三板斧的来历
- 5.3 Thread类及常用同步类分析
- 5.3.1 一个变量引发的思考
- 5.3.2 常用同步类
- 5.4 Looper和Handler类分析
- 5.4.1 Looper类分析
- 5.4.2 Handler分析
- 5.4.3 Looper和Handler的同步关系
- 5.4.4 HandlerThread介绍
- 5.5 本章小结
- 第6章 深入理解Binder
- 6.1 概述
- 6.2 庖丁解MediaServer
- 6.2.1 MediaServer的入口函数
- 6.2.2 独一无二的ProcessState
- 6.2.3 时空穿越魔术-defaultServiceManager
- 6.2.4 注册MediaPlayerService
- 6.2.5 秋风扫落叶-StartThread Pool和join Thread Pool分析
- 6.2.6 你彻底明白了吗
- 6.3 服务总管ServiceManager
- 6.3.1 ServiceManager的原理
- 6.3.2 服务的注册
- 6.3.3 ServiceManager存在的意义
- 6.4 MediaPlayerService和它的Client
- 6.4.1 查询ServiceManager
- 6.4.2 子承父业
- 6.5 拓展思考
- 6.5.1 Binder和线程的关系
- 6.5.2 有人情味的讣告
- 6.5.3 匿名Service
- 6.6 学以致用
- 6.6.1 纯Native的Service
- 6.6.2 扶得起的“阿斗”(aidl)
- 6.7 本章小结
- 第7章 深入理解Audio系统
- 7.1 概述
- 7.2 AudioTrack的破解
- 7.2.1 用例介绍
- 7.2.2 AudioTrack(Java空间)分析
- 7.2.3 AudioTrack(Native空间)分析
- 7.2.4 关于AudioTrack的总结
- 7.3 AudioFlinger的破解
- 7.3.1 AudioFlinger的诞生
- 7.3.2 通过流程分析AudioFlinger
- 7.3.3 audio_track_cblk_t分析
- 7.3.4 关于AudioFlinger的总结
- 7.4 AudioPolicyService的破解
- 7.4.1 AudioPolicyService的创建
- 7.4.2 重回AudioTrack
- 7.4.3 声音路由切换实例分析
- 7.4.4 关于AudioPolicy的总结
- 7.5 拓展思考
- 7.5.1 DuplicatingThread破解
- 7.5.2 题外话
- 7.6 本章小结
- 第8章 深入理解Surface系统
- 8.1 概述
- 8.2 一个Activity的显示
- 8.2.1 Activity的创建
- 8.2.2 Activity的UI绘制
- 8.2.3 关于Activity的总结
- 8.3 初识Surface
- 8.3.1 和Surface有关的流程总结
- 8.3.2 Surface之乾坤大挪移
- 8.3.3 乾坤大挪移的JNI层分析
- 8.3.4 Surface和画图
- 8.3.5 初识Surface小结
- 8.4 深入分析Surface
- 8.4.1 与Surface相关的基础知识介绍
- 8.4.2 SurfaceComposerClient分析
- 8.4.3 SurfaceControl分析
- 8.4.4 writeToParcel和Surface对象的创建
- 8.4.5 lockCanvas和unlockCanvasAndPost分析
- 8.4.6 GraphicBuffer介绍
- 8.4.7 深入分析Surface的总结
- 8.5 SurfaceFlinger分析
- 8.5.1 SurfaceFlinger的诞生
- 8.5.2 SF工作线程分析
- 8.5.3 Transaction分析
- 8.5.4 关于SurfaceFlinger的总结
- 8.6 拓展思考
- 8.6.1 Surface系统的CB对象分析
- 8.6.2 ViewRoot的你问我答
- 8.6.3 LayerBuffer分析
- 8.7 本章小结
- 第9章 深入理解Vold和Rild
- 9.1 概述
- 9.2 Vold的原理与机制分析
- 9.2.1 Netlink和Uevent介绍
- 9.2.2 初识Vold
- 9.2.3 NetlinkManager模块分析
- 9.2.4 VolumeManager模块分析
- 9.2.5 CommandListener模块分析
- 9.2.6 Vold实例分析
- 9.2.7 关于Vold的总结
- 9.3 Rild的原理与机制分析
- 9.3.1 初识Rild
- 9.3.2 RIL_startEventLoop分析
- 9.3.3 RIL_Init分析
- 9.3.4 RIL_register分析
- 9.3.5 关于Rild main函数的总结
- 9.3.6 Rild实例分析
- 9.3.7 关于Rild的总结
- 9.4 拓展思考
- 9.4.1 嵌入式系统的存储知识介绍
- 9.4.2 Rild和Phone的改进探讨
- 9.5 本章小结
- 第10章 深入理解MediaScanner
- 10.1 概述
- 10.2 android.process.media分析
- 10.2.1 MSR模块分析
- 10.2.2 MSS模块分析
- 10.2.3 android.process.media媒体扫描工作的流程总结
- 10.3 MediaScanner分析
- 10.3.1 Java层分析
- 10.3.2 JNI层分析
- 10.3.3 PVMediaScanner分析
- 10.3.4 关于MediaScanner的总结
- 10.4 拓展思考
- 10.4.1 MediaScannerConnection介绍
- 10.4.2 我问你答
- 10.5 本章小结