做 Flutter 鴻蒙化適配的團隊十有八九會在一個意想不到的地方停下來不是原生橋接也不是渲染適配而是測試跑不過去。我們當(dāng)時把整個 Flutter 模塊遷到鴻蒙環(huán)境后第一輪本地用例直接紅了一片報錯都集中在package:matcher的引用、expect的異常拋出時機、以及異步斷言的行為差異上。那一刻我才意識到matcher 這個看似不起眼的三方庫實際上已經(jīng)成為端側(cè)質(zhì)量驗證的底層契約層。這篇我就把整個適配過程、核心拆解和踩坑記錄完整寫出來給正在做鴻蒙化改造、或者準(zhǔn)備把 Dart 測試體系搬到鴻蒙設(shè)備的團隊一個可復(fù)用的參考。matcher 的價值不只在斷言失敗時給出提示這么簡單。它提供的語義化斷言能力、可組合的匹配器抽象、以及自定義匹配算法的擴展機制本質(zhì)上是一套測試契約框架被測對象該滿足什么語義、不滿足時該呈現(xiàn)什么錯誤信息、復(fù)雜業(yè)務(wù)規(guī)則該怎么組織都由它統(tǒng)一承載。鴻蒙化適配要做的不是簡單地把包從 pub.dev 引進來而是讓這套契約框架在新的引擎環(huán)境、新的日志鏈路、新的生命周期模型下仍然保持原有的表達力和穩(wěn)定性。1. 適配這件事的起點matcher 在端側(cè)測試中到底承擔(dān)了什么1.1 為什么一個斷言庫值得單獨做一輪專項先說個背景。我們當(dāng)時的目標(biāo)是把一套基于 Flutter 的業(yè)務(wù)模塊平移到鴻蒙設(shè)備上涉及頁面渲染、數(shù)據(jù)層、平臺通道三塊。第一輪驗證時用的是鴻蒙 Flutter 引擎對應(yīng)的 SDK 分支跑flutter test本地用例很快就崩了。定位后發(fā)現(xiàn)并不是業(yè)務(wù)邏輯的問題而是測試基建本身沒有跟著環(huán)境走matcher是 Dart 生態(tài)里最基礎(chǔ)的斷言庫flutter_test底層大量依賴它一旦這個依賴鏈在鴻蒙環(huán)境里行為不一致上游所有用例全部癱瘓。matcher 表面上只是提供一組函數(shù)但它撐起了測試語義的三個核心能力。第一是語義化斷言你寫的不是if (a b) return false而是expect(result, equals(expected))、expect(stream, emitsInOrder([...]))斷言意圖直接從代碼里讀出來。第二是自定義匹配算法官方匹配器不夠用時可以實現(xiàn)自己的Matcher子類把復(fù)雜業(yè)務(wù)規(guī)則封裝成可復(fù)用的斷言單元。第三是錯誤信息契約匹配失敗時 matcher 會調(diào)用describe和describeMismatch生成人類可讀的失敗描述理想情況下開發(fā)者拿著這段描述就能直接定位問題不需要重新調(diào)試一遍。這三件事在普通 Dart 環(huán)境里已經(jīng)驗證過無數(shù)次但鴻蒙化之后每一件都可能變形異常類型在裁剪版引擎里可能被吞掉、異步斷言的事件循環(huán)時序不同、日志輸出通道和標(biāo)準(zhǔn)還不太一樣。如果不做專項適配整套測試契約等于在鴻蒙端是失效的。1.2 鴻蒙化適配不是換包名而是重建測試契約鏈路很多人對三方庫鴻蒙化有一個誤解覺得純 Dart 庫只要代碼能編譯進去就等于適配完成。這個說法對純計算類邏輯基本成立但對測試庫并不成立。測試庫真正依賴的不是語言本身而是運行時環(huán)境提供的一系列外部約定異常怎么拋、日志怎么打、時間片怎么調(diào)度、失敗現(xiàn)場怎么采集。鴻蒙的 Flutter 引擎是一套獨立構(gòu)建的運行時這些約定和標(biāo)準(zhǔn) Flutter 有差異甚至有缺失。舉例來說expect斷言失敗時默認會拋出TestFailure上層測試框架捕獲它來標(biāo)記用例失敗。但鴻蒙端如果走 release 裁剪路徑Dart 異常對象的部分元信息可能被壓縮TestFailure的堆棧和 message 會變得不完整。再比如異步斷言expectLater它依賴Future的完成順序而鴻蒙上多 isolate 和主事件循環(huán)的協(xié)作方式和標(biāo)準(zhǔn)實現(xiàn)存在細微差別直接跑原有的異步用例可能不穩(wěn)定。所以整個適配工作要分四層依賴接入、斷言語義保持、自定義匹配算法移植、端側(cè)結(jié)果橋接。每一層都不是孤立的比如你定義了漂亮的自定義匹配器最終失敗信息如果到不了鴻蒙原生側(cè)的日志系統(tǒng)那這個匹配器對端側(cè)質(zhì)量驗證就沒有實際意義。這也是我后來堅持把它叫作測試契約框架的原因——你要重建的是從斷言語義到驗證報告之間的整條鏈路。2. 鴻蒙工程的依賴接入與數(shù)據(jù)類型差異盤點2.1 依賴接入的兩種可靠路徑說句實話鴻蒙 Flutter 工程在依賴管理上比標(biāo)準(zhǔn) Flutter 要敏感得多。由于鴻蒙端使用的 Flutter 引擎分支通常有自己配套的 Dart SDK 和 package 解析規(guī)則直接從 pub.dev 拉最新版 matcher 并不是最穩(wěn)的選擇。我們實際驗證下來比較可靠的是下面兩條路徑。第一條是把依賴改為本地工程引用。把 matcher 源碼連同其最小依賴鏈test_api、meta等放進工程內(nèi)第三方目錄然后在pubspec.yaml里用dependency_overrides強制指向本地路徑配合flutter pub get --offline解析。好處是版本完全可控不受遠端倉庫網(wǎng)絡(luò)或解析策略影響缺點是升級時需要手動同步源碼本質(zhì)上是把三方庫納管進自己的倉庫了。第二條是利用 pub 的 git 依賴能力指向一個已經(jīng)驗證過的版本 tag。這個方式適合團隊內(nèi)部維護的公共倉庫CI 構(gòu)建時可以直接拉取。我當(dāng)時優(yōu)先選了第一條原因很簡單鴻蒙項目通常有內(nèi)網(wǎng)構(gòu)建和合規(guī)要求離線化依賴樹是最穩(wěn)妥的不會出現(xiàn)某次構(gòu)建時遠端依賴抖動導(dǎo)致全工程不可用的尷尬。無論選哪條路徑有一點必須注意matcher 本身依賴test_api而鴻蒙 Flutter SDK 自身可能也依賴某個特定版本的test_api。版本不一致時輕則靜態(tài)檢查告警重則運行時兩個版本的Matcher類型互不兼容expect會把你自己實現(xiàn)的Matcher子類判定為類型錯誤。這個坑后面第五節(jié)會詳細說。2.2 鴻蒙 Flutter 引擎下數(shù)據(jù)類型與 API 行為差異適配過程中我整理了一張行為差異表這里直接分享出來給后來者省點排查時間。這些差異不是我在文檔里看到的是真實踩出來的。能力項標(biāo)準(zhǔn) Flutter鴻蒙 Flutter 引擎對 matcher 的影響異常堆棧完整性完整保留鏈?zhǔn)蕉褩elease 裁剪后 message 可能截斷TestFailure信息不完整需要額外補充上下文stdout 日志debugPrint/print行為穩(wěn)定需對接 hilog 才會穩(wěn)定輸出測試報告輸出要重定向不能依賴標(biāo)準(zhǔn)輸出定時器調(diào)度主事件循環(huán)按幀調(diào)度真機場景可能受任務(wù)優(yōu)先級影響異步匹配器的輪詢間隔可能被拉長isolate 通信SendPort語義穩(wěn)定偶發(fā)不同 isolate 間對象格式差異分布式用例要謹慎使用 isolate 內(nèi)匹配字符串與正則標(biāo)準(zhǔn) Unicode 處理基本一致但部分裁剪版本 ICU 數(shù)據(jù)不完整中文語義描述和正則匹配建議多打日志驗證這張表想表達的核心意思是matcher 的適配難點不在 Dart 語言層面而在它運行時所依賴的環(huán)境能力上。尤其是日志和調(diào)度這兩塊直接決定了端側(cè)質(zhì)量驗證是否可信。3. 把 expect 的語義化斷言在鴻蒙上跑通核心鏈路拆解3.1 matcher 的斷言三元組與失敗信息鏈matcher 之所以能產(chǎn)生那么清晰的錯誤提示核心在于每個Matcher都被約定實現(xiàn)三個能力matches判斷是否匹配、describe描述匹配器的語義、describeMismatch描述不匹配的具體原因。這三個方法組合起來構(gòu)成了一條完整的失敗信息鏈。舉個例子expect(10, greaterThan(20))失敗時內(nèi)部的工作過程是這樣的expect拿到greaterThan(20)先調(diào)用matches(10, matchState)得到 false然后調(diào)用describe生成a value greater than 20這樣的語義描述再調(diào)用describeMismatch(10, mismatchDescription, matchState, false)生成which is 10這樣的具體差異描述。最終上層把兩段文字拼起來形成一句完整的話。這套機制我在適配時原封不動地保留因為它才是語義化斷言的真正靈魂——斷言失敗后你看到的不是一個false而是一句能直接指導(dǎo)修復(fù)的話。鴻蒙化的關(guān)鍵是把這條信息鏈不改語義地搬過去同時保證它在鴻蒙日志和報告體系里還能讀出來。如果你想完全繞開flutter_test自己搭一個輕量 runner 也是可行的核心就是手動調(diào)用matches并組裝信息鏈。3.2 在鴻蒙上自定義斷言入口四行代碼的輕量 runner如果團隊不想依賴 flutter_test 的完整執(zhí)行器可以做一個極薄的斷言封裝。我在模擬項目X里寫過這樣一個通用的驗證入口import package:matcher/matcher.dart; void contractExpect(String label, dynamic actual, Matcher matcher) { final matchState Object?, Object?{}; if (matcher.matches(actual, matchState)) return; final desc StringDescription(); matcher.describe(desc); final mismatch StringDescription(); matcher.describeMismatch(actual, mismatch, matchState, false); final message [contract:$label] 期望: ${desc.toString()}, 實際: ${mismatch.toString()}; throw TestFailure(message); }這個入口做的事情不多但足夠可靠。它用matcher.matches做核心判斷失敗時調(diào)用兩個描述方法生成完整信息最后拋TestFailure。如果你不希望引入TestFailure的依賴也可以拋普通Exception只是上層捕獲時要按你的約定解析 message。鴻蒙化適配之后這類 runner 最大的價值是可以統(tǒng)一掛接上下文信息。比如在 label 里帶模塊名、用例名、設(shè)備型號一旦失敗報告里直接能看到是哪個契約、在哪種設(shè)備條件下掛了。這個能力對端側(cè)現(xiàn)場排查非常有用。3.3 異步 expectLater 的多線程語義expectLater是 matcher 的異步斷言入口專門用于驗證 Future、Stream 等異步結(jié)果。適配時你會發(fā)現(xiàn)鴻蒙 Flutter 引擎對 Future 的時序處理基本兼容但有兩個細節(jié)需要注意。第一異步斷言里不要依賴expectLater的返回值做額外邏輯鴻蒙引擎下某些實現(xiàn)路徑會把這個 Future 包裝得比預(yù)期更深返回值的完成時機可能落后于斷言本身。第二端側(cè)測試如果涉及 UI 幀同步expectLater的完成時機要放在runAsync或等效的原生異步任務(wù)之后否則斷言會在下一幀渲染前就執(zhí)行拿到的狀態(tài)不穩(wěn)定。我們實際的處理方式是給異步斷言包了一層帶有超時保護的 wrapper約定在 10 秒內(nèi)必須得到結(jié)果超時按失敗處理。這個超時值不是拍腦袋定的是根據(jù)模擬項目X 的啟動鏈路大數(shù)據(jù)量出的中位數(shù)加了三倍標(biāo)準(zhǔn)差能在不影響正常用例的前提下過濾掉偶發(fā)調(diào)度問題。4. 自定義匹配算法的移植與能力擴展4.1 保留語義化斷言的兩層抽象matcher 的擴展機制有個很優(yōu)雅的設(shè)計底層是Matcher接口面向想完全掌握控制權(quán)的場景上層是CustomMatcher面向絕大多數(shù)業(yè)務(wù)封裝場景。CustomMatcher幫你把matches、describe、describeMismatch三個方法里的板式代碼壓縮掉只讓你聚焦在兩個核心點語義的命名以及業(yè)務(wù)特征的提取。為什么推薦用CustomMatcher而不是裸實現(xiàn)Matcher因為它自帶了一個默認的錯誤描述框架。你只需要在featureOf里返回被測對象的業(yè)務(wù)特征再把匹配規(guī)則寫死在構(gòu)造里失敗時CustomMatcher會自動生成形如an object with feature X的描述。這比每次手寫describeMismatch省太多事而且語義表達的一致性更高。移植到鴻蒙上沒有額外成本因為這一層是純 Dart 邏輯和平臺無關(guān)。真正要用心的是匹配算法的設(shè)計本身下面給兩個我們已經(jīng)在端側(cè)用起來的例子。4.2 兩個典型匹配器業(yè)務(wù)模型契約匹配和異步輪詢穩(wěn)定匹配第一個例子是業(yè)務(wù)模型契約匹配。我們有一個業(yè)務(wù)模塊會下發(fā)設(shè)備配置模型測試里需要斷言模型里的能力集是否符合 UI 展示規(guī)則。只比較值相等是不夠的因為模型里還包含順序敏感的能力位圖。于是實現(xiàn)了一個DeviceConfigContract匹配器import package:matcher/matcher.dart; class DeviceConfigContract extends CustomMatcher { DeviceConfigContract() : super(符合設(shè)備配置契約, a contract-compliant device config); override dynamic featureOf(dynamic actual) { if (actual is! MapString, dynamic) return actual; final caps actual[capabilities] as Listdynamic? ?? []; final priority caps.map((c) c[priority] as int).toList(); final sorted Listint.from(priority)..sort(); return priority.join(,) sorted.join(,) actual[enabled] true; } }這個匹配器把能力按優(yōu)先級排序且啟用這條業(yè)務(wù)規(guī)則封裝成斷言語義。當(dāng)它失敗時CustomMatcher生成的描述會直接說明實際配置不符合設(shè)備配置契約比你去比對一堆字段值要直觀得多。第二個例子是異步輪詢穩(wěn)定匹配。端側(cè)驗證經(jīng)常要等某個異步狀態(tài)穩(wěn)定比如啟動后要等待資源池達到工作狀態(tài)。直接在測試里sleep固定時長很不優(yōu)雅我實現(xiàn)了一個帶輪詢的異步匹配器import package:test_api/test_api.dart; class PollUntilStable extends AsyncMatcher { PollUntilStable(this.inner, {this.timeout const Duration(seconds: 10), this.interval const Duration(milliseconds: 200)}); final Matcher inner; final Duration timeout; final Duration interval; override FutureString? matchAsync(dynamic item) async { final deadline DateTime.now().add(timeout); while (DateTime.now().isBefore(deadline)) { if (inner.matches(item, {})) return null; await Future.delayed(interval); } return 在 $timeout 內(nèi)未能穩(wěn)定滿足匹配條件; } }這個匹配器在鴻蒙真機上的表現(xiàn)比標(biāo)準(zhǔn) Flutter 環(huán)境多了一處需要注意的地方真機任務(wù)調(diào)度并不穩(wěn)定200ms 的間隔在高負載 UI 場景下可能被拉長到 500ms 甚至更多。所以超時時間不能設(shè)太嚴否則偶發(fā)調(diào)度波動就會讓用例誤報失敗。4.3 匹配器的錯誤信息鴻蒙化中文描述與操作 hint遷移過程中我發(fā)現(xiàn)鴻蒙端的測試人員很多是直接從系統(tǒng)側(cè)轉(zhuǎn)過來的對 Dart 生態(tài)的斷言風(fēng)格并不熟悉。所以我們在自定義匹配器的錯誤描述里做了兩個增強一是支持中文語義描述二是附加操作 hint。操作 hint 是我們在describeMismatch里追加的一段話提示排查方向。例如設(shè)備配置契約匹配失敗時hint 會寫建議檢查能力下發(fā)順序是否與 UI 預(yù)期一致。這樣做的收益在端側(cè)問題定位時非常明顯——設(shè)備不在手邊時看報告就能判斷大概是配置下發(fā)問題還是 UI 渲染問題。override Description describeMismatch(dynamic item, Description mismatchDescription, Map matchState, bool verbose) { return mismatchDescription ..add(配置項不滿足契約請檢查能力優(yōu)先級字段和啟用開關(guān)); }這套做法其實就是在把測試斷言變成測試契約:每個匹配器不僅是一段判斷邏輯還是一段領(lǐng)域知識的沉淀失敗時能直接指導(dǎo)人下一步該查什么。5. 端側(cè)質(zhì)量驗證的橋接設(shè)計日志、異步調(diào)度與結(jié)果收集5.1 把斷言結(jié)果接到鴻蒙原生側(cè)MethodChannel 橋梁matcher 跑在 Flutter 側(cè)但鴻蒙執(zhí)行的測試用例往往需要把結(jié)果交給原生側(cè)匯總、展示、上報。我們在架構(gòu)上做了兩層橋接第一層就是用MethodChannel把斷言結(jié)果透傳到鴻蒙原生層。import package:flutter/services.dart; class ContractReporter { static const _channel MethodChannel(contract_reporter); static Futurevoid report(String module, String label, String outcome, String message) async { try { await _channel.invokeMethod(report, { module: module, label: label, outcome: outcome, message: message, }); } catch (_) { // 橋接失敗不影響斷言主流程 } } }這里有個設(shè)計細節(jié)是刻意的橋接失敗必須靜默。測試報告通道是輔助能力不能因為通道異常導(dǎo)致測試用例本身失敗否則真實斷言問題會被偽裝的通道問題干擾。鴻蒙原生側(cè)收到report后會寫入統(tǒng)一的數(shù)據(jù)結(jié)構(gòu)同時把關(guān)鍵信息打到 hilog并附帶設(shè)備型號、系統(tǒng)版本等環(huán)境標(biāo)簽。這一步完成后端側(cè)測試輸出就不僅是 Flutter 側(cè)的 stdout而是可檢索、可歸檔的驗證記錄。5.2 真機場景下的驗證流程橋接完成后整個驗證流程可以組織成這樣的閉環(huán)啟動一套鴻蒙 Flutter 應(yīng)用在關(guān)鍵生命周期節(jié)點用契約斷言檢查頁面和數(shù)據(jù)結(jié)構(gòu)。以模擬項目X 為例我們設(shè)了三個驗證點應(yīng)用冷啟動完成后斷言首屏關(guān)鍵節(jié)點已掛載匹配器驗證節(jié)點集合與預(yù)期契約一致。數(shù)據(jù)通道建立后斷言資源池狀態(tài)已進入可服務(wù)狀態(tài)使用上面的PollUntilStable輪詢匹配器。交互觸發(fā)后斷言埋點上報的數(shù)據(jù)符合事件契約。每個驗證點失敗時contractExpect會拋出帶完整上下文的TestFailure再由ContractReporter把失敗信息送到鴻蒙側(cè)。這個過程讓驗證不再是開發(fā)期的一次性行為而是可以在真機上持續(xù)運行的端側(cè)質(zhì)量門禁。5.3 報告格式與失敗現(xiàn)場的上下文采集報告格式上我們沒有引入成熟報告框架而是用了一個很輕量的 JSON 約定。每條斷言結(jié)果包含模塊名、用例名、斷言標(biāo)簽、結(jié)果、錯誤消息、設(shè)備標(biāo)識、時間戳。鴻蒙原生側(cè)匯總后可以生成 JSON 文件方便 CI 和后續(xù)統(tǒng)計。失敗現(xiàn)場的上下文采集是報告環(huán)節(jié)最容易忽略的部分。我們加了一個現(xiàn)場快照函數(shù)在匹配器失敗時把被測對象的關(guān)鍵字段做一次安全序列化塞進報告。注意安全序列化很重要直接序列化整個業(yè)務(wù)對象很可能因為循環(huán)引用或敏感字段把報告通道拖垮所以只挑斷言關(guān)注的那幾個字段。MapString, Object? snapshotFrom(MapString, Object? raw, ListString keys) { final out String, Object?{}; for (final k in keys) { if (raw.containsKey(k)) out[k] raw[k]; } return out; }這套機制上線后端側(cè)問題定位效率提升很明顯因為報告里已經(jīng)帶著現(xiàn)場不需要再遠程連設(shè)備反復(fù)復(fù)現(xiàn)。6. 適配實測中繞不開的坑與處理記錄6.1 異常 throw 的類型TestFailure 在鴻蒙 release 下的裁剪問題前面提到過鴻蒙端在 release 裁剪路徑下TestFailure的 message 可能不完整。這里給出具體的處理方式不要只依賴異常的 message 字段而是在自定義斷言入口把完整的失敗描述通過結(jié)構(gòu)化參數(shù)傳給上報層。換句話說contractExpect里拋的TestFailure只充當(dāng)執(zhí)行流中斷的信號真正的失敗信息已經(jīng)通過ContractReporter.report送出。這樣即使異常信息被裁剪報告里仍然保留完整描述。這個思路是適配工程里一個典型的雙通道設(shè)計——語義信息走業(yè)務(wù)通道執(zhí)行流信號走異常通道。6.2 事件循環(huán)時序異步匹配器的 poll 在真機上假死PollUntilStable在最早上線時出現(xiàn)過一個規(guī)律性現(xiàn)象每次跑大約十幾分鐘后輪詢會長時間卡住看起來像假死。排查后發(fā)現(xiàn)問題不在匹配器邏輯而在于鴻蒙真機高耗電場景下后臺任務(wù)優(yōu)先級被系統(tǒng)壓低Future.delayed的恢復(fù)時間被無限拉長。處理方法是給輪詢匹配器加一個基于真實時鐘的判斷不再依賴恢復(fù)次數(shù)而是用DateTime.now().isBefore(deadline)做兜底。同時把輪詢間隔從純Future.delayed改為延遲加時間片讓步給系統(tǒng)調(diào)度留出喘息空間。改完后這個現(xiàn)象再沒出現(xiàn)過。這個坑可以沉淀成一條通用經(jīng)驗在鴻蒙端做異步測試邏輯時任何依賴時間恢復(fù)的機制都要加真實時鐘的兜底判斷不要相信延遲 N 毫秒后一定恢復(fù)。6.3 日志通道被合并與丟幀第一次把 matcher 輸出接到 hilog 時發(fā)現(xiàn)部分日志在大量并發(fā)斷言時丟失。原因不復(fù)雜hilog 對單條消息長度有限制長描述會被截斷斷言密集時還會有丟棄策略。處理方式是先本地緩沖再批量上報并給每條日志加序號。這里要特別說明批量上報必須處理失敗重試否則測試結(jié)束后緩沖丟失等于白搭。我們做了一個計數(shù)器確認某條日志成功進入原生側(cè)緩存后才會清除本地副本否則在下一次 flush 時重新上報。6.4 依賴版本靜態(tài)檢查與三方包傳遞依賴適配過程中最耗時間的其實是依賴版本排查。matcher的傳遞依賴包括test_api、meta、stack_trace等。鴻蒙 Flutter SDK 自帶的測試相關(guān)庫版本如果和 matcher 期望的版本不同靜態(tài)檢查會直接告警更隱蔽的是運行時類型不匹配。建議在接入初期就做一個全量依賴審計列出 matcher 及其所有傳遞依賴的版本號和鴻蒙 Flutter SDK 自帶的版本號逐一比對形成一張對照表。版本不一致時優(yōu)先用dependency_overrides強制統(tǒng)一不要指望自然解析能給出正確結(jié)果。這一步做得越早后面踩的坑越少。7. 適配收尾時我的一點心得整套適配做完后我最大的體會是matcher 鴻蒙化最難的部分不是代碼遷移而是思維遷移。你不能再把它當(dāng)成一個斷言庫要看成一個端側(cè)質(zhì)量驗證的契約運行時。語義化斷言、自定義匹配算法、異步輪詢策略、結(jié)果上報鏈路這些能力組合起來才真正支撐起鴻蒙設(shè)備上的質(zhì)量門禁。如果團隊后續(xù)要做類似的適配我的建議是按這個順序推進先把依賴樹釘死再跑通最小斷言鏈路然后擴展自定義匹配器最后接報告通道。每一步都要有真機驗證不要只在模擬器里自嗨。尤其是異步匹配器的超時策略和日志上報通道這兩塊直接決定你在真實設(shè)備上能不能發(fā)現(xiàn)問題、能不能快速定位問題。做完這些這套測試契約框架就算真正在鴻蒙端落地了。