赞
踩
鸿蒙中的config.json应该类似于Android开发中Manifest.xml,可以进行页面的配置。根据顺序,会识别启动应用的时候,要打开哪个界面。
一个 HarmonyOS 应用可以包含多个 Ability,Ability 可以分为:
Feature Ability(简称 FA),有界面,也被称为元程序
Particle Ability(简称 PA),无界面,也被称为元服务
FA 类似于 Android 的 Activity ;PA 类似于 Android 的 Services。
FA 支持 Page Ability,代表了 UI 的能力:Page 模板是 FA 唯一支持的模板,用于提供与用户交互的能力。一个Page实例可以包含一组相关页面,每个页面用一个 AbilitySlice 实例表示。
PA 支持 Service Ability 和 Data Ability:
Service 模板:用于提供后台运行任务的能力,提供应用服务,例如播放音乐等。
Data 模板:用于对外部提供统一的数据访问抽象,提供了统一的数据访问接口,方便 FA 的统一调用,例如对本地文件的读取。
(那么FA与PA如何交互呢?我也不太清楚,继续学习。 -- 在下加的。)
使用 Ability 时必须在配置文件 config.json 中注册该 Ability ,设置相应的属性,该文件存储在每个应用程序的 Java 代码的根目录中。
在 Java 中,Ability 是一个类。事实上,鸿蒙应用程序的开发就是对 Ability 进行继承并进行应用扩展。所有的应用程序的功能最终必须要体现在开发者所创建的 Ability 的子类中。
Page Ability 是 Feature Ability 唯一支持的模板。用于提供与用户的交互能力,其实就是页面的父级。
一个 Page 可以由一个或多个 AbilitySlice 构成,AbilitySlice 是指应用的单个页面及其控制逻辑的总和。
官方认为当一个 Page 由多个 AbilitySlice 共同构成时,这些 AbilitySlice 页面提供的业务能力应具有高度相关性。
在配置文件(config.json)中注册 Ability 时,可以通过配置 Ability 元素中的 “type” 属性来指定 Ability 模板类型,示例如下:
(下边这张图,在下不是非常明白吧。感觉就像是类似于Android的activity栈?)
Ability 生命周期介绍(Ability Life Cycle)是 Ability 被调度到 INACTIVE、ACTIVE、BACKGROUND 等各个状态的统称(主要涉及 PageAbility 类型和 ServiceAbility 类型的 Ability)。
PageAbility 类型的 Ability 生命周期流转如下图所示:
主要生命周期如下:
首先初始化 Ability,初始化完毕后状态是 INITIAL 状态
初始化完成后, 会调用 onStart() 方法,初始化 UI 界面中使用到的控件和变量, 执行完毕后状态变为 INACTIVE 状态
快要显示时,会调用 onActive() 方法,状态变为 ACTIVE 状态
如果由于某些原因,该 Page Ability 失去焦点,进入后台,如弹出对话框,另一个 Page Ability 前台显示,会回调 onInactive() 方法,状态变为 INACTIVE 状态
窗口彻底不显示,但是还处于后台状态,会回调 onBackground() 方法,状态变 BACKGROUND 状态
有几种特殊情况:
如果当前处于 INACTIVE 状态,用户返回 Page Ability,则回调 onActive() 方法,进入 ACTIVE 状态
如果当前的 Page Ability 处于 BACKGROUND 状态,当用户从后台返回前台时, 会回调 onForeground() 方法,状态变为 INACTIVE 状态
如果当前的 Page Ability 处于 BACKGROUND 状态,当该 Ability 彻底销毁,正在结束,因内存不足终止,用户重新进入该界面时,会回调 onStop() 方法,状态变为 INITIAL 状态
生命周期图如下:
--- 应该是对应着Android的Service。---
Service Ability 是 Particle Ability 支持的模板之一。用于后台运行任务(如执行音乐播放、文件下载等),但不提供用户交互界面。
Service 可由其他应用或 Ability 启动,即使用户切换到其他应用,Service 仍将在后台继续运行。
Service 是单实例的。在一个设备上,相同的Service 只会存在一个实例。如果多个 Ability 共用这个实例,只有当与 Service 绑定的所有 Ability 都退出后,Service 才能够退出。
由于 Service 是在主线程里执行的,因此,如果在 Service 里面的操作时间过长,开发者必须在 Service 里创建新的线程来处理,防止造成主线程阻塞,应用程序无响应。
与 Page 类似,Service 也拥有生命周期,如图所示:
根据调用方法的不同,其生命周期有以下两种路径:
启动 Service:该 Service 在其他 Ability 调用startAbility()时创建,然后保持运行。其他 Ability 通过调用stopAbility()来停止 Service,Service 停止后,系统会将其销毁。
连接 Service:该 Service 在其他 Ability 调用 connectAbility() 时创建,客户端可通过调用 disconnectAbility() 断开连接。多个客户端可以绑定到相同 Service,而且当所有绑定全部取消后,系统即会销毁该 Service。
connectAbility() 也可以连接通过 startAbility() 创建的 Service 。在配置文件中,“module > abilities”字段下对当前 Service 做如下配置:
- {
- "module": {
- ...
- "abilities": [
- {
- ...
- "name": ".ServiceAbility",
- "type": "service",
- "visible": true,
- ...
- }
- ]
- ...
- }
- ...
- }
Data Ability 是 Particle Ability 支持的模板之一。用于应用管理其自身和其他应用存储数据的访问,并提供与其他应用共享数据的方法。
Data 既可用于同设备不同应用的数据共享,也支持跨设备不同应用的数据共享。
数据的存放形式多样,可以是数据库,也可以是磁盘上的文件。Data 对外提供对数据的增、删、改、查,以及打开文件等接口,这些接口的具体实现由开发者提供。
Data 的提供方和使用方都通过 URI(Uniform Resource Identifier)来标识一个具体的数据,例如数据库中的某个表或磁盘上的某个文件。
URI 的组成图如下:
HarmonyOS 的 URI 仍基于 URI 通用标准,格式如下:
scheme:协议方案名,固定为“dataability”,代表 Data Ability 所使用的协议类型。
authority:设备 ID。如果为跨设备场景,则为目标设备的 ID;如果为本地设备场景,则不需要填写。
path:资源的路径信息,代表特定资源的位置信息。
query:查询参数。
fragment:可以用于指示要访问的子资源。
URI 示例:
- 跨设备场景:
- dataability://device_id/com.domainname.dataability.persondata/person/10
-
- 本地设备:
- dataability:///com.domainname.dataability.persondata/person/10
在配置文件中,“module > abilities”字段下对当前 Data 做如下配置:
- {
- "module": {
- ...
- "abilities": [
- {
- ...
- "type": "data"
- ...
- }
- ]
- ...
- }
- ...
- }
赞
踩
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。