上個(gè)月我把一個(gè)用Flutter寫的小工具往OpenHarmony設(shè)備上遷移原本以為最麻煩的會(huì)是構(gòu)建腳本和平臺(tái)適配結(jié)果真正花掉大半天的是一堆Dart變量和類型相關(guān)的運(yùn)行時(shí)報(bào)錯(cuò)。這也是我為什么想專門寫一篇關(guān)于Flutter for OpenHarmony實(shí)戰(zhàn)中Dart基礎(chǔ)的內(nèi)容很多人是在項(xiàng)目里直接上手寫界面對(duì)Dart的類型系統(tǒng)沒有系統(tǒng)過一遍一旦進(jìn)入OpenHarmony這種需要頻繁與原生平臺(tái)交換數(shù)據(jù)的場景變量聲明、空安全、類型轉(zhuǎn)換這些基本功就成了攔路虎。這篇內(nèi)容適合正在把Flutter工程遷到OpenHarmony的開發(fā)者也適合剛開始學(xué)Dart、想知道變量到底該怎么聲明的朋友。我會(huì)把Dart的變量聲明方式、內(nèi)置數(shù)據(jù)類型、空安全與類型轉(zhuǎn)換全部串起來講并且把我在真機(jī)上踩過的坑放在后面。1. 為什么Flutter能跑在OpenHarmony上開發(fā)環(huán)境要留意什么1.1 Flutter在OpenHarmony上的運(yùn)行原理很多人有個(gè)誤解覺得Flutter能跨平臺(tái)是因?yàn)樗迅飨到y(tǒng)的原生控件包了一層。其實(shí)Flutter的UI不是用系統(tǒng)控件畫的而是由Flutter引擎自己負(fù)責(zé)布局、繪制和合成Dart代碼只負(fù)責(zé)描述UI結(jié)構(gòu)、狀態(tài)和業(yè)務(wù)邏輯。Dart代碼經(jīng)過AOT或JIT編譯后運(yùn)行在Flutter引擎里引擎再把繪制指令交給底層圖形接口。所以要讓Flutter跑在OpenHarmony上核心工作是把Flutter引擎適配到OpenHarmony的圖形棧和系統(tǒng)服務(wù)上而不是把每個(gè)控件都翻譯成OpenHarmony的組件。這也是為什么現(xiàn)在OpenHarmony上使用Flutter通常不是直接用官方的Flutter SDK而是使用社區(qū)為OpenHarmony做適配的Flutter分支。你在工程里依然用Dart寫業(yè)務(wù)、寫UI用Flutter的組件模型構(gòu)建時(shí)再通過OpenHarmony的編譯工具鏈生成對(duì)應(yīng)平臺(tái)的產(chǎn)物。理解了這一層你就知道為什么Dart基礎(chǔ)在OpenHarmony上同樣重要界面和邏輯仍然全部跑在Dart側(cè)平臺(tái)只是提供系統(tǒng)能力和事件的出口。1.2 搭環(huán)境時(shí)的三個(gè)關(guān)鍵點(diǎn)如果你打算自己搭一套Flutter for OpenHarmony環(huán)境我建議重點(diǎn)盯住三件事。第一是版本對(duì)齊。Flutter官方版本更新很快而OpenHarmony適配分支通常落后于官方版本不能拿到一個(gè)最新Flutter就往適配分支上綁。建議先確認(rèn)適配分支支持的Flutter版本再根據(jù)它選擇合適的Dart SDK。否則構(gòu)建時(shí)往往會(huì)出現(xiàn)版本不匹配的提示這種報(bào)錯(cuò)一般不是代碼問題是環(huán)境問題。第二是SDK路徑和環(huán)境變量。除了Flutter SDK還要安裝OpenHarmony的SDK并讓構(gòu)建工具能找到它。不同年代的工具鏈配置方式差別挺大動(dòng)手之前先看對(duì)應(yīng)適配分支的README比在網(wǎng)上找舊教程更靠譜。我在第一次配置時(shí)就是照著舊文章寫了環(huán)境變量結(jié)果路徑對(duì)不上折騰了半天才發(fā)現(xiàn)是SDK目錄結(jié)構(gòu)和文檔里描述的不一樣。第三是工程結(jié)構(gòu)。OpenHarmony工程通常有自己的構(gòu)建描述文件與標(biāo)準(zhǔn)Flutter工程目錄不完全一樣。實(shí)際操作中很多人是先把Flutter業(yè)務(wù)代碼放在一個(gè)獨(dú)立模塊里再由OpenHarmony主工程引用這樣Dart側(cè)代碼可以盡量保持純凈平臺(tái)相關(guān)代碼單獨(dú)放。這個(gè)結(jié)構(gòu)在調(diào)試時(shí)也清爽Dart邏輯問題在Flutter側(cè)定位系統(tǒng)能力調(diào)用問題在平臺(tái)側(cè)定位不用在一個(gè)目錄里來回翻。2. Dart變量聲明var、final、const、dynamic到底怎么選2.1 var是類型推斷不是“無類型”我經(jīng)常在代碼評(píng)審里看到有人把var理解成“隨便一個(gè)類型”這可能是從JavaScript帶過來的習(xí)慣。Dart里的var其實(shí)是一種簡寫編譯器會(huì)根據(jù)右邊的初始值推斷出變量類型一旦推斷完成這個(gè)變量的類型就固定了。比如你寫var count 10;編譯器會(huì)認(rèn)為count是int后面再寫count hello;就會(huì)報(bào)類型不匹配。這個(gè)設(shè)計(jì)和C的auto、Java 10的var思路一致目的是減少冗余的類型標(biāo)注而不是放棄類型安全。所以當(dāng)你看到一段Dart代碼里到處都是var時(shí)不要以為它在做動(dòng)態(tài)語言的事它仍然被靜態(tài)類型系統(tǒng)管著。區(qū)別在于顯式寫int count讓你一眼看到類型寫var count則需要根據(jù)上下文推斷對(duì)閱讀者來說理解成本略高一點(diǎn)。我在OpenHarmony工程里寫公共模型類時(shí)會(huì)盡量用顯式類型因?yàn)槎嗳藚f(xié)作時(shí)類型本身就是一種文檔一眼看過去就知道這個(gè)字段是整型、字符串還是日期比翻實(shí)現(xiàn)快得多。2.2 final和const兩種“不可變”的區(qū)別很多人知道final和const都表示“不能改”但不知道它們的關(guān)鍵區(qū)別。final變量在運(yùn)行時(shí)確定值一旦賦值就不可變const變量在編譯期就確定了值而且會(huì)被當(dāng)作編譯期常量處理。簡單記凡是能用const的地方它一定滿足final的要求但反過來不一定比如你需要在程序啟動(dòng)后才獲取當(dāng)前時(shí)間并存下來那只能用final因?yàn)闀r(shí)間在編譯期是未知的。為什么這個(gè)區(qū)別在Flutter for OpenHarmony里很重要因?yàn)镕lutter控件大量使用const構(gòu)造來減少不必要的重建。一個(gè)控件如果能在編譯期確定結(jié)構(gòu)和參數(shù)就可以標(biāo)記為constFlutter引擎就能復(fù)用它的實(shí)例減少每一幀的構(gòu)建開銷。你在看高性能Flutter代碼時(shí)會(huì)發(fā)現(xiàn)const Text(xxx)、const EdgeInsets.all(8)特別多這就是在利用Dart的編譯期常量特性。類比一下final像“結(jié)婚戒指”定了就不能換const更像“說明書上的參數(shù)”出廠時(shí)就印好了。兩者都幫你減少可變狀態(tài)但const在性能上還多了一層收益。2.3 dynamic和Object能不用就不用Dart里有兩個(gè)容易混淆的“什么都能裝”的類型dynamic和Object。dynamic會(huì)告訴編譯器“我不管這個(gè)變量的類型你也別檢查我”這相當(dāng)于把靜態(tài)類型系統(tǒng)暫時(shí)關(guān)閉了變量可以指向任意對(duì)象也可以調(diào)用任意方法但編譯時(shí)不報(bào)錯(cuò)不代表運(yùn)行時(shí)沒問題。Object是所有類型的基類它可以接收任何對(duì)象然而編譯器只允許你調(diào)用Object上定義的方法想調(diào)用具體類型的方法必須做類型轉(zhuǎn)換。用生活例子說dynamic像一個(gè)沒有任何標(biāo)簽的箱子你不打開看永遠(yuǎn)不知道里面是什么Object像一個(gè)大箱子你知道它里面裝的都是“東西”但要取出具體物品得先開封檢查。在OpenHarmony的MethodChannel回調(diào)里平臺(tái)返回的數(shù)據(jù)經(jīng)常是Mapdynamic, dynamic或Listdynamic這其實(shí)是平臺(tái)通道的固有特性不是Dart語言的問題處理時(shí)我們通常會(huì)先做類型收窄而不是把dynamic往業(yè)務(wù)代碼里傳。2.4 一套實(shí)用的變量聲明策略基于上面的對(duì)比我在寫Dart代碼時(shí)有一套自己的優(yōu)先級(jí)能定義成const就先定義成const定義不了就考慮final再不行才用var只有極少數(shù)與平臺(tái)交互且動(dòng)態(tài)生成的地方才用dynamic。這條策略在OpenHarmony項(xiàng)目里尤其好用因?yàn)槠脚_(tái)通道把數(shù)據(jù)從原生側(cè)傳回來時(shí)很多值其實(shí)是確定的只是Dart編譯器不知道這時(shí)通過顯式類型和空安全處理把它們“固定”下來后面維護(hù)起來會(huì)很舒服。另外聲明集合時(shí)也要注意可變性。final list [1, 2, 3];表示list這個(gè)引用不能換但list本身的內(nèi)容還是可以增刪改因?yàn)槟J(rèn)的List字面量是可變的。如果你想要一個(gè)完全不可變的列表應(yīng)該用const [1, 2, 3]或者List.unmodifiable(...)。這個(gè)區(qū)別在UI狀態(tài)管理里非常常見用final修飾列表卻仍然能add元素往往會(huì)導(dǎo)致界面沒有按預(yù)期更新因?yàn)橥獠靠雌饋硪脹]變Flutter的組件比較就認(rèn)為狀態(tài)沒有變化。3. Dart內(nèi)置數(shù)據(jù)類型全景從數(shù)值到集合類型的實(shí)戰(zhàn)細(xì)節(jié)3.1 數(shù)值類型int與double運(yùn)算和轉(zhuǎn)換的坑Dart的數(shù)值類型主要有num、int和double。num是int和double的父類型在寫通用工具時(shí)可以用num接收整數(shù)或浮點(diǎn)。int在原生環(huán)境下通常對(duì)應(yīng)64位整型double對(duì)應(yīng)64位浮點(diǎn)所以精度問題在Dart里同樣存在尤其是浮點(diǎn)運(yùn)算不要用if (a b)直接比較兩個(gè)浮點(diǎn)數(shù)應(yīng)該比較差值是否小于一個(gè)很小的閾值否則很容易因?yàn)榫日`差得到錯(cuò)誤結(jié)果。更常見的坑是運(yùn)算符。很多從C或Java過來的同學(xué)會(huì)以為1 / 2等于0因?yàn)檎麛?shù)除法但在Dart里/永遠(yuǎn)返回double想要整數(shù)除法必須用~/取余用%。這在一開始寫業(yè)務(wù)邏輯時(shí)很容易不知不覺踩進(jìn)去比如計(jì)算分頁totalPage totalItem / pageSize得到的是double直接賦給int會(huì)報(bào)錯(cuò)必須改成totalItem ~/ pageSize或者顯式取整。類型轉(zhuǎn)換也有一些要注意的地方。字符串轉(zhuǎn)數(shù)字用int.parse()或double.parse()數(shù)字轉(zhuǎn)字符串用toString()和toStringAsFixed()。把double轉(zhuǎn)int時(shí)有round()、floor()、ceil()三種取整方式指定用哪個(gè)要結(jié)合業(yè)務(wù)。我記得有一次在OpenHarmony設(shè)備上處理傳感器返回的數(shù)值原生那邊傳過來一個(gè)小數(shù)我在Dart里直接toInt()結(jié)果因?yàn)閿?shù)值可能是NaN或無窮大直接拋了異常。所以寫轉(zhuǎn)換代碼前先想清楚這個(gè)值能不能轉(zhuǎn)轉(zhuǎn)換前最好用isFinite檢查一下。3.2 字符串插值、多行和編碼Dart的字符串和大多數(shù)語言相比有一點(diǎn)特別舒服插值直接寫在字符串里。$變量名可以嵌入單個(gè)變量${表達(dá)式}可以嵌入復(fù)雜表達(dá)式。比如print(版本: ${engine.version}, 任務(wù)數(shù): ${tasks.length})。這樣就不用像Java那樣拼一堆加號(hào)了。這個(gè)特性在寫日志時(shí)尤其好用錯(cuò)誤信息里的變量、狀態(tài)、參數(shù)都能拼在一個(gè)字符串里一眼看清當(dāng)時(shí)的情況。字符串也可以用單引號(hào)或雙引號(hào)兩者沒有區(qū)別純個(gè)人習(xí)慣。多行字符串用三個(gè)單引號(hào)或三個(gè)雙引號(hào)括起來可以保留換行和縮進(jìn)這在寫一些格式化的日志或模板時(shí)很實(shí)用。raw raw string在Dart里是前綴r寫在字符串前面的r表示不處理轉(zhuǎn)義字符比如rC:\path\to\file在OpenHarmony上拼文件路徑時(shí)特別有用可以少寫很多反斜杠轉(zhuǎn)義。要注意的是編碼問題。在OpenHarmony平臺(tái)通道中如果原生返回的是字節(jié)數(shù)組需要明確用UTF-8解碼Dart側(cè)一般用utf8.decode(bytes)寫文件時(shí)再utf8.encode(string)。因?yàn)镈art的String是UTF-16編碼存儲(chǔ)的與原生端的字節(jié)編碼不一致很多亂碼問題就出現(xiàn)在這里。也不要直接對(duì)一個(gè)String執(zhí)行逐個(gè)字節(jié)的下標(biāo)操作因?yàn)榭赡芮性诖韺?duì)中間導(dǎo)致字符顯示異常。3.3 List、Set、Map集合類型的正確打開方式集合類型是日常開發(fā)里用得最多的數(shù)據(jù)類型。List是有序列表允許重復(fù)對(duì)應(yīng)其他語言的數(shù)組Set是無序去重集合適合判斷成員是否存在Map是鍵值對(duì)。Dart的集合字面量很直觀[1, 2, 3]是List{a, b}是Set{key: value}是Map。這里有個(gè)容易踩的小陷阱單獨(dú)一個(gè){}是Map不是Set。想創(chuàng)建空的Set必須顯式寫String{}。我在OpenHarmony項(xiàng)目里處理去重場景時(shí)一開始直接var keys {}結(jié)果后面add一個(gè)元素怎么都認(rèn)為是Map的key賦值報(bào)了一堆錯(cuò)查了半天發(fā)現(xiàn)是字面量類型搞混了。這種事不寫代碼時(shí)很難想起來但真遇到了印象非常深。Map的鍵也有講究。Dart里Map的默認(rèn)實(shí)現(xiàn)一般基于哈希鍵要求能正確實(shí)現(xiàn)hashCode和。如果你用自定義對(duì)象做鍵一定要重寫這兩個(gè)方法否則可能出現(xiàn)set和get都不是同一個(gè)對(duì)象的錯(cuò)誤。不過日常與OpenHarmony平臺(tái)交換數(shù)據(jù)時(shí)鍵大多是String比較省心。如果你遇到Map查不到值的問題先看看鍵的類型是不是和寫入時(shí)一致很多時(shí)候是int寫成double或者數(shù)字和字符串混用。3.4 記錄與模式解構(gòu)Dart 3帶來的新玩法聊完基礎(chǔ)類型我想說一個(gè)Dart 3帶來的變化記錄類型。記錄可以讓你把多個(gè)值打包成一個(gè)返回值而不需要專門定義一個(gè)類。比如一個(gè)函數(shù)要返回名稱和版本號(hào)可以寫成(String name, int version)返回值類型就變成了一個(gè)記錄。用起來也很順手var (name, version) getInfo();一次性解構(gòu)出兩個(gè)變量。這在Flutter for OpenHarmony的實(shí)戰(zhàn)中很有價(jià)值。平臺(tái)通道的回調(diào)經(jīng)常需要一個(gè)方法同時(shí)返回幾個(gè)數(shù)據(jù)以前要么傳Map、要么建一個(gè)臨時(shí)數(shù)據(jù)類?，F(xiàn)在用記錄類型比Map明確寫法又比建類輕量。如果還要更復(fù)雜的邏輯匹配Dart 3的switch表達(dá)式和if-case可以配合模式解構(gòu)直接對(duì)記錄或集合進(jìn)行結(jié)構(gòu)匹配代碼會(huì)寫得很干凈。不過也要克制。記錄適合用在臨時(shí)、局部的數(shù)據(jù)結(jié)構(gòu)如果是會(huì)被到處傳遞并且有業(yè)務(wù)含義的數(shù)據(jù)還是建議定義成正式的類因?yàn)轭惪梢杂蟹椒?、注釋、字段約束記錄在這些方面偏輕了。我的習(xí)慣是模塊內(nèi)部或函數(shù)間傳值用記錄跨模塊、跨平臺(tái)傳結(jié)構(gòu)化數(shù)據(jù)用Model類。4. 空安全與類型檢查OpenHarmony上報(bào)錯(cuò)最多的兩類問題4.1 可空類型的本質(zhì)與為什么值得學(xué)Dart的空安全簡單說就是把“這個(gè)變量可能是null”這件事從運(yùn)行時(shí)搬到了編譯期。你聲明int a時(shí)編譯器認(rèn)為a不可能是null聲明int? a時(shí)編譯器知道a可以是null所以在使用前必須判空。這個(gè)設(shè)計(jì)讓很多運(yùn)行時(shí)的空指針錯(cuò)誤提前暴露在寫代碼的時(shí)候而不是等到用戶在真機(jī)上操作時(shí)才崩潰。對(duì)應(yīng)到OpenHarmony平臺(tái)開發(fā)空安全的重要性更高因?yàn)槠脚_(tái)通道返回的數(shù)據(jù)大概率是可空的。比如原生側(cè)某次沒有返回值Dart側(cè)收到的就是一個(gè)null此時(shí)如果你直接把這個(gè)null賦給一個(gè)非空類型編譯期就會(huì)提示錯(cuò)誤。很多人一開始嫌判空麻煩到處用!來強(qiáng)行斷言“它不是null”結(jié)果運(yùn)行時(shí)一旦為null直接拋Null check operator used on a null value?？瞻踩皇墙o你添堵的是逼你想清楚這個(gè)值到底能不能為null該走哪個(gè)分支。4.2 late延遲初始化的實(shí)用場景和風(fēng)險(xiǎn)late是Dart里用來處理“這個(gè)變量現(xiàn)在不賦值但以后賦值一定在第一次使用之前”的情況。常用的場景有依賴某個(gè)初始化方法完成后才能創(chuàng)建的緩存對(duì)象、懶加載計(jì)算結(jié)果。加上late后編譯器允許你暫時(shí)不初始化等到真正訪問變量時(shí)才檢查是否已賦值如果沒有賦值就拋LateInitializationError。在OpenHarmony的Flutter工程里我常用late保存一些與平臺(tái)相關(guān)的一次性對(duì)象比如事件通道的實(shí)例或數(shù)據(jù)緩存。但這里有個(gè)風(fēng)險(xiǎn)late變量如果被并發(fā)訪問或者賦值之前就被其他代碼讀到問題就來了。Dart默認(rèn)是單線程事件循環(huán)所以同一事件循環(huán)內(nèi)一般沒問題但如果開啟了多個(gè)isolate或者在不同異步回調(diào)里訪問同一個(gè)late變量就要特別小心初始化的時(shí)機(jī)。更穩(wěn)妥的做法是不要濫用late。能用final在構(gòu)造函數(shù)初始化就用final能在方法內(nèi)部臨時(shí)創(chuàng)建就用局部變量。late最適合的場景是“初始化路徑很明確、且只初始化一次”的字段一旦發(fā)現(xiàn)某個(gè)late變量需要在多處、多個(gè)時(shí)序下賦值就應(yīng)該重新設(shè)計(jì)數(shù)據(jù)結(jié)構(gòu)而不是繼續(xù)往代碼里堆late。4.3 is、as、!的取舍類型檢查與轉(zhuǎn)換是Dart里最常見的操作之一。is用來判斷一個(gè)對(duì)象是不是某個(gè)類型as用來做強(qiáng)制類型轉(zhuǎn)換!用來做非空斷言。用的時(shí)候有個(gè)基本紀(jì)律盡量先is后轉(zhuǎn)換或者直接用is配合局部變量避免盲目as。比如平臺(tái)通道返回一個(gè)Object值你想知道它是不是String可以這么寫Object? value await channel.invokeMethod(getSomething); if (value is String) { // 在這個(gè)分支里value已經(jīng)被收窄為String print(value.length); } else { print(類型不對(duì): ${value.runtimeType}); }這里value is String之后Dart的流程分析會(huì)自動(dòng)把value當(dāng)作String來用不需要再做一次as。如果你用as強(qiáng)制轉(zhuǎn)換而實(shí)際類型不匹配會(huì)拋TypeError這在線上環(huán)境里是很不友好的。非空斷言!也是這樣它只是讓編譯器閉嘴不會(huì)改變運(yùn)行時(shí)的null。一個(gè)成熟的做法是在Dart代碼里減少!的使用用顯式判空或提前返回替代。4.4 平臺(tái)通道返回值的類型映射陷阱這一節(jié)是OpenHarmony開發(fā)里最容易被坑的地方。MethodChannel或EventChannel把數(shù)據(jù)從原生側(cè)傳回Dart時(shí)數(shù)據(jù)的類型會(huì)經(jīng)過一次“映射”原生側(cè)的整數(shù)、字符串、列表、字典到Dart側(cè)通常會(huì)變成int、String、List、Map。如果原生返回的是一個(gè)泛型列表Dart側(cè)得到的往往是Listdynamic你直接把它賦給ListString聲明會(huì)報(bào)type Listdynamic is not a subtype of type ListString。為什么會(huì)這樣因?yàn)镈art的泛型是不變的Listdynamic不能當(dāng)ListString用。解決方式不是去想辦法做隱式轉(zhuǎn)換而是自己寫一個(gè)mapper把動(dòng)態(tài)類型的列表逐項(xiàng)轉(zhuǎn)換并檢查。我在項(xiàng)目里會(huì)寫一個(gè)統(tǒng)一的值解析函數(shù)處理所有從原生通道進(jìn)來的數(shù)據(jù)在入口就把數(shù)據(jù)變成強(qiáng)類型的Dart對(duì)象業(yè)務(wù)代碼里就不再接觸dynamic了。這個(gè)習(xí)慣能省掉至少一半的運(yùn)行時(shí)類型錯(cuò)誤。EventChannel持續(xù)流數(shù)據(jù)也存在類似問題而且因?yàn)槭钱惒绞录e(cuò)誤更隱蔽。如果你在流回調(diào)里用as強(qiáng)轉(zhuǎn)失敗了不像方法調(diào)用那樣會(huì)馬上跳到catch而是可能把錯(cuò)誤拋到事件流的訂閱者里表現(xiàn)成日志里莫名奇妙的異常。我的建議是對(duì)于EventChannel收到的數(shù)據(jù)一律先做類型收窄再進(jìn)入業(yè)務(wù)邏輯。5. 常見問題排查與調(diào)試技巧實(shí)錄5.1 高頻錯(cuò)誤速查表我在OpenHarmony真機(jī)上調(diào)試Flutter時(shí)遇到過一些出現(xiàn)頻率極高的Dart報(bào)錯(cuò)整理成了一張速查表報(bào)錯(cuò)信息常見原因處理建議Null check operator used on a null value對(duì)null值使用!先用判空或?處理空分支LateInitializationErrorlate變量在賦值前被訪問檢查初始化時(shí)機(jī)不濫用latetype List is not a subtype of type List 平臺(tái)通道返回的是動(dòng)態(tài)列表直接賦給強(qiáng)類型列表寫mapper逐項(xiàng)轉(zhuǎn)換不要依賴隱式轉(zhuǎn)換type Null is not a subtype of type int平臺(tái)返回null賦給了非空int聲明int?或在接收處判空The argument type Object? cant be assigned to the parameter type String空安全類型不匹配使用收窄或顯式轉(zhuǎn)換Unsupported operation: Infinity or NaN toInt()double為無窮或NaN時(shí)調(diào)toInt()轉(zhuǎn)換前先檢查isFinite這張表在團(tuán)隊(duì)里也貼了新人遇到報(bào)錯(cuò)先自己對(duì)照一遍能解決八成問題剩下兩成再深入看調(diào)用棧。如果表里沒有你的場景優(yōu)先去看變量當(dāng)前的實(shí)際類型用runtimeType打印出來通常比猜測更快。5.2 高效定位Dart變量問題的三個(gè)手段第一是靜態(tài)分析優(yōu)先。在提交代碼或真機(jī)調(diào)試前先跑一遍dart analyze它會(huì)幫你找出類型不匹配、未使用變量、可能為空卻沒有處理等問題。靜態(tài)分析器是“廉價(jià)”的越早運(yùn)行越省錢等到真機(jī)上運(yùn)行時(shí)才發(fā)現(xiàn)類型問題往往已經(jīng)需要看一長串調(diào)用棧了。我一般會(huì)在每次寫一個(gè)完整的功能模塊后立刻跑一次analyze把提示當(dāng)作代碼評(píng)審意見逐條處理。第二是正確打日志。在OpenHarmony上調(diào)試Flutterprint在部分構(gòu)建模式下可能看得到也可能看不到用debugPrint更穩(wěn)妥因?yàn)樗鼤?huì)在日志過長時(shí)自動(dòng)分段。如果你需要看一個(gè)變量的真實(shí)類型直接打印變量.runtimeType這個(gè)屬性會(huì)告訴你它運(yùn)行時(shí)到底是什么類型對(duì)于排查平臺(tái)通道返回值非常有用。日志里最好帶上當(dāng)前方法的標(biāo)識(shí)否則同一行日志出現(xiàn)多次根本不知道是哪次調(diào)用打出來的。第三是用斷點(diǎn)調(diào)試。VSCode或Android Studio的Dart調(diào)試器可以在變量賦值處打斷點(diǎn)觀察變量當(dāng)前的值和類型。這個(gè)對(duì)于OpenHarmony工程同樣適用只要你的構(gòu)建產(chǎn)物啟用了調(diào)試符號(hào)。斷點(diǎn)調(diào)試比打日志更直觀但它要求代碼路徑能夠穩(wěn)定走到斷點(diǎn)一般我用來查邏輯錯(cuò)而平臺(tái)通道類型錯(cuò)就用運(yùn)行時(shí)類型打印。5.3 一個(gè)遷移案例從dynamic滿天飛到類型安全最后分享一個(gè)小案例。我之前遷移一個(gè)Flutter待辦應(yīng)用到OpenHarmony時(shí)一開始把平臺(tái)通道返回的數(shù)據(jù)直接塞進(jìn)了狀態(tài)里代碼大概長這樣final Object? data await channel.invokeMethod(fetchTodos); setState(() { todos data as List; // 這里運(yùn)行時(shí)才知道類型 });結(jié)果todos是個(gè)Listdynamic列表頁渲染時(shí)拿到一個(gè)Map又當(dāng)成Todo對(duì)象用直接報(bào)了類型錯(cuò)誤。更麻煩的是錯(cuò)誤只在真機(jī)上跑某個(gè)頁面時(shí)才出現(xiàn)本地調(diào)試很難復(fù)現(xiàn)。改造步驟很簡單先定義一個(gè)Todo類字段用final寫一個(gè)Todo.fromMap(MapString, dynamic map)的工廠方法在方法里每個(gè)字段都用判空和類型檢查處理然后通道回調(diào)處把Listdynamic用map方法逐項(xiàng)轉(zhuǎn)成ListTodo。整個(gè)過程不涉及架構(gòu)改動(dòng)就是讓數(shù)據(jù)在入口變成強(qiáng)類型。改完之后不只是報(bào)錯(cuò)少了代碼補(bǔ)全、單元測試、狀態(tài)判斷都舒服多了。這個(gè)案例也印證了我前面反復(fù)強(qiáng)調(diào)的觀點(diǎn)Dart的類型系統(tǒng)不是約束是你的安全網(wǎng)用好了在OpenHarmony這種多平臺(tái)環(huán)境下反而更省心。類型問題越早處理維護(hù)成本越低別等到運(yùn)行時(shí)才讓它暴露出來。我自己在OpenHarmony上寫Flutter最大的體會(huì)是花點(diǎn)時(shí)間把Dart變量與數(shù)據(jù)類型這一層學(xué)扎實(shí)比到處搜索報(bào)錯(cuò)原因效率高得多。最后再分享一個(gè)小習(xí)慣我每次新建一個(gè)Dart文件時(shí)都會(huì)先聲明好需要用到的數(shù)據(jù)Model和類型別名再寫具體邏輯這樣變量邊界從一開始就是清晰的后面基本不會(huì)在類型上翻車。如果哪天你也被這類問題折騰到半夜不妨回過頭來把基礎(chǔ)再過一遍你會(huì)感謝當(dāng)時(shí)那個(gè)愿意慢下來的自己。