首先Android以Linux内核为基础，所以进程的管理都离不开Linux本身的机制。因此我们需要知道系统打开App的完整过程。
1.app_process：一个可执行程序，是启动zygote和system_server进程的程序
2.Zygote：所以应用程序的父进程，系统的重要进程
3.ActivityManager：am（缩写）是辅助Android四大组件的管理，并且还掌握了所有应用程序进程的创建和进程的优先级管理
init进程
他是一切的开始，在Android系统中，所有进程的进程号都不确定，唯独init进程的进程号一定是1。
以上就是关于framework工作的大致流程。
在四大组件中的任何一个先起来都会导致应用程序的创建。
Activity
在应用程序中，我们会通过startActivity(Intent intent)，startService(Intent service)，sendBroadcase(Intent intent)，ContentResolver打开的ContentProvider，当然还有一些其他的重载方法。在这里提到的所有方法，最终都是通过Binder调用到ActivityManagerService中，尤其进行处理的。并且应用进程与ActivityManagerService所在进程是相互独立的，两者之间的方法通常是不能之间互相调用的。而Android系统中，专门提供了Binder框架来提供进程间通讯和方法调用的能力。
在ActivityManagerService中，对每一个运行中的Activity都有一个ActivityRecord对象与之对应，这个对象记录Activity的详细状态。
Activity的启动背景：
ActivityManagerService中通过Stack和Task来管理Activity
每一个Activity都属于一个Task，一个Task可能包含多个Activity。一个Stack包含多个Task
ActivityStackSupervisor类负责管理所有的Stack
Activity的启动过程会牵涉到：Intent的解析、Stack，Task的查询或创建、Activity进程的创建、Activitiy窗口的创建、Activity的生命周期调度
在Activity启动的最后，会将前一个Activity pause，将新启动的Activity resume以便被用户看到。
在这个时候，如果发现新启动的Activity进程还没有启动，则会通过startSpecificActivityLocked将其启动。
Service
Service的启动相对与Activity来说要简单一些。
在ActivityManagerService中，对每一个运行中的Service都有一个ServiceRecord对象与之对应，记录Service的详细状态。
Provider
在ActivityManagerService中，对每一个运行中的ContentProvider都有一个ContentProviderRecord对象与之对应，来记录其详细状态。
我们通过ContentResolver中的insert、delete、update、query的API来使用ContentProvider。在ContentResolver的实现中，无论使用这里的哪个接口，ContentResolve都会先通过acquireProvider这个方法来获取到一个类型为IContentProvider的远程接口。这个远程接口对接了ContentProvider的实现提供方。
同一个ContentProvider可能同时被多个模块使用，而调用ContentResolver接口的进程只是ContentProvider的一个客户端而已，真正的ContentProvider提供方是运行自身的进程中的，两个进程的通讯需要通过Binder的远程接口形式来调用。如图：
Receiver
广播是一种一对多的消息形式，广播接收者的数量不确定。因此发送广播本身可能是一个很耗时的过程（因为要逐个通知）。
在ActivityManagerService内部是通过队列的形式来管理广播的：BroadcaseQueue(描述了一个广播队列)、BroadcaseRecord(描述了一个广播事件)。
在ActivityManagerService中，如果收到了一个发送广播的请求，会先创建一个BroadcaseRecord接着将其放入BroadcaseQueue中。然后通知队列自己去处理这个广播。然后ActivityManagerService自己就可以继续处理其他请求了。
广播队列本身是在另一个线程处理广播的发送的，这样保证的ActivityManagerService主线程的负载不会太重。