SDK子系统基于一套OpenHarmony源码，生成归一化的SDK可满足多设备的应用开发。
面向多设备，多系统，多应用只提供一套 SDK，具体可分解为三个维度：
多端开发特性归一化针对能力不同设备，只提供一个 OH SDK，不单独提供针对某个设备的 SDK，不存在手机SDK，手表SDK。
兼容性归一化只提供 OH 的 SDK，HOS 不单独提供 SDK，HOS 独有的竞争力特性以 addon 的方式提供给开发者。
多应用支持归一化SDK 中包含三方 API 和系统 API，不单独提供系统 SDK 给系统应用。
SDK在提供编译工具链、开发工具、运行时的基础上增加如下功能：
各个部件的API增加SysCap属性，在SDK生成时为API添加该属性。
定义手机、PC、儿童表、TV和平板爆款设备类型的SysCap集合。
应用开发时，IDE可根据API的SysCap属性以及应用所选的设备类型对API的调用做静态检查和联想，提升开发者体验。
所有Public API需要通过@system，@syscap 标记API相关元信息，但是System API因为不涉及兼容性，所以不要求。
Public API：OpenHarmony 对所有应用开发者公开的 API。System API：提供给系统特权应用使用的 API，普通应用无法使用。
SDK 打包生成两个版本，public 版本和 full 版本，其中 public 版本不包含 system API，full 版本包含 public API 和 system API。IDE 默认下载的 SDK 版本为 public 版本，若 OEM 厂商开发者需要 full 版本，则需要自行从官网下载后，替换到 SDK 安装目录。
在 EMUI 和 OH API 8 及以前的版本中，API 在系统 API 定义上遵循了安卓的定义。
系统应用开发者、OEM厂商，开发系统应用，需要在官网下载 full 版本的 SDK 后，替换 IDE 默认下载的 public 版本。
通过在 API 的 JSDOC 中标记 @systemapi 来标记系统 API。
SysCap，全称SystemCapability，即系统能力，指操作系统中每一个相对独立的特性，如蓝牙，WIFI，NFC，摄像头等，都是系统能力之一。
每个系统能力对应多个 API，这些 API 绑定在一起，随着目标设备是否支持该系统能力共同存在或消失，也会随着 IDE 一起提供给开发者做联想。
通常，模块（Module）是个泛化的概念，主要指在逻辑架构视图中的功能模块，强调代码级复用。
组件（Component），主要指在部署视图中可独立加载、部署和运行的二进制软件实体，强调封装和二进制级复用。
OpenHarmony参考机械装配领域零部件的概念，在软件架构设计中引入了部件（Part）的概念。部件是指在部署视图中具有相对独立性、能完成一定功能的可独立交付，但是不能独立部署的软件实体。
部件是OpenHarmony系统能力的基本单元，以源码为划分依据，具有独立的文件和目录，在不同的设备上可实例化为不同的库或二进制文件。从系统角度看，凡是运行在OpenHarmony上的软件都可以定义为部件。子系统一般是由一个或多个部件构成的。通过组装OpenHarmony部件，就能方便地构建出一个与设备硬件能力最匹配且具备分布式能力的系统。综上所述，子系统划分部件的原则：
具备独立的代码目录和编译脚本，具备独立的仓，可独立下载，可独立编译出库和二进制
具备独立测试验证能力
具备部署能力，不带入该部件的实例化的库和二进制，只会引起部件能力的缺失，不会引起系统的异常
插件化是典型的部件化的设计，例如类似GStreamer，source/decoder plugin都是可以根据产品实际需要来部署
如果部件可以拆出作为原部件的补充功能模块，并向应用提供API，称这类功能模块为子部件，跟随父部件一起部署，无法独立部署。子部件依赖父部件，但父部件不允许依赖子部件
被部件依赖的三方开源库以及子系统内部由于复用等原因拆分的基础部件也为部件，称这类部件为依赖部件，在部件的deps中需指定 依赖部件，依赖部件不需要主动配置裁剪，跟随部件一起部署
系统可通过部件的配置裁剪去定义，所以需要通过System Capability（简写为SysCap）来定义配置裁剪后的系统能力：
不是所有的部件都需要定义System Capability，只有对应用提供API 且 是多设备部署非最小系统必须的（可能被裁剪的） 部件才采用需要定义System Capability。
部件内也可以具备功能裁剪的能力，但不能引起部件API的变化，并需要提供具体功能是否可被使用的检查方法，如checkFunc(xx).
使用两个ID来标识，产品具有的OS能力，应用依赖的OS能力
设备类型（DeviceType）相当于一个规定值的PCID。应用开发者可以在IDE选择设备类型或者自定义某个PCID的设备进行应用开发。
每个部件对应一个或多个 SysCap，每个 SysCap 对应多个 API，这些 API 绑定在一起，随着目标设备是否支持该 SysCap 共同存在或消失。
SysCap与API的关系：提供API的部件必须定义SysCap，定义了SysCap的部件不一定有API。
API 按 SysCap 分类是正交的，不会出现一个 API 同时属于多个 SysCap 的情况，另外，API 的新增，变更，废弃都不影响其所在的 SysCap 本身的功能。
每个 API 通过在 JS DOC 中添加自定义标签 @syscap {SysCap 名称} 的方式来标记该 API 属于哪个 SysCap。
PCID属性如下：
按以下步骤生成PCID文件：
cmd进入此文件夹执行下面的命令即可得到.sc文件
使用上面PCID编码生成的PCID(.sc文件)，按以下步骤进行PCID解码：
此时存在PCID编码生成的PCID(.sc文件)，执行下面的命令：
即可得到.json文件：
按以下步骤进行PCID解码：
PCID采用 BCG（Base Components Group）/OCG（Optional Components Group）/PCG（Product Components Group，预留给OEM）定义特定设备的系统能力。其中，SysCap 是 PCID 的一部分，也是 RPCID 的一部分。对于 SDK，只使用 SysCap 集合，不使用其它字段。
下面是 IDE 通过 PCID 生成 SysCap 集合和 IDE 通过应用使用的 API 涉及的 RequiredSysCap 集合生成 RPCID 的过程。
每个设备根据其硬件能力，对应不同的 SysCap 集合。
SDK 将设备分为两组，爆款设备和 N 设备。
爆款设备为 phone，tablet，wearable，litewearable，tv，car 六种爆款设备，后续可根据生态的拓展增加新的类型，每种爆款设备定义其对应的 SysCap 集合。
N 设备为南向自定义类型的设备，在现阶段，微波炉，油烟机等设备属于 N 设备，后面随着生态的发展，N 设备的能力成为业界标准可成为爆款设备。
爆款设备由 OpenHarmony 定义其 SysCap 集合，定义存放在 SDK 中，N 设备由厂家定义其 SysCap 集合，并以 PCID 的方式提供给开发者。
在 SDK 根目录下新建 device-define 目录，放置爆款设备的 SysCap 集合的定义，每个爆款设备的定义由一个 json 文件承载。
SDK 是 OH 系统中唯一存放设备定义的模块，后续新增、修改、删除爆款的定义都需要从 SDK 中修改。
目录结构如下：
N 设备支持的 SysCap 集合，不会保存在 SDK 中，而是由厂商给出该设备的 PCID，其中包含了厂家对该设备的 SysCap 集合的定义，IDE 通过 PCID 转换工具生成对应的 SysCap 集合，同爆款设备一样，为开发者提供 API 的联想。
SDK 提供全量的 API 给 IDE，IDE 通过开发者的项目支持的设备，筛选该设备支持的 API 提供给开发者做联想。
每个设备，无论是爆款还是 N 设备，都有其能力的 SysCap 的集合，IDE 根据 SysCap 集合，为开发者提供该设备支持的 API。
RequiredSysCap 是应用的一个属性，表示应用使用了全部的 API 涉及的 SysCap 集合，在开发爆款单设备应用时，其默认值为该爆款设备的 SysCap 结合。
对 RequiredSysCap 修改要非常谨慎，因为应用打包时，工具链会根据这个字段生成该应用的 RPCID，RPCID 决定了该应用在应用市场上是否能在对应的设备上分发。
文件内容包含3个关键配置，分别为 base，development 和 product。
对于跨设备开发，IDE 会对 base 中所配置的所有设备的SysCaps 集合取并集作为联想提示，取交集作为生成 RPCID。
除此以外，开发者可以通过 development 修改可联想的 API 范围，和通过 production 修改 RequiredSysCap，
development 中配置 IDE 可用于联想的 SysCap 所使用的 API，默认为 base 中所有 SysCap 包含的 API，可通过 addedSysCaps 进行添加。
product 中配置，会生成应用的 RequiredSysCap 集合，从而用来生成应用的 RPCID，RequiredSysCap 集合默认为 base 中所有设备 SysCap 集合的交集，可使用 addedSysCaps 和 removedSysCaps 来添加和删除。使用 addedSysCaps 要特别慎重，会导致应用商店无法分发的原爆款设备上。
由于该配置项比较复杂，后续 IDE 可考虑通过图形界面配置。
下面是一个手机应用，在爆款手机设备支持的 SysCap 能力基础上，支持 NFC 的 API 联想，在应用支持 NFC 但是不支持 Wifi 的例子。
应用 RequiredSysCap 集合与设备 SysCap 集合相等，建议开发者只使用上述 SysCap 定义的 API 开发应用。
IDE 需要支撑应用的 API 是多设备 SysCap 集合的合集。应用的 RequiredSysCap 应是多设备 SysCap 集合的交集。
应用使用交集外的 SysCap 中的 API，都需要使用 hasCapability 函数进行判断。
定义
说明
canIUse 为全局方法，不需要 import 即可使用。
开发者可覆盖该引用，覆盖后由开发者自行处理并承担后果。
canIUse 为同步方法，需要保证实现的性能。
返回值为布尔值，true 表示该设备支持，可以使用，反之为 false。
CanIUse() 的使用
或者开发者可通过 import 的方式将模块导入，若当前设备不支持该模块，import 的结果为 undefined，开发者在使用其 API 时，需要判断其是否存在。
即使是相同的系统能力，在不同的设备下，也会有能力的差异。比如同是摄像头的能力，平板设备优于智能穿戴设备。
设备的SysCap因产品解决方案厂商拼装的部件组合不同而不同，整体流程如下图：
应用安装时包管理对应用配置的SysCap进行检查，当系统具备的SysCap的集合大于等于应用所需的SysCap时安装成功，否则安装失败。
1）使用SysCap编解码工具将应用的RPCID解码成应用所需的SysCap集。
2）调用init的SysCap查询接口得到系统的SysCap集。
3）包管理对应用所需的SysCap与系统当前具备的SysCap集进行匹配。
IDE子系统为应用开发提供两大类功能：
1）API联想和静态检查
2）生成应用的RPCID
设备类型不同，IDE获取设备的SysCap和应用配置SysCap的有所区别：
1）N设备：设备的SysCap通过用户导入设备PCID和解码得到。应用的配置文件中，deviceType设置为空，所需的SysCap通过requiredSysCap进行全量定义。
2）1+8设备：设备的SysCap通过应用配置的deviceType和SDK定义的对应的SysCap集得到。应用的配置文件中，deviceType设置不为空，如果需要对应设备类型所包含的SysCap集之外的能力，以增量的方式写入requiredSysCap。
设备厂商在设备认证时提供PCID，认证中心基于PCID中包含的SysCap进行认证，认证通过后将PCID与设备token映射，并提供给设备厂商。
应用市场在分发设备时，发送设备token给认证中心，认证中心返回PCID后与应用配置的SysCap进行匹配决定是否分发。