作为常年泡在技术社区的开发者，我对新系统的评判标准向来很直接：能否解决真实场景的痛点。鸿蒙系统问世初期，我没有跟风追逐 “分布式架构” 的宏大概念，而是被其 “轻量化服务触达” 的理念吸引。于是，我把第一个鸿蒙实战项目锁定在一个高频生活场景 ——WiFi 密码分享，用元服务和 App Linking 能力，打造了一款无需安装、碰一碰就能用的 WiFi 密码分享器。这个实验性工具，让我摸清了鸿蒙生态早期能力的应用逻辑，更体会到 “万物互联” 落地的细腻之处。
一、痛点驱动：为什么放弃传统方案选择鸿蒙特性？
WiFi 密码分享的痛点，相信每个人都遇过：家里来客时，要么翻遍手机备忘录找密码，要么对着路由器标签念字符；手机自带的二维码分享看似方便，却受品牌限制 —— 安卓用户给苹果用户分享时，扫出来只是一串乱码；更别提长辈来访，连扫码都觉得繁琐。传统工具类应用又需要双方都安装，临时使用的场景下完全不实用。
鸿蒙版本刚开放元服务能力时，我在开发者文档里看到 “无需安装、卡片化触达” 的描述，瞬间联想到了这个痛点。元服务的轻量化特性，正好匹配 “临时使用、用完即走” 的场景；而 App Linking 的跨应用跳转能力，能解决设备间的信息传递问题。更关键的是，鸿蒙的分布式软总线支持设备近距离快速交互，这让 “碰一碰分享” 从概念变成可能。
早期技术选型时，我曾纠结过两种方案：一是做传统的全屏应用，二是直接基于元服务开发。对比后发现，全屏应用的安装门槛会毁掉 “临时使用” 的核心体验，而元服务的卡片形态正好契合 “快速展示、一键操作” 的需求。最终确定核心技术栈：以元服务为载体，用 App Linking 实现跨设备信息传递，配合二维码生成和 WiFi 信息管理 API，完成从密码获取到分享的全流程。
二、开发攻坚：元服务与应用关联的实战踩坑
鸿蒙早期的开发文档还不够完善，很多能力需要靠调试摸索。整个开发过程中，元服务卡片的动态渲染和 App Linking 的参数传递，是最耗时的两个攻坚点，也让我对鸿蒙特性的理解从 “文档认知” 变成 “实操认知”。
1. 元服务卡片：从 “静态死数据” 到 “动态适配”
项目初期，我用 DevEco Studio 创建了第一个元服务工程，在 FormAbility 里写了个简单的卡片布局：顶部显示 WiFi 名称，中间是二维码，底部加个 “刷新” 按钮。但测试时发现致命问题：卡片上的 WiFi 信息是写死在代码里的，换个 WiFi 环境就失效，完全不具备实用性。
要实现动态更新，就得解决两个问题：一是获取当前连接的 WiFi 信息，二是让卡片实时同步数据。获取 WiFi 信息需要申请权限，早期鸿蒙的权限管理还比较严格，我在 config.json 里配置了 “ohos.permission.GET_WIFI_INFO” 权限后，却发现首次启动时权限申请弹窗不弹出。翻遍开发者论坛才知道，元服务的权限申请需要在 FormAbility 的 onCreate 阶段主动调用 requestPermissions 接口，而不是像全屏应用那样自动触发。
解决权限问题后，又遇到卡片数据同步的难题。元服务卡片默认是缓存渲染的，即使本地 WiFi 信息变了，卡片也不会自动刷新。我尝试用 FormProvider 的 updateForm 接口，在 WiFi 信息变化时主动更新卡片内容。但怎么监测 WiFi 变化呢？通过注册 WiFiEventReceiver 广播接收器，监听网络连接状态变化，当检测到 WiFi 重新连接时，就重新获取 SSID 和密码，再调用 updateForm 接口刷新卡片。这样一来，卡片就从 “静态模板” 变成了 “动态适配当前环境” 的实用工具。
2. App Linking 配置：让 “碰一碰” 唤醒元服务
实现卡片动态显示后，下一个目标是 “碰一碰分享”—— 两台鸿蒙设备靠近时，分享方触发分享，接收方直接弹出元服务卡片。这个流程的核心是 App Linking 的关联配置，也是早期开发最容易踩坑的地方。
首先在 AGC 控制台创建 App Linking，定义了一个深度链接。但最初测试时，发送方触发分享后，接收方只是跳转到浏览器打开链接，并没有唤醒元服务。后来才发现，需要在 AGC 的 “应用关联” 模块里，将 App Linking 与元服务的 Form ID 绑定，同时在应用的 module.json5 文件中配置 skills 节点，指定该链接对应的 Action 为 “action.system.open”，Entities 为 “entity.system.browsable”，这样系统才能识别到这个链接需要唤醒元服务而非打开浏览器。
另一个关键是参数传递 —— 分享时必须把 WiFi 的 SSID 和密码携带到接收方。我将链接改造为 “XXX?ssid=MyHomeWiFi&pwd=Test123456”，但直接明文传递密码存在安全风险。于是用 Base64 对密码进行加密，接收方解析后再解密。
在代码层面，接收方需要在 EntryAbility 的 onCreate 方法中，从 want 参数里获取 uri，解析出 query 参数后解密，再存入 AppStorage，供元服务卡片读取显示。这段解析代码看似简单，却因为早期鸿蒙的 URL 解析 API 不支持中文 SSID，导致中文 WiFi 名称出现乱码。最终通过 URLEncoder 编码和解码，才解决了中文适配问题。
3. 分布式软总线：实现 “碰一碰” 的近距离触发
“碰一碰” 的物理触发，依赖鸿蒙的分布式软总线能力。我在分享方的元服务卡片上添加了一个 “碰一碰分享” 按钮，点击后调用分布式软总线的 publishData 接口，将加密后的 App Linking 通过近距离通信发送给周边设备。接收方通过 subscribeData 接口监听总线数据，收到数据后解析出 App Linking，再调用 startAbilityWithWant 方法唤醒元服务。
测试时发现，两台设备距离超过 10 厘米就无法触发通信，后来调整了分布式软总线的通信参数，将信号强度阈值降低，同时优化了数据发送的重试机制，确保近距离内稳定传输。这样就实现了完整的 “点击分享 - 碰一碰 - 接收方弹出卡片” 流程，接收方无需安装任何应用，就能直接看到 WiFi 二维码。
三、核心代码解析：接收方唤醒元服务的关键逻辑
以下代码是接收方解析 App Linking 并唤醒元服务的核心逻辑，包含了 URL 解析、密码解密和元服务唤醒三个关键步骤，也是整个项目最核心的技术实现部分。
export default class MainAbility extends EntryAbility {
onCreate(want: Want, launchParam: AbilityConstant.LaunchParam) {
hilog.info(0x0000, 'WiFiShare', 'MainAbility onCreate');
// 关键：判断是否通过App Linking唤醒
if (want.uri) {
this.handleAppLinking(want.uri);
}
}
// 处理App Linking链接，解析WiFi信息并唤醒元服务
private async handleAppLinking(uri: string) {
try {
// 1. 解析URL中的参数（处理中文SSID编码问题）
const decodedUri = decodeURIComponent(uri);
const urlObj = new URL(decodedUri);
const ssid = urlObj.searchParams.get('ssid');
const encryptedPwd = urlObj.searchParams.get('pwd');
if (!ssid || !encryptedPwd) {
hilog.error(0x0000, 'WiFiShare', '参数缺失：ssid或pwd为空');
return;
}
// 2. Base64解密密码（解决明文传输安全问题）
const decoder = new util.Base64Decoder();
const pwdBytes = decoder.decodeSync(encryptedPwd);
const password = util.TextDecoder.create('utf-8').decode(pwdBytes);
hilog.info(0x0000, 'WiFiShare', `解析成功 - SSID: ${ssid}, 密码: ${password}`);
// 3. 将WiFi信息存入AppStorage，供元服务卡片读取
AppStorage.SetOrCreate('sharedSsid', ssid);
AppStorage.SetOrCreate('sharedPassword', password);
// 4. 唤醒元服务卡片（指定Form ID）
this.launchMetaService();
} catch (error) {
hilog.error(0x0000, 'WiFiShare', `解析App Linking失败: ${JSON.stringify(error)}`);
}
}
// 唤醒元服务卡片
private launchMetaService() {
const formWant: Want = {
deviceId: '', // 空表示当前设备
bundleName: 'com.demo.wifishare',
abilityName: 'com.demo.wifishare.FormAbility',
parameters: {
'formId': '10001', // 元服务卡片的Form ID
'formType': '1' // 1表示临时卡片
}
};
// 调用元服务启动接口
this.context.startAbility(formWant, (err) => {
if (err) {
hilog.error(0x0000, 'WiFiShare', `启动元服务失败: ${JSON.stringify(err)}`);
return;
}
hilog.info(0x0000, 'WiFiShare', '元服务卡片启动成功');
});
}
}
这段代码是接收方处理分享的核心流程。首先在 onCreate 方法中判断是否由 App Linking 唤醒，若存在 uri 则调用 handleAppLinking 方法解析；解析过程中先处理中文编码问题，再通过 Base64 解密密码，确保数据传输安全；最后将 WiFi 信息存入 AppStorage，并通过 startAbility 接口唤醒元服务卡片，实现 “接收即显示” 的无缝体验。
代码中加入了详细的日志打印和异常处理，这是早期调试鸿蒙应用时必不可少的习惯，能快速定位参数解析或卡片启动失败的问题。
四、体验复盘与生态思考：鸿蒙的 “轻” 与 “联”
这个 WiFi 密码分享器，虽然只是个实验性项目，却让我在鸿蒙生态早期就摸到了其核心竞争力 ——“轻” 与 “联” 的结合。“轻” 体现在元服务无需安装的轻量化形态，降低了用户使用门槛；“联” 则通过 App Linking 和分布式软总线，实现了设备间的无缝信息流转。在两台鸿蒙测试机上完成首次 “碰一碰” 分享时，接收方瞬间弹出包含 WiFi 二维码的卡片，那种无需繁琐操作的流畅感，让我真切感受到了分布式技术的价值。
从开发者视角来看，早期鸿蒙开发虽然有文档不完善、API 不稳定的问题，但官方提供的 AGC 控制台和 DevEco Studio 调试工具，很大程度上降低了探索成本。比如通过 AGC 的 App Linking 调试功能，能实时查看链接的触发日志，快速定位关联配置问题；DevEco Studio 的 Form 预览器，让元服务卡片的布局调试无需频繁打包安装。这些工具层面的支撑，让开发者能更专注于能力组合而非环境配置。
这个项目也让我对鸿蒙生态的未来有了更具体的认知：它的竞争力不在于替代某个系统，而在于通过元服务、分布式软总线等能力，重构 “服务触达用户” 的方式。就像这个 WiFi 分享工具，它没有做复杂的功能，却通过鸿蒙特性解决了传统方案的痛点。对开发者而言，鸿蒙开发的核心不是学习新的语法，而是转变思维 —— 从 “开发应用” 转变为 “设计场景化服务”，用轻量化的载体和无缝的连接，让服务在需要时自然出现。
这次探索让我积累了元服务和分布式能力的实战经验，也为后续参与公司的鸿蒙项目打下了基础。对我而言，这正是技术探索的意义：在未成熟的领域里踩坑、复盘，最终摸清技术的核心逻辑，等到生态爆发时，才能快速抓住机会。
4.2 HarmonyOS 6 新启程
近日，华为正式发布了新一代鸿蒙操作系统 HarmonyOS 6 。新系统在性能、智能体验、安全防护以及跨设备协同方面都带来了显著提升。
回想我开发那个 WiFi 密码分享器元服务的经历，当时最深的感触是：鸿蒙的 “元服务” 和 “应用关联” 像两颗璀璨但略显孤立的珍珠，而 HarmonyOS 6 的发布，仿佛为它们提供了一条更坚固的 “项链”。新闻中提及的 “星河互联架构” 和 “一碰多分享”，正是对我当时所依赖的分布式能力的一次全面升级。这意味着，未来我不仅能让用户 “碰一碰” 分享 WiFi，甚至可以想象，在会议室里，多人 “碰一碰” 就能瞬间组网并同步会议议程，这种跨设备协同的潜力被极大地拓宽了。
更让我感到兴奋的是 “应用智能体” 的规模化上线。在我之前的开发中，元服务卡片更多是静态或简单动态的信息展示。而现在，HarmonyOS 6 让小艺和这些智能体能够深度理解场景并主动服务。这让我不禁思考：我那个 WiFi 分享器，能否在下次迭代中进化为一个 “场景智能体”？当它感知到家里来了新客人，不仅能弹出分享卡片，还能联动智能家居，主动询问 “是否要为您同步播放客厅的音乐列表”？这种从 “工具” 到 “智能伙伴” 的进化，正是 HarmonyOS 6 为我描绘出的全新可能性。
