鸿蒙造物者之路 11 · 出师
续写章节｜沿用「造物者」系列的武侠讲解体，面向电子信息 / 嵌入式方向的新手
=================前情提要===============
从 SHT30 的 I2C 时序，穿过 HDF 驱动、NAPI 桥梁，一路跑到 ArkTS 界面上——26.5°C 这个数字，我等了整整十章。
"下一章，"老陈说，“把你的东西，变成别人能装、能用的产品。”
HAP 包、签名、元服务、上架。最后这一公里。
========================================
这一章你会得到什么
🎯 学完这一章，你应该能：
- ☐ 分清 HAP / HAR / HSP 三种包，知道什么时候用哪个
- ☐ 搞懂签名四件套（.p12 / .csr / .cer / .p7b）都是什么、谁生成
- ☐ 走通上架流程，知道被拒的八大原因
- ☐ 理解元服务是什么，什么样的功能适合做成元服务
- ☐ 对生态现状和就业方向有自己的判断（书里给你判断方法，不给你画饼）
**🧰 需要准备：**一个能跑的项目 + 华为开发者帐号。
**⏱ 预计用时：**约 3 小时
📊 难度：★★☆☆☆ 流程性的东西，照做就行
一、先搞清楚：你编译出来的到底是什么
"你每次点运行，DevEco 生成的那个文件是什么？"老陈问。
“……一个 HAP？”
"对，但只对了一半。"老陈打开构建产物目录：
entry/build/default/outputs/
├── default/
│ ├── entry-default-unsigned.hap ← 未签名
│ └── entry-default-signed.hap ← 已签名（调试签名）
└── ...
“HAP，Harmony Ability Package，鸿蒙应用的基本安装单元。”
他在白板上写了三个词：
HAP —— 能装的（应用包）
HAR —— 编译时用的（静态库）
HSP —— 运行时用的（动态共享包）
1.1 HAP：能装进设备的那个
“**HAP 是可以被安装、被运行的模块包。**一个应用可以有一个或多个 HAP。”
MyApp.app（上架用的总包，App Pack）
├── entry.hap ← 【必装】主模块，应用的入口
├── camera.hap ← 【可选】相机功能模块
├── settings.hap ← 【可选】设置模块
└── wearable.hap ← 【可选】手表模块
| HAP 类型 | 说明 | 数量 |
|---|---|---|
| entry | 主模块，必须有一个，应用入口 | 1 个 |
| feature | 功能模块，可以按需下载 | 0~N 个 |
“为什么要拆成多个 HAP？”
"为了按需下载。"老陈说，“你的应用有 200 MB，但用户只用其中三个功能——没必要让他全下。feature HAP 可以在用户用到的时候再下载。”
1.2 HAR：静态共享包
“HAR（Harmony Archive）是编译期的共享包，类似于 Android 的 AAR。”
┌─────────────────────────────────────────┐
│ HAR（静态共享包） │
├─────────────────────────────────────────┤
│ · 包含 ArkTS 代码、C++ 代码、资源、配置 │
│ · 编译时【复制】进每个引用它的 HAP │
│ · 多个 HAP 都引用 → 每个 HAP 里都有一份 │
│ · 结果：包体变大，但运行时无依赖 │
└─────────────────────────────────────────┘
// entry/oh-package.json5
{
"name": "entry",
"version": "1.0.0",
"dependencies": {
"@ohos/my-utils": "file:../libs/myutils", // ← 引用本地 HAR
"@ohos/network": "^1.2.0" // ← 引用三方库
}
}
“什么时候用 HAR？”
“**当你想把代码分享给别人、或者做成公共库的时候。**比如你写了一个通用的网络请求封装，打包成 HAR，其他项目直接引用。”
1.3 HSP：动态共享包
“HSP（Harmony Shared Package）是运行时的共享包。”
┌─────────────────────────────────────────┐
│ HSP（动态共享包） │
├─────────────────────────────────────────┤
│ · 编译时【不复制】，运行时共享 │
│ · 多个 HAP 引用同一份 → 只有一份 │
│ · 结果：包体更小，但依赖运行时环境 │
│ · 支持动态加载 │
└─────────────────────────────────────────┘
1.4 一张表决定用哪个
| 维度 | HAR | HSP |
|---|---|---|
| 打包方式 | 编译期复制进 HAP | 运行时共享 |
| 包体大小 | 多处引用 → 变大 | 多处引用 → 变小 |
| 独立性 | 独立，不依赖别的包 | 依赖宿主 |
| 动态加载 | ❌ 不支持 | ✅ 支持 |
| 适用场景 | 发布到仓库给外部用 | 同一个应用内部多模块共享 |
| 上手难度 | 简单 | 稍复杂 |
“口诀：对外分享用 HAR，内部复用用 HSP。”
二、元服务：不用安装的"轻应用"
“鸿蒙有个很特别的东西——元服务（以前叫原子化服务）。”
2.1 它是什么
┌──────────────────────────────────────────┐
│ 传统应用 vs 元服务 │
├──────────────────────────────────────────┤
│ 传统应用： 要下载、要安装、有图标、占空间 │
│ 元服务： 【免安装】、无桌面图标、即点即用 │
│ 通过卡片/扫码/负一屏/智慧搜索进入 │
└──────────────────────────────────────────┘
“**用户体验是这样的：**他在负一屏看到一张’快递到了’的卡片，点开就能看物流详情——全程没有安装任何东西。”
2.2 硬限制
“元服务有严格的大小限制，这是为了保证’秒开’：”
| 项目 | 限制 |
|---|---|
| 单个 HAP 大小 | 一般 ≤ 2 MB（部分场景放宽到 10 MB） |
| 总包大小 | 受严格管控 |
| 权限 | 可用权限范围更窄 |
| 后台能力 | 受限更多 |
| 入口 | 卡片、扫码、分享、负一屏、智慧搜索、小艺建议 |
"2 MB 意味着什么？"老陈说，“意味着你不能塞大图、不能塞大库、不能做复杂功能。元服务的定位是’高频刚需、用完即走’。”
2.3 什么时候做元服务
| 场景 | 建议 |
|---|---|
| 点外卖、查快递、看天气、扫码骑车 | ✅ 非常适合 |
| 完整的大型 App（社交、游戏、编辑器） | ❌ 不适合，做传统应用 |
| 给硬件设备做配套控制面板 | ✅ 很适合（你的场景） |
"你的温湿度监控，做成元服务就很合适。"老陈说，“用户扫一下设备上的二维码，直接弹出控制卡片，不用装 App。”
2.4 卡片：元服务的主要形态
“**服务卡片是元服务最重要的载体。**第 07 章提过 FormExtensionAbility，现在看它怎么工作：”
┌──────────────────────────────────────┐
│ 桌面上的卡片（2x2） │
│ ┌────────────────┐ │
│ │ 客厅 26.5°C │ ← 卡片 UI │
│ │ 湿度 61% │ │
│ └────────────────┘ │
└──────────────────────────────────────┘
↕ 数据更新
┌──────────────────────────────────────┐
│ FormExtensionAbility │
│ · onAddForm() 卡片被添加 │
│ · onUpdateForm() 定时更新 │
│ · onRemoveForm() 卡片被删除 │
└──────────────────────────────────────┘
↕ 主动刷新
┌──────────────────────────────────────┐
│ 应用侧：formProvider.updateForm() │
└──────────────────────────────────────┘
// 卡片提供方
import FormExtensionAbility from '@ohos.app.form.FormExtensionAbility';
import formBindingData from '@ohos.app.form.formBindingData';
import formProvider from '@ohos.app.form.formProvider';
export default class SensorFormAbility extends FormExtensionAbility {
// 卡片被添加到桌面
onAddForm(want: Want): formBindingData.FormBindingData {
let data = {
'temp': '--',
'humi': '--',
'device': '客厅'
};
return formBindingData.createFormBindingData(data);
}
// 定时更新（周期由配置决定，最短 30 分钟）
onUpdateForm(formId: string): void {
let data = { 'temp': '26.5', 'humi': '61' };
formProvider.updateForm(formId, formBindingData.createFormBindingData(data));
}
onRemoveForm(formId: string): void {
// 清理
}
}
// module.json5 里声明
{
"extensionAbilities": [
{
"name": "SensorFormAbility",
"srcEntry": "./ets/form/SensorFormAbility.ets",
"type": "form", // ← 卡片类型
"metadata": [
{
"name": "ohos.extension.form",
"resource": "$profile:form_config"
}
]
}
]
}
三、签名：最烦但必须过的一关
“现在讲最让人头疼的：签名。”
3.1 为什么必须签名
“签名做两件事：”
1. 【身份证明】证明这个应用确实是"你"开发的，不是别人冒充的
2. 【完整性】证明应用从你打包之后，没有被任何人篡改过
"没签名的 HAP 装不进真机。"老陈说，“模拟器可以跑未签名的，但真机一律拒绝。”
3.2 四样东西
“鸿蒙的签名涉及四个文件，我给你列清楚：”
| 文件 | 后缀 | 是什么 | 谁生成 |
|---|---|---|---|
| 密钥库 | .p12 |
存着你的私钥 | DevEco Studio 生成 |
| 证书请求 | .csr |
用私钥生成的申请文件 | DevEco Studio 生成 |
| 数字证书 | .cer |
华为（AGC）颁发，证明你是你 | AGC 下载 |
| Profile 文件 | .p7b |
华为颁发，描述你的应用能干什么（包名、权限、设备） | AGC 下载 |
完整流程：
DevEco Studio AGC（AppGallery Connect）
──────────────── ────────────────────────
1. 生成 .p12 密钥库
│
2. 生成 .csr 证书请求
│
└──────── 上传 .csr ──────► 3. 颁发 .cer 证书
│
◄──────── 下载 .cer ───────────────┘
│
4. 在 AGC 创建项目/应用
│
└────── 申请 Profile ──────► 5. 生成 .p7b
│
◄──────── 下载 .p7b ───────────────┘
│
6. 在 DevEco 里配置签名信息
│
7. 编译 → 签名 → 得到 signed.hap
3.3 自动签名（新手走这条）
“DevEco Studio 有自动签名，能帮你省掉 90% 的麻烦。”
File → Project Structure → Signing Configs
→ 勾选 "Automatically generate signature"
→ 登录华为帐号
→ 等待自动生成 .p12 / .cer / .p7b
→ Apply → OK
"自动签名适合调试。"老陈说，“但有几件事它做不了——”
| 限制 | 说明 |
|---|---|
| 设备数量 | 调试 profile 只能绑定有限台设备（一般 100 台） |
| 有效期 | 调试证书有期限，过期要重新签 |
| 上架 | 发布必须用正式的发布证书，不能用调试证书 |
3.4 手动配置
// build-profile.json5
{
"app": {
"signingConfigs": [
{
"name": "default",
"type": "HarmonyOS",
"material": {
"storePassword": "************************",
"certpath": "C:/Users/xxx/.ohos/config/default_xxx.cer",
"keyAlias": "debugKey",
"keyPassword": "************************",
"profile": "C:/Users/xxx/.ohos/config/default_xxx.p7b",
"signAlg": "SHA256withECDSA",
"storeFile": "C:/Users/xxx/.ohos/config/default_xxx.p12"
}
}
],
"products": [
{
"name": "default",
"signingConfig": "default", // ← 引用上面的配置
"compatibleSdkVersion": "5.0.x",
"runtimeOS": "HarmonyOS"
}
]
}
}
"注意：真实项目里不要把密码写进配置文件提交到仓库。"老陈提醒。
3.5 签名的常见坑
| 现象 | 原因 | 解法 |
|---|---|---|
| 真机装不上 | 用的未签名包 | 用 signed.hap |
| 装上了闪退 | 签名与 profile 不匹配 | 重新生成全套签名 |
| “设备不在 profile 白名单” | 调试 profile 没包含这台设备 | 在 AGC 添加设备 UDID |
| 证书过期 | 调试证书有期限 | 重新申请 |
| 跨设备分布式调试失败 | 两端应用签名不一致 | 确保两台设备装的包用同一套签名 ← 第09章提过 |
| 上架被拒 | 用了调试证书 | 换发布证书 |
四、上架：最后一步
“签名搞定，就可以上架了。”
4.1 流程
1. 【AGC 创建应用】
AppGallery Connect → 我的应用 → 新建
填：应用名称、包名、分类、语言、适用设备
2. 【准备素材】
· 应用图标（多个尺寸）
· 应用截图（至少 3 张，不同尺寸）
· 应用描述（中文 + 英文）
· 隐私政策链接（必须有！）
· 版权证明 / 软著（部分分类需要）
3. 【上传包】
Build → Generate HAP/APP → 生成 .app（App Pack）
在 AGC 上传
4. 【填信息】
· 应用分级（年龄分级）
· 定价（免费 / 付费）
· 上架区域
· 内容分级问卷
5. 【提交审核】
一般 1~3 个工作日
6. 【上架】
审核通过后，用户就能搜到了
4.2 被拒的常见原因
“这些坑，提前避开能省一周：”
| 原因 | 说明 |
|---|---|
| 没有隐私政策 | 涉及用户信息的应用必须提供 |
| 权限滥用 | 申请了用不到的权限，或者申请了高敏感权限没说明理由 |
| 崩溃 / ANR | 审核会跑自动化测试 |
| 功能不完整 | 明显的 bug、死链、占位内容 |
| 侵犯知识产权 | 用了别人的图标、名字、内容 |
| 后台行为不当 | 滥用后台任务、常驻通知 |
| 元服务不合规 | 元服务塞了太多功能，或者包体超限 |
| 描述与实际不符 | 描述的功能 App 里没有 |
“最常踩的是’权限滥用’。“老陈说，”**你申请了位置权限，但审核找不到你在哪儿用了——直接拒。**所以申请权限之前，先问自己：真的需要吗？”
五、HarmonyOS NEXT：现在的生态到底怎么样
"老师，我有个问题一直想问。"我举手。
“说。”
“现在学鸿蒙，到底值不值？”
老陈沉默了两秒，然后笑了。
“这是所有新手都会问的问题。我给你讲清楚。”
5.1 NEXT 意味着什么
“HarmonyOS NEXT（现在的 HarmonyOS 5）把 AOSP 全删了，不兼容 APK。”
“这件事有两面：”
【风险面】
· 所有应用要重写 → 生态初期应用少
· 用户可能因为"缺少某个 App"而不换机
· 开发者的旧代码资产要迁移
【机会面】
· 应用缺口 = 开发岗位缺口
· 早期开发者享受红利（流量扶持、政策补贴）
· 技术栈新鲜，大家起跑线接近
· 国家层面推自主操作系统，长期有保障
5.2 真实数据（给你一个判断框架）
“我不给你画饼，我给你自己判断的方法：”
第一步：看主流应用有没有原生版
→ 微信、支付宝、抖音、淘宝、高德、京东...
→ 你自己手机上看一眼，这些有没有鸿蒙原生版
第二步：看招聘
→ 去招聘网站搜"鸿蒙"、"OpenHarmony"、"ArkTS"
→ 看岗位数量、薪资范围、城市分布
第三步：看你的目标行业
→ 消费电子 / 智能家居 / 车载 / 工业控制 → 强相关
→ 纯互联网 Web / 后端 → 弱相关
"别听别人说，自己去查。"老陈说，“这是我给所有学生的建议。”
5.3 我的判断
“作为干这行十几年的人，我的判断是——”
"三条：
1. 纯做北向应用（只会写 ArkTS 界面）→ 竞争激烈，红利期短
原因：培训班三个月能批量产出，门槛低
2. 纯做南向驱动（只会 C + 驱动）→ 稳定，但岗位总量有限
原因：这是传统嵌入式岗，本来就有，鸿蒙只是加成
3. 【南 + 北 都会】→ 稀缺，红利期长
原因：需要两套知识体系，培训班教不了
企业要的是"能一个人扛一个产品"的人
他看着我：“你走的是第三条。”
六、就业方向和学习路线
6.1 岗位方向
| 方向 | 干什么 | 要求 | 适合谁 |
|---|---|---|---|
| 鸿蒙应用开发 | 写 ArkTS 界面和业务逻辑 | ArkTS + ArkUI + Stage 模型 | 有编程基础，偏软件 |
| 鸿蒙系统开发 | 改系统、移植、适配 | C/C++ + Linux + 编译构建 | 有 Linux 基础 |
| 南向驱动开发 | 写 HDF 驱动、适配外设 | C + 硬件 + 数据手册 | 电子/嵌入式背景（你的优势） |
| 鸿蒙设备开发 | 整机开发、产品化 | 上面都要会一点 | 综合型 |
| 元服务 / 卡片开发 | 轻量化服务 | ArkTS + 卡片框架 | 偏产品思维 |
6.2 给你的一条学习路线
老陈在白板上写：
【阶段一：打地基】（1~2 个月）
· C 语言（指针、结构体、内存）—— 你已经有了
· Linux 基础命令 + Shell
· 至少点亮一块开发板的灯（OpenHarmony 轻量系统）
目标：能让板子跑起来、能看串口日志
【阶段二：南向深入】（2~3 个月）
· LiteOS-M 任务 / IPC / 中断
· GPIO / I2C / SPI / UART / PWM / ADC
· HDF 驱动框架 + HCS 配置
· 编译构建（GN / Ninja / hb）
目标：能独立完成一个"采集 + 上传"的小项目
【阶段三：北向入门】（1~2 个月）
· ArkTS 语法 + 静态类型思维
· ArkUI 声明式 + 状态管理
· Stage 模型 + 路由 + 生命周期
· 数据持久化 + 网络 + 权限
目标：能做一个完整的 App
【阶段四：打通】（1~2 个月）
· NAPI（ArkTS ↔ C）
· 分布式软总线 / 跨端迁移 / 分布式数据
· 卡片 / 元服务
目标：能做一个软硬结合的完整产品
【阶段五：出师】
· 做一个能放进简历的项目
· 走完签名 + 上架流程
· 参与开源（OpenHarmony 是开源的，可以提 PR）
"最重要的建议——"老陈放下笔。
“什么？”
"每一阶段都要做出一个能演示的东西。"他说，“别只看书。看十本书不如做一个项目。”
“简历上写’熟悉鸿蒙开发’，没人信；写’我做了一个温湿度监控系统，从驱动到 App 全是我写的，已经上架了’——这就是另一回事了。”
=================小剧场模式=================
我：老师，最后一个问题。
老陈：说。
我：如果鸿蒙没做起来怎么办？ 我花这么多时间，是不是赌错了？
老陈：（沉默两秒）这个问题问得好，而且你该问。
我：……我是不是说错话了？
老陈：没有。盲目下注才蠢。 我给你算一笔账——
我：怎么算？
老陈：你学这些的过程中，你真正学到的东西是什么？
我：（想）C 语言、嵌入式、驱动、RTOS、Linux、编译构建、UI 框架、网络、数据库、分布式……
老陈：这些里面，有哪一样是只有鸿蒙才用得上的？
我：……几乎没有。
老陈：对。 嵌入式、C、驱动、RTOS、Linux——这些在任何 IoT 公司、任何芯片公司、任何硬件公司都用得上。ArkTS 和声明式 UI 也是——学会了它，再学 SwiftUI、Jetpack Compose、Flutter 都很快。
我：所以就算鸿蒙没起来……
老陈：你学到的东西一件都没浪费。 只是少了一个"平台红利"。
我：那我还是赚的。
老陈：你一直都是赚的。 学东西这件事，最坏的结果也只是"多了一种思维方式"。
========================================
七、出师清单
老陈在白板上留了最后一张表：
【包结构】
HAP 能装的（entry 主模块 + feature 功能模块）
HAR 编译期复制（对外分享）
HSP 运行时共享（内部复用）
.app 上架用的总包
【元服务】
免安装、卡片入口、包体 ≤ 2MB（一般）
适合：高频刚需、用完即走、硬件配套面板
【签名四件套】
.p12 密钥库（本地生成）
.csr 证书请求（本地生成）
.cer 数字证书（AGC 颁发）
.p7b Profile（AGC 颁发，描述权限和设备）
调试用自动签名；上架必须用发布证书
【上架】
AGC 创建应用 → 准备素材（图标/截图/隐私政策）
→ 上传 .app → 填信息 → 提交审核（1~3 天）
被拒高发：无隐私政策、权限滥用、崩溃、功能不完整
【方向选择】
纯北向 → 门槛低，竞争大
纯南向 → 稳定，岗位有限
【南北双修】→ 稀缺，红利长 ← 你走这条
【铁律】
每个阶段都要做出一个能演示的东西
简历上写"做了什么"，别写"学了什么"
"这张表，"老陈说，“是你从’学生’变成’开发者’的通行证。”
"明天，"他收拾东西，“我们做最后一件东西。”
“什么东西？”
老陈把那块 Hi3861、一颗 SHT30、一个继电器模块、还有那个小舵机，一股脑推到我面前。
“把你最开始跟我说的那个想法，做出来。”
我愣了一下，然后想起来了——第一次见面那天，他说过：
“三个设备，三个厂家，三种协议，三个 App。”
"一个系统，让它们说同一种语言。"老陈说。
本章自检
过一遍下面的问题。答不上来的，回去翻对应小节——那些就是你这个章的欠账。
- ☐ HAP / HAR / HSP 的区别？对外分享用哪个，内部复用用哪个？
- ☐ 签名的四个文件分别是什么？哪两个是华为颁发的？
- ☐ 调试签名和发布签名的区别？上架能用调试签名吗？
- ☐ 元服务的包体限制大概是多少？什么样的功能适合做元服务？
- ☐ 上架被拒最高发的原因是什么？
- ☐ 说出你的方向定位：纯北向 / 纯南向 / 南北双修？
**➡️ 下一站：**第 12 章 · 造物者（大结局）—— 把前面所有东西串起来，做出成品。
=================剧情片段=================
导演：卡。第十一章，出师。
助理：包结构、元服务、签名、上架、生态、就业路线——这一章是"从技术到产品"。
导演：对。 前面十章教他"怎么做东西"，这一章教他"怎么把东西交付出去"。
助理：我还挺喜欢那段"如果鸿蒙没起来怎么办"的。
导演：那是真话。 学技术的最大风险不是"学错了"，是"只学不用"。只要他真的做出东西来，学到的能力是可迁移的。
助理：最后一章了。
导演：大结局。 一个完整的收尾项目——
助理：宿舍智能改造？
导演：对。用鸿蒙重做他最开始的那个想法。 从驱动、到 NAPI、到 ArkTS 界面、到分布式、到卡片，全部串起来。
助理：师傅要走吗？
导演：要走。 但留点东西。
助理：留什么？
导演：一本手册。 还有一句话。
========================================
未完待续。。。