鴻蒙上用 Flutter 做界面最折騰我的往往不是業(yè)務(wù)邏輯反而是那些不起眼的填充數(shù)據(jù)。界面都排好了但頁面里全是空殼子和“TODO”截圖給產(chǎn)品看對(duì)方回一句“這頁面還沒做完吧”直接噎住。我前陣子就因?yàn)檫@事兒把一個(gè)老項(xiàng)目里的假數(shù)據(jù)生成邏輯整個(gè)換掉干脆把 lorem_gen 這個(gè) Dart 庫搬進(jìn)了鴻蒙 Flutter 工程。整個(gè)過程踩了不少坑但也把思路理得清清楚楚——純 Dart 的三方庫搬到鴻蒙到底要?jiǎng)幽男〇|西哪些能直接復(fù)用哪些必須改。這篇文章就把這次“l(fā)orem_gen 鴻蒙化適配”的完整過程拆開講。讀完你會(huì)得到三條線一是 lorem_gen 這類占位文本庫到底能怎么用二是把第三方 Dart 包移植到鴻蒙 Flutter 工程的具體步驟和卡點(diǎn)三是適配完成之后怎么靠它把 UI 原型效率和壓力測(cè)試質(zhì)量同時(shí)提上去。如果你也在鴻蒙生態(tài)里寫 Flutter或者手頭有別的 Dart 庫想在鴻蒙工程里復(fù)用這套思路完全可以照搬。1. 這項(xiàng)目到底在解決什么問題1.1 占位文本在 UI 開發(fā)里的真實(shí)地位做 UI 原型的時(shí)候占位文本的地位比很多人想象得高。排版是否舒服、控件尺寸是否合理、文字會(huì)不會(huì)溢出、多語言下布局會(huì)不會(huì)崩——這些全靠填充內(nèi)容才能看出來。真正拿到產(chǎn)品文案之前開發(fā)手上拿到的往往是一張?jiān)O(shè)計(jì)圖。設(shè)計(jì)圖里能寫“標(biāo)題文字”“正文內(nèi)容”但落到代碼里你總得塞點(diǎn)真實(shí)的字符串進(jìn)去不然列表根本滾動(dòng)不起來卡片也看不出寬高比合不合理。我見過很多項(xiàng)目用“測(cè)試一下”“123456”“asdfghjk”這種隨手敲的內(nèi)容。它們能撐起頁面但沒法暴露問題。比如一段超長單詞會(huì)不會(huì)撐破 flex 布局一個(gè)接近 2000 字的段落會(huì)不會(huì)讓 Text 控件卡頓這些“正經(jīng)測(cè)試內(nèi)容”是隨手假數(shù)據(jù)永遠(yuǎn)覆蓋不到的。Lorem ipsum 這類經(jīng)典占位文本的價(jià)值就在于它看起來像英文但又不是英文眼球會(huì)自然地把它當(dāng)成“內(nèi)容”而不是“亂碼”同時(shí)它的單詞長度分布和真實(shí)英文很像用來檢驗(yàn)排版是業(yè)內(nèi)公認(rèn)的做法。lorem_gen 這個(gè)庫解決的是“批量生成”的問題。你不僅要一段文本你要的是 50 個(gè)標(biāo)題、200 條列表項(xiàng)、每項(xiàng) 3 到 5 行的描述。手寫根本不可能寫循環(huán)又太生硬。它可以用一句話把數(shù)量、長度、風(fēng)格都控制好生成出來直接喂給 ListView.builder省下來的時(shí)間非?？捎^。1.2 鴻蒙 Flutter 生態(tài)下三方庫復(fù)用的現(xiàn)實(shí)情況鴻蒙引入 Flutter 框架之后Dart 代碼的跨平臺(tái)優(yōu)勢(shì)其實(shí)被繼承了大半。只要一個(gè)庫沒有強(qiáng)行依賴某個(gè)操作系統(tǒng)的底層能力理論上在鴻蒙工程里也能跑。但現(xiàn)實(shí)是現(xiàn)成的鴻蒙適配示例大多集中在 ui 框架、網(wǎng)絡(luò)庫、狀態(tài)管理庫這些大件上像 lorem_gen 這種“小而美”的純邏輯庫反而容易被忽略。我在做模擬項(xiàng)目 X一個(gè)鴻蒙端的資訊閱讀應(yīng)用的時(shí)候需要大量的占位文章數(shù)據(jù)。項(xiàng)目工期緊張后端聯(lián)調(diào)排到兩周后前端不能原地等著。當(dāng)時(shí)第一個(gè)念頭是找現(xiàn)成的假數(shù)據(jù)服務(wù)但考慮到斷網(wǎng)環(huán)境沒法用又想到自己寫一個(gè)隨機(jī)文本生成器——為了這點(diǎn)功能養(yǎng)一段幾十行的工具代碼怎么想都不劃算。最后才回頭看 lorem_gen發(fā)現(xiàn)這東西的 API 設(shè)計(jì)非常干凈生成邏輯獨(dú)立幾乎沒有平臺(tái)相關(guān)的依賴。問題只剩下一個(gè)怎么讓鴻蒙 Flutter 工程認(rèn)這個(gè)包。這次適配的另一個(gè)背景是鴻蒙 Flutter 工程的包管理方式和原生 Flutter 不完全一樣。很多在 pub.dev 上能直接拉取的三方包在鴻蒙工程里不一定能順利解析。最穩(wěn)妥的方案不是硬去改構(gòu)建配置而是把包源碼拉到本地做 path 依賴既繞開了倉庫解析問題又方便我們對(duì)源碼做針對(duì)性調(diào)整。這個(gè)思路對(duì) lorem_gen 成立對(duì)你手頭其他純 Dart 包同樣成立。2. 適配前先摸清 lorem_gen 的底細(xì)2.1 源碼結(jié)構(gòu)與核心邏輯任何移植工作開始前都得先把對(duì)方的技術(shù)底盤看清楚。lorem_gen 這個(gè)庫最吸引我的一點(diǎn)是“簡單到透明”。它的主體就是一組純 Dart 類內(nèi)部維護(hù)了幾套基礎(chǔ)詞庫和生成規(guī)則。調(diào)用的時(shí)候你指定想要的句子數(shù)量、段落數(shù)量、單詞范圍它就在這些詞庫里做隨機(jī)組合。翻它源碼的時(shí)候我特別留意了一件事有沒有用到 dart:io、dart:ffi 這類平臺(tái)相關(guān)庫。結(jié)論是基本沒有。它只用到了 dart:math 的隨機(jī)數(shù)功能。這意味著從語言層面看它并不關(guān)心底層是 Android、iOS 還是鴻蒙只要 Dart 虛擬機(jī)正常生成邏輯就能跑。這個(gè)判斷是后面整個(gè)適配能順利走通的基石。它的生成入口也很規(guī)整。大致分成三層底層的詞庫數(shù)據(jù)、中層的隨機(jī)選擇邏輯、上層暴露給調(diào)用者的生成方法。用戶使用的時(shí)候通常只需要關(guān)心上層那兩三個(gè) API比如生成指定段落數(shù)、指定句子數(shù)的文本。這種分層結(jié)構(gòu)讓適配工作變得很輕松——我甚至可以不動(dòng)底層邏輯只在外層加一些鴻蒙場(chǎng)景需要的定制能力。2.2 鴻蒙側(cè) Flutter 環(huán)境準(zhǔn)備適配前環(huán)境這塊容易翻車我先說我踩過的路。鴻蒙 Flutter 開發(fā)目前依賴的是一套獨(dú)立的 SDK 和配套工具鏈跟原生 Flutter 的側(cè)重點(diǎn)有些差別。我在某公司開發(fā)機(jī)上裝了日常用的 Flutter SDK又額外配了鴻蒙側(cè)的 SDK兩個(gè)環(huán)境并存的時(shí)候命令入口容易搞混。最直接的解決辦法是分開配環(huán)境變量項(xiàng)目目錄里點(diǎn)開終端之前先確認(rèn)當(dāng)前用的是哪一套命令。創(chuàng)建鴻蒙 Flutter 工程模板之后會(huì)自動(dòng)生成一套鴻蒙平臺(tái)的殼工程里面已經(jīng)處理好了 Flutter 引擎和鴻蒙側(cè)的橋接。這層?xùn)|西不用我操心我要解決的是 Dart 側(cè)三方依賴的引入方式。因?yàn)?lorem_gen 打算用本地 path 依賴我需要在工程里單獨(dú)建一個(gè)目錄把它的源碼整體放進(jìn)去。還有一點(diǎn)容易被忽略鴻蒙 Flutter 工程對(duì) Dart SDK 版本是有約束的。lorem_gen 的 pubspec.yaml 里會(huì)聲明它支持的最低 SDK 版本。如果聲明里寫的是某個(gè)比較新的版本而鴻蒙 Flutter SDK 對(duì)應(yīng)的 Dart 版本偏低解析時(shí)就會(huì)報(bào)警。我在拉源碼之前特意先看了這個(gè)聲明確認(rèn)不會(huì)撞版本后面才沒在第一步就卡住。2.3 風(fēng)險(xiǎn)盤點(diǎn)純 Dart 并不等于零改動(dòng)現(xiàn)在可以聊一個(gè)關(guān)鍵判斷純 Dart 庫搬到鴻蒙是不是把文件復(fù)制過去就完事了答案是大概率不能但改動(dòng)量可能很小。lorem_gen 雖然不依賴平臺(tái)能力但它對(duì) Dart SDK 的語言特性有要求空安全相關(guān)語法在低版本環(huán)境里會(huì)直接編譯失敗。如果鴻蒙 Flutter 工具鏈內(nèi)置的 Dart 版本比庫要求的低那就得先做語法層面的兼容。另一個(gè)容易踩的暗坑是依賴傳遞。lorem_gen 本身很干凈但它 pubspec.yaml 里的依賴項(xiàng)其實(shí)也可能把臟東西帶進(jìn)來。雖然這個(gè)庫幾乎沒有第三方依賴但我在做模擬項(xiàng)目時(shí)習(xí)慣性檢查了整棵依賴樹。因?yàn)轼櫭森h(huán)境里有一些原生 Flutter 常用插件是失效的如果庫的依賴鏈里帶了這些插件那適配工作量就會(huì)從“復(fù)制文件”變成“重寫插件”。好在 lorem_gen 沒這個(gè)問題這讓我對(duì)它的好感又加了一分。風(fēng)險(xiǎn)盤點(diǎn)之后我給出的結(jié)論是這個(gè)庫的適配難度在 10 分制里最多 3 分。真正花時(shí)間的是在鴻蒙 Flutter 工程里把本地依賴路徑配好、跑通構(gòu)建、再做一套覆蓋性驗(yàn)證。這幾個(gè)動(dòng)作單獨(dú)看都不難合在一起就是標(biāo)準(zhǔn)的第三方庫鴻蒙化流程。3. 鴻蒙化適配的完整實(shí)操3.1 拉取源碼與依賴分析實(shí)操第一步把 lorem_gen 的源碼拿下來。我沒直接從 pub.dev 拉緩存而是用 git clone 把倉庫整個(gè)拉到項(xiàng)目里的 third_party 目錄。這樣做的原因是后續(xù)如果要自己做定制能直接在源碼上改而且改動(dòng)對(duì)構(gòu)建鏈路是完全可見的。拉完之后先看根部文件。pubspec.yaml 是第一個(gè)必須打開的文件里面藏著庫的依賴關(guān)系、SDK 約束、還有它聲明的入口文件。lorem_gen 的入口文件通常指向 lib 下的主文件所有公開 API 都從那里統(tǒng)一導(dǎo)出。這一層看明白之后就能知道這個(gè)庫對(duì)外暴露了哪些能力后續(xù)接入時(shí)就不用到處翻源碼找類名了。接下來做依賴分析。我在項(xiàng)目里打開 pub get 的日志觀察它有沒有額外拉取什么隱藏依賴。lorem_gen 的依賴列表幾乎可以忽略不計(jì)這給我省了不少事。如果讀者的工程里要移植的是別的庫我建議這一步千萬別跳我見過不少人辛辛苦苦改了主庫結(jié)果被一個(gè)不起眼的傳遞依賴卡了整整一天。3.2 將 lorem_gen 配置為鴻蒙工程的本地包環(huán)境分析完畢開始實(shí)際配置。鴻蒙 Flutter 工程里要用本地包標(biāo)準(zhǔn)做法是在 pubspec.yaml 里聲明 path 依賴。我先把 lorem_gen 源碼放到工程目錄下的 third_party/lorem_gen 文件夾里保證目錄里有完整的 pubspec.yaml 和 lib 文件夾然后在主工程的 pubspec.yaml 中加上依賴聲明。依賴聲明寫法示例dependencies: flutter: sdk: flutter lorem_gen: path: third_party/lorem_gen這里有幾個(gè)細(xì)節(jié)要強(qiáng)調(diào)。path 依賴的路徑是相對(duì)主工程根目錄算的寫錯(cuò)路徑會(huì)直接在 pub get 階段報(bào)錯(cuò)。另外如果 lorem_gen 的 pubspec.yaml 里聲明了 flutter 依賴它在本地路徑下也能識(shí)別但如果它在鴻蒙工程里依賴了某個(gè)不存在于本地的插件這一步就會(huì)顯得非常麻煩。好在 lorem_gen 完全不需要聲明完之后執(zhí)行 pub get日志里能看到它被成功解析。配置完成之后不等于萬事大吉。我還要確認(rèn)鴻蒙側(cè)的構(gòu)建工具能正確識(shí)別這個(gè)本地依賴。鴻蒙 Flutter 工程在構(gòu)建時(shí)會(huì)先同步 Dart 依賴再編譯殼工程。如果只在 pubspec 里寫了依賴卻忘了執(zhí)行依賴同步命令I(lǐng)DE 里依然會(huì)報(bào)“package not found”。我習(xí)慣在終端里手動(dòng)跑一遍依賴同步確保鎖文件更新到最新。3.3 編譯鏈接與生成結(jié)果驗(yàn)證配置好依賴之后第一關(guān)是編譯。我先用 flutter analyze 做靜態(tài)檢查確認(rèn)沒有因?yàn)?SDK 版本差異引入語法問題。lorem_gen 源碼比較干凈這一步基本沒有報(bào)錯(cuò)。接著就是完整的鴻蒙編譯流程因?yàn)橐邙櫭稍O(shè)備上驗(yàn)證我選了一個(gè)輕量模擬器作為目標(biāo)運(yùn)行環(huán)境。編譯過程中有一個(gè)需要注意的點(diǎn)鴻蒙 Flutter 工程的構(gòu)建速度通常比原生 Flutter 慢一些每一步的輸出信息更多。我習(xí)慣在編譯時(shí)專門留一個(gè)終端窗口盯著日志看到“BUILD SUCCESSFUL”或類似關(guān)鍵字再往下走。如果有錯(cuò)誤提前截取日志片段會(huì)比事后翻完整日志高效得多。編譯通過后我寫了一個(gè)最簡單的調(diào)用示例import package:lorem_gen/lorem_gen.dart; void main() { final lorem Lorem(); print(lorem.paragraphs(3)); print(lorem.words(10)); }這段代碼在鴻蒙 Flutter 環(huán)境里編譯并運(yùn)行成功說明 lorem_gen 的核心生成邏輯已經(jīng)真正跑在了鴻蒙側(cè)。之后我又把生成的文本跟原生 Flutter 環(huán)境下生成的結(jié)果做了抽樣比對(duì)確認(rèn)隨機(jī)性正常、格式?jīng)]有亂碼、段落邊界符和預(yù)期一致。這一步驗(yàn)證做完適配工作就算正式收口了。4. 適配后的真實(shí)使用場(chǎng)景與效果4.1 在 UI 原型中快速填充占位文本適配完成后第一件事就是把它接進(jìn)資訊閱讀項(xiàng)目里。我封裝了一個(gè)假的文章數(shù)據(jù)倉庫內(nèi)部用 lorem_gen 生成標(biāo)題、摘要和正文。每次進(jìn)入原型頁面數(shù)據(jù)倉庫都隨機(jī)生成一批內(nèi)容頁面看起來就像是已經(jīng)接入了真實(shí)后端。使用的時(shí)候我會(huì)控制詞數(shù)范圍。標(biāo)題生成 3 到 6 個(gè)詞摘要生成 15 到 30 個(gè)詞正文生成 5 到 8 個(gè)段落。這樣的設(shè)定能讓 UI 既有足夠的文字密度又不會(huì)因?yàn)槟扯挝谋具^長導(dǎo)致布局掉幀。實(shí)際體驗(yàn)下來整個(gè)頁面的排版效果和真實(shí)文章相當(dāng)接近截圖給同事評(píng)審不再有“頁面沒做完”的即視感。我還給 lorem_gen 加了個(gè)小功能把默認(rèn)的英文詞庫擴(kuò)展了一套中文字符集。因?yàn)轼櫭啥说馁Y訊應(yīng)用目標(biāo)用戶是中文場(chǎng)景用英文假文看布局總覺得差一點(diǎn)意思。我直接在本地 fork 里加了一個(gè)簡單的字符池生成中文假文時(shí)用隨機(jī)字符組合成詞。改動(dòng)很小但對(duì)原型的真實(shí)感幫助非常大。4.2 用批量生成文本做壓力測(cè)試的策略原型做完之后壓測(cè)需求就來了。資訊列表頁需要在短時(shí)間內(nèi)渲染大量條目如果每一條都生成 200 字的正文界面就會(huì)面臨很大的渲染壓力。我用 lorem_gen 寫了一個(gè)批量生成器一次性生成 1000 條列表數(shù)據(jù)每條包含標(biāo)題、摘要、閱讀時(shí)長、封面圖地址等字段。這里面文本部分全部由 lorem_gen 產(chǎn)出。壓測(cè)時(shí)要特別注意生成頻率和頁面渲染頻率之間的配合。如果一次性生成 1000 條數(shù)據(jù)list view 首次滑動(dòng)就會(huì)產(chǎn)生明顯的卡頓感這其實(shí)是真實(shí)場(chǎng)景下的正?，F(xiàn)象關(guān)鍵看持續(xù)滑動(dòng)后是否恢復(fù)流暢。我在壓測(cè)過程中用性能工具的幀率記錄功能觀察了 FPS 曲線發(fā)現(xiàn)文本量從每條 50 字提到每條 200 字后掉幀點(diǎn)集中在首次換頁階段后續(xù)保持穩(wěn)定。這個(gè)結(jié)論對(duì)后續(xù)做列表預(yù)加載決策很有參考價(jià)值。壓力測(cè)試真正有說服力的地方在于占位文本的數(shù)據(jù)量可以任意調(diào)節(jié)。lorem_gen 的 API 能精確控制段落數(shù)和句子數(shù)這意味著壓測(cè)用例可以量化——每條 50 字、100 字、200 字、500 字分別跑一遍滑動(dòng)流暢度數(shù)據(jù)一出來頁面性能邊界在哪就很清楚了。手動(dòng)造這種梯度數(shù)據(jù)非常痛苦用庫生成就是一行代碼的事。4.3 包體積與性能影響觀察適配一個(gè)三方庫之后我看的另一項(xiàng)硬指標(biāo)是包體積和運(yùn)行性能。lorem_gen 的源碼只有幾個(gè)文件編譯進(jìn)鴻蒙 Flutter 包之后的體積增量可以忽略不計(jì)。對(duì)比項(xiàng)目里動(dòng)輒幾百 KB 的 UI 庫和網(wǎng)絡(luò)庫這個(gè)占位文本庫的體積非?？酥啤＿\(yùn)行性能方面生成 1000 條短文的時(shí)間在幾十毫秒級(jí)別幾乎感知不到。真正消耗性能的反而是把這些文本渲染到屏幕上。因此我在使用上調(diào)整了一個(gè)策略壓測(cè)場(chǎng)景里預(yù)生成全部數(shù)據(jù)原型場(chǎng)景里按需生成避免不必要的先行計(jì)算。這個(gè)度掌握好了lorem_gen 在鴻蒙 Flutter 工程里幾乎是一條無副作用的“鲇魚”——平時(shí)感覺不到存在但需要的時(shí)候相當(dāng)好用。5. 常見問題與排查心得5.1 高頻問題速查表適配過程中遇到的坑我整理成了一張速查表按出現(xiàn)頻率排序問題現(xiàn)象排查方向解決辦法pub get 報(bào) path 路徑不存在本地包路徑寫錯(cuò)檢查 pubspec.yaml 中 path 是否為相對(duì)主工程根目錄的有效路徑編譯報(bào) SDK 版本沖突lorem_gen 的 pubspec 聲明了更高 Dart SDK修改本地包 pubspec 里的 SDK 約束使其落在鴻蒙 Flutter SDK 支持范圍內(nèi)運(yùn)行期中文假文亂碼字符集編碼問題確認(rèn)生成的字符串為合法的 Unicode 序列避免直接拼接不規(guī)則代理項(xiàng)生成內(nèi)容重復(fù)率過高隨機(jī)種子未處理在生成器外層按時(shí)間設(shè)置隨機(jī)種子確保多次運(yùn)行結(jié)果不同鴻蒙構(gòu)建工具找不到本地包依賴未同步手動(dòng)執(zhí)行 pub get 或 IDE 的依賴同步動(dòng)作刷新鎖文件熱重載后頁面無數(shù)據(jù)本地包改動(dòng)未觸發(fā)重建改動(dòng) third_party 下源碼后需要重新編譯純熱重載有時(shí)不生效這張表里后面兩條是我自己踩得比較深的坑。第三個(gè)問題其實(shí)是所有隨機(jī)生成類庫共有的——不是庫本身的 bug而是運(yùn)行環(huán)境的隨機(jī)種子機(jī)制和原生 Flutter 不完全一樣。加了隨機(jī)種子之后生成結(jié)果的重復(fù)率肉眼可見地下降了。5.2 我踩過的幾個(gè)典型坑第一個(gè)坑是路徑問題。一開始我把 lorem_gen 放在工程根目錄下的 libs/lorem_gen然后在 pubspec.yaml 里寫成了path: libs/lorem_gen/。理論上沒問題但我的項(xiàng)目殼工程結(jié)構(gòu)有點(diǎn)特殊主工程和鴻蒙殼工程不在同一個(gè)層級(jí)導(dǎo)致 pub get 始終報(bào)錯(cuò)。后來改成絕對(duì)路徑才解決但絕對(duì)路徑不好提交到版本庫所以我最后又調(diào)整了目錄結(jié)構(gòu)讓本地依賴相對(duì)路徑穩(wěn)定在同一個(gè)層級(jí)。第二個(gè)坑是 Dart SDK 版本約束。鴻蒙 Flutter 工具鏈的 Dart 版本比我預(yù)想的要保守。lorem_gen 源碼里用的空安全語法沒有問題但 pubspec 里字面聲明的 SDK 下限太高導(dǎo)致 pub get 直接拒絕。解決方法是把本地包 pubspec 里的 environment.sdk 改成鴻蒙工具鏈實(shí)際支持的版本區(qū)間再跑依賴同步。這里要提醒一句改的是本地 fork 包的聲明而不是整個(gè)項(xiàng)目的最低版本要求引入本地包的好處就在這里。第三個(gè)坑更隱性。因?yàn)?lorem_gen 不依賴 dart:io 和 dart:ffi我在評(píng)估階段判斷“零改動(dòng)”?？蓪?shí)際接入時(shí)發(fā)現(xiàn)鴻蒙 Flutter 項(xiàng)目里依賴解析的網(wǎng)絡(luò)源和原生環(huán)境不一樣如果直接使用 pub.dev 遠(yuǎn)程依賴有些網(wǎng)段會(huì)拉得特別慢甚至超時(shí)。所以我才堅(jiān)持走本地 path 依賴路線。這個(gè)坑不是 lorem_gen 本身帶來的但卻是鴻蒙化適配最常見的攔路虎。5.3 給同樣做鴻蒙適配的朋友幾點(diǎn)建議最后分享幾個(gè)經(jīng)驗(yàn)。第一純 Dart 庫移植前一定要看 pubspec.yaml 里的 SDK 約束這是唯一能提前暴露 80% 問題的地方。第二盡量用本地 path 依賴少依賴遠(yuǎn)程倉庫解析鴻蒙網(wǎng)絡(luò)環(huán)境下這能省掉大量不可控的等待時(shí)間。第三生成類庫的隨機(jī)性驗(yàn)證不能省我建議至少連續(xù)生成十次結(jié)果做對(duì)比確認(rèn)每次輸出都不一樣。第四不要一步到位追求“零改動(dòng)”先把最小可用路徑跑通再逐步定制這個(gè)順序能讓你在每一個(gè)階段都知道問題是哪個(gè)環(huán)節(jié)引入的。我在模擬項(xiàng)目 X 里的這次適配從開始評(píng)估到接進(jìn)原型頁面總共花了不到半天時(shí)間。其中有小半天都耗在環(huán)境配置和路徑調(diào)整上真正的代碼改動(dòng)非常少。這說明 lorem_gen 這類純邏輯庫在鴻蒙 Flutter 生態(tài)里的適配成本真的很低。如果你手頭也攢了一堆想用的 Dart 庫不妨用這套流程逐個(gè)試一遍多半比我預(yù)想的還要順利。至少以后再有人跟我說“鴻蒙上 Flutter 三方庫不好適配”我就能拿這次經(jīng)歷回一句有時(shí)候真不是庫的問題是流程沒捋順。