update shared docs

Signed-off-by: Nchangzheng6 <hanfeng6@huawei.com>

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

@@ -3,6 +3,12 @@
 应用间`HSP`用于不同应用间的代码、资源共享。
 应用间`HSP`的宿主应用是一种特殊状态的应用，只能由一个[HSP](hsp-guide.md)组成，不会独立运行在设备上，而是被普通应用模块的依赖项引用。当普通应用运行时，通过动态调用的方式使用应用间`HSP`提供的能力，从而实现应用自身所需要的功能。
 
+## 注意事项
+1. 应用间`HSP`的代码会运行再开发者应用的进程中，调用相关代码时，需要做好异常捕获与容错处理，防止由于应用间`HSP`功能异常导致的稳定性问题。
+2. 一个应用可以同时依赖多个应用间`HSP`。
+3. 应用间`HSP`会影响开发者应用自身的启动时间，依赖过多的应用间HSP可能会导致启动时延发生明显的劣化，建议将依赖的数目控制在16个以内。
+4. 当前三方开发者开发者只能使用系统提供的应用间`HSP`，不支持开发并发布自己的应用间`HSP`。
+
 ## 应用间HSP的使用
 应用间HSP会分为两部分对外发布：
 
@@ -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，配置如下所示：

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

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