鸿蒙OS是一个分布式操作系统,而Ability作为它调度的基本单元,那么,一个分布式Hello HARMony可以有几种写法呢?
# 分布式Hello Harmony用例
## 1. 根据Ability类型
### 1). FA <-> FA FA = Feature Ability,用于显示的前台能力。
可以理解为两个前端应用在协作。
FA/FA模式的Hello Harmony,就是我说Hello, 你说Harmony。
在鸿蒙OS中,FA与FA的协作,有三种方式:
- * 启动,即一个FA启动另一个FA
这严格来说并不算是一个协作,只是与别的操作系统类似,鸿蒙OS也提供了不同应用或者进程相互启动的能力。
- * 迁移(转移,流转,接力),即一个界面从一台设备,转移到另一台设备上。
例如,导航,查询的时候在手机上,开车的时候在汽车车机上,走路的时候在手表上,甚至耳机上。
例如,视频播放,从手机转移到电视。
- * 协同,多台设备在各自的界面上一起完成同一个工作。
例如,多人一起修改一个文档。
例如,多人一起联机玩游戏。 需要注意的是,在鸿蒙OS的设计中,FA之间的协同,如果不依靠PA的帮助,是很难直接进行的。这就好像是MVC架构中,为了解耦合,不同的View之间通常并不直接进行交互。 我们当然可以利用一些非鸿蒙OS独有的特性,例如网络,在不同FA之间搭建起沟通的桥梁,不过,这就非常不鸿蒙了。
### 2). FA <-> PA
PA = Particle Ability,不带显示的后台服务能力。
前台界面与后台服务进行协作。
FA/PA的Hello Harmony,就是你大声说Hello, 我小声说Harmony。
这种交互,即使是在现在的APP开发中,也是一种常见的前后端分离的架构设计。
利用鸿蒙OS的多设备连接能力,可以方便实现,在最适合显示(交互)的设备上运行FA,而在算力更强更富余的设备上运行PA。 例如,用手机与电视进行游戏,手机充当游戏主机(和手柄),而电视充当显示。
### 3). PA <-> PA
不同后台服务进行协作。
PA/PA的Hello Harmony,就是你小声对我说Hello,我也小声回复Harmony。
这样,不同的PA可以专注负责自己的业务,然后通过组合,完成更复杂的任务。
其实,Data Ability 可以认为就是专门处理数据存储的任务的一个PA,而普通Service Ability则是负责处理具体的任务,利用DA,可以轻松为一个任务增加存储功能。
## 2. 根据应用 * 1). 同应用
* 2). 不同应用
其实,应用的概念在鸿蒙OS中已经被边缘化了,而Ability才是现在的C位。
所以,并不存在应用A说Hello,应用B说Harmony这种场景,只有Ability A说Hello,Ability B说Harmony的场景。
基于这个设定,其实,我们不应关心Ability属于哪个应用,因为每个Ability都是独立的。
如果你还是绕不过来,你可以暂时直接认为一个Ability就是一个应用。但是,要注意,在鸿蒙OS中,一个Ability很可能没法像传统的App那样,独立完成一个任务。
而在代码的组织和编写时,对于共同完成一个任务的不同Ability,它们之间难免会有交集,而这,也仅仅限于代码编写时,在运行时,每个Ability都有自己的进程和内存空间。
## 3. 根据设备 * 1). 单设备
* 2). 跨设备
鸿蒙OS天生具有连接多设备的能力,而对于开发者来说,需要考虑的是当前环境下有多少已经连接的设备,而不是要去连接哪台设备。
具体的说,就是,我们不需要考虑网络的问题,而是要考虑,在当前环境中,用哪个设备来完成任务更合理。
有多设备环境下的分布式Hello Harmony, - * 可以每台设备轮流说Hello Harmony,即你说Hello Harmony,我也说Hello Harmony。
- * 也可以所有设备一起完成一个Hello Harmony,即你说Hello 我说 Harmony。
# 参考文档
|