前天的时候，想着这事不如小马过河一下，不能总是被别人现成的信息迷惑着。于是把一个在 Android 上从 Play 商店下载安装的 VPN app 的安装包导了出来。现在的安装包都被 Play 商店搞成了分割版本，语言、屏幕适配等资源都是独立的子包。把所有安装包都传递到鸿蒙 6 设备上，尝试安装。鸿蒙 6 会自动提示经由卓易通打开，但可惜的是，除了主包可以安装成功外，再安装其它几个子包都会失败。而单独安装成功的主包并不能正常运行起来。

后来又做了一点功课，找到一个叫做 AntiSplit M 的工具，它可以把 Play 商店的分割包在本地重组为单一包。这真是救命的稻草，于是来了这么一下子，再传到鸿蒙 6 里尝试安装，竟然就可以正常工作了。安装正常、启动正常、运行正常、功能正常。实话讲，一个为 Android 编写的网络层面的应用，能正常接管鸿蒙系统范围内的网络流量，这是三太爷一开始所没敢相信的，但它就是这样华丽丽地成了。

幸甚至哉，天还没全黑，且行且珍惜吧！

一开始是在老夫那台老旧的 MacBook Pro 2015 上进行的。首先是去官网下载 DevEco Studio 开发环境。体验很差，下载下来的是一个 zip 包，3GB 出头。双击解压，释放出来了 dmg 安装映像，装载映像后再把应用拖放至系统的应用程序文件夹中，这一来二去，对磁盘剩余空间的要求可不低。dmg 本身就有校验机制，完全不知道 zip 那一层是什么目的。安装后在官网的开发文档下寻找卡片开发的示例代码，找到了这个，由于是托管在 Gitee 上，花了一些时间回忆老夫在上面的账号信息。成功下载示例，用 IDE 打开，计划在模拟器里跑一下看，结果令人崩溃的来了：没有模拟器可用。倒不是说鸿蒙开发本身完全不支持模拟器，而是老夫的 MacBook Pro 不符合要求。对于一台 x64 架构的 MacBook Pro，华为给出的可选项是，要么运行 Windows 系统，要么是 ARM 架构的 macOS。无奈，只好换到另一台 Windows 老笔记本上重头再来。

使用 IDE 的向导打开示例工程看了看，感觉它演示的内容比想象的复杂，精简的话，面对根本不了解整个工程结构以及 TypeScript 语法的老夫来说，不是首选方向。于是选择了 DeepSeek，希望它能引导着从 0 实现一个最简单的卡片。最简单的目标有二：一是能把卡片创建到桌面上，二是点击之后能执行进入相应的处理代码中。之所以没有敢从国外敌对势力的 AI 进行，完全是怕它们蠢笨到根本不了解伟大的鸿蒙最新的革命性进展，难免令老夫误入歧途。

然而极可能由于鸿蒙系统过于先进的原因，导致相关信息的保密性也大大提升，所以 DeepSeek 虽然兢兢业业尽心尽责，却在沟通过程中一而再再而三地给出过失的项目组织结构，或者 API 调用的示例代码，复制到 IDE 里就会引发群起的红色警告。还好几个回合下来，老夫渐渐摸到了一些门道，TypeScript 的语法跟 Java 也堪堪可以比对起来稍有理解了，最后还是能构建成功了。悲催的是，人家官方示例的应用图标长按后，关联菜单上可以显示出有“卡片”的入口，而老夫的则不行。后来了解到，IDE 本身有向导可以引导一个卡片的创建过程，在工程树中右键，从关联菜单里选择“New->Service Widget”，其下有静态和动态两种 widget 可选。出于“最简”的原则，显然先弄个静态的试试。这样一来，工程里其实就拥有了老夫手工打造和 IDE 辅助打造的两个 widget。再次运行，发现 IDE 后加的 widget 出现在点选“卡片”入口后的待选列表里，老夫的手工打造的那个依旧无影踪。反复对比，最后发现了一个“只可能是它”的差异点：老夫在设置里指定的 widget 大小为 1×1，而不管是官方示例工程，还是 IDE 向导辅助创建成功的 widget，它们的布局大小都超过了这个尺寸。为了验证，当把 IDE 辅助创建的 widget 的大小设置为 1×1 后，果然它也消失了。这个怪异的限制，没有在任何文档中体现，只不过在向导界面里有所暗示，因为它让你可以选择的布局大小中，没有 1×1 这个选项。

前文提到，DeepSeek 给出的代码一般都不能正常通过编译。在老夫看来，它其实并不是有意的，只不过它所掌握的知识过于陈旧了而已。新加一个 widget 的话，首先是要在工程中增加两个配置项，一处是 src\main\resources\base\profile\form_config.json，在其中的 forms 节点下增加 widget 的基本描述信息，另一处是在 src\main\module.json5 中的 extensionAbilities 节点下增加对应的用于处理 widget 事件的 ability（应该派生于 FormExtensionAbility）的信息，这里会与前面的 form_config.json 关联起来。

此外当然就是代码。widget 自身的代码在 src\main\ets 下，看 IDE 的安排，是要先创建一个以 widget 名字命名的目录，其下再创建 pages 目录，再在其中创建 form_config.json  中指定文件名的 ets 源代码文件。在此源码文件中的同名类（但关键字使用的是添加了 @Entry 和 @Component 注解过的 struct 而不是 class）中，实现 build() 函数。

在这个函数中，执行声明式布局的组合。向其中的控件上增加常规的 onClick 事件处理器是无效行为（别问我怎么知道的），而似乎只能执行 postCardAction。究其原因，想必跟 Android 相似，这些布局最终生效是在远程，而非本 app 的进程内。除了为每一个要执行工作的控件一一指定执行 postCardAction 的 onClick 事件处理器之外，如果有一组相似的控件，例如按钮，还可以借助 FormLink 来完成，FormLink 的参数是一个如下结构：

{
  action:      'action_router',
  abilityName: 'EntryAbility',
  params: {
    message:   '哈哈哈'
  }
}

abilityName 指定了接收卡片上产生的事件的 ability 的名字，message 可以用来区分事件的名称。用一个 message 来区分事件名称看上去比较 low，但官方示例工程里就是这么干的。事实上，postCardAction 的第二个参数就是一个 FormLink。

那么，指定的 ability 如何才能处理卡片发来的动作请求？那就需要处理 onNewWant 了。例如，

onNewWant(want: Want, launchParam: AbilityConstant.LaunchParam): void {
    if (!want || !want.parameters) {
      return;
    }
    let message: string = (JSON.parse(want.parameters?.params as string))?.message;
    if (message === '哈哈哈') {
      console.info('onNewWant: 服务卡片的请求收到了。');

      const wantSettings: Want = {
        bundleName: 'com.huawei.hmos.settings', // 系统设置的包名
        abilityName: 'com.huawei.hmos.settings.MainAbility' // 系统设置的主界面 Ability
      };
      this.context.startAbility(wantSettings)
        .then(() => {
          console.info('Succeeded in starting ability.');
        })
        .catch((error: BusinessError) => {
          console.error(`Failed to start ability. Code is ${error.code}, message is ${error.message}`);
        });
    }
  }

老夫上述代码是想打开系统的设置界面，在模拟器上运行时并未出错，也输出了成功的日志，但是系统的设置界面并未打开。不知道真机上的效果会是如何。

另外，鸿蒙系统对应的 adb 工具叫 hdc（鸿蒙设备连接器），对应 adb 的 dumpsys 命令的命令是 hidumper，管理 ability 的命令是 aa。

实践得草率，总结得仓促，就这么着吧。