第5章 一次开发多端部署

本章目标：深入理解开源鸿蒙"一次开发，多端部署"的设计理念、技术实现和实际效果。

---

5.1 核心理念

"一次开发，多端部署"是开源鸿蒙面向开发者最重要的承诺之一。

5.1.1 痛点：跨平台开发的困境

在开源鸿蒙之前，开发者面临一个棘手的问题：同一个应用需要在多种设备上运行，却需要为每种设备开发一个版本。

传统方案的代价：

假设一个应用需要覆盖手机、平板、手表、电视四种设备：

方案	开发成本	维护成本	体验一致性
各设备独立开发	4倍	4倍	各自为政
响应式Web	1倍	1倍	一般（性能差）
跨平台框架（Flutter/React Native）	~1.5倍	~1.5倍	较好（但有限）

各设备独立开发的问题显而易见：同样的业务逻辑要写四遍，Bug要修四遍，新功能要加四遍。即使使用Flutter、React Native等跨平台框架，虽然UI代码可以复用，但不同设备的交互方式差异（手机触控 vs 手表旋钮 vs 电视遥控器）、硬件能力差异（手表没有GPS、电视没有摄像头）仍然需要大量适配工作。

5.1.2 开源鸿蒙的方案

开源鸿蒙的"一次开发多端部署"不是简单的"写一套代码到处跑"，而是通过分层抽象让开发者只需关注业务逻辑，设备差异由系统自动处理。

核心思路是三层抽象：

开发者编写
  │
  │ ① 业务逻辑 + 声明式UI描述
  ↓
┌──────────────────────────────┐
│    ArkUI 框架                │
│                              │
│  ② 根据设备能力自动适配       │
│  - 屏幕尺寸 → 布局自适应      │
│  - 交互方式 → 组件自动切换    │
│  - 功能可用性 → 特性按需加载  │
└──────────────────────────────┘
  │
  │ ③ 渲染到具体设备
  ↓
手机屏幕 / 平板屏幕 / 手表屏幕 / 电视屏幕

第①层（开发者负责）：用ArkTS + ArkUI描述"应用长什么样、做什么"。使用响应式布局（而非绝对坐标），使用抽象组件（而非特定硬件的API）。

第②层（框架自动处理）：ArkUI框架根据当前设备的屏幕大小、交互方式、可用硬件，自动调整UI的呈现方式。

第③层（系统自动处理）：将适配后的UI渲染到具体设备的屏幕上。

---

5.2 ArkTS：统一开发语言

5.2.1 为什么选择TypeScript作为基础

ArkTS基于TypeScript扩展，而非从零设计新语言。这个选择有几个原因：

（1）JavaScript/TypeScript生态庞大。全球有超过1700万JavaScript开发者，选择TypeScript意味着大量开发者不需要从零学习新语言，降低了迁移门槛。

（2）类型安全。TypeScript是JavaScript的超集，增加了静态类型系统。类型安全在大型项目开发中至关重要——它能在编译时发现大量错误，而非等到运行时才暴露。

（3）声明式UI的自然表达。ArkTS的声明式UI语法（装饰器 + build函数）与TypeScript的类和装饰器语法天然契合，表达简洁自然。

（4）编译优化。TypeScript的静态类型信息为编译器提供了充足的优化空间。ArkTS编译器可以在编译时进行类型检查、死代码消除、内联优化等，生成高效的机器码。

5.2.2 ArkTS对TypeScript的增强

ArkTS在TypeScript基础上增加了以下能力：

声明式UI装饰器：

@Component       // 标记这是一个UI组件
struct MyPage {
  @State count: number = 0   // 状态变量，变化时UI自动更新
  @Prop title: string        // 从父组件传入的属性
  
  build() {                  // 声明式UI描述
    Column() {
      Text(this.title)
        .fontSize(24)
      Text(`Count: ${this.count}`)
      Button('+1')
        .onClick(() => { this.count++ })
    }
  }
}

• @Component：将一个struct标记为UI组件
• @Entry：标记为应用的入口组件
• @State：标记组件的内部状态
• @Prop：标记从父组件传入的属性（单向同步）
• @Link：标记双向同步的状态
• @Provide / @Consume：跨组件层级的状态共享
• @Watch：监听状态变化并触发回调
• @StorageLink：与AppStorage中的状态双向绑定

并发编程模型：

ArkTS提供了TaskPool和Worker两种并发机制：

• TaskPool：轻量级的任务并发池，适合短时间的计算密集型任务。开发者将任务提交到TaskPool，系统自动管理线程的创建和销毁
• Worker：独立的线程，适合长时间运行的后台任务。Worker与主线程通过消息传递通信

// TaskPool示例
import taskPool from '@ohos.taskpool'

@Concurrent
function heavyComputation(input: number): number {
  // 耗时计算
  let result = 0
  for (let i = 0; i < input; i++) {
    result += Math.sqrt(i)
  }
  return result
}

// 在主线程中提交任务
async function runComputation() {
  let task = new taskPool.Task(heavyComputation, 1000000)
  let result = await taskPool.execute(task)
  console.log(`Result: ${result}`)
}

5.2.3 ArkTS对TypeScript的限制

ArkTS并非完全兼容TypeScript。为了保障运行时性能和安全性，它禁用了一些TypeScript特性：

禁用的特性	原因	替代方案
any 类型	削弱类型安全	使用具体类型或 unknown
eval()	动态执行不安全	使用静态代码
arguments	非标准的参数访问	使用剩余参数 ...args
for...in	遍历顺序不确定	使用 for...of 或 forEach
非类型化的导入	无法在编译时验证	使用具名导入
装饰器工厂函数	简化编译器实现	使用标准装饰器

这些限制看似减少了灵活性，但实际上：

• 大部分被禁用的特性本就不是最佳实践
• 限制使得编译器能做更激进的优化（如AOT编译）
• 降低了运行时出错的可能性

---

5.3 ArkUI：声明式UI框架

5.3.1 声明式 vs 命令式

传统的UI框架（如Android的View系统、iOS的UIKit）采用命令式（Imperative）编程模型：开发者通过代码一步步地创建UI元素、设置属性、添加到视图树中。

命令式的典型写法（伪代码）：

创建一个文本视图 text = new Text()
设置文本内容 text.setText("Hello")
设置字体大小 text.setFontSize(24)
添加到父视图 parent.addChild(text)

当数据变化时：
  text.setText(newText)   // 手动更新UI

声明式的写法（ArkTS）：

build() {
  Text("Hello")
    .fontSize(24)
}

当数据变化时：
  this.text = newText    // UI自动更新

声明式UI的核心优势在于数据驱动UI——开发者只需要描述"UI和数据之间的关系"，当数据变化时，UI自动更新。这大大减少了手动操作DOM的代码量，降低了状态管理出错的概率。

5.3.2 响应式布局系统

ArkUI的布局系统是"一次开发多端部署"的关键技术基础。

弹性布局（Flex）：

Column({ space: 10 }) {        // 垂直排列，间距10vp
  Row({ space: 20 }) {          // 水平排列
    Text('Left')
      .layoutWeight(1)          // 占据剩余空间的1份
    Text('Right')
      .layoutWeight(2)          // 占据剩余空间的2份
  }
  .width('100%')
  
  Text('Bottom')
    .width('100%')
}
.width('80%')
.padding(16)

关键布局概念：

• vp（虚拟像素）：ArkUI的长度单位，会根据屏幕密度自动缩放。在160dpi屏幕上1vp = 1px，在320dpi屏幕上1vp = 2px
• fp（字体像素）：专门用于字体大小的单位，支持用户设置的字体缩放偏好
• 百分比：相对于父容器的百分比（'80%'）
• layoutWeight：弹性权重，按比例分配剩余空间
• 断点（Breakpoint）：根据屏幕宽度划分的范围，用于在不同尺寸下应用不同的布局策略

断点系统：

// 系统默认断点
// sm: 屏幕宽度 < 600vp  → 手表、手机竖屏
// md: 600vp ≤ 宽度 < 840vp → 手机横屏、小平板
// lg: 840vp ≤ 宽度 < 1080vp → 平板
// xl: 屏幕宽度 ≥ 1080vp → 大平板、电视

@Component
struct AdaptiveLayout {
  build() {
    Column() {
      if (this.currentBreakpoint <= 'sm') {
        // 小屏幕布局：单列、简化UI
        this.SmallScreenLayout()
      } else if (this.currentBreakpoint <= 'md') {
        // 中等屏幕布局：双列
        this.MediumScreenLayout()
      } else {
        // 大屏幕布局：多列、完整功能
        this.LargeScreenLayout()
      }
    }
  }
}

5.3.3 组件体系

ArkUI提供了丰富的内置组件：

基础组件：

• Text：文本显示
• Button：按钮
• Image：图片显示
• TextInput：文本输入
• Slider：滑动条
• Toggle：开关

容器组件：

• Column/Row：线性布局
• Stack：层叠布局
• Flex：弹性布局
• Grid/GridItem：网格布局
• List/ListItem：列表布局
• Tabs/TabContent：标签页
• Scroll：滚动容器
• Swiper：轮播容器

对话框与弹窗：

• AlertDialog：警告对话框
• ActionSheet：操作列表
• Toast：轻提示
• Popup：气泡弹窗
• Panel：半模态面板
• Navigation：导航组件（路由管理）

媒体组件：

• Video：视频播放
• XComponent：嵌入式原生组件（用于渲染引擎、相机预览等）

---

5.4 Ability框架

5.4.1 Stage模型

开源鸿蒙当前推荐使用Stage模型（之前的FA模型已逐步废弃）。Stage模型的核心是UIAbility和ExtensionAbility。

UIAbility的生命周期：

Create → WindowStageCreate → Foreground ↔ Background → WindowStageDestroy → Destroy

状态	说明
Create	UIAbility实例创建，初始化资源
WindowStageCreate	窗口阶段创建，加载UI内容
Foreground	前台状态，可见且可交互
Background	后台状态，不可见但仍在运行
WindowStageDestroy	窗口阶段销毁，释放UI资源
Destroy	UIAbility实例销毁，释放所有资源

Stage模型的关键设计：

• 每个UIAbility拥有独立的进程（在支持多进程的设备上）。这意味着一个UIAbility崩溃不会影响应用中的其他UIAbility
• WindowStage管理UIAbility的窗口。一个UIAbility可以包含多个窗口（主窗口和子窗口）
• UIContext绑定UIAbility的生命周期。开发者通过UIContext获取与UIAbility相关的系统服务

5.4.2 多设备适配的Ability设计

在一次开发多端部署的场景下，Ability框架需要考虑：

不同设备可能有不同的Ability组合。例如，一个新闻应用：

• 手机/平板：UIAbility（展示新闻列表和详情）
• 手表：UIAbility（简化版新闻摘要）+ WorkSchedulerExtension（后台定时刷新）
• 电视：UIAbility（大屏版新闻，遥控器交互）
• IoT设备（智能音箱）：无UIAbility，只有ServiceAbility（语音播报新闻）

系统根据设备能力自动选择加载哪些Ability。开发者通过module.json5中的deviceTypes字段声明每个模块支持的设备类型：

{
  "module": {
    "name": "news",
    "type": "entry",
    "deviceTypes": ["phone", "tablet", "tv", "wearable"]
  }
}

---

5.5 设备适配策略

"一次开发多端部署"并不意味着完全不需要关心设备差异。开发者需要理解ArkUI提供的几种适配策略，合理使用。

5.5.1 资源限定适配

ArkUI支持按设备能力提供不同的资源文件：

resources/
├── base/                    ← 默认资源（所有设备）
│   ├── element/             ← 字符串资源
│   │   └── string.json
│   ├── media/               ← 图片资源
│   │   └── icon.png
│   └── profile/             ← 配置文件
│       └── main_pages.json
├── limited/                 ← 轻量级设备（LiteOS-M/A）
│   ├── media/
│   │   └── icon.png         ← 低分辨率图标
│   └── profile/
│       └── main_pages.json  ← 简化版页面配置
└── default/                 ← 标准设备（Linux内核）
    ├── media/
    │   └── icon.png         ← 高分辨率图标
    └── profile/
        └── main_pages.json  ← 完整版页面配置

系统会根据当前设备的资源能力（syscap，系统能力集），自动从对应目录加载资源。如果limited目录中缺少某个资源，系统会从base目录中查找。

5.5.2 响应式布局适配

对于屏幕尺寸差异，主要通过响应式布局解决：

• 使用vp和百分比而非绝对像素值
• 使用Flex、Grid等弹性布局容器
• 使用layoutWeight按比例分配空间
• 使用断点系统在不同尺寸下切换布局策略

5.5.3 功能适配

不同设备支持的功能不同（如手表没有摄像头、电视没有GPS），需要做功能级别的适配：

// 检查设备能力
import featureAbility from '@ohos.ability.featureAbility'

@Component
struct CameraFeature {
  hasCamera: boolean = false

  aboutToAppear() {
    // 查询当前设备是否支持摄像头
    this.hasCamera = canIUse('SystemCapability.Multimedia.Camera')
  }

  build() {
    Column() {
      if (this.hasCamera) {
        // 显示拍照功能
        Button('Take Photo')
          .onClick(() => { /* 拍照逻辑 */ })
      } else {
        // 显示替代方案
        Text('Camera not available on this device')
        Button('Select Photo')
          .onClick(() => { /* 从相册选择 */ })
      }
    }
  }
}

canIUse()是ArkUI提供的系统能力查询API，开发者可以在运行时检查设备是否支持某个功能，从而提供替代方案或隐藏不支持的特性。

5.5.4 交互方式适配

不同设备的交互方式不同：

设备	主要交互	辅助交互
手机	触摸（点击、滑动、长按）	语音
平板	触摸 + 手写笔	键盘鼠标
手表	触摸 + 旋钮	语音
电视	遥控器（方向键、确认键）	语音

ArkUI的组件默认支持多种交互方式。例如，一个Button组件：

• 触摸设备：支持点击
• 遥控器设备：支持方向键聚焦 + 确认键触发
• 语音设备：可以通过语义解析触发onClick回调

开发者不需要为每种交互方式编写额外的代码，ArkUI框架自动处理焦点管理和事件分发。但对于复杂交互场景，开发者也可以通过监听特定的输入事件（如遥控器的按键事件）来定制交互行为。

---

5.6 跨设备案例分析

为了具体说明"一次开发多端部署"的效果，我们来看一个简单的"天气应用"在不同设备上的呈现。

5.6.1 应用设计

业务功能：展示当前天气、未来3天预报、空气质量指数

设备覆盖：手机、平板、手表、电视

5.6.2 手机上的呈现

┌─────────────────────────┐
│  ☀️ 北京市               │
│  25°C 多云              │
│                         │
│  ── 未来3天 ──          │
│  明天  🌤  23~28°C       │
│  后天  ☁️  20~25°C       │
│  大后天 🌧  18~22°C      │
│                         │
│  空气质量：良 AQI 68     │
│  湿度：65%              │
│  风力：东南风3级          │
└─────────────────────────┘
竖屏，单列布局，完整信息

5.6.3 平板上的呈现

┌──────────────────────────────────┐
│  ☀️ 北京市    │  25°C  多云       │
│  湿度:65%    │  风力:东南风3级    │
│  AQI:68 良   │                   │
├──────────────┼───────────────────┤
│  明天 🌤      │  后天 ☁️           │
│  23~28°C    │  20~25°C          │
├──────────────┼───────────────────┤
│  大后天 🌧    │                   │
│  18~22°C    │                   │
└──────────────┴───────────────────┘
横屏或大屏，双列布局，信息密度更高

5.6.4 手表上的呈现

┌───────────┐
│  ☀️ 北京  │
│  25°C     │
│  多云     │
└───────────┘
小屏幕，只显示核心信息
无滚动，一屏看完

5.6.5 电视上的呈现

┌─────────────────────────────────────┐
│                                     │
│  ☀️ 北京市         25°C  多云        │
│                                     │
│  ┌─────┐  ┌─────┐  ┌─────┐        │
│  │明天  │  │后天  │  │大后天│        │
│  │🌤   │  │☁️   │  │🌧   │        │
│  │23~28│  │20~25│  │18~22│        │
│  └─────┘  └─────┘  └─────┘        │
│                                     │
│  空气质量: 良  AQI 68  湿度 65%    │
│                                     │
│  ◀  焦点在此处可用遥控器选择  ▶     │
└─────────────────────────────────────┘
大屏幕，三列布局，遥控器交互

5.6.6 实现要点

实现这个天气应用，开发者只需要：

1. 写一份ArkTS代码：使用响应式布局，通过断点系统切换不同的布局策略
2. 准备不同分辨率的资源图片：放在对应的资源目录中
3. 用canIUse()检查设备能力：如手表上隐藏"查看详情"按钮
4. 配置module.json5：声明支持哪些设备类型

不需要：

• ❌ 为每种设备写一个独立的应用
• ❌ 为每种屏幕尺寸写一套布局代码（断点系统自动处理）
• ❌ 为每种交互方式写事件处理代码（ArkUI自动适配）

---

5.7 与其他跨平台方案对比

"一次开发多端部署"并非开源鸿蒙独有。Flutter、React Native、.NET MAUI等框架也提供跨平台能力。以下是对比：

维度	Flutter	React Native	ArkUI（开源鸿蒙）
覆盖平台	Android/iOS/Web/Desktop	Android/iOS	OpenHarmony全设备谱系
开发语言	Dart	JavaScript/TypeScript	ArkTS（TypeScript扩展）
UI模型	声明式（Widget）	声明式（JSX）	声明式（ArkUI组件）
渲染方式	自绘引擎（Skia/Impeller）	原生组件映射	自绘引擎 + 原生组件
设备谱系	手机/平板/Desktop	手机/平板	MCU→手机全谱系
交互适配	触摸为主	触摸为主	触摸+旋钮+遥控器+语音
分布式能力	无	无	内建（跨设备协同）
性能	好（自绘引擎）	一般（JS Bridge）	好（AOT编译+自绘引擎）

ArkUI的独特优势：

• 设备谱系最广：从没有屏幕的IoT设备到电视大屏，而Flutter/React Native主要面向手机和平板
• 交互方式最全：原生支持触控、旋钮、遥控器、语音等多种交互方式
• 分布式能力内建：ArkUI应用天然可以使用分布式软总线、分布式数据管理等能力
• 与系统深度集成：ArkUI不是应用层的框架，而是系统级的UI框架，可以直接使用系统能力

---

5.8 本章小结

关键要点回顾：

1. "一次开发多端部署"通过三层抽象实现：开发者写业务逻辑+声明式UI → ArkUI框架自动适配设备 → 系统渲染到具体设备
2. ArkTS：基于TypeScript扩展，增强了声明式UI语法、状态管理、并发编程等能力，同时限制部分不安全特性
3. ArkUI声明式UI：数据驱动UI更新，响应式布局系统（vp/fp单位、断点系统、弹性布局），丰富的内置组件
4. Stage模型：UIAbility + ExtensionAbility，独立的进程管理和窗口管理，支持按设备类型加载不同的模块
5. 四种适配策略：资源限定适配、响应式布局适配、功能适配（canIUse）、交互方式适配
6. 与其他跨平台方案的差异：ArkUI的独特优势在于覆盖设备谱系最广、交互方式最全、分布式能力内建

下一章预告：第6章将深入开源鸿蒙的内核层，分析统一内核架构的设计与实现——LiteOS-M、LiteOS-A、Linux三种内核如何共存，KAL如何屏蔽差异。