harmony 鸿蒙OpenHarmony xxx子系统 xxx API评审申请
OpenHarmony xxx子系统 xxx API评审申请
背景
- API类型：[Public API|System API|Test API|HDI]
- API需求来源：
- API使用场景：
- API所属子系统：
- API预计发布版本：
- Contributor：
- 本次评审涉及的API数量：
| 类型 | 数量 | 编程语言 |
|---|---|---|
| 新增 | ||
| 行为变更 | ||
| 废弃 | ||
| 删除 |
API说明
必要性说明
现状与差距分析。API的使用场景和价值是什么？
总体特性说明
相关API完成了哪些功能特性。
评审结论
Committer评审结论
领域SIG评审结论
自查表
| 自查项 | 自查结果 |
|---|---|
| 是否已完成拼写检查？ | |
| 是否遵循了编码规范？ | |
| 词性使用是否正确（名词，形容词，副词）？ | |
| 命名是否完整表述了API所做的全部逻辑？ | |
| API的参数数量是否合理？（通常少于7个） | |
| 是否合理使用了缩写？（缩写是大家周知的） | |
| void类型API是否真的考虑过调用者不需要返回值？ | |
| 是否考虑过继承体系是合适的？父类的每一个方法都适用于子类 | |
| 已定义的错误状态是否完备？ | |
| 命名是否正确使用了对仗词： add/remove, create/destroy, insert/delete, start/stop, begin/end, send/receive, up/down, show/hide, open/close, source/target, source/destination, increase/decrease, first/last, next/previous |
|
| 新增API与同模块既存API表述和语义层次是否一致？ | |
| 同步API是否需要提供异步版本？ | |
| 是否每一个public API都真的是开发者需要的？ |
API接口及说明
请填写代码的提交地址。
- 代码地址：
API权限设计
使用该接口是否需要申请相应的权限。
API隐私保护设计
涉及用户隐私，需要考虑隐私保护。
开发者指南
可选。
API代码示例
二选一即可。
- 代码地址：
- 代码片段：
API变更说明
新增接口不需要填写此章节。
行为变更
API行为变更是指API的接口没有发生变化，仅仅是行为发生变化。 API行为变更需要在新的API版本上进行，不允许破坏旧版本API行为（除非是缺陷修复）。
相关接口
变更原因
废弃接口
废弃接口的API说明中，需要添加
@deprecated注解进行（包括：JS/TS/C/C++接口）标记。
相关接口
需描述从哪个版本开始标记为废弃。
废弃原因
替代接口
如果有则提供，如果无则说明原因。
删除接口
接口不允许直接删除，需要在标记废弃之后经过5个API版本才允许删除。
相关接口
删除原因
替代接口
如果有则提供，如果无则说明原因。
DFX
兼容性
性能
功耗
可靠性
可测试性
API必须同步交付API自动化测试用例，用例100%覆盖API接口。
评审结论
- 评审时间：
- 与会人：
- 评审结论：[通过|不通过]
- 评审会议纪要：
你可能感兴趣的鸿蒙文章
harmony 鸿蒙OpenHarmony API 设计规范
0
赞
热门推荐
-
2、 - 优质文章
-
3、 gate.io
-
6、 golang
-
8、 openharmony