书籍: Android进阶解密

followYouself

已于 2022-06-08 00:30:23 修改

阅读量1.3k

点赞数

分类专栏： Android 文章标签： android java android studio

于 2021-08-22 14:59:07 首次发布

本文链接：https://blog.csdn.net/followYouself/article/details/119852659

版权

19 篇文章

订阅专栏

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进程孵化出的桌面进程.

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进程和应用程序进程通信的桥梁.

先由Launcher 向AMS 发送请求, AMS通过 startProcessLocked 函数向Zygote请求fork新进程,新进程启动后,首先调用ActivityThread 的默认main函数
应用程序新进程在ActivityThread类中进入attachApplication 方法向 AMS通信
AMS进入 attachApplicationLocked 函数,调用 ActivityStackSupervisor 类的 attachApplicationLocked 函数, 通过IApplicationThread Binder调用scheduleLaunchActivity函数, 启动Activity
应用程序进程启动新Activity.(scheduleLaunchActivity)

每一次 startService()都会对应一次 onStartCommand() 回调, 回调的参数是传入的Intent对象.
startService()的调用不会累计, 无论调用多少次startService()函数, 一次stopService()调用就会停止Service.
系统会尽最大的努力保持Service处于运行状态. 如果应用进程出现任何的崩溃,导致进程被杀. Service 总是会尝试自动重启,进行恢复.
startService() 的返回值是 ComponentName. 如果Service此时正在启动或者已经处于运行状态,那么ComponentName将返回实际启动的Service信息.如果此时Service还没有启动,那么将返回null.

boolean bindService(Intent service, @NonNull ServiceConnection conn, @BindServiceFlags int flags)
ServiceConnection 当Service服务启动或者停止的时候,接收回调通知. Android 系统会在与服务的连接意外中断时（例如当服务崩溃或被终止时）调用该方法。注意:当客户端取消绑定时，系统“绝对不会”调用该方法。
返回值.true 表示调用绑定函数成功. false 表示绑定失败.注意此时仍然需要调用 unbindService函数去释放连接.

Context的实现类是ContextImpl. 采用装饰器模式, ContextWrapper继承于Context, 组合了 ContextImpl对象.
Context数量 = Activity数量 + Service数量 + 1
Application、Service、activity 都是继承Context的.
getApplicationContext 和 getApplication 返回的是同一个对象 (此处仍然存疑), 都是应用的Application 对象. 因为应用应用就有一个Application对象, 该对象是 LoadApk 的成员变量.

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里缓存一份.

window 是一个接口. 唯一的一个实现类是PhoneWindow.
WindowManager是一个抽象类, 有一个实现类是 WindowManagerImpl. WindowManagerImpl通过 WindowManagerGlobal 和 WMS进行通信.
WindowManager 和 window 之间是桥接模式进行关联的. 他们分别代表两个维度,对window进行管理.
WMS的职责窗口管理(WindowManager)、窗口动画(WindowAnimator)、Input系统中转(IMS)、Surface管理(用于SurfaceFlinger的绘制).

系统的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