作為常年泡在技術社區的開發者，我對新系統的評判標準向來很直接：能否解決真實場景的痛點。鴻蒙系統問世初期，我沒有跟風追逐“分佈式架構”的宏大概念，而是被其“輕量化服務觸達”的理念吸引。於是，我把第一個鴻蒙實戰項目鎖定在一個高頻生活場景——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為我描繪出的全新可能性。
