一、鸿蒙版本演进历史

1.1 版本时间线

1.2 架构演进阶段

阶段一：兼容过渡期（HarmonyOS 1.0 - 4.3）

核心特征：混合内核架构（LiteOS + Linux），兼容 AOSP 安卓应用

┌─────────────────────────────────────────────┐
│           应用层                            │
│   ┌───────────────┐ ┌───────────────────┐  │
│   │  鸿蒙原生应用  │ │  安卓兼容层(APK)  │  │
│   └───────────────┘ └───────────────────┘  │
├─────────────────────────────────────────────┤
│           框架层                            │
│   ┌───────────────┐ ┌───────────────────┐  │
│   │   ArkUI框架   │ │   Android框架    │  │
│   └───────────────┘ └───────────────────┘  │
├─────────────────────────────────────────────┤
│           系统服务层                        │
│   ┌───────────────────────────────────────┐ │
│   │  分布式软总线 · 分布式数据管理 · AI框架 │ │
│   └───────────────────────────────────────┘ │
├─────────────────────────────────────────────┤
│           内核层（混合架构）                │
│   ┌───────────────┐ ┌───────────────────┐  │
│   │    LiteOS     │ │      Linux        │  │
│   └───────────────┘ └───────────────────┘  │
└─────────────────────────────────────────────┘

组件化能力：

• 基于 FA（Feature Ability）模型
• 支持 PageAbility、ServiceAbility、DataAbility
• HAR 静态共享包初步支持

阶段二：纯血鸿蒙期（HarmonyOS NEXT 5.0+）

核心特征：全栈自研，彻底脱离 Linux 内核和 AOSP，采用微内核架构

┌─────────────────────────────────────────────┐
│           应用层                            │
│   ┌───────────────┐ ┌───────────────────┐  │
│   │  鸿蒙原生应用  │ │   元服务(Meta)    │  │
│   │    (HAP格式)   │ │   (免安装服务)    │  │
│   └───────────────┘ └───────────────────┘  │
├─────────────────────────────────────────────┤
│           框架层                            │
│   ┌───────────────────────────────────────┐ │
│   │   ArkTS/ArkUI · Ability框架 · AI框架   │ │
│   └───────────────────────────────────────┘ │
├─────────────────────────────────────────────┤
│           系统服务层                        │
│   ┌───────────────────────────────────────┐ │
│   │ 星盾安全架构 · 分布式能力 · 方舟引擎   │ │
│   └───────────────────────────────────────┘ │
├─────────────────────────────────────────────┤
│           内核层（微内核架构）              │
│   ┌───────────────────────────────────────┐ │
│   │         鸿蒙微内核(HarmonyOS)          │ │
│   │    内核代码量仅约10KB，形式化验证      │ │
│   └───────────────────────────────────────┘ │
└─────────────────────────────────────────────┘

组件化能力：

• Stage 模型替代 FA 模型
• UIAbility + ExtensionAbility 能力体系
• HAR（静态共享包）+ HSP（动态共享包）双重支持
• 完善的插件化架构

1.3 关键技术里程碑

二、架构演进：从 FA 模型到 Stage 模型

2.1 核心差异对比

2.2 Stage 模型三大核心组件

// 1. UIAbility：主界面载体
export default class EntryAbility extends UIAbility {
  onCreate(want, launchParam) { /* 初始化 */ }
  onWindowStageCreate(windowStage) {
    windowStage.loadContent('pages/Index', (err, data) => {
      // 注入全局状态或初始化路由
    });
  }
}

// 2. ExtensionAbility：扩展能力容器（能力即插件）
// 支持 FormExtension（卡片）、ServiceExtension（后台服务）、InputMethodExtension（输入法）

// 3. AbilityStage：应用级生命周期
export default class MyAbilityStage extends AbilityStage {
  onAcceptWant(want) { return 'default'; } // 处理隐式启动
  onConfigurationUpdated(config) { /* 监听配置变化 */ }
}

三、模块形态：HAP/HAR/HSP 选型指南

3.1 三种包类型对比

3.2 决策流程图

需独立运行？ → 是 → 使用 HAP
               ↓ 否
需声明 Ability？ → 是 → 使用 HAP
                   ↓ 否
多模块复用？ → 否 → 使用 HAR
               ↓ 是
包体积敏感？ → 是 → 使用 HSP
               ↓ 否
               使用 HAR

四、组件化最佳实践

4.1 官方推荐三层架构

┌───────────────────────────────────────┐
│ 产品定制层（products）               │ ← 应用入口层，基于设备形态组合特性
│   └── Entry HAP / Feature HAP        │
├───────────────────────────────────────┤
│ 基础特性层（feature）                 │ ← 独立业务模块（登录、支付、搜索）
│   └── 高内聚，标准化接口向上提供服务   │
├───────────────────────────────────────┤
│ 公共能力层（common）                  │ ← 全局复用能力，通过 HAR 包跨工程复用
│   └── 网络请求、UI组件、工具类、数据存储 │
└───────────────────────────────────────┘

4.2 ArkUI 组件扩展装饰器

4.3 组件化设计原则

1. 低耦合高内聚：业务逻辑、公共能力、设备适配完全解耦
2. 接口标准化：通过 .d.ts 文件定义接口契约
3. 事件驱动通信：使用 Emitter 事件总线实现跨模块通信
4. 全局状态管理：借助 AppStorage 实现多模块数据同步

五、插件化最佳实践（基于 HSP）

5.1 HSP 核心特性

// HSP 模块配置（module.json5）
{
  "module": {
    "name": "agent-plugin-hsp",
    "type": "shared",           // 必填：声明为动态共享包
    "mainElement": "index",     // 必填：指定对外暴露的接口文件
    "deviceTypes": ["phone", "tablet", "car"]
  }
}

// HSP 资源访问方式
const hspCtx = createModuleContext('com.example.shared');
const icon = hspCtx.resourceManager.getMedia($r('app.media.icon'));

5.2 插件化架构设计

┌─────────────────────────────────────────┐
│            Entry HAP（主壳）            │
│   ┌───────────┐ ┌───────────┐          │
│   │  路由中心  │ │  状态管理  │          │
│   └─────┬─────┘ └─────┬─────┘          │
└─────────┼─────────────┼─────────────────┘
          │             │
┌─────────▼─────────────▼─────────────────┐
│           公共能力 HSP                    │
│   ┌───────────┐ ┌───────────┐          │
│   │ 网络请求库 │ │ 工具类库  │          │
│   └───────────┘ └───────────┘          │
└─────────────────────────────────────────┘
          │             │
┌─────────▼─────────────▼─────────────────┐
│           业务插件 HSP（按需加载）        │
│   ┌───────────┐ ┌───────────┐          │
│   │ 数据分析  │ │ 视频编辑  │ ...       │
│   └───────────┘ └───────────┘          │
└─────────────────────────────────────────┘

5.3 插件化核心价值

六、性能优化最佳实践

6.1 启动性能优化

问题：多 HAP/HSP 引用相同 HAR 包时，HAR 中的单例模式会失效，导致重复执行初始化代码。

优化方案：

6.2 包体积优化策略

1. 单个 HSP 建议 ≤ 500KB，过大需拆解
2. 动态加载阈值：仅在模块 > 100KB 时使用 HSP
3. 关联性强的工具类合并为单一 HSP（如 utils.hsp）
4. 通过 oh-package.json 区分必需模块与可选模块

七、避坑要点总结

7.1 常见问题

7.2 开发建议

1. 优先复用官方能力：充分利用系统提供的网络、安全、AI 等基础服务
2. 从中小型应用入手：先落地三层架构，积累经验后再向复杂应用扩展
3. 重视分布式适配：跨设备场景需提前封装分布式接口
4. 合理配置依赖：区分必需模块与可选模块

八、总结

核心观点

1. 架构选型：Stage 模型是鸿蒙 Next 的唯一选择，必须拥抱
2. 模块策略：功能隔离用 HAP，代码复用用 HSP，静态资源用 HAR
3. 设计原则：低耦合高内聚、接口契约先行、动态性内建
4. 性能平衡：根据业务需求在 App Size 与启动性能之间做好权衡

未来展望

随着鸿蒙生态的完善，架构还可进一步融入：

• AI 推理引擎
• 原子化服务（元服务）
• 跨设备分布式能力

建议开发者从中小型应用入手落地三层架构，积累实践经验后再向复杂应用扩展。