未验证 提交 5874c6f5 编写于 作者: O openharmony_ci 提交者: Gitee

!12192 修改图片问题

Merge pull request !12192 from zhongjianfei/mm1206
...@@ -367,7 +367,7 @@ export default class FuncAbility extends UIAbility { ...@@ -367,7 +367,7 @@ export default class FuncAbility extends UIAbility {
经常还会遇到一类场景,当应用A已经启动且处于主页面时,回到桌面,打开应用B,并从应用B再次启动应用A,且需要跳转到应用A的指定页面。例如联系人应用和短信应用配合使用的场景。打开短信应用主页,回到桌面,此时短信应用处于已打开状态且当前处于短信应用的主页。再打开联系人应用主页,进入联系人用户A查看详情,点击短信图标,准备给用户A发送短信,此时会再次拉起短信应用且当前处于短信应用的发送页面。 经常还会遇到一类场景,当应用A已经启动且处于主页面时,回到桌面,打开应用B,并从应用B再次启动应用A,且需要跳转到应用A的指定页面。例如联系人应用和短信应用配合使用的场景。打开短信应用主页,回到桌面,此时短信应用处于已打开状态且当前处于短信应用的主页。再打开联系人应用主页,进入联系人用户A查看详情,点击短信图标,准备给用户A发送短信,此时会再次拉起短信应用且当前处于短信应用的发送页面。
![uiability_not_first_started](figures/uiability_not_first_started.png) ![uiability_not_first_started](figures/uiability_not_first_started.png)
针对以上场景,即当应用A的UIAbility实例已创建,并且处于该UIAbility实例对应的主页面中,此时,从应用B中需要再次启动应用A的该UIAbility,并且需要跳转到不同的页面,这种情况下要如何实现呢? 针对以上场景,即当应用A的UIAbility实例已创建,并且处于该UIAbility实例对应的主页面中,此时,从应用B中需要再次启动应用A的该UIAbility,并且需要跳转到不同的页面,这种情况下要如何实现呢?
...@@ -432,12 +432,12 @@ Call调用的使用场景主要包括: ...@@ -432,12 +432,12 @@ Call调用的使用场景主要包括:
**表1** Call调用相关名词解释 **表1** Call调用相关名词解释
| 名词 | 描述 | | 名词 | 描述 |
| -------- | -------- | | -------- | -------- |
| CallerAbility | 进行Call调用的UIAbility(调用方)。 | | CallerAbility | 进行Call调用的UIAbility(调用方)。 |
| CalleeAbility | 被Call调用的UIAbility(被调用方)。 | | CalleeAbility | 被Call调用的UIAbility(被调用方)。 |
| Caller | 实际对象,由startAbilityByCall接口返回,CallerAbility可使用Caller与CalleeAbility进行通信。 | | Caller | 实际对象,由startAbilityByCall接口返回,CallerAbility可使用Caller与CalleeAbility进行通信。 |
| Callee | 实际对象,被CalleeAbility持有,可与Caller进行通信。 | | Callee | 实际对象,被CalleeAbility持有,可与Caller进行通信。 |
Call调用示意图如下所示。 Call调用示意图如下所示。
...@@ -462,15 +462,15 @@ Call功能主要接口如下表所示。具体的API详见[接口文档](../refe ...@@ -462,15 +462,15 @@ Call功能主要接口如下表所示。具体的API详见[接口文档](../refe
**表2** Call功能主要接口 **表2** Call功能主要接口
| 接口名 | 描述 | | 接口名 | 描述 |
| -------- | -------- | | -------- | -------- |
| startAbilityByCall(want: Want): Promise<Caller> | 启动指定UIAbility并获取其Caller通信接口,默认为后台启动,通过配置want可实现前台启动,详见[接口文档](../reference/apis/js-apis-ability-context.md#abilitycontextstartabilitybycall)。AbilityContext与ServiceExtensionContext均支持该接口。 | | startAbilityByCall(want: Want): Promise<Caller> | 启动指定UIAbility并获取其Caller通信接口,默认为后台启动,通过配置want可实现前台启动,详见[接口文档](../reference/apis/js-apis-ability-context.md#abilitycontextstartabilitybycall)。AbilityContext与ServiceExtensionContext均支持该接口。 |
| on(method: string, callback: CalleeCallBack): void | 通用组件Callee注册method对应的callback方法。 | | on(method: string, callback: CalleeCallBack): void | 通用组件Callee注册method对应的callback方法。 |
| off(method: string): void | 通用组件Callee解注册method的callback方法。 | | off(method: string): void | 通用组件Callee解注册method的callback方法。 |
| call(method: string, data: rpc.Sequenceable): Promise<void> | 向通用组件Callee发送约定序列化数据。 | | call(method: string, data: rpc.Sequenceable): Promise<void> | 向通用组件Callee发送约定序列化数据。 |
| callWithResult(method: string, data: rpc.Sequenceable): Promise<rpc.MessageParcel> | 向通用组件Callee发送约定序列化数据, 并将Callee返回的约定序列化数据带回。 | | callWithResult(method: string, data: rpc.Sequenceable): Promise<rpc.MessageParcel> | 向通用组件Callee发送约定序列化数据, 并将Callee返回的约定序列化数据带回。 |
| release(): void | 释放通用组件的Caller通信接口。 | | release(): void | 释放通用组件的Caller通信接口。 |
| on(type: "release", callback: OnReleaseCallback): void | 注册通用组件通信断开监听通知。 | | on(type: "release", callback: OnReleaseCallback): void | 注册通用组件通信断开监听通知。 |
设备内通过Call调用实现UIAbility交互,涉及如下两部分开发: 设备内通过Call调用实现UIAbility交互,涉及如下两部分开发:
...@@ -486,9 +486,9 @@ Call功能主要接口如下表所示。具体的API详见[接口文档](../refe ...@@ -486,9 +486,9 @@ Call功能主要接口如下表所示。具体的API详见[接口文档](../refe
1. 配置Ability的启动模式。 1. 配置Ability的启动模式。
配置module.json5,将CalleeAbility配置为单实例"singleton"。 配置module.json5,将CalleeAbility配置为单实例"singleton"。
| Json字段 | 字段说明 | | Json字段 | 字段说明 |
| -------- | -------- | | -------- | -------- |
| "launchType" | Ability的启动模式,设置为"singleton"类型。 | | "launchType" | Ability的启动模式,设置为"singleton"类型。 |
Ability配置标签示例如下: Ability配置标签示例如下:
......
# FA模型应用程序包结构 # FA模型应用程序包结构
基于[FA模型](application-configuration-file-overview-fa.md)开发的应用,其应用程序包结构如[应用程序包结构(FA模型)](figures/FA_3.png)所示。开发者需要熟悉应用程序包结构相关的基本概念。 基于[FA模型](application-configuration-file-overview-fa.md)开发的应用,其应用程序包结构如下图**应用程序包结构(FA模型)**所示。开发者需要熟悉应用程序包结构相关的基本概念。
FA模型与Stage模型不同之处在于HAP内部文件存放位置不同,FA模型将所有的资源文件、库文件和代码文件都放在assets文件夹中,在文件夹内部进一步区分。 FA模型与Stage模型不同之处在于HAP内部文件存放位置不同,FA模型将所有的资源文件、库文件和代码文件都放在assets文件夹中,在文件夹内部进一步区分。
...@@ -11,7 +11,7 @@ FA模型与Stage模型不同之处在于HAP内部文件存放位置不同,FA ...@@ -11,7 +11,7 @@ FA模型与Stage模型不同之处在于HAP内部文件存放位置不同,FA
- assets是HAP所有的资源文件、库文件和代码文件的集合,内部可以分为entry和js文件夹。entry文件夹中存放的是resources目录和resources.index文件。 - assets是HAP所有的资源文件、库文件和代码文件的集合,内部可以分为entry和js文件夹。entry文件夹中存放的是resources目录和resources.index文件。
- resources目录用于存放应用的资源文件(字符串、图片等),便于开发者使用和维护,详见[资源文件的使用](../key-features/multi-device-app-dev/resource-usage.md/) - resources目录用于存放应用的资源文件(字符串、图片等),便于开发者使用和维护,详见[资源文件的使用](../key-features/multi-device-app-dev/resource-usage.md)
- resources.index是资源索引表,由IDE调用SDK工具生成。 - resources.index是资源索引表,由IDE调用SDK工具生成。
...@@ -19,6 +19,5 @@ FA模型与Stage模型不同之处在于HAP内部文件存放位置不同,FA ...@@ -19,6 +19,5 @@ FA模型与Stage模型不同之处在于HAP内部文件存放位置不同,FA
- pack.info是Bundle中用于描述每个HAP属性的文件,例如app中的bundleName和versionCode信息、module中的name、type和abilities等信息,由IDE工具生成Bundle包时自动生成。 - pack.info是Bundle中用于描述每个HAP属性的文件,例如app中的bundleName和versionCode信息、module中的name、type和abilities等信息,由IDE工具生成Bundle包时自动生成。
**图1** 应用程序包结构(FA模型)
**图1** 应用程序包结构(FA模型)   ![app-pack-fa](figures/app-pack-fa.png)
![FA_3](figures/FA_3.png) \ No newline at end of file
# Stage模型应用程序包结构 # Stage模型应用程序包结构
基于[Stage模型](application-configuration-file-overview-stage.md)开发的应用,经编译打包后,其应用程序包结构如[应用程序包结构(Stage模型)](figures/Stage-.png)所示。开发者需要熟悉应用程序包结构相关的基本概念。 基于[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-structure.md)(Harmony Ability Resources)包,即编译后的.tgz文件。
一个Module可以包含一个或多个[UIAbility](../application-models/uiability-overview.md)组件,如[Module与UIAbility组件关系示意图](figures/ability-and-module.png)所示。 一个Module可以包含一个或多个[UIAbility](../application-models/uiability-overview.md)组件,如[Module与UIAbility组件关系示意图](figures/ability-and-module.png)所示。
**图1** Module与UIAbility组件关系示意图   **图1** Module与UIAbility组件关系示意图
![ability-and-module](figures/ability-and-module.png) ![ability-and-module](figures/ability-and-module.png)
全文中介绍到的Module默认指的是“Ability”类型的Module。 全文中介绍到的Module默认指的是“Ability”类型的Module。
...@@ -21,10 +21,10 @@ ...@@ -21,10 +21,10 @@
- 打包后的HAP包结构包括ets、libs、resources等文件夹和resources.index、module.json、pack.info等文件。 - 打包后的HAP包结构包括ets、libs、resources等文件夹和resources.index、module.json、pack.info等文件。
- ets目录用于存放应用代码编译后的字节码文件。 - ets目录用于存放应用代码编译后的字节码文件。
- libs目录用于存放库文件。库文件是OpenHarmony应用依赖的第三方代码(例如.so、.jar、.bin、.har等二进制文件)。 - libs目录用于存放库文件。库文件是OpenHarmony应用依赖的第三方代码(例如.so、.jar、.bin、.har等二进制文件)。
- resources目录用于存放应用的资源文件(字符串、图片等),便于开发者使用和维护,详见[资源文件的使用](../key-features/multi-device-app-dev/resource-usage.md/) - resources目录用于存放应用的资源文件(字符串、图片等),便于开发者使用和维护,详见[资源文件的使用](../key-features/multi-device-app-dev/resource-usage.md)
- resources.index是资源索引表,由IDE编译工程时生成。 - resources.index是资源索引表,由IDE编译工程时生成。
- module.json是HAP的配置文件,内容由工程配置中的module.json5和app.json5组成,该文件是HAP中必不可少的文件。IDE会自动生成一部分默认配置,开发者按需修改其中的配置。详细字段请参见[应用配置文件](application-configuration-file-overview-stage.md) - module.json是HAP的配置文件,内容由工程配置中的module.json5和app.json5组成,该文件是HAP中必不可少的文件。IDE会自动生成一部分默认配置,开发者按需修改其中的配置。详细字段请参见[应用配置文件](application-configuration-file-overview-stage.md)
- pack.info是Bundle中用于描述每个HAP属性的文件,例如app中的bundleName和versionCode信息、module中的name、type和abilities等信息,由IDE工具生成Bundle包时自动生成。 - pack.info是Bundle中用于描述每个HAP属性的文件,例如app中的bundleName和versionCode信息、module中的name、type和abilities等信息,由IDE工具生成Bundle包时自动生成。
**图2** 应用程序包结构(Stage模型)   **图2** 应用程序包结构(Stage模型)
![Stage-](figures/Stage-.png) ![app-pack-stage](figures/app-pack-stage.png)
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册