Dorck's Blog

修技术之道，日三省吾身 | App Dev & Freelance Thinker & Hacker Growth | 这里是 @道轲(Dorck) 的个人博客，与你一起探寻世界。

把文章发布到掘金，做成一个可复用的 juejin-skill

很多工具的起点都不宏大，往往只是为了去掉一段反复出现、但没有创造性的劳动。 <a href="https://github.com/Moosphan/juejin-skill">juejin-skill</a> 也是这样长出来的。我平时习惯在本地写 Markdown，配图和草稿都按项目目录管理。文章完成后，再回到掘金编辑器里补分类、挑标签、上传图片、创建草稿，偶尔做一次问题不大，但只要写作频率稍微稳定一点，这条链路就会迅速变成额外负担。更麻烦的是，文章一旦修改，还得回到网页端重新同步一遍，本地明明已经有完整原稿，却还要重复操作。  把这件事拆开以后，真正需要被自动化的部分其实非常集中： <ul> <li>登录态最好能复用，而不是每次重新处理登录流程。</li> <li>分类、标签和热榜信息应该可以直接查询，最好还能给出合理推荐。</li> <li>本地 Markdown 应该能够直接转换成平台草稿。</li> <li>本地图片需要在发布前完成上传和替换，不能把相对路径带到线上。</li> <li>已发布文章需要支持基于本地稿件继续更新。</li> <li>真正公开发布时，应该保留一次明确确认。</li> </ul> 于是就有了 <a href="https://github.com/Moosphan/juejin-skill">juejin-skill</a>。它现在是一套同时面向 Codex 和 Claude Code 的掘金发文 Skill，底层共用一套 Node.js CLI。两个 Agent 的接入方式不同，但最终执行的是同一条发布链路。 这篇文章会按照实现顺序，讲清楚它为什么这样拆、哪些设计后来证明是必要的。出于安全和稳定性的考虑，文中对少量平台内部接口路径、字段名和上传链路细节做了抽象化处理，但整体实现思路与工程结构保持真实。 <h2 id="一先把能力收敛到-cli">一、先把能力收敛到 CLI</h2> 做 Agent Skill 时，很容易先写提示词，让模型去判断“什么时候该发布、什么时候该更新、参数该怎么组装”。这种方式短期能跑，但随着功能变多，维护成本会上升得很快。更稳妥的做法，是先把确定性的动作收敛到 CLI，再让不同平台的 Skill 文档去调用这套命令。 现在 <a href="https://github.com/Moosphan/juejin-skill">juejin-skill</a> 的命令大致是这几类： <div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 </pre></td><td class="rouge-code"><pre>juejin-skill login juejin-skill verify juejin-skill categories juejin-skill tags --category <category-id> juejin-skill hot --limit 10 juejin-skill publish --file ./article.md --category <category-id> juejin-skill update --article https://juejin.cn/post/<article-id> --file ./article.md juejin-skill download --article https://juejin.cn/post/<article-id> </pre></td></tr></tbody></table></code></pre></div></div> CLI 放在 <code class="language-plaintext highlighter-rouge">src/commands/cli.js</code>，职责尽量保持简单：解析参数、读取文件、组装调用、输出结果。真正的业务逻辑都下沉到 <code class="language-plaintext highlighter-rouge">src/core/</code>，例如登录、热榜、发布、图片上传、下载等能力都在这一层实现。 这个分层没有复杂设计，价值却非常直接。Codex Skill 和 Claude Code 命令不需要各写一套发布逻辑，只要约定如何调用 CLI 即可。后续修复 bug、补充参数或调整发布流程时，也能保证两个平台的行为保持一致。 <h2 id="二http-层尽量薄错误尽量早暴露">二、HTTP 层尽量薄，错误尽量早暴露</h2> 掘金的核心操作最终都落在 HTTP 请求上，因此我先写了一个比较薄的 <code class="language-plaintext highlighter-rouge">JuejinHttpClient</code>。它主要负责统一请求头、带上本地会话信息，以及处理非成功响应。 <div class="language-js highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 </pre></td><td class="rouge-code"><pre>export class JuejinHttpClient { constructor({ cookie = "", fetchImpl = fetch } = {}) { this.cookie = cookie; this.fetchImpl = fetchImpl; } async post(url, body = {}, { headers = {} } = {}) { return this.#request(url, { method: "POST", headers, body: JSON.stringify(body) }); } } </pre></td></tr></tbody></table></code></pre></div></div> 这里我刻意没有做太厚的封装，比如自动重试、业务错误猜测、静默降级等。和第三方站点打交道时，接口变化、登录失效、参数缺失往往对应完全不同的问题，越早看到状态码和响应片段，排查就越快。如果客户端层过度“聪明”，出问题时反而不容易定位。 另外保留 <code class="language-plaintext highlighter-rouge">fetchImpl</code> 这个注入点，是为了让测试更干净。单元测试可以直接替换成假的 fetch，只验证请求结构和分支逻辑，不需要真的访问平台。 端点和配置统一收敛在 <code class="language-plaintext highlighter-rouge">src/core/config.js</code>。这点看起来普通，但对这类依赖网页端实现细节的工具非常重要。平台调整接口时，只改配置层，维护成本会低很多。 <h2 id="三登录交给浏览器会话交给本地文件">三、登录交给浏览器，会话交给本地文件</h2> 发布、更新和上传图片都依赖登录态。对用户来说，最自然的体验不是把账号密码交给工具，而是用浏览器完成正常登录，然后让程序复用登录结果。 <a href="https://github.com/Moosphan/juejin-skill">juejin-skill</a> 的 <code class="language-plaintext highlighter-rouge">login</code> 命令会用 Playwright 启动浏览器，打开登录页，并在登录成功后提取当前站点所需的会话 Cookie，最终保存到： <div class="language-text highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 </pre></td><td class="rouge-code"><pre>~/.juejin-skill/session.json </pre></td></tr></tbody></table></code></pre></div></div> 后续命令都从这个文件读取会话信息。这样做有几个很实际的好处： <ul> <li>工具本身不接触账号密码，也不需要处理扫码、验证码等登录细节。</li> <li>用户登录一次后，发布、更新和上传图片都可以复用同一份本地会话。</li> <li>会话失效时，只需要重新执行 <code class="language-plaintext highlighter-rouge">login</code>，不必改动其他逻辑。</li> <li>如果想撤销本地登录状态，删除 <code class="language-plaintext highlighter-rouge">session.json</code> 就可以。</li> </ul> 我还补了一个 <code class="language-plaintext highlighter-rouge">verify</code> 命令，用当前会话去校验登录状态。这个命令在实际使用里非常有价值，因为不少“发布失败”表面看像参数问题，最后往往只是会话已经过期。 <h2 id="四把分类标签和热榜纳入同一条工作流">四、把分类、标签和热榜纳入同一条工作流</h2> 发文章不是只把正文上传出去那么简单。真正落地时，往往还要先确认当前有哪些分类、某个分类下有哪些推荐标签、最近热门内容是什么。把这些辅助能力放进同一个工具里，才能让发文流程更顺手。 <a href="https://github.com/Moosphan/juejin-skill">juejin-skill</a> 目前支持： <ul> <li><code class="language-plaintext highlighter-rouge">categories</code>：查询平台分类列表。</li> <li><code class="language-plaintext highlighter-rouge">tags</code>：查询指定分类下的推荐标签，并支持关键词过滤。</li> <li><code class="language-plaintext highlighter-rouge">hot</code>：查询全站或指定分类下的热门文章。</li> </ul> 这里有一个很典型的工程经验：平台表面上“能用”的接口，不一定是最适合自动化调用的接口。早期标签能力使用过另一条数据来源，但在发布场景里稳定性不够，后来我对照网页端当前网络请求，切换到了更接近实际产品逻辑的一条接口。做这类工具时，经常需要顺着真实页面行为反推更可靠的数据入口。 如果用户在发布时没有显式指定分类，CLI 会根据标题和正文里的关键词给出推荐。比如命中 <code class="language-plaintext highlighter-rouge">Android</code>、<code class="language-plaintext highlighter-rouge">Kotlin</code>、<code class="language-plaintext highlighter-rouge">Compose</code>，就更偏向 Android；命中 <code class="language-plaintext highlighter-rouge">React</code>、<code class="language-plaintext highlighter-rouge">Vue</code>、<code class="language-plaintext highlighter-rouge">Vite</code>，就更偏向前端。 这套推荐规则并不复杂，但我很喜欢它的两个特点：可解释、可测试。Agent 可以直接告诉用户“为什么推荐这个分类”，而不是给出一个黑盒结论。分类会影响文章的受众，因此我没有让工具默默替用户做最终决定，而是把推荐结果作为辅助信息交给作者确认。 <h2 id="五发布默认只创建草稿">五、发布默认只创建草稿</h2> 真正的发布逻辑集中在 <code class="language-plaintext highlighter-rouge">ArticlePublisher.publishMarkdown()</code>。整体流程大致如下： <ol> <li>读取 Markdown 文件。</li> <li>提取第一个一级标题作为文章标题。</li> <li>从正文中移除标题行，避免平台正文重复出现标题。</li> <li>扫描本地图片，完成上传并替换成可公开访问的地址。</li> <li>生成摘要，除非用户显式传入 <code class="language-plaintext highlighter-rouge">--brief</code>。</li> <li>将 Markdown 渲染为 HTML，并同步整理平台所需的图片元数据。</li> <li>创建文章草稿。</li> <li>只有在明确确认后，才执行公开发布。</li> </ol> 默认行为是“创建草稿而不是直接公开”。要真正发布，必须显式传入： <div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 </pre></td><td class="rouge-code"><pre>--publish --confirm-publish </pre></td></tr></tbody></table></code></pre></div></div> 也可以通过环境变量开启明确确认： <div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 </pre></td><td class="rouge-code"><pre>JUEJIN_CONFIRM_PUBLISH=1 </pre></td></tr></tbody></table></code></pre></div></div> 这个边界我设得比较坚决。自动化非常适合承担重复劳动，例如读取原稿、上传图片、创建草稿；但公开发布意味着内容会对外可见，工具最好只在作者明确授权后才继续推进。 标题提取也只认第一个一级标题。这样本地 Markdown 仍然可以保持常见写法： <div class="language-md highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 </pre></td><td class="rouge-code"><pre># 我的文章标题 正文从这里开始。 </pre></td></tr></tbody></table></code></pre></div></div> 对作者来说，本地文稿依旧完整；对平台来说，标题和正文则被正确拆分到不同字段中。 <h2 id="六本地图片上传是整条链路最容易出问题的部分">六、本地图片上传，是整条链路最容易出问题的部分</h2> 本地 Markdown 里经常会有这样的图片引用： <div class="language-md highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 </pre></td><td class="rouge-code"><pre>![架构图](./images/architecture.png) </pre></td></tr></tbody></table></code></pre></div></div> 在本地预览时它完全正常，但只要把这段 Markdown 直接提交到平台，线上读者就无法访问作者电脑里的相对路径。也正因为如此，图片上传几乎是整条发文链路里最容易出问题、也最必须做好的部分。 <code class="language-plaintext highlighter-rouge">0.1.2</code> 版本之后，我补上了完整的本地图片处理。逻辑分成两步。 第一步，识别 Markdown 中的图片链接。工具只处理本地文件路径，远程图片、<code class="language-plaintext highlighter-rouge">data:</code> 图片和其他非本地资源会直接跳过。相对路径统一按 Markdown 文件所在目录解析；同一张图片多次出现时，只上传一次，后续复用上传结果。 第二步，走平台当前网页编辑器所使用的媒体上传链路。这里我不展开具体接口细节，只保留实现层面的关键抽象：先拿一次临时授权，再申请上传会话，上传二进制文件，最后提交会话并换取可用于正文的正式资源地址。 这部分实现时有两个容易踩坑的点。 一个是媒体链路里通常存在平台侧资源标识和上传会话标识，它们对最终提交格式有约束，不能只看见“上传成功”就结束。另一个是正文内容和图片元数据往往要同时更新，编辑器能显示图片，并不代表文章提交后的内容结构就是完整的。 所以在实现里，<code class="language-plaintext highlighter-rouge">prepareJuejinContent()</code> 不只是简单替换 Markdown 图片地址，它还会同步整理 HTML 内容和平台要求的图片元数据，确保草稿、编辑器预览和最终文章使用的是同一组资源描述。做完这一层之后，发布流程才算真正稳定。 <h2 id="七更新文章时尽量不要碰用户没让你碰的东西">七、更新文章时，尽量不要碰用户没让你碰的东西</h2> 文章发布之后，本地稿件继续修改是常态。于是 <code class="language-plaintext highlighter-rouge">update</code> 命令对应解决的是另一个高频问题：如何让本地 Markdown 安全地同步回线上文章。 <div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 </pre></td><td class="rouge-code"><pre>juejin-skill update \ --article https://juejin.cn/post/<article-id> \ --file ./article.md </pre></td></tr></tbody></table></code></pre></div></div> 默认行为依旧是更新草稿。如果要进一步同步到公开文章，还需要显式确认： <div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 </pre></td><td class="rouge-code"><pre>juejin-skill update \ --article https://juejin.cn/post/<article-id> \ --file ./article.md \ --publish \ --confirm-publish </pre></td></tr></tbody></table></code></pre></div></div> 更新流程比新建草稿多了一层：程序会先根据文章链接获取文章详情，再找到与之关联的编辑上下文，随后更新对应草稿。这里最重要的不是“把正文换掉”，而是“尽量保留原文章的其他信息”。 分类、标签、封面、摘要、主题、原创状态这类元信息，理论上都应该继承原值。否则用户只是想修一张图、改一个段落，最后却把封面清空了、标签弄丢了，体验会非常差。 另外，平台里某些标识字段的数值范围已经很大，更新逻辑里如果处理不谨慎，容易遇到精度问题。所以实现上我优先沿用原始字符串形式，而不是把所有字段都当作普通数字处理。 我对这部分能力的要求一直很明确：少做多余的事。正文可以更新，图片可以重传，但用户没有显式要求修改的元信息，不应该被工具顺手“重置”。 <h2 id="八下载能力补齐了内容闭环">八、下载能力补齐了内容闭环</h2> 除了发布和更新，项目里还补了一组下载命令： <div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 </pre></td><td class="rouge-code"><pre>juejin-skill download --article https://juejin.cn/post/<article-id> juejin-skill download-user --user https://juejin.cn/user/<user-id> --max-count 20 </pre></td></tr></tbody></table></code></pre></div></div> 下载单篇文章时，程序会优先尝试获取平台返回的 Markdown 内容；如果拿不到，再退回到浏览器抓取页面正文 HTML，并通过 Turndown 转回 Markdown。 如果带上 <code class="language-plaintext highlighter-rouge">--download-images</code>，远程图片会一并下载到本地目录，Markdown 里的地址也会被改写成本地相对路径。 这个能力一开始只是“顺手做了”，后来反而让我觉得它很重要。它让文章内容形成了闭环：线上文章可以回收到本地 Markdown，本地 Markdown 也可以重新发布和继续更新。对长期写技术文章的人来说，本地原稿、图片和历史版本始终掌握在自己手里，是非常有价值的事情。 <h2 id="九codex-和-claude-code-共用一套运行时">九、Codex 和 Claude Code 共用一套运行时</h2> <a href="https://github.com/Moosphan/juejin-skill">juejin-skill</a> 同时服务 Codex 和 Claude Code，但我没有为两个平台各维护一套逻辑，而是让它们共用同一套 Node.js CLI。 Codex 侧主要依赖 <code class="language-plaintext highlighter-rouge">SKILL.md</code>，用于描述何时触发、有哪些命令、默认的安全边界是什么；Claude Code 侧则在 <code class="language-plaintext highlighter-rouge">.claude/commands/</code> 下定义命令文档，例如 <code class="language-plaintext highlighter-rouge">juejin-publish.md</code>、<code class="language-plaintext highlighter-rouge">juejin-hot.md</code>、<code class="language-plaintext highlighter-rouge">juejin-login.md</code>。 两边文档格式不同，但最终调用的都是同一个入口： <div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 </pre></td><td class="rouge-code"><pre>node ./bin/juejin-skill.js ... </pre></td></tr></tbody></table></code></pre></div></div> 构建脚本会生成两套分发目录： <div class="language-text highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 </pre></td><td class="rouge-code"><pre>dist/codex/juejin-skill dist/claude/juejin-skill </pre></td></tr></tbody></table></code></pre></div></div> 这种结构的好处很直接：功能只实现一次，测试也围绕同一套核心代码展开，平台适配层只负责“怎么接”，而不负责“怎么做”。 <h2 id="十既然打算复用就把工程化一起补齐">十、既然打算复用，就把工程化一起补齐</h2> 如果一个 Skill 只能在作者自己的机器上工作，它本质上还只是个人脚本。既然想让它被复用，就必须把版本发布和交付路径也做完整。 现在推送 <code class="language-plaintext highlighter-rouge">v*</code> 标签后，GitHub Actions 会自动完成这些事： <ol> <li>安装依赖和浏览器运行环境。</li> <li>运行 lint 和测试。</li> <li>构建 Codex、Claude 两套产物。</li> <li>生成版本说明。</li> <li>打包并上传 Release 附件。</li> </ol> 这一层我也踩过一个很典型的 CI 坑：自动创建 Release 时返回权限错误。最后定位下来，并不是脚本逻辑有问题，而是 workflow token 缺少写入发布内容所需的权限。 这类问题并不复杂，却很容易被忽略。尤其当一个工具要交付给别人安装和使用时，构建产物、版本说明、Release 附件、安装入口这些环节都必须跑通，否则代码虽然写完了，使用体验仍然是不完整的。 <h2 id="十一测试守住的是我们自己的边界">十一、测试守住的是我们自己的边界</h2> 这个项目的测试覆盖了认证、标签、图片上传、发布更新、下载和分类推荐等核心能力。 我没有试图在测试里证明“平台永远不会变”。第三方接口会调整，页面结构会变，登录策略也可能改变。测试真正适合守住的，是我们自己定义的那些边界和规则。 例如： <ul> <li>同一张本地图片重复出现时，只上传一次。</li> <li>远程图片和 <code class="language-plaintext highlighter-rouge">data:</code> 图片不会被误判为本地文件。</li> <li>更新文章时尽量保留原有分类、标签、封面和主题信息。</li> <li>没有明确确认时，发布流程只停留在草稿阶段。</li> <li>标识字段尽量沿用字符串表示，降低精度风险。</li> </ul> 这些规则稳定之后，排查问题会快很多。出故障时，我们能够更快区分：到底是登录态失效、平台接口变化、媒体链路异常，还是我们自己的参数组织出了偏差。 <h2 id="十二最后想强调的其实是边界感">十二、最后想强调的，其实是边界感</h2> 到这里，<a href="https://github.com/Moosphan/juejin-skill">juejin-skill</a> 已经不再只是一个“帮我把文章发出去”的脚本，而是一条相对完整的内容工作流：查分类、查标签、读 Markdown、上传图片、创建草稿、更新文章、下载归档，都被串进了同一套工具里。 我比较喜欢它现在的边界。重复操作交给工具，关键决策仍然留给作者。分类可以推荐，图片可以自动上传，草稿可以自动创建；但要不要公开发布、要不要覆盖线上内容，依然需要明确确认。 如果你也习惯在本地写 Markdown，又经常把文章同步到掘金，不妨试试这个 Skill：<a href="https://github.com/Moosphan/juejin-skill">Moosphan/juejin-skill</a>。它未必是最复杂的工具，但我希望它足够克制、足够稳定，也足够接近真实写作者每天会用到的那条路径。

2026/6/3

Jekyll 博客自动化发文实践：一个可维护的 blog-post skill 是如何落地的

为个人博客补一套自动化发文能力，看似只是“少敲几次 front matter”，真正落地时却会迅速演变成一个工程问题：如何适配现有博客结构、如何控制发布风险、如何让脚本保持确定性、又如何让不同 AI 编程环境复用同一套能力。本文就围绕这几个问题，复盘 <code class="language-plaintext highlighter-rouge">blog-post skill</code> 的完整实现过程。  这次实现的目标其实很明确：在当前 Jekyll 博客仓库中，新增一个可以被 <code class="language-plaintext highlighter-rouge">Codex</code> 和 <code class="language-plaintext highlighter-rouge">Claude Code</code> 共用的发文 skill，让它支持创建文章、切换公开状态、补齐 front matter、按需执行 <code class="language-plaintext highlighter-rouge">git add / commit / push</code>，并尽可能贴合现有博客的目录结构与写作习惯。 <h2 id="1-为什么不是继续手写文章模板">1. 为什么不是继续手写文章模板</h2> 如果只是偶尔写一篇文章，直接复制旧文章的头部并不算昂贵。但一旦要把“创建文章”和“发布文章”变成一条可重复执行的工作流，手工方式的几个问题会立刻暴露出来： <ul> <li>front matter 容易漏字段，例如 <code class="language-plaintext highlighter-rouge">published</code>、<code class="language-plaintext highlighter-rouge">tags</code>、<code class="language-plaintext highlighter-rouge">categories</code></li> <li>文件路径不稳定，尤其是多主题目录下容易放错位置</li> <li><code class="language-plaintext highlighter-rouge">date</code>、标题、slug 和最终访问链接之间需要保持一致</li> <li>不同 Agent 环境需要反复解释“这篇文章应该怎么建”</li> </ul> 更关键的一点是，这个博客仓库本身并不是一个全新的 Jekyll 默认模板，而是已经演化出自己的内容结构。文章实际并不都放在 <code class="language-plaintext highlighter-rouge">_posts/</code> 根目录，而是分散在： <ul> <li><code class="language-plaintext highlighter-rouge">_posts/post_android</code></li> <li><code class="language-plaintext highlighter-rouge">_posts/post_skills</code></li> <li><code class="language-plaintext highlighter-rouge">_posts/post_gradle</code></li> <li><code class="language-plaintext highlighter-rouge">_posts/post_other</code></li> </ul> 这意味着自动化方案不能只会“生成一篇 markdown”，还必须理解这个仓库自己的组织方式。 <h2 id="2-先分析仓库再决定-skill-的边界">2. 先分析仓库，再决定 skill 的边界</h2> 在开始写脚本之前，第一步不是设计命令，而是先确认博客本身的实现约定。 当前仓库有几个关键事实： <ul> <li>导航栏通过 <code class="language-plaintext highlighter-rouge">_includes/nav.html</code> 自动枚举 <code class="language-plaintext highlighter-rouge">site.pages</code></li> <li>文章页面主要依赖 <code class="language-plaintext highlighter-rouge">title</code>、<code class="language-plaintext highlighter-rouge">date</code>、<code class="language-plaintext highlighter-rouge">tags</code>、<code class="language-plaintext highlighter-rouge">description</code>、<code class="language-plaintext highlighter-rouge">published</code></li> <li>SEO 描述层默认会读取 <code class="language-plaintext highlighter-rouge">excerpt</code> 或 <code class="language-plaintext highlighter-rouge">description</code></li> <li><code class="language-plaintext highlighter-rouge">Rakefile</code> 中虽然有 <code class="language-plaintext highlighter-rouge">rake post</code>，但它只会把文章生成到 <code class="language-plaintext highlighter-rouge">_posts/</code> 根目录</li> </ul> 这意味着现成脚本并不能直接满足需要。尤其是 <code class="language-plaintext highlighter-rouge">rake post</code> 这一类脚手架，只解决了“建文件”问题，却没有解决“建在正确的位置”“带上正确的元数据”“兼容现有工作流”这些更关键的问题。 于是这个 skill 的目标被进一步收敛为两层： <ul> <li>上层 skill：负责理解用户意图，整理出参数</li> <li>下层 CLI：负责用确定性的方式修改仓库</li> </ul> 这个职责划分后来被证明是整个实现里最重要的一次收敛。 <h2 id="3-一个关键转折脚本不该直接吃自然语言">3. 一个关键转折：脚本不该直接吃自然语言</h2> 最开始的直觉方案，其实很容易走向另一条路：直接让脚本接收整段自然语言，例如“创建一篇 Android 文章，标题是什么，发布时间是什么，是否公开”，然后在 CLI 内部用正则把这些信息抠出来。 这条路短期看起来很方便，但问题也非常明显。 <h3 id="31-不确定性太高">3.1 不确定性太高</h3> 自然语言解析一旦放进脚本层，CLI 就会同时承担两类职责： <ul> <li>语义理解</li> <li>文件落盘</li> </ul> 前者天然是不稳定的，后者却必须是稳定的。把两件事情放在一起，最终会让一个原本应该确定可测试的工具，变成带着隐式猜测的执行器。 <h3 id="32-不利于测试">3.2 不利于测试</h3> 如果 CLI 接收的是结构化参数，那么测试只需要验证： <ul> <li>输入某组参数，会落在哪个目录</li> <li>front matter 是否正确</li> <li><code class="language-plaintext highlighter-rouge">published</code> 切换是否符合预期</li> </ul> 但如果 CLI 先要解析自然语言，测试就会被迫跟着验证一堆语言变体。这对工具层来说，并不是一个值得承担的复杂度。 <h3 id="33-不利于多环境复用">3.3 不利于多环境复用</h3> <code class="language-plaintext highlighter-rouge">Codex</code> 和 <code class="language-plaintext highlighter-rouge">Claude Code</code> 都具备很强的自然语言理解能力，真正缺的并不是“会不会解析一句话”，而是“有没有一条可以稳定调用的仓库命令”。既然如此，更合理的方式就是让 Agent 负责理解，脚本负责执行。 所以最终的实现明确改成： <ul> <li><code class="language-plaintext highlighter-rouge">Codex</code> / <code class="language-plaintext highlighter-rouge">Claude Code</code> 把自然语言转换为结构化参数</li> <li><code class="language-plaintext highlighter-rouge">blog-post-skill.js</code> 只接受明确命令与 flags</li> </ul> 这也是为什么现在的 CLI 会采用如下形式： <div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 </pre></td><td class="rouge-code"><pre>node ./tools/blog-post-skill/bin/blog-post-skill.js create \ --title "Activity 启动过程" \ --section android \ --date "2026-05-24 09:30" \ --published false \ --tags "Android,源码分析" </pre></td></tr></tbody></table></code></pre></div></div> 这类接口虽然看起来没有“整段自然语言”那么花哨，但它的可测试性和可维护性要高得多。 <h2 id="4-结构化-cli-是如何设计的">4. 结构化 CLI 是如何设计的</h2> 这套工具最后被收敛为三个明确命令： <ul> <li><code class="language-plaintext highlighter-rouge">sections</code></li> <li><code class="language-plaintext highlighter-rouge">create</code></li> <li><code class="language-plaintext highlighter-rouge">publish</code></li> </ul> <h3 id="41-sections">4.1 <code class="language-plaintext highlighter-rouge">sections</code></h3> <code class="language-plaintext highlighter-rouge">sections</code> 的作用是列出当前博客仓库支持的文章分区，例如： <ul> <li><code class="language-plaintext highlighter-rouge">android</code></li> <li><code class="language-plaintext highlighter-rouge">skills</code></li> <li><code class="language-plaintext highlighter-rouge">gradle</code></li> <li><code class="language-plaintext highlighter-rouge">other</code></li> </ul> 它对应的意义并不只是“打印一个列表”，而是把仓库内部的目录映射显式暴露出来，让上层 Agent 不必硬编码这些知识。 <h3 id="42-create">4.2 <code class="language-plaintext highlighter-rouge">create</code></h3> <code class="language-plaintext highlighter-rouge">create</code> 负责： <ul> <li>解析显式参数</li> <li>根据 <code class="language-plaintext highlighter-rouge">section</code> 找到目标目录</li> <li>生成 front matter</li> <li>根据标题生成 slug</li> <li>组合正文模板或导入外部 markdown</li> </ul> 例如 <code class="language-plaintext highlighter-rouge">android</code> 会映射到 <code class="language-plaintext highlighter-rouge">_posts/post_android</code>，<code class="language-plaintext highlighter-rouge">skills</code> 会映射到 <code class="language-plaintext highlighter-rouge">_posts/post_skills</code>。这一层逻辑被固化在脚本内部的 <code class="language-plaintext highlighter-rouge">SECTION_CONFIG</code> 里，避免每次创建文章时重新判断路径规则。 <h3 id="43-publish">4.3 <code class="language-plaintext highlighter-rouge">publish</code></h3> <code class="language-plaintext highlighter-rouge">publish</code> 的职责相对更偏向“已有文件修改”： <ul> <li>切换 <code class="language-plaintext highlighter-rouge">published: true/false</code></li> <li>更新 <code class="language-plaintext highlighter-rouge">date</code></li> <li>更新 <code class="language-plaintext highlighter-rouge">tags</code>、<code class="language-plaintext highlighter-rouge">description</code></li> <li>可选执行 <code class="language-plaintext highlighter-rouge">git add / commit / push</code></li> </ul> 这让“创建文章”和“发布文章”不再混在一起。换句话说，创建是一次性落盘动作，而发布则是一次状态切换动作。 这种拆分对于博客工作流非常重要，因为许多文章并不是写完立刻发布，而是会在草稿态停留一段时间。 <h2 id="5-front-matter-生成为什么要贴合现有博客">5. front matter 生成为什么要贴合现有博客</h2> 自动化发文脚本如果只会生成 Jekyll 最小头部，实际价值并不大。真正有用的是：它生成的文章必须天然符合当前博客自己的渲染约定。 因此这套 skill 在 front matter 设计上做了几件事。 <h3 id="51-固定页面布局约定">5.1 固定页面布局约定</h3> 默认写入： <div class="language-yaml highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 </pre></td><td class="rouge-code"><pre>layout: post header-style: text catalog: false </pre></td></tr></tbody></table></code></pre></div></div> 这与现有文章的大多数配置保持一致，避免新文章渲染风格突然漂移。 <h3 id="52-自动补-description">5.2 自动补 <code class="language-plaintext highlighter-rouge">description</code></h3> 博客文章页本身会利用 <code class="language-plaintext highlighter-rouge">description</code> 和 <code class="language-plaintext highlighter-rouge">excerpt</code> 做头部描述与 SEO 文本，因此脚本在用户未显式传入摘要时，会基于： <ul> <li>标题</li> <li>subtitle</li> <li>tags</li> <li>section</li> </ul> 自动生成一条短描述。它未必是最终最优文本，但足以保证生成出来的文章不是一份“只有标题没有描述”的半成品。 <h3 id="53-默认加入-excerpt_separator">5.3 默认加入 <code class="language-plaintext highlighter-rouge">excerpt_separator</code></h3> 脚本会默认写入： <div class="language-yaml highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 </pre></td><td class="rouge-code"><pre>excerpt_separator: "" </pre></td></tr></tbody></table></code></pre></div></div> 这样做的目的，是把首页摘要和正文主体的边界提前规范化，而不是把摘要逻辑留给每一篇文章临时发挥。 <h2 id="6-为什么还要补正文骨架模板">6. 为什么还要补正文骨架模板</h2> 很多发文工具会停在 front matter 层，但这个 skill 又向前多走了一步：当用户没有提供完整正文时，脚本会根据 <code class="language-plaintext highlighter-rouge">template</code> 生成一个最小可写的骨架。 目前支持的模板包括： <ul> <li><code class="language-plaintext highlighter-rouge">default</code></li> <li><code class="language-plaintext highlighter-rouge">tutorial</code></li> <li><code class="language-plaintext highlighter-rouge">note</code></li> <li><code class="language-plaintext highlighter-rouge">review</code></li> </ul> 例如 <code class="language-plaintext highlighter-rouge">tutorial</code> 会生成如下结构： <div class="language-markdown highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 </pre></td><td class="rouge-code"><pre>## 问题背景 ## 环境说明 ## 核心步骤 ## 关键细节 ## 总结 </pre></td></tr></tbody></table></code></pre></div></div> 这里的关键并不是“自动生成了几级标题”，而是让不同类型的文章在开稿阶段就拥有稳定结构。对于持续写作来说，这种结构化约束往往比单纯少敲几行 YAML 更有价值。 <h2 id="7-如何同时适配-codex-与-claude-code">7. 如何同时适配 Codex 与 Claude Code</h2> 实现共享能力的核心思路，是让仓库只维护一套真正可执行的能力，把环境差异压缩到外围包装层。 所以整个目录被拆成了三部分： <ul> <li><code class="language-plaintext highlighter-rouge">tools/blog-post-skill/</code></li> <li><code class="language-plaintext highlighter-rouge">.codex/skills/blog-post-publisher/</code></li> <li><code class="language-plaintext highlighter-rouge">.claude/commands/blog-post.md</code></li> </ul> 其中： <ul> <li><code class="language-plaintext highlighter-rouge">tools/blog-post-skill/</code> 是共享运行时</li> <li><code class="language-plaintext highlighter-rouge">SKILL.md</code> 负责告诉 Codex 什么时候该使用这套能力</li> <li><code class="language-plaintext highlighter-rouge">.claude/commands/blog-post.md</code> 负责告诉 Claude Code 该如何组装命令</li> </ul> 这个设计的好处是，真正决定仓库状态的逻辑永远只有一份。上层环境无论是 Codex 还是 Claude Code，都不需要各自再维护一套文件写入实现。 <h2 id="8-一个额外踩坑为什么工具-readme-会出现在导航栏里">8. 一个额外踩坑：为什么工具 README 会出现在导航栏里</h2> skill 本身落地之后，又暴露出一个很典型的 Jekyll 仓库问题：只要某个目录没有被正确排除，它就可能被当作站点内容的一部分。 这个博客的导航栏会自动枚举 <code class="language-plaintext highlighter-rouge">site.pages</code>。而 <code class="language-plaintext highlighter-rouge">tools/blog-post-skill/README.md</code> 作为仓库里的说明文档，如果不被排除出构建范围，就有机会进入站点页面集合，进而在导航栏中冒出一个不该出现的入口。 解决方式很直接：把 <code class="language-plaintext highlighter-rouge">tools</code> 以及相关工具目录加入 <code class="language-plaintext highlighter-rouge">_config.yml</code> 的 <code class="language-plaintext highlighter-rouge">exclude</code>。 这类问题很容易被忽视，因为它不属于“发文脚本是否能运行”的范畴，却直接影响最终站点表现。也正因为如此，发文自动化不应该被理解为一段孤立脚本，而应该被视为站点工程的一部分。 <h2 id="9-这套实现真正解决了什么">9. 这套实现真正解决了什么</h2> 到这里再回头看，这个 skill 真正解决的并不是“创建文章文件很麻烦”这么简单的问题，而是把博客发文流程中的几个关键环节结构化了： <ul> <li>文章目录归类</li> <li>front matter 规范化</li> <li>草稿与公开状态切换</li> <li>AI 编程环境复用</li> <li>Git 提交与推送串联</li> </ul> 更重要的是，它明确了一个适用于很多仓库自动化场景的原则： <blockquote> 语义理解交给 Agent，确定性执行交给脚本。 </blockquote> 一旦这条边界稳定下来，后续无论是继续接图片处理、封面生成、文章校验还是发布检查，都可以沿着同一条结构继续扩展，而不需要反复推翻底层设计。 <h2 id="10-后续可以继续演进的方向">10. 后续可以继续演进的方向</h2> 目前这套 <code class="language-plaintext highlighter-rouge">blog-post skill</code> 已经足够覆盖个人博客的日常发文流程，但它仍然有不少可以继续扩展的空间： <ul> <li>在创建文章前自动校验标签与分类是否符合既有约定</li> <li>增加图片资源目录的自动创建与引用修正</li> <li>在发布前执行本地预览或构建检查</li> <li>将文章元数据进一步抽象为可复用 schema</li> </ul> 如果把它放到更大的团队环境里，这套能力甚至可以继续演化成一个“内容仓库操作层”：前端页面、博客文章、知识库文档、发布说明，统一都通过结构化命令落库。 对个人博客来说，这一步或许还谈不上“平台化”，但它至少证明了一件事：只要先把职责边界拉清，自动化往往比想象中更容易做对，也更容易持续迭代。

2026/5/24

Android 手写渲染技术演进：前缓冲、Ink API 与 Compose 高级触控笔能力

在 Android 手写、批注与白板类应用中，决定体验上限的通常不是单一的绘制 API，而是整条输入与渲染链路的协同效率。过去，开发者往往需要自行处理 <code class="language-plaintext highlighter-rouge">MotionEvent</code> 采样、预测点插值、压感映射、误触回滚以及低延迟渲染。近两年，Google 逐步将这套能力沉淀为可复用的官方组件：底层由 <code class="language-plaintext highlighter-rouge">androidx.graphics:graphics-core</code> 提供低延迟渲染基础设施，上层由 <code class="language-plaintext highlighter-rouge">androidx.ink:ink-*</code> 提供笔迹建模、笔刷系统与几何操作能力；同时，Jetpack Compose 文档也补充了高级触控笔输入的工程化处理方式。 本文基于截至 <code class="language-plaintext highlighter-rouge">2026-05-24</code> 的官方资料，对 Android 手写技术栈的最新状态进行梳理，并讨论前缓冲、Ink API 与 Compose 高级触控笔能力在实际项目中的组合方式。 <img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjr-fQK660FgiUsJF64wNgAAxkWgA-Ul68stuzOKasoAIpQddUhACLL1nEmwSu7oRJriJh_B1vlKftd2VfQ2kDAnDNQNhQ8SGd0y6-U5Zatg9xAKe0EFW7Q13YtB1owvG2vMbC72XsBzsJOhBrGegpCnn4PEEfyFksSkSdAqDviGhDbtm_SyH89Uy4QmQo/s1600/v2-header-Android-type-safe-navigation-for-compose.png" alt="Ink API 官方封面图" /> 图源：Google Android Developers Blog，Ink API 官方文章 <h2 id="1-官方技术栈的最新状态">1. 官方技术栈的最新状态</h2> 截至 <code class="language-plaintext highlighter-rouge">2026-05-24</code>，与 Android 手写能力直接相关的官方组件处于以下状态： <ul> <li><code class="language-plaintext highlighter-rouge">androidx.graphics:graphics-core:1.0.0</code> 稳定版发布于 <code class="language-plaintext highlighter-rouge">2024-05-29</code></li> <li><code class="language-plaintext highlighter-rouge">androidx.graphics:graphics-core:1.0.4</code> 发布于 <code class="language-plaintext highlighter-rouge">2025-12-03</code></li> <li><code class="language-plaintext highlighter-rouge">androidx.ink:ink-*:1.0.0</code> 稳定版发布于 <code class="language-plaintext highlighter-rouge">2025-12-17</code></li> <li><code class="language-plaintext highlighter-rouge">androidx.ink:ink-*:1.1.0-alpha03</code> 发布于 <code class="language-plaintext highlighter-rouge">2026-05-19</code></li> <li>Compose 文档《高级触控笔功能》最后更新时间为 <code class="language-plaintext highlighter-rouge">2026-05-23</code></li> </ul> 这组时间线说明两点。 其一，低延迟渲染不再只是依赖内部实现细节的试验性方案，而已经演化为稳定的 AndroidX 能力。其二，笔迹生成、笔刷配置、输入序列化、几何运算与在途笔迹渲染，已经形成了较完整的上层抽象。这意味着当前 Android 手写应用的技术重点，正在从“如何从零实现一套书写系统”转移到“如何基于官方组件搭建更稳定的工程架构”。 <h2 id="2-前缓冲的技术意义">2. 前缓冲的技术意义</h2> 手写场景与普通界面渲染的主要差异在于延迟容忍度极低。列表、卡片或页面切换通常可以接受几十毫秒级的视觉延迟，但在书写过程中，用户会直接感知笔尖与墨迹之间的空间偏移。所谓“跟手性”，本质上是输入到显示的端到端延迟是否足够小。 前缓冲（front-buffered rendering）的价值正在于此。与只依赖双缓冲或多缓冲的完整帧提交流程相比，前缓冲允许当前正在变化的局部内容更早进入显示链路，从而缩短笔迹首次可见的时间。这种优化并不直接提高最终画质，但可以显著改善书写阶段的主观响应速度。 Google 在 <code class="language-plaintext highlighter-rouge">graphics-core</code> 中围绕低延迟渲染提供了几类关键能力： <ul> <li><code class="language-plaintext highlighter-rouge">GLFrontBufferedRenderer</code></li> <li><code class="language-plaintext highlighter-rouge">CanvasFrontBufferedRenderer</code></li> <li><code class="language-plaintext highlighter-rouge">LowLatencyCanvasView</code></li> <li><code class="language-plaintext highlighter-rouge">CanvasBufferedRenderer</code></li> </ul> 其中，<code class="language-plaintext highlighter-rouge">CanvasFrontBufferedRenderer</code> 与 <code class="language-plaintext highlighter-rouge">LowLatencyCanvasView</code> 使基于 <code class="language-plaintext highlighter-rouge">Canvas</code> 的低延迟渲染路径更加直接，适合触控笔输入类场景；<code class="language-plaintext highlighter-rouge">GLFrontBufferedRenderer</code> 则更适合已有 OpenGL 渲染栈的应用。 从 release notes 可以看到，这套能力的成熟过程高度依赖设备适配与系统兼容修复： <ul> <li><code class="language-plaintext highlighter-rouge">graphics-core:1.0.2</code> 修复了部分 Android 14+ 设备在不支持 front buffer usage flag 时的闪烁问题</li> <li><code class="language-plaintext highlighter-rouge">graphics-core:1.0.3</code> 修复了部分 <code class="language-plaintext highlighter-rouge">API < 33</code> 设备上的全屏闪烁</li> <li><code class="language-plaintext highlighter-rouge">graphics-core:1.0.4</code> 继续改进了特定设备上的兼容性与性能</li> </ul> 这类修复说明，前缓冲的价值已经得到验证，但它依然是接近平台层的能力。对于大多数业务团队而言，直接从 <code class="language-plaintext highlighter-rouge">graphics-core</code> 最底层开始搭建书写系统，意味着需要自己承担更多的设备差异、资源释放与回退逻辑。因此，更常见也更稳妥的做法，是优先站在 Ink API 这一层向下借力。 <h2 id="3-ink-api-的定位从笔迹绘制到书写系统">3. Ink API 的定位：从笔迹绘制到书写系统</h2> 如果只将 Ink API 理解为“官方画笔库”，会低估它的工程价值。更准确的说法是：Ink API 试图为 Android 提供一套结构化的手写系统抽象。 官方将其拆分为多个模块： <ul> <li><code class="language-plaintext highlighter-rouge">Authoring</code>：处理输入接收、在途笔迹管理与交互状态</li> <li><code class="language-plaintext highlighter-rouge">Rendering</code>：负责实时笔迹与完成态笔迹的绘制</li> <li><code class="language-plaintext highlighter-rouge">Strokes</code>：定义笔迹数据模型</li> <li><code class="language-plaintext highlighter-rouge">Brush</code>：定义笔刷的外观、材质与行为</li> <li><code class="language-plaintext highlighter-rouge">Geometry</code>：提供选区、相交、覆盖等几何能力</li> </ul> 这一分层的关键价值，在于将“实时反馈”与“最终结果”从概念上分离。 在手写系统中，用户落笔后的第一诉求是尽快看到墨迹；而笔迹结束之后，系统又必须支持持久化、撤销、回放、重绘、选中与同步。这两类需求关注点不同：前者以延迟最小化为目标，后者以稳定性和可操作性为目标。Google 因而在 Ink API 中明确区分： <ul> <li>使用 <code class="language-plaintext highlighter-rouge">InProgressStrokesView</code> 处理在途笔迹</li> <li>使用 <code class="language-plaintext highlighter-rouge">CanvasStrokeRenderer</code> 或 <code class="language-plaintext highlighter-rouge">ViewStrokeRenderer</code> 处理完成态笔迹</li> </ul> 这种分层并不是实现细节，而是一种值得直接采纳的架构原则：在书写进行时优先追求显示时延，在笔迹结束后再转入质量与结构化表示优先的渲染路径。 <img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiE_VC7aiMgrPRq-rBG-c1LdauGYqi2U8alx80PoxZI4G9kNoURFNHh6RM21KO5SQL8RGRNDxIn_KuYjqA2sFXy_KWjorI1w16wN8HWaXEus2JlEjRtTWfInJGyJb9LpexvxzneqsVL2_Uw214MHlUhi4R7nw1O6QsiJyMEZ4N3hQ-nGQw5PzsNBk6kQe0/w640-h468/image5.gif" alt="Ink API 低延迟书写演示 1" /> 图源：Google Android Developers Blog，Samsung Tab S8 上基于 Ink API 的低延迟书写演示 <img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiNLDZmNs7BwcQsuCn4orht8-OGhsaW4xLs-SEiGOsmu5UdPhBfs787uUFsX9zc25Fd2OEjootN6_U_FhifgLW_3855RdPWlFBZ2kKMLX0pV-ZaR5HrzZt2EevpaQghcnJbDhScQYKke3o3WmBhMvvoyQ9Dt1bqbj6N9vsevjdKa47YzhJqBv_vQQt06u8/s1600/image6.gif" alt="Ink API 低延迟书写演示 2" /> 图源：Google Android Developers Blog，Ink API 官方演示动图 <h2 id="4-笔刷能力的近期演进">4. 笔刷能力的近期演进</h2> 截至 <code class="language-plaintext highlighter-rouge">2026-05-24</code>，Ink API 在笔刷能力上的演进，主要集中在三个方向。 <h3 id="41-从预置笔刷走向可编程笔刷">4.1 从预置笔刷走向可编程笔刷</h3> <code class="language-plaintext highlighter-rouge">1.0.0-alpha04</code> 于 <code class="language-plaintext highlighter-rouge">2025-04-09</code> 引入实验性的自定义 <code class="language-plaintext highlighter-rouge">BrushFamily</code> 能力，官方明确提到可支持类似 <code class="language-plaintext highlighter-rouge">Pencil</code>、<code class="language-plaintext highlighter-rouge">Laser Pointer</code> 的新笔刷。到 <code class="language-plaintext highlighter-rouge">1.1.0-alpha03</code>，程序化自定义笔刷 API 进一步公开为 public。 这一变化的意义在于，笔刷系统开始从“参数调节型配置”转向“可编排的笔刷模型”。对于笔记、教育、批注、设计和创作类产品，这意味着笔刷不再只是颜色与线宽的组合，而可以逐渐成为产品差异化的一部分。 <h3 id="42-笔刷配置的可序列化与版本兼容">4.2 笔刷配置的可序列化与版本兼容</h3> <code class="language-plaintext highlighter-rouge">1.1.0-alpha02</code> 对 <code class="language-plaintext highlighter-rouge">BrushFamily.decode</code> 的兼容性控制进行了增强，同时将 <code class="language-plaintext highlighter-rouge">BrushFamily</code> 的序列化 API 从 experimental 状态提升出来。 这类更新对于线上产品尤其重要。笔刷系统一旦参与文档存储、跨端同步或长期版本演进，就必须回答三个问题： <ul> <li>历史数据是否可以被新版本正确解析</li> <li>多设备间是否能得到一致的笔刷表现</li> <li>笔刷协议是否支持平滑迁移</li> </ul> 序列化与兼容性 API 的完善，意味着 Ink API 正在从“本地渲染工具”向“可持久化的文档能力”演进。 <h3 id="43-输入建模与数值稳定性">4.3 输入建模与数值稳定性</h3> 从 <code class="language-plaintext highlighter-rouge">1.0.0-alpha07</code> 及后续 beta、stable 版本的变更记录来看，Google 持续在优化以下内容： <ul> <li>stroke input smoothing</li> <li><code class="language-plaintext highlighter-rouge">StrokeInputBatch</code> 序列化</li> <li>浮点精度</li> <li>某些场景下的渲染伪影</li> </ul> 这些更新虽然不如新增笔刷直观，却直接决定笔迹系统的稳定性。手写体验中的“抖动感”“回放变形”“跨设备表现不一致”，往往都与输入建模和数值处理有关，而不仅仅是渲染器本身。 <img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjsX5BcJ2qvBaVRKJXf2T-1hxCl9E_VuSZqUDgJnAMhmUGEiOhaC8XreGD9y_I9nRi-Ibz4IQfrWA0tVHmuCzVRmg3oMiJBpsqr-S5m3UHnMKogPfFf8M6Dk9MJv5qxhOE8H5JGypK0ZGpOyRvOhrnNR-z6H-8t8epx76z1jBI2oDlNP211Z1WSP9glBC0/s1600/v2-card-Android-type-safe-navigation-for-compose.png" alt="Ink API 官方卡片图" /> 图源：Google Android Developers Blog，Ink API 官方文章配图 <h2 id="5-compose-高级触控笔能力的工程意义">5. Compose 高级触控笔能力的工程意义</h2> Google 在 Compose 文档《高级触控笔功能》中给出的一个重要信号是：即便应用的 UI 主体采用 Compose，实现高质量手写能力时仍然需要回到 <code class="language-plaintext highlighter-rouge">MotionEvent</code> 级别获取完整输入信息。官方示例使用 <code class="language-plaintext highlighter-rouge">pointerInteropFilter</code> 作为桥接入口： <div class="language-kotlin highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 </pre></td><td class="rouge-code"><pre>@Composable @OptIn(ExperimentalComposeUiApi::class) fun DrawArea(modifier: Modifier = Modifier) { Canvas( modifier = modifier .clipToBounds() .pointerInteropFilter { viewModel.processMotionEvent(it) } ) { // Drawing code here. } } </pre></td></tr></tbody></table></code></pre></div></div> 这一写法的意义不在于“Compose 也能处理触控笔”，而在于它明确了职责划分：Compose 适合承担界面组织与交互壳层，而笔输入细节仍然应由 <code class="language-plaintext highlighter-rouge">MotionEvent</code> 驱动的专门逻辑处理。对多数项目而言，这意味着更合理的结构通常是“Compose UI + MotionEvent 互操作 + 独立的笔迹层”。 <h2 id="6-高级触控笔特性与笔刷设计">6. 高级触控笔特性与笔刷设计</h2> Compose 文档中最值得纳入手写系统设计的，不是单一 API，而是一组输入能力及其工程含义。 <h3 id="61-工具类型识别">6.1 工具类型识别</h3> 官方建议通过 <code class="language-plaintext highlighter-rouge">getToolType(pointerIndex)</code> 区分输入工具，例如： <ul> <li><code class="language-plaintext highlighter-rouge">TOOL_TYPE_STYLUS</code></li> <li><code class="language-plaintext highlighter-rouge">TOOL_TYPE_ERASER</code></li> </ul> 这使系统能够在同一交互链路中区分书写与擦除，而无需依赖额外的模式切换。对于笔记和批注类应用，这种“翻转触控笔即可擦除”的行为接近原生书写习惯，应优先纳入设计。 <h3 id="62-压力方向倾斜与距离">6.2 压力、方向、倾斜与距离</h3> 高级触控笔输入的核心价值，在于提供比二维坐标更丰富的轴数据。官方文档重点涉及： <ul> <li><code class="language-plaintext highlighter-rouge">AXIS_PRESSURE</code></li> <li><code class="language-plaintext highlighter-rouge">AXIS_ORIENTATION</code></li> <li><code class="language-plaintext highlighter-rouge">AXIS_TILT</code></li> <li><code class="language-plaintext highlighter-rouge">AXIS_DISTANCE</code></li> </ul> 这些轴数据应直接参与笔刷建模，而不应仅用于简单线宽映射。较合理的使用方式包括： <ul> <li>使用 <code class="language-plaintext highlighter-rouge">AXIS_PRESSURE</code> 调整粗细、透明度或墨量感</li> <li>使用 <code class="language-plaintext highlighter-rouge">AXIS_ORIENTATION</code> 构建扁头笔、马克笔或书法笔的方向性</li> <li>使用 <code class="language-plaintext highlighter-rouge">AXIS_TILT</code> 实现铅笔侧锋、阴影与扫刷效果</li> <li>使用 <code class="language-plaintext highlighter-rouge">AXIS_DISTANCE</code> 支持悬停预览或落笔前的目标提示</li> </ul> 官方同时提醒，压力值虽然通常位于 <code class="language-plaintext highlighter-rouge">0..1</code> 区间，但部分设备可能返回更高数值。因此，在进入笔刷计算前，应先做归一化与边界处理，避免不同硬件上的表现漂移。 <h3 id="63-悬停反馈">6.3 悬停反馈</h3> 悬停（hover）在手机场景中未必显著，但在平板、折叠屏与 ChromeOS 设备上具有明确价值。其作用不在于“多一个特效”，而在于提升输入前的可预期性。例如： <ul> <li>显示当前笔刷的实际落笔范围</li> <li>高亮即将操作的对象或区域</li> <li>在复杂工具栏或文档页面中给出更细粒度的定位提示</li> </ul> 在 Compose 中，文档建议配合 <code class="language-plaintext highlighter-rouge">hoverable</code> 与 <code class="language-plaintext highlighter-rouge">indication</code> 使用。这类反馈虽然不改变笔迹本身，却能够显著提高交互确定性。 <h2 id="7-误触取消与输入回滚">7. 误触、取消与输入回滚</h2> 高质量手写系统必须将误触处理视为数据一致性问题，而不仅仅是事件过滤问题。官方文档明确指出，手掌误触相关处理涉及： <ul> <li><code class="language-plaintext highlighter-rouge">ACTION_CANCEL</code></li> <li><code class="language-plaintext highlighter-rouge">FLAG_CANCELED</code></li> </ul> 其中，<code class="language-plaintext highlighter-rouge">ACTION_CANCEL</code> 可能在导航手势或防手掌误触触发时出现；<code class="language-plaintext highlighter-rouge">FLAG_CANCELED</code> 自 Android 13（API 33）起可用于标识一次抬起事件很可能源于非预期接触。 正确的处理方式不是简单忽略后续输入，而是支持对已有笔迹进行回滚。具体而言，系统应保留结构化输入历史，在检测到取消语义后定位对应 pointer 所生成的笔迹，并将其从当前状态中移除，再触发重新渲染。只有采用结构化 stroke 数据而非一次性 Path 累积，误触撤销才具备可实现性。 这一点也解释了为什么 Ink API 对 <code class="language-plaintext highlighter-rouge">StrokeInputBatch</code>、几何模型和在途/完成态分层如此重视：它们并非仅服务于渲染，而是服务于后续的状态修正与编辑操作。 <h2 id="8-动作预测与低延迟输入分发">8. 动作预测与低延迟输入分发</h2> Compose 文档推荐使用 <code class="language-plaintext highlighter-rouge">androidx.input:input-motionprediction:1.0.0-beta01</code> 中的 <code class="language-plaintext highlighter-rouge">MotionEventPredictor</code> 进行动作预测。其基本思路是： <ol> <li>对真实 <code class="language-plaintext highlighter-rouge">MotionEvent</code> 调用 <code class="language-plaintext highlighter-rouge">record()</code></li> <li>在 <code class="language-plaintext highlighter-rouge">ACTION_MOVE</code> 阶段调用 <code class="language-plaintext highlighter-rouge">predict()</code></li> <li>将预测点仅作为临时可视化结果参与绘制</li> </ol> 官方同时明确指出，预测点不能作为最终渲染与持久化数据使用。原因在于预测本质上是估算值，随着真实事件到来，旧预测必须被替换。也就是说，预测机制适合改善主观跟手性，但不应污染最终的笔迹数据模型。 与动作预测配套的另一项能力，是 <code class="language-plaintext highlighter-rouge">requestUnbufferedDispatch()</code>。它的作用不是直接提高渲染性能，而是缩短输入在系统队列中被批量缓存的时间。对于手写系统而言，端到端延迟并不只由绘制决定；如果输入事件本身到达应用过晚，再快的前缓冲路径也只能更快地显示“已经过时的输入”。因此，更完整的低延迟链路应同时包含： <ul> <li>低延迟输入分发</li> <li>在途笔迹的快速显示</li> <li>完成态笔迹的稳定提交</li> </ul> <h2 id="9-推荐的工程组合方式">9. 推荐的工程组合方式</h2> 综合 <code class="language-plaintext highlighter-rouge">graphics-core</code>、Ink API 与 Compose 文档中的能力，可以得到一套较稳健的工程分层。 <h3 id="91-界面层">9.1 界面层</h3> 使用 Compose 构建页面结构、工具栏、颜色与笔刷选择器、文档容器以及悬停反馈。这一层的目标是组织交互，而不是承担全部输入解析逻辑。 <h3 id="92-输入层">9.2 输入层</h3> 通过 <code class="language-plaintext highlighter-rouge">pointerInteropFilter</code> 接入 <code class="language-plaintext highlighter-rouge">MotionEvent</code>，完成以下工作： <ul> <li>区分 <code class="language-plaintext highlighter-rouge">TOOL_TYPE_STYLUS</code> 与 <code class="language-plaintext highlighter-rouge">TOOL_TYPE_ERASER</code></li> <li>读取压力、方向、倾斜、距离等轴数据</li> <li>处理 <code class="language-plaintext highlighter-rouge">ACTION_DOWN / MOVE / UP / CANCEL</code></li> <li>根据需要接入 <code class="language-plaintext highlighter-rouge">MotionEventPredictor</code></li> <li>在落笔阶段调用 <code class="language-plaintext highlighter-rouge">requestUnbufferedDispatch()</code></li> </ul> <h3 id="93-笔迹层">9.3 笔迹层</h3> 使用 Ink API 承接实时与完成态笔迹： <ul> <li><code class="language-plaintext highlighter-rouge">InProgressStrokesView</code> 用于在途笔迹显示</li> <li><code class="language-plaintext highlighter-rouge">CanvasStrokeRenderer</code> 或 <code class="language-plaintext highlighter-rouge">ViewStrokeRenderer</code> 用于完成态绘制</li> <li><code class="language-plaintext highlighter-rouge">BrushFamily</code> 用于笔刷建模</li> <li><code class="language-plaintext highlighter-rouge">StrokeInputBatch</code> 用于输入数据存储、回放与同步</li> </ul> <h3 id="94-渲染优化层">9.4 渲染优化层</h3> 仅在确有必要时继续下沉到 <code class="language-plaintext highlighter-rouge">graphics-core</code> 层，针对设备性能、显示时延或现有渲染栈进行深度优化，例如： <ul> <li><code class="language-plaintext highlighter-rouge">CanvasFrontBufferedRenderer</code></li> <li><code class="language-plaintext highlighter-rouge">LowLatencyCanvasView</code></li> <li><code class="language-plaintext highlighter-rouge">GLFrontBufferedRenderer</code></li> </ul> 这种分层的优点在于，既能充分利用官方已验证的上层抽象，又保留了继续向底层优化的空间。 <h2 id="10-结论">10. 结论</h2> Android 手写技术栈当前的变化，不在于单一新 API 的出现，而在于官方能力开始形成清晰的层次结构：<code class="language-plaintext highlighter-rouge">graphics-core</code> 负责低延迟渲染基础设施，Ink API 负责笔迹与笔刷语义，Compose 高级触控笔文档则补足了原始输入处理与工程实践。 从实现角度看，前缓冲解决的是“墨迹何时被尽快看到”，Ink API 解决的是“笔迹如何被建模、绘制、存储与编辑”，而高级触控笔能力解决的是“输入信号如何被完整、准确且可回滚地纳入系统”。只有将这三层能力组合起来，Android 手写应用才能同时获得可接受的时延、稳定的数据模型以及接近原生纸笔的交互质量。 对于当前准备建设书写、批注或圈选能力的团队而言，这套官方技术栈已经具备较高的采用价值。真正需要关注的重点，已经不是是否“应该上官方方案”，而是如何根据业务场景，在实时显示、笔刷表现、状态管理与设备兼容之间完成合理取舍。 <h2 id="参考资料">参考资料</h2> <ul> <li><a href="https://developer.android.com/jetpack/androidx/releases/graphics">AndroidX Graphics Release Notes</a></li> <li><a href="https://developer.android.com/jetpack/androidx/releases/ink">AndroidX Ink Release Notes</a></li> <li><a href="https://developer.android.com/develop/ui/views/touch-and-input/stylus-input/about-ink-api">About Ink API</a></li> <li><a href="https://developer.android.com/develop/ui/views/touch-and-input/stylus-input/low-latency-graphics">Low latency graphics</a></li> <li><a href="https://developer.android.com/develop/ui/views/touch-and-input/stylus-input/ink-api-brush-apis-views">Ink API brush APIs for Views</a></li> <li><a href="https://developer.android.com/develop/ui/views/touch-and-input/stylus-input/ink-api-draw-stroke">Draw a stroke with Ink API</a></li> <li><a href="https://developer.android.com/develop/ui/compose/touch-input/stylus-input/advanced-stylus-features?hl=zh-cn">高级触控笔功能（Jetpack Compose）</a></li> <li><a href="https://android-developers.googleblog.com/2024/10/introducing-ink-api-jetpack-library.html">Introducing Ink API, a new Jetpack library for stylus apps</a></li> </ul>

2026/4/12

Android上的Deep-Link技术调研

<blockquote> 本文是两年前输出的文章，可能与现在的成熟方案存在部分细节上“代沟”，请诸位选择性阅读，适当参考即可。 </blockquote> <h3 id="一需求背景">一、需求背景</h3> 现在有很多 APP 支持从浏览器或其他地方唤起自家应用，并跳转至特定页面去提高用户黏性。在提高运营手段的背景下，应用也需要迫切提高自身的曝光入口以及活动场景。如果用户可以通过点击短信中的一个活动链接能够直接跳转到目标 APP 的特定页面，那么带来的好处也是不言而喻的。 <h3 id="二方案调研">二、方案调研</h3> iOS 系统提供的 universial link 来帮助应用实现这个功能，而至于 Android 可能就比较繁琐了，Android 6.0 之后开始才提供了 <a href="https://developer.android.com/training/app-links/index.html">App Links</a> 来帮助开发者从外部唤起自家应用，但是 6.0 之前一般只能通过 URI Scheme 方式来唤起应用。不同的方案各自都存在对应的兼容性问题，以下是各方案的对比情况： <table> <thead> <tr> <th>技术</th> <th>Universal Link</th> <th>Android App Link</th> <th>URI Scheme</th> <th>Chrome Intent</th> </tr> </thead> <tbody> <tr> <td>平台要求</td> <td>>= iOS 9</td> <td>>= Android 6</td> <td>Chrome 1 < 25, iOS</td> <td>Chrome 1 >= 25</td> </tr> <tr> <td>未安装表现</td> <td>打开 Web 页面</td> <td>打开 Web 页面</td> <td>发生错误</td> <td>可以打开 Web 页面</td> </tr> <tr> <td>能否不发生跳转</td> <td>不能</td> <td>不能</td> <td>能</td> <td>能</td> </tr> <tr> <td>能否去下载页面</td> <td>能</td> <td>能</td> <td>不能</td> <td>能</td> </tr> <tr> <td>iframe 触发</td> <td>不支持</td> <td>不支持</td> <td>Chrome 1 <= 18, iOS < 9</td> <td>不支持</td> </tr> <tr> <td>链接格式 2</td> <td>正常的 URL</td> <td>正常的 URL</td> <td>自定义协议的 URL</td> <td>intent 协议的 URL</td> </tr> </tbody> </table> <ol> <li>本文只针对移动端浏览器，其中 Chrome 表示 Chrome for Android，以及 Android Browser 的对应版本。</li> <li>链接的作用方式有 3 种：用户点击这样的 <code class="language-plaintext highlighter-rouge"><a></code> 标签；脚本中进行页面重定向；设置 <code class="language-plaintext highlighter-rouge">iframe</code> 的 <code class="language-plaintext highlighter-rouge">src</code>。</li> <li>每种实现方式都有其适用的平台和浏览器，要兼容多数浏览器需要根据 User Agent 应用不同的策略。这些实现方式的行为也不一致，可能需要配合产品需求才能确定结合哪几种实现方式。</li> </ol> 下面来看下各方案的具体实现过程。 <h3 id="三uri-scheme-方案">三、URI Scheme 方案</h3> URI Scheme 这种方式比较古老，目前也广泛用于从外部应用打开APP，这种协议由开发者自己定义，有比较丰富的定制性，但唤起时会有一个系统级别弹窗来让用户去选择通过匹配到的 APP 或者浏览器打开。URI 协议格式如下： [scheme]://[host]/[path]?[params] 例如：<code class="language-plaintext highlighter-rouge">http://www.baidu.com/data?page=home&uid=ut9092</code> 上面的 URI 可以在 Android 应用中通过 intent-filter 去识别和处理： <div class="language-xml highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 </pre></td><td class="rouge-code"><pre><intent-filter> <action android:name="android.intent.action.VIEW"/> <category android:name="android.intent.category.DEFAULT"/> <category android:name="android.intent.category.BROWSABLE"/> <data android:host="www.baidu.com" android:pathPattern="data" android:scheme="http"/> </intent-filter> </pre></td></tr></tbody></table></code></pre></div></div> 下面，我们来通过 URI Scheme 来实现一个简单的小 demo，要求能够通过系统的记事本应用中的链接进入到 APP 的目标页面。首先，我们先来约束一下协议格式内容，如下所示： <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 </pre></td><td class="rouge-code"><pre>http://com.example.deeplink?path=demo_page&text=im_from_system_notebook </pre></td></tr></tbody></table></code></pre></div></div> 可以看到，我们定义的 scheme 为 http，而 host 对应的 <code class="language-plaintext highlighter-rouge">com.example.deeplink</code>，这里我设置的是应用的包名，一般不会更改。至于 path 和 text 就很显然是作为参数内容了，这里分别代表着页面路径参数和对应的页面内容参数，方便我们定制不同的页面逻辑，大家可以根据情况制定自己的规则。好的，接下来开始我们的第二步 — 在 demo 项目中额外创建一个页面（EvokeDemoActivity）并添加相应的 intent 匹配逻辑： <div class="language-xml highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 </pre></td><td class="rouge-code"><pre> <activity android:name=".deeplink.EvokeDemoActivity"> <intent-filter> <action android:name="android.intent.action.VIEW"/> <category android:name="android.intent.category.DEFAULT"/> <category android:name="android.intent.category.BROWSABLE"/> <data android:scheme="http" android:host="com.example.deeplink"/> </intent-filter> </activity> </pre></td></tr></tbody></table></code></pre></div></div> 接下来，只需要在目标唤醒页面获取对应的参数内容即可： <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 </pre></td><td class="rouge-code"><pre>/** * Deep link 唤起的目标页面 */ public class EvokeDemoActivity extends AppCompatActivity { public static final String EVOKE_DEMO_PAGE = "demo_page"; private TextView textView; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_evoke_demo); textView = findViewById(R.id.textView); obtainDeepLink(); } private void obtainDeepLink() { Intent intent = getIntent(); if (intent != null && intent.getData() != null && intent.getData().getQueryParameter("path").equals(EVOKE_DEMO_PAGE)) { Log.e("DemoPage", "received deep link intent: " + intent.getData().toString()); String paramContent = intent.getData().getQueryParameter("text"); if (!TextUtils.isEmpty(paramContent)) { textView.setText(paramContent); } } } } </pre></td></tr></tbody></table></code></pre></div></div> 接着运行一下 demo，然后在系统记事本中输入测试链接，如： <code class="language-plaintext highlighter-rouge">[http://com.example.deeplink?path=demo_page&text=im_from_system_notebook](http://com.example.deeplink?path=demo_page&text=im_from_system_notebook)</code> 保存后点击查看，可以看到如下效果： <img src="/img/in-post/post-android/1613976376040-f5705a01-6536-4604-8c49-5839700f823d.png" alt="Kapture 2021-02-22 at 14.45.04.gif" /> 可以发现，我们在记事本里点击链接后弹出了系统弹窗让我们选择打开链接的应用，需要选择我们自己的 APP 来打开（示例这边是 Android samples 应用），然后成功进入了目标 app 的制定页面并拿到了携带的参数内容。 <h3 id="四app-links-方案">四、App links 方案</h3> 与 iOS 中的 universial links 方案类似，Android 在 6.0 推出了 App links，用标准的 Web 页面 URL，同时绑定对应的 App。可以支持从白名单配置中的链接直接唤起 App，而不需要额外弹窗提示，对于用户来说会降低困扰，提升用户体验度。首先，我们需要生成一份配置文件放到服务端，点击 Android studio 的 Tools > App Links Assistant，进入配置页面后第一步点击 Open URL Mapping Editor，添加一个 URL： <img src="/img/in-post/post-android/1613993915191-1ded7dcf-1228-443c-b530-eb6f59eb01fb.png" alt="add_url" /> 然后在 Android manifest 文件中修改一下配置： <div class="language-xml highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 </pre></td><td class="rouge-code"><pre><activity android:name=".deeplink.EvokeDemoActivity"> <intent-filter android:autoVerify="true"> <action android:name="android.intent.action.VIEW"/> <category android:name="android.intent.category.DEFAULT"/> <category android:name="android.intent.category.BROWSABLE"/> <data android:scheme="http" android:host="com.example.deeplink"/> </intent-filter> </activity> </pre></td></tr></tbody></table></code></pre></div></div> 可以看到，这里我们只是添加了一个 autoVerify 属性。接着通过点击 Open Digital Asset Links File Generator **来生成配置的 json 文件： <img src="/img/in-post/post-android/1613994492217-c518d1d8-aca1-44f2-ab3a-9e763871e049.png" alt="config" /> **具体可参考官方文档的配置过程：<a href="https://developer.android.com/studio/write/app-link-indexing?utm_source=android-studio#associatesite">https://developer.android.com/studio/write/app-link-indexing?utm_source=android-studio#associatesite</a> 最终配置文件上传到服务器并测试通过后，就可以同样打开上面的测试链接，发现直接可以唤起我们的 APP，而不需要经过弹窗拦截。此外，我们除了可以通过Android studio提供的 tools 来验证 app link 配置的正确性以外，也可以直接通过以下 adb 命令来验证： <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 </pre></td><td class="rouge-code"><pre>adb shell dumpsys [package_name] domain-preferred-apps </pre></td></tr></tbody></table></code></pre></div></div> 如果显示如下信息，则校验成功： <div class="language-xml highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 </pre></td><td class="rouge-code"><pre>Package: com.xxx.example Domains: example.applink.xxx.com Status: always : 200000036 </pre></td></tr></tbody></table></code></pre></div></div> 另外，需要注意的是：想要该配置关联生效，APP 在安装时必须联网。 <h3 id="五测试-app-links-唤起方式">五、测试 App Links 唤起方式</h3> 当您 App Links 所有的环节已经配置完成后，可以利用测试设备测试唤起效果，测试步骤如下： 1、创建一条用于测试的 DeepLink ； 2、在测试设备中原生场景下进行测试，如：短信、备忘录等等；（不要直接在第三方软件中进行测试，例如微信。第三方软件通常对 DeepLink 跳转存在限制） 3、点击测试 DeepLink，如果可以直接跳转到 App 中，说明可以直接唤起 App，为最理想流程。 4、如果未直接跳转到 App 中，而是跳入下载引导中间页，并且系统弹窗询问是否要在应用中打开，此时可以通过上面的 <code class="language-plaintext highlighter-rouge">adb shell dumpsys [package_name] domain-preferred-apps</code> 命令中的 Status 查看状态，如果状态显示为“ask”，并且确认 App Links 集成流程正确无误，则可能是当前测试设备机型在 AppLinks 遇到校验问题，对于该情况请参考下方常见问题说明。对于 Status 状态的说明： <table> <thead> <tr> <th>Status 状态</th> <th>描述</th> </tr> </thead> <tbody> <tr> <td>ask</td> <td>Applink校验失败, 每次打开连接跳转时会弹出一个对话框，提示选择打开短链的App</td> </tr> <tr> <td>always</td> <td>校验成功，理想状态</td> </tr> <tr> <td>never</td> <td>用户选择不再打开</td> </tr> <tr> <td>always-ask</td> <td>可忽略，尚未发现这一个出现, 跟 never 一样需要手动干预才会出现</td> </tr> <tr> <td>undefined</td> <td>尚未校验完成，请稍后再试</td> </tr> </tbody> </table> 常见问题： 1、多数客户可能会在验证环节得到的 Status 为 ask，这是为什么呢？ AppLinks 的合法性是由系统校验，不同的手机系统使用不同的校验组件，即使是一个厂商的不同型号手机都可能使用不同的校验组件。如果系统使用 com.android.statementservice 进行 AppLinks 的校验，在网络正常的情况下基本都能顺利通过，如果系统使用 com.google.android.gms 组件校验，在手机能够科学上网的情况，也就是能够正常访问 Google 时，校验才能通过。常见华为 mate 系列，P 系列使用的都是 gms，也就是 Status 会为 ask。查看自己手机是使用哪种组件，在命令行中输入以下命令： adb shell dumpsys package i 综上，Applink 不能顺利通过系统检验，原因有以下可能： <ul> <li>可能是国内网络问题，使用 gms 组件校验的手机需要联通 Google 服务</li> <li>可能是您产品配置问题，GIO 填写的签名和手机上运行的 APP 签名不同</li> </ul> <h3 id="六在浏览器唤起-app-的场景">六、在浏览器唤起 APP 的场景</h3> 可是，重点来了，我们在实际测试过程中发现了一堆兼容性问题，在说明这些兼容性问题前，我们先解释一个概念：<code class="language-plaintext highlighter-rouge">intent://</code> 协议。 Android Chrome 25+ 后已经不支持自定义 <code class="language-plaintext highlighter-rouge">scheme</code> 的方式，只支持 <code class="language-plaintext highlighter-rouge">intent://</code> 协议（<a href="https://developer.chrome.com/multidevice/android/intents">Android Intents with Chrome</a>），最终要的是需要用户手动进行 点击 才能跳转，举个例子： <div class="language-html highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 </pre></td><td class="rouge-code"><pre> <a href="intent://scan/#Intent;scheme=zxing;package=com.google.zxing.client.android;S.browser_fallback_url=http%3A%2F%2Fzxing.org;end"> Take a QR code </a> <iframe href="intent://xxx" style="display: none;">></iframe>// 失效 <iframe href="strange://xxx" style="display: none;">></iframe>// 失效 </pre></td></tr></tbody></table></code></pre></div></div> <code class="language-plaintext highlighter-rouge">intent://</code> 协议格式说明： <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 </pre></td><td class="rouge-code"><pre>intent: //scan/ #Intent; package=com.google.zxing.client.android; scheme=zxing; end; </pre></td></tr></tbody></table></code></pre></div></div> 目前市面上大多第三方浏览器都是基于 Chrome 开发，这就带来了兼容性问题（没有条件覆盖所有的系统浏览器，这里只是有限测试的结果）： <img src="/img/in-post/post-android/1613995861766-a0a7aae1-7d24-46ea-9150-91e05218433a.png" alt="browsers" /> 1、部分浏览器，只支持 <code class="language-plaintext highlighter-rouge">intent://</code> 协议 手动 唤起，如chrome、锤子。 2、部分浏览器只支持 <code class="language-plaintext highlighter-rouge">scheme</code> 唤起，如 UC 浏览器。 3、大部分浏览器，同时支持 <code class="language-plaintext highlighter-rouge">scheme</code> 私有协议和 <code class="language-plaintext highlighter-rouge">intent://</code> 协议 自动 唤起。但，都没有按标准的 <code class="language-plaintext highlighter-rouge">intent://</code> 协议来实现（除了 360 浏览器，给 360 点个赞）： <ul> <li>有的浏览器在 App 没安装时并没有执行 <code class="language-plaintext highlighter-rouge">S.browser_fallback_url</code>，而是跳转到应用市场如猎豹浏览器 4.46.3、乐视浏览器 1.2.1.29。</li> <li>有的浏览器不支持 <code class="language-plaintext highlighter-rouge">S.browser_fallback_url</code> 如搜狗浏览器、欧朋浏览器、猎豹浏览器。</li> <li>有的浏览器无论应用有无安装 <code class="language-plaintext highlighter-rouge">S.browser_fallback_url</code> 一直都会执行如 QQ 浏览器。</li> </ul> 所以对这部分浏览器，不能使用 <code class="language-plaintext highlighter-rouge">intent://</code> 协议。 4、更奇葩者，二者都不支持，如百度浏览器。 <h5 id="兼容性问题解决方案">兼容性问题解决方案</h5> 针对上述三个兼容性问题，第 4 种情况无解我们直接忽略，第 2 第 3 种情况只能用自定义 scheme 的方式。问题出在第 1 种情况，因为只能手动唤起，我们需要对浏览器类型进行判断（浏览器没有提供是否支持 <code class="language-plaintext highlighter-rouge">自定义 scheme</code>、<code class="language-plaintext highlighter-rouge">intent://</code> 的 API 只能通过 UA 判断），结合我们有限的测试结果，如果是锤子、Chrome 原生浏览器，需在页面中内置一个“下载应用”的按钮引导用户点击。 <div class="language-html highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 </pre></td><td class="rouge-code"><pre> // 如果安装了 App 就跳转，否则就访问 S.browser_fallback_url 的值 http://strange.com <a href="intent://strange/#Intent;scheme=strange://login;package=com.strange;S.browser_fallback_url=http%3A%2F%2Fstrange.com;end">跳转到活动页/下载</a> </pre></td></tr></tbody></table></code></pre></div></div> 我们来分析一下浏览器的 UA ，举几个例子： <div class="language-html highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 </pre></td><td class="rouge-code"><pre>//小米系统浏览器 User-Agent:Mozilla/5.0 (Linux; U; Android 6.0.1; zh-cn; MI 3W Build/MMB29M) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/53.0.2785.146 Mobile Safari/537.36 XiaoMi/MiuiBrowser/8.9.5 // 小米 Chrome 原生浏览器 User-Agent:Mozilla/5.0 (Linux; Android 6.0.1; MI 3W Build/MMB29M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.108 Mobile Safari/537.36 // 锤子系统浏览器 User-Agent:Mozilla/5.0 (Linux; Android 5.1.1; YQ603 Build/LMY47V) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.11 Mobile Safari/537.36 // 锤子 Chrome 原生浏览器 User-Agent:Mozilla/5.0 (Linux; Android 5.1.1; YQ603 Build/LMY47V) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.89 Mobile Safari/537.36 </pre></td></tr></tbody></table></code></pre></div></div> 可以看出小米浏览器是在 Chrome 原生浏览器的 UA 上增加了 <code class="language-plaintext highlighter-rouge">XiaoMi/MiuiBrowser/8.9.5</code> 这部分特征码。类似的，很多第三方浏览器都是在 Chrome 基础上增加自己的特征码，换句话说 Chrome 原生浏览器 UA 没有自己的特征。而锤子系统浏览器和 Chrome 原生浏览器 UA 几乎一样，这就使得<code class="language-plaintext highlighter-rouge">判断是否锤子系统浏览器、 Chrome 原生浏览器</code> 变得异常困难，要想尽可能完美解决问题只能使用排除法。排除法由于不可能排除所有非 Chrome 原生浏览器，可能会存在误伤的可能。 <h5 id="经浏览器中转唤起-app-总结">经浏览器中转唤起 App 总结</h5> 要实现经浏览器中转 自动 唤起 App，Android 和 iOS 都可以通过 <code class="language-plaintext highlighter-rouge">自定义 scheme</code> 的方式，但 Android 的情况稍显复杂，因为部分浏览器并不支持，必须换成 <code class="language-plaintext highlighter-rouge">intent://</code> 协议的方式 手动 唤起。考虑到浏览器判断的难度，结合浏览器市场占有率的情况，我们最终的方案是暂时忽略 <code class="language-plaintext highlighter-rouge">锤子系统浏览器、 Chrome 原生浏览器</code> 这部分不支持 <code class="language-plaintext highlighter-rouge">自定义 scheme 自动唤起 App</code> 的用户。 <h5 id="app-links兼容性问题">App Links兼容性问题</h5> <ul> <li>App links在国内的支持还不够，部分安卓浏览器并不支持跳转至App，而是直接在浏览器上打开对应页面（直接将Applink作为链接跳转）。</li> <li>系统询问是否打开对应App时，假如用户选择“取消”并且选中了“记住此操作”，那么用户以后就无法再跳转 App。</li> </ul> <div class="language-html highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 </pre></td><td class="rouge-code"><pre> <a href="https://tuyasmart.applink.smart321.com/triple/fromalexa?client_id=xxx&response_type=alexa&state=1&scope=uejdj&redirect_uri=https.baidu.com">通过applink唤起</a> </pre></td></tr></tbody></table></code></pre></div></div> <div class="language-html highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 </pre></td><td class="rouge-code"><pre> <a href="intent://applink/deviceshare/#Intent;scheme=tuyasmart;package=com.tuya.smart;S.browser_fallback_url=https://www.zhihu.com/question/270839820;end">通过 chrome Intent 唤起</a> </pre></td></tr></tbody></table></code></pre></div></div> <div class="language-html highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 </pre></td><td class="rouge-code"><pre> <a href="tuyasmart://com.tuya.smart/applink/deviceshare?short_code=124141">通过scheme唤起</a> </pre></td></tr></tbody></table></code></pre></div></div> 经过自己简单部署的前端页面发现，在 App link、chrome intent 以及 scheme 三种唤起方式在不同机型和浏览器表现上存在较大差异，以下是几种机型和浏览器简单的对比（并不全）： <table> <thead> <tr> <th> </th> <th>App link（Android 6.0）</th> <th>chrome intent</th> <th>scheme</th> </tr> </thead> <tbody> <tr> <td>Pixel 2 XL（chrome）</td> <td>成功且无弹窗</td> <td>成功且无弹窗</td> <td>成功且无弹窗</td> </tr> <tr> <td>一加7t（夸克）</td> <td>失败</td> <td>成功，唤起前会有确认弹窗</td> <td>成功，唤起前会有确认弹窗</td> </tr> <tr> <td>三星GT-19500（三星浏览器 6.0 以下）</td> <td>失败</td> <td>成功且无弹窗</td> <td>成功且无弹窗</td> </tr> <tr> <td>三星GT-19500（chrome浏览器 6.0 以下）</td> <td>成功，但有选择弹窗</td> <td>成功且无弹窗</td> <td>成功且无弹窗</td> </tr> </tbody> </table> 虽然安卓还支持 APP Links 技术，但是这个技术依赖于谷歌服务器的验证，而谷歌服务器是被墙的，所以是在国内基本不能用。所以在安卓端能用的技术只有scheme技术了）可是大部分 App 的 URL Scheme 方式都被微信QQ封锁了，不过微信QQ有维护着一个白名单，如果你的域名在白名单内，那这个域名下所有的页面发起的 URL Scheme 就都会被允许。 <h3 id="七项目中应用现状">七、项目中应用现状</h3> 目前内置项目中已经部分模块实现了从外部网页直接唤起进入 APP 内部的功能，主要还是借助于传统 Deep link 的方式实现的： <div class="language-xml highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 </pre></td><td class="rouge-code"><pre> <activity android:name="com.example.activity.ThirdAuthActivity" android:exported="@ref/0x7f05000d" android:launchMode="2" android:screenOrientation="1" android:configChanges="0x4a0"> <intent-filter android:autoVerify="true"> <action android:name="android.intent.action.VIEW" /> <category android:name="android.intent.category.DEFAULT" /> <category android:name="android.intent.category.BROWSABLE" /> <data android:scheme="https" android:host="xyz.com" android:path="/action/share" /> </intent-filter> </activity> <activity android:name="com.example.activity.ThirdLinkActivity" android:screenOrientation="1" android:configChanges="0x4a0"> <intent-filter android:autoVerify="true"> <action android:name="android.intent.action.VIEW" /> <category android:name="android.intent.category.DEFAULT" /> <category android:name="android.intent.category.BROWSABLE" /> <data android:scheme="https" android:host="xyz123.com" android:path="/action/share" /> </intent-filter> </activity> </pre></td></tr></tbody></table></code></pre></div></div> 经过与产品确认，目前只考虑 Android 6.0及以上的情况统一使用 AppLinks 来从外部网页唤起应用。然而，针对于国内浏览器环境等综合因素及 Android6.0 以下的情况，还是使用传统 DeepLinks 方式兜底。 <h3 id="八理想方案">八、理想方案</h3> 综合起来就是： <ul> <li>通过 App Links（iOS 则是Universal Links），可以实现点击短信链接直接唤起 App；</li> <li>如果系统因为各种原因不支持 App Links，备选方案是 <code class="language-plaintext highlighter-rouge">URI Scheme</code>，不过会出弹框让用户选择用哪个 App 打开链接；</li> <li>如果用户没有选择我们的 App 而是选择了浏览器打开，则通过 <code class="language-plaintext highlighter-rouge">URI scheme</code> 尝试唤起 App；</li> <li>由于技术和成本问题，我们忽略不支持 URI Scheme 的浏览器。</li> </ul> 如下图所示： <img src="/img/in-post/post-android/1613995927345-daa104ec-88c1-43db-9bc9-c06526da922c.png" alt="perfect_flow" /> 网页能否判断当前运行的浏览器环境，如果是 chrome 浏览器（或内置chrome内核)，则通过 Applink 唤起应用页面，如果其他类型的浏览器能否判断是否支持 <code class="language-plaintext highlighter-rouge">intent://</code> 唤起，否则都通过原生 scheme 来兜底，至于 Android 6.0 以下机型默认执行 scheme 唤起，这也是 App link 在低版本机型上的默认兜底方式。 <h3 id="相关参考">相关参考</h3> <ul> <li><a href="https://sq.163yun.com/blog/article/172802377606160384">一切为了运营！如何从推广短信链接唤起 App？</a></li> <li><a href="https://www.zhihu.com/question/34846193">知乎讨论：如何用手机短信唤起app</a></li> <li><a href="https://developer.android.com/studio/write/app-link-indexing.html">Android官方文档：App Links 使用</a></li> <li><a href="https://developer.android.com/training/app-links/index.html">Android官方：处理Android应用链接</a></li> <li><a href="https://blog.csdn.net/u014626094/article/details/79501298">通过 Url 链接打开 APP</a></li> <li><a href="https://harttle.land/2017/12/24/launch-app-from-browser.html">Deep Linking：从浏览器调起 APP</a></li> <li><a href="https://developer.android.com/training/app-links/verify-site-associations">Android 文档：APP links 验证</a></li> <li><a href="https://growingio.gitbook.io/docs/product-manual/growing/ads/advance/deeplink">Growingio 专注用户增长 sdk 文档</a></li> <li><a href="https://cloud.tencent.com/developer/article/1558422">说说 Applink 的使用以及原理</a></li> <li><a href="https://juejin.cn/post/6844903494760349703">https://juejin.cn/post/6844903494760349703</a></li> <li><a href="https://segmentfault.com/a/1190000038308634">几种在浏览器网页唤起APP的方案</a></li> <li><a href="https://github.com/suanmei/callapp-lib/issues/26">网页唤起APP开源库推荐</a></li> <li><a href="https://developer.umeng.com/docs/191212/detail/194585">https://developer.umeng.com/docs/191212/detail/194585</a></li> <li><a href="https://segmentfault.com/a/1190000039744899">Web 前端几种常见的本地部署方式</a></li> </ul>

2023/9/16

Launcher进程启动过程剖析

上一篇<a href="https://dorck.cn/2023/04/22/android-initialization/">文章</a>我们对 Android 系统启动过程做了一定了解，本文将继续分析 Launcher 进程的启动流程。 <blockquote> 本文基于 Android 13 最新代码来进行源码分析。 </blockquote> <h3 id="launcher-进程启动">Launcher 进程启动</h3> 上文中，我们最终谈到了 <code class="language-plaintext highlighter-rouge">system_server</code> 进程的创建过程，并且该进程主要负责： <ul> <li>创建系统服务管理器——SystemServiceManager</li> <li>启动各种服务（AMS、PMS等）</li> <li>开启 Looper 循环，等待其他线程发送消息并处理</li> </ul> 我们看一下 AMS 服务创建及配置这块实现： <blockquote> frameworks/base/services/java/com/android/server/SystemServer.java </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 </pre></td><td class="rouge-code"><pre>// Activity manager runs the show. t.traceBegin("StartActivityManager"); // TODO: Might need to move after migration to WM. ActivityTaskManagerService atm = mSystemServiceManager.startService( ActivityTaskManagerService.Lifecycle.class).getService(); mActivityManagerService = ActivityManagerService.Lifecycle.startService( mSystemServiceManager, atm); mActivityManagerService.setSystemServiceManager(mSystemServiceManager); mActivityManagerService.setInstaller(installer); ...... // We now tell the activity manager it is okay to run third party // code. It will call back into us once it has gotten to the state // where third party code can really run (but before it has actually // started launching the initial applications), for us to complete our // initialization. mActivityManagerService.systemReady(() -> { Slog.i(TAG, "Making services ready"); t.traceBegin("StartActivityManagerReadyPhase"); mSystemServiceManager.startBootPhase(t, SystemService.PHASE_ACTIVITY_MANAGER_READY); t.traceEnd(); t.traceBegin("StartObservingNativeCrashes"); try { mActivityManagerService.startObservingNativeCrashes(); } catch (Throwable e) { reportWtf("observing native crashes", e); } ...... }, t); </pre></td></tr></tbody></table></code></pre></div></div> 下面重点关注一下 <code class="language-plaintext highlighter-rouge">ActivityManagerService.systemReady</code> 方法，通过注释可以简单了解到 Launcher 应用貌似就是在这里启动的，来找一下代码实现： <blockquote> frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 </pre></td><td class="rouge-code"><pre>public ActivityManagerService(Context systemContext, ActivityTaskManagerService atm) { ... mAtmInternal = LocalServices.getService(ActivityTaskManagerInternal.class); ... } /** * Ready. Set. Go! */ public void systemReady(final Runnable goingCallback, @NonNull TimingsTraceAndSlog t) { t.traceBegin("PhaseActivityManagerReady"); mSystemServiceManager.preSystemReady(); ... // Some systems - like automotive - will explicitly unlock system user then switch // to a secondary user. // TODO(b/242195409): this workaround shouldn't be necessary once we move // the headless-user start logic to UserManager-land. if (isBootingSystemUser && !UserManager.isHeadlessSystemUserMode()) { t.traceBegin("startHomeOnAllDisplays"); mAtmInternal.startHomeOnAllDisplays(currentUserId, "systemReady"); t.traceEnd(); } } </pre></td></tr></tbody></table></code></pre></div></div> 启动 Launcher 应用是在 <code class="language-plaintext highlighter-rouge">ActivityTaskManagerInternal#startHomeOnAllDisplays</code> 方法中，我们需要找一下 ActivityTaskManagerInternal 的实现类，但发现它是通过 <code class="language-plaintext highlighter-rouge">LocalServices.getService</code> 方法获取的： <blockquote> frameworks/base/core/java/com/android/server/LocalServices.java </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 </pre></td><td class="rouge-code"><pre>public final class LocalServices { private LocalServices() {} private static final ArrayMap<Class<?>, Object> sLocalServiceObjects = new ArrayMap<Class<?>, Object>(); /** * Returns a local service instance that implements the specified interface. * * @param type The type of service. * @return The service object. */ @SuppressWarnings("unchecked") public static <T> T getService(Class<T> type) { synchronized (sLocalServiceObjects) { return (T) sLocalServiceObjects.get(type); } } /** * Adds a service instance of the specified interface to the global registry of local services. */ public static <T> void addService(Class<T> type, T service) { synchronized (sLocalServiceObjects) { if (sLocalServiceObjects.containsKey(type)) { throw new IllegalStateException("Overriding service registration"); } sLocalServiceObjects.put(type, service); } } /** * Remove a service instance, must be only used in tests. */ @VisibleForTesting public static <T> void removeServiceForTest(Class<T> type) { synchronized (sLocalServiceObjects) { sLocalServiceObjects.remove(type); } } } </pre></td></tr></tbody></table></code></pre></div></div> 不难发现，LocalServices 其实就是个容器类，用于存储各项服务，既然可以通过 getService 获取服务实现，那么添加服务应该就是通过 addService 实现的，我们查找一下调用该方法的地方，并指定 class 为 <code class="language-plaintext highlighter-rouge">ActivityTaskManagerInternal</code>，最终发现实现层在 <code class="language-plaintext highlighter-rouge">ActivityTaskManagerService#LocalService</code> 中： <blockquote> frameworks/base/services/core/java/com/android/server/wm/ActivityTaskManagerService.java </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 </pre></td><td class="rouge-code"><pre>public class ActivityTaskManagerService extends IActivityTaskManager.Stub { public ActivityTaskManagerService(Context context) { mContext = context; ... mInternal = new LocalService(); ... } ... private void start() { LocalServices.addService(ActivityTaskManagerInternal.class, mInternal); } ... final class LocalService extends ActivityTaskManagerInternal { ... @Override public boolean startHomeOnAllDisplays(int userId, String reason) { synchronized (mGlobalLock) { return mRootWindowContainer.startHomeOnAllDisplays(userId, reason); } } ... } ... } </pre></td></tr></tbody></table></code></pre></div></div> 继续追溯到 <code class="language-plaintext highlighter-rouge">WindowManagerService#mRoot</code> 并查找实现： <blockquote> frameworks/base/services/core/java/com/android/server/wm/RootWindowContainer.java </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 </pre></td><td class="rouge-code"><pre> boolean startHomeOnDisplay(int userId, String reason, int displayId, boolean allowInstrumenting, boolean fromHomeKey) { // Fallback to top focused display or default display if the displayId is invalid. if (displayId == INVALID_DISPLAY) { final Task rootTask = getTopDisplayFocusedRootTask(); displayId = rootTask != null ? rootTask.getDisplayId() : DEFAULT_DISPLAY; } final DisplayContent display = getDisplayContent(displayId); return display.reduceOnAllTaskDisplayAreas((taskDisplayArea, result) -> result | startHomeOnTaskDisplayArea(userId, reason, taskDisplayArea, allowInstrumenting, fromHomeKey), false /* initValue */); } </pre></td></tr></tbody></table></code></pre></div></div> 继续再跟进到该类的 <code class="language-plaintext highlighter-rouge">startHomeOnTaskDisplayArea</code> 中： <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 </pre></td><td class="rouge-code"><pre>/** * This starts home activity on display areas that can have system decorations based on * displayId - default display area always uses primary home component. * For secondary display areas, the home activity must have category SECONDARY_HOME and then * resolves according to the priorities listed below. * - If default home is not set, always use the secondary home defined in the config. * - Use currently selected primary home activity. * - Use the activity in the same package as currently selected primary home activity. * If there are multiple activities matched, use first one. * - Use the secondary home defined in the config. */ boolean startHomeOnTaskDisplayArea(int userId, String reason, TaskDisplayArea taskDisplayArea, boolean allowInstrumenting, boolean fromHomeKey) { // Fallback to top focused display area if the provided one is invalid. if (taskDisplayArea == null) { final Task rootTask = getTopDisplayFocusedRootTask(); taskDisplayArea = rootTask != null ? rootTask.getDisplayArea() : getDefaultTaskDisplayArea(); } Intent homeIntent = null; ActivityInfo aInfo = null; if (taskDisplayArea == getDefaultTaskDisplayArea()) { homeIntent = mService.getHomeIntent(); aInfo = resolveHomeActivity(userId, homeIntent); } else if (shouldPlaceSecondaryHomeOnDisplayArea(taskDisplayArea)) { Pair<ActivityInfo, Intent> info = resolveSecondaryHomeActivity(userId, taskDisplayArea); aInfo = info.first; homeIntent = info.second; } if (aInfo == null || homeIntent == null) { return false; } if (!canStartHomeOnDisplayArea(aInfo, taskDisplayArea, allowInstrumenting)) { return false; } // Updates the home component of the intent. homeIntent.setComponent(new ComponentName(aInfo.applicationInfo.packageName, aInfo.name)); homeIntent.setFlags(homeIntent.getFlags() | FLAG_ACTIVITY_NEW_TASK); // Updates the extra information of the intent. if (fromHomeKey) { homeIntent.putExtra(WindowManagerPolicy.EXTRA_FROM_HOME_KEY, true); if (mWindowManager.getRecentsAnimationController() != null) { mWindowManager.getRecentsAnimationController().cancelAnimationForHomeStart(); } } homeIntent.putExtra(WindowManagerPolicy.EXTRA_START_REASON, reason); // Update the reason for ANR debugging to verify if the user activity is the one that // actually launched. final String myReason = reason + ":" + userId + ":" + UserHandle.getUserId( aInfo.applicationInfo.uid) + ":" + taskDisplayArea.getDisplayId(); mService.getActivityStartController().startHomeActivity(homeIntent, aInfo, myReason, taskDisplayArea); return true; } </pre></td></tr></tbody></table></code></pre></div></div> 定位到这里就知道我们离最终启动 Launcher 进程的地方不远了，因为我们发现了 Intent 的踪迹，这个方法内构建了一个 <code class="language-plaintext highlighter-rouge">homeIntent</code> 用于启动 Launcher 的 Activity。于是继续跟进： <blockquote> frameworks/base/services/core/java/com/android/server/wm/ActivityStartController.java </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 </pre></td><td class="rouge-code"><pre>void startHomeActivity(Intent intent, ActivityInfo aInfo, String reason, TaskDisplayArea taskDisplayArea) { final ActivityOptions options = ActivityOptions.makeBasic(); options.setLaunchWindowingMode(WINDOWING_MODE_FULLSCREEN); if (!ActivityRecord.isResolverActivity(aInfo.name)) { // The resolver activity shouldn't be put in root home task because when the // foreground is standard type activity, the resolver activity should be put on the // top of current foreground instead of bring root home task to front. options.setLaunchActivityType(ACTIVITY_TYPE_HOME); } final int displayId = taskDisplayArea.getDisplayId(); options.setLaunchDisplayId(displayId); options.setLaunchTaskDisplayArea(taskDisplayArea.mRemoteToken .toWindowContainerToken()); // The home activity will be started later, defer resuming to avoid unnecessary operations // (e.g. start home recursively) when creating root home task. mSupervisor.beginDeferResume(); final Task rootHomeTask; try { // Make sure root home task exists on display area. rootHomeTask = taskDisplayArea.getOrCreateRootHomeTask(ON_TOP); } finally { mSupervisor.endDeferResume(); } mLastHomeActivityStartResult = obtainStarter(intent, "startHomeActivity: " + reason) .setOutActivity(tmpOutRecord) .setCallingUid(0) .setActivityInfo(aInfo) .setActivityOptions(options.toBundle()) .execute(); mLastHomeActivityStartRecord = tmpOutRecord[0]; if (rootHomeTask.mInResumeTopActivity) { // If we are in resume section already, home activity will be initialized, but not // resumed (to avoid recursive resume) and will stay that way until something pokes it // again. We need to schedule another resume. mSupervisor.scheduleResumeTopActivities(); } } </pre></td></tr></tbody></table></code></pre></div></div> 接着发现启动 Launcher 是通过 obtainStarter 获取 ActivityStarter 并内部调用 execute 方法来实现的，而这里的 mLastHomeActivityStartResult 则是启动结果。我们具体来看下 ActivityStarter 的 execute 是如何实现的： <blockquote> frameworks/base/services/core/java/com/android/server/wm/ActivityStarter.java </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 </pre></td><td class="rouge-code"><pre>/** * Resolve necessary information according the request parameters provided earlier, and execute * the request which begin the journey of starting an activity. * @return The starter result. */ int execute() { try { onExecutionStarted(); // Refuse possible leaked file descriptors if (mRequest.intent != null && mRequest.intent.hasFileDescriptors()) { throw new IllegalArgumentException("File descriptors passed in Intent"); } final LaunchingState launchingState; synchronized (mService.mGlobalLock) { final ActivityRecord caller = ActivityRecord.forTokenLocked(mRequest.resultTo); final int callingUid = mRequest.realCallingUid == Request.DEFAULT_REAL_CALLING_UID ? Binder.getCallingUid() : mRequest.realCallingUid; launchingState = mSupervisor.getActivityMetricsLogger().notifyActivityLaunching( mRequest.intent, caller, callingUid); } // If the caller hasn't already resolved the activity, we're willing // to do so here. If the caller is already holding the WM lock here, // and we need to check dynamic Uri permissions, then we're forced // to assume those permissions are denied to avoid deadlocking. if (mRequest.activityInfo == null) { mRequest.resolveActivity(mSupervisor); } // Add checkpoint for this shutdown or reboot attempt, so we can record the original // intent action and package name. if (mRequest.intent != null) { String intentAction = mRequest.intent.getAction(); String callingPackage = mRequest.callingPackage; if (intentAction != null && callingPackage != null && (Intent.ACTION_REQUEST_SHUTDOWN.equals(intentAction) || Intent.ACTION_SHUTDOWN.equals(intentAction) || Intent.ACTION_REBOOT.equals(intentAction))) { ShutdownCheckPoints.recordCheckPoint(intentAction, callingPackage, null); } } int res; synchronized (mService.mGlobalLock) { final boolean globalConfigWillChange = mRequest.globalConfig != null && mService.getGlobalConfiguration().diff(mRequest.globalConfig) != 0; final Task rootTask = mRootWindowContainer.getTopDisplayFocusedRootTask(); if (rootTask != null) { rootTask.mConfigWillChange = globalConfigWillChange; } ProtoLog.v(WM_DEBUG_CONFIGURATION, "Starting activity when config " + "will change = %b", globalConfigWillChange); final long origId = Binder.clearCallingIdentity(); res = resolveToHeavyWeightSwitcherIfNeeded(); if (res != START_SUCCESS) { return res; } res = executeRequest(mRequest); Binder.restoreCallingIdentity(origId); if (globalConfigWillChange) { // If the caller also wants to switch to a new configuration, do so now. // This allows a clean switch, as we are waiting for the current activity // to pause (so we will not destroy it), and have not yet started the // next activity. mService.mAmInternal.enforceCallingPermission( android.Manifest.permission.CHANGE_CONFIGURATION, "updateConfiguration()"); if (rootTask != null) { rootTask.mConfigWillChange = false; } ProtoLog.v(WM_DEBUG_CONFIGURATION, "Updating to new configuration after starting activity."); mService.updateConfigurationLocked(mRequest.globalConfig, null, false); } // The original options may have additional info about metrics. The mOptions is not // used here because it may be cleared in setTargetRootTaskIfNeeded. final ActivityOptions originalOptions = mRequest.activityOptions != null ? mRequest.activityOptions.getOriginalOptions() : null; // If the new record is the one that started, a new activity has created. final boolean newActivityCreated = mStartActivity == mLastStartActivityRecord; // Notify ActivityMetricsLogger that the activity has launched. // ActivityMetricsLogger will then wait for the windows to be drawn and populate // WaitResult. mSupervisor.getActivityMetricsLogger().notifyActivityLaunched(launchingState, res, newActivityCreated, mLastStartActivityRecord, originalOptions); if (mRequest.waitResult != null) { mRequest.waitResult.result = res; res = waitResultIfNeeded(mRequest.waitResult, mLastStartActivityRecord, launchingState); } return getExternalResult(res); } } finally { onExecutionComplete(); } } </pre></td></tr></tbody></table></code></pre></div></div> 这里主要做一些 Activity 启动相关细节参数的校验，验证通过后继续执行 <code class="language-plaintext highlighter-rouge">executeRequest</code> 方法： <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 </pre></td><td class="rouge-code"><pre> /** * Executing activity start request and starts the journey of starting an activity. Here * begins with performing several preliminary checks. The normally activity launch flow will * go through {@link #startActivityUnchecked} to {@link #startActivityInner}. */ private int executeRequest(Request request) { ... final ActivityRecord r = new ActivityRecord.Builder(mService) .setCaller(callerApp) .setLaunchedFromPid(callingPid) .setLaunchedFromUid(callingUid) .setLaunchedFromPackage(callingPackage) .setLaunchedFromFeature(callingFeatureId) .setIntent(intent) .setResolvedType(resolvedType) .setActivityInfo(aInfo) .setConfiguration(mService.getGlobalConfiguration()) .setResultTo(resultRecord) .setResultWho(resultWho) .setRequestCode(requestCode) .setComponentSpecified(request.componentSpecified) .setRootVoiceInteraction(voiceSession != null) .setActivityOptions(checkedOptions) .setSourceRecord(sourceRecord) .build(); mLastStartActivityRecord = r; ... mLastStartActivityResult = startActivityUnchecked(r, sourceRecord, voiceSession, request.voiceInteractor, startFlags, true /* doResume */, checkedOptions, inTask, inTaskFragment, restrictedBgActivity, intentGrants); if (request.outActivity != null) { request.outActivity[0] = mLastStartActivityRecord; } return mLastStartActivityResult; } </pre></td></tr></tbody></table></code></pre></div></div> 首先构建了一个 ActivityRecord 用于记录 Activity 相关信息（如包名、进程名、启动模式、task 信息等），接着调用 <code class="language-plaintext highlighter-rouge">startActivityUnchecked</code>： <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 </pre></td><td class="rouge-code"><pre>/** * Start an activity while most of preliminary checks has been done and caller has been * confirmed that holds necessary permissions to do so. * Here also ensures that the starting activity is removed if the start wasn't successful. */ private int startActivityUnchecked(final ActivityRecord r, ActivityRecord sourceRecord, IVoiceInteractionSession voiceSession, IVoiceInteractor voiceInteractor, int startFlags, boolean doResume, ActivityOptions options, Task inTask, TaskFragment inTaskFragment, boolean restrictedBgActivity, NeededUriGrants intentGrants) { int result = START_CANCELED; final Task startedActivityRootTask; // Create a transition now to record the original intent of actions taken within // startActivityInner. Otherwise, logic in startActivityInner could start a different // transition based on a sub-action. // Only do the create here (and defer requestStart) since startActivityInner might abort. final TransitionController transitionController = r.mTransitionController; Transition newTransition = (!transitionController.isCollecting() && transitionController.getTransitionPlayer() != null) ? transitionController.createTransition(TRANSIT_OPEN) : null; RemoteTransition remoteTransition = r.takeRemoteTransition(); try { mService.deferWindowLayout(); transitionController.collect(r); try { Trace.traceBegin(Trace.TRACE_TAG_WINDOW_MANAGER, "startActivityInner"); result = startActivityInner(r, sourceRecord, voiceSession, voiceInteractor, startFlags, doResume, options, inTask, inTaskFragment, restrictedBgActivity, intentGrants); } finally { Trace.traceEnd(Trace.TRACE_TAG_WINDOW_MANAGER); startedActivityRootTask = handleStartResult(r, options, result, newTransition, remoteTransition); } } finally { mService.continueWindowLayout(); } postStartActivityProcessing(r, result, startedActivityRootTask); return result; } </pre></td></tr></tbody></table></code></pre></div></div> 继续追踪到 <code class="language-plaintext highlighter-rouge">startActivityInner</code> 方法中： <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 </pre></td><td class="rouge-code"><pre>int startActivityInner(final ActivityRecord r, ActivityRecord sourceRecord, IVoiceInteractionSession voiceSession, IVoiceInteractor voiceInteractor, int startFlags, boolean doResume, ActivityOptions options, Task inTask, TaskFragment inTaskFragment, boolean restrictedBgActivity, NeededUriGrants intentGrants) { ... if (mDoResume) { final ActivityRecord topTaskActivity = startedTask.topRunningActivityLocked(); if (!mTargetRootTask.isTopActivityFocusable() || (topTaskActivity != null && topTaskActivity.isTaskOverlay() && mStartActivity != topTaskActivity)) { mTargetRootTask.ensureActivitiesVisible(null /* starting */, 0 /* configChanges */, !PRESERVE_WINDOWS); mTargetRootTask.mDisplayContent.executeAppTransition(); } else { // If the target root-task was not previously focusable (previous top running // activity on that root-task was not visible) then any prior calls to move the // root-task to the will not update the focused root-task. If starting the new // activity now allows the task root-task to be focusable, then ensure that we // now update the focused root-task accordingly. if (mTargetRootTask.isTopActivityFocusable() && !mRootWindowContainer.isTopDisplayFocusedRootTask(mTargetRootTask)) { mTargetRootTask.moveToFront("startActivityInner"); } mRootWindowContainer.resumeFocusedTasksTopActivities( mTargetRootTask, mStartActivity, mOptions, mTransientLaunch); } } mRootWindowContainer.updateUserRootTask(mStartActivity.mUserId, mTargetRootTask); ... } </pre></td></tr></tbody></table></code></pre></div></div> 发现最终又调用回了 RootWindowContainer： <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 </pre></td><td class="rouge-code"><pre>boolean resumeFocusedTasksTopActivities( Task targetRootTask, ActivityRecord target, ActivityOptions targetOptions, boolean deferPause) { if (!mTaskSupervisor.readyToResume()) { return false; } boolean result = false; // 如果是栈顶 Activity 则调用 resumeTopActivityUncheckedLocked if (targetRootTask != null && (targetRootTask.isTopRootTaskInDisplayArea() || getTopDisplayFocusedRootTask() == targetRootTask)) { result = targetRootTask.resumeTopActivityUncheckedLocked(target, targetOptions, deferPause); } for (int displayNdx = getChildCount() - 1; displayNdx >= 0; --displayNdx) { final DisplayContent display = getChildAt(displayNdx); final boolean curResult = result; boolean[] resumedOnDisplay = new boolean[1]; display.forAllRootTasks(rootTask -> { final ActivityRecord topRunningActivity = rootTask.topRunningActivity(); if (!rootTask.isFocusableAndVisible() || topRunningActivity == null) { return; } if (rootTask == targetRootTask) { // Simply update the result for targetRootTask because the targetRootTask // had already resumed in above. We don't want to resume it again, // especially in some cases, it would cause a second launch failure // if app process was dead. resumedOnDisplay[0] |= curResult; return; } if (rootTask.getDisplayArea().isTopRootTask(rootTask) && topRunningActivity.isState(RESUMED)) { // Kick off any lingering app transitions from the MoveTaskToFront // operation, but only consider the top task and root-task on that // display. rootTask.executeAppTransition(targetOptions); } else { resumedOnDisplay[0] |= topRunningActivity.makeActiveIfNeeded(target); } }); result |= resumedOnDisplay[0]; if (!resumedOnDisplay[0]) { // In cases when there are no valid activities (e.g. device just booted or launcher // crashed) it's possible that nothing was resumed on a display. Requesting resume // of top activity in focused root task explicitly will make sure that at least home // activity is started and resumed, and no recursion occurs. final Task focusedRoot = display.getFocusedRootTask(); if (focusedRoot != null) { result |= focusedRoot.resumeTopActivityUncheckedLocked(target, targetOptions); } else if (targetRootTask == null) { result |= resumeHomeActivity(null /* prev */, "no-focusable-task", display.getDefaultTaskDisplayArea()); } } } return result; } </pre></td></tr></tbody></table></code></pre></div></div> 第一次正常启动 Launcher 会执行到 <code class="language-plaintext highlighter-rouge">resumeTopActivityUncheckedLocked</code>： <blockquote> frameworks/base/services/core/java/com/android/server/wm/Task.java </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 </pre></td><td class="rouge-code"><pre>/** * Ensure that the top activity in the root task is resumed. * * @param prev The previously resumed activity, for when in the process * of pausing; can be null to call from elsewhere. * @param options Activity options. * @param deferPause When {@code true}, this will not pause back tasks. * * @return Returns true if something is being resumed, or false if * nothing happened. * * NOTE: It is not safe to call this method directly as it can cause an activity in a * non-focused root task to be resumed. * Use {@link RootWindowContainer#resumeFocusedTasksTopActivities} to resume the * right activity for the current system state. */ @GuardedBy("mService") boolean resumeTopActivityUncheckedLocked(ActivityRecord prev, ActivityOptions options, boolean deferPause) { if (mInResumeTopActivity) { // Don't even start recursing. return false; } boolean someActivityResumed = false; try { // Protect against recursion. mInResumeTopActivity = true; if (isLeafTask()) { if (isFocusableAndVisible()) { someActivityResumed = resumeTopActivityInnerLocked(prev, options, deferPause); } } else { int idx = mChildren.size() - 1; while (idx >= 0) { final Task child = (Task) getChildAt(idx--); if (!child.isTopActivityFocusable()) { continue; } if (child.getVisibility(null /* starting */) != TASK_FRAGMENT_VISIBILITY_VISIBLE) { if (child.topRunningActivity() == null) { // Skip the task if no running activity and continue resuming next task. continue; } // Otherwise, assuming everything behind this task should also be invisible. break; } someActivityResumed |= child.resumeTopActivityUncheckedLocked(prev, options, deferPause); // Doing so in order to prevent IndexOOB since hierarchy might changes while // resuming activities, for example dismissing split-screen while starting // non-resizeable activity. if (idx >= mChildren.size()) { idx = mChildren.size() - 1; } } } // When resuming the top activity, it may be necessary to pause the top activity (for // example, returning to the lock screen. We suppress the normal pause logic in // {@link #resumeTopActivityUncheckedLocked}, since the top activity is resumed at the // end. We call the {@link ActivityTaskSupervisor#checkReadyForSleepLocked} again here // to ensure any necessary pause logic occurs. In the case where the Activity will be // shown regardless of the lock screen, the call to // {@link ActivityTaskSupervisor#checkReadyForSleepLocked} is skipped. final ActivityRecord next = topRunningActivity(true /* focusableOnly */); if (next == null || !next.canTurnScreenOn()) { checkReadyForSleep(); } } finally { mInResumeTopActivity = false; } return someActivityResumed; } </pre></td></tr></tbody></table></code></pre></div></div> 最终会跟进到 <code class="language-plaintext highlighter-rouge">TaskFragment</code> 当中： <blockquote> frameworks/base/services/core/java/com/android/server/wm/TaskFragment.java </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 </pre></td><td class="rouge-code"><pre>final boolean resumeTopActivity(ActivityRecord prev, ActivityOptions options, boolean deferPause) { ... if (next.attachedToProcess()) { ... } else { // Whoops, need to restart this activity! if (!next.hasBeenLaunched) { next.hasBeenLaunched = true; } else { if (SHOW_APP_STARTING_PREVIEW) { next.showStartingWindow(false /* taskSwich */); } if (DEBUG_SWITCH) Slog.v(TAG_SWITCH, "Restarting: " + next); } ProtoLog.d(WM_DEBUG_STATES, "resumeTopActivity: Restarting %s", next); mTaskSupervisor.startSpecificActivity(next, true, true); } } </pre></td></tr></tbody></table></code></pre></div></div> 重点看下 <code class="language-plaintext highlighter-rouge">ActivityTaskSupervisor#startSpecificActivity</code>： <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 </pre></td><td class="rouge-code"><pre>void startSpecificActivity(ActivityRecord r, boolean andResume, boolean checkConfig) { // Is this activity's application already running? final WindowProcessController wpc = mService.getProcessController(r.processName, r.info.applicationInfo.uid); boolean knownToBeDead = false; if (wpc != null && wpc.hasThread()) { try { realStartActivityLocked(r, wpc, andResume, checkConfig); return; } catch (RemoteException e) { Slog.w(TAG, "Exception when starting activity " + r.intent.getComponent().flattenToShortString(), e); } // If a dead object exception was thrown -- fall through to // restart the application. knownToBeDead = true; // Remove the process record so it won't be considered as alive. mService.mProcessNames.remove(wpc.mName, wpc.mUid); mService.mProcessMap.remove(wpc.getPid()); } r.notifyUnknownVisibilityLaunchedForKeyguardTransition(); final boolean isTop = andResume && r.isTopRunningActivity(); mService.startProcessAsync(r, knownToBeDead, isTop, isTop ? HostingRecord.HOSTING_TYPE_TOP_ACTIVITY : HostingRecord.HOSTING_TYPE_ACTIVITY); } </pre></td></tr></tbody></table></code></pre></div></div> 跟踪了方法调用栈这么久终于找到“罪魁祸首”了，startSpecificActivity 方法做了两件事： <ul> <li>如果 Activity 的进程已经启动，则直接执行 <code class="language-plaintext highlighter-rouge">realStartActivityLocked</code> 来启动 Activity（通常是启动一般已运行进程的 Activity）；</li> <li>如果 Activity 的进程尚未启动，那么需要先执行 <code class="language-plaintext highlighter-rouge">ActivityTaskManagerService#startProcessAsync</code> 创建进程（通常是进程尚未启动的情况，例如初次打开 APP）。</li> </ul> 上面的 Activity 在本场景下指代 Launcher 进程的首个 Activity，由于是第一次启动该 Activity，所以进程肯定还没有创建，我们先去看下 startProcessAsync 中是如何创建 Launcher 进程的： <blockquote> frameworks/base/services/core/java/com/android/server/wm/ActivityTaskManagerService.java </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 </pre></td><td class="rouge-code"><pre>void startProcessAsync(ActivityRecord activity, boolean knownToBeDead, boolean isTop, String hostingType) { try { if (Trace.isTagEnabled(TRACE_TAG_WINDOW_MANAGER)) { Trace.traceBegin(TRACE_TAG_WINDOW_MANAGER, "dispatchingStartProcess:" + activity.processName); } // Post message to start process to avoid possible deadlock of calling into AMS with the // ATMS lock held. final Message m = PooledLambda.obtainMessage(ActivityManagerInternal::startProcess, mAmInternal, activity.processName, activity.info.applicationInfo, knownToBeDead, isTop, hostingType, activity.intent.getComponent()); mH.sendMessage(m); } finally { Trace.traceEnd(TRACE_TAG_WINDOW_MANAGER); } } </pre></td></tr></tbody></table></code></pre></div></div> 由此可见，这里通过 Message-Handler 来发送创建进程的消息，消息接收处理是通过设置的 Callback，最终回调给 <code class="language-plaintext highlighter-rouge">ActivityManagerInternal::startProcess</code>： <blockquote> frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 </pre></td><td class="rouge-code"><pre>@Override public void startProcess(String processName, ApplicationInfo info, boolean knownToBeDead, boolean isTop, String hostingType, ComponentName hostingName) { try { if (Trace.isTagEnabled(Trace.TRACE_TAG_ACTIVITY_MANAGER)) { Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "startProcess:" + processName); } synchronized (ActivityManagerService.this) { // If the process is known as top app, set a hint so when the process is // started, the top priority can be applied immediately to avoid cpu being // preempted by other processes before attaching the process of top app. startProcessLocked(processName, info, knownToBeDead, 0 /* intentFlags */, new HostingRecord(hostingType, hostingName, isTop), ZYGOTE_POLICY_FLAG_LATENCY_SENSITIVE, false /* allowWhileBooting */, false /* isolated */); } } finally { Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER); } } @GuardedBy("this") final ProcessRecord startProcessLocked(String processName, ApplicationInfo info, boolean knownToBeDead, int intentFlags, HostingRecord hostingRecord, int zygotePolicyFlags, boolean allowWhileBooting, boolean isolated) { return mProcessList.startProcessLocked(processName, info, knownToBeDead, intentFlags, hostingRecord, zygotePolicyFlags, allowWhileBooting, isolated, 0 /* isolatedUid */, false /* isSdkSandbox */, 0 /* sdkSandboxClientAppUid */, null /* sdkSandboxClientAppPackage */, null /* ABI override */, null /* entryPoint */, null /* entryPointArgs */, null /* crashHandler */); } </pre></td></tr></tbody></table></code></pre></div></div> 接着执行到 <code class="language-plaintext highlighter-rouge">ProcessList#startProcessLocked</code> ： <blockquote> frameworks/base/services/core/java/com/android/server/am/ProcessList.java </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 </pre></td><td class="rouge-code"><pre>ProcessRecord startProcessLocked(String processName, ApplicationInfo info, boolean knownToBeDead, int intentFlags, HostingRecord hostingRecord, int zygotePolicyFlags, boolean allowWhileBooting, boolean isolated, int isolatedUid, boolean isSdkSandbox, int sdkSandboxUid, String sdkSandboxClientAppPackage, String abiOverride, String entryPoint, String[] entryPointArgs, Runnable crashHandler) { long startTime = SystemClock.uptimeMillis(); ProcessRecord app; if (!isolated) { app = getProcessRecordLocked(processName, info.uid); checkSlow(startTime, "startProcess: after getProcessRecord"); ... } else { // If this is an isolated process, it can't re-use an existing process. app = null; } ... final boolean success = startProcessLocked(app, hostingRecord, zygotePolicyFlags, abiOverride); checkSlow(startTime, "startProcess: done starting proc!"); return success ? app : null; } /** * @return {@code true} if process start is successful, false otherwise. */ @GuardedBy("mService") boolean startProcessLocked(ProcessRecord app, HostingRecord hostingRecord, int zygotePolicyFlags, boolean disableHiddenApiChecks, boolean disableTestApiChecks, String abiOverride) { if (app.isPendingStart()) { return true; } ... ApplicationInfo definingAppInfo; if (hostingRecord.getDefiningPackageName() != null) { definingAppInfo = new ApplicationInfo(app.info); definingAppInfo.packageName = hostingRecord.getDefiningPackageName(); definingAppInfo.uid = uid; } else { definingAppInfo = app.info; } runtimeFlags |= Zygote.getMemorySafetyRuntimeFlags( definingAppInfo, app.processInfo, instructionSet, mPlatformCompat); ... // 进程入口函数所在类 final String entryPoint = "android.app.ActivityThread"; return startProcessLocked(hostingRecord, entryPoint, app, uid, gids, runtimeFlags, zygotePolicyFlags, mountExternal, seInfo, requiredAbi, instructionSet, invokeWith, startUptime, startElapsedTime); } catch (RuntimeException e) { Slog.e(ActivityManagerService.TAG, "Failure starting process " + app.processName, e); mService.forceStopPackageLocked(app.info.packageName, UserHandle.getAppId(app.uid), false, false, true, false, false, app.userId, "start failure"); return false; } } boolean startProcessLocked(HostingRecord hostingRecord, String entryPoint, ProcessRecord app, int uid, int[] gids, int runtimeFlags, int zygotePolicyFlags, int mountExternal, String seInfo, String requiredAbi, String instructionSet, String invokeWith, long startUptime, long startElapsedTime) { ... if (mService.mConstants.FLAG_PROCESS_START_ASYNC) { ... return true; } else { try { final Process.ProcessStartResult startResult = startProcess(hostingRecord, entryPoint, app, uid, gids, runtimeFlags, zygotePolicyFlags, mountExternal, seInfo, requiredAbi, instructionSet, invokeWith, startUptime); handleProcessStartedLocked(app, startResult.pid, startResult.usingWrapper, startSeq, false); } catch (RuntimeException e) { ... } return app.getPid() > 0; } } /** * Main handler routine to start the given process from the ProcStartHandler. * * Note: this function doesn't hold the global AM lock intentionally. */ private void handleProcessStart(final ProcessRecord app, final String entryPoint, final int[] gids, final int runtimeFlags, int zygotePolicyFlags, final int mountExternal, final String requiredAbi, final String instructionSet, final String invokeWith, final long startSeq) { final Runnable startRunnable = () -> { try { final Process.ProcessStartResult startResult = startProcess(app.getHostingRecord(), entryPoint, app, app.getStartUid(), gids, runtimeFlags, zygotePolicyFlags, mountExternal, app.getSeInfo(), requiredAbi, instructionSet, invokeWith, app.getStartTime()); synchronized (mService) { handleProcessStartedLocked(app, startResult, startSeq); } } catch (RuntimeException e) { ... } }; // Use local reference since we are not using locks here final ProcessRecord predecessor = app.mPredecessor; if (predecessor != null && predecessor.getDyingPid() > 0) { handleProcessStartWithPredecessor(predecessor, startRunnable); } else { // Kick off the process start for real. startRunnable.run(); } } private Process.ProcessStartResult startProcess(HostingRecord hostingRecord, String entryPoint, ProcessRecord app, int uid, int[] gids, int runtimeFlags, int zygotePolicyFlags, int mountExternal, String seInfo, String requiredAbi, String instructionSet, String invokeWith, long startTime) { try { Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "Start proc: " + app.processName); ... final Process.ProcessStartResult startResult; boolean regularZygote = false; if (hostingRecord.usesWebviewZygote()) { ... } else if (hostingRecord.usesAppZygote()) { final AppZygote appZygote = createAppZygoteForProcessIfNeeded(app); // We can't isolate app data and storage data as parent zygote already did that. startResult = appZygote.getProcess().start(entryPoint, app.processName, uid, uid, gids, runtimeFlags, mountExternal, app.info.targetSdkVersion, seInfo, requiredAbi, instructionSet, app.info.dataDir, null, app.info.packageName, /*zygotePolicyFlags=*/ ZYGOTE_POLICY_FLAG_EMPTY, isTopApp, app.getDisabledCompatChanges(), pkgDataInfoMap, allowlistedAppDataInfoMap, false, false, new String[]{PROC_START_SEQ_IDENT + app.getStartSeq()}); } else { regularZygote = true; startResult = Process.start(entryPoint, app.processName, uid, uid, gids, runtimeFlags, mountExternal, app.info.targetSdkVersion, seInfo, requiredAbi, instructionSet, app.info.dataDir, invokeWith, app.info.packageName, zygotePolicyFlags, isTopApp, app.getDisabledCompatChanges(), pkgDataInfoMap, allowlistedAppDataInfoMap, bindMountAppsData, bindMountAppStorageDirs, new String[]{PROC_START_SEQ_IDENT + app.getStartSeq()}); } ... return startResult; } finally { Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER); } } </pre></td></tr></tbody></table></code></pre></div></div> 经过重重方法调用，最终抵达了进程创建的目的地，它的前置方法 <code class="language-plaintext highlighter-rouge">startProcessLocked</code> 主要用于包装进程启动相关参数信息及合并状态信息。值得注意的是，参数中的 entryPoint 这里特指 <code class="language-plaintext highlighter-rouge">android.app.ActivityThread</code>，表示后续在创建进程时的入口类。我们主要关注一下上面的 <code class="language-plaintext highlighter-rouge">startProcess</code> 方法，它内部涉及到两个不同的创建新进程的分支，分别为： <ul> <li>appZygote：AppZygote 进程来孵化新进程，与常规 zygote 创建的应用相比受到更多限制；</li> <li>regularZygote：常规的 zygote32/zygote64 进程，是所有 Android 应用的父进程。</li> </ul> 我们这里着重关注 regularZygote 的分支，具体看下内部通过 <code class="language-plaintext highlighter-rouge">Process.start</code> 创建进程的实现： <blockquote> frameworks/base/core/java/android/os/Process.java </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 </pre></td><td class="rouge-code"><pre>/** * State associated with the zygote process. * @hide */ public static final ZygoteProcess ZYGOTE_PROCESS = new ZygoteProcess(); public static ProcessStartResult start(@NonNull final String processClass, @Nullable final String niceName, int uid, int gid, @Nullable int[] gids, int runtimeFlags, int mountExternal, int targetSdkVersion, @Nullable String seInfo, @NonNull String abi, @Nullable String instructionSet, @Nullable String appDataDir, @Nullable String invokeWith, @Nullable String packageName, int zygotePolicyFlags, boolean isTopApp, @Nullable long[] disabledCompatChanges, @Nullable Map<String, Pair<String, Long>> pkgDataInfoMap, @Nullable Map<String, Pair<String, Long>> whitelistedDataInfoMap, boolean bindMountAppsData, boolean bindMountAppStorageDirs, @Nullable String[] zygoteArgs) { return ZYGOTE_PROCESS.start(processClass, niceName, uid, gid, gids, runtimeFlags, mountExternal, targetSdkVersion, seInfo, abi, instructionSet, appDataDir, invokeWith, packageName, zygotePolicyFlags, isTopApp, disabledCompatChanges, pkgDataInfoMap, whitelistedDataInfoMap, bindMountAppsData, bindMountAppStorageDirs, zygoteArgs); } </pre></td></tr></tbody></table></code></pre></div></div> 可以看到，<code class="language-plaintext highlighter-rouge">Process.start</code> 最终调用的是 <code class="language-plaintext highlighter-rouge">ZygoteProcess#start</code> 方法： <blockquote> frameworks/base/core/java/android/os/ZygoteProcess.java </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 </pre></td><td class="rouge-code"><pre>public final Process.ProcessStartResult start(@NonNull final String processClass, final String niceName, int uid, int gid, @Nullable int[] gids, int runtimeFlags, int mountExternal, int targetSdkVersion, @Nullable String seInfo, @NonNull String abi, @Nullable String instructionSet, @Nullable String appDataDir, @Nullable String invokeWith, @Nullable String packageName, int zygotePolicyFlags, boolean isTopApp, @Nullable long[] disabledCompatChanges, @Nullable Map<String, Pair<String, Long>> pkgDataInfoMap, @Nullable Map<String, Pair<String, Long>> allowlistedDataInfoList, boolean bindMountAppsData, boolean bindMountAppStorageDirs, @Nullable String[] zygoteArgs) { // TODO (chriswailes): Is there a better place to check this value? if (fetchUsapPoolEnabledPropWithMinInterval()) { informZygotesOfUsapPoolStatus(); } try { return startViaZygote(processClass, niceName, uid, gid, gids, runtimeFlags, mountExternal, targetSdkVersion, seInfo, abi, instructionSet, appDataDir, invokeWith, /*startChildZygote=*/ false, packageName, zygotePolicyFlags, isTopApp, disabledCompatChanges, pkgDataInfoMap, allowlistedDataInfoList, bindMountAppsData, bindMountAppStorageDirs, zygoteArgs); } catch (ZygoteStartFailedEx ex) { Log.e(LOG_TAG, "Starting VM process through Zygote failed"); throw new RuntimeException( "Starting VM process through Zygote failed", ex); } } private Process.ProcessStartResult startViaZygote(@NonNull final String processClass, @Nullable final String niceName, final int uid, final int gid, @Nullable final int[] gids, int runtimeFlags, int mountExternal, int targetSdkVersion, @Nullable String seInfo, @NonNull String abi, @Nullable String instructionSet, @Nullable String appDataDir, @Nullable String invokeWith, boolean startChildZygote, @Nullable String packageName, int zygotePolicyFlags, boolean isTopApp, @Nullable long[] disabledCompatChanges, @Nullable Map<String, Pair<String, Long>> pkgDataInfoMap, @Nullable Map<String, Pair<String, Long>> allowlistedDataInfoList, boolean bindMountAppsData, boolean bindMountAppStorageDirs, @Nullable String[] extraArgs) throws ZygoteStartFailedEx { ArrayList<String> argsForZygote = new ArrayList<>(); ... argsForZygote.add(processClass); if (extraArgs != null) { Collections.addAll(argsForZygote, extraArgs); } synchronized(mLock) { // The USAP pool can not be used if the application will not use the systems graphics // driver. If that driver is requested use the Zygote application start path. return zygoteSendArgsAndGetResult(openZygoteSocketIfNeeded(abi), zygotePolicyFlags, argsForZygote); } } private Process.ProcessStartResult zygoteSendArgsAndGetResult( ZygoteState zygoteState, int zygotePolicyFlags, @NonNull ArrayList<String> args) throws ZygoteStartFailedEx { ... return attemptZygoteSendArgsAndGetResult(zygoteState, msgStr); } private Process.ProcessStartResult attemptZygoteSendArgsAndGetResult( ZygoteState zygoteState, String msgStr) throws ZygoteStartFailedEx { try { final BufferedWriter zygoteWriter = zygoteState.mZygoteOutputWriter; final DataInputStream zygoteInputStream = zygoteState.mZygoteInputStream; zygoteWriter.write(msgStr); zygoteWriter.flush(); // Always read the entire result from the input stream to avoid leaving // bytes in the stream for future process starts to accidentally stumble // upon. Process.ProcessStartResult result = new Process.ProcessStartResult(); result.pid = zygoteInputStream.readInt(); result.usingWrapper = zygoteInputStream.readBoolean(); if (result.pid < 0) { throw new ZygoteStartFailedEx("fork() failed"); } return result; } catch (IOException ex) { zygoteState.close(); Log.e(LOG_TAG, "IO Exception while communicating with Zygote - " + ex.toString()); throw new ZygoteStartFailedEx(ex); } } </pre></td></tr></tbody></table></code></pre></div></div> 总的来说，上面就是 zygote 孵化进程的过程。主要分为以下几个步骤： <ul> <li>启动进程的参数封装</li> <li>打开 Socket 套接字，并与 zygote 进程建立连接（详见 <code class="language-plaintext highlighter-rouge">openZygoteSocketIfNeeded</code>）</li> <li>将进程的参数信息写入 <code class="language-plaintext highlighter-rouge">BufferedWriter</code>，并传输给 zygote 进程；通过 <code class="language-plaintext highlighter-rouge">DataInputStream</code> 来接收 zygote 进程返回的结果</li> </ul> 打开套接字并与 ZygoteServer 建立连接是在 openZygoteSocketIfNeeded 中完成的： <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 </pre></td><td class="rouge-code"><pre>/** * Tries to open a session socket to a Zygote process with a compatible ABI if one is not * already open. If a compatible session socket is already open that session socket is returned. * This function may block and may have to try connecting to multiple Zygotes to find the * appropriate one. Requires that mLock be held. */ private ZygoteState openZygoteSocketIfNeeded(String abi) throws ZygoteStartFailedEx { try { attemptConnectionToPrimaryZygote(); if (primaryZygoteState.matches(abi)) { return primaryZygoteState; } if (mZygoteSecondarySocketAddress != null) { // The primary zygote didn't match. Try the secondary. attemptConnectionToSecondaryZygote(); if (secondaryZygoteState.matches(abi)) { return secondaryZygoteState; } } } catch (IOException ioe) { throw new ZygoteStartFailedEx("Error connecting to zygote", ioe); } throw new ZygoteStartFailedEx("Unsupported zygote ABI: " + abi); } private void attemptConnectionToPrimaryZygote() throws IOException { if (primaryZygoteState == null || primaryZygoteState.isClosed()) { primaryZygoteState = ZygoteState.connect(mZygoteSocketAddress, mUsapPoolSocketAddress); maybeSetApiDenylistExemptions(primaryZygoteState, false); maybeSetHiddenApiAccessLogSampleRate(primaryZygoteState); } } </pre></td></tr></tbody></table></code></pre></div></div> 如果没有打开 zygote 进程的套接字，则尝试开启并建立连接。下面看下 <code class="language-plaintext highlighter-rouge">ZygoteState</code> 类的静态方法 <code class="language-plaintext highlighter-rouge">connect</code>。 <blockquote> frameworks/base/core/java/android/os/ZygoteProcess.java </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 </pre></td><td class="rouge-code"><pre>/** * Create a new ZygoteState object by connecting to the given Zygote socket and saving the * given USAP socket address. * * @param zygoteSocketAddress Zygote socket to connect to * @param usapSocketAddress USAP socket address to save for later * @return A new ZygoteState object containing a session socket for the given Zygote socket * address * @throws IOException */ static ZygoteState connect(@NonNull LocalSocketAddress zygoteSocketAddress, @Nullable LocalSocketAddress usapSocketAddress) throws IOException { DataInputStream zygoteInputStream; BufferedWriter zygoteOutputWriter; final LocalSocket zygoteSessionSocket = new LocalSocket(); if (zygoteSocketAddress == null) { throw new IllegalArgumentException("zygoteSocketAddress can't be null"); } try { zygoteSessionSocket.connect(zygoteSocketAddress); zygoteInputStream = new DataInputStream(zygoteSessionSocket.getInputStream()); zygoteOutputWriter = new BufferedWriter( new OutputStreamWriter(zygoteSessionSocket.getOutputStream()), Zygote.SOCKET_BUFFER_SIZE); } catch (IOException ex) { try { zygoteSessionSocket.close(); } catch (IOException ignore) { } throw ex; } return new ZygoteState(zygoteSocketAddress, usapSocketAddress, zygoteSessionSocket, zygoteInputStream, zygoteOutputWriter, getAbiList(zygoteOutputWriter, zygoteInputStream)); } </pre></td></tr></tbody></table></code></pre></div></div> <code class="language-plaintext highlighter-rouge">ZygoteState</code> 类哟用于表示与 Zygote 进程通信的状态。假如传递给 connect 方法的实参是 <code class="language-plaintext highlighter-rouge">ZYGOTE_SOCKET</code>（即”zygote”），这代表要连接的远程地址。该方法中首先创建一个 <code class="language-plaintext highlighter-rouge">LocalSocket</code> 对象，接着调用其 <code class="language-plaintext highlighter-rouge">connect</code> 方法，连接成功之后，就可以得到套接字的输入和输出流，并将输入流其封装成 <code class="language-plaintext highlighter-rouge">DataInputStream</code> 对象，然后将输出流封装成 <code class="language-plaintext highlighter-rouge">BufferedWriter</code> 对象。接着就可以通过 <code class="language-plaintext highlighter-rouge">DataInputStream</code> 对象获得 Zygote 进程发送过来的消息，而通过 <code class="language-plaintext highlighter-rouge">BufferedWriter</code> 对象发送消息给 Zygote 进程。 那么问题来了，我们只知道了 socket 通信的一端，另外一端如何找到呢？其实上一篇关于<a href="https://dorck.cn/2023/04/22/android-initialization/">Android系统启动过程</a>的文章中在分析到 zygote 进程启动过程时已经提过一笔了： <blockquote> com.android.internal.os.ZygoteInit </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 </pre></td><td class="rouge-code"><pre>public static void main(String[] argv) { ZygoteServer zygoteServer = null; Runnable caller; try { String zygoteSocketName = "zygote"; ... Log.i(TAG, "Accepting command socket connections"); // The select loop returns early in the child process after a fork and // loops forever in the zygote. caller = zygoteServer.runSelectLoop(abiList); } catch (Throwable ex) { Log.e(TAG, "System zygote died with fatal exception", ex); throw ex; } finally { if (zygoteServer != null) { zygoteServer.closeServerSocket(); } } // We're in the child process and have exited the select loop. Proceed to execute the // command. if (caller != null) { caller.run(); } } </pre></td></tr></tbody></table></code></pre></div></div> zygote 进程通过 <code class="language-plaintext highlighter-rouge">ZygoteServer#runSelectLoop</code> 来循环监听其他进程的 Socket 连接： <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 </pre></td><td class="rouge-code"><pre> Runnable runSelectLoop(String abiList) { ArrayList<FileDescriptor> socketFDs = new ArrayList<>(); ArrayList<ZygoteConnection> peers = new ArrayList<>(); // sServerSocket是socket通信中的服务端，即zygote进程，保存到fds[0] socketFDs.add(mZygoteSocket.getFileDescriptor()); peers.add(null); mUsapPoolRefillTriggerTimestamp = INVALID_TIMESTAMP; while (true) { ... StructPollfd[] pollFDs; // Allocate enough space for the poll structs, taking into account // the state of the USAP pool for this Zygote (could be a // regular Zygote, a WebView Zygote, or an AppZygote). if (mUsapPoolEnabled) { usapPipeFDs = Zygote.getUsapPipeFDs(); pollFDs = new StructPollfd[socketFDs.size() + 1 + usapPipeFDs.length]; } else { pollFDs = new StructPollfd[socketFDs.size()]; } /* * For reasons of correctness the USAP pool pipe and event FDs * must be processed before the session and server sockets. This * is to ensure that the USAP pool accounting information is * accurate when handling other requests like API deny list * exemptions. */ int pollIndex = 0; for (FileDescriptor socketFD : socketFDs) { pollFDs[pollIndex] = new StructPollfd(); pollFDs[pollIndex].fd = socketFD; pollFDs[pollIndex].events = (short) POLLIN; ++pollIndex; } final int usapPoolEventFDIndex = pollIndex; if (mUsapPoolEnabled) { pollFDs[pollIndex] = new StructPollfd(); pollFDs[pollIndex].fd = mUsapPoolEventFD; pollFDs[pollIndex].events = (short) POLLIN; ++pollIndex; // The usapPipeFDs array will always be filled in if the USAP Pool is enabled. assert usapPipeFDs != null; for (int usapPipeFD : usapPipeFDs) { FileDescriptor managedFd = new FileDescriptor(); managedFd.setInt$(usapPipeFD); pollFDs[pollIndex] = new StructPollfd(); pollFDs[pollIndex].fd = managedFd; pollFDs[pollIndex].events = (short) POLLIN; ++pollIndex; } } int pollTimeoutMs; ... int pollReturnValue; try { // 处理轮询状态，当pollFds有事件到来则往下执行，否则阻塞在这里 pollReturnValue = Os.poll(pollFDs, pollTimeoutMs); } catch (ErrnoException ex) { throw new RuntimeException("poll failed", ex); } if (pollReturnValue == 0) { // The poll returned zero results either when the timeout value has been exceeded // or when a non-blocking poll is issued and no FDs are ready. In either case it // is time to refill the pool. This will result in a duplicate assignment when // the non-blocking poll returns zero results, but it avoids an additional // conditional in the else branch. mUsapPoolRefillTriggerTimestamp = INVALID_TIMESTAMP; mUsapPoolRefillAction = UsapPoolRefillAction.DELAYED; } else { boolean usapPoolFDRead = false; while (--pollIndex >= 0) { // 采用I/O多路复用机制，当接收到客户端发出连接请求或者数据处理请求到来，则往下执行； // 否则进入continue，跳出本次循环。 if ((pollFDs[pollIndex].revents & POLLIN) == 0) { continue; } if (pollIndex == 0) { // 即fds[0]，代表的是sServerSocket，则意味着有客户端连接请求； // 则创建ZygoteConnection对象,并添加到fds。 ZygoteConnection newPeer = acceptCommandPeer(abiList); peers.add(newPeer); socketFDs.add(newPeer.getFileDescriptor()); } else if (pollIndex < usapPoolEventFDIndex) { // 从Zygote服务器套接字接受会话套接字 try { ZygoteConnection connection = peers.get(pollIndex); boolean multipleForksOK = !isUsapPoolEnabled() && ZygoteHooks.isIndefiniteThreadSuspensionSafe(); final Runnable command = connection.processCommand(this, multipleForksOK); ... } catch (Exception e) { ... } finally { // Reset the child flag, in the event that the child process is a child- // zygote. The flag will not be consulted this loop pass after the // Runnable is returned. mIsForkChild = false; } } else { ... } } ... } ... } } </pre></td></tr></tbody></table></code></pre></div></div> <code class="language-plaintext highlighter-rouge">mUsapPoolEnabled</code> 标识是否开启 USAP 机制。从Android Q(10)开始，Google 引入了一种新的机制：USAP(Unspecialized App Process)。通过 prefork 的方式提前创建好一批进程，当有应用启动时，直接将已经创建好的进程分配给它，从而省去了 fork 的动作，因此可以提升性能。后面将会有专门篇幅来研究 USAP 机制的运行原理，本文暂不做详细介绍。 其实，最终 ZygoteServer 会接收到来自 system_server 进程 AMS 创建新应用进程的消息，并通过 <code class="language-plaintext highlighter-rouge">ZygoteConnection#processCommand</code> 来处理并创建新进程： <blockquote> frameworks/base/core/java/com/android/internal/os/ZygoteConnection.java </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 </pre></td><td class="rouge-code"><pre>/** * Reads a command from the command socket. If a child is successfully forked, a * {@code Runnable} that calls the childs main method (or equivalent) is returned in the child * process. {@code null} is always returned in the parent process (the zygote). * If multipleOK is set, we may keep processing additional fork commands before returning. * * If the client closes the socket, an {@code EOF} condition is set, which callers can test * for by calling {@code ZygoteConnection.isClosedByPeer}. */ Runnable processCommand(ZygoteServer zygoteServer, boolean multipleOK) { ZygoteArguments parsedArgs; try (ZygoteCommandBuffer argBuffer = new ZygoteCommandBuffer(mSocket)) { while (true) { ... int pid; FileDescriptor childPipeFd = null; FileDescriptor serverPipeFd = null; ... if (canPreloadApp() && parsedArgs.mPreloadApp != null) { byte[] rawParcelData = Base64.getDecoder().decode(parsedArgs.mPreloadApp); Parcel appInfoParcel = Parcel.obtain(); appInfoParcel.unmarshall(rawParcelData, 0, rawParcelData.length); appInfoParcel.setDataPosition(0); ApplicationInfo appInfo = ApplicationInfo.CREATOR.createFromParcel(appInfoParcel); appInfoParcel.recycle(); if (appInfo != null) { handlePreloadApp(appInfo); } else { throw new IllegalArgumentException("Failed to deserialize --preload-app"); } return null; } ... if (parsedArgs.mInvokeWith != null || parsedArgs.mStartChildZygote || !multipleOK || peer.getUid() != Process.SYSTEM_UID) { // Continue using old code for now. TODO: Handle these cases in the other path. pid = Zygote.forkAndSpecialize(parsedArgs.mUid, parsedArgs.mGid, parsedArgs.mGids, parsedArgs.mRuntimeFlags, rlimits, parsedArgs.mMountExternal, parsedArgs.mSeInfo, parsedArgs.mNiceName, fdsToClose, fdsToIgnore, parsedArgs.mStartChildZygote, parsedArgs.mInstructionSet, parsedArgs.mAppDataDir, parsedArgs.mIsTopApp, parsedArgs.mPkgDataInfoList, parsedArgs.mAllowlistedDataInfoList, parsedArgs.mBindMountAppDataDirs, parsedArgs.mBindMountAppStorageDirs); try { if (pid == 0) { // in child zygoteServer.setForkChild(); zygoteServer.closeServerSocket(); IoUtils.closeQuietly(serverPipeFd); serverPipeFd = null; return handleChildProc(parsedArgs, childPipeFd, parsedArgs.mStartChildZygote); } else { // In the parent. A pid < 0 indicates a failure and will be handled in // handleParentProc. IoUtils.closeQuietly(childPipeFd); childPipeFd = null; handleParentProc(pid, serverPipeFd); return null; } } finally { IoUtils.closeQuietly(childPipeFd); IoUtils.closeQuietly(serverPipeFd); } } else { ZygoteHooks.preFork(); Runnable result = Zygote.forkSimpleApps(argBuffer, zygoteServer.getZygoteSocketFileDescriptor(), peer.getUid(), Zygote.minChildUid(peer), parsedArgs.mNiceName); if (result == null) { // parent; we finished some number of forks. Result is Boolean. // We already did the equivalent of handleParentProc(). ZygoteHooks.postForkCommon(); // argBuffer contains a command not understood by forksimpleApps. continue; } else { // child; result is a Runnable. zygoteServer.setForkChild(); Zygote.setAppProcessName(parsedArgs, TAG); // ??? Necessary? return result; } } } } ... } </pre></td></tr></tbody></table></code></pre></div></div> 首先调用 ZygoteArguments 得到客户端发来的启动进程参数，接着进行权限检查，然后调用 <code class="language-plaintext highlighter-rouge">forkAndSpecialize</code> 创建新进程（native 层通过 fork() 来克隆出新进程，此时 native 层的进程其实相当于已经生成了），返回 pid 若为 0，则开始调用 <code class="language-plaintext highlighter-rouge">handleChildProc</code> 来处理子进程；如果返回 pid > 0，则开始调用 <code class="language-plaintext highlighter-rouge">handleParentProc</code> 来处理父进程。注意，这里并不是简单的 if-else 关系，调用 forkAndSpecialize 之后其实会返回两次，一次返回到父进程，另一次返回到新启动的子进程。至于为什么会返回两次，这里先埋下一个彩蛋，后续文章会填坑。接下来我们来继续看下如果返回的 pid 是 0，即在子进程返回的情况下，handleChildProc 做了些什么： <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 </pre></td><td class="rouge-code"><pre>private Runnable handleChildProc(ZygoteArguments parsedArgs, FileDescriptor pipeFd, boolean isZygote) { /* * By the time we get here, the native code has closed the two actual Zygote * socket connections, and substituted /dev/null in their place. The LocalSocket * objects still need to be closed properly. */ closeSocket(); Zygote.setAppProcessName(parsedArgs, TAG); // End of the postFork event. Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER); if (parsedArgs.mInvokeWith != null) { WrapperInit.execApplication(parsedArgs.mInvokeWith, parsedArgs.mNiceName, parsedArgs.mTargetSdkVersion, VMRuntime.getCurrentInstructionSet(), pipeFd, parsedArgs.mRemainingArgs); // Should not get here. throw new IllegalStateException("WrapperInit.execApplication unexpectedly returned"); } else { if (!isZygote) { return ZygoteInit.zygoteInit(parsedArgs.mTargetSdkVersion, parsedArgs.mDisabledCompatChanges, parsedArgs.mRemainingArgs, null /* classLoader */); } else { return ZygoteInit.childZygoteInit( parsedArgs.mRemainingArgs /* classLoader */); } } } </pre></td></tr></tbody></table></code></pre></div></div> 由于我们创建的是应用进程，所以上方代码显然会执行到 <code class="language-plaintext highlighter-rouge">ZygoteInit.childZygoteInit</code>： <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 </pre></td><td class="rouge-code"><pre>/** * The main function called when starting a child zygote process. This is used as an alternative * to zygoteInit(), which skips calling into initialization routines that start the Binder * threadpool. */ static Runnable childZygoteInit(String[] argv) { RuntimeInit.Arguments args = new RuntimeInit.Arguments(argv); return RuntimeInit.findStaticMain(args.startClass, args.startArgs, /* classLoader= */null); } /** * Invokes a static "main(argv[]) method on class "className". * Converts various failing exceptions into RuntimeExceptions, with * the assumption that they will then cause the VM instance to exit. * * @param className Fully-qualified class name * @param argv Argument vector for main() * @param classLoader the classLoader to load {@className} with */ protected static Runnable findStaticMain(String className, String[] argv, ClassLoader classLoader) { Class<?> cl; try { cl = Class.forName(className, true, classLoader); } catch (ClassNotFoundException ex) { throw new RuntimeException( "Missing class when invoking static main " + className, ex); } Method m; try { m = cl.getMethod("main", new Class[] { String[].class }); } catch (NoSuchMethodException ex) { throw new RuntimeException( "Missing static main on " + className, ex); } catch (SecurityException ex) { throw new RuntimeException( "Problem getting static main on " + className, ex); } int modifiers = m.getModifiers(); if (! (Modifier.isStatic(modifiers) && Modifier.isPublic(modifiers))) { throw new RuntimeException( "Main method is not public and static on " + className); } /* * This throw gets caught in ZygoteInit.main(), which responds * by invoking the exception's run() method. This arrangement * clears up all the stack frames that were required in setting * up the process. */ return new MethodAndArgsCaller(m, argv); } </pre></td></tr></tbody></table></code></pre></div></div> 由上述代码可知，最终会通过反射的方式来为之前传递进来的 <code class="language-plaintext highlighter-rouge">processClass</code> 创建实例对象，根据上面流程的分析，这里的 processClass 显然是 <code class="language-plaintext highlighter-rouge">android.app.ActivityThread</code> 这个类，接着调用该类的 <code class="language-plaintext highlighter-rouge">main</code> 方法： <blockquote> frameworks/base/core/java/android/app/ActivityThread.java </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 </pre></td><td class="rouge-code"><pre>public static void main(String[] args) { Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "ActivityThreadMain"); // Install selective syscall interception AndroidOs.install(); ... Looper.prepareMainLooper(); ... ActivityThread thread = new ActivityThread(); thread.attach(false, startSeq); if (sMainThreadHandler == null) { sMainThreadHandler = thread.getHandler(); } // End of event ActivityThreadMain. Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER); Looper.loop(); throw new RuntimeException("Main thread loop unexpectedly exited"); } </pre></td></tr></tbody></table></code></pre></div></div> ActivityThread 的 <code class="language-plaintext highlighter-rouge">main</code> 中准备一个主线程的 Looper 并初始化消息队列，并创建一个 ActivityThread 实例，执行 <code class="language-plaintext highlighter-rouge">attach</code> 方法创建 Application 和绑定生命周期，最后开启主线程的消息循环。我们重点看下 attach 方法： <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 </pre></td><td class="rouge-code"><pre>private void attach(boolean system, long startSeq) { sCurrentActivityThread = this; mConfigurationController = new ConfigurationController(this); mSystemThread = system; // 此处 system 为 false if (!system) { android.ddm.DdmHandleAppName.setAppName("<pre-initialized>", UserHandle.myUserId()); RuntimeInit.setApplicationObject(mAppThread.asBinder()); final IActivityManager mgr = ActivityManager.getService(); try { mgr.attachApplication(mAppThread, startSeq); } catch (RemoteException ex) { throw ex.rethrowFromSystemServer(); } ... } else { ... } ... } </pre></td></tr></tbody></table></code></pre></div></div> attach 中执行了 IActivityManager 的 <code class="language-plaintext highlighter-rouge">attachApplication</code> 方法，而 IActivityManager 其实是一个 Binder 接口，这里通过 ActivityManager.getService 获取它的代理服务 AMS，进而调用 <code class="language-plaintext highlighter-rouge">attachApplication</code> 来将 ActivityThread 内部类 ApplicationThread 绑定到 AMS，这样就可以通过 Binder IPC 间接控制应用进程了： <blockquote> frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 </pre></td><td class="rouge-code"><pre>@Override public final void attachApplication(IApplicationThread thread, long startSeq) { if (thread == null) { throw new SecurityException("Invalid application interface"); } synchronized (this) { int callingPid = Binder.getCallingPid(); final int callingUid = Binder.getCallingUid(); final long origId = Binder.clearCallingIdentity(); attachApplicationLocked(thread, callingPid, callingUid, startSeq); Binder.restoreCallingIdentity(origId); } } private boolean attachApplicationLocked(@NonNull IApplicationThread thread, int pid, int callingUid, long startSeq) { // Find the application record that is being attached... either via // the pid if we are running in multiple processes, or just pull the // next app record if we are emulating process with anonymous threads. ProcessRecord app; long startTime = SystemClock.uptimeMillis(); long bindApplicationTimeMillis; if (pid != MY_PID && pid >= 0) { synchronized (mPidsSelfLocked) { app = mPidsSelfLocked.get(pid); } if (app != null && (app.getStartUid() != callingUid || app.getStartSeq() != startSeq)) { ... // If there is already an app occupying that pid that hasn't been cleaned up cleanUpApplicationRecordLocked(app, pid, false, false, -1, true /*replacingPid*/, false /* fromBinderDied */); removePidLocked(pid, app); app = null; } } else { app = null; } ... try { ... ApplicationInfo appInfo = instr != null ? instr.mTargetInfo : app.info; app.setCompat(compatibilityInfoForPackage(appInfo)); if (app.getIsolatedEntryPoint() != null) { // This is an isolated process which should just call an entry point instead of // being bound to an application. thread.runIsolatedEntryPoint( app.getIsolatedEntryPoint(), app.getIsolatedEntryPointArgs()); } else if (instr2 != null) { ... } else { thread.bindApplication(processName, appInfo, app.sdkSandboxClientAppVolumeUuid, app.sdkSandboxClientAppPackage, providerList, null, profilerInfo, null, null, null, testMode, mBinderTransactionTrackingEnabled, enableTrackAllocation, isRestrictedBackupMode || !normalMode, app.isPersistent(), new Configuration(app.getWindowProcessController().getConfiguration()), app.getCompat(), getCommonServicesLocked(app.isolated), mCoreSettingsObserver.getCoreSettingsLocked(), buildSerial, autofillOptions, contentCaptureOptions, app.getDisabledCompatChanges(), serializedSystemFontMap, app.getStartElapsedTime(), app.getStartUptime()); } ... // Make app active after binding application or client may be running requests (e.g // starting activities) before it is ready. synchronized (mProcLock) { app.makeActive(thread, mProcessStats); checkTime(startTime, "attachApplicationLocked: immediately after bindApplication"); } ... } catch (Exception e) { ... } boolean didSomething = false; // See if the top visible activity is waiting to run in this process... if (normalMode) { try { didSomething = mAtmInternal.attachApplication(app.getWindowProcessController()); } catch (Exception e) { Slog.wtf(TAG, "Exception thrown launching activities in " + app, e); badApp = true; } } ... return true; } </pre></td></tr></tbody></table></code></pre></div></div> ApplicationThread 作为 ActivityThread 的内部类，它是 <code class="language-plaintext highlighter-rouge">IApplicationThread</code> 这个 Binder 接口的最终实现类，即 ApplicationThread 内部实现了一套 AIDL 接口，这个接口与 Application 的创建、Activity 及 Service 等四大组件启动等息息相关。最终调用 <code class="language-plaintext highlighter-rouge">IApplicationThread</code> 的 <code class="language-plaintext highlighter-rouge">bindApplication</code> 方法： <blockquote> frameworks/base/core/java/android/app/ActivityThread.java#ApplicationThread </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 </pre></td><td class="rouge-code"><pre>@Override public final void bindApplication(String processName, ApplicationInfo appInfo, String sdkSandboxClientAppVolumeUuid, String sdkSandboxClientAppPackage, ProviderInfoList providerList, ComponentName instrumentationName, ProfilerInfo profilerInfo, Bundle instrumentationArgs, IInstrumentationWatcher instrumentationWatcher, IUiAutomationConnection instrumentationUiConnection, int debugMode, boolean enableBinderTracking, boolean trackAllocation, boolean isRestrictedBackupMode, boolean persistent, Configuration config, CompatibilityInfo compatInfo, Map services, Bundle coreSettings, String buildSerial, AutofillOptions autofillOptions, ContentCaptureOptions contentCaptureOptions, long[] disabledCompatChanges, SharedMemory serializedSystemFontMap, long startRequestedElapsedTime, long startRequestedUptime) { ... AppBindData data = new AppBindData(); data.processName = processName; data.appInfo = appInfo; data.sdkSandboxClientAppVolumeUuid = sdkSandboxClientAppVolumeUuid; data.sdkSandboxClientAppPackage = sdkSandboxClientAppPackage; data.providers = providerList.getList(); data.instrumentationName = instrumentationName; data.instrumentationArgs = instrumentationArgs; data.instrumentationWatcher = instrumentationWatcher; data.instrumentationUiAutomationConnection = instrumentationUiConnection; data.debugMode = debugMode; data.enableBinderTracking = enableBinderTracking; data.trackAllocation = trackAllocation; data.restrictedBackupMode = isRestrictedBackupMode; data.persistent = persistent; data.config = config; data.compatInfo = compatInfo; data.initProfilerInfo = profilerInfo; data.buildSerial = buildSerial; data.autofillOptions = autofillOptions; data.contentCaptureOptions = contentCaptureOptions; data.disabledCompatChanges = disabledCompatChanges; data.mSerializedSystemFontMap = serializedSystemFontMap; data.startRequestedElapsedTime = startRequestedElapsedTime; data.startRequestedUptime = startRequestedUptime; sendMessage(H.BIND_APPLICATION, data); } </pre></td></tr></tbody></table></code></pre></div></div> 上面代码通过一个 Handler 实例发送 <code class="language-plaintext highlighter-rouge">H.BIND_APPLICATION</code> 消息，意味着需要构建和绑定 Application 对象。这个 Handler 同样是 ActivityThread 的内部类： <blockquote> frameworks/base/core/java/android/app/ActivityThread.java#H </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 </pre></td><td class="rouge-code"><pre>class H extends Handler { public static final int BIND_APPLICATION = 110; ... public void handleMessage(Message msg) { if (DEBUG_MESSAGES) Slog.v(TAG, ">>> handling: " + codeToString(msg.what)); switch (msg.what) { case BIND_APPLICATION: Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "bindApplication"); AppBindData data = (AppBindData)msg.obj; handleBindApplication(data); Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER); break; case EXIT_APPLICATION: if (mInitialApplication != null) { mInitialApplication.onTerminate(); } Looper.myLooper().quit(); break; } Object obj = msg.obj; if (obj instanceof SomeArgs) { ((SomeArgs) obj).recycle(); } if (DEBUG_MESSAGES) Slog.v(TAG, "<<< done: " + codeToString(msg.what)); } } </pre></td></tr></tbody></table></code></pre></div></div> 通过跨进程通信，Application 的创建和绑定最终回到了主线程： <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 </pre></td><td class="rouge-code"><pre>private void handleBindApplication(AppBindData data) { ... // Instrumentation info affects the class loader, so load it before // setting up the app context. final InstrumentationInfo ii; if (data.instrumentationName != null) { ii = prepareInstrumentation(data); } else { ii = null; } final ContextImpl appContext = ContextImpl.createAppContext(this, data.info); mConfigurationController.updateLocaleListFromAppContext(appContext); ... // Continue loading instrumentation. if (ii != null) { initInstrumentation(ii, data, appContext); } else { mInstrumentation = new Instrumentation(); mInstrumentation.basicInit(this); } // Allow disk access during application and provider setup. This could // block processing ordered broadcasts, but later processing would // probably end up doing the same disk access. Application app; final StrictMode.ThreadPolicy savedPolicy = StrictMode.allowThreadDiskWrites(); final StrictMode.ThreadPolicy writesAllowedPolicy = StrictMode.getThreadPolicy(); try { // If the app is being launched for full backup or restore, bring it up in // a restricted environment with the base application class. app = data.info.makeApplicationInner(data.restrictedBackupMode, null); ... mInitialApplication = app; ... try { mInstrumentation.callApplicationOnCreate(app); } catch (Exception e) { if (!mInstrumentation.onException(app, e)) { throw new RuntimeException( "Unable to create application " + app.getClass().getName() + ": " + e.toString(), e); } } } finally { ... } ... } </pre></td></tr></tbody></table></code></pre></div></div> 最终通过 LoadedApk 中的 <code class="language-plaintext highlighter-rouge">makeApplication</code> 方法来尝试创建 Application 对象并执行它的 <code class="language-plaintext highlighter-rouge">onCreate</code> 生命周期方法： <blockquote> frameworks/base/core/java/android/app/LoadedApk.java </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 </pre></td><td class="rouge-code"><pre>public Application makeApplicationInner(boolean forceDefaultAppClass, Instrumentation instrumentation) { return makeApplicationInner(forceDefaultAppClass, instrumentation, /* allowDuplicateInstances= */ false); } private Application makeApplicationInner(boolean forceDefaultAppClass, Instrumentation instrumentation, boolean allowDuplicateInstances) { if (mApplication != null) { return mApplication; } Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "makeApplication"); ... Application app = null; final String myProcessName = Process.myProcessName(); String appClass = mApplicationInfo.getCustomApplicationClassNameForProcess( myProcessName); if (forceDefaultAppClass || (appClass == null)) { appClass = "android.app.Application"; } try { ... ContextImpl appContext = ContextImpl.createAppContext(mActivityThread, this); // The network security config needs to be aware of multiple // applications in the same process to handle discrepancies NetworkSecurityConfigProvider.handleNewApplication(appContext); app = mActivityThread.mInstrumentation.newApplication( cl, appClass, appContext); appContext.setOuterContext(app); } catch (Exception e) { ... } mActivityThread.mAllApplications.add(app); mApplication = app; ... if (instrumentation != null) { try { instrumentation.callApplicationOnCreate(app); } catch (Exception e) { ... } } Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER); return app; } </pre></td></tr></tbody></table></code></pre></div></div> 如果 Application 对象依然存在则直接返回当前对象，否则会通过 Instrumentation(ActivityThread中的成员变量 mInstrumentation，而非参数传递进来的) 来新建一个 Application： <blockquote> frameworks/base/core/java/android/app/Instrumentation.java </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 </pre></td><td class="rouge-code"><pre>public Application newApplication(ClassLoader cl, String className, Context context) throws InstantiationException, IllegalAccessException, ClassNotFoundException { Application app = getFactory(context.getPackageName()) .instantiateApplication(cl, className); app.attach(context); return app; } public @NonNull Application instantiateApplication(@NonNull ClassLoader cl, @NonNull String className) throws InstantiationException, IllegalAccessException, ClassNotFoundException { return (Application) cl.loadClass(className).newInstance(); } </pre></td></tr></tbody></table></code></pre></div></div> 可以看到，最终是通过反射生成一个全新的 Application 对象并返回给上层，并执行了它的 <code class="language-plaintext highlighter-rouge">onCreate</code> 方法。至此，Application 创建并启动完毕。 <h3 id="继续启动-activity">继续启动 Activity</h3> 仔细想一下，之前我们分析 Launcher 进程创建过程中的时候，它会提前创建一个 ActivityRecord 对象并置于栈顶，如果当前进程已创建，则直接执行 realStartActivityLocked 来真正启动一个 Activity；如果进程还没有创建，则先创建进程。我们上面分析了一大通不也正是研究了进程还没有创建的情况吗。既然我们后来创建了一个新的 Application，那是不是应该继续之前未完成的使命呢？也就是将先前打断的 Activity 启动的工作继续执行起来。Android 系统不可能连这个问题都考虑不到对吧，所以 Application 创建完毕后应该会继续执行启动 Activity 的逻辑！ 我们回到之前的 ActivityManagerService 中查看 <code class="language-plaintext highlighter-rouge">attachApplicationLocked</code>： <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 </pre></td><td class="rouge-code"><pre>private boolean attachApplicationLocked(@NonNull IApplicationThread thread, int pid, int callingUid, long startSeq) { ... try { ... ApplicationInfo appInfo = instr != null ? instr.mTargetInfo : app.info; app.setCompat(compatibilityInfoForPackage(appInfo)); if (app.getIsolatedEntryPoint() != null) { // This is an isolated process which should just call an entry point instead of // being bound to an application. thread.runIsolatedEntryPoint( app.getIsolatedEntryPoint(), app.getIsolatedEntryPointArgs()); } else if (instr2 != null) { ... } else { thread.bindApplication(processName, appInfo, app.sdkSandboxClientAppVolumeUuid, app.sdkSandboxClientAppPackage, providerList, null, profilerInfo, null, null, null, testMode, mBinderTransactionTrackingEnabled, enableTrackAllocation, isRestrictedBackupMode || !normalMode, app.isPersistent(), new Configuration(app.getWindowProcessController().getConfiguration()), app.getCompat(), getCommonServicesLocked(app.isolated), mCoreSettingsObserver.getCoreSettingsLocked(), buildSerial, autofillOptions, contentCaptureOptions, app.getDisabledCompatChanges(), serializedSystemFontMap, app.getStartElapsedTime(), app.getStartUptime()); } ... // Make app active after binding application or client may be running requests (e.g // starting activities) before it is ready. synchronized (mProcLock) { app.makeActive(thread, mProcessStats); checkTime(startTime, "attachApplicationLocked: immediately after bindApplication"); } ... } catch (Exception e) { ... } boolean didSomething = false; // See if the top visible activity is waiting to run in this process... if (normalMode) { try { didSomething = mAtmInternal.attachApplication(app.getWindowProcessController()); } catch (Exception e) { Slog.wtf(TAG, "Exception thrown launching activities in " + app, e); badApp = true; } } // Find any services that should be running in this process... if (!badApp) { try { didSomething |= mServices.attachApplicationLocked(app, processName); checkTime(startTime, "attachApplicationLocked: after mServices.attachApplicationLocked"); } catch (Exception e) { Slog.wtf(TAG, "Exception thrown starting services in " + app, e); badApp = true; } } ... return true; } </pre></td></tr></tbody></table></code></pre></div></div> 可以看到，在成功创建和绑定 Application 之后，又继续执行了<code class="language-plaintext highlighter-rouge">ActivityTaskManagerInternal#attachApplication</code>，它又做了什么事情呢？： <blockquote> frameworks/base/services/core/java/com/android/server/wm/ActivityTaskManagerService.java </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 </pre></td><td class="rouge-code"><pre>public boolean attachApplication(WindowProcessController wpc) throws RemoteException { synchronized (mGlobalLockWithoutBoost) { if (Trace.isTagEnabled(TRACE_TAG_WINDOW_MANAGER)) { Trace.traceBegin(TRACE_TAG_WINDOW_MANAGER, "attachApplication:" + wpc.mName); } try { return mRootWindowContainer.attachApplication(wpc); } finally { Trace.traceEnd(TRACE_TAG_WINDOW_MANAGER); } } } </pre></td></tr></tbody></table></code></pre></div></div> 继续跟进到 <code class="language-plaintext highlighter-rouge">RootWindowContainer#attachApplication</code>： <blockquote> frameworks/base/services/core/java/com/android/server/wm/RootWindowContainer.java </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 </pre></td><td class="rouge-code"><pre>boolean attachApplication(WindowProcessController app) throws RemoteException { try { return mAttachApplicationHelper.process(app); } finally { mAttachApplicationHelper.reset(); } } boolean process(WindowProcessController app) throws RemoteException { mApp = app; for (int displayNdx = getChildCount() - 1; displayNdx >= 0; --displayNdx) { getChildAt(displayNdx).forAllRootTasks(this); if (mRemoteException != null) { throw mRemoteException; } } if (!mHasActivityStarted) { ensureActivitiesVisible(null /* starting */, 0 /* configChanges */, false /* preserveWindows */); } return mHasActivityStarted; } void ensureActivitiesVisible(ActivityRecord starting, int configChanges, boolean preserveWindows, boolean notifyClients) { if (mTaskSupervisor.inActivityVisibilityUpdate() || mTaskSupervisor.isRootVisibilityUpdateDeferred()) { // Don't do recursive work. return; } try { mTaskSupervisor.beginActivityVisibilityUpdate(); // First the front root tasks. In case any are not fullscreen and are in front of home. for (int displayNdx = getChildCount() - 1; displayNdx >= 0; --displayNdx) { final DisplayContent display = getChildAt(displayNdx); display.ensureActivitiesVisible(starting, configChanges, preserveWindows, notifyClients); } } finally { mTaskSupervisor.endActivityVisibilityUpdate(); } } </pre></td></tr></tbody></table></code></pre></div></div> 这里是查找 Activity 栈是否存在需要被启动的 Activity，继续跟进 <code class="language-plaintext highlighter-rouge">DisplayContent#ensureActivitiesVisible</code>： <blockquote> frameworks/base/services/core/java/com/android/server/wm/DisplayContent.java </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 </pre></td><td class="rouge-code"><pre>void ensureActivitiesVisible(ActivityRecord starting, int configChanges, boolean preserveWindows, boolean notifyClients) { if (mInEnsureActivitiesVisible) { // Don't do recursive work. return; } mInEnsureActivitiesVisible = true; mAtmService.mTaskSupervisor.beginActivityVisibilityUpdate(); try { forAllRootTasks(rootTask -> { rootTask.ensureActivitiesVisible(starting, configChanges, preserveWindows, notifyClients); }); if (mTransitionController.useShellTransitionsRotation() && mTransitionController.isCollecting() && mWallpaperController.getWallpaperTarget() != null) { // Also update wallpapers so that their requestedVisibility immediately reflects // the changes to activity visibility. // TODO(b/206005136): Move visibleRequested logic up to WindowToken. mWallpaperController.adjustWallpaperWindows(); } } finally { mAtmService.mTaskSupervisor.endActivityVisibilityUpdate(); mInEnsureActivitiesVisible = false; } } </pre></td></tr></tbody></table></code></pre></div></div> 接着跟进 <code class="language-plaintext highlighter-rouge">Task#ensureActivitiesVisible</code>： <blockquote> frameworks/base/services/core/java/com/android/server/wm/Task.java </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 </pre></td><td class="rouge-code"><pre>/** * Make sure that all activities that need to be visible in the root task (that is, they * currently can be seen by the user) actually are and update their configuration. * @param starting The top most activity in the task. * The activity is either starting or resuming. * Caller should ensure starting activity is visible. * @param preserveWindows Flag indicating whether windows should be preserved when updating * configuration in {@link EnsureActivitiesVisibleHelper}. * @param configChanges Parts of the configuration that changed for this activity for evaluating * if the screen should be frozen as part of * {@link EnsureActivitiesVisibleHelper}. * */ void ensureActivitiesVisible(@Nullable ActivityRecord starting, int configChanges, boolean preserveWindows) { ensureActivitiesVisible(starting, configChanges, preserveWindows, true /* notifyClients */); } /** * Ensure visibility with an option to also update the configuration of visible activities. * @see #ensureActivitiesVisible(ActivityRecord, int, boolean) * @see RootWindowContainer#ensureActivitiesVisible(ActivityRecord, int, boolean) * @param starting The top most activity in the task. * The activity is either starting or resuming. * Caller should ensure starting activity is visible. * @param notifyClients Flag indicating whether the visibility updates should be sent to the * clients in {@link EnsureActivitiesVisibleHelper}. * @param preserveWindows Flag indicating whether windows should be preserved when updating * configuration in {@link EnsureActivitiesVisibleHelper}. * @param configChanges Parts of the configuration that changed for this activity for evaluating * if the screen should be frozen as part of * {@link EnsureActivitiesVisibleHelper}. */ // TODO: Should be re-worked based on the fact that each task as a root task in most cases. void ensureActivitiesVisible(@Nullable ActivityRecord starting, int configChanges, boolean preserveWindows, boolean notifyClients) { mTaskSupervisor.beginActivityVisibilityUpdate(); try { forAllLeafTasks(task -> { task.updateActivityVisibilities(starting, configChanges, preserveWindows, notifyClients); }, true /* traverseTopToBottom */); if (mTranslucentActivityWaiting != null && mUndrawnActivitiesBelowTopTranslucent.isEmpty()) { // Nothing is getting drawn or everything was already visible, don't wait for // timeout. notifyActivityDrawnLocked(null); } } finally { mTaskSupervisor.endActivityVisibilityUpdate(); } } final void updateActivityVisibilities(@Nullable ActivityRecord starting, int configChanges, boolean preserveWindows, boolean notifyClients) { mTaskSupervisor.beginActivityVisibilityUpdate(); try { mEnsureActivitiesVisibleHelper.process( starting, configChanges, preserveWindows, notifyClients); } finally { mTaskSupervisor.endActivityVisibilityUpdate(); } } </pre></td></tr></tbody></table></code></pre></div></div> 进入 <code class="language-plaintext highlighter-rouge">EnsureActivityVisibilities</code> ： <blockquote> frameworks/base/services/core/java/com/android/server/wm/EnsureActivitiesVisibleHelper.java </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 </pre></td><td class="rouge-code"><pre>void process(@Nullable ActivityRecord starting, int configChanges, boolean preserveWindows, boolean notifyClients) { reset(starting, configChanges, preserveWindows, notifyClients); ... // We should not resume activities that being launched behind because these // activities are actually behind other fullscreen activities, but still required // to be visible (such as performing Recents animation). final boolean resumeTopActivity = mTopRunningActivity != null && !mTopRunningActivity.mLaunchTaskBehind && mTaskFragment.canBeResumed(starting) && (starting == null || !starting.isDescendantOf(mTaskFragment)); ArrayList<TaskFragment> adjacentTaskFragments = null; for (int i = mTaskFragment.mChildren.size() - 1; i >= 0; --i) { final WindowContainer child = mTaskFragment.mChildren.get(i); final TaskFragment childTaskFragment = child.asTaskFragment(); if (childTaskFragment != null && childTaskFragment.getTopNonFinishingActivity() != null) { childTaskFragment.updateActivityVisibilities(starting, configChanges, preserveWindows, notifyClients); ... } else if (child.asActivityRecord() != null) { setActivityVisibilityState(child.asActivityRecord(), starting, resumeTopActivity); } } } private void setActivityVisibilityState(ActivityRecord r, ActivityRecord starting, final boolean resumeTopActivity) { ... if (reallyVisible) { ... if (!r.attachedToProcess()) { // 需要关联到具体的进程并启动activity makeVisibleAndRestartIfNeeded(mStarting, mConfigChanges, isTop, resumeTopActivity && isTop, r); } else if (r.isVisibleRequested()) { // If this activity is already visible, then there is nothing to do here. ... } else { r.makeVisibleIfNeeded(mStarting, mNotifyClients); } // Aggregate current change flags. mConfigChanges |= r.configChangeFlags; } else { ... r.makeInvisible(); } ... } private void makeVisibleAndRestartIfNeeded(ActivityRecord starting, int configChanges, boolean isTop, boolean andResume, ActivityRecord r) { // We need to make sure the app is running if it's the top, or it is just made visible from // invisible. If the app is already visible, it must have died while it was visible. In this // case, we'll show the dead window but will not restart the app. Otherwise we could end up // thrashing. if (!isTop && r.isVisibleRequested() && !r.isState(INITIALIZING)) { return; } // This activity needs to be visible, but isn't even running... // get it started and resume if no other root task in this root task is resumed. ... if (r != starting) { mTaskFragment.mTaskSupervisor.startSpecificActivity(r, andResume, true /* checkConfig */); } } </pre></td></tr></tbody></table></code></pre></div></div> 看到这里，我们可以大胆猜测 Activity 即使已经存在，但尚未显示，也没有关联到具体的进程。如果顶部没有其他的 Activity，我们可以尝试启动这个 Activity： <blockquote> frameworks/base/services/core/java/com/android/server/wm/ActivityTaskSupervisor.java </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 </pre></td><td class="rouge-code"><pre>void startSpecificActivity(ActivityRecord r, boolean andResume, boolean checkConfig) { // Is this activity's application already running? final WindowProcessController wpc = mService.getProcessController(r.processName, r.info.applicationInfo.uid); boolean knownToBeDead = false; if (wpc != null && wpc.hasThread()) { try { realStartActivityLocked(r, wpc, andResume, checkConfig); return; } catch (RemoteException e) { Slog.w(TAG, "Exception when starting activity " + r.intent.getComponent().flattenToShortString(), e); } // If a dead object exception was thrown -- fall through to // restart the application. knownToBeDead = true; // Remove the process record so it won't be considered as alive. mService.mProcessNames.remove(wpc.mName, wpc.mUid); mService.mProcessMap.remove(wpc.getPid()); } r.notifyUnknownVisibilityLaunchedForKeyguardTransition(); final boolean isTop = andResume && r.isTopRunningActivity(); mService.startProcessAsync(r, knownToBeDead, isTop, isTop ? HostingRecord.HOSTING_TYPE_TOP_ACTIVITY : HostingRecord.HOSTING_TYPE_ACTIVITY); } </pre></td></tr></tbody></table></code></pre></div></div> Wonderful！这代码是不是有点熟悉，没错，我们再次回到了这个分叉路口： <ul> <li>如果 Activity 的进程已经启动，则直接执行 <code class="language-plaintext highlighter-rouge">realStartActivityLocked</code> 来启动 Activity；</li> <li>如果 Activity 的进程尚未启动，那么需要先执行 <code class="language-plaintext highlighter-rouge">ActivityTaskManagerService#startProcessAsync</code> 创建进程。</li> </ul> 只不过这次我们已经拥有了一个正在运行的进程，所以这一次将会执行到 realStartActivityLocked 来启动一个 Activity。 <h3 id="总结">总结</h3> Android 中在 system_server 进程启动 Launcher 进程主要有以下几个步骤： <ol> <li>准备参数信息：AMS 执行 systemReady，接着组装 homeIntent 和 ActivityRecord。</li> <li>判断是否需要新建进程：如果当前存在进程，则直接启动 Activity，否则先创建和启动进程。</li> <li>等待创建请求：Zygote 进程会在启动后等待新的应用程序进程的创建请求。</li> <li>接收创建请求：当有新的应用程序进程的创建请求到达时，Zygote 进程会接收该请求，并根据该请求创建一个新的进程。</li> <li>复制进程：为了快速创建新的进程，Zygote 进程会通过复制自身进程并清除一些状态来创建一个新的应用程序进程。这个过程是通过使用类似于 Unix 的 fork 系统调用实现的。</li> <li>初始化应用程序进程：新的应用程序进程会继承 Zygote 进程的一些特性，例如 Java 虚拟机实例、类和资源等。Zygote 进程会对新进程进行一些初始化工作，例如为新进程设置一些系统属性、启动主线程等。</li> <li>加载应用程序代码：新的应用程序进程会在启动时加载应用程序的代码，并开始执行应用程序的入口函数。</li> <li>启动 Launcher Activity：当进程和 Application 创建完毕后，如果存在未启动的 Activity，则前往创建执行启动。</li> </ol> 关于 Activity 的启动过程将在下一章节来剖析，到时也会附上整个 APP 启动过程关键节点流程图。 <h3 id="相关面试题">相关面试题</h3> <ul> <li>应用进程的孵化过程？</li> <li>Android 创建进程时的 USAP 机制是什么？</li> <li>为什么 Android 进程的 <code class="language-plaintext highlighter-rouge">fork()</code> 会返回两次？</li> <li>Android 系统的 Activity Task 管理机制？</li> </ul> <h3 id="相关参考">相关参考</h3> <ul> <li>https://juejin.cn/post/6978743408756162590</li> <li>https://blog.csdn.net/zhuzp_blog/article/details/120894309</li> <li>https://blog.csdn.net/qq_34512207/article/details/113725772</li> </ul>

2023/5/4

回顾Java中经典的生产/消费者模型

<h3 id="概述">概述</h3> 生产者-消费者模型是 Java 并发编程中比较常见的加锁应用场景之一，以下是维基百科的对于该名词的定义： <blockquote> 生产者消费者问题（Producer-consumer problem），也称有限缓冲问题（Bounded-buffer problem），是一个<a href="https://zh.wikipedia.org/wiki/多进程">多进程</a><a href="https://zh.wikipedia.org/wiki/同步">同步</a>问题的经典案例。该问题描述了共享固定大小<a href="https://zh.wikipedia.org/wiki/缓冲区">缓冲区</a>的两个进程——即所谓的“生产者”和“消费者”——在实际运行时会发生的问题。生产者的主要作用是生成一定量的数据放到缓冲区中，然后重复此过程。与此同时，消费者也在缓冲区消耗这些数据。该问题的关键就是要保证生产者不会在缓冲区满时加入数据，消费者也不会在缓冲区中空时消耗数据。 </blockquote> <h3 id="问题分析">问题分析</h3> <img src="/img/in-post/post-android/java_producer_consumer.png" alt="java_producer_consumer" /> 结合上图及定义我们可以提取出该模型具有以下特点： <ul> <li>生产者和消费者可以同时并发运作</li> <li>缓冲区满则阻塞等待消费者消费数据</li> <li>缓冲区空则阻塞等待生产者生产数据</li> </ul> 我们知道，生产者和消费者可以同时运作，并且二者执行效率和规模也很有可能出现严重的不对等性。那么为了保证生产和消费操作的原子性和共享数据的可见性，我们需要借助一种同步机制来保障该模型的正常运行。 <h3 id="实现方式">实现方式</h3> 以下来介绍几种常见的生产-消费模型的实现方式。 <h5 id="1-synchorized--waitnotify">1. synchorized + wait/notify</h5> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 </pre></td><td class="rouge-code"><pre>public class GoodsStorageDispatcher { // 仓库容纳上限 private static final int MAX_SIZE = 100; // 仓库容纳的货物集合 private LinkedList<Good> list = new LinkedList(); public void produce(Good good) { synchronized (list) { while (list.size() == MAX_SIZE) { System.out.println("仓库已满 >> 生产暂停，等待消费"); try { list.wait(); } catch (InterruptedException e) { e.printStackTrace(); } } list.add(good); System.out.println("生产了一个新产品，现库存为：" + list.size()); list.notifyAll(); } } public void consume() { synchronized (list) { while (list.size() == 0) { System.out.println("库存已清仓 >> 消费暂停，等待生产"); try { list.wait(); } catch (InterruptedException e) { e.printStackTrace(); } } list.remove(); System.out.println("消费了一个产品，现库存为：" + list.size()); list.notifyAll(); } } } </pre></td></tr></tbody></table></code></pre></div></div> 可以看到，我们采用对象锁以及等待/唤醒的方式来实现生产和消费的同步机制。这里的 wait 和 notifyAll 在示例中含义如下： <ul> <li>wait：在缓冲区满/空的情况下先挂起生产/消费线程并释放锁，进入等待状态，让其他线程执行</li> <li>notify：当生产/消费一个商品时，通知其他等待的线程继续执行并释放锁，进入等待状态</li> </ul> 值得注意的是，produce 和 consume 方法中都使用了 while 循环来判断缓冲区的存储状态（空/满），这样处理的原因是什么呢，为何不直接用 if 呢？ 其实这里用 while 是为了防止虚假唤醒，我们结合一个例子更好理解一些： <img src="/img/in-post/post-android/fake_notify.png" alt="fake_notify" style="zoom: 67%;" /> 如上图所示，假设我们现在有 1 个生产者，3 个消费者在执行生产和消费任务，而目前缓冲区（Warehouse）仅有一个数据：A。 如果当 Consumer-1 消费了 A 后，缓冲区就为空了，Consumer-2 和 Consumer-3 从缓冲区取数据消费时就会陷入等待状态（因为 Consumer-2 消费时缓冲区为空会执行 wait 方法并释放锁，Consumer-3也会重蹈覆辙）。而此时又有一个生产者 Producer-2 生产了数据 B 并加入缓冲区，通过 notifyAll 去唤醒所有等待的消费者，假设消费者 Consumer-2 优先抢到了使用权将 B 消费后缓冲区又恢复到空空如也的状态。接下来的情况就值得注意了：消费者 Consumer-3 想终于可以消费了，然而由于使用的是 if，所以唤醒后继续执行到 <code class="language-plaintext highlighter-rouge">list.remove()</code>，毫无疑问的抛出了 IndexOutOfBoundsException，因为此时 list 为空了，这就是所谓的“虚假唤醒”。其实这里我们不能直接消费数据，而是要继续等待。因此这里使用 while 循环判断，当唤醒继续执行代码时重新进入 while 内判断缓冲区数据是否为空。 <h5 id="2-lock--condition">2. Lock + Condition</h5> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 </pre></td><td class="rouge-code"><pre>public class GoodsStorageDispatcher { // 仓库容纳上限 private static final int MAX_SIZE = 100; // 仓库容纳的货物集合 private LinkedList<Good> list = new LinkedList(); // 锁 final Lock lock = new ReentrantLock(); // 用于等待或唤醒线程（仓库满后需要等待被消费，成功消费后需要唤醒线程继续生产） final Condition notFull = lock.newCondition(); // 用于等待或唤醒线程（仓库清仓后需要等待生产，生产成功后需要唤醒线程继续消费） final Condition notEmpty = lock.newCondition(); public void produce(Good good) throws InterruptedException { lock.lock(); try { while (list.size() == MAX_SIZE) { //防止虚假唤醒，Condition的await调用一般会放在一个循环判断中 System.out.println("仓库已满 >> 生产暂停，等待消费"); notFull.await(); } list.add(good); notEmpty.signal(); } finally { lock.unlock(); } } public void consume() throws InterruptedException { lock.lock(); try { while (list.size() == 0) { System.out.println("库存已清仓 >> 消费暂停，等待生产"); notEmpty.await(); } list.remove(); notFull.signal(); } finally { lock.unlock(); } } } </pre></td></tr></tbody></table></code></pre></div></div> 通过 ReentrantLock + Condition 来替代实现上面的等待/唤醒，但无疑它的功能性更加齐全和灵活（有限等待、公平锁、读写锁分离等）。 <h5 id="3-blockingqueue">3. BlockingQueue</h5> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 </pre></td><td class="rouge-code"><pre>public class GoodsStorageDispatcher { // 仓库容纳上限 private static final int MAX_SIZE = 100; // 仓库容纳的货物集合 private LinkedBlockingQueue<Good> list = new LinkedBlockingQueue<>(MAX_SIZE); public void produce(Good good) { if (list.size() == MAX_SIZE) { System.out.println("仓库已满 >> 生产暂停，等待消费"); } try { list.put(good); } catch (InterruptedException e) { e.printStackTrace(); } } public void consume() { if (list.size() == 0) { System.out.println("库存已清仓 >> 消费暂停，等待生产"); } try { list.take(); } catch (InterruptedException e) { e.printStackTrace(); } } } </pre></td></tr></tbody></table></code></pre></div></div> <code class="language-plaintext highlighter-rouge">BlockingQueue</code> 其实就是阻塞队列，是基于阻塞机制实现的线程安全的队列。而阻塞机制的实现是通过在入队和出队时加锁的方式避免并发操作。我们可以理解它内部其实已经实现了上述的加锁和等待/唤醒这一套流程，只不过帮我们封装好了这一切。 <h3 id="应用场景">应用场景</h3> 我们所熟知的线程池，它的内部其实就是构建了一个生产者-消费者模型用于将任务管理和线程管理两部分工作解耦，很大程度上提高了可扩展性。 <img src="/img/in-post/post-android/threadpool_running_process.png" alt="threadpool_running_process" /> 平时业务中也会有生产消费模型的用武之地，比如多固件更新过程就符合生产-消费模型，用户通过手动操作选中特定设备的固件包加入升级队列，随后由 UpdateDispatcher 根据具体设备类型进行不同策略的分发消费。 <h3 id="相关参考">相关参考</h3> <ul> <li><a href="https://blog.csdn.net/thetimelyrain/article/details/107209101">wait()方法为什么要放在while循环里面-虚假唤醒</a></li> <li><a href="https://juejin.cn/post/6999798721269465102">深入理解 BlockingQueue</a></li> </ul>

2023/4/29

Android系统启动流程剖析

Android 手机从长按开机到应用的启动阶段都经历了些什么呢？Android 启动过程涉及一系列操作，首先是启动 ROM，接着是引导加载程序、内核启动、init、Zygote 和 SystemServer 创建等过程。整个过程涉及到虚拟机的启动、Binder 线程池的创建以及各项系统服务启动等过程。熟悉 APP 启动过程还可以帮助我们打破性能优化瓶颈，助力于启动性能的提升。下面是启动过程涉及到的关键进程和服务： <img src="/img/in-post/post-android/android_init_brief.png" alt="android_init_brief" style="zoom:70%;" /> <blockquote> 本文基于 Android 13 最新代码来分析 Android 系统及应用启动过程。 </blockquote> <h3 id="init-进程启动">Init 进程启动</h3> init 进程在 Android 系统中扮演着非常重要的角色，它不仅仅是系统的第一个用户进程（pid 为 1），还负责整个系统的启动和进程的管理。当 Android 设备启动时，Bootloader 会初始化硬件设备，并在硬件自检之后将控制权交给 Kernel，Kernel 会加载 Android 系统的内核。而 init 进程的启动过程就发生在内核启动后，接着调用 system/core/init/main.cpp 来创建 init 进程，在此期间读取 init.rc 文件，启动 zygote 进程、servicemanager 等，最后完成初始化工作。下面来结合源码具体分析 init 启动后都做了些什么： <blockquote> system/core/init/main.cpp </blockquote> <div class="language-c++ highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 </pre></td><td class="rouge-code"><pre> using namespace android::init; int main(int argc, char** argv) { #if __has_feature(address_sanitizer) __asan_set_error_report_callback(AsanReportCallback); #elif __has_feature(hwaddress_sanitizer) __hwasan_set_error_report_callback(AsanReportCallback); #endif // Boost prio which will be restored later setpriority(PRIO_PROCESS, 0, -20); if (!strcmp(basename(argv[0]), "ueventd")) { return ueventd_main(argc, argv); } if (argc > 1) { if (!strcmp(argv[1], "subcontext")) { android::base::InitLogging(argv, &android::base::KernelLogger); const BuiltinFunctionMap& function_map = GetBuiltinFunctionMap(); return SubcontextMain(argc, argv, &function_map); } if (!strcmp(argv[1], "selinux_setup")) { return SetupSelinux(argv); } if (!strcmp(argv[1], "second_stage")) { return SecondStageMain(argc, argv); } } return FirstStageMain(argc, argv); } </pre></td></tr></tbody></table></code></pre></div></div> 内核启动后会调用到这里的 main 函数，主要执行了以下几个操作： <ul> <li>ueventd_main：该函数是 ueventd 守护进程的主要函数，通过 netlink scoket 响应内核生成的 uevent 事件。它设置信号处理程序，创建用于侦听传入 uevent 的套接字，然后进入无限循环以处理 uevent 事件。它其实也算是 init 进程，不过具体细节本文不再深究，后面会单独拎出来讲一讲。</li> <li>SubcontextMain：subcontext 进程的主要处理函数，负责为 init 进程创建和管理子进程，并通过 socket 与 init 进行通信。</li> <li>SetupSelinux：该函数会尝试加载在init.rc文件中定义的SELinux策略文件。如果文件存在，则在系统启动时加载所需的SELinux策略，并执行其他相关的SELinux设置。这些设置包括设置SELinux上下文，为设备中的所有进程和授权的服务分配安全策略和权限等。</li> <li>FirstStageMain：init 执行的第一阶段，主要做一些初始化文件系统、kernel 日志以及为第二阶段设定一些环境变量。</li> <li>SecondStageMain：init 执行的第二阶段，主要负责加载属性文件、启动属性服务、加载 init.rc 文件并创建和启动子进程。</li> </ul> 下面我们着重分析一下 init.rc 加载及子进程启动过程。 <div class="language-c++ highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 </pre></td><td class="rouge-code"><pre>int SecondStageMain(int argc, char** argv) { if (REBOOT_BOOTLOADER_ON_PANIC) { InstallRebootSignalHandlers(); } ...... // 加载属性文件 PropertyInit(); ...... // 启动属性服务 StartPropertyService(&property_fd); // Make the time that init stages started available for bootstat to log. RecordStageBoottimes(start_time); ...... ActionManager& am = ActionManager::GetInstance(); ServiceList& sm = ServiceList::GetInstance(); // 加载解析 init.rc LoadBootScripts(am, sm); } </pre></td></tr></tbody></table></code></pre></div></div> init.rc 文件的解析是在 LoadBootScripts() 中完成的，详见下面的实现： <div class="language-c++ highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 </pre></td><td class="rouge-code"><pre>static void LoadBootScripts(ActionManager& action_manager, ServiceList& service_list) { Parser parser = CreateParser(action_manager, service_list); std::string bootscript = GetProperty("ro.boot.init_rc", ""); if (bootscript.empty()) { parser.ParseConfig("/system/etc/init/hw/init.rc"); if (!parser.ParseConfig("/system/etc/init")) { late_import_paths.emplace_back("/system/etc/init"); } // late_import is available only in Q and earlier release. As we don't // have system_ext in those versions, skip late_import for system_ext. parser.ParseConfig("/system_ext/etc/init"); if (!parser.ParseConfig("/vendor/etc/init")) { late_import_paths.emplace_back("/vendor/etc/init"); } if (!parser.ParseConfig("/odm/etc/init")) { late_import_paths.emplace_back("/odm/etc/init"); } if (!parser.ParseConfig("/product/etc/init")) { late_import_paths.emplace_back("/product/etc/init"); } } else { parser.ParseConfig(bootscript); } } </pre></td></tr></tbody></table></code></pre></div></div> Init 进程依次解析不同路径下谷歌内置 system、SoC 厂商 vendor 以及 odm 厂商的 init.rc 文件并执行启动相关进程。init.rc 本质上只是一个语法文件，至于具体的 Service 和 Action 解析逻辑是在 ServiceParser 和 ActionParser 中处理，至于最终执行逻辑则是由解析处理器将所有 Service 和 Action 封装到 ServiceList 和 ActionList 单例对象中集中处理的。这里以 <code class="language-plaintext highlighter-rouge">init.zygote64_32.rc</code> 中一段启动 zygote 的 rc 代码为例： <blockquote> Note：system/core/rootdir/init.rc 中通过 import 动态引入了基于不同平台的 zygote 进程启动配置，以下仅以常见的 init.zygote64_32.rc 平台为例。 </blockquote> <pre><code class="language-rst"> service zygote /system/bin/app_process64 -Xzygote /system/bin --zygote --start-system-server --socket- name=zygote class main priority -20 user root group root readproc reserved_disk socket zygote stream 660 root system socket usap_pool_primary stream 660 root system onrestart exec_background - system system -- /system/bin/vdc volume abort_fuse onrestart write /sys/power/state on onrestart restart audioserver onrestart restart cameraserver onrestart restart media onrestart restart media.tuner onrestart restart netd onrestart restart wificond task_profiles ProcessCapacityHigh MaxPerformance critical window=${zygote.critical_window.minute:-off} target=zygote-fatal </code></pre> Service 是一个服务类型的程序，以 service 开头，由 init 进程启动，其中每一个 service ，在启动时会通过 fork 方式生成子进程。其中，<code class="language-plaintext highlighter-rouge">zygote</code> 是进程的名字，<code class="language-plaintext highlighter-rouge">/system/bin/app_process </code> 是执行程序的路径，它是通过编译生成的，其包含了 <code class="language-plaintext highlighter-rouge">main()</code> 函数在内的一系列代码。在编译过程中，编译器会将源代码编译成目标文件，并将目标文件链接成可执行文件。在链接过程中，编译器会将不同的目标文件链接到一起，形成一个统一的可执行文件。在这个过程中， <code class="language-plaintext highlighter-rouge">app_process</code> 可执行文件会链接到 <code class="language-plaintext highlighter-rouge">app_main.cpp</code> 文件中定义的 <code class="language-plaintext highlighter-rouge">main()</code> 函数，因此运行 <code class="language-plaintext highlighter-rouge">app_process</code> 可执行文件时，系统会自动调用 <code class="language-plaintext highlighter-rouge">app_main.cpp</code> 文件中的 <code class="language-plaintext highlighter-rouge">main()</code> 函数。 后面几项则是传递给执行程序的参数，其中 <code class="language-plaintext highlighter-rouge">--start-system-server</code> 表示在 Zygote 进程启动后需要启动 System Server 进程。Zygote 进程是使用 Socket 来进行跨进程通信的，所以会创建一个名为 zygote 的 socket，660 表示访问权限 <code class="language-plaintext highlighter-rouge">rw-rw----</code>，表示文件拥有者和同一群组用户具有读写权限。 <blockquote> 了解更多关于 init.rc 语法约定参考：<a href="https://zhuanlan.zhihu.com/p/448765932">Android启动初始化 init.rc 详解</a> </blockquote> 接着 zygote 进程通过以下代码被启动： <blockquote> system/core/init/service.cpp </blockquote> <div class="language-c++ highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 </pre></td><td class="rouge-code"><pre>Result<void> Service::Start() { ... pid_t pid = -1; if (namespaces_.flags) { pid = clone(nullptr, nullptr, namespaces_.flags | SIGCHLD, nullptr); } else { pid = fork(); } if (pid == 0) { umask(077); cgroups_activated.CloseWriteFd(); setsid_finished.CloseReadFd(); RunService(descriptors, std::move(cgroups_activated), std::move(setsid_finished)); _exit(127); } else { cgroups_activated.CloseReadFd(); setsid_finished.CloseWriteFd(); } if (pid < 0) { pid_ = 0; return ErrnoError() << "Failed to fork"; } ... } </pre></td></tr></tbody></table></code></pre></div></div> 可以看到最终是通过 clone 或者 fork 的方式来创建一个进程，并返回 pid，其实最终它们都是通过系统调用基于父进程孵化出一个子进程，并与当前进程共享地址空间和文件描述符等资源。 <h3 id="zygote-进程">zygote 进程</h3> 通过上面分析我们知道，zygote 进程在启动后会执行到 app_main.cpp 的 main 函数中： <blockquote> frameworks/base/cmds/app_process/app_main.cpp </blockquote> <div class="language-c++ highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 </pre></td><td class="rouge-code"><pre>#if defined(__LP64__) static const char ABI_LIST_PROPERTY[] = "ro.product.cpu.abilist64"; static const char ZYGOTE_NICE_NAME[] = "zygote64"; #else static const char ABI_LIST_PROPERTY[] = "ro.product.cpu.abilist32"; static const char ZYGOTE_NICE_NAME[] = "zygote"; #endif int main(int argc, char* const argv[]) { AppRuntime runtime(argv[0], computeArgBlockSize(argc, argv)); ... // Parse runtime arguments. Stop at first unrecognized option. bool zygote = false; bool startSystemServer = false; bool application = false; String8 niceName; String8 className; ++i; // Skip unused "parent dir" argument. while (i < argc) { const char* arg = argv[i++]; // 通过 init.rc 中约定的 `--zygote` 来判断是zygote进程 if (strcmp(arg, "--zygote") == 0) { zygote = true; niceName = ZYGOTE_NICE_NAME; } else if (strcmp(arg, "--start-system-server") == 0) { startSystemServer = true; } else if (strcmp(arg, "--application") == 0) { application = true; } else if (strncmp(arg, "--nice-name=", 12) == 0) { niceName.setTo(arg + 12); } else if (strncmp(arg, "--", 2) != 0) { className.setTo(arg); break; } else { --i; break; } } ... if (!niceName.isEmpty()) { runtime.setArgv0(niceName.string(), true /* setProcName */); } if (zygote) { // 进入 AppRunTime 中继续执行，准备穿越到 Java 世界 runtime.start("com.android.internal.os.ZygoteInit", args, zygote); } else if (className) { runtime.start("com.android.internal.os.RuntimeInit", args, zygote); } else { fprintf(stderr, "Error: no class name or --zygote supplied.\n"); app_usage(); LOG_ALWAYS_FATAL("app_process: no class name or --zygote supplied."); } } </pre></td></tr></tbody></table></code></pre></div></div> 通过上述代码我们可以发现，zygote 进程通过 <code class="language-plaintext highlighter-rouge">--zygote</code> 参数标记，如果是 zygote 进程，最终会执行到 AppRuntime.start 中： <blockquote> frameworks/base/core/jni/AndroidRuntime.cpp </blockquote> <div class="language-c++ highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 </pre></td><td class="rouge-code"><pre>/* * Start the Android runtime. This involves starting the virtual machine * and calling the "static void main(String[] args)" method in the class * named by "className". * * Passes the main function two arguments, the class name and the specified * options string. */ void AndroidRuntime::start(const char* className, const Vector<String8>& options, bool zygote) { ALOGD(">>>>>> START %s uid %d <<<<<<\n", className != NULL ? className : "(unknown)", getuid()); static const String8 startSystemServer("start-system-server"); // Whether this is the primary zygote, meaning the zygote which will fork system server. bool primary_zygote = false; ... /* start the virtual machine */ JniInvocation jni_invocation; jni_invocation.Init(NULL); JNIEnv* env; if (startVm(&mJavaVM, &env, zygote, primary_zygote) != 0) { return; } onVmCreated(env); /* * Register android functions. */ if (startReg(env) < 0) { ALOGE("Unable to register all android natives\n"); return; } ... /* * Start VM. This thread becomes the main thread of the VM, and will * not return until the VM exits. */ char* slashClassName = toSlashClassName(className != NULL ? className : ""); jclass startClass = env->FindClass(slashClassName); if (startClass == NULL) { ALOGE("JavaVM unable to locate class '%s'\n", slashClassName); /* keep going */ } else { jmethodID startMeth = env->GetStaticMethodID(startClass, "main", "([Ljava/lang/String;)V"); if (startMeth == NULL) { ALOGE("JavaVM unable to find main() in '%s'\n", className); /* keep going */ } else { env->CallStaticVoidMethod(startClass, startMeth, strArray); #if 0 if (env->ExceptionCheck()) threadExitUncaughtException(env); #endif } } free(slashClassName); ALOGD("Shutting down VM\n"); if (mJavaVM->DetachCurrentThread() != JNI_OK) ALOGW("Warning: unable to detach main thread\n"); if (mJavaVM->DestroyJavaVM() != 0) ALOGW("Warning: VM did not shut down cleanly\n"); } </pre></td></tr></tbody></table></code></pre></div></div> 通过这部分代码我们了解到，jni 层的 AndroidRuntime 的 start 函数主要完成了三件事： <ul> <li>启动 zygote 进程的虚拟机</li> <li>完成 JNI 方法注册（在 VM 上注册 Android 本地方法，只为了能够让 native 调用到 Java 层方法）</li> <li>调用 Java 层的 com.android.internal.os.ZygoteInit#main 方法</li> </ul> 至此，终于来到了我们熟悉的 Java 世界了，继续 zygote 的初始化逻辑： <blockquote> com.android.internal.os.ZygoteInit </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 </pre></td><td class="rouge-code"><pre>/** * This is the entry point for a Zygote process. It creates the Zygote server, loads resources, * and handles other tasks related to preparing the process for forking into applications. * * This process is started with a nice value of -20 (highest priority). All paths that flow * into new processes are required to either set the priority to the default value or terminate * before executing any non-system code. The native side of this occurs in SpecializeCommon, * while the Java Language priority is changed in ZygoteInit.handleSystemServerProcess, * ZygoteConnection.handleChildProc, and Zygote.childMain. * * @param argv Command line arguments used to specify the Zygote's configuration. */ @UnsupportedAppUsage public static void main(String[] argv) { ZygoteServer zygoteServer = null; Runnable caller; try { ... boolean startSystemServer = false; String zygoteSocketName = "zygote"; boolean enableLazyPreload = false; for (int i = 1; i < argv.length; i++) { if ("start-system-server".equals(argv[i])) { startSystemServer = true; } else if ("--enable-lazy-preload".equals(argv[i])) { enableLazyPreload = true; } else if (argv[i].startsWith(ABI_LIST_ARG)) { abiList = argv[i].substring(ABI_LIST_ARG.length()); } else if (argv[i].startsWith(SOCKET_NAME_ARG)) { zygoteSocketName = argv[i].substring(SOCKET_NAME_ARG.length()); } else { throw new RuntimeException("Unknown command line argument: " + argv[i]); } } // In some configurations, we avoid preloading resources and classes eagerly. // In such cases, we will preload things prior to our first fork. if (!enableLazyPreload) { preload(bootTimingsTraceLog); } zygoteServer = new ZygoteServer(isPrimaryZygote); if (startSystemServer) { Runnable r = forkSystemServer(abiList, zygoteSocketName, zygoteServer); // {@code r == null} in the parent (zygote) process, and {@code r != null} in the // child (system_server) process. if (r != null) { r.run(); return; } } Log.i(TAG, "Accepting command socket connections"); // The select loop returns early in the child process after a fork and // loops forever in the zygote. caller = zygoteServer.runSelectLoop(abiList); } catch (Throwable ex) { Log.e(TAG, "System zygote died with fatal exception", ex); throw ex; } finally { if (zygoteServer != null) { zygoteServer.closeServerSocket(); } } // We're in the child process and have exited the select loop. Proceed to execute the // command. if (caller != null) { caller.run(); } } </pre></td></tr></tbody></table></code></pre></div></div> ZygoteInit#main 中大致做了以下几件事： <ul> <li>preload：预加载系统基础类、资源文件、共享库等。</li> <li>ZygoteServer：创建 Socket 服务端，用于和其他进程通信。</li> <li>forkSystemServer：fork 出 system_server 子进程，下面会分析到。</li> <li>ZygoteServer#runSelectLoop：socket 循环监听 AMS 用于创建应用进程的请求。</li> </ul> 那么我简单总结一下，zygote 进程负责创建虚拟机，并注册 JNI 方法，成为 Java 进程的母体，用于持续孵化 Java 进程。在创建完system_server 进程后调用 <code class="language-plaintext highlighter-rouge">runSelectLoop</code>，随时等待接收创建新进程的请求并立即唤醒开始执行相应创建工作。 <h3 id="system_server-进程">system_server 进程</h3> Zygote 的初始化过程涉及到 system_server 进程的创建和启动，那我们就来看下 system_server 进程的启动过程： <blockquote> com.android.internal.os.ZygoteInit </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 </pre></td><td class="rouge-code"><pre>/** * Prepare the arguments and forks for the system server process. * * @return A {@code Runnable} that provides an entrypoint into system_server code in the child * process; {@code null} in the parent. */ private static Runnable forkSystemServer(String abiList, String socketName, ZygoteServer zygoteServer) { String[] args = { "--setuid=1000", "--setgid=1000", "--setgroups=1001,1002,1003,1004,1005,1006,1007,1008,1009,1010,1018,1021,1023," + "1024,1032,1065,3001,3002,3003,3006,3007,3009,3010,3011", "--capabilities=" + capabilities + "," + capabilities, "--nice-name=system_server", "--runtime-args", "--target-sdk-version=" + VMRuntime.SDK_VERSION_CUR_DEVELOPMENT, // system_server 执行程序的类名 "com.android.server.SystemServer", }; ... ZygoteArguments parsedArgs; int pid; try { ... /* Request to fork the system server process */ pid = Zygote.forkSystemServer( parsedArgs.mUid, parsedArgs.mGid, parsedArgs.mGids, parsedArgs.mRuntimeFlags, null, parsedArgs.mPermittedCapabilities, parsedArgs.mEffectiveCapabilities); } catch (IllegalArgumentException ex) { throw new RuntimeException(ex); } /* For child process */ if (pid == 0) { if (hasSecondZygote(abiList)) { waitForSecondaryZygote(socketName); } zygoteServer.closeServerSocket(); return handleSystemServerProcess(parsedArgs); } return null; } /** * Finish remaining work for the newly forked system server process. */ private static Runnable handleSystemServerProcess(ZygoteArguments parsedArgs) { if (parsedArgs.mNiceName != null) { Process.setArgV0(parsedArgs.mNiceName); } ... if (parsedArgs.mInvokeWith != null) { ... throw new IllegalStateException("Unexpected return from WrapperInit.execApplication"); } else { ClassLoader cl = getOrCreateSystemServerClassLoader(); if (cl != null) { Thread.currentThread().setContextClassLoader(cl); } /* * Pass the remaining arguments to SystemServer. */ return ZygoteInit.zygoteInit(parsedArgs.mTargetSdkVersion, parsedArgs.mDisabledCompatChanges, parsedArgs.mRemainingArgs, cl); } /* should never reach here */ } public static Runnable zygoteInit(int targetSdkVersion, long[] disabledCompatChanges, String[] argv, ClassLoader classLoader) { if (RuntimeInit.DEBUG) { Slog.d(RuntimeInit.TAG, "RuntimeInit: Starting application from zygote"); } Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "ZygoteInit"); RuntimeInit.redirectLogStreams(); // 设置异常处理机制 RuntimeInit.commonInit(); // 启动进程的Binder线程池 ZygoteInit.nativeZygoteInit(); return RuntimeInit.applicationInit(targetSdkVersion, disabledCompatChanges, argv, classLoader); } </pre></td></tr></tbody></table></code></pre></div></div> 看到上面的参数信息 args 包含了 <code class="language-plaintext highlighter-rouge">com.android.server.SystemServer</code> 就可以大致猜到最后应该是反射创建的实例。上面方法 <code class="language-plaintext highlighter-rouge">ZygoteInit#forkSystemServer</code> 继续追踪下去，system_server 进程的创建最终通过 Zygote.forkSystemServer 实现的： <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 </pre></td><td class="rouge-code"><pre>/** * Special method to start the system server process. In addition to the * common actions performed in forkAndSpecialize, the pid of the child * process is recorded such that the death of the child process will cause * zygote to exit. * * @param uid the UNIX uid that the new process should setuid() to after * fork()ing and and before spawning any threads. * @param gid the UNIX gid that the new process should setgid() to after * fork()ing and and before spawning any threads. * @param gids null-ok; a list of UNIX gids that the new process should * setgroups() to after fork and before spawning any threads. * @param runtimeFlags bit flags that enable ART features. * @param rlimits null-ok an array of rlimit tuples, with the second * dimension having a length of 3 and representing * (resource, rlim_cur, rlim_max). These are set via the posix * setrlimit(2) call. * @param permittedCapabilities argument for setcap() * @param effectiveCapabilities argument for setcap() * * @return 0 if this is the child, pid of the child * if this is the parent, or -1 on error. */ static int forkSystemServer(int uid, int gid, int[] gids, int runtimeFlags, int[][] rlimits, long permittedCapabilities, long effectiveCapabilities) { ZygoteHooks.preFork(); int pid = nativeForkSystemServer( uid, gid, gids, runtimeFlags, rlimits, permittedCapabilities, effectiveCapabilities); // Set the Java Language thread priority to the default value for new apps. Thread.currentThread().setPriority(Thread.NORM_PRIORITY); ZygoteHooks.postForkCommon(); return pid; } </pre></td></tr></tbody></table></code></pre></div></div> system_server 进程的最终实现是在 native 层，但是从注释来看，它的返回值如果是 0 则说明当前是子进程，否则可能依然是父进程或者 fork 失败。如果 system_server 进程创建成功，会依次执行到 handleSystemServerProcess 和 zygoteInit 方法，继续跟进到 RuntimeInit.applicationInit 一探究竟： <blockquote> frameworks/base/core/java/com/android/internal/os/RuntimeInit.java </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 </pre></td><td class="rouge-code"><pre>protected static Runnable applicationInit(int targetSdkVersion, long[] disabledCompatChanges, String[] argv, ClassLoader classLoader) { ... // Remaining arguments are passed to the start class's static main return findStaticMain(args.startClass, args.startArgs, classLoader); } protected static Runnable findStaticMain(String className, String[] argv, ClassLoader classLoader) { Class<?> cl; try { cl = Class.forName(className, true, classLoader); } catch (ClassNotFoundException ex) { throw new RuntimeException( "Missing class when invoking static main " + className, ex); } Method m; try { m = cl.getMethod("main", new Class[] { String[].class }); } catch (NoSuchMethodException ex) { throw new RuntimeException( "Missing static main on " + className, ex); } catch (SecurityException ex) { throw new RuntimeException( "Problem getting static main on " + className, ex); } int modifiers = m.getModifiers(); if (! (Modifier.isStatic(modifiers) && Modifier.isPublic(modifiers))) { throw new RuntimeException( "Main method is not public and static on " + className); } /* * This throw gets caught in ZygoteInit.main(), which responds * by invoking the exception's run() method. This arrangement * clears up all the stack frames that were required in setting * up the process. */ return new MethodAndArgsCaller(m, argv); } /** * Helper class which holds a method and arguments and can call them. This is used as part of * a trampoline to get rid of the initial process setup stack frames. */ static class MethodAndArgsCaller implements Runnable { /** method to call */ private final Method mMethod; /** argument array */ private final String[] mArgs; public MethodAndArgsCaller(Method method, String[] args) { mMethod = method; mArgs = args; } public void run() { try { mMethod.invoke(null, new Object[] { mArgs }); } catch (IllegalAccessException ex) { throw new RuntimeException(ex); } catch (InvocationTargetException ex) { Throwable cause = ex.getCause(); if (cause instanceof RuntimeException) { throw (RuntimeException) cause; } else if (cause instanceof Error) { throw (Error) cause; } throw new RuntimeException(ex); } } } </pre></td></tr></tbody></table></code></pre></div></div> 最终不出我们所料，findStaticMain 中传递的 className 对应的就是我们之前的 com.android.server.SystemServer 类，我们来看看它里面都做了些什么（SystemServer#main 会执行到 <code class="language-plaintext highlighter-rouge">run</code> 方法）： <blockquote> frameworks/base/services/java/com/android/server/SystemServer.java </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 </pre></td><td class="rouge-code"><pre>private void run() { try { ... // Prepare the main looper thread (this thread). android.os.Process.setThreadPriority( android.os.Process.THREAD_PRIORITY_FOREGROUND); android.os.Process.setCanSelfBackground(false); Looper.prepareMainLooper(); Looper.getMainLooper().setSlowLogThresholdMs( SLOW_DISPATCH_THRESHOLD_MS, SLOW_DELIVERY_THRESHOLD_MS); SystemServiceRegistry.sEnableServiceNotFoundWtf = true; ... // Initialize the system context. createSystemContext(); ... // Create the system service manager. mSystemServiceManager = new SystemServiceManager(mSystemContext); mSystemServiceManager.setStartInfo(mRuntimeRestart, mRuntimeStartElapsedTime, mRuntimeStartUptime); mDumper.addDumpable(mSystemServiceManager); LocalServices.addService(SystemServiceManager.class, mSystemServiceManager); // Prepare the thread pool for init tasks that can be parallelized SystemServerInitThreadPool tp = SystemServerInitThreadPool.start(); mDumper.addDumpable(tp); ... } finally { t.traceEnd(); // InitBeforeStartServices } // Setup the default WTF handler RuntimeInit.setDefaultApplicationWtfHandler(SystemServer::handleEarlySystemWtf); // Start services. try { t.traceBegin("StartServices"); startBootstrapServices(t); startCoreServices(t); startOtherServices(t); startApexServices(t); } catch (Throwable ex) { Slog.e("System", "******************************************"); Slog.e("System", "************ Failure starting system services", ex); throw ex; } finally { t.traceEnd(); // StartServices } ... // Loop forever. Looper.loop(); throw new RuntimeException("Main thread loop unexpectedly exited"); } </pre></td></tr></tbody></table></code></pre></div></div> 通过分析上面代码可以发现 system_server 为我们做了很多事情： <ul> <li>创建系统服务管理器 SystemServiceManager</li> <li>启动引导服务（AMS、PMS等）、核心服务和其他各种服务</li> <li>创建主线程 Looper 并一直循环，等待其他线程通过 Handler 发送消息再唤醒并处理。</li> </ul> <h5 id="nativezygoteinit">nativeZygoteInit</h5> 上面的 com.android.internal.os.ZygoteInit#forkSystemServer 中 <code class="language-plaintext highlighter-rouge">ZygoteInit.nativeZygoteInit()</code> 方法主要从 native 层创建了进程的 Binder 线程池。值得注意的，这一切发生在 system_server 进程创建之后。最终可以追溯到： <blockquote> frameworks/native/libs/binder/ProcessState.cpp </blockquote> <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 </pre></td><td class="rouge-code"><pre>void ProcessState::spawnPooledThread(bool isMain) { if (mThreadPoolStarted) { String8 name = makeBinderThreadName(); ALOGV("Spawning new pooled thread, name=%s\n", name.string()); sp<Thread> t = sp<PoolThread>::make(isMain); t->run(name.string()); pthread_mutex_lock(&mThreadCountLock); mKernelStartedThreads++; pthread_mutex_unlock(&mThreadCountLock); } } </pre></td></tr></tbody></table></code></pre></div></div> <h3 id="系统启动日志分析">系统启动日志分析</h3> 从 Android 开机开始到我们系统初始化完毕，这中间设有大量的关键日志，如果能够好好利用，对于我们排查一些系统性问题或者性能问题会有巨大帮助。以下列举部分关键节点的 Tag： <h5 id="可查看启动耗时">可查看启动耗时</h5> <ul> <li>boot_progress_start：表示 kernel 启动完成，第一个用户空间进程 init 进程启动</li> <li>boot_progress_preload_start：zygote 进程开始预加载 class 资源（记录于 ZygoteInit#preload 调用时机）</li> <li>boot_progress_preload_end：zygote 进程 class 资源预加载结束</li> <li>boot_progress_system_run：表示 system_server 进程启动（记录于 SystemServer#run 调用时机）</li> <li>boot_progress_pms_start：表示 PMS 服务启动并开始扫描应用的动作</li> <li>boot_progress_pms_ready：表示 PMS 服务应用扫描完毕</li> <li>boot_progress_ams_ready：表示 AMS 已经进入 systemReady 状态可以启动桌面应用了</li> <li>boot_progress_enable_screen：标志着锁频界面已经点亮显示，开机完成并统计耗时</li> </ul> 更多 native 层相关统计的 tag 参照：<a href="https://cs.android.com/android/platform/superproject/+/master:system/logging/logcat/event.logtags">system/logging/logcat/event.logtags</a> 我们可以额外留意一些系统进程和服务的相关日志，比如 zygote 运行相关日志： <div class="language-lisp highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 </pre></td><td class="rouge-code"><pre>// Zygote64进程(Zygote): AndroidRuntime::start 11-23 14:36:51.260 557 557 D AndroidRuntime: >>>>>> START com.android.internal.os.ZygoteInit uid 0 <<<<<< // Zygote64进程: AndroidRuntime::startVm 11-23 14:36:51.304 557 557 D AndroidRuntime: CheckJNI is OFF // 执行ZygoteInit.preload() 11-23 14:36:52.134 557 557 D Zygote : begin preload // 执行ZygoteInit.preloadClasses(), 预加载3860个classes, 花费时长746ms 11-23 14:36:52.134 557 557 I Zygote : Preloading classes... 11-23 14:36:52.881 557 557 I Zygote : ...preloaded 3860 classes in 746ms. // 执行ZygoteInit.preloadClasses(), 预加载86组资源, 花费时长179ms 11-23 14:36:53.114 557 557 I Zygote : Preloading resources... 11-23 14:36:53.293 557 557 I Zygote : ...preloaded 86 resources in 179ms. // 执行ZygoteInit.preloadSharedLibraries() 11-23 14:36:53.494 557 557 I Zygote : Preloading shared libraries... 11-23 14:36:53.503 557 557 D Zygote : end preload // 执行com_android_internal_os_Zygote_nativeForkSystemServer(),成功fork出system_server进程 11-23 14:36:53.544 557 557 I Zygote : System server process 1274 has been created // Zygote开始进入runSelectLoop() 11-23 14:36:53.546 557 557 I Zygote : Accepting command socket connections </pre></td></tr></tbody></table></code></pre></div></div> system_server 进程运行相关日志： <div class="language-lisp highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 </pre></td><td class="rouge-code"><pre>//进入system_server, 建立跟Zygote进程的socket通道 11-23 14:36:53.586 1274 1274 I Zygote : Process: zygote socket opened, supported ABIS: armeabi-v7a,armeabi // 执行SystemServer.run() 11-23 14:36:53.618 1274 1274 I SystemServer: Entered the Android system server! <===> boot_progress_system_run // 等待installd准备就绪 11-23 14:36:53.707 1274 1274 I Installer: Waiting for installd to be ready. //服务启动 11-23 14:36:53.732 1274 1274 I ActivityManager: Memory class: 192 //phase100 11-23 14:36:53.883 1274 1274 I SystemServiceManager: Starting phase 100 11-23 14:36:53.902 1274 1274 I SystemServer: Package Manager 11-23 14:37:03.816 1274 1274 I SystemServer: User Service ... 11-23 14:37:03.940 1274 1274 I SystemServer: Init Watchdog 11-23 14:37:03.941 1274 1274 I SystemServer: Input Manager 11-23 14:37:03.946 1274 1274 I SystemServer: Window Manager ... 11-23 14:37:04.081 1274 1274 I SystemServiceManager: Starting com.android.server.MountService$Lifecycle 11-23 14:37:04.088 1274 2717 D MountService: Thinking about reset, mSystemReady=false, mDaemonConnected=true 11-23 14:37:04.088 1274 1274 I SystemServiceManager: Starting com.android.server.UiModeManagerService 11-23 14:37:04.520 1274 1274 I SystemServer: NetworkTimeUpdateService //phase480 && 500 11-23 14:37:05.056 1274 1274 I SystemServiceManager: Starting phase 480 11-23 14:37:05.061 1274 1274 I SystemServiceManager: Starting phase 500 11-23 14:37:05.231 1274 1274 I ActivityManager: System now ready <==> boot_progress_ams_ready 11-23 14:37:05.234 1274 1274 I SystemServer: Making services ready 11-23 14:37:05.243 1274 1274 I SystemServer: WebViewFactory preparation //phase550 11-23 14:37:05.234 1274 1274 I SystemServiceManager: Starting phase 550 11-23 14:37:05.237 1274 1288 I ActivityManager: Force stopping com.android.providers.media appid=10010 user=-1: vold reset //Phase600 11-23 14:37:06.066 1274 1274 I SystemServiceManager: Starting phase 600 11-23 14:37:06.236 1274 1274 D MountService: onStartUser 0 </pre></td></tr></tbody></table></code></pre></div></div> 基于记录以上关键日志的目的，我们可以通过以下 logcat 命令在手机开机后使用： <ul> <li><code class="language-plaintext highlighter-rouge">adb logcat -b events |grep “boot_progress”</code></li> <li><code class="language-plaintext highlighter-rouge">adb logcat -s Zygote|SystemServer|SystemServiceManager|ActivityManager</code></li> </ul> <h3 id="总结">总结</h3> 笔者认为，源码分析过程中如果能输出关键类调用的流程，能够显著加强后续理解。关于普通应用进程的创建和启动过程将在后续 Activity 启动分析中一并介绍。下图就是关于本文各进程启动过程的方法调用链路总结。 <img src="/img/in-post/post-android/init_method_call.svg" alt="init_method_call" style="zoom: 50%;" /> <h3 id="参考">参考</h3> <ul> <li><a href="https://source.android.com/docs/core/architecture?hl=zh-cn">AOSP 架构概览</a></li> <li><a href="http://gityuan.com/2016/02/01/android-booting/">Android 系统启动综述</a></li> <li>https://juejin.cn/post/6999491633129455653</li> </ul>

2023/4/22

AOSP在Mac上的编译实践（上）

AOSP，即 Android Open Source Project，对于 Android 开发者来说再熟悉不过的项目，本文将着重介绍如何在 MacOS Monterey 环境上下载完整的 AOSP 源码。 <h2 id="git--python">Git & Python</h2> <h4 id="1-git-安装和配置">1. Git 安装和配置</h4> 在安装了 <a href="https://brew.sh/">Homebrew</a> 的情况下，安装 git 我们只需要执行如下命令： <div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 </pre></td><td class="rouge-code"><pre>brew install git </pre></td></tr></tbody></table></code></pre></div></div> 接着初始化一下 Git 的全局配置信息： <div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 </pre></td><td class="rouge-code"><pre>git config --global user.name "User Name" git config --global user.email "your@example.com" </pre></td></tr></tbody></table></code></pre></div></div> <h4 id="2-配置-python-环境">2. 配置 python 环境</h4> 一般情况下我们电脑上都会安装了 python 环境，如果没有安装，可以前往 <a href="https://www.python.org">python官方站点</a>下载。安装成功并做好解释器关联后执行以下命令查看版本信息： <div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 </pre></td><td class="rouge-code"><pre>➜ ~ python --version Python 3.10.4 </pre></td></tr></tbody></table></code></pre></div></div> 目前的 repo 都是基于 python 3.0，我们需要留意最新的 <a href="https://android.googlesource.com/tools/repo">repo</a> 版本中的 main.py 文件中定义的版本和我们本地的 python 环境是否一致。这里能跑通并不代表整个环境就万事大吉了，后面在安装 repo 的时候会提到因 python 配置而遇到的一个问题。 <h2 id="安装-repo">安装 repo</h2> Repo 是建立在 Git 上的一个多仓库管理工具，可以组织多个仓库的上传和下载。它是 Google 基于 Python 和 Git 编写的脚本工具，可以协助我们管理多个 Git 存储仓库。首先，我们通过如下命令安装和配置 repo： <div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 </pre></td><td class="rouge-code"><pre>➜ mkdir ~/DevKit/bin ➜ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/DevKit/bin/repo ➜ chmod a+x ~/DevKit/bin/repo </pre></td></tr></tbody></table></code></pre></div></div> 如果提示网络问题可能需要翻墙，可尝试使用国内镜像： <div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 </pre></td><td class="rouge-code"><pre>curl https://mirrors.tuna.tsinghua.edu.cn/git/git-repo -o ~/DevKit/bin/repo chmod a+x ~/DevKit/bin/repo </pre></td></tr></tbody></table></code></pre></div></div> 接着执行 <code class="language-plaintext highlighter-rouge">repo --version</code> 查看是否安装成功： <div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 </pre></td><td class="rouge-code"><pre>➜ ~ repo --version <repo not installed> repo launcher version 2.32 (from /Users/dorck/DevKit/bin/repo) git 2.32.0 (Apple Git-132) Python 3.10.4 (v3.10.4:9d38120e33, Mar 23 2022, 17:29:05) [Clang 13.0.0 (clang-1300.0.29.30)] OS Darwin 21.4.0 (Darwin Kernel Version 21.4.0: Fri Mar 18 00:46:32 PDT 2022; root:xnu-8020.101.4~15/RELEASE_ARM64_T6000) CPU arm64 (arm) Bug reports: https://bugs.chromium.org/p/gerrit/issues/entry?template=Repo+tool+issue ➜ ~ </pre></td></tr></tbody></table></code></pre></div></div> 若出现上述版本提示信息说明安装成功，可继续进行下一步操作。But，在笔者的 M1 电脑上遇到了一个坑，在执行 <code class="language-plaintext highlighter-rouge">repo --version</code> 时提示 python 配置问题： <div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 </pre></td><td class="rouge-code"><pre>env: python: No such file or directory </pre></td></tr></tbody></table></code></pre></div></div> 出现这类问题的常见原因一般是本地有多个 python 版本环境，导致链接出错，于是我先定位一下本地机器中的 python 解释器版本有哪些： <div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 </pre></td><td class="rouge-code"><pre>➜ where python /Library/Frameworks/Python.framework/Versions/3.10/bin/python3.10 </pre></td></tr></tbody></table></code></pre></div></div> 可以看到我电脑指向的是 /Library/Frameworks 下的内置 python 环境，然而我又翻看了一下 <code class="language-plaintext highlighter-rouge">~/.bash_profile</code> 中的 python 环境配置： <div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 </pre></td><td class="rouge-code"><pre># Python 配置 alias python="/Library/Frameworks/Python.framework/Versions/3.10/bin/python3.10" export PATH="/Library/Frameworks/Python.framework/Versions/3.10/bin:$PATH" export PATH=/usr/local/bin:$PATH export PATH=/Users/{YOUR_NAME}/DevKit/bin:$PATH export REPO_URL='https://mirrors.tuna.tsinghua.edu.cn/git/git-repo' </pre></td></tr></tbody></table></code></pre></div></div> 可以看到，我这边配置了不止一项 python 环境，<code class="language-plaintext highlighter-rouge">/usr/local/bin</code> 下还存在一个 3.0 版本的 python，那么为什么 repo 中的 python 代码执行不了呢？简单看了下 repo 的<a href="https://docs.python.org/3/library/sys.html">内部代码</a>，发现他里面是通过 sys 库来获取的当前运行的 python 解释器。以下是笔者的个人猜测：在 macOS 系统中，系统默认的 Python 解释器是 Python 2.x 版本，如果安装了 Python 3.x 版本，而且没有设置符号链接将其路径添加到系统 PATH 中，那么系统就无法找到 Python 3.x 版本的可执行文件。因此，当您在终端中输入 <code class="language-plaintext highlighter-rouge">python3</code> 命令时，系统会去默认的路径 <code class="language-plaintext highlighter-rouge">/usr/bin/</code> 中查找 Python 解释器，而无法找到 Python 3.x 版本的解释器，从而导致 “env: python: No such file or directory” 错误的发生。要解决这个问题，我们可以执行以下命令： <div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 </pre></td><td class="rouge-code"><pre>ln -sf /Library/Frameworks/Python.framework/Versions/3.10/bin/python3 /usr/local/bin/python </pre></td></tr></tbody></table></code></pre></div></div> 这个命令的作用是将 Python 3.10 版本的可执行文件添加到了 <code class="language-plaintext highlighter-rouge">/usr/local/bin</code> 目录下，并创建了一个符号链接(软链接)，使得 <code class="language-plaintext highlighter-rouge">python</code> 命令可以正确地指向 Python 3.10 版本的可执行文件，从而避免在使用 <code class="language-plaintext highlighter-rouge">python</code> 命令时出现因为找不到 Python 3.10 版本的可执行文件而报错的问题。这样，当我们在终端中输入 <code class="language-plaintext highlighter-rouge">python</code> 或 <code class="language-plaintext highlighter-rouge">python3</code> 命令时，系统会优先在 <code class="language-plaintext highlighter-rouge">/usr/local/bin</code> 目录下查找，找到该目录下的 <code class="language-plaintext highlighter-rouge">python</code> 或 <code class="language-plaintext highlighter-rouge">python3</code> 命令，然后使用其中的 Python 3.10 版本的可执行文件来执行程序，从而保证我们使用的是正确的 Python 版本。 接下来，安装完成 repo 后，我可以将以下 <code class="language-plaintext highlighter-rouge">REPO_URL</code> 地址替换为国内的镜像地址，方便后续下载 AOSP 源码，由于该项目较大，需要保证稳定的网络环境，不具备翻墙条件的此步骤为必选项： <div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 </pre></td><td class="rouge-code"><pre>export REPO_URL='https://mirrors.tuna.tsinghua.edu.cn/git/git-repo' export PATH=/Users/{YOUR_NAME}/DevKit/bin:$PATH </pre></td></tr></tbody></table></code></pre></div></div> 以上配置请复制到 ~/.bash_profile 中，并执行 <code class="language-plaintext highlighter-rouge">source ~/.bash_profile</code> 使其生效。这里需要将 repo 的 path 也放置到环境变量中，方便我们全局调用。 <blockquote> 关于 repo 的具体用法可以参考：<a href="https://juejin.cn/post/6971009369693503519">多仓库管理工具—Repo</a> </blockquote> <h2 id="下载-aosp">下载 AOSP</h2> 接下来我们就可以愉快的下载 AOSP 代码了： <div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 </pre></td><td class="rouge-code"><pre>➜ mkdir AOSP ➜ cd ~/AOSP ➜ repo init -u https://mirrors.tuna.tsinghua.edu.cn/git/AOSP/platform/manifest -b android-13.0.0_r30 </pre></td></tr></tbody></table></code></pre></div></div> 通过 repo init 命令来初始化、关联具体的 repo 项目，并指定了下载分支为 Android 13 版本的代码。当然，事情可能并不会一帆风顺，出现了下面的报错信息： <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 </pre></td><td class="rouge-code"><pre>fatal: Cannot get https://gerrit.googlesource.com/git-repo/clone.bundle fatal: error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590) </pre></td></tr></tbody></table></code></pre></div></div> 我们需要执行一下 Python 安装包下的 <code class="language-plaintext highlighter-rouge">Install Certificates.command</code> 脚本来安装证书，然后重新执行上述 init 命令： <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 </pre></td><td class="rouge-code"><pre>Downloading Repo source from https://mirrors.tuna.tsinghua.edu.cn/git/git-repo remote: Enumerating objects: 4463, done. remote: Counting objects: 100% (4463/4463), done. remote: Compressing objects: 100% (2123/2123), done. remote: Total 8034 (delta 3979), reused 2340 (delta 2340), pack-reused 3571 Receiving objects: 100% (8034/8034), 3.74 MiB | 13.53 MiB/s, done. Resolving deltas: 100% (5171/5171), done. repo: Updating release signing keys to keyset ver 2.3 </pre></td></tr></tbody></table></code></pre></div></div> 输出以上信息说明 repo 的 manifest 配置下载成功，接下来只需要同步一下代码即可： <div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 </pre></td><td class="rouge-code"><pre>➜ repo sync </pre></td></tr></tbody></table></code></pre></div></div> 代码同步时间会比较长，我们能做的就是耐心等待了。最终下载完成的 AOSP 大小直逼 150 GB： <img src="/img/in-post/post-android/aosp_download_suc.png" alt="aosp_download_suc" style="zoom: 50%;" /> 下一篇文章将会一起探索如何在 Mac 上编译 Android Open Source Project 项目，拭目以待。 <h2 id="参考">参考</h2> <ul> <li><a href="https://source.android.google.cn/docs/setup/about/build-numbers?hl=zh-cn#source-code-tags-and-builds">AOSP 中的代号、标记和 build 号</a></li> </ul>

2023/4/21

效率编程之快捷键篇

这是一个关于如何效率编程的系列专题，未来将会涉及诸如工具、脚本、插件、开源框架等各方面，只要能够帮助我们提升开发效率。 在日常当中，熟练地运用各种快捷键能够极大地提升我们的开发和工作效率。当看到其他同学通过快捷键两三下操作就帮你定位了问题代码并修改完毕，你是否也曾露出羡慕之色。正所谓磨刀不误砍柴工，快捷键也像宝刀一样，长时间弃而不用就会生锈，长此以往我们就会失去这一强大的臂助。 <blockquote> 以下常用快捷键指令皆基于 MAC 系统。 </blockquote> <h3 id="基础文本操作">基础文本操作</h3> 其实很多文本类工具都提供了通用的快捷键，比如文本选择、光标快速移动等等，毋以善小而不为，不要小看这些小小的效率提升，聚沙成塔，长久以后就会凝聚成我们自身强大工作流的一部分。 <h5 id="光标移动">光标移动</h5> <ul> <li>光标移动到行头/尾：<code class="language-plaintext highlighter-rouge">Cmd + ←</code> / <code class="language-plaintext highlighter-rouge">Cmd + →</code></li> <li>光标移动到文本开头/结尾：<code class="language-plaintext highlighter-rouge">Cmd + ↑</code> / <code class="language-plaintext highlighter-rouge">Cmd + ↓</code></li> <li>光标向前/向后隔一词跳跃：<code class="language-plaintext highlighter-rouge">Option + ←</code> / <code class="language-plaintext highlighter-rouge">Option + →</code></li> </ul> <h5 id="文本浏览">文本浏览</h5> <ul> <li>移动到文本开始/末尾：<code class="language-plaintext highlighter-rouge">Fn + ←</code> / <code class="language-plaintext highlighter-rouge">Fn + →</code>（浏览器和部分文本工具支持）</li> <li>文本上/下翻页：<code class="language-plaintext highlighter-rouge">Fn + ↑</code> / <code class="language-plaintext highlighter-rouge">Fn + ↓</code> （大部分文本工具都支持）</li> </ul> <h5 id="文本选取">文本选取</h5> 通过 <code class="language-plaintext highlighter-rouge">Shift</code> 搭配上方的光标移动快捷键，我们可以便捷实现文本选取。 <ul> <li>从当前位置选取到行首/尾：<code class="language-plaintext highlighter-rouge">Cmd + Shift + ←</code> / <code class="language-plaintext highlighter-rouge">Cmd + Shift + →</code></li> <li>从当前位置选取到文本开头/结尾：<code class="language-plaintext highlighter-rouge">Cmd + Shift + ↑</code> / <code class="language-plaintext highlighter-rouge">Cmd + Shift + ↓</code> 或者使用 <code class="language-plaintext highlighter-rouge">Fn + Shift + ←</code> / <code class="language-plaintext highlighter-rouge">Fn + Shift + →</code></li> <li>从当前位置向前/向后选取一个单词：<code class="language-plaintext highlighter-rouge">Option + Shift + ←</code> / <code class="language-plaintext highlighter-rouge">Option + Shift + →</code></li> <li>从当前位置向上/下选取一页：<code class="language-plaintext highlighter-rouge">Fn + Shift + ↑</code> / <code class="language-plaintext highlighter-rouge">Fn + Shift + ↓</code></li> </ul> <h5 id="文本删除">文本删除</h5> <ul> <li>向前删除：<code class="language-plaintext highlighter-rouge">Delete</code></li> <li>向后删除：<code class="language-plaintext highlighter-rouge">Fn + delete</code></li> <li>向前删除一个词：<code class="language-plaintext highlighter-rouge">Option + delete</code></li> <li>向后删除一个词：<code class="language-plaintext highlighter-rouge">Option + Fn + delete</code></li> <li>删除至行首：<code class="language-plaintext highlighter-rouge">Cmd + delete</code></li> </ul> <h5 id="文本查询">文本查询</h5> <ul> <li>当前文稿内查询：<code class="language-plaintext highlighter-rouge">Cmd + F</code></li> <li> 项目内查询：<code class="language-plaintext highlighter-rouge">Cmd + Shift + F</code> </li> <li>查询并定位命中的下一个目标：<code class="language-plaintext highlighter-rouge">Enter</code> / <code class="language-plaintext highlighter-rouge">Cmd + G</code></li> <li>查询并定位命中的上一个目标：<code class="language-plaintext highlighter-rouge">Cmd + Shift + G</code></li> </ul> <h5 id="文本样式">文本样式</h5> <ul> <li>粗体：<code class="language-plaintext highlighter-rouge">Cmd + B</code></li> <li>斜体：<code class="language-plaintext highlighter-rouge">Cmd + I</code></li> <li>下划线：<code class="language-plaintext highlighter-rouge">Cmd + U</code></li> <li>文字超链接：<code class="language-plaintext highlighter-rouge">Cmd + K</code></li> </ul> <h3 id="窗口操作">窗口操作</h3> <h5 id="切换">切换</h5> <ul> <li>隐藏屏幕正在显示的最上层窗口：<code class="language-plaintext highlighter-rouge">Cmd + H</code></li> <li>隐藏屏幕正在显示的底层窗口（除最上层以外的窗口）：<code class="language-plaintext highlighter-rouge">Cmd + Option + H</code></li> <li>在多个全屏窗口之间前后切换：<code class="language-plaintext highlighter-rouge">Control + ←</code> / <code class="language-plaintext highlighter-rouge">Control + →</code></li> <li>将所有窗口进入/退出预览模式：<code class="language-plaintext highlighter-rouge">Control + ↑</code> / <code class="language-plaintext highlighter-rouge">Control + ↓</code></li> </ul> <h5 id="应用程序">应用程序</h5> <ul> <li>在多个应用程序间前后切换：<code class="language-plaintext highlighter-rouge">Cmd + Tab</code> / <code class="language-plaintext highlighter-rouge">Cmd + Shift + Tab</code> / <code class="language-plaintext highlighter-rouge">Cmd + Tab + ←</code> / <code class="language-plaintext highlighter-rouge">Cmd + Tab + →</code></li> <li>退出最上层的应用程序：<code class="language-plaintext highlighter-rouge">Cmd + Q</code></li> <li>退出除最上层以外的其他应用：<code class="language-plaintext highlighter-rouge">Cmd + Shift + Q</code></li> </ul> <h5 id="关闭">关闭</h5> <ul> <li>关闭窗口：<code class="language-plaintext highlighter-rouge">Cmd + W</code></li> </ul> <h3 id="文件操作">文件操作</h3> <ul> <li>新建文件夹：<code class="language-plaintext highlighter-rouge">Command + Shift + N</code></li> <li>弹出窗口输入绝对路径课直达目标文件夹：<code class="language-plaintext highlighter-rouge">Command + Shift + G</code></li> <li>打开所选文件：<code class="language-plaintext highlighter-rouge">Command + O</code></li> <li>前往当前文件夹的上/下一层文件夹：<code class="language-plaintext highlighter-rouge">Command + ↑</code> / <code class="language-plaintext highlighter-rouge">Command + ↓</code></li> <li>将文件移至废纸篓：<code class="language-plaintext highlighter-rouge">Command + Delete</code></li> <li>清理废纸篓：<code class="language-plaintext highlighter-rouge">Command + Shift + Delete</code></li> <li>文件预览：<code class="language-plaintext highlighter-rouge">Space</code></li> <li>查看文件简介：<code class="language-plaintext highlighter-rouge">Command + I</code></li> <li>进入当前文件操作栈的上/下一层：<code class="language-plaintext highlighter-rouge">Cmd + [</code> / <code class="language-plaintext highlighter-rouge">Cmd + ]</code></li> <li>最小化窗口：<code class="language-plaintext highlighter-rouge">Cmd + M</code></li> <li>查看最近使用的文件：<code class="language-plaintext highlighter-rouge">Shift + Cmd + F</code></li> <li>进入下载目录：<code class="language-plaintext highlighter-rouge">Option + Cmd + L</code></li> <li>进入个人目录：<code class="language-plaintext highlighter-rouge">Shift + Cmd + H</code></li> </ul> <h3 id="其他系统快捷键">其他系统快捷键</h3> <h5 id="截图">截图</h5> <ul> <li>截取整个屏幕内容到桌面：<code class="language-plaintext highlighter-rouge">Command + Shift + 3</code></li> <li>截取整个屏幕内容到剪贴板：<code class="language-plaintext highlighter-rouge">Command + Shift + Control + 3</code></li> <li>截取所选屏幕区域到桌面，或按空格键仅捕捉一个窗口：<code class="language-plaintext highlighter-rouge">Command + Shift + 4</code></li> <li>截取所选屏幕区域到剪贴板，或按空格键仅捕捉一个窗口：<code class="language-plaintext highlighter-rouge">Command + Shift + Control + 4</code></li> </ul> <h5 id="撤销与恢复">撤销与恢复</h5> 很多时候，我们在经常编辑文本或处理文件的时候会大量用到撤销和恢复撤销两个动作。 <ul> <li>撤销：<code class="language-plaintext highlighter-rouge">Cmd + Z</code></li> <li>恢复撤销：<code class="language-plaintext highlighter-rouge">Cmd + Shift + Z</code></li> </ul> <h5 id="锁屏与关机">锁屏与关机</h5> <ul> <li>锁定屏幕：<code class="language-plaintext highlighter-rouge">Control + Command + Q</code></li> <li>重启：<code class="language-plaintext highlighter-rouge">Control + Command + Power</code></li> <li>关机：<code class="language-plaintext highlighter-rouge">Command + Option + COntrol + Power</code></li> </ul> <h3 id="android-studio-快捷键">Android Studio 快捷键</h3> <h5 id="搜索替换">搜索&替换</h5> <table> <thead> <tr> <th>快捷键说明</th> <th>Windows ｜ Linux</th> <th>MacOS</th> </tr> </thead> <tbody> <tr> <td>全局搜索（代码、文件、菜单）</td> <td>Shift + Shift</td> <td>Shift + Shift</td> </tr> <tr> <td>当前文件内查找代码</td> <td>Ctrl + F</td> <td>Command + F</td> </tr> <tr> <td>当前文件内代码替换</td> <td>Ctrl + R</td> <td>Command + R</td> </tr> <tr> <td>全局搜索代码（路径、项目、模块）</td> <td>Ctrl + Shift + F</td> <td>Command + Shift + F</td> </tr> <tr> <td>全局替换（路径、项目、模块）</td> <td>Ctrl + Shift + R</td> <td>Command + Shift + R</td> </tr> <tr> <td>查找下一项内容</td> <td>F3</td> <td>Command + G</td> </tr> <tr> <td>查找上一项内容</td> <td>Shift + F3</td> <td>Command + Shift+ G</td> </tr> <tr> <td>查看最近打开的文件窗口</td> <td>Ctrl + E</td> <td>Command + E</td> </tr> <tr> <td>查看最近编辑过的文件窗口</td> <td>Ctrl + Shift + E</td> <td>Command + Shift + E</td> </tr> <tr> <td>关闭当前窗口</td> <td>Ctrl + F4</td> <td>Command + W</td> </tr> </tbody> </table> <h5 id="代码查看编辑">代码查看&编辑</h5> <table> <thead> <tr> <th>快捷键说明</th> <th>Windows ｜ Linux</th> <th>MacOS</th> </tr> </thead> <tbody> <tr> <td>进入源代码</td> <td>F4 或 Ctrl + Enter</td> <td>Command + ↓ 或 Command + 鼠标单击</td> </tr> <tr> <td>跳转到代码指定行</td> <td>Ctrl+G</td> <td>Command + L</td> </tr> <tr> <td>跳转到上一个代码编辑的位置</td> <td>Ctrl + Shift + 退格键</td> <td>Command + Option + ← 或 Command+Shift+Delete</td> </tr> <tr> <td>跳转到下一个代码编辑的位置</td> <td> </td> <td>Command + Option + →</td> </tr> <tr> <td>查看类层次结构(继承关系)</td> <td>Ctrl + H</td> <td>Ctrl + H</td> </tr> <tr> <td>查看方法层次结构</td> <td>Ctrl + Shift + H</td> <td>Command + Shift + H</td> </tr> <tr> <td>查看调用层次结构</td> <td>Ctrl + Alt + H</td> <td>Ctrl + Option + H</td> </tr> <tr> <td>插入模版代码</td> <td>Alt + Insert</td> <td>Command + N</td> </tr> <tr> <td>前往子类实现该方法</td> <td>Ctrl + I</td> <td>Ctrl + I</td> </tr> <tr> <td>选择重写父类某个方法</td> <td>Ctrl + O</td> <td>Ctrl + O</td> </tr> <tr> <td>将代码放入条件语句中(if-else/try-catch..)</td> <td>Ctrl + Alt + T</td> <td>Command + Option + T</td> </tr> <tr> <td>删除整行</td> <td>Ctrl + Y</td> <td>Command + Delete</td> </tr> <tr> <td>收起/展开当前代码块</td> <td>Ctrl + 减号键Ctrl + 加号键</td> <td>Command+减号键或Command+加号键</td> </tr> <tr> <td>收起/展开所有代码块</td> <td>Ctrl + Shift + 减号键或 Ctrl + Shift + 加号键</td> <td>Command+Shift+减号键或 Command+Shift+加号键</td> </tr> <tr> <td>复制当前行并另起一行粘贴(不会放到粘贴板)</td> <td>Ctrl + D</td> <td>Command + D</td> </tr> <tr> <td>快速预览查看文档</td> <td>Ctrl + Q</td> <td>Ctrl + J</td> </tr> <tr> <td>预览查看选定方法的参数</td> <td>Ctrl + P</td> <td>Command + P</td> </tr> <tr> <td>显示或直接跳转到方法调用方</td> <td>Ctrl + B 或 Ctrl + 点击</td> <td>Command + B 或 Command + 点击</td> </tr> <tr> <td>显示或直接跳转到方法实现处</td> <td>Ctrl + Alt + B</td> <td>Command + Option + B</td> </tr> <tr> <td>跳转到超类方法处</td> <td>Ctrl + U</td> <td>Command + U</td> </tr> <tr> <td>快速预览方法定义</td> <td>Ctrl + Shift + I</td> <td>Command + Y</td> </tr> <tr> <td>切换项目左侧工具窗口的可见性</td> <td>Alt + 1</td> <td>Command + 1</td> </tr> <tr> <td>添加/取消行注释</td> <td>Ctrl + /</td> <td>Command + /</td> </tr> <tr> <td>添加/取消块注释</td> <td>Ctrl + Shift + /</td> <td>Command + Shift + /</td> </tr> <tr> <td>增加选中的代码块</td> <td>Ctrl + W</td> <td>Option + 向上箭头</td> </tr> <tr> <td>减少选中的代码块</td> <td>Ctrl + Shift + W</td> <td>Option + 向下箭头</td> </tr> <tr> <td>移动到代码块起始位置</td> <td>Ctrl + [</td> <td>Option + Command + [</td> </tr> <tr> <td>移动到代码块结束位置</td> <td>Ctrl + ]</td> <td>Option + Command + ]</td> </tr> <tr> <td>从当前位置选择到代码块起始位置</td> <td>Ctrl + Shift + [</td> <td>Option + Command + Shift + [</td> </tr> <tr> <td>从当前位置选择到代码块结束位置</td> <td>Ctrl + Shift + ]</td> <td>Option + Command + Shift + ]</td> </tr> <tr> <td>包名导入优化</td> <td>Ctrl + Alt + O</td> <td>Control + Option + O</td> </tr> <tr> <td>显示快速修复建议</td> <td>Alt + Enter</td> <td>Option + Enter</td> </tr> <tr> <td>重新格式化代码</td> <td>Ctrl + Alt + L</td> <td>Command + Option + L</td> </tr> <tr> <td>自动修复行缩进</td> <td>Ctrl + Alt + I</td> <td>Ctrl + Option + I</td> </tr> <tr> <td>缩进/取消缩进行</td> <td>Tab 或 Shift + Tab</td> <td>Tab 或 Shift + Tab</td> </tr> <tr> <td>另起一行</td> <td>Shift + Enter</td> <td>Shift + Enter(注意和 Command + Enter 区别：前者光标自动跟进到下一行开头，而后者光标停留在原地)</td> </tr> </tbody> </table> <h5 id="版本控制">版本控制</h5> <table> <thead> <tr> <th>快捷键说明</th> <th>Windows ｜ Linux</th> <th>MacOS</th> </tr> </thead> <tbody> <tr> <td>将项目提交到 VCS（Push）</td> <td>Ctrl + K</td> <td>Command + K</td> </tr> <tr> <td>从 VCS 更新项目（Pull）</td> <td>Ctrl + T</td> <td>Command + T</td> </tr> <tr> <td>查看最近变更</td> <td>Alt + Shift + C</td> <td>Option + Shift + C</td> </tr> <tr> <td>打开 VCS 对话框</td> <td>Alt +`（反引号）</td> <td>Ctrl + V</td> </tr> </tbody> </table> <h5 id="重构相关">重构相关</h5> <table> <thead> <tr> <th>快捷键说明</th> <th>Windows ｜ Linux</th> <th>MacOS</th> </tr> </thead> <tbody> <tr> <td>复制</td> <td>F5</td> <td>Fn + F5</td> </tr> <tr> <td>移动</td> <td>F6</td> <td>FN + F6</td> </tr> <tr> <td>安全删除</td> <td>Alt+Delete</td> <td>Command + Delete</td> </tr> <tr> <td>重命名（方法、属性、文件等）</td> <td>Shift+F6</td> <td>Fn + Shift + F6</td> </tr> <tr> <td>更改方法/属性签名</td> <td>Ctrl+F6</td> <td>Fn + Command + F6</td> </tr> <tr> <td>方法内联（将方法内实现部分提取到方法调用处）</td> <td>Ctrl + Alt + N</td> <td>Command + Option + N</td> </tr> <tr> <td>提取方法</td> <td>Ctrl+Alt+M</td> <td>Command + Option + M</td> </tr> <tr> <td>提取为局部变量</td> <td>Ctrl+Alt+V</td> <td>Command + Option + V</td> </tr> <tr> <td>提取为类成员字段</td> <td>Ctrl+Alt+F</td> <td>Command + Option + F</td> </tr> <tr> <td>提取为常量</td> <td>Ctrl+Alt+C</td> <td>Command + Option + C</td> </tr> <tr> <td>提取为方法参数（e.g,将方法内局部变量提取为通过外部传入）</td> <td>Ctrl+Alt+P</td> <td>Command + Option + P</td> </tr> </tbody> </table> <h5 id="代码调试">代码调试</h5> <table> <thead> <tr> <th>快捷键说明</th> <th>Windows ｜ Linux</th> <th>MacOS</th> </tr> </thead> <tbody> <tr> <td>调试</td> <td>Shift + F9</td> <td>Ctrl+D</td> </tr> <tr> <td>单步跳过</td> <td>F8</td> <td>Fn + F8</td> </tr> <tr> <td>单步进入</td> <td>F7</td> <td>Fn + F7</td> </tr> <tr> <td>智能单步进入</td> <td>Shift + F7</td> <td>Fn + Shift + F7</td> </tr> <tr> <td>单步退出</td> <td>Shift + F8</td> <td>Fn + Shift + F8</td> </tr> <tr> <td>运行到光标位置</td> <td>Alt + F9</td> <td>Fn + Option + F9</td> </tr> <tr> <td>评估表达式</td> <td>Alt + F8</td> <td>Fn + Option + F8</td> </tr> <tr> <td>继续运行程序</td> <td>F9</td> <td>Command + Option + R</td> </tr> <tr> <td>切换断点</td> <td>Ctrl + F8</td> <td>Fn + Command + F8</td> </tr> <tr> <td>查看断点</td> <td>Ctrl + Shift + F8</td> <td>Fn + Command + Shift + F8</td> </tr> </tbody> </table> <h5 id="自定义快捷键">自定义快捷键</h5> Android Studio 还有很多操作没有关联上具体的快捷键，而我们也可以通过自定义的方式来为高频操作绑定上快捷键。只需要到工具栏的 Android Studio 一栏找到 Preference（或用快捷键 <code class="language-plaintext highlighter-rouge">Cmd + ,</code> ）进入设置 <code class="language-plaintext highlighter-rouge">keymap</code> 选项中搜索对应的操作即可。这里以 Sync Project with Gradle Files 操作为例： <img src="/img/in-post/post-skills/image-20230416085732692.png" alt="image-20230416085732692" style="zoom:50%;" /> 接下来只需选中目标项绑定快捷键即可，我这里绑定的快捷键是 <code class="language-plaintext highlighter-rouge">CMd + Option + S</code>。Android Studio 比较智能，如果绑定了已被使用的快捷键会提示冲突问题。 <h3 id="小结">小结</h3> 开发效率即意味着生产力，长时间维持着 996 状态也并不代表生产力就高，相反，我们自身会一直处于高压状态，不利于身心健康。故而，我们应该着手于术，从实际出发，点滴汇聚，提升效率，把时间多专注在享受生活上，而不是庸庸碌碌的“机器命”。 <h3 id="参考">参考</h3> <ul> <li><a href="https://developer.android.google.cn/studio/intro/keyboard-shortcuts?hl=zh-cn">Android Studio shortcuts</a></li> </ul>

2023/4/16

Android系统中线程的创建过程

我们都知道，Android 中线程创建过程需要追溯到 Native 层面，最终是委托给一个 Linux 标准线程 pthread 来执行的，所以 Android 中线程状态本质上是 Native 线程的一种映射。Android 中运行的线程可以分为两种：一种是 attach 到虚拟机的，即虚拟机线程；另一种是没有 attach 到虚拟机的。今天我们就分别从源码层面来看看 Android 系统中 Java 和 Native 层线程的创建过程。 <blockquote> 以下分析基于 <a href="https://cs.android.com">Android 13 最新源码</a>。 </blockquote> <h3 id="java-线程创建过程">Java 线程创建过程</h3> 首先，我们需要知道的是：当我们通过 <code class="language-plaintext highlighter-rouge">new</code> 关键字创建一个 Thread 时其实并没有真正创建一个线程，只有调用 <code class="language-plaintext highlighter-rouge">start</code> 方法后才会去创建线程。先来看下 <code class="language-plaintext highlighter-rouge">start</code> 方法内部实现： <div class="language-java highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 </pre></td><td class="rouge-code"><pre> public synchronized void start() { /** * This method is not invoked for the main method thread or "system" * group threads created/set up by the VM. Any new functionality added * to this method in the future may have to also be added to the VM. * * A zero status value corresponds to state "NEW". */ // Android-changed: Replace unused threadStatus field with started field. // The threadStatus field is unused on Android. if (started) throw new IllegalThreadStateException(); /* Notify the group that this thread is about to be started * so that it can be added to the group's list of threads * and the group's unstarted count can be decremented. */ group.add(this); // Android-changed: Use field instead of local variable. // It is necessary to remember the state of this across calls to this method so that it // can throw an IllegalThreadStateException if this method is called on an already // started thread. started = false; try { // Android-changed: Use Android specific nativeCreate() method to create/start thread. // start0(); nativeCreate(this, stackSize, daemon); started = true; } finally { try { if (!started) { group.threadStartFailed(this); } } catch (Throwable ignore) { /* do nothing. If start0 threw a Throwable then it will be passed up the call stack */ } } } </pre></td></tr></tbody></table></code></pre></div></div> 可以看到，最终线程的创建和执行是在 <code class="language-plaintext highlighter-rouge">nativeCreate</code> 方法中，而它是个 native 方法，对应的实现在 /art/runtime/native/java_lang_Thread.cc 文件中，代码如下： <div class="language-c highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 </pre></td><td class="rouge-code"><pre>static void Thread_nativeCreate(JNIEnv* env, jclass, jobject java_thread, jlong stack_size, jboolean daemon) { // There are sections in the zygote that forbid thread creation. Runtime* runtime = Runtime::Current(); if (runtime->IsZygote() && runtime->IsZygoteNoThreadSection()) { jclass internal_error = env->FindClass("java/lang/InternalError"); CHECK(internal_error != nullptr); env->ThrowNew(internal_error, "Cannot create threads in zygote"); return; } Thread::CreateNativeThread(env, java_thread, stack_size, daemon == JNI_TRUE); } </pre></td></tr></tbody></table></code></pre></div></div> 继续跟踪到 /art/runtime/thread.cc： <div class="language-c highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 </pre></td><td class="rouge-code"><pre>void Thread::CreateNativeThread(JNIEnv* env, jobject java_peer, size_t stack_size, bool is_daemon) { CHECK(java_peer != nullptr); Thread* self = static_cast<JNIEnvExt*>(env)->GetSelf(); ...... int pthread_create_result = 0; if (child_jni_env_ext.get() != nullptr) { pthread_t new_pthread; pthread_attr_t attr; child_thread->tlsPtr_.tmp_jni_env = child_jni_env_ext.get(); CHECK_PTHREAD_CALL(pthread_attr_init, (&attr), "new thread"); CHECK_PTHREAD_CALL(pthread_attr_setdetachstate, (&attr, PTHREAD_CREATE_DETACHED), "PTHREAD_CREATE_DETACHED"); CHECK_PTHREAD_CALL(pthread_attr_setstacksize, (&attr, stack_size), stack_size); pthread_create_result = pthread_create(&new_pthread, &attr, gUseUserfaultfd ? Thread::CreateCallbackWithUffdGc : Thread::CreateCallback, child_thread); CHECK_PTHREAD_CALL(pthread_attr_destroy, (&attr), "new thread"); if (pthread_create_result == 0) { // pthread_create started the new thread. The child is now responsible for managing the // JNIEnvExt we created. // Note: we can't check for tmp_jni_env == nullptr, as that would require synchronization // between the threads. child_jni_env_ext.release(); // NOLINT pthreads API. return; } } ...... } </pre></td></tr></tbody></table></code></pre></div></div> <code class="language-plaintext highlighter-rouge">Thread::CreateNativeThread</code> 方法实现比较多，过滤了一些代码，我们重点关注下里面调用了 <code class="language-plaintext highlighter-rouge">pthread_create</code> 方法： <blockquote> bionic/libc/bionic/pthread_create.cpp </blockquote> <div class="language-c highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 </pre></td><td class="rouge-code"><pre>int pthread_create(pthread_t* thread_out, pthread_attr_t const* attr, void* (*start_routine)(void*), void* arg) { ...... } </pre></td></tr></tbody></table></code></pre></div></div> POSIX 线程（POSIX threads）又简称 Pthreads 是线程的 POSIX 标准，该标准定义了创建和操纵线程的一整套 API，在类 Unix 操作系统（Unix、Linux、Mac OS X等）中都使用 Pthreads 作为操作系统的线程，Windows操作系统也有其移植版 pthreads-win32。简而言之该标准定义内部 API 创建和操纵线程， Pthreads 定义了一套 C 程序语言类型、函数与常量，它以 pthread.h 头文件和一个线程库实现，所以在 Android Studio 使用时直接在 C/C++ 文件中 #include < pthread.h > 引入即可。 该函数是一个线程阻塞函数，调用方将一直等待到线程结束为止，当函数返回时，被等待线程的资源被收回。如果执行成功，将返回 0，如果失败则返回一个错误码。 该函数参数释义如下： <ul> <li>thread_out：线程标识符的指针，pthread_t 类型，即线程 ID（线程创建成功后会将分配的线程 ID 赋值给 thread_out）</li> <li>attr：它是一个结构体类型，用于表示创建线程的相关属性信息，如线程优先级、调度策略等等</li> <li>start_routine：表示线程运行函数的地址</li> <li>arg：代表线程运行函数的参数</li> </ul> 看到这里，基本代表 Java 层面的线程创建路径分析完成了，想更多了解关于 pthread 内容可自行查阅资料。此外，Android 中还有一种 native 线程，即 C/C++ 平台的 Thread 特供版。 <h3 id="native-线程创建">Native 线程创建</h3> 刚刚我们分析了 Java 层面的 Thread 创建流程，下面来简单看下 Android Native 层中的 Thread 是如何创建的。首先我们需要关注一下 system/core/libutils/Threads.cpp 这个文件，里面是针对 Android 平台的 native 层如何创建一个线程的相关封装。 <div class="language-c highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 </pre></td><td class="rouge-code"><pre>status_t Thread::run(const char* name, int32_t priority, size_t stack) { Mutex::Autolock _l(mLock); if (mRunning) { // thread already started return INVALID_OPERATION; } ... mRunning = true; bool res; if (mCanCallJava) { // 创建能调用Java代码的Native线程 res = createThreadEtc(_threadLoop, this, name, priority, stack, &mThread); } else { // 创建只能调用C/C++代码的Native线程 res = androidCreateRawThreadEtc(_threadLoop, this, name, priority, stack, &mThread); } if (res == false) { return UNKNOWN_ERROR; } return NO_ERROR; } </pre></td></tr></tbody></table></code></pre></div></div> <code class="language-plaintext highlighter-rouge">mCanCallJava</code> 是在 Thread 对象创建时的构造参数，在构造函数中默认设置值为 <code class="language-plaintext highlighter-rouge">true</code>。 <ul> <li>当 mCanCallJava 为 true 时，则代表创建的是不仅能调用 C/C++ 代码，还能调用 Java 代码的 Native 线程。</li> <li>当 mCanCallJava 为 false 时，则代表创建的是只能调用 C/C++ 代码的 Native 线程。</li> </ul> 有关两种创建线程模式的方法实现分别在 createThreadEtc 和 androidCreateRawThreadEtc 中，下面来简单分析一下它们的实现链路。 <h5 id="androidcreaterawthreadetc">androidCreateRawThreadEtc</h5> 本方法用于创建仅允许调用 C/C++ 代码的线程。 <blockquote> <a href="https://cs.android.com/android/platform/superproject/+/refs/heads/master:system/core/libutils/Threads.cpp;drc=7346c436e5a11ce08f6a80dcfeb8ef941ca30176;bpv=1;bpt=1;l=117?q=Threads.cpp&ss=android%2Fplatform%2Fsuperproject&gsn=androidCreateRawThreadEtc&gs=KYTHE%3A%2F%2Fkythe%3A%2F%2Fandroid.googlesource.com%2Fplatform%2Fsuperproject%3Flang%3Dc%252B%252B%3Fpath%3Dsystem%2Fcore%2Flibutils%2FThreads.cpp%2326cI-R-PypD1DZioBVZ2i29KWl0Nhu4SxPFXreBRDGI">Threads.cpp#androidCreateRawThreadEtc</a> </blockquote> <div class="language-c highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 </pre></td><td class="rouge-code"><pre>int androidCreateRawThreadEtc(android_thread_func_t entryFunction, void *userData, const char* threadName __android_unused, int32_t threadPriority, size_t threadStackSize, android_thread_id_t *threadId) { pthread_attr_t attr; pthread_attr_init(&attr); pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED); #if defined(__ANDROID__) /* valgrind is rejecting RT-priority create reqs */ if (threadPriority != PRIORITY_DEFAULT || threadName != NULL) { // Now that the pthread_t has a method to find the associated // android_thread_id_t (pid) from pthread_t, it would be possible to avoid // this trampoline in some cases as the parent could set the properties // for the child. However, there would be a race condition because the // child becomes ready immediately, and it doesn't work for the name. // prctl(PR_SET_NAME) only works for self; prctl(PR_SET_THREAD_NAME) was // proposed but not yet accepted. thread_data_t* t = new thread_data_t; t->priority = threadPriority; t->threadName = threadName ? strdup(threadName) : NULL; t->entryFunction = entryFunction; t->userData = userData; entryFunction = (android_thread_func_t)&thread_data_t::trampoline; userData = t; } #endif if (threadStackSize) { pthread_attr_setstacksize(&attr, threadStackSize); } errno = 0; pthread_t thread; int result = pthread_create(&thread, &attr, (android_pthread_entry)entryFunction, userData); pthread_attr_destroy(&attr); if (result != 0) { ALOGE("androidCreateRawThreadEtc failed (entry=%p, res=%d, %s)\n" "(android threadPriority=%d)", entryFunction, result, strerror(errno), threadPriority); return 0; } // Note that *threadID is directly available to the parent only, as it is // assigned after the child starts. Use memory barrier / lock if the child // or other threads also need access. if (threadId != nullptr) { *threadId = (android_thread_id_t)thread; // XXX: this is not portable } return 1; } </pre></td></tr></tbody></table></code></pre></div></div> 可以看到，上面代码首先做了一些线程对象的属性赋值，然后分配线程的栈空间，接着是通过 pthread 来创建一个线程，线程创建成功则返回 1。值得注意的是，这里的 <code class="language-plaintext highlighter-rouge">entryFunction</code> 其实就是之前代码中传进来的 <code class="language-plaintext highlighter-rouge">_threadLoop</code> 函数： <div class="language-c highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 </pre></td><td class="rouge-code"><pre>int Thread::_threadLoop(void* user) { Thread* const self = static_cast<Thread*>(user); sp<Thread> strong(self->mHoldSelf); wp<Thread> weak(strong); self->mHoldSelf.clear(); #if defined(__ANDROID__) // this is very useful for debugging with gdb self->mTid = gettid(); #endif bool first = true; do { bool result; if (first) { first = false; self->mStatus = self->readyToRun(); result = (self->mStatus == OK); if (result && !self->exitPending()) { // Binder threads (and maybe others) rely on threadLoop // running at least once after a successful ::readyToRun() // (unless, of course, the thread has already been asked to exit // at that point). // This is because threads are essentially used like this: // (new ThreadSubclass())->run(); // The caller therefore does not retain a strong reference to // the thread and the thread would simply disappear after the // successful ::readyToRun() call instead of entering the // threadLoop at least once. result = self->threadLoop(); } } else { result = self->threadLoop(); } // establish a scope for mLock { Mutex::Autolock _l(self->mLock); if (result == false || self->mExitPending) { self->mExitPending = true; self->mRunning = false; // clear thread ID so that requestExitAndWait() does not exit if // called by a new thread using the same thread ID as this one. self->mThread = thread_id_t(-1); // note that interested observers blocked in requestExitAndWait are // awoken by broadcast, but blocked on mLock until break exits scope self->mThreadExitedCondition.broadcast(); break; } } // Release our strong reference, to let a chance to the thread // to die a peaceful death. strong.clear(); // And immediately, re-acquire a strong reference for the next loop strong = weak.promote(); } while(strong != nullptr); return 0; } </pre></td></tr></tbody></table></code></pre></div></div> 通过上述代码不难发现：_threadLoop 内部会循环调用 Thread 对象的成员方法 <code class="language-plaintext highlighter-rouge">threadLoop</code>，该成员方法一般由派生类来自行实现。该线程将会在下面几种情况退出循环： <ul> <li>线程状态错误，即 mStatus != OK</li> <li>线程即将退出，调用 Thread::requestExit() 时会触发</li> <li>线程的强引用被释放，无法继续将弱引用提升为强引用</li> </ul> <h5 id="createthreadetc">createThreadEtc</h5> 本方法用于创建允许调用 C/C++ 和 Java 代码的线程。 <blockquote> <a href="https://cs.android.com/android/platform/superproject/+/refs/heads/master:system/core/libutils/include/utils/AndroidThreads.h;drc=7346c436e5a11ce08f6a80dcfeb8ef941ca30176;bpv=1;bpt=1;l=104?gsn=createThreadEtc&gs=KYTHE%3A%2F%2Fkythe%3A%2F%2Fandroid.googlesource.com%2Fplatform%2Fsuperproject%3Flang%3Dc%252B%252B%3Fpath%3Dsystem%2Fcore%2Flibutils%2Finclude%2Futils%2FAndroidThreads.h%23tT-K0gHAowaJ7f3TSwiqGCfDqOT3WNg0_49y9_WYVp0">system/core/libutils/include/utils/AndroidThreads.h#createThreadEtc</a> </blockquote> <div class="language-c highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 </pre></td><td class="rouge-code"><pre>// Create thread with lots of parameters inline bool createThreadEtc(thread_func_t entryFunction, void *userData, const char* threadName = "android:unnamed_thread", int32_t threadPriority = PRIORITY_DEFAULT, size_t threadStackSize = 0, thread_id_t *threadId = nullptr) { return androidCreateThreadEtc(entryFunction, userData, threadName, threadPriority, threadStackSize, threadId) ? true : false; } </pre></td></tr></tbody></table></code></pre></div></div> 继续跟踪 <code class="language-plaintext highlighter-rouge">androidCreateThreadEtc</code> 函数： <div class="language-c highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 </pre></td><td class="rouge-code"><pre>static android_create_thread_fn gCreateThreadFn = androidCreateRawThreadEtc; int androidCreateThreadEtc(android_thread_func_t entryFunction, void *userData, const char* threadName, int32_t threadPriority, size_t threadStackSize, android_thread_id_t *threadId) { return gCreateThreadFn(entryFunction, userData, threadName, threadPriority, threadStackSize, threadId); } void androidSetCreateThreadFunc(android_create_thread_fn func) { gCreateThreadFn = func; } </pre></td></tr></tbody></table></code></pre></div></div> 看到这里可以发现继续调用了 <code class="language-plaintext highlighter-rouge">gCreateThreadFn</code> 函数，而该函数会被调用方在其他地方赋值代理掉，所以我们需要找到调用 <code class="language-plaintext highlighter-rouge">androidSetCreateThreadFunc</code> 函数的地方，最终锁定在了 <a href="https://cs.android.com/android/platform/superproject/+/refs/heads/master:frameworks/base/core/jni/AndroidRuntime.cpp;l=1685;drc=7346c436e5a11ce08f6a80dcfeb8ef941ca30176;bpv=1;bpt=1">frameworks/base/core/jni/AndroidRuntime.cpp</a> 这个文件： <div class="language-c highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 </pre></td><td class="rouge-code"><pre>/* * Register android native functions with the VM. */ /*static*/ int AndroidRuntime::startReg(JNIEnv* env) { ATRACE_NAME("RegisterAndroidNatives"); /* * This hook causes all future threads created in this process to be * attached to the JavaVM. (This needs to go away in favor of JNI * Attach calls.) */ androidSetCreateThreadFunc((android_create_thread_fn) javaCreateThreadEtc); ALOGV("--- registering native functions ---\n"); /* * Every "register" function calls one or more things that return * a local reference (e.g. FindClass). Because we haven't really * started the VM yet, they're all getting stored in the base frame * and never released. Use Push/Pop to manage the storage. */ env->PushLocalFrame(200); if (register_jni_procs(gRegJNI, NELEM(gRegJNI), env) < 0) { env->PopLocalFrame(NULL); return -1; } env->PopLocalFrame(NULL); //createJavaThread("fubar", quickTest, (void*) "hello"); return 0; } </pre></td></tr></tbody></table></code></pre></div></div> 由此看来，Android 系统会在向虚拟机中注册 native 方法时将 gCreateThreadFn 指定向 <code class="language-plaintext highlighter-rouge">javaCreateThreadEtc</code> 这个函数。那么我们就来看下 javaCreateThreadEtc 内部实现如何： <blockquote> <a href="https://cs.android.com/android/platform/superproject/+/refs/heads/master:frameworks/base/core/jni/AndroidRuntime.cpp;drc=7346c436e5a11ce08f6a80dcfeb8ef941ca30176;bpv=1;bpt=1;l=1442?gsn=javaCreateThreadEtc&gs=KYTHE%3A%2F%2Fkythe%3A%2F%2Fandroid.googlesource.com%2Fplatform%2Fsuperproject%3Flang%3Dc%252B%252B%3Fpath%3Dframeworks%2Fbase%2Fcore%2Fjni%2FAndroidRuntime.cpp%23Hu_OOm1g4JDVMfzDHU98HuMryIeU8hbMIVcQhf8k4vY">frameworks/base/core/jni/AndroidRuntime.cpp#javaCreateThreadEtc</a> </blockquote> <div class="language-c highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 </pre></td><td class="rouge-code"><pre>/* * This is invoked from androidCreateThreadEtc() via the callback * set with androidSetCreateThreadFunc(). * * We need to create the new thread in such a way that it gets hooked * into the VM before it really starts executing. */ /*static*/ int AndroidRuntime::javaCreateThreadEtc( android_thread_func_t entryFunction, void* userData, const char* threadName, int32_t threadPriority, size_t threadStackSize, android_thread_id_t* threadId) { void** args = (void**) malloc(3 * sizeof(void*)); // javaThreadShell must free int result; LOG_ALWAYS_FATAL_IF(threadName == nullptr, "threadName not provided to javaCreateThreadEtc"); args[0] = (void*) entryFunction; args[1] = userData; args[2] = (void*) strdup(threadName); // javaThreadShell must free result = androidCreateRawThreadEtc(AndroidRuntime::javaThreadShell, args, threadName, threadPriority, threadStackSize, threadId); return result; } </pre></td></tr></tbody></table></code></pre></div></div> 根据官方给出的注释可以知道：<code class="language-plaintext highlighter-rouge">javaCreateThreadEtc</code> 函数从 <code class="language-plaintext highlighter-rouge">androidCreateThreadEtc</code> 中通过 <code class="language-plaintext highlighter-rouge">androidSetCreateThreadFunc</code> 设置的回调来进行调用的，即在线程真正开始执行之前被 Hook 到虚拟机中。我们接着来看下真正实现的 androidCreateRawThreadEtc 函数： <div class="language-c highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 </pre></td><td class="rouge-code"><pre>int androidCreateRawThreadEtc(android_thread_func_t entryFunction, void *userData, const char* threadName __android_unused, int32_t threadPriority, size_t threadStackSize, android_thread_id_t *threadId) { pthread_attr_t attr; pthread_attr_init(&attr); pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED); #if defined(__ANDROID__) /* valgrind is rejecting RT-priority create reqs */ if (threadPriority != PRIORITY_DEFAULT || threadName != NULL) { // Now that the pthread_t has a method to find the associated // android_thread_id_t (pid) from pthread_t, it would be possible to avoid // this trampoline in some cases as the parent could set the properties // for the child. However, there would be a race condition because the // child becomes ready immediately, and it doesn't work for the name. // prctl(PR_SET_NAME) only works for self; prctl(PR_SET_THREAD_NAME) was // proposed but not yet accepted. thread_data_t* t = new thread_data_t; t->priority = threadPriority; t->threadName = threadName ? strdup(threadName) : NULL; t->entryFunction = entryFunction; t->userData = userData; entryFunction = (android_thread_func_t)&thread_data_t::trampoline; userData = t; } #endif if (threadStackSize) { pthread_attr_setstacksize(&attr, threadStackSize); } errno = 0; pthread_t thread; int result = pthread_create(&thread, &attr, (android_pthread_entry)entryFunction, userData); pthread_attr_destroy(&attr); if (result != 0) { ALOGE("androidCreateRawThreadEtc failed (entry=%p, res=%d, %s)\n" "(android threadPriority=%d)", entryFunction, result, strerror(errno), threadPriority); return 0; } // Note that *threadID is directly available to the parent only, as it is // assigned after the child starts. Use memory barrier / lock if the child // or other threads also need access. if (threadId != nullptr) { *threadId = (android_thread_id_t)thread; // XXX: this is not portable } return 1; } </pre></td></tr></tbody></table></code></pre></div></div> 该函数实现在 androidCreateRawThreadEtc 章节就已经分析过了，只不过这里的 <code class="language-plaintext highlighter-rouge">entryFunction</code> 传过来的是 AndroidRuntime::javaThreadShell，我们来看下它内部如何实现的： <blockquote> <a href="https://cs.android.com/android/platform/superproject/+/refs/heads/master:frameworks/base/core/jni/AndroidRuntime.cpp;drc=7346c436e5a11ce08f6a80dcfeb8ef941ca30176;bpv=1;bpt=1;l=1413?gsn=javaThreadShell&gs=KYTHE%3A%2F%2Fkythe%3A%2F%2Fandroid.googlesource.com%2Fplatform%2Fsuperproject%3Flang%3Dc%252B%252B%3Fpath%3Dframeworks%2Fbase%2Fcore%2Fjni%2FAndroidRuntime.cpp%232dRQv8aW1yl_ahrbBQXwWUKL7oGOgfdloD9ALdX35aU">frameworks/base/core/jni/AndroidRuntime.cpp</a> </blockquote> <div class="language-c highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 </pre></td><td class="rouge-code"><pre>/* * When starting a native thread that will be visible from the VM, we * bounce through this to get the right attach/detach action. * Note that this function calls free(args) */ /*static*/ int AndroidRuntime::javaThreadShell(void* args) { void* start = ((void**)args)[0]; void* userData = ((void **)args)[1]; char* name = (char*) ((void **)args)[2]; // we own this storage free(args); JNIEnv* env; int result; /* hook us into the VM */ if (javaAttachThread(name, &env) != JNI_OK) return -1; /* start the thread running */ result = (*(android_thread_func_t)start)(userData); /* unhook us */ javaDetachThread(); free(name); return result; } </pre></td></tr></tbody></table></code></pre></div></div> javaThreadShell 函数比较重要，综合上下文不难发现，代码中的局部变量 <code class="language-plaintext highlighter-rouge">start</code> 代表的是 _threadLoop，<code class="language-plaintext highlighter-rouge">userData</code> 代表 Thread 对象，而 <code class="language-plaintext highlighter-rouge">name</code> 指向线程的名称。接着继续调用了 <code class="language-plaintext highlighter-rouge">javaAttachThread</code> 函数，用于将线程 hook 到当前进程的虚拟机中，进而执行 Java 代码。紧接着继续执行线程自身的逻辑，即调用成员函数 <code class="language-plaintext highlighter-rouge">threadLoop</code>；线程执行完毕后调用了 <code class="language-plaintext highlighter-rouge">javaDetachThread</code> 函数用于将线程从虚拟机中剥离。下面重点看下 javaAttachThread 内部是如何将线程 hook 至虚拟机的： <div class="language-c highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 </pre></td><td class="rouge-code"><pre>/* * Makes the current thread visible to the VM. * * The JNIEnv pointer returned is only valid for the current thread, and * thus must be tucked into thread-local storage. */ static int javaAttachThread(const char* threadName, JNIEnv** pEnv) { JavaVMAttachArgs args; JavaVM* vm; jint result; vm = AndroidRuntime::getJavaVM(); assert(vm != NULL); args.version = JNI_VERSION_1_4; args.name = (char*) threadName; args.group = NULL; result = vm->AttachCurrentThread(pEnv, (void*) &args); if (result != JNI_OK) ALOGI("NOTE: attach of thread '%s' failed\n", threadName); return result; } </pre></td></tr></tbody></table></code></pre></div></div> 可以看见 javaAttachThread 中又调用了 AttachCurrentThread 函数，该函数可以将 native 线程附加到进程的 VM 中，详细参见官方 JNI 文档：<a href="https://developer.android.com/training/articles/perf-jni?hl=zh-cn#threads">JNI 提示</a> 接着可以在 runtime 中找到 CheckAttachThread 实现： <div class="language-c highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 </pre></td><td class="rouge-code"><pre>// Check whether the current thread is attached. This is usually required // to be the first check, as ScopedCheck needs a ScopedObjectAccess for // checking heap values (and that will fail with unattached threads). bool CheckAttachedThread(const char* function_name) { Thread* self = Thread::Current(); if (UNLIKELY(self == nullptr)) { // Need to attach this thread for a proper abort to work. We prefer this // to get reasonable stacks and environment, rather than relying on // tombstoned. JNIEnv* env; Runtime::Current()->GetJavaVM()->AttachCurrentThread(&env, /* thr_args= */ nullptr); std::string tmp = android::base::StringPrintf( "a thread (tid %" PRId64 " is making JNI calls without being attached", static_cast<int64_t>(GetTid())); Runtime::Current()->GetJavaVM()->JniAbort(function_name, tmp.c_str()); CHECK_NE(Runtime::Current()->GetJavaVM()->DetachCurrentThread(), JNI_ERR); return false; } return true; } </pre></td></tr></tbody></table></code></pre></div></div> 好吧，里面又调用了 GetJavaVM()-> AttachCurrentThread，看来我们还得继续跟下去，不过为了节省中间若干个类文件跳转环节，这里直接指出最终目的地在 <code class="language-plaintext highlighter-rouge">Runtime::AttachCurrentThread</code> 函数里面： <blockquote> <a href="https://cs.android.com/android/platform/superproject/+/refs/heads/master:art/runtime/runtime.cc;drc=7346c436e5a11ce08f6a80dcfeb8ef941ca30176;bpv=1;bpt=1;l=2428?gsn=AttachCurrentThread&gs=KYTHE%3A%2F%2Fkythe%3A%2F%2Fandroid.googlesource.com%2Fplatform%2Fsuperproject%3Flang%3Dc%252B%252B%3Fpath%3Dart%2Fruntime%2Fruntime.cc%23Q56GPTk2CWJsQUdZAdwYiLpyNr6vSrIH3nWc6hCz66k">art/runtime/runtime.cc</a> </blockquote> <div class="language-c highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 </pre></td><td class="rouge-code"><pre>bool Runtime::AttachCurrentThread(const char* thread_name, bool as_daemon, jobject thread_group, bool create_peer, bool should_run_callbacks) { ScopedTrace trace(__FUNCTION__); Thread* self = Thread::Attach(thread_name, as_daemon, thread_group, create_peer, should_run_callbacks); // Run ThreadGroup.add to notify the group that this thread is now started. if (self != nullptr && create_peer && !IsAotCompiler()) { ScopedObjectAccess soa(self); self->NotifyThreadGroup(soa, thread_group); } return self != nullptr; } </pre></td></tr></tbody></table></code></pre></div></div> 这里其实就是将线程在 JavaVM 层面包装成一个 VM 上的线程再返回给 self。接下来就不继续往下深究了，篇幅有限，本文先讲到这里，里面还涉及到很多 JavaVM 相关的细节及原理将在后续文章中做一个补充。 顺带提一嘴，Android SDK 中的 Thread 与 JDK 中的 java.lang.Thread 实际上是有区别的，虽然 Android 也使用 Java 语言开发，但Android 基于平台特殊性对 JDK 进行了一些删减和改造。我们都知道 Java 是具有跨平台特性的，同一套代码它完全可以在 Windows、Linux 等操作系统上正常运作，但其实内部的线程创建等细节是基于 OS 的特性进行各自实现的： <img src="/img/in-post/post-android/java_thread_creation.png" alt="java_thread_creation" /> <blockquote> 想了解更多关于 Java 线程的启动过程可以参考<a href="https://zhuanlan.zhihu.com/p/439797698">此文</a>。 </blockquote> <h3 id="总结">总结</h3> 我们通过在 Java 层面创建线程的时候，VM 会包装成一个 VM 的 Thread，然后启动 pthread，再调用 run 方法，但我们通过 pthread 独立创建的线程，是没有和 VM 里面的线程对象建立关联的，VM 压根不知道它的存在。但是如果该线程想要访问 Java代码，这就得需 VM 帮忙，故而需要将 native 层自己创建的线程包装成一个 VM 层面的 Thread 对象，然后添加到 VM 的 thread 集合中去，如此一来，Android 的虚拟机就可以感知到 native 中这个线程对象的存在了。 <h3 id="相关参考">相关参考</h3> <ul> <li><a href="https://cs.android.com/android/platform/superproject/+/master:art/runtime/native/java_lang_Thread.cc">runtime/native/java_lang_Thread.cc</a></li> <li><a href="https://cs.android.com/android/platform/superproject/+/master:system/core/libutils/Threads.cpp">system/core/libutils/Threads.cpp</a></li> <li><a href="https://cs.android.com/android/platform/superproject/+/refs/heads/master:system/core/libutils/include/utils/Thread.h">system/core/libutils/include/utils/Thread.h</a></li> <li><a href="https://blog.csdn.net/u012430727/article/details/115239992">Android native/C++层Thread线程实现源码分析</a></li> <li><a href="https://keeplooking.top/2020/05/19/Android/AttachCurrentThread/">JNI为什么要调用AttachCurrentThread</a></li> </ul>

2023/4/7