我是一名后端開發(fā)愛好者，工作日常接觸到最多的就是Java語言啦，所以我都盡量抽業(yè)余時(shí)間把自己所學(xué)到所會的，通過文章的形式進(jìn)行輸出，希望以這種方式幫助到更多的初學(xué)者或者想入門的小伙伴們，同時(shí)也能對自己的技術(shù)進(jìn)行沉淀，加以復(fù)盤，查缺補(bǔ)漏。
第一章：序章：靈感的火花與賽道的抉擇
1.1 參賽初心：當(dāng)“開發(fā)者”遇上“博物館迷”
2024 年末，當(dāng) HarmonyOS 創(chuàng)新賽的號角吹響時(shí)，我們團(tuán)隊(duì)正沉浸在 ArkTS 和聲明式 UI 的學(xué)習(xí)熱情中。我們既是開發(fā)者，也是一群博物館愛好者。我們熱愛歷史的厚重，卻也時(shí)常為當(dāng)下博物館的導(dǎo)覽體驗(yàn)感到“抓狂”。
“星光”為引，鴻蒙聚能。這次大賽不僅僅是技術(shù)的比拼，更是尋找“用鴻蒙技術(shù)解決實(shí)際問題”的絕佳舞臺。我們當(dāng)即一拍即合：參賽！
1.2 傳統(tǒng)導(dǎo)覽的“三大痛點(diǎn)”
我們的靈感，源于一次次在博物館中的“糟糕體驗(yàn)”：
1. “掃碼”的割裂感：走到一個(gè)展品前，掏出手機(jī)，解鎖，打開微信/App，對焦那個(gè)反光的、貼在角落的二維碼，等待加載… 這一套流程下來，與文物的“精神交流”早已被徹底打斷。
2. “租導(dǎo)覽器”的笨重：租用實(shí)體導(dǎo)覽器，不僅需要押金，設(shè)備老舊、音質(zhì)差，而且無法提供圖文、視頻等多媒體的沉浸式體驗(yàn)。
3. “藍(lán)牙 Beacon”的不精準(zhǔn)：部分博物館嘗試過藍(lán)牙 iBeacon 方案，但信號“漂移”問題嚴(yán)重，常常是人站在 A 展品前，手機(jī)卻在推送 B 展品的信息，體驗(yàn)極差。
這些痛點(diǎn)，讓我們看到了一個(gè)明確的突破口：我們能否創(chuàng)造一種“無感”的、“即時(shí)”的、“精準(zhǔn)”的導(dǎo)覽體驗(yàn)？
1.3 “智游文博”的誕生：一個(gè)“碰一碰”的構(gòu)想
我們把目光投向了 HarmonyOS。如果說其他系統(tǒng)是在“App”的圍墻花園里做優(yōu)化，那么鴻蒙從誕生之初，就在思考如何“拆掉圍墻”，讓服務(wù)“流”起來。
我們的“Aha!”時(shí)刻不期而至：
· 如果，我們用 NFC 標(biāo)簽代替二維碼呢？
· 如果，用戶手機(jī)“碰一碰”標(biāo)簽，不是打開一個(gè)笨重的 App，而是“秒出”一張輕盈的服務(wù)卡片呢？
· 如果，用戶在卡片上意猶未盡，點(diǎn)擊“詳情”，又能“無縫”流入 App 的深度體驗(yàn)（如 3D 模型、AR 互動）呢？
這個(gè) “碰一碰（NFC）-> 秒出卡片（元服務(wù)）-> 詳情流轉(zhuǎn)（AppLinking）” 的構(gòu)想，讓我們所有人興奮不已。它幾乎完美契合了 HarmonyOS“原子化服務(wù)”和“無縫流轉(zhuǎn)”的核心理念。這不僅是一個(gè)參賽作品，更是一個(gè)真正能提升用戶體驗(yàn)的解決方案。
1.4 我們的技術(shù)藍(lán)圖與團(tuán)隊(duì)分工“智游文博 (Smart Museum Tour)”項(xiàng)目正式立項(xiàng)。我們的目標(biāo)非常明確：打造基于 HarmonyOS 近場能力的極致導(dǎo)覽體驗(yàn)。
團(tuán)隊(duì)分工如下：
· 我（組長/架構(gòu)）：負(fù)責(zé)整體架構(gòu)設(shè)計(jì)，主攻 NFC 與元服務(wù)的技術(shù)預(yù)研和實(shí)現(xiàn)。
· 小A (ArkUI 專家)：負(fù)責(zé)主 App 和元服務(wù)卡片的 UI/UX 設(shè)計(jì)與實(shí)現(xiàn)，確保多端適配。
· 小B (后端/云開發(fā))：負(fù)責(zé)（模擬的）博物館展品數(shù)據(jù)庫，以及 AppLinking、APMS 等開放能力的后臺配置與聯(lián)調(diào)。
我們的征途，就從最核心的“第一觸點(diǎn)”—— NFC 開始。
第二章：萬物互聯(lián)的“第一觸點(diǎn)”：NFC 近場通信深度實(shí)踐
這是我們的第一個(gè)技術(shù)難關(guān)，也是我們方案的基石。如果“碰一碰”的體驗(yàn)做不好，后續(xù)的一切都無從談起。
2.1 為什么是 NFC？—— 我們的技術(shù)選型思考
在答辯中，評委一定會問：為什么是 NFC，而不是更廉價(jià)的二維碼？
我們的答案是：體驗(yàn)的“質(zhì)變”。
NFC 帶來的“主動”與“即時(shí)”的魔法感，是二維碼永遠(yuǎn)無法比擬的。我們堅(jiān)信，這是未來場景交互的方向。
2.2 HarmonyOS NFC 基礎(chǔ)：從配置到權(quán)限
要在 HarmonyOS 上玩轉(zhuǎn) NFC，首先必須搞定配置。
步驟 1：聲明權(quán)限
在 entry/src/main/module.json5 文件中，我們必須聲明 NFC 相關(guān)的權(quán)限：
步驟 2：配置 TechIDs關(guān)鍵)
NFC 標(biāo)簽有很多種技術(shù)標(biāo)準(zhǔn)（如 Ndef, IsoDep, NfcA/B/F/V 等）。我們必須告訴系統(tǒng)，我們的應(yīng)用關(guān)心哪些類型的標(biāo)簽。這同樣在 module.json5 中配置。
2.3 實(shí)戰(zhàn)：NFC 標(biāo)簽的“初始化”—— 寫入展品 ID
在博物館“布展”時(shí)，我們需要先給每個(gè)展品旁的空白 NFC 標(biāo)簽寫入信息。我們開發(fā)了一個(gè)內(nèi)部管理功能來實(shí)現(xiàn)這一點(diǎn)。
關(guān)鍵設(shè)計(jì)：我們沒有寫入“展品名稱”或“介紹”等大數(shù)據(jù)，而是只寫入了一個(gè)小巧的、指向性的 URI：smartmuseum://exhibit?id=123。這極大提高了寫入速度和讀取效率。
2.4 實(shí)戰(zhàn)：捕獲 TAG_DISCOVERED 并解析數(shù)據(jù)
當(dāng)用戶手機(jī)“碰”到這個(gè)標(biāo)簽時(shí)，系統(tǒng)會發(fā)出一個(gè) Want，我們的應(yīng)用需要捕獲它并解析。
這部分邏輯通常寫在 EntryAbility 的 onNewWant 生命周期中，因?yàn)榇藭r(shí) App 可能已經(jīng)啟動。
2.5 踩坑與調(diào)試：NFC 的“靈”與“不靈”
這是我們參賽過程中耗時(shí)最長的階段之一：
· 坑 1：機(jī)容性。我們發(fā)現(xiàn)，不同型號的華為手機(jī)，NFC 感應(yīng)區(qū)域（背部）不完全一致。我們必須在 demo 視頻里明確演示“正確”的觸碰姿勢。
· 坑 2：onNewWant 不觸發(fā)。調(diào)試了很久，發(fā)現(xiàn) module.json5 里的 techList 沒配對。我們買的標(biāo)簽是 NfcA + Ndef，但一開始只配了 Ndef，導(dǎo)致系統(tǒng)在底層就給過濾了。
· 坑 3：讀寫沖突。在開發(fā)“寫入”功能時(shí)，如果寫入失敗，標(biāo)簽可能會“鎖死”或進(jìn)入一個(gè)奇怪的狀態(tài)，導(dǎo)致后續(xù)讀取也失敗。解決方案：每次 connect() 之后，必須保證 close() 被調(diào)用，即使在 catch 塊中也要處理。
攻克了 NFC，我們就打通了“人”與“物”的連接。下一步，是優(yōu)化這個(gè)連接的“反饋”。
第三章：體驗(yàn)的飛從“打開App”到“服務(wù)直達(dá)”（元服務(wù)篇）
這是我們方案的第一個(gè)**“關(guān)鍵獲獎點(diǎn)”**。傳統(tǒng)方案（包括微信小程序）在NFC“碰一碰”后，無論如何都要加載一個(gè)“頁面”。而我們要做的，是“卡片”。
3.1 獲獎點(diǎn)（一）：打破“App孤島”，實(shí)現(xiàn)“即碰即看”
我們的核心理念是：用戶 90% 的需求只是想“看一眼”展品簡介。為了這 90% 的需求，去加載一個(gè) 10% 才會用到的完整 App（帶 3D 模型、AR 功能）是極大的性能浪費(fèi)。
務(wù)（服務(wù)卡片） 是完美的解決方案。它輕量、免安裝、可數(shù)據(jù)驅(qū)動，是承載“驚鴻一瞥”信息的最佳形態(tài)。
3.2 元服務(wù) (Widget) 架構(gòu)設(shè)計(jì)
我們創(chuàng)建了一個(gè) WidgetExtensionAbility，專門用于處理和展示展品信息的卡片。
步驟 1：創(chuàng)建 WidgetExtensionAbility
在 entry 模塊上右鍵 -> New -> Ability -> WidgetExtensionAbility。我們將其命名為 ExhibitWidgetAbility。
步驟 2：配置 form_config.json
在 resources/base/profile/form_config.json 中，我們定義卡片的屬性：
步驟 3：編寫卡片 UI
卡片 UI (ExhibitWidgetCard.ts) 必須簡潔明了。
這是我們方案中最具技巧性的部分。NFC 默認(rèn)是拉起 App (EntryAbility) 的，我們?nèi)绾巫屗稗D(zhuǎn)而”拉起卡片呢？
我們沒有（也不能）直接拉起卡片。
我們的流程是：
1. NFC 依然拉起 EntryAbility (或一個(gè)專門的后臺 ServiceAbility)。
2. EntryAbility 在 onNewWant 中解析出展品 ID。
3. EntryAbility 立即請求系統(tǒng)并顯示一個(gè)臨時(shí)卡片。
4. EntryAbility 獲取展品數(shù)據(jù)，并更新這個(gè)卡片。
通過這套“NFC -> EntryAbility (后臺處理) -> formManager.requestForm (臨時(shí)卡片) -> formProvider.updateForm異步更新) ”的組合拳，我們完美實(shí)現(xiàn)了“即碰即看”的絲滑體驗(yàn)。用戶在碰觸后，桌面會立刻彈出一個(gè)“加載中”的卡片，0.5 秒后數(shù)據(jù)刷新，體驗(yàn)遠(yuǎn)勝于等待 App 啟動。
卡片解決了“淺層需求”，但對于想深入了解（如查看 3D 模型、AR 互動）的用戶，我們必須提供一條“無縫”的路徑流入主 App。
4.1 獲獎點(diǎn)（二）：從“卡片”到“應(yīng)用”的絲滑銜接
如果用戶在卡片上點(diǎn)擊“查看詳情”，我們拉起了 App 首頁，讓用戶自己去列表里找這個(gè)展品，那體驗(yàn)無疑是災(zāi)難性的。
我們必須做到：卡片 -> 拉起 App -> 精準(zhǔn)進(jìn)入該展品的詳情頁。
這就是 AppLinking 的用武之地。它是一個(gè)跨平臺的深度鏈接服務(wù)，能幫我們生成一個(gè)鏈接，無論用戶是否安裝了 App，都能被智能地引導(dǎo)。
4.2 AppLinking 詳解：它解決了什么？
AppLinking 解決了“服務(wù)流轉(zhuǎn)”的“尋址”問題。它提供了一個(gè)統(tǒng)一的 URL，后臺會自動處理：
· 已安裝 App：直接拉起 App，并傳遞參數(shù)。
· 未安裝 App：引導(dǎo)至 AppGallery 下載，下載安裝后首次啟動時(shí)，依然能傳遞參數(shù)。
4.3 實(shí)戰(zhàn)：配置 AppLinking 鏈接
這是小B同學(xué)（負(fù)責(zé)后臺）的工作，但作為參賽者都必須了解。
1. 開通服務(wù)：在 AppGallery Connect (AGC) 中，為我們的“智游文博”項(xiàng)目開通“App Linking”服務(wù)。
2. 配置 URL 前綴：AGC 會分配給我們一個(gè)短鏈域名，例如 smartmuseum.agconnect.link。
3. 創(chuàng)建 AppLinking：
短：系統(tǒng)自動生成（或自定義）。
深度鏈接 (Deep Link)：這是關(guān)鍵。我們指定一個(gè) App 能識別的 URI，例如：smartmuseum://details。
安卓/鴻蒙參數(shù)：設(shè)置我們的包名 com.example.smartmuseum，以及啟動的 Activity(在鴻蒙上即EntryAbility`)。
回退行為：如果未安裝，跳轉(zhuǎn)到我們的 AppGallery 詳情頁。
4. 最終形態(tài)：我們創(chuàng)建了一個(gè)鏈接，它會根據(jù)參數(shù)動態(tài)變化，例如：
https://smartmuseum.agconnect.link/open?exhibitId=123
這個(gè)鏈接，會最終被解析為 smartmuseum://details?exhibitId=123 并傳遞給我們的 App。
4.4 實(shí)戰(zhàn)：卡片按鈕的終極形態(tài)
現(xiàn)在，我們回到 ExhibitWidgetCard.ets，給那個(gè)“查看詳情”按鈕賦予靈魂。
注意：卡片是一個(gè)獨(dú)立的 FormExtension 進(jìn)程，它使用 router.pushUrl 時(shí)，會向系統(tǒng)發(fā)出一個(gè) Want。系統(tǒng)中的 AppLinking 服務(wù)會攔截這個(gè) URL，解析它，然后構(gòu)建一個(gè)新的 Want 來拉起我們的 EntryAbility。
4.5 實(shí)戰(zhàn)：主應(yīng)用 (EntryAbility) 接收與解析 AppLinking
最后一步。用戶點(diǎn)擊卡片按鈕后，EntryAbility 會被再次喚醒，我們又回到了 onNewWant。
至此，我們的核心獲獎鏈路 “碰一碰（NFC）-> 秒出卡片（元服務(wù)）-> 詳情（AppLinking）” 全部打通！這套組合拳，為評委們呈現(xiàn)了一個(gè)兼具“魔法感”和“實(shí)用性”的完美閉環(huán)。
功能跑通了，但我們離“金獎”還差最后一步——性能。
5.1 遭遇瓶頸：評委面前，卡頓是“原罪”
在賽前內(nèi)測時(shí)，我們發(fā)現(xiàn)了兩個(gè)致命問題：
1. 卡片慢：NFC 碰觸后，卡片有時(shí)要 2-3 秒才彈出，有時(shí)甚至?xí)?ANR (應(yīng)用無響應(yīng))。
2. App 冷啟動慢：從卡片點(diǎn)擊“詳情”拉起主 App 時(shí)，白屏?xí)r間過長，超過了 3 秒。
在創(chuàng)新賽這種“一分鐘定勝負(fù)”的答辯上，任何一次卡頓都是“原罪”。我們必須解決它。
5.2 引入“鴻蒙開放能力”：APMS
我們引入了華為提供的“APMS (應(yīng)用性能管理服務(wù))”。它就像一個(gè)隨身的“性能醫(yī)生”，可以幫我們非侵入式地監(jiān)控和分析應(yīng)用的性能。
我們集成了 APMS SDK，并在 AGC 后臺打開了“性能分析”。
5.3 案例分析（一）：定位“卡片加載慢” (ANR)
APMS 的 ANR 監(jiān)控很快上報(bào)了問題。
1. 問題定位：通過 ANR 報(bào)告的堆棧，我們震驚震驚地發(fā)現(xiàn)，問題出在 EntryAbility 的 onNewWant 方法里。
2. 錯(cuò)誤原因：onNewWant行在主線程。我們調(diào)用的 processNfcWant 方法中，包含了 ndefTag.connect() 和 ndefTag.readNdefessage() 這兩個(gè) I/O 操作。當(dāng) NFC 標(biāo)簽接觸不良或數(shù)據(jù)較大時(shí)，這兩個(gè)方法可能會阻塞主線程超過 500 毫秒，引發(fā) ANR！
解決方案：萬物皆可異步！
我們必須將所有 I/O 操作移出主線程。
調(diào)優(yōu)成果：修改后，onNewWant 瞬間執(zhí)行完畢。NFC 碰觸后，App 主線程毫無壓力，卡片彈出的 ANR 問題徹底解決。
5.4 案例分析（二）：定位“主應(yīng)用冷啟動慢”
APMS 的“應(yīng)用啟動”分析報(bào)告了“冷啟動耗時(shí)過長”。
· 問題定位：報(bào)告顯示，EntryAbility 的 onCreate 方法耗時(shí)高達(dá) 1.5 秒。
· 錯(cuò)誤原因：我們在 onCreate 里“好心”地做了太多初始化：初始化數(shù)據(jù)庫、加載全部房間和展品列表、初始化 3D 渲染引擎、初始化 AR SDK…
· 解決方案：載（Lazy Initialization）。onCreate 只做最輕量級的、必需的初始化。
調(diào)優(yōu)成果：通過懶加載，onCreate 的耗時(shí)從 1.5 秒降到了 0.2 秒。配合 AppLinking 的精準(zhǔn)跳轉(zhuǎn)，用戶從點(diǎn)擊卡片到進(jìn)入詳情頁的冷啟動時(shí)間縮短到 1 秒內(nèi)，體驗(yàn)大幅提升。
在最終答辯時(shí)，我們自豪地展示了 APMS 的“優(yōu)化前后”對比圖，這成為了評委給出“工程質(zhì)量分”的重要依據(jù)。
第六章：總結(jié)與致謝：星途探索，永不止步
6.1 我們的“獲獎密碼”復(fù)盤
如今回看，“智游文博”能獲得評委的青睞，我想我們的“獲獎密碼”可以總結(jié)為三點(diǎn)：
1. 精準(zhǔn)的場景切入：我們沒有做“大而全”的應(yīng)用，而是聚焦于“博物館導(dǎo)覽”這一個(gè)垂直場景的“核心痛點(diǎn)”。
2. “鴻蒙原生思維：我們沒有把鴻蒙當(dāng)成另一個(gè)“安卓”，而是從立項(xiàng)之初就思考如何利用其“原子化”和“流轉(zhuǎn)”的特性。我們方案的核心，不是 App，而是“服務(wù)”。
3. 技術(shù)鏈的完美閉環(huán)：我們打通了 NFC（輸入）-> 元服務(wù)（輕反饋）-> AppLinking（重反饋） 的全鏈路，并用 APMS（） 保證了體驗(yàn)的極致。這是一個(gè)完整且優(yōu)雅的鴻蒙解決方案。
6.2 參賽的最大收獲：從“App開發(fā)者”到“場景設(shè)計(jì)師”
這次 HarmonyOS 創(chuàng)新賽，帶給我們的不僅是獎項(xiàng)的榮譽(yù)，更是開發(fā)思維的徹底重塑。
我們不再僅僅思考“這個(gè)頁面怎么畫”，而是開始思考“這個(gè)服務(wù)應(yīng)該在何時(shí)、以何種形態(tài)（卡片/App/語音在哪個(gè)設(shè)備上被觸發(fā)”。我們從一個(gè)“App 開發(fā)者”，真正開始轉(zhuǎn)變?yōu)橐粋€(gè)“全場景服務(wù)的設(shè)計(jì)師”。
6.3 感恩與致謝
星光不負(fù)趕路人。感謝 CSDN 和華為搭建的“星光”平臺，讓我們有機(jī)會將奇思妙想付諸實(shí)踐；感謝我的隊(duì)友小 A 和小 B，是無數(shù)個(gè)深夜的聯(lián)調(diào)和爭論，才打磨出了“智游文博”；更要感謝鴻蒙生態(tài)，是它提供的強(qiáng)大技術(shù)底座，讓我們得以站在巨人的肩膀上，去構(gòu)想下一個(gè)時(shí)代的交互。
6.4 展望未來
“智游文博”的故事還遠(yuǎn)未結(jié)束。未來，我們計(jì)劃引入 AR 能力，當(dāng)用戶通過 AppLinking 進(jìn)入詳情頁后，可以直接開啟 AR 模式，讓文物“活”在手機(jī)屏幕上。
我們的“星途探索”才剛剛開始。希望我們的這點(diǎn)參賽心得，能為后來者提供一點(diǎn)微光，激勵(lì)更多開發(fā)者加入鴻蒙生態(tài)，共同用技術(shù)點(diǎn)亮全場景的未來?。ㄞD(zhuǎn)載自CSDN，作者：喵手）
