【经验】简谈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/178396951

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

 

Everything is ？

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

https://link.zhihu.com/?target=https%3A//developer.harmonyos.com/cn/documentation%3Ffrom%3Dtimeline

EveryThing is Ability。

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

=【】

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

原文链接