OH有两种类型的开发者，一个是应用开发者，一个是设备开发者，对于我们来说，我们既是应用开发者又是设备开发者

一、应用开发者

对于OH的应用开发者，目前逐渐推荐使用Stage模型开发程序。Stage的模型如下

根据文中意思：一个应用程序提供两种类型组件，1是UIAbility，2是ExtensionAbility。UI用作交互，Ex用作能力扩展。

这里ExAbility可以是OH默认提供的基本功能，也可以是自己封装的第三方库。

当然，OH的应用开发者默认要使用ArkTS来开发ArkUI，所以学习ArkTS应该是当前第一步骤

二、设备开发者

对于不同的设备，我们应该默认按照标准系统移植方式开发，一方面我们本身是Linux系统厂商，不会也没必要基于轻量（MCU）系统开发，和小型（嵌入式设备）系统开发。包括当前OH提供的api10，都是基于标准系统进行扩展的。这里可以大胆笃定OH默认的发展方向和市场前景在于Linux标准系统侧，与传统Linux桌面系统厂商竞争。

开发标准系统需要自行定义板级配置和为其编写HDF抽象层驱动，主要如文中介绍

标准驱动架构图如下

这里可以知道，标准系统长期应该仍基于Linux的LTS进行开发，OH做的是OSAL层抽象。相关具体的代码位置如下

所以我们的职责目前应该是在LTS的Linux版本，例如4.19和5.10上，搞定OH的OSAL层，这也就搞定了OH的底层

当然，OH的设备开发者默认需要在具体的硬件设备上支持，所以按照OH的SDK的编译构建流程来适配指定的开发板应该是第一步骤

三、其他开发者

根据OH的整体设计，可以发现不仅包括了应用层和内核层，还有框架层和系统服务层，这两层应该怎么办呢

首先，根据OH当前社区发展现状可以知道，OH目前大部分的代码仍是鸿蒙团队和鸿蒙扶持的相关团队在开发

其次，根据和鸿蒙沟通的情况，可以知道OH商务路线策略是扶持多个发行版厂商，而不是建立大一统的开源开放策略，目前鸿蒙内部团队的代码优于开发社区版本1个版本

并且，OH官网的适配样例绝大部分仍处于应用设计层次，并没有涉及系统的层次，参考《OpenHarmony样例展示视频合集》

根据上面两方面信息，可以知道，作为其他公司开发鸿蒙的框架层和系统服务层，有如下缺点

• 非鸿蒙原生团队故接触此两层技术难度较大，且我们非鸿蒙扶持的相关公司
• 代码不是最新的（开源落后鸿蒙团队1个版本）
• 这两个层的代码会经常修改（鸿蒙团队会完善框架）