跟阿斌一起学鸿蒙(4). 分布式Hello Harmony的N种写法
目录
假如,鸿蒙能让你用电饭煲来遥控电视...
跟阿斌一起学鸿蒙(1). Hello Harmony
跟阿斌一起学鸿蒙(2). Ability vs App?
跟阿斌一起学鸿蒙(3). 远程虚拟设备的限制和使用方法
鸿蒙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。
参考文档
* Ability 概述 > https://developer.harmonyos.com/cn/docs/documentation/doc-guides/ability-ability-overview-0000000000029852 * 分布式任务调度 > https://developer.harmonyos.com/cn/docs/documentation/doc-guides/ability-distributed-overview-0000001050419345
后续
接下来,我将对不同的写法,一一进行讲解,欢迎持续关注。
作者:IT男阿斌
想了解更多内容,请访问: 51CTO和华为官方战略合作共建的鸿蒙技术社区https://harmonyos.51cto.com

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Canal 组件简介与 vivo 帐号实践
互联网应用随着业务的发展,部分单表数据体量越来越大,应对服务性能与稳定的考虑,有做分库分表、数据迁移的需要,本文介绍了vivo帐号应对以上需求的实践。 一、前言 Canal 是阿里巴巴开源项目,关于什么是 Canal?又能做什么?我会在后文为大家一一介绍。 在本文您将可以了解到vivo帐号使用 Canal 解决了什么样的业务痛点,基于此希望对您所在业务能有一些启示。 二、Canal介绍 1. 简介 Canal [kə'næl],译意为水道/管道/沟渠,主要用途是基于 MySQL 数据库增量日志解析,提供增量数据订阅和消费。 早期阿里巴巴因为杭州和美国双机房部署,存在跨机房同步的业务需求,实现方式主要是基于业务 trigger 获取增量变更。从 2010 年开始,业务逐步尝试数据库日志解析获取增量变更进行同步,由此衍生出了大量的数据库增量订阅和消费业务。 2. 工作原理 2.1 MySQL 主备复制原理 Canal最核心的运行机制就是依赖于MySQL的主备复制,我们优先简要说明下MySQL主备复制原理。 MySQL master 将数据变更写入二进制日志( binary log, 其...
- 下一篇
我的百度十年 | 云原生时代架构师的十大核心能力(下)
自从2009年入职百度以来,已经经历了11年了,我自己从一线研发工程师开始,也逐步成长成为了带领复杂技术方向的技术负责人。10年多的工作历程,让我有幸经历了大范围的技术演变,特别是云计算和云原生技术从朦胧到普及,对工程师和架构师的要求也发生了不少变化。趁着自己入职11周年的日子,结合我自己在百度的成长历程,总结下我认为在云计算特别是云原生时代,对软件架构师的核心能力要求,希望帮助大家在通往架构师的路上少走弯路。 本文是《云原生时代架构师的十大核心能力》下篇,若想了解文章上篇内容,可以阅读我的百度十年 | 云原生时代架构师的十大核心能力(上) (六)沟通表达和合作双赢能力 沟通表达是工程师必不可少的基本能力。随着自身的成长,我也越来越多的参与到了诸如职称评定,技术评审和工作汇报等会议中。我发现很多同学做不到高效清晰的表达。比如有的同学在没有任何背景情况下,直接讲解决方案,下面听的同学完全不清楚方案要解决什么问题,自然无法进行判断;还比如有的同学对设计方案的局部细节花费了大量的时间进行描述,但是没有全局视角或者整体的介绍;再比如有的同学在做工作总结和汇报时,对技术方案进行了全面的说明,但...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker安装Oracle12C,快速搭建Oracle学习环境
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- SpringBoot2整合Redis,开启缓存,提高访问速度
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- CentOS7设置SWAP分区,小内存服务器的救世主
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS7安装Docker,走上虚拟化容器引擎之路
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- CentOS关闭SELinux安全模块