Chrome基础服务
基于Mojo的服务通常放置在//services目录下，因此，了解该目录的结构十分必要。
前言
该目录包含了Chrome基础服务。如果你将Chrome看做是移动操作系统，Chrome基础服务可以看做是这个操作系统中基础的系统服务层。
这里的每一个子目录大致对应了一个服务：
- 是// services / service_manager的客户端，具有自己的唯一标识
- 依赖宿主操作系统的限制，基础服务可以逻辑上运行在一个独立的进程，这样可以得到安全/性能隔离的收益
API标准
如上所属，//services目录下的各个服务旨在优雅的实现跨平台多用例的重用性。为了达到这个目标，我们对服务API标准提出了严格的要求。在开始针对//services目录做大量工作前（特别是成为某项服务的owner前），请熟用该标准 - 你有责任维护他们。
服务目录结构
每个服务的结构如下：
依赖
//services目录下的代码只能通过该目录下的每个子目录的/public/目录的头文件相互依赖，因此，实现代码也许无法直接共享。
服务代码还应该注意不要与//services目录外的静态库紧密耦合。一定避免依赖目标平台层，例如//content，//chrome或//third_party/WebKit。
打包
注意，尽管在物理层面上可以将每个服务打成独立包，但使用服务的产品也可以使用不同方案进行打包，例如将多个服务打成一个包。
补充文档
高级设计文档（High-level Design Doc）
服务主页（Servicification Homepage）
服务策略（Servicification Strategies）
与其他顶层子目录的关系
服务可以被看做是来自于Chromium代码库的库代码的整体，通常是//base和//mojo目录，不过//compontents，//ui等目录也为每个服务提供了对应的功能。
并非//components目录下的所有内容都有权利自动变为服务。将//components比作//lib。单个//components可以定义，实现，使用Mojo接口，不过只有//services在Service Manger中有唯一ID，因此只有//services才有可能获取Mojo接口。
添加新的服务
查看Service Manager文档以获取更多细节，这里讲述了如何定义一项服务，对其他服务公开接口，或使用其他服务已经公开的接口。
