目录
前言
在前面一篇Android 跨进程通信-（二）Binder机制之ServiceManager主要介绍的Binder机制中的ServiceManager，那么Client进程和Server进程又是如何启动呢？又是如何进行数据交互的呢？
现在以一个APP的进程为Client进程，然后我们创建的一个AIDL服务为Server进程，我们主要分析下这两者直接是怎么通信。
因为APP的进程为Client进程，所以Client进程的创建，那也就是APP进程的创建。我们主要分析下一个APP的进程是怎么创建出来的，会不会也和ServiceManager进程那样有内存映射呢？
如果不喜欢看里面的代码，可以直接看下每一部分的小结。
一 准备工作
Android系统启动第一个进程为init进程，init进程通过解析init.rc来fork出zygote进程。Android的其他进程都是有Zygote进程fork出来的。所以APP进程也是有Zygote进程fork出来的。
1.zygote进程创建
当zygote创建出来之后，会加载到 /frameworks/base/cmds/app_process/app_main.cpp的main()方法
int main(int argc, char* const argv[])
{
//.....
if (zygote) {
runtime.start("com.android.internal.os.ZygoteInit", args, zygote);
} else if (className) {
runtime.start("com.android.internal.os.RuntimeInit", args, zygote);
} else {
fprintf(stderr, "Error: no class name or --zygote supplied.\n");
app_usage();
LOG_ALWAYS_FATAL("app_process: no class name or --zygote supplied.");
}
//.....
}该main()里面的功能：通过Android虚拟机AppRuntime来启动不同的类的main()方法。通过执行ZygoteInit的main()，完成Zygote进程的职责。
2.zygote进程功能加载
在Zygote进程启动之后，执行ZygoteInit的main()来实现zygote进程功能加载，主要逻辑如下：
- （1）创建一个Server端的ZygoteServer，等待ActivityManagerService请求来创建APP进程
- （2）通过forkSystemServer()来fork出SystemServer进程
ZygoteInit的main()里面对应的代码位于 /frameworks/base/core/java/com/android/internal/os/ZygoteInit.java，简单的贴一点主要逻辑代码如下：
public static void main(String argv[]) {
ZygoteServer zygoteServer = null;
//.....
Runnable caller;
try {
//.....
for (int i = 1; i < argv.length; i++) {
if ("start-system-server".equals(argv[i])) {
startSystemServer = true;
}
//.....
else if (argv[i].startsWith(ABI_LIST_ARG)) {
abiList = argv[i].substring(ABI_LIST_ARG.length());
}
//.....
}
//与AMS socket通信的server
zygoteServer = new ZygoteServer(isPrimaryZygote);
//SystemServer进程的创建
if (startSystemServer) {
Runnable r = forkSystemServer(abiList, zygoteSocketName, zygoteServer);
// child (system_server) process.
if (r != null) {
r.run();
return;
}
}
//循环等待AMS发出fork进程的通知
caller = zygoteServer.runSelectLoop(abiList);
} finally {
if (zygoteServer != null) {
zygoteServer.closeServerSocket();
}
}
//启动子进程
if (caller != null) {
caller.run();
}
}
简单的将里面的点总结下：
（1）ZygoteServer职责
在Zygote进程第一次启动的时候创建ZygoteServer，作用就是与AMS建立Socket通信的服务端。AMS发出创建APP进程的通知时，就会通过socket通信通知Zygote进程创建APP进程。
主要通过 zygoteServer.runSelectLoop(abiList)启动一个循环，等待AMS来发送请求。对应的代码位于frameworks/base/core/java/com/android/internal/os/ZygoteServer.java，简单的贴一点主要逻辑代码如下：
Runnable runSelectLoop(String abiList) {
ArrayList<FileDescriptor> fds = new ArrayList<FileDescriptor>();
ArrayList<ZygoteConnection> peers = new ArrayList<ZygoteConnection>();
fds.add(mServerSocket.getFileDescriptor());
peers.add(null);
while (true) {
//.......
for (int i = pollFds.length - 1; i >= 0; --i) {
if ((pollFds[i].revents & POLLIN) == 0) {
continue;
}
if (i == 0) {
ZygoteConnection newPeer = acceptCommandPeer(abiList);
peers.add(newPeer);
fds.add(newPeer.getFileDesciptor());
} else {
try {
//当接收到需要创建APP进程的消息,通过processOneCommand来创建进程
ZygoteConnection connection = peers.get(i);
final Runnable command = connection.processOneCommand(this);
// 当前是子进程
if (mIsForkChild) {
// We're in the child. We should always have a command to run at this
// stage if processOneCommand hasn't called "exec".
if (command == null) {
throw new IllegalStateException("command == null");
}
return command;
} else {
//如果在server进程中，不应该有任何需要运行的命令
if (command != null) {
throw new IllegalStateException("command != null");
}
//.......
}
}
//.......
}
}
}
}这样接收到AMS发过来的请求的时候，最终会通过jni调用到Native的 app_main.cpp下的onZygoteInit()方法来创建APP进程。
小结：
- 1.ZygoteServer作用：在zygote进程中创建socket的server端，通过socket通信接收AMS的创建进程的请求；
- 2.在ZygoteServer中维护着一个死循环，接收AMS发出请求；
（2）system_server进程
在Android系统启动加载Zygote进程的时候，通过ZygoteInit#forkSystemServer()中来调用到Zygote.forkSystemServer()来创建出system_server进程。因为这个章节的内容比较多，所以单独拉出见 “二 system_server进程 ”。
小结：
- 1.通过zygote进程fork出system_server进程；
- 2.最终调用到Native的app_main.cpp下的onZygoteInit()来对system_server进程进行初始化;
- 3.通过RuntimeInit.applicationInit来加载system_server进程的功能；
- 3.system_server进程的功能实现类对应的com.android.server.SystemServer。
3.小结zygote进程
- （1）zygote进程是运行在Android虚拟机上，通过AppRuntime启动的zygote进程对应的功能；
- （2）zygote进程有两个作用：一个是创建一个与AMS进行socket通信的server端，等待接收AMS发出创建进程的请求；另一个是fork出system_server进程；
- （3）对system_server进程进行初始化之后，通过执行com.android.server.SystemServer#main()，来实现system_server进程的功能：启动一些重要的系统service
二 system_server进程
因为这个内容有点多，所以单独拉出一章总结下。
system_server进程是有Zygote进程由ZygoteInit#forkSystemServer()最终产生的。其中一个逻辑调用流程主要分为两部分：
- （1）通过Zygote.forkSystemServer来fork出system_server进程；
- （2）通过ZygoteInit#forkSystemServer()返回值的时候调用handleSystemServerProcess对进程进程初始化及功能加载
private static Runnable forkSystemServer(String abiList, String socketName,
ZygoteServer zygoteServer) {
//.....
/* Hardcoded command line to start the system server */
String args[] = {
"--setuid=1000",
"--setgid=1000",
"--setgroups=1001,1002,1003,1004,1005,1006,1007,1008,1009,1010,1018,1021,1023,"
+ "1024,1032,1065,3001,3002,3003,3006,3007,3009,3010",
"--capabilities=" + capabilities + "," + capabilities,
"--nice-name=system_server",
"--runtime-args",
"--target-sdk-version=" + VMRuntime.SDK_VERSION_CUR_DEVELOPMENT,
"com.android.server.SystemServer",
};
//.....
/* Request to fork the system server process */
pid = Zygote.forkSystemServer(
parsedArgs.mUid, parsedArgs.mGid,
parsedArgs.mGids,
parsedArgs.mRuntimeFlags,
null,
parsedArgs.mPermittedCapabilities,
parsedArgs.mEffectiveCapabilities);
//.....
/* For child process */
if (pid == 0) {
if (hasSecondZygote(abiList)) {
waitForSecondaryZygote(socketName);
}
zygoteServer.closeServerSocket();
return handleSystemServerProcess(parsedArgs);
}
}通过Zygote.forkSystemServer()在fork system_server进程的时候，我们可以看到此时system_server进程的一些参数内容：
- 用户id和用户组都设置了1000，并且拥有1001-1010、1018、1021、1032、1065、3001-3010权限
- 进程名为system_server
- 启动的类名为com.android.server.SystemServer
1.system_server进程创建
从代码中可以看到最终fork进程的代码最终调用到Zygote.forkSystemServer(),实现代码代码对应的: /frameworks/base/core/java/com/android/internal/os/Zygote.java，简单的代码逻辑如下：
public static int forkSystemServer(int uid, int gid, int[] gids, int runtimeFlags,
int[][] rlimits, long permittedCapabilities, long effectiveCapabilities) {
// ......
int pid = nativeForkSystemServer(
uid, gid, gids, runtimeFlags, rlimits, permittedCapabilities, effectiveCapabilities);
// ......
return pid;
}最终调用到Native的/frameworks/base/core/jni/com_android_internal_os_Zygote.cpp#com_android_internal_os_Zygote_nativeForkSystemServer()的相关代码
static jint com_android_internal_os_Zygote_nativeForkSystemServer(
JNIEnv* env, jclass, uid_t uid, gid_t gid, jintArray gids,
jint runtime_flags, jobjectArray rlimits, jlong permittedCapabilities,
jlong effectiveCapabilities) {
pid_t pid = ForkAndSpecializeCommon(env, uid, gid, gids,
runtime_flags, rlimits,
permittedCapabilities, effectiveCapabilities,
MOUNT_EXTERNAL_DEFAULT, NULL, NULL, true, NULL,
NULL, false, NULL, NULL);
if (pid > 0) {
gSystemServerPid = pid;
// 如果system_server进程死亡，会重启zygote进程
int status;
if (waitpid(pid, &status, WNOHANG) == pid) {
RuntimeAbort(env, __LINE__, "System server process has died. Restarting Zygote!");
}
// 。。。。。。。
}
return pid;
}最终通过 ForkAndSpecializeCommon()来fork一个进程，返回给Zygote的forkSystemServer()。system_server进程是zygote进程fork出来的第一个进程。如果system_server进程死亡，Zygote 进程会重启。
其中Zygote.forkSystemServer()的返回值：0代表创建的是子进程；>0表示的是主进程。
2.system_server进程初始化
通过Zygote.forkSystemServer()得到system_server进程之后，返回给ZygoteInit#forkSystemServer()，然后执行返回值，返回值的时候调用ZygoteInit#handleSystemServerProcess()进程完成初始化和功能的加载。
在handleSystemServerProcess()中主要调用了ZygoteInit.zygoteInit()，代码中可以看到这里又实现了两个功能：
- （1）通过ZygoteInit.nativeZygoteInit()完成进程的初始化
- （2）通过RuntimeInit.applicationInit运行该进程的功能的类的main()
下面的代码是ZygoteInit.zygoteInit()里面的部分主要逻辑代码如下：
public static final Runnable zygoteInit(int targetSdkVersion, String[] argv,
ClassLoader classLoader) {
//......
ZygoteInit.nativeZygoteInit();
return RuntimeInit.applicationInit(targetSdkVersion, argv, classLoader);
}本小节主要先看初始化过程，其中功能加载放到第三小节中总结。
在初始化过程中，最终通过一系列调用到Native的app_main.cpp下的onZygoteInit() 来进行初始化。详细的内容见“三从Native看APP进程的初始化 ”。
3.system_server进程功能加载
在上面的system_server进程初始化的返回的时候，继续向下调用到 RuntimeInit.applicationInit()来执行执行对应的com.android.server.SystemServer的main()。
com.android.server.SystemServer功能对应代码：frameworks/base/services/java/com/android/server/SystemServer.java。只列举下里面的关键代码如下：
public final class SystemServer {
/**
* The main entry point from zygote.
*/
public static void main(String[] args) {
new SystemServer().run();
}
private void run() {
//......
startBootstrapServices();
startCoreServices();
startOtherServices();
SystemServerInitThreadPool.shutdown();
//......
}
}这样通过上面三个过程，已经将system_server进程启动，并且加载了SystemServer中的功能： 主要启动了一些重要的系统Service，如ActivityManagerService、PackageManagerService等，所以说这些系统Service运行在system_server进程中。
小结：
- 1.system_server进程是有Zygote进程fork出来的第一进程SystemServer 进程。如果子进程 SystemServer 挂了，Zygote 进程就会自杀，导致 Zygote 进程会重启。
- 2.system_server进程最终通过native的com_android_internal_os_Zygote.cpp#com_android_internal_os_Zygote_nativeForkSystemServer()来实现进程的创建；
- 3.system_server进程创建之后，会通过ZygoteInit.zygoteInit()完成进程的初始化和功能加载，其中功能对应的com.android.server.SystemServer的main()功能：主要启动了一些重要系统Service
三 从Native看APP进程的初始化
当接收到AMS发送过来创建进程的请求的时候，在zygote进程中维护的死循环（对应/frameworks/base/core/java/com/android/internal/os/ZygoteConnection.java中的processOneCommand()）中接收该请求，创建APP进程，并完成对APP进程的初始化以及功能加载。
1.APP进程创建
主要在代码实现：/frameworks/base/core/java/com/android/internal/os/ZygoteConnection.java的processOneCommand()，简单的代码逻辑如下：
Runnable processOneCommand(ZygoteServer zygoteServer) {
//.....
//fork进程
pid = Zygote.forkAndSpecialize(parsedArgs.uid, parsedArgs.gid, parsedArgs.gids,
parsedArgs.runtimeFlags, rlimits, parsedArgs.mountExternal, parsedArgs.seInfo,
parsedArgs.niceName, fdsToClose, fdsToIgnore, parsedArgs.startChildZygote,
parsedArgs.instructionSet, parsedArgs.appDataDir);
//.....
//初始化进程
try {
if (pid == 0) {
//.....
return handleChildProc(parsedArgs, descriptors, childPipeFd,
parsedArgs.startChildZygote);
} else {
//.....
handleParentProc(pid, descriptors, serverPipeFd);
return null;
}
}和前面提到的system_server进程创建过程一致，都是通过 Zygote进程来fork一个进程，只不过现在调用的是Zygote.forkAndSpecialize()，最终会调用用到/frameworks/base/core/jni/com_android_internal_os_Zygote.cpp#com_android_internal_os_Zygote_nativeForkAndSpecialize()：
static jint com_android_internal_os_Zygote_nativeForkAndSpecialize(
JNIEnv* env, jclass, jint uid, jint gid, jintArray gids,
jint runtime_flags, jobjectArray rlimits,
jint mount_external, jstring se_info, jstring se_name,
jintArray fdsToClose, jintArray fdsToIgnore, jboolean is_child_zygote,
jstring instructionSet, jstring appDataDir) {
//......
return ForkAndSpecializeCommon(env, uid, gid, gids, runtime_flags,
rlimits, capabilities, capabilities, mount_external, se_info,
se_name, false, fdsToClose, fdsToIgnore, is_child_zygote == JNI_TRUE,
instructionSet, appDataDir);
}通过源码发现，其实和system_server进程一样，都是通过ForkAndSpecializeCommon()来创建出该APP进程。
2.APP进程初始化
当Zygote.forkAndSpecialize()返回的时候，又会调用到handleChildProc()来进行进程初始化，而这个handleChildProc()里面的具体实现也是通过ZygoteInit#zygoteInit() ，那么该方法中前面也提到会有两部分的功能：
- （1）初始化进程
- （2）进程的功能加载
具体的代码逻辑见2.system_server进程初始化，这里仅简单描述。
同样本小节还是只详细说明下进程初始化的过程，最终调用到app_main.cpp下的onZygoteInit()对APP的进程进行初始化，具体代码实现位于 /frameworks/base/cmds/app_process/app_main.cpp下的onZygoteInit()方法：
virtual void onZygoteInit()
{
sp<ProcessState> proc = ProcessState::self();
ALOGV("App process: starting thread pool.\n");
proc->startThreadPool();
}最终具体的逻辑在 /frameworks/native/libs/binder/ProcessState.cpp。
（1）第一行代码实现的具体功能
#define BINDER_VM_SIZE ((1 * 1024 * 1024) - sysconf(_SC_PAGE_SIZE) * 2)
sp<ProcessState> ProcessState::self()
{
Mutex::Autolock _l(gProcessMutex);
if (gProcess != NULL) {
return gProcess;
}
gProcess = new ProcessState("/dev/binder");
return gProcess;
}
ProcessState::ProcessState(const char *driver)
: mDriverName(String8(driver))
, mDriverFD(open_driver(driver))
, mVMStart(MAP_FAILED)
, mThreadCountLock(PTHREAD_MUTEX_INITIALIZER)
, mThreadCountDecrement(PTHREAD_COND_INITIALIZER)
, mExecutingThreadsCount(0)
, mMaxThreads(DEFAULT_MAX_BINDER_THREADS)
, mStarvationStartTimeMs(0)
, mManagesContexts(false)
, mBinderContextCheckFunc(NULL)
, mBinderContextUserData(NULL)
, mThreadPoolStarted(false)
, mThreadPoolSeq(1)
{
//对应就是通过mDriverFD(open_driver(driver))打开"/dev/binder"设备文件驱动
if (mDriverFD >= 0) {
//这个又是和ServiceManager一样的去记在APP的进程创建一个BINDER_VM_SIZE大小的虚拟内存空间
//BINDER_VM_SIZ大小为1M-8k（_SC_PAGE_SIZE为page页大小，为4K）
mVMStart = mmap(0, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE | MAP_NORESERVE, mDriverFD, 0);
//.......
}
}
看到这几行熟悉的代码，好开心，终于和前面Android 跨进程通信-（二）Binder机制之ServiceManager中在创建ServiceManager进程的时候类似：
- （1）通过open_driver()打开设备文件"/dev/binder"，获取一个"/dev/binder"的文件描述，通过该文件描述与Binder驱动程序进行交互
static int open_driver(const char *driver)
{
int fd = open(driver, O_RDWR | O_CLOEXEC);
if (fd >= 0) {
int vers = 0;
status_t result = ioctl(fd, BINDER_VERSION, &vers);
//......
size_t maxThreads = DEFAULT_MAX_BINDER_THREADS;
result = ioctl(fd, BINDER_SET_MAX_THREADS, &maxThreads);
//......
}
//......
return fd;
}与ServiceManager进程不同的是，在这里设置进程内的binder线程池中的线程最大值，默认为15个。
- （2）通过mmap在APP的进程中分配1M-8K的虚拟内存空间，同时也会调用到内核的builder_mmap来在内核空间创建一个虚拟内存空间，同时申请一个物理内存映射到进程的虚拟内存空间和内核的虚拟内存空间。
另外注意一点，这个地方的ProcessState为单例模式，也就是一个进程中只能有一个ProcessState实例，保证每个进程只打开"/dev/binder"设备一次。我们给到APP进程中分配的1M-8K的虚拟内存空间，而进程内的binder线程数为15个，这些都是共享这块内存空间，所以在一次调用传输的数据肯定不会是1M-8K大小的数据。详见Android 跨进程通信-（十）Binder机制传输数据限制—罪魁祸首Binder线程池
（2）第二行代码实现的具体功能
void ProcessState::startThreadPool()
{
AutoMutex _l(mLock);
if (!mThreadPoolStarted) {
mThreadPoolStarted = true;
spawnPooledThread(true);
}
}
通过该方法启动了进程内的binder线程池。 这里启动线程池之后就会设置mThreadPoolStarted为true，这就是保证每个应用进程只启动一个binder线程池，并且本次创建的是binder主线程(传入spawnPooledThread的值为true)，其余的线程都是有Binder驱动来控制创建的。
3.APP进程功能加载
由于APP进程同system_server进程一样，都是调用的ZygoteInit.nativeZygoteInit()进行初始化进程之后，会返回ZygoteInit#zygoteInit()，然后继续向下调用 RuntimeInit.applicationInit()来执行对应实现功能的类，只不过对于APP进程加载的是android.app.ActivityThread的main()，其中部分主要逻辑代码如下：
public static void main(String[] args) {
//......
//为该线程创建一个Looper
Looper.prepareMainLooper();
//......
ActivityThread thread = new ActivityThread();
//完成application对象的初始化，然后调用到application的onCreate()
thread.attach(false, startSeq);
//......
if (sMainThreadHandler == null) {
sMainThreadHandler = thread.getHandler();
}
//......
//开启Looper
Looper.loop();
throw new RuntimeException("Main thread loop unexpectedly exited");
}ActivityThread是APP的入口类，管理APP进程的主线程的执行，通过消息循环队列来完成执行Activity、Broadcast、Service相关操作。
4.小结APP进程
通过分析APP进程的创建之后的初始化过程，发现和前面的猜想是一样的，都是要打开设备文件"/dev/binder"和内存映射：
- 1.Android系统的第一个用户进程是init进程，而init进程fork出Zygote进程，Android系统中的其他进程都是有Zygote进程fork出来的；
- 2.Zygote进程会在创建的过程中，会创建与AMS socket通信的server端，创建一个死循环，等待AMS来发出创建APP进程的请求；
- 4.APP进程的创建过程和system_server进程一样，最终都是通过一系列调用到native的com_android_internal_os_Zygote.cpp的ForkAndSpecializeCommon()一个进程。
- 5.初始化APP进程和system_server进程一样，最终通过一系列调用到app_main中的onZygoteInit()初始化APP进程；
- 6.APP进程初始化过程和ServiceManager进程一样：
- （1）通过open_driver()打开设备文件"dev/binder"，获得该设备文件描述符，和Binder驱动进行交互；
- （2）与ServiceManager进程打开设备文件不同的是，需要发送设置线程最大数给到Binder驱动；
- （3）通过mmap进行内存映射的逻辑与ServiceManager进程一致，都是需要分配1M-8k的进程的虚拟内存空间
- （4）在mmap内存映射的过程中同样也需要调用到内核的builder_mmap，在内核空间分配虚拟内存空间，同时还要申请一块物理内存，映射到APP进程的虚拟内存空间和内核的虚拟内存空间。
- 7.APP进程功能加载和system_server进程一样，最终通过 RuntimeInit.applicationInit()来执行APP进程对应的功能实现类android.app.ActivityThread的main()。
四 总结
1.用图来描述一个进程从创建、初始化和功能加载过程
- 1.Android系统启动的时候创建的第一个init进程；
- 2.init进程fork出Zygote进程，Android的其他进程都是有该进程fork出来的；
- 3.Zygote进程在加载功能的时候，需要实现两个功能：一个是system_server进程的创建、初始化和加载；另一个就是创建ZygoteServer，建立与AMS的socket通信的server端；
- 4.当Zygote进程接收到AMS发出的创建APP的进程的时候，会调用到对应的方法完成APP进程创建、初始化以及功能的加载；
2.创建system_server进程的方法调用
- 1.在ZygoteInit.main()中会调用到forkSystemServer()用来返回一个system_server进程；
- 2.在ZygoteInit.forkSystemServer()中最终会调用到native的com_android_internal_os_Zygote.cpp#com_android_internal_os_Zygote_native()，通过 ForkAndSpecializeCommon()来fork一个进程，返回给ZygoteInit.forkSystemServer()；（进程的创建）
- 3.在ZygoteInit.forkSystemServer()返回的时候，调用ZygoteInit#handleSystemServerProcess()作为返回值，其中在handleSystemServerProcess中调用ZygoteInit#zygoteInit()完成进程的初始化；（进程的初始化和功能的加载）
- 4.ZygoteInit#zygoteInit()中通过ZygoteInit.nativeZygoteInit()初始化进程，最终调用的是app_main.cpp下的onZygoteInit() ；（具体的进程初始化）
- 5.在ZygoteInit#zygoteInit()中通过 RuntimeInit.applicationInit()来加载system_server进程对应的功能类：com.android.server.SystemServer的main()。（具体进程的功能加载）
3.创建APP进程的方法调用
- 1.当Zygote进程接收到创建APP进程的消息的时候，会调用到ZygoteConnection#processOneCommand()；
- 2.在ZygoteConnection#processOneCommand()中通过Zygote.forkAndSpecialize，最终调用到native的com_android_internal_os_Zygote.cpp#com_android_internal_os_Zygote_nativeForkAndSpecialize()，通过 ForkAndSpecializeCommon()来fork一个进程，返回给ZygoteConnection#processOneCommand()；（进程的创建）
- 3.在ZygoteConnection#processOneCommand()接收到进程创建返回的时候，会通过handleChildProc()调用到ZygoteInit#zygoteInit()来完成进程的初始化；（进程的初始化和功能的加载）
- 4.同4；（具体的进程初始化）
- 5.在ZygoteInit#zygoteInit()执行返回值的时候，调用 RuntimeInit.applicationInit()来加载APP进程对应的功能类：android.app.ActivityThread的main()。（具体进程的功能加载）
4.大胆的总结下
- 1.实现一个Zygote进程的功能，首先有一个zygote进程，然后通过Android虚拟机执行com.android.internal.os.ZygoteInit#main()，实现zygote进程对应的功能；
- 2.实现一个com.android.server.SystemServer的功能，首先有一个system_server进程，通过Zygote进程fork出一个system_server进程，最终通过一系列的调用到app_main.cpp下的onZygoteInit() 对进程进行初始化，最终通过 RuntimeInit.applicationInit()执行com.android.server.SystemServer#main()，实现system_server进程对应的功能；
- 3.同样实现一个APP的功能，首先需要一个APP进程，通过Zygote进程fork出一个APP进程，最终通过一系列调用到到app_main.cpp下的onZygoteInit() 对进程进行初始化，最终 通过RuntimeInit.applicationInit()执行APP的入口类android.app.ActivityThread，实现该APP进程对应的功能。
遗留问题：那么根据这个总结下去，Server进程应该也是这么一个思路，首先fork一个server进程，然后进行初始化，最后加载该server需要实现的功能。
下一个要总结下Server进程创建过程，见Android 跨进程通信-（四）Binder机制之Server。
1068
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
