【经验】简谈HarmonyOS的Ability设计理念

陪孩子上体育课闲暇,看到大家对鸿蒙热情高涨,也来凑凑热闹,作为内部人有些信息肯定是不能透漏,见谅。就对现在公布的一些资料,回顾一下HarmonyOS最核心概念Ability我个人的理解。

前天在一个技术群里面,一个哥们说了一段话,我觉得挺符合技术上思考的:

来自OSDT群里面一个兄弟见解:
实际上,操作系统不是“凭空”设计出来的,并不是一个人大吼一声“我要设计操作系统了”,他就可以坐下来设计操作系统了。你去观察每一个系统,每一个组件,它一定是有一个“原系统”在那里供它抄的。包括llvm,也是作者从gcc里面一点一点挖出来的。unix从multics挖出来,linux抄了unix和minix。从这个角度讲,鸿蒙应该也必须去抄一个系统。抄的过程就是理解和掌握的过程,真的掌握了,就有改进的想法了。

不要刻意的去创新,而是发现痛点,去改进,先fork,再rewrite

对于国内在构建生态OS上人才积累和经验缺乏,凭空去想象一个OS基本是不现实的。设计一个OS依赖设计者的能力,经验,背景等及其系统未来的愿景。鸿蒙设计参与者基本来自几个方面:华为大平台领域,老终端(类似我这种一直做Android十几年的人),及其前AOS团队(华为前几年做的一个终端OS)。设计来自不同领域,因此前期设计理念碰撞还是很充分的,包括商业模式分析,技术创新性论证及其与流行OS的差异性等等,我的分析材料都写了100多页,因此大家不用担心Harmony OS会闭门造车,也不要去嘲笑华为啥都不懂。参与设计的技术人,对一个OS的难度及其对现在Android等系统的创新性认识是非常深刻的。

之前我写过一篇文章简单总结了Android应用框架的创新性:https://zhuanlan.zhihu.com/p/…

Android应用框架模型相比其他系统包括IOS都是非常先进的,组件化和服务化是一个非常大的创新。优秀的设计是需要学习的,我最早思考应用框架就是确定一个应用应该怎么构成,为什么这样构成,Android基于四大组件模型进行构建应用,HarmonyOS应该如何构成呢? 这个问题困惑了很久,内部也讨论了很久。大家都知道HarmonyOS面向的是1+8+N全场景分布式OS,那么他的应用框架必须即满足单机应用的开发,还需要满足分布式应用的开发。结合应用服务化理念和分布式应用开发(迁移和协同),是不是可以让应用完全可以能力化和服务化呢?

 

Everything is ?


?应该起个什么名字呢?讨论了两个多小时,大概找了8个名字。抱歉的是这8个名字找不到了,其中我记得包括Atom(原子),MetaAblity(元能力)等。大家对中文名字元能力还是比较感兴趣,中国传统文化“元”有表示万物基本构成的意思。经历不断演化,最终大家看到是官方发布的FA,PA的概念了。

https://developer.harmonyos.com/cn/documentation

EveryThing is Ability。

即HarmonyOS应用有Ablity基本构成,Ability是系统的最小调度单位,也是不同设备之间系统最小迁移单元。Ability在分布式模型有点像Actor(Actors : A model of Concurrent Computation经典模型),需要交互的Ability通过Delegate机制相互通信和交互。

=【】

总之一个OS概念不会凭空创造,肯定会继承前系统经验,结合自己特征去做改动,因此如果你看到HarmonyOS有一些其他系统的经验和不谋而合的理念也没什么奇怪的。


想了解更多内容,请访问:
51CTO和华为官方战略合作共建的鸿蒙技术社区
https://harmonyos.51cto.com?jssq

发表评论

邮箱地址不会被公开。 必填项已用*标注