Chromeium 服务模型

目的

将Chrome代码库移至面向服务的模型。这将产生可重用和解耦的组件，同时还减少重复。它也允许Chrome小组和其他小组尝试新功能，而无需修改Chrome。

 

背景

Chrome的体系结构存在各种问题和局限性：

1. 组件一致性差：
   • 特定于功能的代码散布在不同的模块和流程中，例如平台和浏览器功能以及Blink和[chrome，组件，内容] /浏览器+渲染器中的代码。
   • 似乎不相关的功能具有直接或间接的依赖关系纠缠，从而难以隔离离散的服务代码以实现重用，安全性和稳定性（例如，网络服务）。
2. 复制/不必要的复杂性：
   • 浏览器进程的许多特定于功能的IPC可以由一小组较少的通用服务API适当地替换。例如，胡椒，内容，扩展等模块中的代码通常具有类似的代码，用于代理浏览器以处理许可请求，通知，配额，磁盘访问，资源加载等。
   • 功能会实现自己的绑定层（例如，扩展，WebUI）。
   • 常见的操作（网络，首选项等）的访问方式取决于调用代码的过程。
3. 可扩展性差：
   • 缺乏灵活的API和模块化意味着通常必须直接在浏览器中内置实验和新功能，从而进一步增加复杂性和膨胀度（例如Stars，Blimp，PDF）或被完全禁止（Flutter，Dart，Cardboard）。
   • 无法为Chrome代码库的特殊用途（即，用于Headless Chrome＆Blimp项目）插入不同的核心服务（网络，磁盘）实现。
4. 泄漏抽象：
   • 在未以相同方式实现接口的平台上，代码重用变得更加困难（例如，iOS上的WKWebView与WebContents）
   • 诸如WebContents的核心抽象假定托管渲染器是Blink的实例，这为PDF和Blimp之类的功能增加了不必要的开销。
   • 由于平台差异（例如，Android上的gpu代码使用不同的代码路径）或安全性和稳定性方面的改进（例如，网络和配置文件流程），很难将服务移至其他流程。

 

上述限制有两个主要原因。首先是代码库被简单地推动来完成许多其原本不适合的功能。从一开始，团队就有意识地选择不过度设计代码和体系结构，直到有明显需求为止。第二个原因是，在急于添加新功能和支持新平台的过程中，我们没有停下来重新考虑分层。有了Mojo现在提供给我们的工具，从Mandoline汲取的经验教训以及对代码库进行长期重构的承诺，我们就有机会将体系结构转移到更加模块化和灵活的体系结构上。

 

总览

我们建议通过将代码移至服务模型来解决上面列出的各种问题。鉴于Chrome现在托管了许多平台（例如，网络平台，Pepper插件，扩展程序，NaCl，Mojo Apps，Chrome应用，Android应用），因此应该使用许多系统（例如OS）中常见的分层模型来构建Chrome。最终目标应该是拥有一组共享服务，在这些共享服务上可以层叠其他服务和功能。

 

这些服务将通过Mojo接口公开，该接口隐藏有关调用方和实现方位置的详细信息。它将允许任何一方转移到不同的流程，从而轻松地改进系统。网络是一个示例：拥有网络服务后，我们可以选择将其运行在进程外以提高稳定性/安全性，如果资源有限，也可以在进程内运行。如果消费者仅通过Mojo接口与网络服务进行通信，那么对他们来说透明的网络实际发生位置。 Mojo还可以通过避免重复的实现（取决于调用者使用的进程，模块或语言）来允许代码重用。通过检查当前系统的IPC文件，可以看到一组初始的共享服务。它们包括：文件，网络，首选项，leveldb，同步，通知，权限，配额，剪贴板，发布/订阅等。这些服务的创建应通过将当前代码转换为使用这些新服务来驱动。

 

同样，浏览器功能应通过Mojo接口公开其API。通过适当的安全检查，应该可以从其他过程和语言访问它们。这样可以避免支持某个功能的多个API。它还将允许使用不同的实现方式，例如由Chrome小组或Google的其他小组探索浏览器的新功能。如果某个功能需要与渲染引擎进行交互，则应使用Mojo接口来实现，该接口由Blink，iOS以及将来可能添加的内容处理程序（见下文）透明实现。

 

专案

• 创建供多个功能使用或基于其他服务的“基础”服务。当我们转换功能或简化代码时，这应该由需求驱动。有关启动程序服务及其合理性的建议列表，请参阅此文档。当我们创建服务时，目标应该是使用该通用功能转换尽可能多的代码。初始设置包括：
  • UI（渲染和输入）（音乐）
  • 网络（作为概图，请参阅Mandoline的mojo / services / network / public / interfaces /）
  • 文件（作为粗略的草图，请参阅Mandoline的components / filesystem / public / interfaces /）
  • 级别数据库
  • 同步化
  • 酒馆/酒馆
  • 偏爱
  • 允许
  • 剪贴板
  • 通知事项
  • 追踪
  • WebView（导航，框架树）
• 通过使用上方的核心服务分层实现，将跨越浏览器和渲染器的Web平台实现转换为仅在渲染器中实现。起始集：
  • 本地存储：详细设计
  • 会话存储
  • 索引数据库
  • 文件系统
• 为从扩展API和WebUI调用的浏览器功能创建Mojo接口。然后，扩展JS填充程序可以直接从渲染器进程中调用它们。同样对于WebUI，让页面调用功能的Mojo接口，而不是手动编写绑定。
• 重构跨越浏览器和渲染器进程的浏览器组件，以通过Mojo界面调用HTML引擎。
  • 从所有分层的组件开始，因为这会删除一个额外的层来处理iOS /内容。
  • 完成浏览器的其余功能（即未与iOS共享的Chrome功能）。

代码位置

提取的服务位于//服务中。有关更多信息，请参见该目录中的README.md。提取的库代码应移至有意义的位置（例如src / components，src / ui等）

 

追踪错误

https://bugs.chromium.org/p/chromium/issues/detail?id=598069

 

范围与非目标

服务工作的目的不是使所有Chrome功能都使用Mojo相互交谈，也不是将每个功能或界面分解成自己的过程。基本上，我们不打算复制早期在壁虎中使用XPCOM的方式。

 

相反，您可以将该项目视为通过以下方式对Chrome从Chrome IPC到Mojo的转换的增强：

 

• 几个Chrome IPC界面的实现中存在的常见用例被公开为一个较低级别的设计良好的通用界面，从而允许将特定功能的代码移入客户端。
• 给定这些接口的模块化，就可以将实现重新定位到另一个进程，而无需更新调用代码。

 

此外，您应该将Mojo视为在可能需要隔离一段代码的情况下使用的工具，而不是默认使用Mojo代替诸如简单函数调用和PostTask（）之类的更显而易见的技术。

 

附录A：未来的项目

上面的项目可以对我们多年来一直想要的Chrome架构进行进一步的改进，但是到目前为止，实施起来过于复杂。一些例子：

• 在单独的沙盒过程中运行网络代码。对于Windows，由于外部软件通过LSP等将其挂接，所以这将有助于提高稳定性。我们还可以将此代码沙箱化（不如渲染器强大，但比没有沙箱的浏览器更好）。可以分阶段进行，每个级别都有其自身的优势并最终达到一个单独的过程：
  • 汇聚所有代码以通过相同的API发出网络请求（即，无论调用代码是在渲染器进程中还是在浏览器进程中）。这将简化代码，并允许Blimp等项目轻松覆盖HTTP和套接字请求等的实现。
  • 浏览器进程中同步挂接到网络层的代码需要使用异步API。这将清除网络库的公共接口。
  • 将网络代码移到一个单独的进程。这将提高稳定性和安全性。如果所有的Chrome都未运行，它还将允许通过其他功能发出网络请求。
• 在Chrome中实施Mojo Shell的内容处理程序概念。这将允许新功能/实验显示其内容并获取输入事件，而无需更改代码中的其他子系统来支持它们。这很可能取决于使用Mojo UI服务的Chrome。
• 在只能访问配置文件目录的沙盒进程中运行每个配置文件文件服务。因此，大多数访问磁盘的代码都将受到保护，以防止被读取/写入其他目录的漏洞利用。我们将需要文件服务的多个实例，其中之一可以访问整个文件系统，以在需要它的浏览器中获取代码。脚步：
  • 将子进程中的文件系统访问权限转换为使用文件服务
  • 在浏览器中转换文件访问权限（在我们控制的代码中）以同时使用文件服务
• 关闭浏览器后再运行它的一小部分。目前这是不可能的，因为所有代码都相互依赖。使用服务模型，可以仅运行所需的少量服务。一些例子：
  • ARC运行时（与Chrome分开运行）需要Chrome提供大量服务。第一步，我们必须使用接口手动包装它们。要在没有Chrome的情况下运行ARC，第二步要求在Chrome不运行时所有这些服务都可用。
  • 在桌面设备上，如果浏览器关闭，我们希望显示通知。