材料引用blog:http://gityuan.com/ 

App主要是具体的UI业务需求.
AMS则是管理系统四大组件以及进程管理，尤其是Activity的各种栈以及状态切换等管理；
WMS则是管理Activiy所相应的窗口系统(系统窗口以及嵌套的子窗口)；
SurfaceFlinger则是将应用UI绘制到frameBuffer(帧缓冲区),最终由硬件完成渲染到屏幕上

交互

• App跟AMS通信，会建立Session连接到WMS，后续便通过IWindowSesson跟WMS通信；
• WMS跟SF通信，WMS建立SurfaceComposerClient，然后会在SF中创建Client与之对应， 后续便通过ISurfaceComposerClient跟SF通信；

系统启动架构图

 图解： Android系统启动过程由上图从下往上的一个过程是由Boot Loader引导开机，然后依次进入 -> Kernel -> Native -> Framework -> App
2.1 Linux内核层，2.2 硬件抽象层 (HAL) ，2.3 Android Runtime & 系统库，2.4 Framework层，2.5 App层，2.6 Syscall && JNI
app和framework之间用jni. framework和kernal之间是syscall

Boot Loader引导开机，然后依次进入 -> Kernel -> Native -> Framework -> App

启动流程：

1. 点击桌面App图标，Launcher进程采用Binder IPC向system_server进程发起startActivity请求；
2. system_server进程接收到请求后，向zygote进程发送创建进程的请求；
3. Zygote进程fork出新的子进程，即App进程；
4. App进程，通过Binder IPC向sytem_server进程发起attachApplication请求；
5. system_server进程在收到请求后，进行一系列准备工作后，再通过binder IPC向App进程发送scheduleLaunchActivity请求；
6. App进程的binder线程（ApplicationThread）在收到请求后，通过handler向主线程发送LAUNCH_ACTIVITY消息；
7. 主线程在收到Message后，通过发射机制创建目标Activity，并回调Activity.onCreate()等方法。

到此，App便正式启动，开始进入Activity生命周期，执行完onCreate/onStart/onResume方法，UI渲染结束后便可以看到App的主界面。 启动Activity较为复杂，后续计划再进一步讲解生命周期过程与系统是如何交互，以及UI渲染过程，敬请期待。

每个module作用：

system_server进程是系统进程，Java framework框架的核心载体，里面运行了大量的系统服务，比如这里提供ApplicationThreadProxy（简称ATP），ActivityManagerService（简称AMS），这个两个服务都运行在system_server进程的不同线程中，由于ATP和AMS都是基于IBinder接口，都是binder线程，binder线程的创建与销毁都是由binder驱动来决定的。

App进程是应用程序所在进程，主线程主要负责Activity/Service等组件的生命周期以及UI相关操作都运行在这个线程； 另外，每个App进程中至少会有两个binder线程 ApplicationThread(简称AT)和ActivityManagerProxy（简称AMP），除了下图中所示的线程，其实还有很多线程，比如signal catcher线程等。

Framework层（java frame & c++ frame）

• Zygote进程，是由init进程通过解析init.rc文件后fork生成的，Zygote进程主要包含：
  • 加载ZygoteInit类，注册Zygote Socket服务端套接字
  • 加载虚拟机
  • 提前加载类preloadClasses
  • 提前加载资源preloadResouces
• System Server进程，是由Zygote进程fork而来，System Server是Zygote孵化的第一个进程，System Server负责启动和管理整个Java framework，包含ActivityManager，WindowManager，PackageManager，PowerManager等服务。
• Media Server进程，是由init进程fork而来，负责启动和管理整个C++ framework，包含AudioFlinger，Camera Service等服务。

App层

• Zygote进程孵化出的第一个App进程是Launcher，这是用户看到的桌面App；
• Zygote进程还会创建Browser，Phone，Email等App进程，每个App至少运行在一个进程上。
• 所有的App进程都是由Zygote进程fork生成的。

每一个Activity对应一个应用窗口；每一个窗口对应一个ViewRootImpl对象；
每一个App进程对应唯一的WindowManagerGlobal对象；
WindowManagerGlobal.sWindowManagerService用于跟WMS交互.
WindowManagerGlobal.sWindowSession用于跟Session交互；
每一个App进程对应唯一的相同Session代理对象；
App可以没有Activity/PhoneWindow/DecorView，例如带悬浮窗口的Service；
Activity运行在ActivityThread所在的主线程；
DecorView是Activity所要显示的视图内容；
ViewRootImpl：管理DecorView跟WMS的交互；每次调用addView()添加窗口时，则都会创建一个ViewRootImpl对象；

源码分析参考：Android系统启动-zygote篇 http://gityuan.com/2016/02/13/android-zygote/ ---这个blog写的比较详细具体
startService源码从AMS进程到service的新进程启动过程分析：https://www.jianshu.com/p/e9f579c3b6d0
Android系统启动-综述 http://gityuan.com/2016/02/01/android-booting/

，，，，，，，，，，，，，，，，，，，，，，，

Android系统启动过程:
|启动Kernel创建init进程-->init进程fork第一个进程即Zygote进程(横穿Java和C/C++)-->Zygote创建虚拟机(调用AndroidRuntime.cpp中的startVm创建虚拟机)-->startReg完成虚拟机中的JNI方法注册 

,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

//先启动AMS,Process.sart 启动new serviceB，然后serviceB和AMS通信，然后到UI 线程

1 ActivityManagerService(AMS)的startService 
2 底层调用  Process.start 
Process.start()会启动service的新进程。然后导入android.app.ActivityThread类实行它的main函数。
在Android应用程序中，每一个进程对应一个ActivityThread实例，在实行main函数中，会创建一个thread实例。
所以ServiceManagerNative.asInterface(new BinderProxy())==new ServiceManagerProxy(new BinderProxy())
3 ActivityThread类的main函数：
1) main函数中创建该进程的UI线程的Looper以及loop().
2) 创建完ActivityThread,调用ActivityThread.attach函数。
在attach函数中,会调用ActivityManagerNative.getDefault().attachApplication(mAppThread)函数
得到ActivityManagerService(AMS)的远程接口，即ActivityManagerProxy。
3) mAppThread是ApplicationThread对象，它是service新进程，通过Binder驱动程序传递给ActivityManagerService(AMS)进程里.
(mAppThread(new service)----<binder>----AMS)
AMS进程通过IApplicationThread对象跟service新进程通信.
AMS进程把mAppThread设置到代理ApplicationThreadProxy的mRemote。
ActivityManagerProxy:attachApplication(app)
4 在AMS onTransact()-->父类ActivityManagerNative的onTransact(),
其中ApplicationThreadNative.asInterface(data.readStrongBinder())，返回是ApplicationThreadProxy的对象，
把之前的IApplicationThread的实例mAppThread对象（通过Binder驱动放到data里面，即data.readStrongBinder()）放到ApplicationThreadProxy的mRemote.
在AMS进程里通过ApplicationThreadProxy中mRemote和service新进程通信。
((mAppThread放到ApplicationThreadProxy的mRemote<------>service新进程通信))
在AMS中的attachApplication中：mServices是ActiveServices实例对象
5 ApplicationThreadProxy的scheduleCreateService：
其中mRemote就是service新进程的ApplicationThread对象，
通过Binder驱动程序回到service新进程的ApplicationThread对象中去执行onTransact(),
6 在H类handleMessage 中：
handlerCreateService是在ActivityThread：//H.CREATE_SERVICE.回到新进程的UI线程
service.onCreate(),service就起来了。
最终通过ClassLoader加载Activity类，创建对象，回调对应的生命周期，整个过程结束。

// ServiceManagerNative.java
static public IServiceManager asInterface(IBinder obj) {
    //由于obj为BpBinder，该方法默认返回null
    IServiceManager in = (IServiceManager)obj.queryLocalInterface(descriptor);
    return new ServiceManagerProxy(obj); //见下文
}
class ServiceManagerProxy implements IServiceManager {
    public ServiceManagerProxy(IBinder remote) {
        mRemote = remote; //将BinderProxy保存到mRemote
    }
}
所以ServiceManagerNative.asInterface(new BinderProxy())==new ServiceManagerProxy(new BinderProxy()). 
mRemote为BinderProxy对象，该BinderProxy对象的成员变量mObject记录着BpBinder(0)，其作为binder代理端，指向大管家serviceManager进程的服务。
ServiceManager.getIServiceManager==new ServiceManagerProxy(new BinderProxy())，此处ServiceManagerProxy简称为SMP。
framework层的ServiceManager的调用实际的工作确实交给SMP的成员变量BinderProxy；
而BinderProxy通过jni方式，最终会调用BpBinder对象；可见上层binder架构的核心功能依赖native架构的服务来完成的。

,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

 loadLibrary动态库加载过程分析

动态库加载程，调用栈如下：

System.loadLibrary()
  Runtime.loadLibrary()
    Runtime.doLoad()
      Runtime_nativeLoad()
          LoadNativeLibrary()
              dlopen()
              dlsym()
              JNI_OnLoad()

System.loadLibrary()和System.load()都用于加载动态库，loadLibrary()可以方便自动加载依赖库，load()可以方便地指定具体路径的动态库。对于loadLibrary()会将将xxx动态库的名字转换为libxxx.so，再从/data/app/[packagename]-1/lib/arm64，/vendor/lib64，/system/lib64等路径中查询对应的动态库。无论哪种方式，最终都会调用到LoadNativeLibrary()方法，该方法主要操作：

• 通过dlopen打开动态共享库;
• 通过dlsym获取JNI_OnLoad符号所对应的方法；
• 调用该加载库中的JNI_OnLoad()方法。