2、Android 系统架构与 WebKit：Android 系统分层、WebKit 在 Android 中的位置、WebView 与 WebKit 的关系、Chromium WebView 的演进
好，咱们今天聊聊 Android 系统架构和 WebKit 的关系。说实话，我刚入行那会儿，也搞不清楚 WebView 到底是个什么玩意儿。它到底是一个浏览器？还是一个组件？跟 WebKit 又是什么关系？
嗯，别急。我们一层层剥开来看。
Android 系统分层：从底层到上层
Android 系统本身是分层的。你想想看，一个手机要跑起来，硬件、驱动、操作系统、应用框架，缺一不可。我习惯把 Android 分成这么几层：
- Linux 内核层：这是地基。内存管理、进程调度、网络协议栈，全在这里。WebKit 的沙箱机制、多进程架构，最终都要依赖这一层。
- 硬件抽象层（HAL）：把硬件差异封装起来。比如 GPU 驱动、显示驱动。WebKit 渲染页面时，最终要通过 HAL 把画面画到屏幕上。
- 系统运行时层：包含 ART（Android Runtime）、核心库。WebKit 的 JavaScript 引擎 V8 就运行在这一层。
- 应用框架层：我们开发者最熟悉的一层。Activity、Service、ContentProvider，还有我们今天的主角——WebView，都在这里。
- 应用层：你写的 App，用户用的浏览器，都在最上面。
核心观点：WebKit 不是一个 App，它是一套底层渲染引擎。它横跨了系统运行时层和应用框架层。
WebKit 在 Android 中的位置
WebKit 在 Android 里到底待在哪？我直接说结论：它不在 Linux 内核里，也不在应用层。它藏在系统框架层和运行时层之间。
具体来说：
- libwebcore.so：这是 WebKit 的核心库。解析 HTML、构建 DOM 树、布局、渲染，全在这里。它运行在系统进程中。
- chromium_webview.so：这是 Chromium 版本的 WebView 核心库。从 Android 5.0 开始，Google 用 Chromium 替换了原来的 WebKit。后面我会细讲。
- android.webkit.WebView：这是 Java 层的封装。你写代码时 new 一个 WebView，实际上它通过 JNI 调用底层的 C++ 库。
我在项目中遇到过一个问题：某个页面在 Chrome 浏览器里显示正常，但在 WebView 里就崩了。排查了半天，发现是 WebView 的渲染管线跟系统 SurfaceFlinger 的同步机制有冲突。说白了，就是底层渲染的节奏没对上。
避坑指南：我曾经以为 WebView 就是一个小 Chrome。其实不是。WebView 的进程模型、内存管理、GPU 渲染路径，跟 Chrome 浏览器有细微差别。调试时一定要用 WebView 专用的 DevTools 协议。
WebView 与 WebKit 的关系
这个问题，我经常被问到。简单来说：WebView 是壳，WebKit 是核。
WebView 提供的是 Java 层的 API。比如：
loadUrl()：加载网页evaluateJavascript()：执行 JSsetWebViewClient()：监听页面加载状态
而 WebKit 负责的是底层工作：
- 解析 HTML/CSS/JS
- 构建渲染树
- 执行布局计算
- 调用 Skia 或 OpenGL 进行绘制
你可以把 WebView 想象成一个遥控器，WebKit 是电视机里的电路板。你按遥控器上的按钮（调用 WebView API），电路板（WebKit）就去执行对应的操作。
注意：WebView 和 WebKit 的版本不是一一对应的。同一个 Android 系统上，WebView 的版本可能比系统自带的 WebKit 版本新。这是因为 Google 通过 Google Play 服务独立更新 WebView。
Chromium WebView 的演进
这个演进过程，我亲身经历过。从 Android 4.4 到现在的 Android 14，WebView 经历了三次大变革。
| Android 版本 | WebView 内核 | 特点 |
|---|---|---|
| 4.4 (KitKat) | Chromium WebView (初始版) | 从 WebKit 切换到 Chromium，性能提升明显 |
| 5.0 (Lollipop) | 独立更新的 WebView | 通过 Google Play 独立更新，不再依赖系统 OTA |
| 7.0 (Nougat) | Chrome 与 WebView 分离 | WebView 不再捆绑 Chrome，使用独立的 APK |
| 10.0+ | Trichrome WebView | Chrome、WebView、Google Play 服务共享同一套底层库 |
为什么 Google 要这么折腾？说白了，就是为了解决碎片化问题。以前 WebView 是跟系统绑定的，系统不升级，WebView 就永远是个老版本。现在好了，通过 Google Play 服务，WebView 可以独立更新，安全补丁和性能优化能快速推送到用户手机上。
我记得在 Android 5.0 刚推出独立更新时，我们团队还专门做了兼容性测试。结果发现，同一个 App 在不同手机上，WebView 的行为居然不一样。有的支持 WebRTC，有的不支持。嗯，这就是独立更新带来的副作用——版本碎片化从系统层转移到了 WebView 层。
架构图：WebKit 在 Android 中的位置
下面这张图，是我自己画的。它展示了 WebKit 在 Android 系统各层中的位置，以及 WebView 如何与底层交互。
从这张图你可以看到，WebKit 并不直接跟硬件打交道。它通过 HAL 调用 GPU 进行加速渲染，通过 Linux 内核管理网络请求和内存分配。而 WebView 作为 Java 层的封装，只是提供了一个让 App 开发者方便调用的接口。
总结一下：Android 系统架构是分层的，WebKit 位于运行时层，WebView 是它在应用框架层的 Java 封装。Chromium WebView 的演进，本质上是 Google 为了解决碎片化、提升渲染性能而做的一系列架构调整。
嗯，这一章的内容就到这里。下一章我们会深入 WebKit 的渲染管线，看看一个 URL 是怎么变成屏幕上的像素的。到时候我会分享一个我调试过的真实案例，保证让你印象深刻。