android开机 / 启动app

ServiceManager进程

 - android所有服务的大管家，基本所有app服务都通过binder驱动注册到ServiceManager进程中。 - 本身也是一个服务，init进程启动时，使用BINDER_SET_CONTEXT_MGR命令将自己注册成Service Manager时，Binder驱动会自动为它创建Binder实体。其次这个Binder的引用在所有Client中都固定为0而无须通过其它手段获得。也就是说，一个Server若要向Service Manager注册自己的Binder就必需通过0这个引用号和Service Manager的Binder通信。（持有serviceManager的binder代理对象）系统会将应用程序所需的各种服务通过 Binder 驱动注册到系统中（ServiceManager 先被注册，之后其他服务再通过 ServiceManager 进行注册），然后当某个客户端需要使用某个服务的时候，也需要与 Binder 驱动进行交互，Binder 会通过服务的名称到 ServiceManager 中查找指定的服务，并将其返回给客户端程序进行使用。 - android中的各种服务是什么时候注册的？      app启动的时候会启动 system_server 进程，我们的AMS、PMS、WMS等都是在该进程启动的时候通过binder驱动注册到ServiceManager中【binder驱动会为各种_MS创建位于内核中的binder节点实体，并将节点name和binder引用打包传给Servicemanager中，ServiceManager将这些信息填入查找表中，client请求时携带名字通过binder驱动从ServiceManager中查找获取服务的binder引用，就可以通信了】

开机

ClientTransaction（包装了IApplicationThread和目标acivity的token）

内部 经过 TransactionExcutor，TransactionHandler中转，以及内部类handler处理 - bindApplication() - 创建Application performCreateActivity() - 最终回调到Instrumentation.callActivityOnCreate()执行launcher页面暂停

ActivityStackSupervisor --- startSpecificActivity（）{ //判断app进程是否存在 }->

初始化linux内核相关初始化init进程

click应用图标startActivity()//1、获取ATMS的binder代理对象，开启跨进程调用//2、传递Launcher进程中的ApplicatonThread匿名binder// system_server 和 launcher进程互相持有binder代理Instrumentation.execStartActivity()

处理launcher相关

对userid做安全检查/沙箱控制（根据取值范围） ->ActivityStartControler获取ActivityStarter ->excute()  ->startActivityUnChecked() {通过ActivityStarter：封装activity启动模式、任务栈，处理ActivityStack-TaskRecord-activityRecord 内部AcitityStackSupervisor处理不同app任务栈（ActivityStack）}- >ActivityStack --- resumeTopActivityInnerLocked ->

app进程

YES

是否启动app（非程序逻辑做区分）

启动各种进程服务：

app /activity启动流程

属性

NO这就相当于应用内走startActivitybinder方式

ATMS（老版本AMS）

创建文件目录挂载分区

no -> socket ipc通知zygote创建app进程

//通知zygote孵化进程 ATMS.startProcessAsync()

内部 经过 TransactionExcutor，TransactionHandler中转，以及内部类handler处理 - performPauseActivity() - 最终回调到Instrumentation.callActivityOnPause()执行launcher页面暂停

1、preload预加载公共类和资源，为提高app启动效率

2、创建LocalServerSocket，开启runSelectLoop()循环监听客户端请求，并完成fork进程

3、fork并启动system_server进程

fork()

copy-on-write即写时拷贝技术，提高应用运行速度，降低了内存的使用量。fork()创建的的时候不进行内存的复制，这是因为复制内存的开销是很大的，此时子进程只需要共享父进程的内存空间即可，而当子进程需要需要修改共享内存信息时才将内存信息复制到自己的内存中，并进行修改

yes -> binderipc启动新activity

//启动ActivityClientLifeCyclerManager:  scheduleTransaction(ClientTransaction) {   IApplicationThread client = transaction.getClient();   transaction.schedule();}

binder方式

本次交给ATMS处理任务栈，封装avtivity，然后执行transaction.schedule()binder方式

socket方式

ActivityThread（App入口）

zygote进程启动会执行

zygote方式

system_server进程启动

SurfaceFlinger进程

处理动画相关，这里初始化为了处理开机动画

launcher进程

system_server进程

luancher启动

1、请求PMS获取已安装应用的信息（图标/name），用来适配桌面2、执行resumeFocusTopActivity() ->   resumeTopActivityInnerLock() -> 回到activity启动逻辑，判断进程 -> clientTransaction一系列中转 -> 回到launcher进程ApplicationThread -> bindAppLication（通过内部类handler.sendmsg通知ActivityThread，Instrumentation来创建AppLication） -> attachApplicationLocked（一样通过handler，AT，Ins反射创建activity，执行oncreate方法）使用socket、binder，使用hander

暂停前台activity（launcher在前台）

ActivityStack.startPausingLocked() - >//binder暂停activityClientLifeCyclerManager:  scheduleTransaction(ClientTransaction) {   IApplicationThread client = transaction.getClient();   transaction.schedule();}

Zygote进程

LocalServerSocket{ runSelectLoop() // （启动时已经创建）监听请求，fork进程}

main()attach(){  ATMS.attachApplication(ApplicationThread)}