From ba7e2f5f0f62d19dadb59252b556d7e20613cadb Mon Sep 17 00:00:00 2001 From: jady3356 Date: Wed, 19 Jan 2022 12:29:40 +0000 Subject: [PATCH] =?UTF-8?q?update=20zh-cn/design/OpenHarmony=E9=83=A8?= =?UTF-8?q?=E4=BB=B6=E8=AE=BE=E8=AE=A1=E5=92=8C=E5=BC=80=E5=8F=91=E6=8C=87?= =?UTF-8?q?=E5=8D=97.md.=20Signed-off-by:=20yangming=5Fha=20?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...00\345\217\221\346\214\207\345\215\227.md" | 63 +++++++++---------- 1 file changed, 31 insertions(+), 32 deletions(-) diff --git "a/zh-cn/design/OpenHarmony\351\203\250\344\273\266\350\256\276\350\256\241\345\222\214\345\274\200\345\217\221\346\214\207\345\215\227.md" "b/zh-cn/design/OpenHarmony\351\203\250\344\273\266\350\256\276\350\256\241\345\222\214\345\274\200\345\217\221\346\214\207\345\215\227.md" index b5083e1c84..6edcd0a60e 100755 --- "a/zh-cn/design/OpenHarmony\351\203\250\344\273\266\350\256\276\350\256\241\345\222\214\345\274\200\345\217\221\346\214\207\345\215\227.md" +++ "b/zh-cn/design/OpenHarmony\351\203\250\344\273\266\350\256\276\350\256\241\345\222\214\345\274\200\345\217\221\346\214\207\345\215\227.md" @@ -10,25 +10,7 @@ OpenHarmony参考机械装配领域的零部件的概念将系统能力抽象为 部件是体现系统能力的基本单元，以源码为划分依据，具有独立的文件和目录，在不同设备上可以实例化为相应的库或可执行文件。 -## 部件设计 - -### 1、设计原则 - -部件在设计和开发时应遵循如下规则和建议： - -**规则1.1** 部件应当实现独立自制原则，保持部件本身的解耦和独立自治。 - -**规则1.2** 部件应该去中心化治理，部件间的依赖关系应简单清晰合理。 - -**规则1.3** 禁止部件间反向依赖、循环依赖，下层部件禁止依赖上层部件。 - -**规则1.4** 禁止部件的实现依赖特定的开发板或产品形态。 - -**规则1.5** 部件接口应保持稳定，已发布的接口不能变化，保持接口兼容。 - -**建议1.1** 部件应支持自动化构建和验证的能力。 - -### 2、划分原则 +## 部件划分 部件按照如下原则进行划分： @@ -48,15 +30,32 @@ OpenHarmony参考机械装配领域的零部件的概念将系统能力抽象为 - 如果部件可拆分出更小的功能模块并向应用提供API，称这类模块为**子部件**，跟随父部件一起部署，无法独立部署。子部件依赖父部件，但父部件不允许依赖子部件。 -### 3、部件、仓、路径命名和目录树 +### 基本原则 + +部件在设计和开发时应遵循如下规则和建议： + +**规则1.1** 部件应当实现独立自制原则，保持部件本身的解耦和独立。 + +**规则1.2** 部件应该去中心化治理，部件间的依赖关系应简单清晰合理。 + +**规则1.3** 禁止部件间反向依赖、循环依赖，下层部件禁止依赖上层部件。 + +**规则1.4** 禁止部件的实现依赖特定的开发板或产品形态。 + +**规则1.5** 部件接口应保持稳定，已发布的接口不能变化，保持接口兼容。 + +**建议1.1** 部件应支持自动化构建和验证的能力。 + +### 命名规则 #### **部件名：** -为名词形式，需体现部件的功能，在系统内全局唯一，不超过63个有效英文字符，使用内核风格命名，例如：unix_like。 +英文名：名词形式，需体现部件的功能，在系统内全局唯一，不超过63个有效英文字符，使用小写加下划线的内核风格命名，例如：unix_like。 +中文名：名词形式，需体现部件的功能，不超过16个中文字符，不建议中英文混合。 #### **仓名：** -部件仓名命名规则：<子系统名>_<部件名>，例如：文件管理子系统的存储服务部件的仓名为“filemanagement_storage_service”。 +部件仓名使用英文，命名规则：<子系统>_<部件>，例如：文件管理子系统的存储服务部件的仓名为“filemanagement_storage_service”。仓名总长度不超过100个字符。 > 说明： > @@ -68,21 +67,21 @@ OpenHarmony参考机械装配领域的零部件的概念将系统能力抽象为 #### **路径：** -部件根目录路径规则：<领域>/<子系统>/<部件>， 例如：foundation/filemanagement/storage_service +部件目录使用英文，路径规则：<领域>/<子系统>/<部件>， 例如：foundation/filemanagement/storage_service。 #### **部件目录结构：** ```xml ├── interfaces # 接口 │ ├── kits # 应用接口，可选 -│ │ ├── js # js接口，可选 -│ │ └── native # c/c++接口，可选 +│ │ ├── js # JS接口，可选 +│ │ └── native # C/C++接口，可选 │ └── inner_api # 系统内部件间接口 ├── frameworks # 部件无独立进程的实现，可选 -│ ├── native # c/c++实现，可选 +│ ├── native # C/C++实现，可选 │ └── js # JS API的实现，可选 │ ├── napi # napi代码实现，可选 -│ ├── builtin # 仅用于liteos-m，可选 +│ ├── builtin # 仅用于LiteOS-M，可选 │ └── plugin # Ark UI特有，可选 ├── services # 独立进程的实现，可选 ├── test # 测试代码，必选 @@ -95,16 +94,17 @@ OpenHarmony参考机械装配领域的零部件的概念将系统能力抽象为 部件的新增、合并、删除需经架构SIG（Special Interest Group）和[相关领域的SIG leader](https://gitee.com/openharmony/community/blob/master/sig/sigs_subsystem_list.md)评审，流程如下： 1、准备如下的部件属性列表： + 表1. 部件属性评审表 | 部件属性 | 说明 | | ------------ | ------------------------------------------------------------ | -| 英文名称 | 为名词形式，需体现部件的功能，在系统内全局唯一，不超过63个有效英文字符，使用内核风格命名，例如：unix_like。 | -| 中文名称 | 名称形式，需体现部件的功能，不超过16个中文字符，不建议中英文混合。 | +| 英文名称 | 名词形式，需体现部件的功能，在系统内全局唯一，不超过63个有效英文字符，使用小写加下划线的内核风格命名，例如：unix_like。 | +| 中文名称 | 名词形式，需体现部件的功能，不超过16个中文字符，不建议中英文混合。 | | 子系统 | 部件归属的子系统 | | 功能描述 | 一句话简要描述部件功能，100字以内。 | | 可配置特性 | 部件对外可配置的特性。 | -| 适用系统类型 | 部件适用的系统类型：小型、轻量和标准，可以是支持多种。 | +| 适用系统类型 | 部件适用的系统类型：小型、轻量和标准，可以同时支持多种。 | | 源码目录 | 部件的源码根目录。 | | ROM | 部件设计的ROM基线值。 | | RAM | 部件设计的RAM基线值。 | @@ -115,5 +115,4 @@ OpenHarmony参考机械装配领域的零部件的概念将系统能力抽象为 > 说明：部件修改/合并需提供修改/合并前后部件属性，提供待删除的部件停止维护的计划。删除和合并部件要谨慎，要评估对存量版本的影响。 -3、评审通过后，请按[SIG管理章程](https://gitee.com/openharmony/community/tree/master/sig)新建部件仓和修改manifest，SIG孵化完成后合入OpenHarmony组织代码主库。 - +3、评审通过后，请按[SIG管理章程](https://gitee.com/openharmony/community/tree/master/sig)新建部件仓和修改manifest，SIG孵化完成后合入OpenHarmony组织代码主库。 \ No newline at end of file -- GitLab