Android系统启动流程
- 启动电源以及系统启动
- 引导程序BootLoader执行
- 启动Linux内核.启动pid为 0 的进程 swapper
- init进程启动,pid 为 1.
引导孵化出Zygote进程(Java进程).启动Native层的Media Server、Service Manager(binder 服务管家)、开机动画. - Zygote 进程. 第一个java进程,加载虚拟机
- SystemServer进程. framework进程,包含多种服务.AMS,WMS 等等
- Launcher进程.由Zygote进程孵化出的桌面进程.
AMS
- android/app/ActivityManager.java
通过 AIDL 调用AMS 服务 - com/android/server/am/ActivityManagerService.java
- com/android/server/am/ActivityStarter.java
- com/android/server/am/ActivityStackSupervisor.java
- com/android/server/am/ProcessRecord.java
- com/android/server/am/TaskRecord.java
- android/server/am/ActivityRecord.java
记录 Activity信息 - com/android/server/am/ActivityStack.java
- android/app/IApplicationThread.aidl
AIDL 文件,其实现是 ApplicationThread, 继承了 IAppllicationThread.Stub. 是ActivityThread类的内部类. ApplicationThread是 AMS服务所在SystemServer进程 和 应用程序进程通信的桥梁.
AMS小知识点
- AMS是在SystemServer进程初始化的时候创建的.
- AMS是系统服务,继承于 SystemService,而不是继承于普通的Service
startProcessLocked函数可以启动一个新的应用进程getProcessRecordLocked根据进程名字和UID 获取已经存在的进程.如果不存在, 返回空
从Launcher启动一个应用程序
- https://blog.csdn.net/abm1993/article/details/85137753
- https://blog.csdn.net/qq_43093708/article/details/83217256
- 先由Launcher 向AMS 发送请求, AMS通过 startProcessLocked 函数向Zygote请求fork新进程,新进程启动后,首先调用ActivityThread 的默认main函数
- 应用程序新进程在ActivityThread类中 进入attachApplication 方法向 AMS通信
- AMS进入 attachApplicationLocked 函数,调用 ActivityStackSupervisor 类的 attachApplicationLocked 函数, 通过IApplicationThread Binder调用scheduleLaunchActivity函数, 启动Activity
- 应用程序进程启动新Activity.(scheduleLaunchActivity)
Service 相关
startService() 函数
- 每一次
startService()都会对应一次onStartCommand()回调, 回调的参数是传入的Intent对象. startService()的调用不会累计, 无论调用多少次startService()函数, 一次stopService()调用就会停止Service.- 系统会尽最大的努力保持Service处于运行状态. 如果应用进程出现任何的崩溃,导致进程被杀. Service 总是会尝试自动重启,进行恢复.
startService()的返回值是ComponentName. 如果Service此时正在启动或者已经处于运行状态,那么ComponentName将返回实际启动的Service信息.如果此时Service还没有启动,那么将返回null.
bindService
boolean bindService(Intent service, @NonNull ServiceConnection conn, @BindServiceFlags int flags)- ServiceConnection 当Service服务启动或者停止的时候,接收回调通知. Android 系统会在与服务的连接意外中断时（例如当服务崩溃或被终止时）调用该方法。注意:当客户端取消绑定时，系统“绝对不会”调用该方法。
- 返回值.true 表示调用绑定函数成功. false 表示绑定失败.注意此时仍然需要调用
unbindService函数去释放连接.
onBind
- 返回binder
onUnbind
- 只有所有的客户端连接都断开的时候,才会执行此函数.
onRebind
- 只有在onUnbind 函数返回 true的时候,系统才会调用此函数.至于原因??
Context
- Context的实现类是ContextImpl. 采用装饰器模式, ContextWrapper继承于Context, 组合了 ContextImpl对象.
- Context数量 = Activity数量 + Service数量 + 1
- Application、Service、activity 都是继承Context的.
getApplicationContext和getApplication返回的是同一个对象 (此处仍然存疑), 都是应用的Application 对象. 因为应用应用就有一个Application对象, 该对象是 LoadApk 的成员变量.
getSystemService()
- context.getSystemService(String name) 获取系统服务. 系统服务都是通过Client 和 Server 架构提供服务的. Server端都是运行在SystemServer进程的. 通过 getSystemService 获取的系统服务实际是服务的一个client实例. 例如获取 AMS服务,实际获取的是ActivityManager的实例.然后 通过ActivityManager 向 AMS binder通信.
- context.getSystemService 调用后, 调用 ContetImpl 的 getSystemService实现
- 在SystemServiceRegistry缓存的map中检索服务. SystemServiceRegistry 中 通过hashMap 缓存了 系统服务的 client端. SystemServiceRegistry 通过static 代码块 初始化缓存了一系列系统服务.
- SystemServiceRegistry 是运行在应用进程内的. getSystemService 方法的调用过程是没有IPC 跨进程调用的. 系统服务的 client端都会在SystemServiceRegistry里缓存一份.
WindowManagerService
- window 是一个接口. 唯一的一个实现类是PhoneWindow.
- WindowManager是一个抽象类, 有一个实现类是 WindowManagerImpl. WindowManagerImpl通过 WindowManagerGlobal 和 WMS进行通信.
- WindowManager 和 window 之间是桥接模式进行关联的. 他们分别代表两个维度,对window进行管理.
- WMS的职责 窗口管理(WindowManager)、窗口动画(WindowAnimator)、Input系统中转(IMS)、Surface管理(用于SurfaceFlinger的绘制).
window
- 系统的window 分为三种类型: Application window、Sub window、System window. 应用窗口、子窗口、系统窗口.
- window添加新View流程:WindowManager.addView --> RootViewImpl.setView --> Session.addToDisplay --> WindowManagerService.addWindow
- window更新 view 的调用流程. windowManager --> WindowManagerImpl --> WindowManagerGlobal --> ViewRootImpl --> IWindowSession --> Session --> WMS
- DisplayThread.java 线程处理 WindowManager、DisplayManager、InputManager相关的低时间延迟的操作.线程名字是
android.display - UiThread 界面线程
android.ui - runWithScissors, 用于线程和handler的looper线程之间进行同步. 参考链接 https://blog.csdn.net/plokmju88/article/details/107551413