714 Star 4.3K Fork 1.2K

OpenHarmony / docs

 / 详情

OpenHarmony 的基础概念和术语问题征集--欢迎大家跟帖

Done
Task member
Opened this issue  
2021-09-10 11:12

概念和术语问题征集帖

_ 同一个概念的讨论,建议在首次提出的楼层中充分讨论,一个概念一个楼层。 _

背景

  • 随着 OpenHarmony 开源项目的推广,目标是面向全场景、全连接、全智能时代,搭建一个智能终端设备操作系统的框架和平台,促进万物互联产业的繁荣发展。
  • 新的概念FA、PA、SA、HAP、HDF、HDI、HCS、IDN、MSDP等概念层出不穷......

问题

  • 新的术语和概念多,且缺乏精准定义,每个人对其的理解又不一致,导致大家沟通困难、效率低下

措施

  • 开贴收集大家对OpenHarmony 架构和基础概念、专业术语的理解的存在的一些问题,有针对性的组织进行优化,采用更加通俗易懂的方式进行定义,使得OpenHarmony的所提出来的框架、基础概念能被大家所理解

  • 组织相关领域专家线上/线下基础知识介绍和沟通,并录制视频托管至哔哩哔哩官方网站,供大家回放和查看。

问题反馈方式: (直接在该ISSUE中跟帖反馈,参考格式如下)

  • 对OpenHarmony的基础框架、概念、术语等的问题
  • 希望获得什么方式进行解答和赋能(官方指导资料、线上视频培训、线下活动、动漫演示)

相关参考

同一个概念的讨论,建议在首次提出的楼层中充分讨论,一个概念一个楼层。

Attachments

Comments (45)

jinguang created任务
jinguang set assignee to jinguang
jinguang set related project to OpenHarmony
jinguang set start time to 2021-09-10
jinguang set deadline to 2021-09-30
jinguang set top level to High
jinguang set priority to Serious
jinguang set related repository to OpenHarmony/docs
jinguang added
 
SIG_Docs
label
jinguang changed priority from Serious to Not specified
jinguang changed description
jinguang changed description
jinguang changed description
Expand operation logs

我先来。
概念/术语:Ability

Ability的是OHOS最为重要的概念,但非常遗憾,这个概念的定义就很不清晰。在OHOS术语表中如下描述:

应用的重要组成部分,是应用所具备能力的抽象。Ability分为两种类型,Feature Ability和Particle Ability。

但在HarmonyOS编程IDE中,就变成了page, service, data和CA。

而在doc文档里又是这样描述的:

Ability分为FA(Feature Ability)和PA(Particle Ability)两种类,其中FA支持Page Ability,PA支持Service Ability和Data Ability。

这里面混淆的地方在于,既然Feature Ability=Page Ability,那为什么还要保留一个Page Ability的名字。
能否这样定义Ability分为FA(Feature Ability)和PA(Particle Ability),而PA有可以分为SA(Service Ability)和DA(Data Ability),另外CA是啥东西,能否去掉?

这么改还有一个原因就是如果都用JS编程,那实际上是只有FA和Particle Ability的。更没有Page这个概念保留的必要。

如果是同一个概念的讨论,建议在同一个楼层下回复讨论

概念/术语:Service

Service这个术语是滥用最严重的。

在LiteIPC里面,Service是指一个进程对外提供的服务,这个服务有Service接口,向SAMGR注册。

在L2的启动框架里面,各个被sa_main拉起来的进程,也叫Service。

在HarmonyOS创建APP的时候,选择的类型有一个叫Service,对应的是原子化服务。

Service这个词其本身就非常不适合单独使用做来术语,因为其意义过于泛化,建议要么组合使用,要么更换成其他更具体的名词。

如:
LiteIPC里面改为IPC Service
L2启动框架里面改为Service Process
HarmonyOS的应用类型改为Service Application

或者:
LiteIPC里面仍旧叫Service
L2启动框架改为叫System Ability Server
HarmonyOS的应用类型改为Routine一类的词汇

概念:Mini,Small,Standard

一开始,我们有L0-L5的概念,大家都形成共识了。因为一些原因,我们现在改了,改成了Mini,Small,Standard,但是问题来了,我们还有Lite的概念,我们有内核的LiteOS,代码里面也都是分Standard和Lite,请问Mini,Small,和Lite是什么关系?其实在英语里面,这三个根本区分不出来哪个大哪个小,无法让人直观理解。

建议,废除Mini,Small,Standard的定义,回归L0-L5的定义,L0和L1定义为Lite,L2以上定义为Standard。

收到 感谢钊哥的反馈

既然只有Lite 和 Standard,又何必再回归到L0、L1、L2、L3、L4、L5。废除Mini,Small,Standard 改称 Lite 和Standard 两个不就够了? 回归L0-L5会导致政策反复,影响更不太好

L0和L1架构悬殊,用一个词汇来称呼是不行的LiteOS-m和LiteOS-a差距还是很大。

既然分不开,且结果最终分类还是三种,那Mini,Small,Standard 倒也没啥问题。LiteOS-m LiteOS-a的命名应该来自 ARM Cortex-M 和 ARM Cortex-A,我觉得这个可能需要改一下。比如 GD32VF103是RISC-V系列的MCU又或者是平头哥玄铁910这种SOC呢。建议改成LiteOS-Mini LiteOS-Small。虽然我也同意mini small区分不出来哪个大哪个小,存在理解障碍

你说的有道理,但是代码层面确实LiteOS-M和LiteOS-a是按照xxxx_lite这样的方式组织的。

L2 是基于 L1 的吗?

不是,没有依赖关系

HDF框架里面有个模块叫Abilities,建议改名,改为Utils

HDF框架里面的OSAL与系统框架里面的KAL非常容易混淆,建议改掉。

Permission和Capability两个概念应该统一,现在不同的地方有不同的叫法。

钊哥 你说的这个permission 和 capability 两个在OpenHarmony里面是说:permission权限控制,capability能力集吗?
或者说这两个概念在OpenHarmony 有时候出现混用的情况?

不是,都是用来形容权限的,你可以看看权限部分的代码,有的用permission,有的用capability

Page Ability 和 Particle Ability,如果让我缩写就都是PA,但是不知道为啥官方定义 Page 不缩写,掩耳盗铃吗?

感谢鹏飞的反馈

Small System 和 Standard System 界限定义非常模糊,按照内存划分不太准确,应该是以使用轻量级组件构建的系统叫Small System,使用标准组件构建的系统叫Standard System, 准确划分好 轻量级组件、标准组件、公用组件

同一个概念的讨论,建议在首次提出的楼层中充分讨论,一个概念一个楼层。

NEEN changed description

请教一下,编译等指令中使用到hb set、hb build中的hb是什么意思,是什么的缩写?

我理解应该是harmony build

那么编译指令hb build -f不是就重复了嘛,如果缩写中含有build的话 :joy:

hb = Harmony Building, 是Open Harmony自研的命令行构建工具。它是一个可执行程序,传入set和build等参数完成不同功能。

Building的意思是大楼,只能是HarmonyOS Build,而现在我们叫OpenHarmony,那这个就对不上了。而且前面兄弟说的对hb build就成了HarmonyOS build build,就重复了。

概念/术语:Ability

Feature Ability,目前来看是指界面上显示的组件,直接改叫Page Ability或者Surface Ability
Particle Ability,避免和Page Ability混淆,建议换一个名称

谢谢,意见收到
下来我们根据大家反馈的意见,统一优化一下

概念:bundle

这个概念也是乱用的,OHOS的包管理模块BM,就是bundle manager,有应用的安装、卸载功能,实际管理的是HAP,那HAP和bundle是啥关系?

hpm当中的组件,英文名也是bundle,实际上是OHOS一组代码。又冲突了。

概念:component

这个词汇就更加不清楚,JS编程框架里面有component,Java框架里有第三方组件Third-party component,编译构建体系里面也有component,这些都是什么关系?我们现在搞组件开发大赛,实际上就让开发者无所适从,不知道要的是什么类型的组件。

Lite=L1, Lite minimal=L0

Rich>=L2, lightweight aka Lite=L1, Lite minimal or lite min=L0

概念/术语与系统/子系统/模块的名字解耦,典型的如compile/runtime之于Ark,又如liteOS是已经使用的名称,Lite就可以不再是lite日常用语所对应概念,而只是一个名字,哪怕这个liteOS的实现(implementation)实际上是一个rich OS(Terminology),没有隐喻,就像“张三”不一定排行老三一样。因此对系统/子系统命名规则可以是“codename”,譬如🐻,🐯

同意,不需要刻意非要是名字直译英文,只要是妥当的,能够让人建立联想的就可以。不要干嘛都是Service,难道大家这么喜欢搞服务吗?大宝剑出身?

观摩学习中,不过是要规范一些常用称谓。

NEEN changed description

HDF涉及很多名词术语,看似通用易懂,如设备、器件、接口、服务、驱动、host、client、node等,然而如果没有对HDF较深刻的认识,经常不知其所指是哪层哪级哪面哪个东西。印象中只有看有例子的文章时,才容易理解意思。如果可能,建议也一并梳理界定

HDF的Platform也是一个不好理解的词汇。HDF最拗口的是有一个DeviceServiceManager,还有一个DeviceManagerService。

收到反馈 谢谢老凯
近期计划与对应领域沟通,在 driver sig 中组织大家以开放方式研讨一下对应的问题。

轻设备和富设备,南向和北向 好像是内部说法,不对外呈现,但资料中又大量出现,对外应该怎么说。建议能够统一一个说法。

这个问题前半部分等同于:#I49H96:OpenHarmony 的基础概念和术语问题征集--欢迎大家跟帖?from=project-issue#note_6621717_link
后半部分南向设备和北向应用接口应该说是借用了运营商的描述思路,不算是纯内部说法(https://zh.wikipedia.org/wiki/OpenFlow);在资料中是没有一个统一的对南向和北向接口定义的解读确实是欠妥,这块我们记录下来,一并刷新,谢谢你反馈的宝贵意见

【卡片】这个术语,有的场景用service widget, 有的场景用card.有没有什么区分的原则。

service widget 是指服务卡片,将用户应用程序的重要信息以服务卡片的形式展示在桌面,用户可通过快捷手势使用卡片,以达到服务直达、减少层级跳转的目的;
card 是指连接弹窗,设备连接弹窗是一种轻量界面,适用于设备连接过程。连接弹窗主要包含功能介绍、登录授权和配网等信息。这个翻译感觉不是太好,已经与资料负责的同事沟通,建议修改更合适的名称

【原子化布局】 的英文术语有没有比较权威的?目前看到的有Adaptive UX framework 和 atomic adaptive layout

@Annie_wang "Adaptive UX framework " 描述在哪儿看到的?我这边只在harmonyos开发网站上找到 atomic adaptive layout英文描述

此问题需求收集暂时关闭,对应的解决和优化思路参考附件所示

jinguang upload file社区术语评审建议.xlsx
jinguang changed issue state from 待办的 to 已完成
jinguang changed top level from High to Not top

Sign in to comment

Status
Assignees
Projects
Milestones
Pull Requests
Successfully merging a pull request will close this issue.
Branches
Planed to start   -   Planed to end
-
Top level
Priority
Duration (hours)
Confirm
参与者(14)
5126245 dongjinguang 1625667980 1817662 zzzuo 1630123833 8118894 li yangshui and jiaolong 1615518004
加载更多
1
https://git.oschina.net/openharmony/docs.git
git@git.oschina.net:openharmony/docs.git
openharmony
docs
docs

Search