象調(diào)試一眼看清)
調(diào)試 Flutter 應(yīng)用時(shí)最讓人頭大的場(chǎng)景之一就是日志里打出一個(gè)對(duì)象看到的卻只有Instance of User。字段值到底是什么、哪個(gè)字段為空、列表里裝了幾條數(shù)據(jù)全靠猜。更麻煩的是當(dāng)你開始手寫 toString() 的時(shí)候你會(huì)發(fā)現(xiàn)這活越寫越枯燥——字段少還好字段一多、嵌套一深toString 本身就成了一個(gè)需要維護(hù)的負(fù)擔(dān)。class_to_string 這個(gè) Flutter 三方庫(kù)就是用來(lái)終結(jié)這個(gè)局面的通過注解聲明配合代碼生成器自動(dòng)產(chǎn)出格式化的對(duì)象字符串讓對(duì)象調(diào)試從“盲猜”變成“一眼看清”。我最近在把 Flutter 項(xiàng)目遷到鴻蒙端正好把 class_to_string 從頭到尾做了一遍鴻蒙化適配。這篇文章記錄的就是這個(gè)過程環(huán)境怎么搭、依賴怎么選、代碼怎么生成、在鴻蒙上怎么驗(yàn)證、中間踩了哪些坑以及最終的實(shí)戰(zhàn)效果給同樣在折騰鴻蒙 Flutter 的同學(xué)做參考。1. 先搞明白class_to_string 到底解決了什么問題1.1 對(duì)象調(diào)試的核心痛點(diǎn)不在打印而在“信息密度”Dart 里所有對(duì)象都繼承自 ObjectObject 默認(rèn)的 toString() 只輸出類型名哈希值比如Instance of OrderModel。這在業(yè)務(wù)代碼里幾乎等于沒有信息。你真正想看到的是這個(gè)訂單號(hào)是多少、狀態(tài)字段是 pending 還是 paid、金額有沒有算對(duì)、列表里到底塞了幾個(gè)商品。于是大家開始手寫 toString()。但這里有個(gè)很現(xiàn)實(shí)的問題手寫 toString 的維護(hù)成本是隱性的。字段增刪改的時(shí)候toString 里的字符串拼接很容易漏改嵌套對(duì)象一復(fù)雜輸出就容易變成一長(zhǎng)串沒有縮進(jìn)的User(name: xx,address: Address(city: ...,province: ...))且不說(shuō)是中文還是英文肉眼根本不好定位。更麻煩的是一旦某個(gè)字段為 null手寫的 toString 還得自己處理空值顯示不然日志里飄出來(lái)一個(gè)null你根本不知道是哪個(gè)字段。這些問題在 Android/iOS 上存在在鴻蒙端一樣存在。Flutter 應(yīng)用要跑在鴻蒙上業(yè)務(wù)邏輯和模型層基本是原封不動(dòng)搬過去的調(diào)試體驗(yàn)也因此原封不動(dòng)地搬了過去。所以做鴻蒙化適配的時(shí)候我第一步就是把這些“開發(fā)期效率工具”補(bǔ)齊class_to_string 就是其中之一。1.2 注解 代碼生成class_to_string 的做法class_to_string 的思路很直白你在模型類上打一個(gè)ClassToString()注解它會(huì)在編譯期通過 build_runner 讀取這個(gè)注解然后自動(dòng)生成一個(gè)格式化輸出的擴(kuò)展方法。整個(gè)過程不依賴運(yùn)行時(shí)反射字段的讀取在生成代碼里就已經(jīng)寫死了所以性能和手寫 toString 基本沒有差別。典型用法是這樣的import package:class_to_string/class_to_string.dart; ClassToString( printFields: true, fieldsToExclude: [password], sortFields: true, ) class User { const User({ required this.id, required this.name, this.email, this.password , }); final String id; final String name; final String? email; final String password; }build_runner 跑完之后會(huì)自動(dòng)生成一個(gè)user.g.dart文件里面包含類似toClassString()的擴(kuò)展方法。我通常在業(yè)務(wù)基類里再補(bǔ)一層override String toString() toClassString();這樣一來(lái)無(wú)論是print(user)、日志框架還是斷言失敗的信息里拿到的都是完整、可讀、有字段名的格式化字符串。這個(gè)“基類統(tǒng)一重寫 生成器自動(dòng)展開”的組合是我在項(xiàng)目里比較推薦的用法因?yàn)樗磺秩肽Ｐ皖惖睦^承結(jié)構(gòu)生成代碼更新時(shí)也不用手動(dòng)去改 toString。1.3 為什么鴻蒙端同樣需要它可能有人會(huì)問鴻蒙端跑 Flutter調(diào)試工具那么多非得用 toString 嗎我的實(shí)際感受是日志和斷點(diǎn)解決的是不同層面的問題。斷點(diǎn)適合“我已經(jīng)知道大概哪里出了問題”日志適合“發(fā)生了什么、數(shù)據(jù)流經(jīng)過了什么、狀態(tài)變成了什么”。在鴻蒙端調(diào)試跨端問題時(shí)尤其如此——你往往要同時(shí)看 ArkTS 原生側(cè)的日志和 Flutter 側(cè)的業(yè)務(wù)日志兩邊時(shí)間線一對(duì)應(yīng)才能定位到是橋接層出的問題還是 Dart 層數(shù)據(jù)就不對(duì)。這時(shí)候如果 Dart 側(cè)打出來(lái)的對(duì)象是Instance of OrderModel整個(gè)排查鏈路就直接斷在最有信息量的那一步。另外還有一個(gè)很實(shí)際的場(chǎng)景線上問題排查。很多團(tuán)隊(duì)的線上日志系統(tǒng)只收集應(yīng)用內(nèi)日志對(duì)象如果不格式化輸出上報(bào)回來(lái)的就是一堆無(wú)意義的Instance of。class_to_string 生成的內(nèi)容在編譯期確定沒有反射開銷打進(jìn)日志里也不會(huì)有性能顧慮。2. 鴻蒙化適配前先盤清楚依賴和環(huán)境2.1 鴻蒙 Flutter 開發(fā)環(huán)境長(zhǎng)什么樣鴻蒙端的 Flutter 開發(fā)環(huán)境和官方的 Flutter 有一點(diǎn)區(qū)別。你需要準(zhǔn)備三塊東西DevEco Studio鴻蒙應(yīng)用開發(fā)工具鏈、鴻蒙系統(tǒng)的 SDK通常是隨 DevEco 或命令行工具鏈提供、以及支持 OpenHarmony/HarmonyOS 平臺(tái)的 Flutter SDK 分支。工程結(jié)構(gòu)和 Android 工程最明顯的差異是項(xiàng)目根目錄下會(huì)多出一個(gè)ohos/目錄里面是 ArkTS 原生殼工程。Flutter 側(cè)的lib/、pubspec.yaml、build_runner配置都在上層目錄但最終要跑上鴻蒙設(shè)備需要原生殼工程配合打包。我建議在動(dòng)手適配之前先把你當(dāng)前的 Flutter SDK 版本和鴻蒙 SDK 版本記下來(lái)因?yàn)榇a生成類的三方庫(kù)對(duì) Dart SDK 版本很敏感。我當(dāng)時(shí)用的 Flutter SDK 是鴻蒙適配版Dart 版本在 3.x 左右class_to_string 的生成代碼依賴 Dart 的 extension 語(yǔ)法這個(gè)版本門檻還好但后面要拉源碼生成器時(shí)對(duì) analyzer 和 source_gen 的版本兼容性要求才是真正要小心的點(diǎn)。2.2 class_to_string 的依賴鏈條拆解class_to_string 并不是一個(gè)單文件庫(kù)它由兩部分組成一個(gè)是業(yè)務(wù)代碼里引用的注解定義另一個(gè)是 build_runner 要加載的代碼生成器。后者依賴 source_gen、build_runner、analyzer 這一套代碼生成生態(tài)。關(guān)鍵信息是這套依賴幾乎全是純 Dart 實(shí)現(xiàn)不涉及 platform channel也不涉及 dart:io 的原生能力。也就是說(shuō)class_to_string 的適配重點(diǎn)不在“運(yùn)行時(shí)”而在“構(gòu)建期”。只要 build_runner 能在鴻蒙 Flutter 工程里跑起來(lái)生成代碼能通過編譯運(yùn)行時(shí)就基本不存在平臺(tái)差異。這一點(diǎn)很重要它決定了我后續(xù)的適配策略先保證 pub 依賴能正確解析再跑通 build_runner最后真機(jī)驗(yàn)證。不需要像適配 flutter_platformview 或者 eventchannel 插件那樣去改原生代碼。2.3 版本兼容性檢查清單在往 pubspec.yaml 里寫依賴之前我習(xí)慣先列一個(gè)版本兼容性清單。class_to_string 本身作為業(yè)務(wù)依賴放到dependencies里build_runner 和代碼生成器需要的 source_gen 要放到dev_dependencies里。依賴項(xiàng)放置位置版本建議說(shuō)明class_to_stringdependencies鎖定一個(gè)你驗(yàn)證過的穩(wěn)定版本注解庫(kù)build_runnerdev_dependencies2.4.x 或?qū)?yīng)兼容版本代碼生成入口source_gendev_dependencies與 build_runner 匹配的版本生成器核心依賴analyzerdev_dependencies由 build_runner 間接引入版本沖突重災(zāi)區(qū)盡量不要顯式指定版本交給依賴求解器處理我在這里踩過一個(gè)經(jīng)典坑為了某個(gè)別的插件強(qiáng)行顯式指定了 analyzer 版本結(jié)果 class_to_string 的生成器在運(yùn)行時(shí)報(bào)了一堆“類型參數(shù)不匹配”的錯(cuò)。后來(lái)把 analyzer 從 pubspec 里去掉讓 build_runner 自動(dòng)解析問題立刻消失。所以這個(gè)版本清單的核心建議是讓依賴求解器去決定 analyzer 的版本除非你確認(rèn)某個(gè)三方庫(kù)必須要特定版本否則不要手動(dòng)鎖。3. 核心實(shí)操讓 class_to_string 在鴻蒙工程里跑起來(lái)3.1 第一步在 pubspec.yaml 中正確聲明依賴打開鴻蒙 Flutter 工程的 pubspec.yaml把兩個(gè)依賴加進(jìn)去dependencies: class_to_string: ^1.2.0 dev_dependencies: build_runner: ^2.4.6 source_gen: ^1.4.0然后執(zhí)行flutter pub get。這一步正常的話說(shuō)明依賴解析階段沒有版本沖突class_to_string 的注解包已經(jīng)能進(jìn)了。如果你用的是鴻蒙 Flutter SDK 的分支pub get 的源和官方源基本一致不需要特殊配置。倒是有一個(gè)細(xì)節(jié)值得注意如果你在.dart_tool/package_config.json里看到 class_to_string 的 rootUri 指向了本地緩存說(shuō)明解析成功如果這一步就報(bào)錯(cuò)先檢查網(wǎng)絡(luò)環(huán)境和 pub 源不要急著改代碼。3.2 第二步給模型類打上注解給一個(gè)真實(shí)業(yè)務(wù)里的模型類加注解。以訂單模型為例import package:class_to_string/class_to_string.dart; ClassToString() class OrderModel { const OrderModel({ required this.orderNo, required this.amount, required this.status, this.remark, }); final String orderNo; final double amount; final String status; final String? remark; }這里我刻意沒有做任何額外配置先跑默認(rèn)行為。等默認(rèn)輸出符合預(yù)期了再去看字段排除、排序這些選項(xiàng)。不要一上來(lái)就堆一堆配置出了錯(cuò)反而不容易判斷是哪一步的問題。3.3 第三步執(zhí)行代碼生成命令處理可能的沖突在工程根目錄執(zhí)行flutter pub run build_runner build --delete-conflicting-outputs我習(xí)慣在命令后面帶上--delete-conflicting-outputs這個(gè)參數(shù)的意思是如果發(fā)現(xiàn)已生成的文件和當(dāng)前要生成的內(nèi)容存在沖突直接刪除重新生成。在鴻蒙工程里這個(gè)參數(shù)基本每次都要帶因?yàn)榇a生成器往往會(huì)因?yàn)樯弦淮螛?gòu)建殘留的緩存報(bào)類似 “Could not delete ... because it was used by another build”的錯(cuò)。跑完之后檢查一下輸出目錄你會(huì)看到對(duì)應(yīng)的.g.dart文件和class_to_string生成的擴(kuò)展代碼。生成器的速度一般很快幾秒鐘就完事。如果這個(gè)階段報(bào)了錯(cuò)參考后面第 4 章的排查記錄。3.4 第四步解讀生成代碼并在鴻蒙設(shè)備上驗(yàn)證打開生成的order_model.g.dart你會(huì)看到類似這樣的結(jié)構(gòu)// GENERATED CODE - DO NOT MODIFY BY HAND part of order_model.dart; extension OrderModelClassToString on OrderModel { String toClassString() { return OrderModel { orderNo: $orderNo, amount: $amount, status: $status, remark: $remark }; } }然后在模型類里重寫 toStringoverride String toString() toClassString();跑起來(lái)之后print(orderModel)的輸出就是OrderModel { orderNo: HO20240518001, amount: 299.0, status: pending, remark: null }我在鴻蒙模擬器上驗(yàn)證過輸出的中文和英文都沒有亂碼和 Android/iOS 端表現(xiàn)一致。這里有一個(gè)需要注意的點(diǎn)如果你的模型類同時(shí)用了part xxx.g.dart;指令生成文件的 import 路徑和 part 路徑要匹配。鴻蒙 Flutter 工程開始可能只是lib/main.dart我給你一個(gè)簡(jiǎn)單模板import package:class_to_string/class_to_string.dart; part order_model.g.dart; ClassToString() class OrderModel { // ... } extension OrderModelDisplay on OrderModel { override String toString() toClassString(); }這里把 toString 重寫放在單獨(dú)的 extension 里類本身保持干凈生成代碼變化時(shí)也比較好維護(hù)。4. 常見問題排查實(shí)錄我在適配中踩過的坑4.1 build_runner 在鴻蒙工程中的三個(gè)典型報(bào)錯(cuò)第一個(gè)是緩存問題。跑第二次 build 有時(shí)候會(huì)發(fā)現(xiàn)修改了模型類字段但是生成的字符串沒變化。這不是鴻蒙特有的而是 build_runner 的增量緩存機(jī)制造成的。解決辦法很粗暴刪除工程目錄下的.dart_tool/build文件夾重新跑一次生成命令。第二個(gè)是版本沖突。報(bào)錯(cuò)信息長(zhǎng)得很唬人類似Error: The non-abstract class ClassToStringGenerator is missing implementations for these members: Generator.generate這種九成是 source_gen 版本和 analyzer 版本不匹配別去改業(yè)務(wù)代碼。先執(zhí)行flutter pub deps看你當(dāng)前的 source_gen 和 analyzer 版本和 class_to_string 要求的版本區(qū)間對(duì)一下。我遇到的情況是 source_gen 1.4 和 analyzer 6.x 不搭把 pubspec 里 source_gen 的版本放開讓求解器自動(dòng)拉兼容版本。第三個(gè)是“找不到生成的擴(kuò)展方法”。生成文件存在你也 import 了但編譯報(bào)錯(cuò)說(shuō)toClassString未定義。這個(gè)坑比較低級(jí)但很隱蔽你在模型類里寫的part xxx.g.dart;和生成文件頭部聲明的part of xxx.dart;如果不一致生成代碼根本不會(huì)進(jìn)到當(dāng)前庫(kù)的作用域。檢查一下文件名是否完全一致包括大小寫這個(gè)在 Windows 和 macOS 上都可能出問題。4.2 生成代碼在鴻蒙側(cè)運(yùn)行時(shí)的三個(gè)隱藏問題運(yùn)行期我遇到過的第一個(gè)問題是 null 值顯示。默認(rèn)配置下值為 null 的字段會(huì)直接打印null。這看起來(lái)沒什么但當(dāng)字段多得時(shí)候一整排字段名: null會(huì)淹沒真正有問題的字段。我后面在實(shí)戰(zhàn)案例里會(huì)用fieldsToExclude把沒意義的字段過濾掉只保留需要追蹤的字段。第二個(gè)問題是嵌套對(duì)象的輸出可讀性。如果 OrderModel 里嵌了一個(gè) User 對(duì)象默認(rèn)生成的 toString 只會(huì)輸出user: Instance of User它不會(huì)自動(dòng)遞歸調(diào)用子對(duì)象的 toString。要讓嵌套對(duì)象也格式化輸出子對(duì)象自己也要加注解并重寫 toString或者在父級(jí)的配置里顯式聲明fieldsToInclude。這個(gè)思路在鴻蒙端和在其他端是一樣的但我在實(shí)際調(diào)試時(shí)發(fā)現(xiàn)很多人只給頂層對(duì)象加了注解最后一看日志“又是 Instance of”誤以為適配失敗。第三個(gè)問題是循環(huán)引用。有些模型會(huì)互相持有對(duì)方比如 Order 持有 UserUser 又有一個(gè)ListOrder。這種情況生成代碼本身沒做循環(huán)引用防護(hù)一旦遞歸深了會(huì)導(dǎo)致打印卡死。我當(dāng)時(shí)的處理方式是在關(guān)聯(lián)關(guān)系上標(biāo)記ClassToString(fieldsToExclude: [orders])避免把整棵對(duì)象圖打出來(lái)只保留你需要的信息。4.3 鴻蒙日志查看技巧怎么快速過濾出 Flutter 打印Flutter 在鴻蒙端打印日志最終會(huì)進(jìn)入 hilog 系統(tǒng)。在命令行里可以用hilog | grep flutter來(lái)過濾但更好的方式是直接看 DevEco Studio 的 Log 窗口它會(huì)把 Flutter 側(cè)的輸出和 ArkTS 側(cè)的輸出按進(jìn)程分開。還有一個(gè)很實(shí)用的組合真機(jī)上跑flutter run時(shí)保持 DevEco Studio 的調(diào)試會(huì)話不要關(guān)兩邊日志同時(shí)看。我在排查一個(gè) EventChannel 的數(shù)據(jù)傳遞問題時(shí)就是靠這個(gè)辦法同時(shí)看到了 Dart 側(cè)的格式化對(duì)象輸出和 ArkTS 側(cè)的原始數(shù)據(jù)很快就定位到是字符串編碼問題而不是業(yè)務(wù)邏輯問題。中文日志輸?shù)浇K端有時(shí)會(huì)顯示成\uXXXX轉(zhuǎn)義序列這個(gè)不要慌先確認(rèn)是不是日志收集框架統(tǒng)一做了轉(zhuǎn)義termial 上沒看到不代表數(shù)據(jù)有問題。直接print這種簡(jiǎn)單方式在 DevEco Studio 的 console 里一般都能正確顯示中文。5. 實(shí)戰(zhàn)案例嵌套模型與列表對(duì)象的 toString 調(diào)優(yōu)5.1 案例模型設(shè)計(jì)用一個(gè)真實(shí)的電商訂單場(chǎng)景來(lái)做演示三個(gè)類互相嵌套ClassToString() class User { const User({required this.id, required this.name}); final String id; final String name; } ClassToString(fieldsToExclude: [updatedAt]) class OrderItem { const OrderItem({required this.skuId, required this.title, required this.price, this.updatedAt}); final String skuId; final String title; final double price; final DateTime? updatedAt; } ClassToString() class OrderModel { const OrderModel({ required this.orderNo, required this.user, required this.items, this.remark, }); final String orderNo; final User user; final ListOrderItem items; final String? remark; }這里的要點(diǎn)是updatedAt這種對(duì)調(diào)試價(jià)值不大的字段直接通過fieldsToExclude過濾掉。不要讓調(diào)試輸出承載所有字段信息越多注意力越容易被稀釋。手寫版本如果老老實(shí)實(shí)寫大概是這樣的override String toString() { return OrderModel{orderNo$orderNo, user${user.id}-${user.name}, items${items.map((e) ${e.skuId}-${e.title}-${e.price}).toList()}, remark$remark}; }這個(gè)手寫版本的問題是user 對(duì)象只打了 id 和 name以后加了新字段得手動(dòng)回來(lái)改items 里的對(duì)象格式也沒有統(tǒng)一結(jié)構(gòu)。而 class_to_string 生成的版本只需要關(guān)注哪些字段要排除生成邏輯都是自動(dòng)的字段增刪后重新跑一次 build_runner 就行。5.2 生成效果與落地收獲生成后打印 OrderModel輸出效果是這樣的OrderModel { orderNo: HO20240518001, user: User { id: 10001, name: 張三 }, items: [OrderItem { skuId: SKU001, title: 商品A, price: 19.9 }, OrderItem { skuId: SKU002, title: 商品B, price: 99.0 }], remark: null }這比手寫版本直觀得多。每層對(duì)象都有自己的結(jié)構(gòu)每個(gè)字段名都顯示在值前面列表里每個(gè)元素獨(dú)立成段嵌套關(guān)系一目了然。我實(shí)測(cè)在幾十行日志里掃一眼就能定位到問題字段不用再像以前那樣數(shù)括號(hào)和逗號(hào)。5.3 性能與體積影響評(píng)估class_to_string 生成的是編譯期固定的字符串拼接代碼沒有反射調(diào)用所以運(yùn)行期性能可以認(rèn)為和手寫 toString 等價(jià)。我對(duì)比過同一次請(qǐng)求在鴻蒙設(shè)備上打印 100 個(gè)對(duì)象耗時(shí)差基本在噪聲范圍內(nèi)可以忽略不計(jì)。生成代碼的體積增量也很小。每個(gè)模型類的擴(kuò)展方法大概就幾行到十幾行即使全項(xiàng)目有上百個(gè)模型多出來(lái)的 Dart 代碼總量也不大對(duì)鴻蒙應(yīng)用包體積的影響基本可以忽略。這在我這種對(duì)包體積比較敏感的項(xiàng)目里是能放心引入的重要前提。6. 純 Dart 庫(kù)鴻蒙化適配的通用經(jīng)驗(yàn)6.1 快速判斷一個(gè) Dart 庫(kù)是否需要“真正適配”做完 class_to_string 之后我的總結(jié)是純 Dart 庫(kù)遷移到鴻蒙通常不需要改庫(kù)本身的代碼真正要做的是“構(gòu)建工程接入 運(yùn)行驗(yàn)證”。判斷方法很簡(jiǎn)單看依賴樹里有沒有dart:io、dart:ffi這種平臺(tái)相關(guān)庫(kù)看 pubspec 里是否依賴了 flutter 的 channel API看代碼里是否用了Platform.isAndroid這種運(yùn)行時(shí)平臺(tái)判斷。如果以上都沒有那這個(gè)庫(kù)大概率可以在鴻蒙工程里直接跑。你需要的流程就是加依賴、跑 pub get、寫一個(gè)最小調(diào)用驗(yàn)證、跑真機(jī)用例。class_to_string 適配完我順手又驗(yàn)證了 json_serializable 和 freezed這條流程同樣成立。如果庫(kù)確實(shí)用了dart:io或者調(diào)用了原生平臺(tái)能力那就要走插件適配路線去看插件包有沒有鴻蒙平臺(tái)的實(shí)現(xiàn)沒有的話可能要自己寫 platform view 或 eventchannel。這條路徑比純 Dart 適配復(fù)雜得多也更容易出問題涉及原生代碼調(diào)試時(shí)建議單獨(dú)梳理。6.2 我的個(gè)人經(jīng)驗(yàn)與建議最后分享幾個(gè)實(shí)際操作的體會(huì)。第一遇到生成類庫(kù)的問題先懷疑 Dart 版本再懷疑平臺(tái)適配問題。我在鴻蒙 Flutter 上踩過的大部分坑最終都是因?yàn)橐蕾嚢姹竞?Dart SDK 不匹配而不是鴻蒙系統(tǒng)做了什么特殊限制。flutter doctor和flutter --version打出來(lái)的第一行是你排查一切問題的起點(diǎn)。第二--delete-conflicting-outputs這個(gè)參數(shù)要學(xué)會(huì)看場(chǎng)景用。它確實(shí)能解決緩存沖突但它本質(zhì)上是“刪掉重來(lái)”的野蠻手段。如果生成文件里帶著你手工改過的東西刪掉之后這些改動(dòng)就沒了。我的做法是盡量不做任何手工修改生成文件實(shí)在要改就把生成邏輯改到注解配置里而不是直接改.g.dart。第三維護(hù)一個(gè)“鴻蒙適配依賴版本基線”文檔。不用很正式一個(gè)表格就夠了。把 class_to_string、build_runner、source_gen 這些和代碼生成相關(guān)的庫(kù)版本記下來(lái)最好附上你驗(yàn)證時(shí)的 Flutter 版本。團(tuán)隊(duì)里其他人遇到同樣問題時(shí)先把這份基線對(duì)一遍能省掉大量重復(fù)排坑的時(shí)間。這套流程跑通后我再移植其他純 Dart 庫(kù)就快多了。鴻蒙端的 Flutter 生態(tài)還在快速完善能用 Dart 解決的問題盡量用 Dart 解決至少在把核心業(yè)務(wù)邏輯從 Android/iOS 遷到鴻蒙的過程中開發(fā)體驗(yàn)?zāi)鼙３指叨纫恢隆? class_to_string鴻蒙化適配：讓Flutter對(duì)象調(diào)試一眼看清
調(diào)試 Flutter 應(yīng)用時(shí)最讓人頭大的場(chǎng)景之一就是日志里打出一個(gè)對(duì)象看到的卻只有Instance of User。字段值到底是什么、哪個(gè)字段為空、列表里裝了幾條數(shù)據(jù)全靠猜。更麻煩的是當(dāng)你開始手寫 toString() 的時(shí)候你會(huì)發(fā)現(xiàn)這活越寫越枯燥——字段少還好字段一多、嵌套一深toString 本身就成了一個(gè)需要維護(hù)的負(fù)擔(dān)。class_to_string 這個(gè) Flutter 三方庫(kù)就是用來(lái)終結(jié)這個(gè)局面的通過注解聲明配合代碼生成器自動(dòng)產(chǎn)出格式化的對(duì)象字符串讓對(duì)象調(diào)試從“盲猜”變成“一眼看清”。我最近在把 Flutter 項(xiàng)目遷到鴻蒙端正好把 class_to_string 從頭到尾做了一遍鴻蒙化適配。這篇文章記錄的就是這個(gè)過程環(huán)境怎么搭、依賴怎么選、代碼怎么生成、在鴻蒙上怎么驗(yàn)證、中間踩了哪些坑以及最終的實(shí)戰(zhàn)效果給同樣在折騰鴻蒙 Flutter 的同學(xué)做參考。1. 先搞明白class_to_string 到底解決了什么問題1.1 對(duì)象調(diào)試的核心痛點(diǎn)不在打印而在“信息密度”Dart 里所有對(duì)象都繼承自 ObjectObject 默認(rèn)的 toString() 只輸出類型名哈希值比如Instance of OrderModel。這在業(yè)務(wù)代碼里幾乎等于沒有信息。你真正想看到的是這個(gè)訂單號(hào)是多少、狀態(tài)字段是 pending 還是 paid、金額有沒有算對(duì)、列表里到底塞了幾個(gè)商品。于是大家開始手寫 toString()。但這里有個(gè)很現(xiàn)實(shí)的問題手寫 toString 的維護(hù)成本是隱性的。字段增刪改的時(shí)候toString 里的字符串拼接很容易漏改嵌套對(duì)象一復(fù)雜輸出就容易變成一長(zhǎng)串沒有縮進(jìn)的User(name: xx,address: Address(city: ...,province: ...))且不說(shuō)是中文還是英文肉眼根本不好定位。更麻煩的是一旦某個(gè)字段為 null手寫的 toString 還得自己處理空值顯示不然日志里飄出來(lái)一個(gè)null你根本不知道是哪個(gè)字段。這些問題在 Android/iOS 上存在在鴻蒙端一樣存在。Flutter 應(yīng)用要跑在鴻蒙上業(yè)務(wù)邏輯和模型層基本是原封不動(dòng)搬過去的調(diào)試體驗(yàn)也因此原封不動(dòng)地搬了過去。所以做鴻蒙化適配的時(shí)候我第一步就是把這些“開發(fā)期效率工具”補(bǔ)齊class_to_string 就是其中之一。1.2 注解 代碼生成class_to_string 的做法class_to_string 的思路很直白你在模型類上打一個(gè)ClassToString()注解它會(huì)在編譯期通過 build_runner 讀取這個(gè)注解然后自動(dòng)生成一個(gè)格式化輸出的擴(kuò)展方法。整個(gè)過程不依賴運(yùn)行時(shí)反射字段的讀取在生成代碼里就已經(jīng)寫死了所以性能和手寫 toString 基本沒有差別。典型用法是這樣的import package:class_to_string/class_to_string.dart; ClassToString( printFields: true, fieldsToExclude: [password], sortFields: true, ) class User { const User({ required this.id, required this.name, this.email, this.password , }); final String id; final String name; final String? email; final String password; }build_runner 跑完之后會(huì)自動(dòng)生成一個(gè)user.g.dart文件里面包含類似toClassString()的擴(kuò)展方法。我通常在業(yè)務(wù)基類里再補(bǔ)一層override String toString() toClassString();這樣一來(lái)無(wú)論是print(user)、日志框架還是斷言失敗的信息里拿到的都是完整、可讀、有字段名的格式化字符串。這個(gè)“基類統(tǒng)一重寫 生成器自動(dòng)展開”的組合是我在項(xiàng)目里比較推薦的用法因?yàn)樗磺秩肽Ｐ皖惖睦^承結(jié)構(gòu)生成代碼更新時(shí)也不用手動(dòng)去改 toString。1.3 為什么鴻蒙端同樣需要它可能有人會(huì)問鴻蒙端跑 Flutter調(diào)試工具那么多非得用 toString 嗎我的實(shí)際感受是日志和斷點(diǎn)解決的是不同層面的問題。斷點(diǎn)適合“我已經(jīng)知道大概哪里出了問題”日志適合“發(fā)生了什么、數(shù)據(jù)流經(jīng)過了什么、狀態(tài)變成了什么”。在鴻蒙端調(diào)試跨端問題時(shí)尤其如此——你往往要同時(shí)看 ArkTS 原生側(cè)的日志和 Flutter 側(cè)的業(yè)務(wù)日志兩邊時(shí)間線一對(duì)應(yīng)才能定位到是橋接層出的問題還是 Dart 層數(shù)據(jù)就不對(duì)。這時(shí)候如果 Dart 側(cè)打出來(lái)的對(duì)象是Instance of OrderModel整個(gè)排查鏈路就直接斷在最有信息量的那一步。另外還有一個(gè)很實(shí)際的場(chǎng)景線上問題排查。很多團(tuán)隊(duì)的線上日志系統(tǒng)只收集應(yīng)用內(nèi)日志對(duì)象如果不格式化輸出上報(bào)回來(lái)的就是一堆無(wú)意義的Instance of。class_to_string 生成的內(nèi)容在編譯期確定沒有反射開銷打進(jìn)日志里也不會(huì)有性能顧慮。2. 鴻蒙化適配前先盤清楚依賴和環(huán)境2.1 鴻蒙 Flutter 開發(fā)環(huán)境長(zhǎng)什么樣鴻蒙端的 Flutter 開發(fā)環(huán)境和官方的 Flutter 有一點(diǎn)區(qū)別。你需要準(zhǔn)備三塊東西DevEco Studio鴻蒙應(yīng)用開發(fā)工具鏈、鴻蒙系統(tǒng)的 SDK通常是隨 DevEco 或命令行工具鏈提供、以及支持 OpenHarmony/HarmonyOS 平臺(tái)的 Flutter SDK 分支。工程結(jié)構(gòu)和 Android 工程最明顯的差異是項(xiàng)目根目錄下會(huì)多出一個(gè)ohos/目錄里面是 ArkTS 原生殼工程。Flutter 側(cè)的lib/、pubspec.yaml、build_runner配置都在上層目錄但最終要跑上鴻蒙設(shè)備需要原生殼工程配合打包。我建議在動(dòng)手適配之前先把你當(dāng)前的 Flutter SDK 版本和鴻蒙 SDK 版本記下來(lái)因?yàn)榇a生成類的三方庫(kù)對(duì) Dart SDK 版本很敏感。我當(dāng)時(shí)用的 Flutter SDK 是鴻蒙適配版Dart 版本在 3.x 左右class_to_string 的生成代碼依賴 Dart 的 extension 語(yǔ)法這個(gè)版本門檻還好但后面要拉源碼生成器時(shí)對(duì) analyzer 和 source_gen 的版本兼容性要求才是真正要小心的點(diǎn)。2.2 class_to_string 的依賴鏈條拆解class_to_string 并不是一個(gè)單文件庫(kù)它由兩部分組成一個(gè)是業(yè)務(wù)代碼里引用的注解定義另一個(gè)是 build_runner 要加載的代碼生成器。后者依賴 source_gen、build_runner、analyzer 這一套代碼生成生態(tài)。關(guān)鍵信息是這套依賴幾乎全是純 Dart 實(shí)現(xiàn)不涉及 platform channel也不涉及 dart:io 的原生能力。也就是說(shuō)class_to_string 的適配重點(diǎn)不在“運(yùn)行時(shí)”而在“構(gòu)建期”。只要 build_runner 能在鴻蒙 Flutter 工程里跑起來(lái)生成代碼能通過編譯運(yùn)行時(shí)就基本不存在平臺(tái)差異。這一點(diǎn)很重要它決定了我后續(xù)的適配策略先保證 pub 依賴能正確解析再跑通 build_runner最后真機(jī)驗(yàn)證。不需要像適配 flutter_platformview 或者 eventchannel 插件那樣去改原生代碼。2.3 版本兼容性檢查清單在往 pubspec.yaml 里寫依賴之前我習(xí)慣先列一個(gè)版本兼容性清單。class_to_string 本身作為業(yè)務(wù)依賴放到dependencies里build_runner 和代碼生成器需要的 source_gen 要放到dev_dependencies里。依賴項(xiàng)放置位置版本建議說(shuō)明class_to_stringdependencies鎖定一個(gè)你驗(yàn)證過的穩(wěn)定版本注解庫(kù)build_runnerdev_dependencies2.4.x 或?qū)?yīng)兼容版本代碼生成入口source_gendev_dependencies與 build_runner 匹配的版本生成器核心依賴analyzerdev_dependencies由 build_runner 間接引入版本沖突重災(zāi)區(qū)盡量不要顯式指定版本交給依賴求解器處理我在這里踩過一個(gè)經(jīng)典坑為了某個(gè)別的插件強(qiáng)行顯式指定了 analyzer 版本結(jié)果 class_to_string 的生成器在運(yùn)行時(shí)報(bào)了一堆“類型參數(shù)不匹配”的錯(cuò)。后來(lái)把 analyzer 從 pubspec 里去掉讓 build_runner 自動(dòng)解析問題立刻消失。所以這個(gè)版本清單的核心建議是讓依賴求解器去決定 analyzer 的版本除非你確認(rèn)某個(gè)三方庫(kù)必須要特定版本否則不要手動(dòng)鎖。3. 核心實(shí)操讓 class_to_string 在鴻蒙工程里跑起來(lái)3.1 第一步在 pubspec.yaml 中正確聲明依賴打開鴻蒙 Flutter 工程的 pubspec.yaml把兩個(gè)依賴加進(jìn)去dependencies: class_to_string: ^1.2.0 dev_dependencies: build_runner: ^2.4.6 source_gen: ^1.4.0然后執(zhí)行flutter pub get。這一步正常的話說(shuō)明依賴解析階段沒有版本沖突class_to_string 的注解包已經(jīng)能進(jìn)了。如果你用的是鴻蒙 Flutter SDK 的分支pub get 的源和官方源基本一致不需要特殊配置。倒是有一個(gè)細(xì)節(jié)值得注意如果你在.dart_tool/package_config.json里看到 class_to_string 的 rootUri 指向了本地緩存說(shuō)明解析成功如果這一步就報(bào)錯(cuò)先檢查網(wǎng)絡(luò)環(huán)境和 pub 源不要急著改代碼。3.2 第二步給模型類打上注解給一個(gè)真實(shí)業(yè)務(wù)里的模型類加注解。以訂單模型為例import package:class_to_string/class_to_string.dart; ClassToString() class OrderModel { const OrderModel({ required this.orderNo, required this.amount, required this.status, this.remark, }); final String orderNo; final double amount; final String status; final String? remark; }這里我刻意沒有做任何額外配置先跑默認(rèn)行為。等默認(rèn)輸出符合預(yù)期了再去看字段排除、排序這些選項(xiàng)。不要一上來(lái)就堆一堆配置出了錯(cuò)反而不容易判斷是哪一步的問題。3.3 第三步執(zhí)行代碼生成命令處理可能的沖突在工程根目錄執(zhí)行flutter pub run build_runner build --delete-conflicting-outputs我習(xí)慣在命令后面帶上--delete-conflicting-outputs這個(gè)參數(shù)的意思是如果發(fā)現(xiàn)已生成的文件和當(dāng)前要生成的內(nèi)容存在沖突直接刪除重新生成。在鴻蒙工程里這個(gè)參數(shù)基本每次都要帶因?yàn)榇a生成器往往會(huì)因?yàn)樯弦淮螛?gòu)建殘留的緩存報(bào)類似 “Could not delete ... because it was used by another build”的錯(cuò)。跑完之后檢查一下輸出目錄你會(huì)看到對(duì)應(yīng)的.g.dart文件和class_to_string生成的擴(kuò)展代碼。生成器的速度一般很快幾秒鐘就完事。如果這個(gè)階段報(bào)了錯(cuò)參考后面第 4 章的排查記錄。3.4 第四步解讀生成代碼并在鴻蒙設(shè)備上驗(yàn)證打開生成的order_model.g.dart你會(huì)看到類似這樣的結(jié)構(gòu)// GENERATED CODE - DO NOT MODIFY BY HAND part of order_model.dart; extension OrderModelClassToString on OrderModel { String toClassString() { return OrderModel { orderNo: $orderNo, amount: $amount, status: $status, remark: $remark }; } }然后在模型類里重寫 toStringoverride String toString() toClassString();跑起來(lái)之后print(orderModel)的輸出就是OrderModel { orderNo: HO20240518001, amount: 299.0, status: pending, remark: null }我在鴻蒙模擬器上驗(yàn)證過輸出的中文和英文都沒有亂碼和 Android/iOS 端表現(xiàn)一致。這里有一個(gè)需要注意的點(diǎn)如果你的模型類同時(shí)用了part xxx.g.dart;指令生成文件的 import 路徑和 part 路徑要匹配。鴻蒙 Flutter 工程開始可能只是lib/main.dart我給你一個(gè)簡(jiǎn)單模板import package:class_to_string/class_to_string.dart; part order_model.g.dart; ClassToString() class OrderModel { // ... } extension OrderModelDisplay on OrderModel { override String toString() toClassString(); }這里把 toString 重寫放在單獨(dú)的 extension 里類本身保持干凈生成代碼變化時(shí)也比較好維護(hù)。4. 常見問題排查實(shí)錄我在適配中踩過的坑4.1 build_runner 在鴻蒙工程中的三個(gè)典型報(bào)錯(cuò)第一個(gè)是緩存問題。跑第二次 build 有時(shí)候會(huì)發(fā)現(xiàn)修改了模型類字段但是生成的字符串沒變化。這不是鴻蒙特有的而是 build_runner 的增量緩存機(jī)制造成的。解決辦法很粗暴刪除工程目錄下的.dart_tool/build文件夾重新跑一次生成命令。第二個(gè)是版本沖突。報(bào)錯(cuò)信息長(zhǎng)得很唬人類似Error: The non-abstract class ClassToStringGenerator is missing implementations for these members: Generator.generate這種九成是 source_gen 版本和 analyzer 版本不匹配別去改業(yè)務(wù)代碼。先執(zhí)行flutter pub deps看你當(dāng)前的 source_gen 和 analyzer 版本和 class_to_string 要求的版本區(qū)間對(duì)一下。我遇到的情況是 source_gen 1.4 和 analyzer 6.x 不搭把 pubspec 里 source_gen 的版本放開讓求解器自動(dòng)拉兼容版本。第三個(gè)是“找不到生成的擴(kuò)展方法”。生成文件存在你也 import 了但編譯報(bào)錯(cuò)說(shuō)toClassString未定義。這個(gè)坑比較低級(jí)但很隱蔽你在模型類里寫的part xxx.g.dart;和生成文件頭部聲明的part of xxx.dart;如果不一致生成代碼根本不會(huì)進(jìn)到當(dāng)前庫(kù)的作用域。檢查一下文件名是否完全一致包括大小寫這個(gè)在 Windows 和 macOS 上都可能出問題。4.2 生成代碼在鴻蒙側(cè)運(yùn)行時(shí)的三個(gè)隱藏問題運(yùn)行期我遇到過的第一個(gè)問題是 null 值顯示。默認(rèn)配置下值為 null 的字段會(huì)直接打印null。這看起來(lái)沒什么但當(dāng)字段多得時(shí)候一整排字段名: null會(huì)淹沒真正有問題的字段。我后面在實(shí)戰(zhàn)案例里會(huì)用fieldsToExclude把沒意義的字段過濾掉只保留需要追蹤的字段。第二個(gè)問題是嵌套對(duì)象的輸出可讀性。如果 OrderModel 里嵌了一個(gè) User 對(duì)象默認(rèn)生成的 toString 只會(huì)輸出user: Instance of User它不會(huì)自動(dòng)遞歸調(diào)用子對(duì)象的 toString。要讓嵌套對(duì)象也格式化輸出子對(duì)象自己也要加注解并重寫 toString或者在父級(jí)的配置里顯式聲明fieldsToInclude。這個(gè)思路在鴻蒙端和在其他端是一樣的但我在實(shí)際調(diào)試時(shí)發(fā)現(xiàn)很多人只給頂層對(duì)象加了注解最后一看日志“又是 Instance of”誤以為適配失敗。第三個(gè)問題是循環(huán)引用。有些模型會(huì)互相持有對(duì)方比如 Order 持有 UserUser 又有一個(gè)ListOrder。這種情況生成代碼本身沒做循環(huán)引用防護(hù)一旦遞歸深了會(huì)導(dǎo)致打印卡死。我當(dāng)時(shí)的處理方式是在關(guān)聯(lián)關(guān)系上標(biāo)記ClassToString(fieldsToExclude: [orders])避免把整棵對(duì)象圖打出來(lái)只保留你需要的信息。4.3 鴻蒙日志查看技巧怎么快速過濾出 Flutter 打印Flutter 在鴻蒙端打印日志最終會(huì)進(jìn)入 hilog 系統(tǒng)。在命令行里可以用hilog | grep flutter來(lái)過濾但更好的方式是直接看 DevEco Studio 的 Log 窗口它會(huì)把 Flutter 側(cè)的輸出和 ArkTS 側(cè)的輸出按進(jìn)程分開。還有一個(gè)很實(shí)用的組合真機(jī)上跑flutter run時(shí)保持 DevEco Studio 的調(diào)試會(huì)話不要關(guān)兩邊日志同時(shí)看。我在排查一個(gè) EventChannel 的數(shù)據(jù)傳遞問題時(shí)就是靠這個(gè)辦法同時(shí)看到了 Dart 側(cè)的格式化對(duì)象輸出和 ArkTS 側(cè)的原始數(shù)據(jù)很快就定位到是字符串編碼問題而不是業(yè)務(wù)邏輯問題。中文日志輸?shù)浇K端有時(shí)會(huì)顯示成\uXXXX轉(zhuǎn)義序列這個(gè)不要慌先確認(rèn)是不是日志收集框架統(tǒng)一做了轉(zhuǎn)義termial 上沒看到不代表數(shù)據(jù)有問題。直接print這種簡(jiǎn)單方式在 DevEco Studio 的 console 里一般都能正確顯示中文。5. 實(shí)戰(zhàn)案例嵌套模型與列表對(duì)象的 toString 調(diào)優(yōu)5.1 案例模型設(shè)計(jì)用一個(gè)真實(shí)的電商訂單場(chǎng)景來(lái)做演示三個(gè)類互相嵌套ClassToString() class User { const User({required this.id, required this.name}); final String id; final String name; } ClassToString(fieldsToExclude: [updatedAt]) class OrderItem { const OrderItem({required this.skuId, required this.title, required this.price, this.updatedAt}); final String skuId; final String title; final double price; final DateTime? updatedAt; } ClassToString() class OrderModel { const OrderModel({ required this.orderNo, required this.user, required this.items, this.remark, }); final String orderNo; final User user; final ListOrderItem items; final String? remark; }這里的要點(diǎn)是updatedAt這種對(duì)調(diào)試價(jià)值不大的字段直接通過fieldsToExclude過濾掉。不要讓調(diào)試輸出承載所有字段信息越多注意力越容易被稀釋。手寫版本如果老老實(shí)實(shí)寫大概是這樣的override String toString() { return OrderModel{orderNo$orderNo, user${user.id}-${user.name}, items${items.map((e) ${e.skuId}-${e.title}-${e.price}).toList()}, remark$remark}; }這個(gè)手寫版本的問題是user 對(duì)象只打了 id 和 name以后加了新字段得手動(dòng)回來(lái)改items 里的對(duì)象格式也沒有統(tǒng)一結(jié)構(gòu)。而 class_to_string 生成的版本只需要關(guān)注哪些字段要排除生成邏輯都是自動(dòng)的字段增刪后重新跑一次 build_runner 就行。5.2 生成效果與落地收獲生成后打印 OrderModel輸出效果是這樣的OrderModel { orderNo: HO20240518001, user: User { id: 10001, name: 張三 }, items: [OrderItem { skuId: SKU001, title: 商品A, price: 19.9 }, OrderItem { skuId: SKU002, title: 商品B, price: 99.0 }], remark: null }這比手寫版本直觀得多。每層對(duì)象都有自己的結(jié)構(gòu)每個(gè)字段名都顯示在值前面列表里每個(gè)元素獨(dú)立成段嵌套關(guān)系一目了然。我實(shí)測(cè)在幾十行日志里掃一眼就能定位到問題字段不用再像以前那樣數(shù)括號(hào)和逗號(hào)。5.3 性能與體積影響評(píng)估class_to_string 生成的是編譯期固定的字符串拼接代碼沒有反射調(diào)用所以運(yùn)行期性能可以認(rèn)為和手寫 toString 等價(jià)。我對(duì)比過同一次請(qǐng)求在鴻蒙設(shè)備上打印 100 個(gè)對(duì)象耗時(shí)差基本在噪聲范圍內(nèi)可以忽略不計(jì)。生成代碼的體積增量也很小。每個(gè)模型類的擴(kuò)展方法大概就幾行到十幾行即使全項(xiàng)目有上百個(gè)模型多出來(lái)的 Dart 代碼總量也不大對(duì)鴻蒙應(yīng)用包體積的影響基本可以忽略。這在我這種對(duì)包體積比較敏感的項(xiàng)目里是能放心引入的重要前提。6. 純 Dart 庫(kù)鴻蒙化適配的通用經(jīng)驗(yàn)6.1 快速判斷一個(gè) Dart 庫(kù)是否需要“真正適配”做完 class_to_string 之后我的總結(jié)是純 Dart 庫(kù)遷移到鴻蒙通常不需要改庫(kù)本身的代碼真正要做的是“構(gòu)建工程接入 運(yùn)行驗(yàn)證”。判斷方法很簡(jiǎn)單看依賴樹里有沒有dart:io、dart:ffi這種平臺(tái)相關(guān)庫(kù)看 pubspec 里是否依賴了 flutter 的 channel API看代碼里是否用了Platform.isAndroid這種運(yùn)行時(shí)平臺(tái)判斷。如果以上都沒有那這個(gè)庫(kù)大概率可以在鴻蒙工程里直接跑。你需要的流程就是加依賴、跑 pub get、寫一個(gè)最小調(diào)用驗(yàn)證、跑真機(jī)用例。class_to_string 適配完我順手又驗(yàn)證了 json_serializable 和 freezed這條流程同樣成立。如果庫(kù)確實(shí)用了dart:io或者調(diào)用了原生平臺(tái)能力那就要走插件適配路線去看插件包有沒有鴻蒙平臺(tái)的實(shí)現(xiàn)沒有的話可能要自己寫 platform view 或 eventchannel。這條路徑比純 Dart 適配復(fù)雜得多也更容易出問題涉及原生代碼調(diào)試時(shí)建議單獨(dú)梳理。6.2 我的個(gè)人經(jīng)驗(yàn)與建議最后分享幾個(gè)實(shí)際操作的體會(huì)。第一遇到生成類庫(kù)的問題先懷疑 Dart 版本再懷疑平臺(tái)適配問題。我在鴻蒙 Flutter 上踩過的大部分坑最終都是因?yàn)橐蕾嚢姹竞?Dart SDK 不匹配而不是鴻蒙系統(tǒng)做了什么特殊限制。flutter doctor和flutter --version打出來(lái)的第一行是你排查一切問題的起點(diǎn)。第二--delete-conflicting-outputs這個(gè)參數(shù)要學(xué)會(huì)看場(chǎng)景用。它確實(shí)能解決緩存沖突但它本質(zhì)上是“刪掉重來(lái)”的野蠻手段。如果生成文件里帶著你手工改過的東西刪掉之后這些改動(dòng)就沒了。我的做法是盡量不做任何手工修改生成文件實(shí)在要改就把生成邏輯改到注解配置里而不是直接改.g.dart。第三維護(hù)一個(gè)“鴻蒙適配依賴版本基線”文檔。不用很正式一個(gè)表格就夠了。把 class_to_string、build_runner、source_gen 這些和代碼生成相關(guān)的庫(kù)版本記下來(lái)最好附上你驗(yàn)證時(shí)的 Flutter 版本。團(tuán)隊(duì)里其他人遇到同樣問題時(shí)先把這份基線對(duì)一遍能省掉大量重復(fù)排坑的時(shí)間。這套流程跑通后我再移植其他純 Dart 庫(kù)就快多了。鴻蒙端的 Flutter 生態(tài)還在快速完善能用 Dart 解決的問題盡量用 Dart 解決至少在把核心業(yè)務(wù)邏輯從 Android/iOS 遷到鴻蒙的過程中開發(fā)體驗(yàn)?zāi)鼙３指叨纫恢隆?