| RFC-0027：您只需为实际使用的资源付费 | |
|---|---|
| 状态 | 已接受 |
| 领域 |
|
| 说明 | 向 FIDL 添加功能时，我们应评估为使用 FIDL 而不使用新功能的用户添加该功能的成本。因此，我们应针对接受某个功能（这会对不使用该功能的用户带来费用）设定非常高的标准。 |
| 作者 | |
| 提交日期（年-月-日） | 2019-01-19 |
| 审核日期（年-月-日） | 2019-02-04 |
总结
本文档提出了一条设计原则，我们应在 RFC 审核流程中遵循该原则：
您只需要按照实际用量付费
具体而言，在向 FIDL 添加功能时，我们应评估为使用 FIDL 但不使用新功能的用户添加该功能所产生的费用。然后，我们应针对接受某个功能（这会对不使用该功能的用户带来费用）设定非常高的标准。
设计初衷
FIDL 最重要的一个方面是，Fuchsia 普遍使用 FIDL 进行进程间通信，因此用于定义系统 ABI。
许多进程间通信用例对性能至关重要。当人们在评估这些对性能至关重要的用例的技术时，FIDL 会与自定义消息格式以及临时序列化和反序列化例程竞争。
其他进程间通信用例对灵活性至关重要。当人们针对这些对灵活性至关重要的用例评估技术时，FIDL 会与 protobuf 或众多其他面向网络的消息格式展开竞争。
为了成功地在整个 Fuchsia 中广泛使用，FIDL 需要满足这两项需求。具体而言，使用 FIDL 的协议设计人员需要能够在性能和灵活性之间进行权衡，以满足自己的需求。
通过采用“您只需要用多少，付多少”这一设计原则，对性能至关重要的客户可以避免为支持灵活性的功能付费；而 FIDL 的双重“用多少，付多少”使 FIDL 能够为对灵活性至关重要的客户提供服务。
设计
本部分介绍了我们如何形成此设计原则的历史，以及正例和反例。
历史记录
FIDL 是对 Mojo 进程间通信系统的演变。当时，Mojo 的灵活性显著高于 FIDL，后者非常适合对灵活性至关重要的用例。但是，具有性能关键型用例的客户不愿意采用 Mojo，因为该系统提供的灵活性无法满足他们的需求。
FIDL2（截至 2017 年 3 月 1 日，截至 2017 年 3 月 1 日是撰写本文时 FIDL 的当前版本迭代）的原始设计在设计领域提出了不同的选择。为了赢得对性能至关重要的客户，FIDL2 的灵活性远低于 Mojo，这使得 FIDL2 通过自定义消息格式以及临时序列化和反序列化例程实现了性能竞争力。一些客户端仍然需要临时序列化和反序列化例程，但 FIDL2 已成功用于进程间通信的消息格式。
FIDL2 的原始设计针对性能过度旋转，需要改进，以满足对灵活性至关重要的客户的需求。为了取得成功，FIDL 需要添加功能，以支持各种用例的灵活性，同时不影响不要求灵活性的客户的性能。
结构体和表
RFC-0047 就是“您只需用多少，付多少”的一个积极示例，它引入了一些表。表是一种单独的数据类型，支持对灵活性至关重要的用例，而不是替换结构体（具有固定大小和布局，支持性能关键型用例）。协议设计人员可以选择是否要为这种灵活性付费。
可扩展联合体
另一个重要示例是 RFC-0061，它引入了可扩展的联合。这个例子说明我们不能盲目应用这一原则。在该设计中，您可以选择是将可扩展联合体作为单独的概念引入，还是将所有不可扩展联合替换为可扩展联合体。
归根结底是进行价值判断，以权衡为所有并集客户端施加灵活性带来的性能成本与具有两个高度重叠的结构的复杂性成本（例如，向协议设计人员强加 cognative 负载，以选择适合其用例的结构）。在本例中，我们分析了联合的客户端，并确定它们中的大多数都重视灵活性，这意味着向绝大多数联合客户端强加灵活性成本不会导致它们为不使用的功能付费。对于少数不注重灵活性的应用，我们咨询了客户后认为，额外的费用不会产生沉重负担。
实施策略
设计进程间通信系统的一种策略是预先找出所有问题的理想平衡，然后实现该系统。遗憾的是，设计进程间通信系统所涉及的问题非常复杂，以至于这种策略超出了人类所能处理的范围。相反，我们试图制定一个目前尽可能做到最好的策略，然后以迭代方式优化设计，以更好地满足客户的需求。
从广义上讲，我们可以使用两种策略来平衡性能和灵活性：我们可以通过过度强调性能或过度强调灵活性来达到理想的平衡。
解读本文档的另一种方法是提议我们在为 FIDL 构建工程计划，首先过度强调性能（就像在原始 FIDL2 设计中一样），然后在保持性能的同时提高灵活性，从而实现性能与灵活性之间的平衡。
在评估对 FIDL 的更改以及 RFC 流程期间，我们希望将这一原则与其他设计注意事项权衡。当两个原则相冲突时，有许多适合解决这种关系的方法：评估对可能受影响的用户的影响，参考先例（例如，Protobuf 的优化工作或 FlatBuffers 设计选择），考虑谁需要承担复杂性（例如用户、语言设计师、绑定作者），考虑目前的设计是否达到极限归根结底，我们需要运用自己的判断来决定如何以最佳方式平衡这些因素。
文档和示例
本文档提议在 FIDL 的效率目标列表中添加“您只需用多少、付多少”原则。
向后兼容性
此原则可向后兼容当前的 FIDL 设计和工程程序。
性能
这一原则重视性能。
安全性
这一原则可能会对安全性产生负面影响，因为满足该原则可能会导致系统更加复杂（例如，同时具有结构体和表）。
缺点、替代方案和未知情况
该方案的一项成本是排除可用于满足灵活性关键型用例的设计空间，但代价是对性能至关重要的用例。
采用这种设计原则的另一个代价是，FIDL 系统比在其他情况下更复杂。例如，在所有位置使用表可能比在某些位置使用结构体而在其他位置使用表更简单。这种额外的复杂性给 FIDL 实现和使用 FIDL 的开发者造成了负担。为了减轻这一缺点，我们在应用该原则时应该考虑到这种复杂性成本。
平衡性能和灵活性的另一种策略是通过过度强调灵活性来达到理想的平衡。这种方法的难点在于，人类通过添加代码而不是移除代码来工程系统（例如，类似于在粘土中雕刻，而不是在大理石上雕刻）。相较于通过添加代码提高性能，通过添加代码来提高灵活性更容易。
早期技术和参考资料
许多其他语言采用了“用多少，付多少”设计原则，包括 C++1 和 Rust2。