跨端技術(shù)棧這事我被問過太多次了尤其是“iOS、安卓、鴻蒙三端同時(shí)要”這個(gè)需求基本是這兩年移動(dòng)端團(tuán)隊(duì)里出現(xiàn)頻率最高的一句話。原因也不難理解以前做App打包兩個(gè)端就已經(jīng)夠折騰現(xiàn)在鴻蒙加入進(jìn)來如果還堅(jiān)持三套原生代碼各自維護(hù)光排期就能讓人頭皮發(fā)麻。最近我正好把一套業(yè)務(wù)代碼完整跑在了這三端上就著這次實(shí)戰(zhàn)把選型思路和落地細(xì)節(jié)整理一遍。這篇內(nèi)容主要聊“一套代碼跨三端運(yùn)行”的技術(shù)棧方案覆蓋Flutter、React Native、uni-app、Taro等主流跨端框架的對(duì)比也會(huì)講清楚平臺(tái)能力如何抽象、鴻蒙適配要注意什么、打包上架會(huì)遇到哪些坑。適合正在做技術(shù)選型的開發(fā)團(tuán)隊(duì)也適合那些被老板問“鴻蒙版本什么時(shí)候能出”卻不知道怎么答的移動(dòng)端工程師。1. 跨三端的核心痛點(diǎn)與方案全景在我給你列技術(shù)棧對(duì)比之前先花點(diǎn)時(shí)間說清楚“跨三端”到底難在哪。很多人一開始以為既然iOS和安卓都能跨那再加一個(gè)鴻蒙應(yīng)該也差不多。真上手后會(huì)發(fā)現(xiàn)自己想簡(jiǎn)單了。1.1 三端生態(tài)差異決定了它比“跨兩端”復(fù)雜一個(gè)量級(jí)iOS那側(cè)是典型的閉源生態(tài)系統(tǒng)版本滾動(dòng)節(jié)奏快審核規(guī)則嚴(yán)格交付前對(duì)隱私權(quán)限、簽名證書有一套完整的流程。安卓這側(cè)雖然碎片化問題老生常談但勝在開源廠商各自魔改ROM兼容性測(cè)試的活兒永遠(yuǎn)干不完。到了鴻蒙這邊情況又不太一樣面向純血版本開發(fā)的App需要適配ArkTS聲明式語法和新的API體系不少原生的第三方SDK并不是直接復(fù)用到鴻蒙就行得看它有沒有對(duì)應(yīng)的版本。這三套環(huán)境放在一起意味著你的工程至少要處理三種構(gòu)建工具鏈、三種平臺(tái)權(quán)限模型、三套UI規(guī)范。如果純用原生開發(fā)每個(gè)需求都要在三個(gè)工程里分別實(shí)現(xiàn)一遍修改一個(gè)按鈕顏色都得重復(fù)三次勞動(dòng)更別提產(chǎn)品經(jīng)理臨時(shí)改需求時(shí)那種酸爽感?？缍丝蚣艿膬r(jià)值就在這里它把“業(yè)務(wù)邏輯”和“平臺(tái)差異”剝離開讓一份代碼負(fù)責(zé)核心鏈路的開發(fā)只在真正需要調(diào)原生能力的地方留出口子。1.2 主流跨端技術(shù)棧全景對(duì)比現(xiàn)在市面上的跨端方案大致分三派自渲染引擎派、原生橋接派、小程序容器派。我先用一張表把主流的候選者擺出來后面再逐個(gè)細(xì)說。技術(shù)棧語言/語法渲染方式鴻蒙適配成熟度典型適用場(chǎng)景FlutterDart自繪引擎(Skia/Impeller)官方支持和社區(qū)適配并行相對(duì)成熟對(duì)UI一致性要求高、需覆蓋三端的中大型AppReact NativeJS/TS React原生組件橋接社區(qū)適配(如react-native-ohos)推進(jìn)中可用但需側(cè)重點(diǎn)驗(yàn)證團(tuán)隊(duì)React技術(shù)棧強(qiáng)、原生交互要求高的Appuni-appVue語法條件編譯到各端小程序端用webview或原生渲染官方已支持HarmonyOS Next國內(nèi)生態(tài)較完善國內(nèi)業(yè)務(wù)、需要同時(shí)覆蓋小程序和App的場(chǎng)景TaroReact語法類React多端偏H5/小程序鴻蒙App端支持較弱已有小程序/React體系想低成本復(fù)用業(yè)務(wù)代碼Compose MultiplatformKotlin聲明式UI自繪JetBrains官方支持iOS/安卓鴻蒙依賴社區(qū)路線Kotlin技術(shù)棧、邏輯共享需求為主的團(tuán)隊(duì)從當(dāng)前這個(gè)時(shí)間點(diǎn)看如果目標(biāo)是“一套代碼真正覆蓋iOS、安卓、鴻蒙三個(gè)原生App端”我個(gè)人更推薦優(yōu)先評(píng)估Flutter和uni-app這兩條路線。React Native雖然在iOS和安卓上的生態(tài)依然很能打但鴻蒙側(cè)的第三方庫適配還在持續(xù)完善遇到冷門原生組件時(shí)容易卡在“有沒有人維護(hù)”這個(gè)問題上。Taro更適合歸到“小程序/H5多端復(fù)用”那一類直接做三端原生App時(shí)它不是最順的選擇。2. 技術(shù)選型思路與架構(gòu)設(shè)計(jì)選技術(shù)棧這件事本質(zhì)上是把團(tuán)隊(duì)現(xiàn)狀、業(yè)務(wù)形態(tài)、目標(biāo)平臺(tái)這三者放到一張桌子上去談。不要上來就問哪個(gè)框架最好先問自己的業(yè)務(wù)最在意什么。2.1 選型的第一性原則團(tuán)隊(duì)和業(yè)務(wù)形態(tài)說了算我見過不少團(tuán)隊(duì)因?yàn)椤癋lutter比較火”就硬切過來最后被Dart語言學(xué)習(xí)成本卡了一個(gè)月。反過來也有團(tuán)隊(duì)用uni-app省了小程序的事但業(yè)務(wù)里大量依賴高性能原生渲染最后在性能上反復(fù)折騰。選型第一考慮的是團(tuán)隊(duì)里大多數(shù)人熟悉什么第二才是框架本身的能力邊界。把業(yè)務(wù)形態(tài)也放進(jìn)來一起看。如果你的產(chǎn)品是工具類、內(nèi)容類、電商類頁面以“列表詳情表單”為主Flutter和uni-app都很穩(wěn)。如果你的產(chǎn)品強(qiáng)依賴系統(tǒng)原生的地圖、相機(jī)、推送等能力就要認(rèn)真評(píng)估每個(gè)框架在這些插件上的成熟度。如果你的業(yè)務(wù)同時(shí)要覆蓋公眾號(hào)H5、微信小程序、抖音小程序那一套u(yù)ni-app或Taro代碼順便發(fā)到App端性價(jià)比確實(shí)高。鴻蒙適配的成熟度也要單獨(dú)拿出來問一問。不同版本的跨端框架對(duì)HarmonyOS的支持深度不一樣不能只看“支持鴻蒙”這四個(gè)字要確認(rèn)它支持的是不是面向下一代鴻蒙的ArkTS產(chǎn)物以及插件市場(chǎng)中你需要的原生模塊有沒有鴻蒙版本。2.2 架構(gòu)分層的核心定義清楚“一套代碼”的邊界許多人對(duì)“一套代碼”有個(gè)誤解以為就是寫一套任何地方都不能出現(xiàn)平臺(tái)判斷。真實(shí)的工程實(shí)踐里那叫理想主義。跨端框架解決的是讓業(yè)務(wù)邏輯能夠百分百共享但UI層的極少數(shù)差異化調(diào)整、平臺(tái)能力層的原生實(shí)現(xiàn)很難完全不分端。我更傾向于把工程拆成四層UI層頁面結(jié)構(gòu)、組件、樣式絕大多數(shù)代碼跨端共享業(yè)務(wù)層狀態(tài)管理、路由、數(shù)據(jù)模型、接口請(qǐng)求這一層必須純凈不摻平臺(tái)判斷數(shù)據(jù)層網(wǎng)絡(luò)、緩存、本地存儲(chǔ)通過統(tǒng)一接口暴露給上層平臺(tái)能力層支付、推送、分享、攝像頭、定位等原生能力只用統(tǒng)一方法簽名暴露這個(gè)分層的硬性要求是上面的業(yè)務(wù)層永遠(yuǎn)不要直接調(diào)用某個(gè)平臺(tái)的原生API而是通過抽象接口走平臺(tái)能力層。這樣即使某個(gè)原生模塊在鴻蒙上暫時(shí)無法實(shí)現(xiàn)你只需要替換一個(gè)實(shí)現(xiàn)類業(yè)務(wù)代碼一行都不用改。這個(gè)邊界劃清楚一套代碼跨三端才真正成立。2.3 關(guān)鍵決策點(diǎn)渲染引擎、狀態(tài)管理、路由方案渲染引擎決定了你的UI在復(fù)雜動(dòng)畫場(chǎng)景下穩(wěn)不穩(wěn)。Flutter自繪所有控件三端渲染效果幾乎一致適合對(duì)UI一致性要求高的Appuni-app在App端最終也要通過webview或者原生渲染來落性能和一致性上多少有些妥協(xié)。這一點(diǎn)要結(jié)合你們的UI復(fù)雜度來判斷如果是報(bào)表、圖表、動(dòng)畫很多的界面Flutter這種自繪引擎會(huì)更省心。狀態(tài)管理是另一個(gè)必須提前統(tǒng)一的點(diǎn)。Flutter項(xiàng)目里常見的Provider、Riverpod、Bloc任意選一個(gè)都可以重點(diǎn)是全團(tuán)隊(duì)強(qiáng)制統(tǒng)一別一個(gè)頁面一種寫法。uni-app對(duì)應(yīng)的是Vue生態(tài)的Pinia或VuexTaro則是Redux或Zustand。只要狀態(tài)層統(tǒng)一了跨端維護(hù)成本會(huì)直線下降。路由方案也一樣。Flutter有g(shù)o_routeruni-app有自己的路由APITaro也可以用React Router。路由命名和跳轉(zhuǎn)參數(shù)最好集中維護(hù)在配置文件里這樣三端的行為習(xí)慣一致也方便測(cè)試同學(xué)寫自動(dòng)化用例。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)方向定了之后真正干活的時(shí)候你會(huì)發(fā)現(xiàn)細(xì)節(jié)全在“邊界管理”和“平臺(tái)差異”上。這一章節(jié)我講幾個(gè)實(shí)操中繞不開的點(diǎn)。3.1 工程結(jié)構(gòu)與條件編譯怎么設(shè)計(jì)很多人都忽略干凈工程結(jié)構(gòu)的重要性等到代碼量上萬行之后再重構(gòu)代價(jià)就大了。我在Flutter工程里習(xí)慣把目錄這樣劃分lib/ core/ # 基礎(chǔ)工具、網(wǎng)絡(luò)層、常量 features/ # 業(yè)務(wù)模塊按功能劃分 login/ ui/ logic/ models/ shared/ # 跨模塊復(fù)用的組件、widget platform/ # 平臺(tái)能力抽象層只放接口這個(gè)結(jié)構(gòu)的關(guān)鍵在于platform目錄只放抽象接口不放任何具體實(shí)現(xiàn)。具體的iOS、安卓、鴻蒙實(shí)現(xiàn)代碼放在各自的平臺(tái)目錄或者插件包里不會(huì)混進(jìn)共享代碼中。使用uni-app或Taro時(shí)條件編譯是很順手的能力。比如uni-app里可以這樣寫// #ifdef APP-PLUS // 只在App端執(zhí)行的邏輯 this.payByApp() // #endif // #ifdef H5 // 只在H5端執(zhí)行的邏輯 this.payByH5() // #endif條件編譯的用法本身不難但建議只用它做小范圍適配比如支付渠道選擇、特定平臺(tái)的彈窗樣式不要讓整段業(yè)務(wù)邏輯被ifdef包裹否則代碼的可讀性和可測(cè)試性會(huì)迅速惡化。3.2 原生能力調(diào)用的統(tǒng)一封裝法跨端App最容易被吐槽的就是調(diào)用原生能力時(shí)一地雞毛。比如支付iOS走Apple Pay安卓走支付寶或微信SDK鴻蒙上又可能走華為支付。作為業(yè)務(wù)層它壓根不關(guān)心底層是哪個(gè)支付渠道它只想知道“這次支付成功沒”。所以我的做法是先定義一組抽象接口abstract class PaymentService { FuturePayResult pay(PayRequest request); }然后分別在iOS插件、安卓插件、鴻蒙適配包里實(shí)現(xiàn)這個(gè)接口。業(yè)務(wù)層調(diào)用時(shí)只知道有PaymentService完全不知道背后是誰在干活。后續(xù)如果某個(gè)平臺(tái)的支付SDK升級(jí)了我只需要改對(duì)應(yīng)平臺(tái)的實(shí)現(xiàn)業(yè)務(wù)層完全無感。Flutter的MethodChannel是實(shí)現(xiàn)這套封裝最常用的手段class NativeBridge { static const MethodChannel _channel MethodChannel(com.example.app/platform); static FutureString? getDeviceInfo() async { return await _channel.invokeMethod(getDeviceInfo); } }原生側(cè)對(duì)應(yīng)實(shí)現(xiàn)MethodChannel的方法即可。最需要注意的是方法名、參數(shù)結(jié)構(gòu)、返回值類型一定要三端對(duì)齊并且在接口文檔里寫清楚不然很容易出現(xiàn)“iOS好好的安卓回調(diào)里的字段對(duì)不上”這種低級(jí)但隱蔽的問題。3.3 鴻蒙適配要比其他兩端更較真鴻蒙方向的適配我單獨(dú)拿出來重點(diǎn)講因?yàn)檫@里踩坑的概率最高。第一件要接受的事是面向鴻蒙的應(yīng)用開發(fā)語法體系已經(jīng)從Java/Kotlin切到了ArkTSUI描述也從聲明式XML轉(zhuǎn)向了ArkUI不少原先生態(tài)里“無腦復(fù)用安卓代碼”的思路直接失效?？缍丝蚣軒湍阊谏w了一部分差異但你依賴的第三方原生SDK如果還沒有鴻蒙版照樣會(huì)卡殼。第二件事是UI規(guī)范。鴻蒙有自己的設(shè)計(jì)語言和交互習(xí)慣比如側(cè)滑返回的層級(jí)關(guān)系、彈窗風(fēng)格、權(quán)限彈窗的文案要求和iOS、安卓不完全一樣。就算你用Flutter自繪了一套統(tǒng)一視覺也要在交互細(xì)節(jié)上留出鴻蒙適配空間比如側(cè)滑返回手勢(shì)、導(dǎo)航欄布局參數(shù)不該把iOS那套直接生搬過去。第三件是打包簽名與權(quán)限聲明。鴻蒙應(yīng)用上架有自己的簽名體系和權(quán)限列表打包產(chǎn)物是HAP或APP格式不能用安卓的APK那套邏輯去理解。發(fā)布到華為應(yīng)用市場(chǎng)要通過AGC完成簽名和審核流程所需要準(zhǔn)備的材料、隱私聲明、權(quán)限說明都值得提前確認(rèn)別等開發(fā)完了才臨時(shí)去摸流程。4. 實(shí)操過程從初始化到三端打包光講道理很難有感覺我直接復(fù)盤一遍“從零到三端”跑通的完整過程。這里以Flutter路線為主因?yàn)樗壳霸谌嗽鶤pp覆蓋上最貼近“一套代碼”這句話。4.1 環(huán)境準(zhǔn)備不嫌多缺一樣都跑不通三端跨平臺(tái)開發(fā)的環(huán)境配置比普通移動(dòng)開發(fā)多一個(gè)鴻蒙的SDK要裝。我按順序梳理一下Flutter SDK建議直接上穩(wěn)定版并確保本機(jī)Dart環(huán)境正常XcodeiOS構(gòu)建用Mac上必須的Android Studio安卓構(gòu)建用順便管理安卓SDKDevEco Studio鴻蒙側(cè)的IDE同時(shí)負(fù)責(zé)鴻蒙SDK的下載鴻蒙SDK在DevEco Studio里安裝主要看API版本和ArkTS編譯器環(huán)境變量也要記得配好。Flutter能正常識(shí)別出三個(gè)平臺(tái)從flutter doctor的輸出里一眼能看出缺了什么。flutter doctor看到Xcode、Android toolchain、Flutter工具鏈都是綠勾鴻蒙側(cè)的SDK路徑也能被識(shí)別到才算準(zhǔn)備完成。早期踩過一個(gè)坑鴻蒙SDK裝好之后還需要在DevEco Studio里手動(dòng)“安裝并關(guān)聯(lián)”到Flutter插件否則flutter build時(shí)根本找不到鴻蒙平臺(tái)。4.2 初始化工程并跑通第一段業(yè)務(wù)代碼用flutter create創(chuàng)建工程之后默認(rèn)只會(huì)生成iOS和安卓目錄。鴻蒙側(cè)的工程目錄需要依賴Flutter的鴻蒙適配插件或者模板來生成常見的做法是在工程創(chuàng)建后通過適配工具生成類似“ohos”的模塊目錄。flutter create --org com.example my_app把第一段業(yè)務(wù)代碼放在lib/main.dart里一個(gè)簡(jiǎn)單的底部導(dǎo)航、一個(gè)列表頁就夠了。關(guān)鍵不是功能多復(fù)雜而是把“同一段Dart代碼跑三個(gè)平臺(tái)”這個(gè)鏈路打通。此時(shí)會(huì)發(fā)現(xiàn)在iOS模擬器、安卓模擬器、鴻蒙模擬器上都啟動(dòng)成功這個(gè)體驗(yàn)會(huì)讓人瞬間安心不少。跑通了第一段共享代碼之后立刻補(bǔ)上平臺(tái)能力層的測(cè)試。至少寫一個(gè)獲取設(shè)備型號(hào)的方法分別通過三種端側(cè)實(shí)現(xiàn)返回各自的系統(tǒng)名稱驗(yàn)證MethodChannel在這些平臺(tái)上的行為是否一致。這個(gè)驗(yàn)證要趁早做晚了排查問題會(huì)難很多。4.3 三端打包上架要點(diǎn)簽名、權(quán)限與審核開發(fā)完之后真正的收尾工作是出包。iOS側(cè)要處理證書和描述文件在Xcode里設(shè)置好Bundle Identifier和簽名通過Archive導(dǎo)出ipa包再傳到App Store Connect走審核。需要注意的是iOS審核對(duì)隱私權(quán)限說明很嚴(yán)格如果你調(diào)了相機(jī)、位置必須在Info.plist里寫清用途描述。安卓側(cè)最麻煩的反而是多渠道打包。國內(nèi)應(yīng)用市場(chǎng)往往需要不同的渠道標(biāo)識(shí)可以用Gradle配置productFlavors來區(qū)分也可以借助打包平臺(tái)統(tǒng)一處理。簽名要用正式的keystore不能拿debug簽名直接上架。權(quán)限方面安卓從Android 6.0開始就要運(yùn)行時(shí)申請(qǐng)權(quán)限如果你的App面向Android 13以上一些Notification權(quán)限和圖片選擇權(quán)限的行為也要做適配。鴻蒙側(cè)的流程差異最大。打包產(chǎn)物是HAP簽名要到AppGallery Connect申請(qǐng)證書和Profile文件再通過DevEco Studio的打包工具完成簽名。鴻蒙應(yīng)用市場(chǎng)的審核對(duì)隱私聲明、權(quán)限含義說明都有專門要求建議在開發(fā)階段就把相關(guān)材料準(zhǔn)備好否則往往開發(fā)一周、審核準(zhǔn)備又耗一周。5. 常見問題排查與避坑實(shí)錄最后這部分是我真正想提醒大家的全是實(shí)操里面容易踩的坑我把它們按常見程度和典型的排查思路整理成速查表。問題現(xiàn)象可能原因排查思路與解決建議同樣代碼在鴻蒙上頁面錯(cuò)位鴻蒙UI布局約束與iOS/安卓存在差異在三端都查一遍布局日志優(yōu)先排查SafeArea、狀態(tài)欄高度、橫豎屏適配原生插件在鴻蒙上無反應(yīng)插件體系不兼容鴻蒙SDK確認(rèn)插件是否具備鴻蒙實(shí)現(xiàn)換用鴻蒙原生SDK自封裝MethodChannel調(diào)用超時(shí)原生側(cè)方法名與Dart側(cè)不匹配統(tǒng)一維護(hù)方法名常量?jī)啥巳罩就瑫r(shí)打開對(duì)照打包后包體積過大引入的原生庫過多或未做裁剪用構(gòu)建分析工具對(duì)比移除未使用的插件和資源啟動(dòng)速度比原生慢跨端框架初始化開銷加上首幀資源加載做啟動(dòng)優(yōu)化比如延遲加載非核心插件、減少啟動(dòng)時(shí)的同步請(qǐng)求權(quán)限彈窗文案審核被拒權(quán)限用途描述與實(shí)際使用場(chǎng)景不符逐條核對(duì)權(quán)限聲明確保文案精確且不濫用權(quán)限5.1 頁面錯(cuò)亂先從布局適配查起三端之間最普遍的問題是頁面錯(cuò)亂尤其集中在狀態(tài)欄、底部安全區(qū)、橫豎屏切換這些地方。iOS有劉海屏安卓有各種挖孔屏鴻蒙又有自己的狀態(tài)欄邏輯如果代碼里用了固定的高度值基本必出問題。建議從做設(shè)計(jì)稿開始就把“安全區(qū)”當(dāng)成一個(gè)變量來處理而不是寫死數(shù)值。Flutter里可以用MediaQuery來處理paddinguni-app里用uni.getSystemInfo得到狀態(tài)欄高度再動(dòng)態(tài)計(jì)算。先讓三端的基礎(chǔ)布局都基于安全區(qū)自適應(yīng)再談跨端一致。這條不做后面改到崩潰都改不完。5.2 原生模塊在鴻蒙失效別指望“直接復(fù)用”跨端框架最坑的一點(diǎn)是插件市場(chǎng)的質(zhì)量參差不齊。很多知名插件在iOS和安卓上表現(xiàn)穩(wěn)定但鴻蒙版本要么沒有要么是社區(qū)開發(fā)者隨手提的PR功能覆蓋不全。這時(shí)候不要硬等官方自己寫一個(gè)鴻蒙專用的實(shí)現(xiàn)類往抽象接口下面一塞反而最快。排查這類問題時(shí)也要放開思路如果插件有鴻蒙版本優(yōu)先檢查API版本是否對(duì)應(yīng)如果插件沒有鴻蒙版本直接把調(diào)用入口的日志打出來確認(rèn)問題到底出在初始化還是調(diào)用階段再做對(duì)策。5.3 性能與包體積優(yōu)化前期習(xí)慣決定后期命運(yùn)跨端App最容易被人吐槽的是“包大、占內(nèi)存、啟動(dòng)慢”。這些問題很多是從工程初期就埋下的引入插件時(shí)不做評(píng)估圖片資源不做壓縮啟動(dòng)時(shí)把所有模塊全部初始化。優(yōu)化方向很清晰但真正執(zhí)行需要決心。包體積方面定期用構(gòu)建產(chǎn)物分析工具檢查哪些庫占了空間。性能方面把啟動(dòng)流程劃分為必要和非必要非必要模塊做延遲加載。業(yè)務(wù)代碼里的長(zhǎng)列表和圖片緩存也要一開始就接好真到了用戶反饋卡頓再回頭補(bǔ)成本高得多。我個(gè)人的習(xí)慣是每做一個(gè)功能模塊就順手跑一次release構(gòu)建看看體積和啟動(dòng)耗時(shí)的增量是否異常。這個(gè)習(xí)慣幫我避掉過好幾次“看似正常、實(shí)際上往包里悄悄塞了個(gè)大SDK”的問題。5.4 團(tuán)隊(duì)協(xié)作規(guī)范跨端比單端更需要紀(jì)律跨端開發(fā)的坑很多來自“規(guī)范不一致”。同一個(gè)功能的命名iOS寫法一個(gè)樣安卓寫法一個(gè)樣鴻蒙又一個(gè)樣時(shí)間一長(zhǎng)整個(gè)工程就亂成一鍋粥。建議團(tuán)隊(duì)從一開始就建立三端的命名映射表、接口變更流程和代碼評(píng)審規(guī)則尤其是原生橋接層的方法名和參數(shù)名必須由專人維護(hù)并形成文檔。代碼評(píng)審里我會(huì)特別關(guān)注“平臺(tái)判斷有沒有漏網(wǎng)”和“原生調(diào)用有沒有繞過抽象層”這兩類問題。每一次PR都要檢查是否有平臺(tái)相關(guān)的代碼泄漏到共享業(yè)務(wù)層一旦發(fā)現(xiàn)就直接打回。這個(gè)規(guī)則看起來有點(diǎn)死板但它是保證“一套代碼”不出岔子最有效的護(hù)欄。最后補(bǔ)充一個(gè)我踩過坑之后沉淀的習(xí)慣跨三端這件事不要指望任何一個(gè)框架能100%消除平臺(tái)差異。無論選Flutter還是uni-app最終都要在自己的工程里把“共享”和“隔離”的邊界定義出來并且強(qiáng)制執(zhí)行。我在實(shí)際操作中的體會(huì)是最快讓團(tuán)隊(duì)感受到跨端紅利的方式不是一上來就鋪大架構(gòu)而是先把一個(gè)完整業(yè)務(wù)模塊推到三端跑通讓所有人看到“同一份代碼真的能同時(shí)上線”這個(gè)結(jié)果后面推進(jìn)起來會(huì)順非常多。另外一個(gè)小建議把鴻蒙側(cè)的模擬器和真機(jī)都準(zhǔn)備好平時(shí)寫頁面的時(shí)候順手多看一眼鴻蒙上的表現(xiàn)不要等到最后統(tǒng)一驗(yàn)證。三端同步集成、同步回歸雖然一開始節(jié)奏會(huì)被拖慢一點(diǎn)但到后期你會(huì)發(fā)現(xiàn)它反而是省時(shí)間省得最狠的做法。