阅读视图

发现新文章,点击刷新页面。

鸿蒙 RNOH 下 DocumentPicker copyTo 失败:一个错误码,三个独立根因

从相册选图调 DocumentPicker.pick({ copyTo: 'documentDirectory' }),拿到的 fileCopyUri 永远是 nullcopyError13900002 No such file or directory。看起来是个简单的路径问题,实际拆开后发现是三个独立 bug 叠在一起。

问题

业务代码很标准:

const [picked] = await DocumentPicker.pick({
  type: [DocumentPicker.types.images],
  copyTo: 'documentDirectory',
});
// 期望: picked.fileCopyUri 是沙箱内可上传路径

HarmonyOS 6.1.0 (API 23) 模拟器从相册选图,拿到的结果:

{
  "fileCopyUri": null,
  "copyError": "13900002 No such file or directory",
  "uri": "file://media/Photo/1/IMG_...",
  "type": "image/png"
}

fileCopyUri 为空,copyError 是 13900002。后台日志显示请求根本没发出去——前端在文件拷贝阶段就失败了。

更诡异的是,用 RNFS.copyFile(picked.uri, sandboxPath) 做兜底也失败,报错路径从 picker 移到了 RNFS,表面看像 RNFS 的问题。

复现

HarmonyOS 6.1.0 (API 23) 模拟器:

输入 表现
从系统相册选图 fileCopyUri: null,copyError 13900002
从文件管理器选含中文名的 PDF fileCopyUri: null,copyError 13900002
从文件管理器选纯 ASCII 文件名 PDF 正常

报错码都是 13900002,但根因不止一个。

鸿蒙下 file:// 的三种形态

在排查之前,先理解一个背景知识。跨端开发者通常把 file:// 理解为"file:// + 一个 POSIX 绝对路径",但鸿蒙下 file:// 实际承载了三种不同语义:

类型 示例 说明
沙箱路径 file:///data/storage/.../img.jpg 应用私有目录,读写自由
媒体库 URI file://media/Photo/1/IMG_... 系统相册,只读临时授权
用户目录 URI file://docs/storage/... 用户文件管理器选中的文件

本文涉及前两种。picker 从相册拿到的是媒体库 URI(只读),需要拷贝到沙箱(可读写)才能给业务侧用。问题就出在这个拷贝过程。

根因一:用 'r+' 打开只读的相册文件

原始代码:

async function copyFile(source: string, dest: string): Promise<void> {
  let inputStream = fs.createStreamSync(source, 'r+');  // ← 读写模式打开
  let outputStream = fs.createStreamSync(dest, 'w+');
  // ...
}

@ohos.file.fs.createStreamSync 的 mode 遵循 POSIX:'r+' 要求文件可读可写。但相册媒体库 URI 在应用层只持有临时只读授权,用 'r+' 打开直接报 13900002

这就是相册选图必坏的原因——不是路径问题,是打开模式不对。

修复:改成 'r'

let inputStream = fs.createStreamSync(source, 'r');  // 只读打开

根因二:文件名直接拼接导致路径异常

原始代码:

const destFilePath = `${destUUIdDir}/${sourceUri.name ?? new Date().getTime()}`;

两个边界问题:

  1. sourceUri.name 可能是 undefined:部分媒体库 URI 解析不出文件名,fallback 成 Date.now()——丢扩展名,业务侧 mime.getType(ext) 失效
  2. 含中文 / Emoji / 特殊字符的文件名createStreamSync(destFilePath, ...) 创建目标文件时会失败,报错码同样是 13900002,和根因一撞符号,光看错误码无法区分

修复:用固定前缀 + 原始扩展名,避开用户输入的文件名:

private getSafeCopyFileName(sourceUri: fileuri.FileUri): string {
  const name = sourceUri.name ?? String(new Date().getTime());
  const dotIndex = name.lastIndexOf('.');
  const ext = dotIndex >= 0 ? name.substring(dotIndex) : '';
  return `picked${ext || ''}`;
}

不管原始文件名是中文、Emoji 还是 200 个字符,目标文件名都是 picked.pngpicked.pdf 这样的安全格式。扩展名保留,业务侧 MIME 判断不受影响。

根因三:result.uri 被改写,丢失了 picker 的临时授权

原始代码:

result = {
  uri: fUri.path,  // ← 沙箱物理绝对路径,例如 /data/.../IMG_xxx.jpg
  type: fileMimeType,
  name: filename,
  size: fileSize,
  fileCopyUri: null,
};

copyTo 因根因一或根因二失败时,业务侧通常会兜底:

await RNFS.copyFile(picked.uri, sandboxDest);

picked.uri 已经被改写成了 fUri.path(物理绝对路径),没有原始授权。RNFS 这次拷贝同样会挂,且报错路径从 picker 移到了 RNFS——表面看像 RNFS 的问题,实际是 picker 把授权链截断了。

修复:保留原始 picker URI:

result = {
  uri: uri,  // ← 改回原始 picker uri(保留临时授权)
  // ...
};

同时把原始 URI 透传进 copyFileToLocalStorage,作为复制源的候选之一。

综合修复:多源回退

把三个根因的修复整合后,copyFile 改成了双源回退:

async function copyFile(originalUri: string, sourcePath: string, dest: string): Promise<void> {
  const sources = [originalUri, sourcePath].filter(
    (value, index, list) => value && list.indexOf(value) === index,
  );
  let lastErr;
  for (const source of sources) {
    try {
      await copyFileStream(source, dest);
      return;
    } catch (err) {
      lastErr = err;
    }
  }
  throw lastErr ?? new Error('copyFile failed');
}

originalUri(如 file://media/...)走媒体库授权,sourcePath(如 /data/...)走绝对路径,任一可用即成功。配合 'r' 模式打开,相册图也能正常拷贝。

改动与根因对应关系

根因 改动 效果
'r+' 打开只读文件 copyFileStream'r' 相册图直接拷贝成功
文件名拼接异常 getSafeCopyFileNamepicked + 扩展名 中文 / Emoji / 长名都安全;MIME 判断不受影响
fUri.path 丢授权 result.uri = uri RNFS 兜底链路有原始 URI 可用
综合鲁棒性 copyFile 双源回退 原始 URI 和物理路径任一可用即成功

业务侧配套

patch 解决了 picker 内部的拷贝,但业务侧还有一层兜底(utils/ensureUploadablePath.ts),基于 result.uri 保留原始 picker URI 实现三级回退:

  1. 优先用 fileCopyUri(picker 拷贝成功时直接可用)
  2. 兜底用 RNFS.copyFile(picker.uri, sandboxPath)(依赖原始 URI 的临时授权)
  3. 最终兜底用 RNFS.readFile + writeFile base64(纯数据拷贝,不依赖 URI 授权)

如果 result.uri 还是被改写成 fUri.path,第二级兜底就废了,只剩 base64 兜底——能用但性能差。

经验

  1. 鸿蒙的 file:// 不是 POSIX 的 /——媒体库 URI、用户目录 URI、沙箱路径三者权限模型完全不同,不能当同一个东西用
  2. 同一个错误码可能有多个根因——13900002 既可能是打开模式不对,也可能是文件名非法,光看错误码无法区分,需要结合场景判断
  3. picker 返回的 URI 本身就是资源——它携带了临时授权,覆盖成物理路径等于丢掉了这个资源,下游所有依赖授权的操作都会失败
  4. 文件名不要直接用用户输入——中文、Emoji、超长名都是定时炸弹,UUID + 扩展名是最安全的选择

将 libsmb2 集成到 HarmonyOS ArkTS 项目

将 libsmb2 集成到 HarmonyOS ArkTS 项目

本文记录在鸿蒙媒体播放器项目 hmplayer 中集成 libsmb2 实现 SMB 网络文件浏览与播放的完整过程。libsmb2支持smb3协议。能够查看macos上的文件夹分享。配置macos分享的时候需要把选项中的window共享创建一个账号和密码。之后使用使用此账号密码进行连接。

整体架构

ArkTS 层 (Smb2Client.ets)
    ↓ NAPI 绑定 (libentry.so)
C/C++ 层 (napi_init.cpp)
    ↓ 静态链接
libsmb2 (thirdparty/libsmb2/arm64-v8a/lib/libsmb2.so.1)

ArkTS 通过 NAPI 调用 C++ 导出的函数,C++ 层直接调用 libsmb2 的 C API。整个模块编译为 libentry.so,在应用加载时自动注册。

第一步:放置预编译库

libsmb2 不需要在项目中从源码编译,直接放置预编译好的 arm64-v8a 架构的 .so 文件:

entry/src/main/cpp/thirdparty/libsmb2/arm64-v8a/
├── include/smb2/
│   ├── libsmb2.h
│   ├── smb2.h
│   ├── smb2-errors.h
│   ├── libsmb2-raw.h
│   └── libsmb2-dcerpc*.h
├── lib/
│   ├── libsmb2.so.6.1.0
│   ├── libsmb2.so.1 -> libsmb2.so.6.1.0
│   ├── libsmb2.so -> libsmb2.so.1
│   └── cmake/libsmb2/
└── lib/pkgconfig/

第二步:配置 CMake

entry/src/main/cpp/CMakeLists.txt 中添加:

cmake_minimum_required(VERSION 3.4.1)
project(libsmb2project)

# 应用主库,包含 NAPI 绑定
add_library(entry SHARED napi_init.cpp)

# 链接 NAPI 运行时和日志库
target_link_libraries(entry PUBLIC libace_napi.z.so libhilog_ndk.z.so)

# 引入 libsmb2 预编译库
set(LIBSMB2_DIR ${CMAKE_CURRENT_SOURCE_DIR}/thirdparty/libsmb2/${OHOS_ARCH})
set(LIBSMB2_LIB ${LIBSMB2_DIR}/lib/libsmb2.so.1)

target_link_libraries(entry PRIVATE ${LIBSMB2_LIB})
target_include_directories(entry PRIVATE ${LIBSMB2_DIR}/include)

${OHOS_ARCH} 由 DevEco Studio 构建时自动注入,值为 arm64-v8a

第三步:配置 ABI 过滤

entry/build-profile.json5 中指定只构建 arm64-v8a

{
  externalNativeOptions: {
    path: './src/main/cpp/CMakeLists.txt',
    abiFilters: ['arm64-v8a'],
    arguments: '',
    cppFlags: '',
  },
}

第四步:编写 NAPI 绑定

entry/src/main/cpp/napi_init.cpp 是核心绑定文件,将 libsmb2 的 C API 暴露给 ArkTS。

模块注册

#include <napi/native_api.h>

static napi_module entryModule = {
    .nm_version = 1,
    .nm_flags = 0,
    .nm_filename = nullptr,
    .nm_register_func = RegisterEntryModule,   // 你的注册函数
    .nm_modname = "entry",
    .nm_priv = nullptr,
    .reserved = {0},
};

extern "C" __attribute__((constructor)) void RegisterEntryModule(void)
{
    napi_module_register(&entryModule);
}

__attribute__((constructor)) 保证共享库加载时自动执行注册。

全局状态管理

Native 层使用全局变量维护单一连接:

static smb2_context* g_smb2_ctx = nullptr;
static smb2dir*      g_smb2_dir = nullptr;
static smb2fh*       g_smb2_fh  = nullptr;

同一时间只允许一个 SMB 连接,打开新文件时自动关闭旧的文件句柄。

导出函数示例

每个 NAPI 函数都是 libsmb2 C API 的薄封装,负责 napi_value 与 C 类型之间的转换:

// 初始化上下文
static napi_value InitContext(napi_env env, napi_callback_info info)
{
    // ...
    g_smb2_ctx = smb2_init_context();
    if (!g_smb2_ctx) {
        napi_create_int32(env, -1, &result);
        return result;
    }
    napi_create_int32(env, 0, &result);
    return result;
}

// 连接共享
static napi_value ConnectShare(napi_env env, napi_callback_info info)
{
    size_t argc = 4;
    napi_value args[4];
    napi_get_cb_info(env, info, &argc, args, nullptr, nullptr);

    char server[256], share[256], user[256], password[256];
    // ... 从 napi_value 提取字符串

    int ret = smb2_connect_share(g_smb2_ctx, server, share, user, password);
    // ...
}

// 读取文件(随机访问)
static napi_value ReadFile(napi_env env, napi_callback_info info)
{
    size_t argc = 2;
    napi_value args[2];
    napi_get_cb_info(env, info, &argc, args, nullptr, nullptr);

    int64_t offset, size;
    // ... 提取参数

    uint8_t* buf = new uint8_t[size];
    int n = smb2_pread(g_smb2_ctx, g_smb2_fh, buf, size, offset);

    // 将数据拷贝到 ArrayBuffer 返回给 ArkTS
    void* data;
    napi_create_arraybuffer(env, n, &data, &ab);
    memcpy(data, buf, n);
    delete[] buf;
    return ab;
}

所有导出函数在 RegisterEntryModule 中统一注册:

static napi_value RegisterEntryModule(napi_env env, napi_value exports)
{
    napi_property_descriptor desc[] = {
        { "initContext",        nullptr, InitContext,        nullptr, nullptr, nullptr, napi_default, nullptr },
        { "destroyContext",     nullptr, DestroyContext,     nullptr, nullptr, nullptr, napi_default, nullptr },
        { "setUser",            nullptr, SetUser,            nullptr, nullptr, nullptr, napi_default, nullptr },
        { "setPassword",        nullptr, SetPassword,        nullptr, nullptr, nullptr, napi_default, nullptr },
        { "setDomain",          nullptr, SetDomain,          nullptr, nullptr, nullptr, napi_default, nullptr },
        { "setAuthentication",  nullptr, SetAuthentication,  nullptr, nullptr, nullptr, napi_default, nullptr },
        { "connectShare",       nullptr, ConnectShare,       nullptr, nullptr, nullptr, napi_default, nullptr },
        { "disconnectShare",    nullptr, DisconnectShare,    nullptr, nullptr, nullptr, napi_default, nullptr },
        { "openDir",            nullptr, OpenDir,            nullptr, nullptr, nullptr, napi_default, nullptr },
        { "closeDir",           nullptr, CloseDir,           nullptr, nullptr, nullptr, napi_default, nullptr },
        { "readDir",            nullptr, ReadDir,            nullptr, nullptr, nullptr, napi_default, nullptr },
        { "getError",           nullptr, GetError,           nullptr, nullptr, nullptr, napi_default, nullptr },
        { "openFile",           nullptr, OpenFile,           nullptr, nullptr, nullptr, napi_default, nullptr },
        { "closeFile",          nullptr, CloseFile,          nullptr, nullptr, nullptr, napi_default, nullptr },
        { "getFileSize",        nullptr, GetFileSize,        nullptr, nullptr, nullptr, napi_default, nullptr },
        { "readFile",           nullptr, ReadFile,           nullptr, nullptr, nullptr, napi_default, nullptr },
    };
    napi_define_properties(env, exports, sizeof(desc) / sizeof(desc[0]), desc);
    return exports;
}

第五步:声明 TypeScript 类型

entry/src/main/cpp/types/libentry/index.d.ts 中声明类型,让 ArkTS 能获得完整的类型提示:

export interface Smb2DirEntry {
  name: string
  type: number
  isDirectory: boolean
}

export const SMB2_SEC_UNDEFINED: number
export const SMB2_SEC_NTLMSSP: number
export const SMB2_SEC_KRB5: number

export function initContext(): number
export function destroyContext(): number
export function setUser(user: string): number
export function setPassword(password: string): number
export function setDomain(domain: string): number
export function setAuthentication(method: number): number
export function connectShare(
  server: string,
  share: string,
  user: string,
  password: string
): number
export function disconnectShare(): number
export function openDir(path: string): number
export function closeDir(): number
export function readDir(): Smb2DirEntry[]
export function getError(): string
export function openFile(path: string): number
export function closeFile(): number
export function getFileSize(): number
export function readFile(offset: number, size: number): ArrayBuffer

对应的 oh-package.json5

{
  name: 'libentry.so',
  types: './index.d.ts',
  version: '1.0.0',
}

第六步:ArkTS 封装层

在 ArkTS 侧通过 import libentry from 'libentry.so' 导入原生模块,封装为易用的类。

Smb2Client

import libentry from 'libentry.so'

export class Smb2Client {
  private connected: boolean = false

  init(): number {
    return libentry.initContext()
  }

  destroy(): number {
    this.connected = false
    return libentry.destroyContext()
  }

  setUser(user: string): number {
    return libentry.setUser(user)
  }

  setPassword(password: string): number {
    return libentry.setPassword(password)
  }

  setDomain(domain: string): number {
    return libentry.setDomain(domain)
  }

  setAuthentication(method: number): number {
    return libentry.setAuthentication(method)
  }

  connect(
    server: string,
    share: string,
    user: string,
    password: string
  ): number {
    const ret = libentry.connectShare(server, share, user, password)
    if (ret === 0) {
      this.connected = true
    }
    return ret
  }

  disconnect(): number {
    this.connected = false
    return libentry.disconnectShare()
  }

  openDir(path: string): number {
    return libentry.openDir(path)
  }

  closeDir(): number {
    return libentry.closeDir()
  }

  readDir(): libentry.Smb2DirEntry[] {
    return libentry.readDir()
  }

  getError(): string {
    return libentry.getError()
  }

  openFile(path: string): number {
    return libentry.openFile(path)
  }

  closeFile(): number {
    return libentry.closeFile()
  }

  getFileSize(): number {
    return libentry.getFileSize()
  }

  readFile(offset: number, size: number): ArrayBuffer {
    return libentry.readFile(offset, size)
  }
}

SmbFileCache(文件缓存下载)

SMB 文件不能直接作为视频播放器的数据源,需要先下载到本地缓存。SmbFileCache 通过分块读取 + 并发写入实现高效下载:

export class SmbFileCache {
  private client: Smb2Client
  private readonly CHUNK_SIZE = 4 * 1024 * 1024 // 4MB

  async download(
    remotePath: string,
    localPath: string,
    onProgress?: (progress: number, speed: string) => void
  ): Promise<string> {
    // 1. 打开远程文件
    this.client.openFile(remotePath)
    const totalSize = this.client.getFileSize()

    // 2. 分块读取,通过 ConcurrentFileDownloader 写入本地文件
    let downloaded = 0
    let startTime = Date.now()

    while (downloaded < totalSize) {
      const chunkSize = Math.min(this.CHUNK_SIZE, totalSize - downloaded)
      const data = this.client.readFile(downloaded, chunkSize)

      // 并发写入磁盘(不阻塞主线程)
      await ConcurrentFileDownloader.writeChunk(localPath, downloaded, data)

      downloaded += chunkSize

      // 回调进度
      if (onProgress) {
        const elapsed = (Date.now() - startTime) / 1000
        const speed = downloaded / elapsed / 1024
        onProgress(downloaded / totalSize, `${speed.toFixed(1)} KB/s`)
      }
    }

    // 3. 关闭文件句柄
    this.client.closeFile()
    return localPath
  }
}

第七步:UI 层集成

SmbEntry 类型

目录条目类型与 NAPI 声明一致:

interface SmbEntry {
  name: string
  type: number
  isDirectory: boolean
}

连接流程

pageSmbBrowser.ets 中,页面组件的生命周期管理 SMB 连接:

@Entry
@Component
struct PageSmbBrowser {
  @State client: Smb2Client = new Smb2Client();
  @State entries: SmbEntry[] = [];
  @State currentPath: string = '/';
  @State downloadProgress: number = 0;
  @State downloadSpeed: string = '';
  @State isDownloading: boolean = false;

  aboutToAppear() {
    this.client.init();
    this.client.setUser('admin');
    this.client.setPassword('123456');
    this.client.setDomain('WORKGROUP');

    const ret = this.client.connect('192.168.1.100', 'Public', 'admin', '123456');
    if (ret === 0) {
      this.loadDirectory('/');
    }
  }

  aboutToDisappear() {
    this.client.disconnect();
    this.client.destroy();
  }

  loadDirectory(path: string) {
    const ret = this.client.openDir(path);
    if (ret === 0) {
      const raw = this.client.readDir();
      // 过滤 . 和 ..,目录优先排序
      this.entries = raw
        .filter(e => e.name !== '.' && e.name !== '..')
        .sort((a, b) => {
          if (a.isDirectory && !b.isDirectory) return -1;
          if (!a.isDirectory && b.isDirectory) return 1;
          return a.name.localeCompare(b.name);
        });
      this.client.closeDir();
    }
  }
}

文件操作

// 点击目录:进入子目录
onDirClick(entry: SmbEntry) {
  const newPath = this.currentPath === '/' ? `/${entry.name}` : `${this.currentPath}/${entry.name}`;
  this.currentPath = newPath;
  this.loadDirectory(newPath);
}

// 点击媒体文件:下载到缓存后播放
onMediaClick(entry: SmbEntry) {
  const remotePath = this.currentPath === '/' ? `/${entry.name}` : `${this.currentPath}/${entry.name}`;
  const localPath = `/data/storage/el2/base/cache/smb/${entry.name}`;

  this.isDownloading = true;
  const cache = new SmbFileCache(this.client);
  cache.download(remotePath, localPath, (progress, speed) => {
    this.downloadProgress = progress;
    this.downloadSpeed = speed;
  }).then((path) => {
    // 播放本地缓存文件(调用导航跳转到播放器页面)
    this.isDownloading = false;
    // pushPath({ name: PageName.videoPlayer, param: { uri: path } });
  });
}

// 返回上级目录
onBack() {
  if (this.currentPath === '/') return;
  const parts = this.currentPath.split('/').filter(p => p.length > 0);
  parts.pop();
  this.currentPath = parts.length > 0 ? '/' + parts.join('/') : '/';
  this.loadDirectory(this.currentPath);
}

API 列表

集成的 16 个 NAPI 函数覆盖了 SMB 文件浏览与读取的完整流程:

函数 对应 libsmb2 API 说明
initContext() smb2_init_context() 创建 SMB 上下文
destroyContext() smb2_destroy_context() 销毁上下文
setUser(user) smb2_set_user() 设置用户名
setPassword(password) smb2_set_password() 设置密码
setDomain(domain) smb2_set_domain() 设置域名
setAuthentication(method) smb2_set_authentication() 认证方式(0=自动, 1=NTLM, 2=Kerberos)
connectShare(server, share, user, password) smb2_connect_share() 连接 SMB 共享
disconnectShare() smb2_disconnect_share() 断开连接
openDir(path) smb2_opendir() 打开远程目录
closeDir() smb2_closedir() 关闭目录句柄
readDir() smb2_readdir() 循环至 NULL 读取全部目录条目
getError() smb2_get_error() 获取最近一次错误信息
openFile(path) smb2_open(path, O_RDONLY) 打开文件(只读)
closeFile() smb2_close() 关闭文件句柄
getFileSize() smb2_fstat() 获取文件大小
readFile(offset, size) smb2_pread() 按偏移量读取指定字节,返回 ArrayBuffer

关键注意事项

  1. 单一连接限制:Native 层使用全局变量 g_smb2_ctxg_smb2_dirg_smb2_fh,同一时间只能维持一个 SMB 连接、一个目录句柄、一个文件句柄。对于单页面浏览场景足够,如需并发连接需重构为句柄池模式。

  2. 只读文件访问openFile 固定使用 O_RDONLY 标志,不支持写操作。

  3. 同步 API:绑定只使用了 libsmb2 的同步接口(smb2_connect_sharesmb2_pread 等),未接入 libsmb2 的异步事件循环(smb2_get_fd/smb2_service)。在鸿蒙的 TaskPool 中执行可避免阻塞 UI 主线程。

  4. 权限声明:在 module.json5 中需要声明 ohos.permission.INTERNETohos.permission.GET_NETWORK_INFO

  5. ABI 支持:当前仅构建 arm64-v8a。如需支持 armeabi-v7ax86_64,需交叉编译对应架构的 libsmb2 并添加到 abiFilters 中。

参考文档

参考文档:参考文档

HarmonyOS AbilityStage 实战:别把启动参数散落在每个页面里

鸿蒙应用做到后面,真正让人头疼的,往往不是某个页面写得丑,也不是某个按钮样式没调好,而是入口越来越多以后,启动逻辑开始乱。

桌面图标能进来,服务卡片能进来,通知能进来,Deep Link 能进来,应用内部还可能用 Want 拉起另一个 UIAbility。第一版代码一般都挺朴素:在首页 aboutToAppear 里读一下参数,判断要不要跳详情页。刚开始没问题,甚至看起来挺清爽。

但需求一多,首页就很容易变成“入口垃圾桶”。

这里判断通知来源,那里判断服务卡片参数,后面又补一个外部链接解析。冷启动的时候还能凑合,二次拉起、回前台、横竖屏切换、任务栈恢复一来,问题就开始变得有点玄学了。

我之前见过一个挺典型的线上问题:用户从服务卡片点进来,本来应该打开某个订单详情页,结果偶尔落到首页;用户从外部链接再次拉起应用,页面没刷新;还有更隐蔽的,应用已经在后台了,新的 Want 进来以后,全局初始化又跑了一遍,监听注册了两次,后面同一个事件回调两遍。

查日志的时候也挺难受。每个页面都觉得自己只是“顺手处理一下入口参数”,最后谁也说不清这次启动到底是桌面启动、卡片启动,还是二次拉起。

这种问题不能靠再加几个 if 硬顶。Stage 模型下,AbilityStage、Want、UIAbility 这条链路本来就应该承担启动治理的职责。只是很多项目写着写着,把它们当成了“系统自动生成的模板文件”,真正的业务入口反而全塞到页面里了。

image.png

AbilityStage / Want / UIAbility,别分开看

单独看这几个概念,其实都不复杂。

AbilityStage 是 Module 级别的组件管理器,HAP 首次加载时会创建它。UIAbility 是带界面的应用组件,负责创建、销毁、前后台切换这些生命周期。Want 是组件之间传递信息的载体,启动目标、参数、action、uri 这些东西都可以从里面拿。

但工程里真正容易出问题的地方,不是“某个回调怎么写”,而是边界没划清。

我一般会这么分:

  • AbilityStage 管进程级、模块级的东西,比如轻量初始化、Specified 启动模式分流、全局依赖准备。
  • Want 只当入口信息,进来以后尽快转成业务能理解的结构。
  • UIAbility 管窗口、生命周期和启动载荷注入。
  • ArkUI 页面只消费归一后的业务参数,不直接解析原始 Want。

这几条边界看着有点啰嗦,但真到项目里很有用。

后面新增通知入口、服务卡片入口、Deep Link 入口时,不需要每个页面跟着改。入口逻辑集中在入口层,页面只关心“我要展示什么业务状态”。这才比较像一个能长期维护的结构。

先把原始 Want 收敛成 LaunchPayload

很多启动混乱,根源就是页面直接读 Want。

页面一旦开始知道太多入口细节,就会慢慢变成半个路由中心。今天读 scene,明天读 from,后天再补一个 uri,最后首页里一堆参数判断,谁也不敢动。

我更习惯定义一个中间结构,叫 LaunchPayload。它不追求把 Want 的所有字段都复刻一遍,只留下业务真正需要的东西。

// common/launch/LaunchPayload.ets
export enum LaunchScene {
  NORMAL = 'normal',
  CARD = 'card',
  NOTIFICATION = 'notification',
  DEEP_LINK = 'deep_link',
  INTERNAL = 'internal'
}

export interface LaunchPayload {
  scene: LaunchScene
  targetPage: string
  bizId?: string
  uri?: string
  from?: string
  rawAction?: string
  extras: Record<string, string>
  receivedAt: number
}

这里有个小取舍:extras 我只放字符串。

不是说 Want 里不能带别的类型,而是启动参数最好别变成一个“万能对象”。入口传来的东西越杂,页面兜底越麻烦。真要复杂对象,建议传 id,再让业务层去查详情。

启动参数要负责的是“把用户带到哪”,不是“把整个业务现场都搬进来”。这句话挺重要,很多入口混乱都是从这里开始的。

写一个 Want 解析器,别让页面自己猜

下面这个 LaunchPayloadParser 就是专门干脏活的。

它负责把不同来源的 Want 参数,统一整理成业务可读的结构。页面拿到的不是一坨原始参数,而是一份已经归一过的启动载荷。

// common/launch/LaunchPayloadParser.ets
import { Want } from '@kit.AbilityKit'
import { LaunchPayload, LaunchScene } from './LaunchPayload'

export class LaunchPayloadParser {
  static parse(want: Want | undefined): LaunchPayload {
    const params = want?.parameters ?? {}
    const uri = want?.uri ?? ''
    const action = want?.action ?? ''

    const scene = this.parseScene(params, uri, action)
    const bizId = this.readString(params, 'bizId')
    const from = this.readString(params, 'from')

    return {
      scene,
      targetPage: this.resolveTargetPage(scene, bizId, uri),
      bizId,
      uri,
      from,
      rawAction: action,
      extras: this.pickSafeExtras(params),
      receivedAt: Date.now()
    }
  }

  private static parseScene(params: Record<string, Object>, uri: string, action: string): LaunchScene {
    const scene = this.readString(params, 'scene')

    if (scene === 'card') {
      return LaunchScene.CARD
    }

    if (scene === 'notification') {
      return LaunchScene.NOTIFICATION
    }

    if (uri.length > 0) {
      return LaunchScene.DEEP_LINK
    }

    if (action.length > 0) {
      return LaunchScene.INTERNAL
    }

    return LaunchScene.NORMAL
  }

  private static resolveTargetPage(scene: LaunchScene, bizId?: string, uri?: string): string {
    if (scene === LaunchScene.DEEP_LINK && uri) {
      return this.resolveDeepLink(uri)
    }

    if (bizId && bizId.length > 0) {
      return 'pages/Detail'
    }

    return 'pages/Home'
  }

  private static resolveDeepLink(uri: string): string {
    // 这里只做简单示例。
    // 真实项目里建议做白名单解析,别让外部 uri 任意指定页面路径。
    if (uri.includes('/detail')) {
      return 'pages/Detail'
    }

    if (uri.includes('/search')) {
      return 'pages/Search'
    }

    return 'pages/Home'
  }

  private static pickSafeExtras(params: Record<string, Object>): Record<string, string> {
    const allowList: string[] = ['tab', 'keyword', 'source']
    const extras: Record<string, string> = {}

    allowList.forEach((key: string) => {
      const value = this.readString(params, key)
      if (value !== undefined) {
        extras[key] = value
      }
    })

    return extras
  }

  private static readString(params: Record<string, Object>, key: string): string | undefined {
    const value = params[key]
    return typeof value === 'string' ? value : undefined
  }
}

这段代码看起来确实有点啰嗦,但它救命的地方也就在这。

所有入口先过一层白名单,不允许外部参数直接控制内部页面路径;所有参数先转成可控结构,不让页面到处写 want.parameters?.xxx。项目越大,这种“看起来多一层”的代码越值钱。

我自己比较怕那种“先凑合一下”的入口代码。因为入口一旦散了,后面不是不好重构,是没人敢重构。用户从哪里进来、带了什么参数、应该落到哪个页面,全都藏在几个页面生命周期里,查一次问题能把人查麻。

AbilityStage:只做进程级初始化和启动分流

AbilityStage 很容易被误用。

有些项目会把一堆业务初始化都丢进去:数据库、网络、埋点、用户信息、远程配置,全塞上。冷启动一慢,大家又开始怀疑系统回调慢,或者怀疑首屏性能不行。其实很多时候,是自己把太重的东西放错地方了。

我的建议比较保守:AbilityStage 只做轻量、必要、进程级的事情。

比如日志初始化、依赖容器准备、Specified 启动模式的 key 分流。需要 IO、需要用户态、需要网络的初始化,不要一股脑压在这里。

// entry/src/main/ets/entryability/MyAbilityStage.ets
import { AbilityStage, Want } from '@kit.AbilityKit'
import { hilog } from '@kit.PerformanceAnalysisKit'
import { LaunchPayloadParser } from '../common/launch/LaunchPayloadParser'

export default class MyAbilityStage extends AbilityStage {
  onCreate(): void {
    // 这里适合做轻量级、进程级准备。
    // 不建议在这里做耗时网络请求,也别依赖页面上下文。
    hilog.info(0x0000, 'AppStage', 'AbilityStage onCreate')
  }

  onAcceptWant(want: Want): string {
    // Specified 启动模式下,系统会通过这个 key 决定复用哪个 UIAbility 实例。
    // key 设计要稳定,不要把时间戳这种随机值塞进去。
    const payload = LaunchPayloadParser.parse(want)

    if (payload.bizId && payload.bizId.length > 0) {
      return `detail_${payload.bizId}`
    }

    return 'main'
  }
}

onAcceptWant 这块很容易写错。

我见过有人为了“保证每次都是新的”,直接返回时间戳。短期看,好像解决了页面不刷新的问题;长期看,其实是把实例复用搞乱了。

Specified 模式要的不是“每次都新开”,而是“同一类业务复用同一个目标实例”。key 的粒度要跟业务场景一致。比如详情页按 id 分流,主入口统一回到 main。别为了省事,把 key 写成一个随机数,那后面任务栈和实例管理都会跟着乱。

UIAbility:冷启动和二次拉起要走同一套逻辑

UIAbility 的生命周期更贴近业务。

用户冷启动时会走 onCreate,窗口创建时走 onWindowStageCreate;应用已有实例再次被拉起时,常见场景会走 onNewWant。如果只在 onCreate 里处理参数,二次拉起就很容易漏。

我一般会在 UIAbility 里保留一个当前启动载荷,然后用 LocalStorage 注入页面。页面不直接碰 Want。

// entry/src/main/ets/entryability/EntryAbility.ets
import { AbilityConstant, UIAbility, Want } from '@kit.AbilityKit'
import { window } from '@kit.ArkUI'
import { hilog } from '@kit.PerformanceAnalysisKit'
import { LaunchPayload } from '../common/launch/LaunchPayload'
import { LaunchPayloadParser } from '../common/launch/LaunchPayloadParser'

export default class EntryAbility extends UIAbility {
  private storage: LocalStorage = new LocalStorage()
  private latestPayload?: LaunchPayload

  onCreate(want: Want, launchParam: AbilityConstant.LaunchParam): void {
    this.latestPayload = LaunchPayloadParser.parse(want)
    this.storage.setOrCreate('launchPayload', this.latestPayload)

    hilog.info(0x0000, 'EntryAbility',
      `onCreate scene=${this.latestPayload.scene}, target=${this.latestPayload.targetPage}`)
  }

  onWindowStageCreate(windowStage: window.WindowStage): void {
    // 页面首次加载时,把归一后的启动载荷注入进去。
    windowStage.loadContent('pages/Home', this.storage, (err) => {
      if (err.code) {
        hilog.error(0x0000, 'EntryAbility',
          `loadContent failed, code=${err.code}, message=${err.message}`)
        return
      }

      hilog.info(0x0000, 'EntryAbility', 'loadContent success')
    })
  }

  onNewWant(want: Want, launchParam: AbilityConstant.LaunchParam): void {
    // 已有实例被再次拉起时,不要重复跑全局初始化。
    // 这里只更新启动载荷,让页面或路由层消费。
    this.latestPayload = LaunchPayloadParser.parse(want)
    this.storage.setOrCreate('launchPayload', this.latestPayload)

    hilog.info(0x0000, 'EntryAbility',
      `onNewWant scene=${this.latestPayload.scene}, target=${this.latestPayload.targetPage}`)
  }

  onForeground(): void {
    // 恢复轻量资源,例如刷新当前会话状态。
    // 不建议在这里重复解析启动参数。
    hilog.info(0x0000, 'EntryAbility', 'onForeground')
  }

  onBackground(): void {
    // 暂停耗时任务、保存必要状态。
    hilog.info(0x0000, 'EntryAbility', 'onBackground')
  }

  onDestroy(): void {
    // 取消监听、释放 UIAbility 级资源。
    hilog.info(0x0000, 'EntryAbility', 'onDestroy')
  }
}

这段的重点不是 loadContent,而是 onCreateonNewWant 共用同一个解析器。

冷启动和二次拉起不应该分裂成两套业务规则。你今天忘了在 onNewWant 补一个参数,明天就会遇到那种特别烦的现象:应用杀掉后正常,后台唤起异常;从桌面进来正常,从通知进来异常。

这类问题通常不好测,因为测试同学一旦把应用杀掉重进,问题就消失了。

页面只消费 LaunchPayload,不碰原始 Want

页面里可以用 @LocalStorageProp 拿到启动载荷。至于它来自桌面、卡片还是 Deep Link,页面不需要知道太多。

// entry/src/main/ets/pages/Home.ets
import { LaunchPayload, LaunchScene } from '../common/launch/LaunchPayload'

@Entry
@Component
struct Home {
  @LocalStorageProp('launchPayload') launchPayload?: LaunchPayload

  @State tip: string = '正常进入首页'

  aboutToAppear(): void {
    this.consumeLaunchPayload(this.launchPayload)
  }

  onPageShow(): void {
    // 从后台回到前台时,页面可做轻量刷新。
    // 不建议在这里重新猜测启动来源。
  }

  private consumeLaunchPayload(payload?: LaunchPayload): void {
    if (!payload) {
      return
    }

    if (payload.scene === LaunchScene.CARD) {
      this.tip = `从服务卡片进入,业务ID:${payload.bizId ?? '无'}`
      return
    }

    if (payload.scene === LaunchScene.DEEP_LINK) {
      this.tip = `从外部链接进入:${payload.uri ?? ''}`
      return
    }

    if (payload.bizId) {
      this.tip = `准备打开详情:${payload.bizId}`
      return
    }

    this.tip = '正常进入首页'
  }

  build() {
    Column({ space: 16 }) {
      Text('HarmonyOS 启动治理示例')
        .fontSize(22)
        .fontWeight(FontWeight.Bold)

      Text(this.tip)
        .fontSize(15)
        .fontColor('#666666')

      if (this.launchPayload?.targetPage === 'pages/Detail') {
        Button('进入详情')
          .onClick(() => {
            // 项目里可以交给统一 RouterService,
            // 不建议在每个页面散落路由拼接。
          })
      }
    }
    .padding(24)
    .width('100%')
  }
}

这里有个问题经常有人问:为什么不在 UIAbility 里直接路由到详情页?

可以,但要看项目的路由方案。

如果你的登录态、弹窗恢复、页面栈管理、Tab 状态都在页面层或者 RouterService 里,UIAbility 直接跳详情页,有时候反而会绕过业务状态。我的做法是,UIAbility 负责把“启动意图”送到页面,真正的业务路由交给应用内部的 RouterService。

这样页面栈归页面,入口归入口,边界比较清楚。后面要改路由策略,也不用去生命周期回调里翻一堆代码。

生命周期不是背回调顺序,而是定职责

UIAbility 启动到前台时,会触发 onCreate()onWindowStageCreate()onForeground() 这一类生命周期回调。文档顺序看懂不难,难的是每个回调里该放什么、不该放什么。

image.png

我通常按下面这个口径拆:

onCreate:读取 Want,生成 LaunchPayload,准备 UIAbility 级状态。别在这里直接操作还没创建的窗口。

onWindowStageCreate:加载页面,注入 LocalStorage,绑定窗口相关逻辑。窗口级别的东西放这里,不要提前。

onNewWant:已有实例再次被拉起时更新启动意图。这里不要重复初始化全局服务,也不要重复注册监听。

onForeground:应用回到前台,恢复轻量资源,比如刷新会话、恢复播放按钮状态。不要把它当第二个 onCreate

onBackground:暂停耗时任务,保存必要状态。能停的就停,尤其是轮询、定位、长连接这类逻辑。

onDestroy:取消监听、释放资源、打点收尾。不要假设它每次都一定按你期望的时机触发,但该写的清理还是要写。

职责分清以后,很多“偶发问题”就不再玄学了。

比如二次拉起没刷新,就去看 onNewWant;前后台切换重复初始化,就查 onForeground;窗口相关状态异常,就去看 onWindowStageCreate。至少排查方向是明确的,不至于在首页、详情页、路由工具类之间来回翻。

常见坑位:这些地方真的容易埋雷

1. 首页承担了太多入口职责

首页读 Want、首页解析 URI、首页判断通知、首页处理卡片参数,短期确实快,长期基本一定乱。首页是 UI,不是入口网关。

这个坑很多项目都会踩,因为第一版最方便的地方就是首页。但方便不是没有代价,只是代价晚点来。

2. onNewWant 忘了处理

这类 bug 很烦:冷启动正常,后台再次拉起异常;杀掉应用再试,又正常了。

原因往往是只在 onCreate 解析了 Want,已有实例二次拉起时没有更新业务载荷。开发自测时如果习惯每次都杀进程,很容易漏掉。

3. Specified key 设计太随意

onAcceptWant 返回的 key 应该稳定、有业务含义。

随机 key 会让实例复用不可控;key 粒度太粗,会导致不同业务入口抢同一个实例。这个地方别偷懒,最好一开始就按业务场景定规则。

4. 外部参数直接控制页面路径

Deep Link 或外部 Want 里带一个 path,然后你直接 router 到对应页面,这个写法很危险。

至少要做白名单映射。外部参数只能表达意图,不能拿到内部路由的完全控制权。尤其是对外开放的链接入口,更不能相信传进来的每一个字段。

5. 前后台切换重复初始化

onForeground 不是重启。

回前台时做轻量恢复可以,别把登录初始化、数据库初始化、全局监听注册再跑一遍。重复初始化这种问题前期不明显,后面会变成重复请求、重复回调、状态错乱。

6. 页面销毁后,异步回调还在改状态

启动之后经常伴随异步动作,比如查详情、拉配置、校验登录。页面销毁后回调还更新状态,就会出现偶现闪跳或者日志报错。

建议给异步任务加 taskId,或者在页面消失时取消。别让旧任务回来覆盖新页面。

稳定性优化:给启动链路加一个任务号

如果启动入口多,建议给每次 LaunchPayload 分配一个自增序号。后到的启动意图优先级更高,旧任务回来不能覆盖新状态。

这个设计不复杂,但很管用。

// common/launch/LaunchSession.ets
import { LaunchPayload } from './LaunchPayload'

export class LaunchSession {
  private currentSeq: number = 0
  private latest?: LaunchPayload

  next(payload: LaunchPayload): number {
    this.currentSeq += 1
    this.latest = payload
    return this.currentSeq
  }

  isLatest(seq: number): boolean {
    return seq === this.currentSeq
  }

  getLatest(): LaunchPayload | undefined {
    return this.latest
  }
}

页面或 RouterService 使用时:

const seq = launchSession.next(payload)

this.loadBizData(payload).then(() => {
  if (!launchSession.isLatest(seq)) {
    // 旧入口触发的异步结果,不允许覆盖新入口状态。
    return
  }

  // 更新页面或路由状态
})

用户从通知点进来,半秒后又从服务卡片点进来,两次入口都可能触发异步加载。没有序号保护,旧请求后回来就能把新页面状态盖掉。

很多“偶尔跳错详情”的问题,本质就是旧任务覆盖了新任务。这个问题不加日志很难看出来,加了任务号以后,一眼就能看出是谁回来晚了。

哪些场景更适合这么做

这套启动治理不是所有 demo 都需要。一个只有首页和设置页的小工具,没必要上来就搞一堆入口层封装。

但下面几类应用,我建议早点做:

  • 内容类应用:从通知、搜索、外部链接进入文章或视频详情。
  • 办公类应用:服务卡片进入审批、待办、日程详情。
  • 电商和本地生活:活动链接、订单通知、桌面快捷入口都要落到不同业务页。
  • 工具类应用:从分享、文件打开、Deep Link 进入不同编辑模式。
  • 多 UIAbility 应用:主界面、独立编辑器、沉浸式展示页需要不同启动实例策略。

只要入口超过两个,就建议尽早把 Want 解析收敛掉。别等首页堆到几百行再重构,到那时候你已经分不清哪段逻辑是给哪个入口补的了。

结尾:入口治理写早一点,后面少还很多债

HarmonyOS 的 AbilityStage、Want、UIAbility,不只是应用模板里那几个默认文件。它们更像应用的入口骨架。

骨架稳了,页面和业务路由才不会到处补洞。

我的习惯是:AbilityStage 只做轻量进程级准备和分流;Want 进入应用后马上转成 LaunchPayload;UIAbility 统一处理冷启动和二次拉起;页面只消费归一后的业务参数。

看着多了几个类,但后面加入口、查问题、做灰度、做埋点,都会轻松很多。

别把启动参数散落在每个页面里。页面一多,谁都不愿意碰;入口一多,问题就开始像玄学。启动链路这种东西,越早工程化,越不容易在上线后给自己挖坑。

Neo 构建鸿蒙应用【三】:实战社交应用与工程感悟

Neo 构建鸿蒙应用【三】:实战社交应用与工程感悟

Neo 框架连载(终篇)· AI 辅助撰写

前两篇讲完了架构和机制。这一篇换个角度——不谈概念,只看代码。用一个模拟 Soul 业务场景的社交应用完整实现,验证框架在真实项目中的表现,最后分享一些工程实践中的感悟。

示例项目:EchoApp

EchoApp 是 Neo 仓库中的示例项目(examples/soul-app),模拟一款社交应用的核心功能:聊天、广场动态、匹配、用户资料等。不是 demo 级别的 HelloWorld,而是有意按照中型项目的体量来组织代码:

维度 数量
Service 总数 27
infra 层 8
business 层 12
feature 层 5
lazy 层 2
页面 10
组件 40+

选择这个体量是有原因的——太少了看不出分层的价值,太多了读起来成本太高。27 个 Service 恰好在"能看清楚全貌"和"有足够的复杂度"之间。

从零开始:AppModule 的设计思路

AppModule 是整个应用的起点,所有 27 个 Service 在这里统一声明:

export const appModule = new NeoModule('EchoApp', [
  // ===== GLOBAL_PHASE (serial, p10) — 8 infra services =====
  { tag: 'AppInitService', phase: GLOBAL_PHASE, factory: () => new AppInitService() },
  { tag: 'SecurityService', phase: GLOBAL_PHASE,
    factory: () => new SecurityService(), dependencies: ['AppInitService'] },
  { tag: 'DatabaseService', phase: GLOBAL_PHASE,
    factory: () => new DatabaseService(), dependencies: ['AppInitService'] },
  { tag: 'NetworkService', phase: GLOBAL_PHASE,
    factory: () => new NetworkService(), dependencies: ['AppInitService', 'SecurityService'] },
  { tag: 'CacheService', phase: GLOBAL_PHASE, factory: () => new CacheService() },
  { tag: 'StorageService', phase: GLOBAL_PHASE,
    factory: () => new StorageService(), dependencies: ['AppInitService'] },
  // ...

  // ===== BUSINESS_PHASE (serial, p20) — 12 business services =====
  { tag: 'AuthService', phase: BUSINESS_PHASE,
    factory: () => new AuthService(), dependencies: ['NetworkService', 'SecurityService', 'StorageService'] },
  { tag: 'UserService', phase: BUSINESS_PHASE,
    factory: () => new UserService(), dependencies: ['AuthService', 'DatabaseService'] },
  { tag: 'IMService', phase: BUSINESS_PHASE,
    factory: () => new IMService(), dependencies: ['AuthService', 'NetworkService', 'DatabaseService'] },
  { tag: 'MomentService', phase: BUSINESS_PHASE,
    factory: () => new MomentService(), dependencies: ['AuthService', 'NetworkService', 'CacheService'] },
  { tag: 'MatchService', phase: BUSINESS_PHASE,
    factory: () => new MatchService(), dependencies: ['AuthService', 'NetworkService', 'CacheService'] },
  // ...

  // ===== FEATURE_PHASE (parallel, p30) — 5 feature services =====
  { tag: 'SearchService', phase: FEATURE_PHASE,
    factory: () => new SearchService(), dependencies: ['NetworkService', 'CacheService'] },
  { tag: 'AnalyticsService', phase: FEATURE_PHASE,
    factory: () => new AnalyticsService() },
  // ...

  // ===== LAZY_PHASE (parallel, p40) — 2 lazy services =====
  { tag: 'GameService', phase: LAZY_PHASE,
    factory: () => new GameService(), dependencies: ['MatchService', 'IMService'] },
  { tag: 'StoryService', phase: LAZY_PHASE,
    factory: () => new StoryService(), dependencies: ['AuthService', 'NetworkService', 'MediaService'] },
])

设计这个文件时的思考

1. 分层的判断标准

哪些 Service 放 infra、哪些放 business,不是拍脑袋决定的。判断标准:

  • infra:无业务状态,换一个应用也能用。NetworkService、CacheService、DatabaseService——它们不知道"用户"是什么概念
  • business:有业务状态,和具体应用绑定。AuthService 知道 token,IMService 知道消息,MomentService 知道动态
  • feature:锦上添花,应用没有它们也能跑。SearchService、AnalyticsService
  • lazy:用户可能永远不会用到的功能。GameService、StoryService

2. 依赖的方向

依赖关系一定是单向的:infra ← business ← feature ← lazy。不会出现 IMService 依赖 SearchService 的情况。这不是框架强制的,而是分层的自然结果——你不会在业务层引用一个功能层的服务,因为业务层在它之前就加载了。

3. Phase 的调整是启动优化的主要手段

假设启动速度不达标,优化思路不是去改 Service 内部代码,而是调整 Phase 归属:

  • MatchService 从 BUSINESS 降到 FEATURE?匹配结果不在首屏展示,可以先显示骨架屏
  • EmojiService 从 BUSINESS 降到 FEATURE?表情面板不是默认展开的
  • 每降一个,BUSINESS 阶段就少一个串行等待的 Service,用户更快看到首页

这种优化不需要改任何业务代码,只改 AppModule 中的 phase 字段。

一个完整的数据流:发送消息

以聊天功能为例,走一遍从用户操作到 UI 刷新的全链路。

页面层(features)

// ChatPage.ets
@Entry
@Component
struct ChatPage {
  @State messages: ChatMessage[] = []
  @State inputText: string = ''
  private imSvc?: IMService
  private unbind: (() => void) | undefined
  private conversationId: string = ''

  aboutToAppear() {
    const params = router.getParams() as ChatPageParams
    this.conversationId = params.conversationId

    this.imSvc = serviceManager.get<IMService>('IMService')!
    this.unbind = StateBinder.bind<ChatMessage[]>(
      this.imSvc.getMessagesObservable(),
      this as Object,
      'messages'
    )
    this.loadMessages()
  }

  aboutToDisappear() { this.unbind?.() }

  async loadMessages() {
    if (this.imSvc && this.conversationId) {
      this.messages = await this.imSvc.getMessages(this.conversationId)
      await this.imSvc.markAsRead(this.conversationId)
    }
  }

  // 用户点击发送
  async onSend() {
    if (this.imSvc && this.inputText.trim()) {
      await this.imSvc.sendMessage(this.conversationId, this.inputText.trim())
      this.inputText = ''
    }
  }

  build() {
    Column() {
      List() {
        ForEach(this.messages, (msg: ChatMessage) => {
          ListItem() {
            // 渲染消息气泡
          }
        })
      }
      // 输入框 + 发送按钮
    }
  }
}

页面做的事情很薄:绑定 Observable、调用 Service 方法、渲染 UI。没有网络请求、没有状态管理、没有回调地狱。

业务层(domains)

// IMService.ets
export class IMService extends Service {
  private conversationsObs = new Observable<Conversation[]>([])
  private messagesObs = new Observable<ChatMessage[]>([])

  getMessagesObservable() { return this.messagesObs }

  async sendMessage(conversationId: string, content: string): Promise<ChatMessage> {
    // 1. 业务逻辑:创建消息
    const msg = this.createMessage(conversationId, content)

    // 2. 网络:发送到服务器
    await this.networkSvc.send('/im/send', msg)

    // 3. 更新 Observable → 自动通知所有绑定的页面
    const msgs = this.messagesObs.getValue()
    this.messagesObs.setValue([...msgs, msg])

    // 4. 发送事件 → 其他 Service 可以响应
    eventBus.emit('im:messageSent', { conversationId, message: msg } as Object)

    return msg
  }
}

业务层做的事情:处理业务逻辑、协调基础设施、更新 Observable、发送事件。它不知道有哪些页面在用自己,也不知道 UI 长什么样。

基础设施层(infra)

// NetworkService.ets
export class NetworkService extends Service {
  async send(path: string, data: Object): Promise<Object> {
    // 纯技术实现:HTTP 请求、重试、超时
    // 不知道"消息"是什么,只知道 path 和 data
  }
}

基础设施层做的事情:纯技术实现。不知道业务概念,不知道 UI,甚至不知道自己在被谁调用。

完整链路

用户点击发送(ChatPage.onSend)
  → imSvc.sendMessage(convId, '你好')        // 页面调 Service
    → 创建消息对象                            // 业务逻辑
    → networkSvc.send('/im/send', msg)        // 调基础设施
    → messagesObs.setValue([...msgs, msg])    // 更新 Observable
      → StateBinder 自动写入 @State messages  // 数据驱动 UI
      → ArkUI 重新渲染消息列表                 // 用户看到新消息
    → eventBus.emit('im:messageSent')         // 通知其他 Service

页面不需要手动 this.messages = newMessages,不需要 this.$setState(),不需要 notifyDataSetChanged()。Service 调了 setValue,UI 自动刷新。

新增一个功能要改几个文件

假设产品要求新增一个"举报"功能。需要改哪些文件?

1. 定义 Serviceservices/feature/ReportService.ets(新建)

export class ReportService extends Service {
  async report(targetId: string, reason: string): Promise<boolean> {
    const network = this.depServices.find(s => s.tag === 'NetworkService') as NetworkService
    await network.send('/report', { targetId, reason } as Object)
    return true
  }
}

2. 注册到 AppModulemodules/AppModule.ets(加一行)

{ tag: 'ReportService', phase: FEATURE_PHASE,
  factory: () => new ReportService(), dependencies: ['NetworkService'] },

3. 页面使用 — 在需要举报的页面中

const reportSvc = serviceManager.get<ReportService>('ReportService')!
await reportSvc.report(targetId, '不适当内容')

三个文件,零耦合。不需要修改 NetworkService、不需要修改任何基类、不需要在某个全局注册表里手动添加。定义 → 注册 → 使用,流程是固定的。

工程感悟

框架是团队契约,不是技术炫耀

我说这么多有的没的,核心就一件事:如果存在一种共同约束,不是特别完美,但也不特别烂,就能产生一些价值。

精准高效沟通是特例,低效沟通是常态;层次分明是特例,层次渗透是常态;需求稳定是特例,经常变更是常态。Neo 提供的不是理想架构,而是一个团队可以共同遵守的底线。所有人定义 Service 的时候知道 init 不能做 IO,声明依赖的时候知道要看 AppModule,写页面的时候知道通过 Observable 拿数据。

这种共同约束的收益不是立竿见影的,而是在项目三个月、六个月、一年后——当新功能还在源源不断地加进来,而代码还能看懂、还能改、还能测试的时候——才会体现。

ArkTS 的限制反而帮了忙

ArkTS 比 TypeScript 严格很多:不能用 any、不能用 Record<> 的动态访问、不能省略泛型、不能 spread 对象。这些限制在初期让人头疼,但回头看,它们迫使你写出更明确的代码:

  • 没有 any → 每个变量都有类型 → Service 的接口必须定义清楚
  • 不能动态访问属性 → 必须用接口声明 router.getParams() 的返回值 → 页面参数有文档
  • 必须显式泛型 → StateBinder.bind<T>() 一眼就知道绑的是什么类型

这些限制和 Neo 的设计理念是契合的——约束带来清晰

结构化不是炫技

尤其在近两年 AI 编程越来越成熟的背景下,"炫技"显得越来越廉价。结构化的目的是让代码可维护、可测试、可交接,而不是展示设计模式的熟练度。

AI 时代的工程节奏

Neo 本身就是 AI 辅助开发的产物。我的判断是:AI 生成产品的速度太快了,把 IDEA 尽可能快地做出来,远比人工打磨细节的 ROI 高。

本系列文章也是这个思路——核心观点和设计决策是人定的,文字落地是 AI 做的。与其花一周打磨一篇"完美"的技术文章,不如一天发三篇把思路讲清楚,把省下来的时间投入到下一个功能、下一个项目中。

写在最后

软件是有固有生命周期的,公司和团队也有生命周期。在经济上行期软件行业的迭代都非常快,很多软件在没达到最大容积之前,公司和团队的生命周期已走到最终阶段。

这不是悲观——恰恰是因为时间有限,才更需要一个好的结构约束。让代码在你还在的时候能跑,在你走了之后别人也能接。Neo 不追求成为最好的框架,只追求成为一个不太烂的共同约束

如果这篇文章对你有一点启发,去 GitHub 看看源码,跑一下 EchoApp 示例。觉得有用就点个 Star,有问题就提 Issue。

共勉。


系列文章

Neo 构建鸿蒙应用【二】:技术路线全解

Neo 构建鸿蒙应用【二】:技术路线全解

Neo 框架连载 · AI 辅助撰写 · GitHub

上一篇建立了四层架构的宏观视图。这一篇把 Neo 的全部技术机制讲完:Service、NeoModule、ServiceManager、Phase、Observable、StateBinder、Scope。

核心思路借鉴了 JavaBean 和 IoC——Java Boy 编程梦开始的地方。

Service:最小功能单元

所有领域建模被命名为 XXXService,继承 Service 基类。一个 Service 的完整生命周期:

constructor → register → init → loginCallback → load → (WORKING)
                                                  ↑
                                    reload ← unload ← logoutCallback

基类定义

export abstract class Service implements AppPropagation {
  tag: string = this.constructor.name    // 默认用类名作标识
  context: Context | undefined
  depServices: AppPropagation[] = []     // 依赖的服务列表

  constructor(services: Service[]) {
    this.depServices = services
  }

  register = (cxt: Context) => {
    this.context = cxt
    this.init()
    // lifecycle → INITIALIZED
  }

  loginCallback = async () => {
    this.load().then(res => {
      if (res) {
        // lifecycle → WORKING
        serviceManager.refreshNode(this, this.lifecycle)
      }
    })
  }

  logoutCallback = async () => { /* unload → INITIALIZED */ }

  init() {}                                        // 初始化成员属性,不能做网络 IO
  async load(): Promise<boolean> { return true }   // 加载数据
  async unload(): Promise<boolean> { return true } // 卸载清理
  reload = () => { this.unload().then(() => this.load()) }
}

设计要点:

  • register 是箭头函数属性,不是方法。ArkTS 中子类不能 override 父类的箭头函数属性,保证基类的生命周期管理不被绕过
  • constructor(services: Service[]) 构造器注入,Spring 的思路
  • init() 不能做网络 IO——仅用于初始化成员属性
  • load() 返回 Promise<boolean>——true 表示成功,状态转为 WORKING

实际例子

// AuthService.ets
export class AuthService extends Service {
  private currentUser: UserInfo | null = null
  private token: string = ''

  constructor() { super([]) }

  init() { this.currentUser = null; this.token = '' }

  async load(): Promise<boolean> {
    const saved = await this.loadFromStorage()
    if (saved) { this.token = saved.token; this.currentUser = saved.user }
    return true
  }

  async unload(): Promise<boolean> {
    this.currentUser = null; this.token = ''
    return true
  }
}

NeoModule:Koin 式模块声明

Service 定义好了,如何组织起来?借鉴 Koin 的 module DSL 风格:

import { NeoModule, GLOBAL_PHASE, BUSINESS_PHASE } from 'neo'

const networkModule = new NeoModule('Network', [
  { tag: 'ApiService', phase: GLOBAL_PHASE, factory: () => new ApiService([]) },
  { tag: 'AuthService', phase: GLOBAL_PHASE, factory: () => new AuthService([]) },
])

const userModule = new NeoModule('User', [
  { tag: 'UserService', phase: BUSINESS_PHASE,
    factory: () => new UserService([]),
    dependencies: ['AuthService'] },
])

每个声明包含:

字段 说明
tag 服务唯一标识
phase 所属加载阶段
factory 延迟创建工厂
dependencies 依赖的其他服务 tag

模块组合:

const appModule = networkModule.merge(userModule)
// 同名声明以当前模块优先

校验(load() 时自动调用):

const errors = appModule.validate()
// 检测缺失依赖 + 循环依赖(DFS)

ServiceManager:IoC 容器

中枢管理者,处理注册、依赖解析和生命周期。

核心流程

// EntryAbility.onCreate
serviceManager.register(this.context)          // 注入上下文
serviceManager.loadModule(appModule)            // 加载模块(校验、分组、注册)
await serviceManager.loginCallback()            // 触发多阶段启动

依赖解析

内部维护两张映射:serviceMap(tag → 实例)和 dependentMap(被谁依赖)。loginCallback 触发时递归解析依赖链——加载 Service A 之前,确保其所有依赖已 WORKING:

// ServiceManager 内部(简化)
private ensureNodeWorking(node) {
  await Promise.all(node.depServices.map(dep => this.ensureNodeWorking(dep)))
  this.invokeLogin(node)
  await this.waitForLifecycle(node.tag, ServiceLifeCycle.WORKING)
}

获取服务:

const userService = serviceManager.get<UserService>('UserService')!
const isReady = serviceManager.ready(userService)

Phase:渐进式启动

27 个 Service 不需要同时加载。

四个预定义阶段

阶段 优先级 策略 用途
GLOBAL_PHASE 10 串行等待 配置、数据库、网络、安全
BUSINESS_PHASE 20 串行等待 认证、用户、消息、通话
FEATURE_PHASE 30 并行触发 搜索、统计、主题、国际化
LAZY_PHASE 40 并行触发 小游戏、故事

策略含义:

  • 串行等待waitForComplete: true):该阶段全部完成后才进入下一阶段
  • 并行触发waitForComplete: false):触发后立即进入下一阶段,不等待完成
时间轴 ─────────────────────────────────────────────→

GLOBAL (串行)  ████████████████
BUSINESS (串行)                 ████████████████
FEATURE (并行)                                   ████ ← 不阻塞
LAZY (并行)                                           ██ ← 不阻塞

                     ↑ UI 可交互

启动耗时可控的核心:GLOBAL + BUSINESS 同步确保核心就绪,FEATURE + LAZY 异步不阻塞。优化手段就是把非必要 Service 从 BUSINESS 降到 FEATURE。

实战中的启动优化

我曾在实际项目中用这套机制做过启动优化(详见原文),当时 Neo 还不存在,但核心代码已经具备了 Service + Phase 的雏形。

优化成果固然可喜,但更重要的是整个结构变得可控了。因为每个 Service 的依赖关系、加载阶段、生命周期都是声明式的,我可以保证:

  • 把某个 Service 从 BUSINESS 降到 FEATURE,不会导致依赖它的模块出问题——依赖解析是自动的
  • 新增一个 Service 不需要改任何已有代码——在 AppModule 加一行声明即可
  • 变更的影响范围是可预期的——约束由框架兜底

这不是黑盒优化,而是白盒优化。以后遇到启动性能问题,打开 AppModule 调整 Phase 归属即可——不需要重新分析依赖链,不需要画调用图,套路是固定的。

自定义阶段:

const CACHE_PHASE = createPhase({
  name: 'CACHE', priority: 25, waitForComplete: false, description: '缓存预热'
})

Observable:Service 端的数据源

Service 加载了数据,如何让页面感知变化?

朴素做法是页面直接调 Service 方法拿返回值赋给 @State——但只在初始化时有效,其他页面的数据变更不会自动刷新。

Neo 的方案是 Observable——泛型观察者容器:

export class Observable<T> {
  private value_: T
  private listeners: Set<(value: T) => void> = new Set()

  constructor(initialValue: T) { this.value_ = initialValue }
  getValue(): T { return this.value_ }

  setValue(newValue: T): void {
    if (this.value_ === newValue) return
    this.value_ = newValue
    this.notify()
  }

  onChange(listener: (value: T) => void): () => void {
    this.listeners.add(listener)
    return () => { this.listeners.delete(listener) }
  }
}

没有 Subject、没有 Operator、没有调度器。ArkTS 不支持 RxJS 那套管道,也没有必要引入。

Service 中使用

export class IMService extends Service {
  private conversationsObs = new Observable<Conversation[]>([])
  private messagesObs = new Observable<ChatMessage[]>([])

  getConversationsObservable() { return this.conversationsObs }
  getMessagesObservable() { return this.messagesObs }

  async sendMessage(conversationId: string, content: string): Promise<ChatMessage> {
    const msg = await this.doSend(conversationId, content)
    const msgs = this.messagesObs.getValue()
    this.messagesObs.setValue([...msgs, msg])  // 自动通知 UI
    return msg
  }

  async load(): Promise<boolean> {
    this.conversationsObs.setValue(await this.fetchConversations())
    return true
  }
}

模式:内部持有 Observable → getter 暴露 → setValue 触发变更。外部只能订阅,不能直接修改。

StateBinder:Service 到 @State 的桥

Observable 解决了通知问题,StateBinder 解决了写入 @State 的问题:

export class StateBinder {
  static bind<T>(
    observable: Observable<T>,
    component: Object,      // 页面组件实例
    stateKey: string        // @State 属性名
  ): () => void {
    const record = component as Record<string, Object>
    record[stateKey] = observable.getValue() as Object    // 初始化
    const unlisten = observable.onChange((newValue: T) => {
      record[stateKey] = newValue as Object               // 变更时自动写入
    })
    return unlisten
  }

  static bindAll(factories: Array<() => () => void>): () => void { /* 批量绑定 */ }
}

页面中使用

@Entry
@Component
struct ChatListPage {
  @State conversations: Conversation[] = []
  private unbind: (() => void) | undefined

  aboutToAppear() {
    const imSvc = serviceManager.get<IMService>('IMService')!
    this.unbind = StateBinder.bind<Conversation[]>(
      imSvc.getConversationsObservable(),
      this as Object,       // ArkTS 要求显式转换
      'conversations'
    )
  }

  aboutToDisappear() { this.unbind?.() }

  build() {
    List() {
      ForEach(this.conversations, (conv: Conversation) => {
        ListItem() { /* 渲染会话项 */ }
      })
    }
  }
}

注意两点 ArkTS 限制:

  • this as Object 不能省略——组件的 this 类型不允许直接传给 Object 参数
  • 显式泛型 <T> 不能省略——ArkTS 不支持自动推断泛型给 Record<string, Object> 赋值

批量绑定:

aboutToAppear() {
  this.unbind = StateBinder.bindAll([
    () => StateBinder.bind<Conversation[]>(imSvc.getConversationsObservable(), this as Object, 'conversations'),
    () => StateBinder.bind<ChatMessage[]>(imSvc.getMessagesObservable(), this as Object, 'messages'),
    () => StateBinder.bind<number>(matchSvc.getCountObservable(), this as Object, 'matchCount'),
  ])
}

aboutToDisappear() { this.unbind?.() }  // 一行解绑所有

Scope:页面级作用域

有些 Service 是页面专属的,页面离开时应该卸载:

import { scopeManager } from 'neo'

aboutToAppear() {
  this.scope = scopeManager.createScope('ChatPage')
  this.scope.bindTo(this)  // aboutToDisappear 时自动 close

  const chatRoomSvc = new ChatRoomService([])
  this.scope.register(chatRoomSvc)
}
// 页面销毁 → scope.close() → unload 所有注册的服务

Scope 查找机制:优先从作用域内找,找不到回退到全局 ServiceManager。scope.get<T>('ChatRoomService') 获取页面级服务,scope.getGlobal<T>('AuthService') 获取全局服务。

小结

Neo 的完整技术路线:

组件 职责
Service 功能单元,声明式生命周期
NeoModule Koin 式模块声明,组合与校验
ServiceManager IoC 容器,依赖解析
Phase 多阶段加载,串行/并行策略
Observable Service 端可观察数据源
StateBinder Service 数据 → @State 响应式桥
Scope 页面级作用域,自动卸载

下一篇是最后一篇,用 SoulApp 示例串起全链路,并分享这个框架在工程实践中的一些感悟。


系列文章

鸿蒙呼吸动画踩了三个坑:GPU降级时机、设计Token校验、i18n漏key——具体怎么处理的

在鸿蒙上做呼吸动画,我以为最难的是 ArkTS 语法,结果最麻烦的是——我根本不知道用户的设备跑到哪一档了。

呼吸动画是「呼吸视界」这个 App 的核心体验:吸气时圆圈缓慢扩张,屏气时保持,呼气时收缩。这个动画一旦卡顿,「跟着 App 呼吸」的节奏就断了,用户能感觉到「哪里不对」,但不会告诉你是帧率问题。

先说一下这个 App 是干什么的,方便后面的技术背景理解。

产品背景:一个给自己做的呼吸训练工具

「呼吸视界」(iOS App Store ID: 6758613852)做的是结构化呼吸训练引导——4-7-8 呼吸法、盒式呼吸、Wim Hof 法这些。网上这些方法的文字说明很多,但照着文字练,你得自己数秒、记顺序,练着练着就分心了。

我做这个的起因很功利:开会前容易紧张,想找个东西帮我两分钟之内把状态重置一下。找了一圈没找到合适的,就自己写了。

App 有三块核心功能:带动画节奏的引导式练习、本地持久化的训练记录、以及一个课程进度系统(不只是单次练习,而是完整的训练计划)。iOS 版目前评分 5 分,样本量不大,但有个用户说「可以跟随练习呼吸,保持稳定的心情」——说实话这个反馈比我预期的更朴实,我自己用下来觉得更直接的感受是:开会前真的有用,两分钟够了。

鸿蒙版最近发布,把移植过程里踩的几个坑整理一下。

坑一:呼吸动画的 GPU 降级,我不知道该在哪个阈值切

呼吸动画用 GPU 渲染时效果最好,过渡顺滑,缩放曲线自然。但鸿蒙设备碎片化比 iOS 严重得多,中低端机上 GPU 渲染直接掉帧,整个动画变得一顿一顿的。

所以我做了一套自适应降级:检测到性能不足时切到 Canvas fallback 模式,同时把当前渲染质量分成 highbalancedlow 三档。

问题来了:切换阈值怎么定?

我的判断方式是盯 frameMs(单帧渲染耗时)和连续低帧计数:

// 连续低帧超过阈值时触发降级
if (frameMs > 22 && consecutiveLowFpsCount >= 3) {
  // 22ms ≈ 45fps,低于此值且连续3帧 → 切 balanced
  adaptRenderer('degrade quality -> balanced');
  consecutiveLowFpsCount = 0;
}
if (frameMs > 33 && consecutiveLowFpsCount >= 3) {
  // 33ms ≈ 30fps,连续3帧 → 切 canvas fallback
  adaptRenderer('switch renderer -> canvas fallback');
}

这个阈值不是凭感觉拍的,是我把 hilog 日志抓出来跑脚本分析的结果。日志里会输出每帧的 fpsframeMstickMs 以及当前渲染质量档位,降级事件会打 BF_PERF_ADAPT 标签,比如 degrade quality -> balanced 或者 switch renderer -> canvas fallback

对独立开发者来说这套日志分析挺重要——没有 QA、没有用户主动反馈卡顿,只能靠工具自己发现问题。我在没有真机的情况下,靠日志回放重现了好几个卡顿场景。

目前 Canvas 模式下动画过渡还是不如 GPU 顺滑,这个还在打磨,算是没解决干净的问题。

坑二:设计 Token 漏用——一个脚本比 code review 更可靠

App 的调性是「平静克制」,UI 上我比较在意所有间距、圆角、阴影、动画时长要统一。如果哪个地方直接写了魔法数字,整体质感就散了。

鸿蒙版我把所有设计 token 收进一个 Style.ets,导出四个命名空间:SPACERADIUSSHADOWMOTION。问题是开发过程中很容易手滑——改某个组件时直接写 borderRadius(8) 而不是 RADIUS.card,这种事我自己也干过。

所以我写了一个 check_design_foundation.py,逻辑很简单:用 path.read_text() 读取关键文件内容,用字符串匹配检查是否包含预期的 token 引用。比如检查 AppBackdrop.ets 里有没有 export struct AppBackdrop,检查 SheetBackground.ets 里有没有调用 AppBackdrop(,检查根页面 RootPage.ets 里有没有 AppBackdrop({

不是正则匹配魔法数字(那个误报太多),而是检查「关键结构是否存在」——更像一个架构约束验证器。

真实案例:有一次我重构了背景组件 AppBackdrop,改了对外接口,但忘了更新 SheetBackground 里的调用方式,就是被这个脚本拦下来的。如果没有这个检查,这个问题可能得等到真机运行时才会发现。

我还把几个类似的脚本整合进一个 check_foundation_alignment.py,统一管理:设计 token 校验、按压反馈检查、页面过渡检查、i18n 对等检查、路由检查——提交前一起跑,哪个挂了去修哪个。独立开发没有 code review,这套东西算是自己给自己兜底。

坑三:i18n 漏 key,双语维护是个持续性的低级错误

App 支持中英双语,维护四个语言文件:strings_app_en.etsstrings_app_zh-Hans.ets 以及对应的 base 版本。每次加新功能往里填 key,英文填了忘了填中文,或者反过来,这种事经常发生。

check_i18n_keys.py 做的事很直白:把四个文件里的 key 全部提取出来做集合差运算,输出「哪些 key 在英文有但中文没有」以及反向的情况。

这个脚本帮我发现过好几次漏掉的 key,有时候漏的是边缘功能的文案,有时候是一个按钮标题——后者如果漏了,用户看到的就是 key 字符串本身,很难看。

课程进度系统:本地存储是主动选择,不是偷懒

ProgramProgressRecord 记录用户在某个训练计划里完成了哪些 session、当前在第几阶段。数据全部本地存储,没有云同步。

说实话云同步我也不想做。OAuth 接入、服务器费用、隐私合规、多端数据冲突处理……这一套对独立开发者来说投入产出比太低。用户的训练记录放本地就够了,鸿蒙的 Preferences 和 RelationalStore 用起来比我预期顺手,持久化这块没遇到太大麻烦。

自定义呼吸节奏的交互,我还没想明白

用户可以自由设置吸气、屏气、呼气各阶段的时长。这个功能的交互我试了三版:滑动条、数字步进器、转盘——感觉都差点意思。滑动条精度不够,步进器操作次数太多,转盘在小屏上很难操作。

这个目前还搁着,UI 做得比较简陋。如果你做过类似的时长输入控件——尤其是整数秒精度、范围大概 1-30 秒的场景——很想听听你用了什么方案。

【Flutter×鸿蒙】通关手册(二):FVM 不认鸿蒙 SDK?4步手动塞进去

系列导航:

我第一次让 FVM 管理鸿蒙版 Flutter SDK 时,前后踩了 4 个坑,花了大半天才跑通。事后复盘发现,每个坑都不难,只是没人提前告诉我"为什么要这样做"。这篇把整个过程拆成 5 关,每关讲清「为什么」和「怎么做」,争取让你 20 分钟一次通关。

前置条件:请先完成第一篇的全部内容——DevEco Studio 已安装,ohpm、node、hvigorw 在终端里都能正常调用。


🗺️ 通关路线图

关卡 任务 预计耗时
第1关 安装 FVM 2 min
第2关 克隆鸿蒙版 SDK 5 min(取决于网速)
第3关 修复版本"身份证" 3 min
第4关 指定鸿蒙 SDK 路径 1 min
第5关 全绿验证 2 min

🎯 第 1 关:安装 FVM

目标

让终端认识 fvm 命令。

为什么需要 FVM

一句话——让不同项目用不同版本的 Flutter,互不干扰。比如项目 A 用官方 3.24 跑 Android/iOS,项目 B 用鸿蒙版 3.35.8。FVM 就是 Flutter 的"版本档案柜",每个抽屉放一个版本。

📋 操作

# macOS(在终端里执行,这是用 Homebrew 包管理器安装 FVM)
brew install fvm
# Windows(在 cmd 或 PowerShell 中执行,这是用 Chocolatey 包管理器安装 FVM)
choco install fvm

安装完后,配置 FVM 缓存路径。把以下两行写入 ~/.zshrc(上一篇介绍过,这是 Mac 终端的配置文件):

# FVM 存放所有 Flutter 版本的目录
export FVM_CACHE_PATH=$HOME/fvm
# 让 FVM 的默认版本可以直接用 flutter 命令调用
export PATH="$HOME/fvm/default/bin:$PATH"

保存后执行下面这条命令,让刚才的配置立即生效(否则要关掉终端重新打开):

source ~/.zshrc

✅ 验证

# 查看 FVM 版本号,确认安装成功
fvm --version

看到版本号(如 3.1.4)就过关了。

⚠️ 如果报 command not found:Mac 用户确认已安装 Homebrew(执行 brew --version 看有没有输出);Windows 用户确认已安装 Chocolatey(执行 choco --version)。如果包管理器本身都没装,请先去官网安装。


🎯 第 2 关:克隆鸿蒙版 SDK

目标

把华为的鸿蒙版 Flutter 放进 FVM 管辖。

为什么不能直接 fvm install

正常装 Flutter 只需要 fvm install 3.24.0,FVM 会自动去 GitHub 下载。但鸿蒙版是华为团队在 AtomGit(国内代码托管平台)上单独维护的,FVM 的世界里它根本不存在。所以我们要"手动入库"——自己下载代码,放到 FVM 的档案柜里,假装它一直在那。

⚠️ 本关最大的坑:分支名和版本号是两回事!

仓库的分支叫 oh-3.35.7-dev,看到 3.35.7 你会以为版本就是 3.35.7。但实际上代码里的版本已经迭代到了 3.35.8-ohos-0.0.2

类比:Git 分支叫 feature/login-v1,但代码早就改到 v3 了。分支名是创建时起的,不会跟着版本号自动更新。

千万别拿分支名当版本号用,团队必须统一用 3.35.8-ohos-0.0.2 这个真实版本号。

📋 操作

# --depth 1 只取最新代码,省空间(省去几个 GB 的历史记录)
git clone -b oh-3.35.7-dev --depth 1 
https://atomgit.com/openharmony-tpc/flutter_flutter.git 
~/fvm/versions/3.35.8-ohos-0.0.2

注意看:clone 命令里分支名是 oh-3.35.7-dev,但目标文件夹名是 3.35.8-ohos-0.0.2——这不是写错了,上面已经解释了为什么不一样。

💡 怎么确认真实版本号? clone 完后执行 ~/fvm/versions/3.35.8-ohos-0.0.2/bin/flutter --version 看输出。如果加入已有团队,直接看项目的 .fvmrc 文件(命令:cat .fvmrc)。

✅ 验证

# 确认文件下载成功(ls = 列出目录内容)
ls ~/fvm/versions/3.35.8-ohos-0.0.2/bin/flutter

文件存在就过关。

⚠️ 如果报 No such file or directory:回去检查 clone 命令是否执行成功。常见原因是网络超时(AtomGit 在国内,通常不需要梯子,但公司内网可能有限制)。重新执行 clone 前,先删掉残留目录:rm -rf ~/fvm/versions/3.35.8-ohos-0.0.2,再重试。


🎯 第 3 关:修复版本"身份证"

目标

让 FVM 正确识别这个 SDK 的版本号。

为什么要做这步

clone 下来的 SDK 有两张"证件":

  1. version 文件——相当于身份证,一行文本写着版本号
  2. bin/cache/flutter.version.json——相当于内部档案,JSON 格式的详细版本信息

问题是,这两张证件上都写着 0.0.0-unknown(因为鸿蒙团队是从开发分支构建的,没有打标准标签)。但我们的文件夹名叫 3.35.8-ohos-0.0.2。FVM 一查——名字对不上,直接翻脸。

⚠️ 不做这步的后果:FVM 会弹出 "Version mismatch" 并试图删掉你的 SDK 重装。如果看到了这个弹窗,千万不要选任何选项,按 Ctrl+C(Mac 也是 Ctrl 不是 Cmd)退出,回来做这步。

📋 操作

macOS / Linux:

cd ~/fvm/versions/3.35.8-ohos-0.0.2

# 第一步:改"身份证"
echo -n "3.35.8-ohos-0.0.2" > version

# 第二步:初始化 Flutter 引擎(首次运行会下载 Dart SDK,需要等 1-3 分钟)
bin/flutter --version

# 第三步:改"内部档案"(把所有 0.0.0-unknown 替换成正确的版本号)
sed -i '' 's/0.0.0-unknown/3.35.8-ohos-0.0.2/g' bin/cache/flutter.version.json

Windows PowerShell:

# 进入 SDK 所在目录
cd $env:USERPROFILE\fvm\versions\3.35.8-ohos-0.0.2

# 第一步:改"身份证"
"3.35.8-ohos-0.0.2" | Set-Content version -NoNewline

# 第二步:初始化引擎
bin\flutter --version

# 第三步:改"内部档案"(PowerShell 的查找替换写法)
(Get-Content bin\cache\flutter.version.json) -replace '0.0.0-unknown', '3.35.8-ohos-0.0.2' | Set-Content bin\cache\flutter.version.json

⚠️ 三步的顺序不能乱——第二步会生成 flutter.version.json 文件,第三步才有东西可改。如果你先执行了第三步,会报文件不存在。

✅ 验证

# 回到任意目录都可以执行(fvm list = 列出 FVM 管理的所有 Flutter 版本)
fvm list

看到 Version 列显示 3.35.8-ohos-0.0.2(不是空白、不是 Need setup、不是 0.0.0-unknown),这关就过了。

02_fvm_list.png ⚠️ 如果还是显示异常,逐一排查两张"证件":

# 检查"身份证"内容
cat ~/fvm/versions/3.35.8-ohos-0.0.2/version
# 应该输出:3.35.8-ohos-0.0.2(没有多余空行)

# 检查"内部档案"有没有残留的 0.0.0-unknown
cat ~/fvm/versions/3.35.8-ohos-0.0.2/bin/cache/flutter.version.json
# 里面所有 version 字段应该都是 3.35.8-ohos-0.0.2

如果 version 文件内容不对,重新执行第一步;如果 JSON 里还有 0.0.0-unknown,重新执行第三步。


🎯 第 4 关:指定鸿蒙 SDK 路径

目标

让 Flutter 知道鸿蒙的 SDK(OpenHarmony SDK)装在哪。

为什么不用环境变量

我试过 HOS_SDK_HOMEOHOS_SDK_HOME 等环境变量,时灵时不灵。原因是不同方式打开的终端(VS Code 内置终端 vs 系统终端 vs CI 环境)加载配置文件的顺序不一样,变量可能没被读到。flutter config 会把路径写入 Flutter 自己的配置文件,不管从哪里启动都能读到,最稳。

📋 操作

# 把鸿蒙 SDK 的位置"写死"到 Flutter 的配置里(一次性操作)
~/fvm/versions/3.35.8-ohos-0.0.2/bin/flutter config \
--ohos-sdk="/Applications/DevEco-Studio.app/Contents/sdk"

⚠️ Windows 用户路径改为:--ohos-sdk="C:\Program Files\Huawei\DevEco Studio\sdk"

请根据 DevEco Studio 实际安装路径调整。不确定装在哪?打开 DevEco Studio → Settings → SDK 页面可以看到路径。

终端输出 Setting "ohos-sdk" value to "..." 就成功了。

✅ 验证

不急,下一关一起验收。


🎯 第 5 关:全绿验证

目标

flutter doctor 中 HarmonyOS toolchain 一栏显示绿色对勾。

📋 操作

# 运行 Flutter 的环境诊断工具(-v 表示显示详细信息)
~/fvm/versions/3.35.8-ohos-0.0.2/bin/flutter doctor -v

✅ 验证

关注输出中的 HarmonyOS 那一栏:

[✓] HarmonyOS toolchain - develop for HarmonyOS devices
    • OpenHarmony Sdk at /Applications/DevEco-Studio.app/Contents/sdk,
      available api versions has [22:default]
    • Ohpm version 6.0.1
    • Node version v18.20.1
    • Hvigorw binary at .../hvigor/bin/hvigorw

看到 [✓] 加上 4 个子项都有值 = 通关!

02_flutter_doctor.png 💡 你可能会看到 Flutter 那栏有几个 ! 警告(channel 不标准、upstream 不是官方地址)。这是鸿蒙版的正常现象,完全不影响开发和打包,放心忽略。

⚠️ 如果 HarmonyOS 那栏还是红叉,按优先级排查:

  1. SDK not found → 回第 4 关检查 config 路径是否正确
  2. ohpm/hvigorw missing → 回第一篇检查环境变量
  3. Version mismatch → 回第 3 关检查两张"证件"

🔧 附加关:FVM 的"碎碎念"

通关后你会发现,每次用 fvm flutter xxx 时 FVM 都会弹 "not a valid version" 的警告让你确认。这不是报错,只是 FVM 在说:"这个版本号我在官方列表里查不到,你确定要用吗?"

三种应对方式:

  1. 手动按 y——每次弹出输入 y 回车
  2. 自动确认——命令前加 yes |
yes | fvm flutter doctor
  1. 绕过 FVM——直接用绝对路径调用,完全不弹警告:
~/fvm/versions/3.35.8-ohos-0.0.2/bin/flutter doctor

我推荐第三种,路径虽长但最省心。可以设个快捷方式(alias)缩短它:

# 把这行加到 ~/.zshrc 里(alias = 给一条长命令起个短名字)
alias hflutter="$HOME/fvm/versions/3.35.8-ohos-0.0.2/bin/flutter"

保存后 source ~/.zshrc,之后直接 hflutter runhflutter doctor 就行。


🏆 通关总结

项目 状态
FVM ✅ 已安装
鸿蒙版 Flutter SDK ✅ ~/fvm/versions/3.35.8-ohos-0.0.2
version 文件 ✅ 已修复
flutter.version.json ✅ 已修复
flutter config --ohos-sdk ✅ 已配置
flutter doctor HarmonyOS ✅ 全绿

回顾核心逻辑:FVM 只管官方 Flutter,鸿蒙版要我们手动塞进去(第 2 关);塞进去后"证件"信息对不上,需要手动修正(第 3 关);最后告诉 Flutter 鸿蒙 SDK 在哪(第 4 关)。理解了这条线,以后鸿蒙版 SDK 升级换版本号,你也能照样搞定。

如果中途卡住,大概率是版本号写错了——检查文件夹名、version 文件内容、flutter.version.json 里的版本号,三者必须完全一致


下一篇预告:SDK 准备好了,接下来要把你的老 Flutter 项目跑到鸿蒙上——听起来就是敲几行命令的事?没那么简单。→ 【Flutter×鸿蒙】通关手册(三):debug 包也要签名,这点和 Android 差远了

❌