!15801 【包管理】共享包资料优化

Merge pull request !15801 from hanfeng/master

zh-cn/application-dev/Readme-CN.md

@@ -17,7 +17,6 @@
       - 应用程序包结构
         - [Stage模型应用程序包结构](quick-start/application-package-structure-stage.md)
         - [FA模型应用程序包结构](quick-start/application-package-structure-fa.md)
-        - [HAR包结构](quick-start/har-structure.md)
       - 应用程序包多HAP机制
         - [多HAP机制设计目标](quick-start/multi-hap-objective.md)
         - [多HAP构建视图](quick-start/multi-hap-build-view.md)
@@ -26,11 +25,11 @@
         - [多HAP运行机制及数据通信方式](quick-start/multi-hap-principles.md)
       - [应用程序包安装和卸载流程](quick-start/application-package-install-uninstall.md)
       - 共享包
+        - [共享包概述](quick-start/shared-guide.md)
         - [HAR](quick-start/har-package.md)
         - HSP
-          - [HSP概述](quick-start/hsp-guide.md)
           - [应用内HSP开发指导](quick-start/in-app-hsp.md)
-          - [应用间HSP开发指导](quick-start/cross-app-hsp.md)
+          - [应用间HSP开发指导（仅对系统应用开放）](quick-start/cross-app-hsp.md)
     - 应用配置文件（Stage模型）
       - [应用配置文件概述（Stage模型）](quick-start/application-configuration-file-overview-stage.md)
       - [app.json5配置文件](quick-start/app-configuration-file.md)

zh-cn/application-dev/quick-start/Readme-CN.md

@@ -11,7 +11,6 @@
     - 应用程序包结构
       - [Stage模型应用程序包结构](application-package-structure-stage.md)
       - [FA模型应用程序包结构](application-package-structure-fa.md)
-      - [HAR包结构](har-structure.md)
     - 应用程序包多HAP机制
       - [多HAP机制设计目标](multi-hap-objective.md)
       - [多HAP构建视图](multi-hap-build-view.md)
@@ -20,6 +19,12 @@
       - [多HAP运行机制及数据通信方式](multi-hap-principles.md)
     - [应用程序包安装和卸载流程](application-package-install-uninstall.md)
     - [应用程序包更新流程](application-package-update.md)
+    - 共享包
+      - [共享包概述](shared-guide.md)
+      - [HAR](har-package.md)
+      - HSP
+        - [应用内HSP开发指导](in-app-hsp.md)
+        - [应用间HSP开发指导（仅对系统应用开放）](cross-app-hsp.md)
     - 应用程序包快速修复
       - [快速修复概述](quickfix-principles.md)
       - [快速修复调试指导](quickfix-debug.md)

zh-cn/application-dev/quick-start/application-package-structure-stage.md

@@ -4,7 +4,7 @@
 基于[Stage模型](application-configuration-file-overview-stage.md)开发的应用，经编译打包后，其应用程序包结构如下图**应用程序包结构（Stage模型）**所示。开发者需要熟悉应用程序包结构相关的基本概念。
 
 
-- 在开发态，一个应用包含一个或者多个Module，可以在[DevEco Studio](https://developer.harmonyos.com/cn/develop/deveco-studio/)工程中[创建一个或者多个Module](https://developer.harmonyos.com/cn/docs/documentation/doc-guides-V3/ohos-adding-deleting-module-0000001218760594-V3)。Module是OpenHarmony应用/服务的基本功能单元，包含了源代码、资源文件、第三方库及应用/服务配置文件，每一个Module都可以独立进行编译和运行。Module分为“Ability”和“Library”两种类型，“Ability”类型的Module对应于编译后的HAP（Harmony Ability Package）；“Library”类型的Module对应于[HAR](har-structure.md)（Harmony Ability Resources）包，即编译后的.tgz文件。
+- 在开发态，一个应用包含一个或者多个Module，可以在[DevEco Studio](https://developer.harmonyos.com/cn/develop/deveco-studio/)工程中[创建一个或者多个Module](https://developer.harmonyos.com/cn/docs/documentation/doc-guides-V3/ohos-adding-deleting-module-0000001218760594-V3)。Module是OpenHarmony应用/服务的基本功能单元，包含了源代码、资源文件、第三方库及应用/服务配置文件，每一个Module都可以独立进行编译和运行。Module分为“Ability”和“Library”两种类型，“Ability”类型的Module对应于编译后的HAP（Harmony Ability Package）；“Library”类型的Module对应于[HAR](har-package.md)（Harmony Archive），或者[HSP](shared-guide.md)（Harmony Shared Package）。
   一个Module可以包含一个或多个[UIAbility](../application-models/uiability-overview.md)组件，如**Module与UIAbility组件关系示意图**所示。
 
     **图1** Module与UIAbility组件关系示意图  

zh-cn/application-dev/quick-start/cross-app-hsp.md

 # 应用间HSP开发指导
 
 应用间`HSP`用于不同应用间的代码、资源共享。
-应用间`HSP`的宿主应用是一种特殊状态的应用，只能由一个[HSP](hsp-guide.md)包组成，不会独立运行在设备上，而是被普通应用模块的依赖项引用。当普通应用运行时，通过动态调用的方式使用应用间`HSP`提供的能力，从而实现应用自身所需要的功能。
+应用间`HSP`的宿主应用是一种特殊状态的应用，只能由一个`HSP`组成，不会独立运行在设备上，而是被普通应用模块的依赖项引用。当普通应用运行时，通过动态调用的方式使用应用间`HSP`提供的能力，从而实现应用自身所需要的功能。
+
+## 注意事项
+1. 应用间`HSP`的代码会运行再开发者应用的进程中，调用相关代码时，需要做好异常捕获与容错处理，防止由于应用间`HSP`功能异常导致的稳定性问题。
+2. 一个应用可以同时依赖多个应用间`HSP`。
+3. 应用间`HSP`会影响开发者应用自身的启动时间，依赖过多的应用间`HSP`可能会导致启动时延发生明显的劣化，建议将依赖的数目控制在16个以内。
+4. 当前三方开发者开发者只能使用系统提供的应用间`HSP`，不支持开发并发布自己的应用间`HSP`。
 
 ## 应用间HSP的使用
 应用间HSP会分为两部分对外发布：
 
-一部分为[HAR包](har-package.md)，这部分`HAR`包中不会包含具体的功能实现代码，而仅仅包含导出的对象与方法，所以体积很小。应用开发者将`HAR`包集成到自身的工程中，然后就可以通过调用`HAR`包中提供的对象与方法完成自身的应用功能。
+一部分为[HAR](har-package.md)，这部分`HAR`中不会包含具体的功能实现代码，而仅仅包含导出的对象与方法，所以体积很小。应用开发者将`HAR`集成到自身的工程中，然后就可以通过调用`HAR`中提供的对象与方法完成自身的应用功能。
 
-另外一部分为[HSP](hsp-guide.md)，这部分为应用间`HSP`的具体实现，里面包含js/ts代码、C++库、资源和配置文件。这部分会上架到应用市场或者集成到系统版本中。
+另外一部分为HSP，这部分为应用间`HSP`的具体实现，里面包含js/ts代码、C++库、资源和配置文件。这部分会上架到应用市场或者集成到系统版本中。
 
-### 集成应用间HSP的HAR包
-`HAR`包中的`index.d.ets`文件是应用间`HSP`导出的声明文件的入口，所有需要导出的接口，统一在`index.d.ets`文件中定义。`index.d.ets`文件路径如下：
+### 集成应用间HSP的HAR
+`HAR`中的`index.d.ets`文件是应用间`HSP`导出的声明文件的入口，所有需要导出的接口，统一在`index.d.ets`文件中定义。`index.d.ets`文件路径如下：
 ```
 src
 ├── main
@@ -110,8 +116,8 @@ extern "C" __attribute__((constructor)) void RegisterLibaModule(void) {
     napi_module_register(&demoModule);
 }
 ```
-### 使用HAR包导出的能力
-引用`HAR`包前，需要先配置对`HAR`的依赖，配置方式可参考[文档](https://developer.harmonyos.com/cn/docs/documentation/doc-guides/ohos-development-npm-package-0000001222578434#section89674298391)。`HAR`包配置成功后，在配置模块的`module.json`中会生成相关依赖项信息，如下所示：
+### 使用HAR导出的能力
+引用`HAR`前，需要先配置对`HAR`的依赖，配置方式可参考[文档](https://developer.harmonyos.com/cn/docs/documentation/doc-guides/ohos-development-npm-package-0000001222578434#section89674298391)。`HAR`配置成功后，在配置模块的`module.json`中会生成相关依赖项信息，如下所示：
 ```json
 "dependencies": [
       {
@@ -122,8 +128,8 @@ extern "C" __attribute__((constructor)) void RegisterLibaModule(void) {
 ]
 ```
 其中`bundleName`为应用间`HSP`的`bundle`名称，`moduleName`为应用间`HSP`的模块名称，`versionCode`为应用间`HSP`的版本号。
-#### **使用HAR包中的ArkUI组件**
-`HAR`共享包的依赖配置成功后，可以引用`HAR`共享包的ArkUI组件。ArkUI组件的导入方式与ts的导入方式一致，通过`import`引入`HAR`共享包导出的ArkUI组件，示例如下所示：
+#### **使用HAR中的ArkUI组件**
+`HAR`的依赖配置成功后，可以引用`HAR`的ArkUI组件。ArkUI组件的导入方式与ts的导入方式一致，通过`import`引入`HAR`导出的ArkUI组件，示例如下所示：
 ``` ts
 import { UIComponent } from 'liba'
 
@@ -133,7 +139,7 @@ struct Index {
   @State message: string = 'Hello World'
   build() {
     Row() {
-      // 引用HAR共享包的ArkUI组件
+      // 引用HAR的ArkUI组件
       UIComponent()
       Column() {
         Text(this.message)
@@ -147,8 +153,8 @@ struct Index {
 }
 ```
 
-#### **使用HAR包中的ts方法**
-通过`import`引用`HAR`共享包导出的ts类和方法，示例如下所示：
+#### **使用HAR中的ts方法**
+通过`import`引用`HAR`导出的ts类和方法，示例如下所示：
 ``` ts
 import { foo1 } from 'liba'
 import { foo2 } from 'liba'
@@ -160,7 +166,7 @@ struct Index {
       Column() {
         Button('Button')
           .onClick(()=>{
-            // 引用HAR共享包的ts方法
+            // 引用HAR的ts方法
             foo1();
             foo2();
         })
@@ -171,8 +177,8 @@ struct Index {
   }
 }
 ```
-#### **使用HAR包中的native方法**
-通过`import`引用`HAR`共享包导出的native方法，示例如下所示：
+#### **使用HAR中的native方法**
+通过`import`引用`HAR`导出的native方法，示例如下所示：
 ``` ts
 import { nativeHello } from 'liba'
 
@@ -183,7 +189,7 @@ struct Index {
       Column() {
         Button('Button')
           .onClick(()=>{
-            // 引用HAR共享包的native方法
+            // 引用HAR的native方法
             nativeHello();
         })
       }
@@ -196,26 +202,20 @@ struct Index {
 
 ## 应用间HSP的分发方式
 应用间`HSP`由于并未直接完整的集成到开发者应用中去，所以需要提前预置在系统版本中或者随开发者应用同步安装到设备上，主要有以下两种形式：
-1. 随系统发布，部分常用应用间`HSP`会预置在系统版本中
+1. 随系统发布，部分常用应用间`HSP`会预置在系统版本中。
 2. 随应用发布，即用户在应用市场下载应用时，如果应用依赖了一个或者多个应用间`HSP`，同时设备上没有安装这个其依赖的应用间`HSP`时，应用市场会为用户同时下载普通应用以及其依赖的应用间`HSP`。从而保证普通应用能够正常使用共享库的功能。
 
 ### 应用间HSP的调试方式
 开发者本地调试应用间`HSP`相关的功能时，可能并不具备上述分发的条件，此时可以通过`bm`相关指令本地完成应用间`HSP`的分发，主要步骤如下：
-1. 获取到应用间`HSP`的安装包
-2. 通过`bm`指令先安装应用间`HSP`的安装包
+1. 获取到应用间`HSP`的安装包。
+2. 通过`bm`指令先安装应用间`HSP`的安装包。
 ```
 bm install -s sharebundle.hsp
 ```
-3. 通过`bm`指令后安装开发者自身的应用`hap`
+3. 通过`bm`指令后安装开发者自身的应用`hap`。
 ```
 bm install -p feature.hap
 ```
-4. 启动开发者自身的应用，调试相关功能
+4. 启动开发者自身的应用，调试相关功能。
 
-**注意**：步骤2和步骤3不可以颠倒，否则会由于缺少必要的应用间`HSP`导致开发者的应用安装失败。更多`bm`相关指令可以参考[文档](https://gitee.com/openharmony/bundlemanager_bundle_framework#bm%E5%B7%A5%E5%85%B7%E5%91%BD%E4%BB%A4)。
-
+**注意**：步骤2和步骤3不可以颠倒，否则会由于缺少必要的应用间`HSP`导致开发者的应用安装失败。更多`bm`相关指令可以参考[文档](https://gitee.com/openharmony/bundlemanager_bundle_framework#bm%E5%B7%A5%E5%85%B7%E5%91%BD%E4%BB%A4)。
\ No newline at end of file
-## 注意事项
-1. 应用间`HSP`的代码会运行再开发者应用的进程中，调用相关代码时，需要做好异常捕获与容错处理，防止由于应用间`HSP`功能异常导致的稳定性问题
-2. 一个应用可以同时依赖多个应用间`HSP`
-3. 应用间`HSP`会影响开发者应用自身的启动时间，依赖过多的应用间HSP可能会导致启动时延发生明显的劣化，建议将依赖的数目控制在16个以内。
-4. 当前三方开发者开发者只能使用系统提供的应用间`HSP`，不支持开发并发布自己的应用间`HSP`。
\ No newline at end of file

zh-cn/application-dev/quick-start/har-package.md

 # HAR
-HAR（Harmony Archive）是Harmony静态共享包，可以包含代码、C++库、资源和配置文件。通过HAR共享包，可以实现多个模块或多个工程共享ArkUI组件、资源等相关代码。HAR不同于HAP，不能独立安装运行在设备上，只能作为应用模块的依赖项被引用。
+HAR（Harmony Archive）是静态共享包，可以包含代码、C++库、资源和配置文件。通过HAR可以实现多个模块或多个工程共享ArkUI组件、资源等相关代码。HAR不同于HAP，不能独立安装运行在设备上，只能作为应用模块的依赖项被引用。
 
 ## 创建HAR模块
-HAR包对应DevEco Studio工程中的“Library”类型的[Module](https://developer.harmonyos.com/cn/docs/documentation/doc-guides-V3/ohos-adding-deleting-module-0000001218760594-V3)，可以通过DevEco Studio创建一个HAR模块。HAR模块默认不开启混淆能力，开启混淆能力，需要把HAR模块的build-profile.json5文件中的artifactType字段设置为obfuscation，配置如下所示：
+HAR对应DevEco Studio工程中的“Library”类型的[Module](https://developer.harmonyos.com/cn/docs/documentation/doc-guides-V3/ohos-adding-deleting-module-0000001218760594-V3)，可以通过DevEco Studio创建一个HAR模块。HAR模块默认不开启混淆能力，开启混淆能力，需要把HAR模块的build-profile.json5文件中的artifactType字段设置为obfuscation，配置如下所示：
 
 ```json
 {
@@ -19,7 +19,7 @@ artifactType字段有以下两种取值，默认缺省为original。
 需要对代码资产进行保护时，建议开启混淆能力，混淆能力开启后，DevEco Studio在构建HAR时，会对代码进行编译、混淆及压缩处理，保护代码资产。
 注意：artifactType字段设置为obfuscation时，apiType字段必须设置为stageMode，因为Stage模型才支持混淆。
 
-## HAR共享包开发注意事项
+## HAR开发注意事项
 - HAR不支持在配置文件中声明abilities、extensionAbilities组件。
 - HAR不支持在配置文件中声明pages页面。
 - HAR不支持在build-profile.json5文件的buildOption中配置worker。
@@ -27,7 +27,7 @@ artifactType字段有以下两种取值，默认缺省为original。
 - Stage模型的HAR，不能引用AppScope内的内容。在编译构建时APPScope中的内容不会打包到HAR中，导致HAR资源引用失败。
 
 ## 导出HAR的ArkUI组件、接口、资源
-index.ets文件是HAR共享包导出声明文件的入口，HAR共享包需要导出的接口，统一在index.ets文件中导出。index.ets文件是DevEco Studio默认自动生成的，用户也可以自定义，在模块的package.json文件中的main字段配置入口声明文件，配置如下所示：
+index.ets文件是HAR导出声明文件的入口，HAR需要导出的接口，统一在index.ets文件中导出。index.ets文件是DevEco Studio默认自动生成的，用户也可以自定义，在模块的package.json文件中的main字段配置入口声明文件，配置如下所示：
 ```json
 {
   "main": "index.ets"
@@ -84,17 +84,17 @@ export { func } from './src/main/ts/test'
 export { func2 } from './src/main/ts/test'
 ```
 ### 资源
-HAR模块编译打包时会把资源打包到HAR包中。在编译构建HAP时，DevEco Studio会从HAP模块及依赖的模块中收集资源文件，如果不同模块下的资源文件出现重名冲突时，DevEco Studio会按照以下优先级进行覆盖（优先级由高到低）：
+HAR模块编译打包时会把资源打包到HAR中。在编译构建HAP时，DevEco Studio会从HAP模块及依赖的模块中收集资源文件，如果不同模块下的资源文件出现重名冲突时，DevEco Studio会按照以下优先级进行覆盖（优先级由高到低）：
 - AppScope（仅API9的Stage模型支持）。
 - HAP包自身模块。
 - 依赖的HAR模块，如果依赖的多个HAR之间有资源冲突，会按照依赖顺序进行覆盖（依赖顺序在前的优先级较高）。
 
 ## 引用HAR的ArkUI组件、接口、资源
-引用HAR共享包前，需要先配置对HAR的依赖，配置方式可[参考](https://developer.harmonyos.com/cn/docs/documentation/doc-guides/ohos-development-npm-package-0000001222578434#section89674298391)。
+引用HAR前，需要先配置对HAR的依赖，配置方式可[参考](https://developer.harmonyos.com/cn/docs/documentation/doc-guides/ohos-development-npm-package-0000001222578434#section89674298391)。
 
-### 引用HAR共享包的ArkUI组件
+### 引用HAR的ArkUI组件
 
-HAR共享包的依赖配置成功后，可以引用HAR共享包的ArkUI组件。ArkUI组件的导入方式与ts的导入方式一致，通过`import`引入HAR共享包导出的ArkUI组件，示例如下所示：
+HAR的依赖配置成功后，可以引用HAR的ArkUI组件。ArkUI组件的导入方式与ts的导入方式一致，通过`import`引入HAR导出的ArkUI组件，示例如下所示：
 ```js
 // entry/src/main/ets/pages/index.ets
 import { MainPage } from "@ohos/library"
@@ -105,7 +105,7 @@ struct Index {
   @State message: string = 'Hello World'
   build() {
     Row() {
-      // 引用HAR共享包的ArkUI组件
+      // 引用HAR的ArkUI组件
       MainPage()
       Column() {
         Text(this.message)
@@ -118,8 +118,8 @@ struct Index {
   }
 }
 ```
-### 引用HAR共享包的类和方法
-通过`import`引用HAR共享包导出的ts类和方法，示例如下所示：
+### 引用HAR的类和方法
+通过`import`引用HAR导出的ts类和方法，示例如下所示：
 ```js
 // entry/src/main/ets/pages/index.ets
 import { Log } from "@ohos/library"
@@ -133,7 +133,7 @@ struct Index {
       Column() {
         Button('Button')
           .onClick(()=>{
-            // 引用HAR共享包的类和方法
+            // 引用HAR的类和方法
             Log.info("har msg");
             func();
         })
@@ -144,8 +144,8 @@ struct Index {
   }
 }
 ```
-### 引用HAR共享包的资源
-通过`$r`引用HAR共享包中的资源，例如在HAR模块的`src/main/resources`里添加字符串资源（在string.json中定义，name：hello_har）和图片资源（icon_har.png），然后在Entry模块中引用该字符串和图片资源的示例如下所示：
+### 引用HAR的资源
+通过`$r`引用HAR中的资源，例如在HAR模块的`src/main/resources`里添加字符串资源（在string.json中定义，name：hello_har）和图片资源（icon_har.png），然后在Entry模块中引用该字符串和图片资源的示例如下所示：
 ```js
 // entry/src/main/ets/pages/index.ets
 @Entry
@@ -154,11 +154,11 @@ struct Index {
   build() {
     Row() {
       Column() {
-        // 引用HAR共享包的字符串资源
+        // 引用HAR的字符串资源
         Text($r("app.string.hello_har"))
           .fontSize(50)
           .fontWeight(FontWeight.Bold)
-        // 引用HAR共享包的图片资源
+        // 引用HAR的图片资源
         Image($r("app.media.icon_har"))
       }
       .width('100%')

zh-cn/application-dev/quick-start/har-structure.md

-# HAR包结构
-
-
-[HAR（Harmony Archive）](https://developer.harmonyos.com/cn/docs/documentation/doc-guides/ohos-development-npm-package-0000001222578434)是Harmony静态共享包，可以包含代码、C++库、资源和module.json文件（Stage模型）或config.json文件（FA模型）等，用于实现多个模块或多个工程间的代码共享。
-
-HAR包不同于HAP，不能独立安装运行在设备上，只能作为应用模块的依赖项被引用。
-
-HAR包对应DevEco Studio工程中的“Library”类型的[Module](https://developer.harmonyos.com/cn/docs/documentation/doc-guides-V3/ohos-adding-deleting-module-0000001218760594-V3)。
-

zh-cn/application-dev/quick-start/hsp-guide.md

-# HSP概述
-
-`HSP`（`Harmony Shared Package`）是Harmony动态共享包，可以包含代码、C++库、资源和配置文件。
-`HSP`与[HAR（Harmony Achive）](har-package.md)都是为了实现代码和资源的共享，最大的不同之处在于，`HAR`中的代码和资源跟随使用方编译，如果有多个使用方，它们的编译产物中会存在多份相同拷贝。**而`HSP`中的代码和资源可以独立编译，运行时在一个进程中代码也只会存在一份。**
-
-**图1** `HAR`和`HSP`在`APP`包中的形态示意图
-![in-app-hsp-har](figures/in-app-hsp-har.png)
-
-**HSP旨在解决HAR包存在的几个问题：**
-- 多个`HAP`引用相同`HAR`包，导致的`APP`包大小膨胀问题
-- 多个`HAP`引用相同`HAR`包，`HAR`包中的一些状态变量无法共享的问题
-
-**HSP的一些约束：**
-- `HSP`及其使用方都必须是`Stage`模型
-- `HSP`及其使用方都必须使用`esmodule`编译模式
-- `HSP`不支持在配置文件中声明`abilities`、`extensionAbilities`标签
-
-`HSP`按照使用场景可以分为[应用内HSP](in-app-hsp.md)和[应用间HSP](cross-app-hsp.md)。它们在配置文件和使用方式等方面有所区别。
\ No newline at end of file

zh-cn/application-dev/quick-start/in-app-hsp.md

@@ -110,7 +110,7 @@ export { nativeMulti } from './utils/nativeTest'
     "library": "file:../library"
 }
 ```
-然后就可以像使用`HAR`包一样调用`HSP`的对外接口了。
+然后就可以像使用`HAR`一样调用`HSP`的对外接口了。
 例如，上面的`library`已经导出了下面这些接口：
 ```ts
 // library/src/main/ets/index.ets

zh-cn/application-dev/quick-start/shared-guide.md

+# 共享包概述
+
+OpenHarmony提供了两种共享包，[HAR（Harmony Achive）](har-package.md)静态共享包，和HSP（Harmony Shared Package）动态共享包。
+
+HAR与HSP都是为了实现代码和资源的共享，都可以包含代码、C++库、资源和配置文件，最大的不同之处在于：HAR中的代码和资源跟随使用方编译，如果有多个使用方，它们的编译产物中会存在多份相同拷贝；而HSP中的代码和资源可以独立编译，运行时在一个进程中代码也只会存在一份。
+
+**图1** `HAR`和`HSP`在`APP`包中的形态示意图
+![in-app-hsp-har](figures/in-app-hsp-har.png)
+
+**HSP旨在解决HAR存在的几个问题：**
+- 多个`HAP`引用相同的`HAR`，导致的`APP`包大小膨胀问题。
+- 多个`HAP`引用相同的`HAR`，`HAR`中的一些状态变量无法共享的问题。
+
+**HSP的一些约束：**
+- `HSP`及其使用方都必须是`Stage`模型。
+- `HSP`及其使用方都必须使用`esmodule`编译模式。
+- `HSP`不支持在配置文件中声明`abilities`、`extensionAbilities`标签。
+
+`HSP`按照使用场景可以分为[应用内HSP](in-app-hsp.md)和[应用间HSP](cross-app-hsp.md)。它们在配置文件和使用方式等方面有所区别。
\ No newline at end of file