《HarmonyOS 7 Flutter 三方插件鸿蒙化开发手记》05:从本地能跑到真正可发布的 OHOS 插件【鸿蒙心迹】
example 能跑,就等于插件可以发布了吗?还差得远。

前四篇我们把插件从无到有搭起来了:
- 01:插件被 HarmonyOS 识别
- 02:Dart 和 ArkTS 通信
- 03:接入系统能力
- 04:生命周期和权限
现在 example 能跑了。但能不能发布给别人用?
差得远。example 能跑只是第一步,真正发布还要处理版本兼容、错误码、测试、文档这些事。
一、先想清楚:example 能跑和可发布差在哪
先把最基础的问题想明白。
| 对比 | example 能跑 | 可发布插件 |
|---|---|---|
| 版本 | 只测当前 SDK | 要兼容多个 SDK 版本 |
| 错误 | 能跑就行 | 错误码要清晰 |
| 测试 | 手动点一下 | 单元测试、真机验证 |
| 文档 | 没有 | README、示例 |
二、版本兼容为什么重要
插件依赖 HarmonyOS SDK 版本。用户用的 SDK 版本可能不一样。
| 版本 | 问题 |
|---|---|
| 插件写死 SDK 版本 | 低版本用户用不了 |
| 没有版本检查 | 高版本 API 在低版本崩了 |
| API 行为变化 | 升级后行为变了 |
HarmonyOS 7 对应 API 26。升级应用的时候,要评估 API 行为变化,在新旧设备上做兼容验证。
这段代码解决什么问题: 版本兼容检查。
文件: ohos/src/main/ets/PluginCompat.ets
用途: 版本兼容
接入位置: 插件初始化
import { deviceInfo } from '@kit.BasicServicesKit';
class PluginCompat {
static checkMinSdk(minApi: number): boolean {
let apiVersion = deviceInfo.sdkApiVersion;
return apiVersion >= minApi;
}
static getApiVersion(): number {
return deviceInfo.sdkApiVersion;
}
}
三、错误码为什么要对用户可读
example 里出错了,打个日志就行。发布给别人用,用户不知道为什么出错。
错误码要统一、要可读。Dart 层用户拿到错误码,知道发生了什么。
| 错误码 | 说明 |
|---|---|
| canceled | 用户取消 |
| not_found | 文件不存在 |
| permission_denied | 权限拒绝 |
| timeout | 超时 |
| unknown | 未知错误 |

四、发布前要做什么
发布前 Checklist:
- 插件目录结构规范;
- 错误码统一;
- 版本兼容检查;
- example 跑通;
- 单元测试;
- 真机验证;
- README 写清楚;
- API 26 升级验证。
五、几个容易踩的坑
第一个坑:example 能跑就直接发布。没做版本兼容,没做错误处理。
第二个坑:HarmonyOS SDK 版本写死。低版本用户用不了。
第三个坑:依赖版本无上限。新版本出问题,老用户也受影响。
第四个坑:API 行为变化没有兼容保护。升级后行为变了。
第五个坑:错误码对 Dart 用户不可读。用户不知道为什么出错。
第六个坑:没有测试 Engine 重建和异常生命周期。线上出问题。
第七个坑:README 只写 Android/iOS。HarmonyOS 用户不知道怎么用。

这次做工程收口最大的体会是:能跑的 Demo 和可发布的插件,差了一整个工程化过程。
真正做的时候,最容易忽略的不是怎么写功能,而是怎么管好版本、错误、测试、文档。这些东西 example 里不用管,发布的时候全得补上。
更多推荐


所有评论(0)