素材来源于“AMS 的启动过程分析”“PMS 的启动过程分析”“安装包的解析过程分析”三段视频。 一、system_server 应用进程里的 Application.onCreate 已经处于启动链后段。此时系统早已知道包名对应哪个 UID、入口 Activity 是谁、它声明了哪些 intent-filter。这些数据若到 startActivity 时才从 APK 临时读取，每次组件解析

本文整理自享学团队直播课《Android 插件化(三)：资源加载》。 前面两讲把插件的类和 Activity 都"骗"进来了，但插件的 Activity 跑起来之后，getResources 拿到的还是宿主的资源——图片、字符串、布局全是宿主那套。这一讲要做的就是让插件用自己的 AssetManager 单独加载一份属于插件的资源。 要做到这一点，你得先想通两件事： 上一讲那两个 Hook 点

本文整理自享学团队直播课《Android 插件化(二)：Activity加载》。 上一讲解决的是"插件的类能被加载进来"，这一讲解决的是"插件的 Activity 能真正被启动"。前者靠类加载器，后者靠 Hook——在 Android 启动 Activity 的链路中间安插一个钩子，把"要启动哪个 Activity"这个信息偷偷换一遍，让一个已注册的占坑 Activity 去骗过 AMS 的校验，

本文内容整理自享学团队直播课《App 启动流程源码分析（二）》 一、本集要解决的问题 《一》把"启动"的边界定死了：从点击 icon 到主 Activity 显示。也画了四进程的地图，结尾留了一个口子——下一篇从 Launcher 的 startActivity 跟到 AMS 请求 Zygote fork。本集从这个口子接上。 核心问题只有一个：从点击桌面图标，到 App 进程真正跑起来并创建好

一、面试题：广播如何跨进程 1.1 题目的真实问法 听上去在考 BroadcastReceiver，实际问的是四大组件的底层通信机制——广播只是四个组件里被挑出来的那一个，换成 Activity 启动、bindService、ContentProvider 查询，答案的骨架完全一样。 只回答「广播走 Binder」拿不到分。面试官想听的是这条链路上有哪几站、每一站由谁完成、哪几步跨了进程。 1.2

一、Binder 为什么是面试必问题 1.1 大厂必问 Handler 和 Binder 是 Android 面试里出现频率最高的两道基础题，公司规模越大问得越细。Handler 还好，多数人写过 postDelayed、debug 过 ANR，多少有点感性认识；Binder 就不一样，工作三五年却讲不清它是什么的开发者相当多。 原因在于日常开发几乎接触不到它的存在——startActivity