（可选）您的幽默标题
| 字段 | 值 |
|---|---|
| 状态 | 草稿 |
| 作者 | 您的电子邮件 |
| 已提交 | 保留为空，直至提交 |
| 已批改 | 在审核前留空 |
总结
对提案其余部分进行一段说明。
设计初衷
此建议可解决什么问题？
设计
这是提案的技术详细版本。
概括来讲，提案的一个重要要点是修改提案的 FIDL 部分。这至少包括：
- FIDL 源语言
- FIDL 传输格式
- 一流的语言绑定（C、C++、Dart、Go、Rust）
- FIDL 风格指南和 API 评分准则
- FIDL 调整过程
您的提案应涵盖所有相关领域。例如，如果您的提案在 FIDL 语言中添加了一个新类型，则还需要讨论该功能的样式指南，以及如何在绑定中实现该功能。
本文档中的关键字“必须”“不得”“必需”“会”“不会”“应”“不应”“建议”“可以”和“可选”应按 RFC 2119 中的描述进行解释。
实施策略
你们将如何进行这一更改？某些 FTP 不涉及破坏性更改，可能会作为单个 CL 发生。另一些则是大幅度变动。 无论采用哪种方式，都需要考虑如何将实现细分成任务。
对于可能会更改的更复杂实现，我们建议您编写一份“意图实现”(I2I) 文档，并在此部分提供指向该文档的链接。然后，I2I 就可以作为一个动态的、独立的设计文档，可以单独进行更新，这样该文档就不会随着细节的变化而不断地重新编辑。这也使得 FTP 可以专注于高级的重要概念，而不是实施和执行。
工效学设计
您的更改是否使 FIDL 更易于使用且更易于理解？这是否使绑定更易于使用？否则，其复杂性的理由是什么？
重点关注最终用户 API 以及理解相关概念所需的认知工作。
文档和示例
您可能需要处理多种类型的文档。
您如何以各种 FIDL 教程的风格编写或更改此功能的教程？设想一下 您向 Fuchsia 新用户说明您的功能
您如何撰写参考文档？例如，假设您的方案扩展了 FIDL 传输格式。如何更新传输格式的文档？假设您要充分详细地介绍您的功能，让他们能够实现您的功能。
您提议的功能有哪些重要示例或使用场景？
向后兼容性
向后兼容性分为两种：FIDL 文件源代码兼容性和 ABI 或传输格式兼容性。此部分应同时提及这两种人群。随着时间的推移，进行不向后兼容的更改的能力将变得更加困难。
如果您要引入新的数据类型或语言功能，请考虑您希望用户对 FIDL 定义做出哪些更改，而不会中断已生成代码的用户。如果您的功能对生成的语言绑定施加了新的源代码兼容性限制，请在此处列出这些限制。
性能
此方案会对 IPC 性能产生什么影响？构建性能？
安全性
您的功能对安全性有何影响？您的功能是否很容易以非内存安全型语言安全使用？您的功能是否容易意外泄露进程地址空间的详细信息？
测试
如何测试您的功能？例如，您需要为 fidlc 还是 C++ 绑定编写新的测试？
如果您的更改会影响编码或解码，请计划更新一致性测试套件。
如何测试新功能的使用情况？如果您添加语言功能，您将如何在每种语言的绑定中对其进行测试？
缺点、替代方案和未知因素
实施该方案的费用是多少？
还有哪些策略可以解决同样的问题？
若要接受此提案，仍需解决哪些问题或改进哪些细节？您对此问题的回答可能会随着提案的推进而发生变化。
现有技术和参考资料
在阅读此提案时，是否有任何背景资料可能会有帮助？例如，其他序列化或 IPC 系统是否解决了此方案解决的相同问题？