代码拉取完成，页面将自动刷新
_ 同一个概念的讨论，建议在首次提出的楼层中充分讨论，一个概念一个楼层。 _
开贴收集大家对OpenHarmony 架构和基础概念、专业术语的理解的存在的一些问题，有针对性的组织进行优化，采用更加通俗易懂的方式进行定义，使得OpenHarmony的所提出来的框架、基础概念能被大家所理解
组织相关领域专家线上/线下基础知识介绍和沟通，并录制视频托管至哔哩哔哩官方网站，供大家回放和查看。
同一个概念的讨论，建议在首次提出的楼层中充分讨论，一个概念一个楼层。
我先来。
概念/术语：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这个概念保留的必要。
10
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。
概念/术语：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一类的词汇
5
概念：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。
3
既然只有Lite 和 Standard,又何必再回归到L0、L1、L2、L3、L4、L5。废除Mini，Small，Standard 改称 Lite 和Standard 两个不就够了? 回归L0-L5会导致政策反复，影响更不太好
既然分不开，且结果最终分类还是三种，那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区分不出来哪个大哪个小，存在理解障碍
HDF框架里面有个模块叫Abilities，建议改名，改为Utils
Permission和Capability两个概念应该统一，现在不同的地方有不同的叫法。
Small System 和 Standard System 界限定义非常模糊，按照内存划分不太准确，应该是以使用轻量级组件构建的系统叫Small System,使用标准组件构建的系统叫Standard System, 准确划分好 轻量级组件、标准组件、公用组件
请教一下，编译等指令中使用到hb set、hb build中的hb是什么意思，是什么的缩写？
我理解应该是harmony build
那么编译指令hb build -f不是就重复了嘛，如果缩写中含有build的话 
hb = Harmony Building, 是Open Harmony自研的命令行构建工具。它是一个可执行程序，传入set和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”，譬如🐻，🐯
观摩学习中，不过是要规范一些常用称谓。
HDF涉及很多名词术语，看似通用易懂，如设备、器件、接口、服务、驱动、host、client、node等，然而如果没有对HDF较深刻的认识，经常不知其所指是哪层哪级哪面哪个东西。印象中只有看有例子的文章时，才容易理解意思。如果可能，建议也一并梳理界定
轻设备和富设备，南向和北向 好像是内部说法，不对外呈现，但资料中又大量出现，对外应该怎么说。建议能够统一一个说法。
这个问题前半部分等同于：#I49H96:OpenHarmony 的基础概念和术语问题征集--欢迎大家跟帖
后半部分南向设备和北向应用接口应该说是借用了运营商的描述思路，不算是纯内部说法（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英文描述
此问题需求收集暂时关闭，对应的解决和优化思路参考附件所示
登录 后才可以发表评论
