1. 為什么第一個(gè)實(shí)戰(zhàn)項(xiàng)目我選了一個(gè)信息流小應(yīng)用而不是再寫一個(gè) Todo我發(fā)現(xiàn)很多剛接觸 Flutter 的朋友學(xué)完基礎(chǔ)語(yǔ)法之后會(huì)卡在同一個(gè)地方教程里的每個(gè)知識(shí)點(diǎn)都看懂了Button、ListView、網(wǎng)絡(luò)請(qǐng)求都單獨(dú)跑通過(guò)但一說(shuō)到做個(gè)自己的項(xiàng)目就完全不知道從哪下手。這個(gè)系列就是為了解決這個(gè)問(wèn)題。這次實(shí)戰(zhàn)我給自己定的題目很簡(jiǎn)單——做一個(gè)可用的信息流閱讀應(yīng)用不做復(fù)雜特效不堆砌花哨交互但必須把真實(shí) App 的骨架搭完整啟動(dòng)頁(yè)、列表頁(yè)、詳情頁(yè)、網(wǎng)絡(luò)請(qǐng)求、加載狀態(tài)、錯(cuò)誤處理、本地緩存、下拉刷新、上拉加載、打包配置。為什么選這個(gè)方向而不是再寫一個(gè)經(jīng)典 Todo原因很實(shí)際第一信息流是最常見(jiàn)、最不挑領(lǐng)域的應(yīng)用形態(tài)。選它能保證讀者把代碼跑起來(lái)之后能立刻想象到這東西換個(gè)數(shù)據(jù)源就能變成新聞閱讀器、商品列表、開源項(xiàng)目導(dǎo)航。第二它天然覆蓋 Flutter 的核心知識(shí)點(diǎn)。列表渲染對(duì)應(yīng) ListView.builder網(wǎng)絡(luò)層對(duì)應(yīng) dio/http 封裝異步狀態(tài)對(duì)應(yīng) FutureBuilder以及后續(xù)的 Riverpod頁(yè)面跳轉(zhuǎn)對(duì)應(yīng)命名路由本地緩存對(duì)應(yīng) shared_preferences 或文件存儲(chǔ)。做一遍等于把 Flutter 日常開發(fā)的高頻場(chǎng)景全部過(guò)了一遍。第三它足夠小。一個(gè)人一個(gè)周末能做出來(lái)不會(huì)因?yàn)楣こ烫蟀胪径鴱U。我見(jiàn)過(guò)太多的學(xué)習(xí)路徑是每個(gè)組件學(xué)三遍項(xiàng)目一個(gè)都沒(méi)做完整過(guò)。這次我反過(guò)來(lái)——直接開干遇到什么補(bǔ)什么。提示這篇文章是項(xiàng)目實(shí)戰(zhàn)第一彈我會(huì)把從零到發(fā)布的全過(guò)程都寫出來(lái)。如果你還在猶豫我現(xiàn)在水平夠不夠先別糾結(jié)完整跟一遍你會(huì)發(fā)現(xiàn)自己能走通的路比想象中長(zhǎng)。2. 開工前我先把目錄結(jié)構(gòu)和依賴一次定好2.1 為什么一開始就要定目錄結(jié)構(gòu)而不是寫到哪里算哪里很多初學(xué)者最喜歡在 main.dart 里一口氣寫五百行跑通了再說(shuō)。這種做法在五十行以內(nèi)問(wèn)題不大一旦項(xiàng)目超過(guò)兩三個(gè)頁(yè)面就會(huì)發(fā)現(xiàn)自己陷入改一個(gè)變量滿文件搜的困境。這次實(shí)戰(zhàn)從一開始我就把目錄按功能拆分目標(biāo)很明確每個(gè)文件只干一件事通過(guò)命名快速定位。我先定義了一個(gè)標(biāo)準(zhǔn)分層結(jié)構(gòu)lib/ ├── main.dart # 入口負(fù)責(zé)初始化 ├── app.dart # 根組件負(fù)責(zé)主題和路由 ├── constants/ # 全局常量、API地址、存儲(chǔ)key ├── models/ # 數(shù)據(jù)模型 ├── services/ # 網(wǎng)絡(luò)請(qǐng)求、數(shù)據(jù)服務(wù) ├── providers/ # 狀態(tài)管理控制器 ├── pages/ │ ├── home/ # 首頁(yè)相關(guān) │ ├── detail/ # 詳情頁(yè)相關(guān) │ └── splash/ # 啟動(dòng)頁(yè)相關(guān) └── widgets/ # 通用組件這樣拆分的直接收益是等代碼量過(guò)了兩千行你仍然能在十秒內(nèi)定位出一個(gè)組件或接口的位置。后續(xù)加頁(yè)面、加功能也只是往對(duì)應(yīng)目錄里放文件不需要?jiǎng)悠渌K。2.2 依賴選型的思路依賴選型我遵循夠用、穩(wěn)定、生態(tài)好三個(gè)原則。下面是最終在 pubspec.yaml 里鎖定的關(guān)鍵依賴和選型理由依賴用途選型理由dio網(wǎng)絡(luò)請(qǐng)求攔截器機(jī)制成熟可統(tǒng)一處理日志、錯(cuò)誤碼、token社區(qū)使用量最大riverpod狀態(tài)管理編譯期安全調(diào)試友好不需要 BuildContext 就能讀取狀態(tài)適合中大型項(xiàng)目shared_preferences本地鍵值存儲(chǔ)輕量適合存設(shè)置項(xiàng)和簡(jiǎn)單緩存元數(shù)據(jù)cached_network_image網(wǎng)絡(luò)圖片緩存自帶內(nèi)存磁盤二級(jí)緩存列表圖片滾動(dòng)時(shí)省流量不卡頓flutter_screenutil屏幕適配按設(shè)計(jì)稿尺寸自動(dòng)換算省去不同機(jī)型手工調(diào)尺寸的麻煩intl日期格式化官方維護(hù)格式化相對(duì)時(shí)間很順手有一個(gè)容易忽略的點(diǎn)版本號(hào)我統(tǒng)一用了脫字符^限定大版本不鎖死具體小版本。這樣 pub get 的時(shí)候能拿到兼容范圍內(nèi)的最新版同時(shí)避免大版本升級(jí)帶來(lái)的破壞性變化。2.3 避免把依賴版本一直跟著最新走我知道有朋友習(xí)慣直接flutter pub add xxx然后一路 yes。跑是能跑但等過(guò)了兩三個(gè)月項(xiàng)目里可能會(huì)出現(xiàn)依賴間的兼容性沖突——你裝 A 的新版結(jié)果 B 的接口變了。我的做法是每次新增依賴之前先在 pub.dev 上看一眼它的更新時(shí)間、最后版本發(fā)布時(shí)間、以及 README 里有沒(méi)有提到 breaking change。穩(wěn)比新重要。3. 主題、路由、配置這幾塊決定了后面寫代碼的手感3.1 全局主題的配置方式一個(gè)信息流應(yīng)用主題不需要復(fù)雜但配色和字體的統(tǒng)一是基本功。我在 constants 目錄下建了app_theme.dart用 Flutter 自帶的ThemeData把三套東西統(tǒng)一管理起來(lái)顏色主色、背景色、卡片色、文字主次色文本樣式標(biāo)題字號(hào)、正文行高、輔助文字顏色通用組件樣式卡片圓角、陰影、AppBar 返回按鈕風(fēng)格實(shí)際效果是頁(yè)面里幾乎不寫TextStyle(fontSize: 14)這種散裝樣式全走主題引用。后面想要換夜間模式或者調(diào)整品牌色只改一個(gè)文件全 App 生效。這里分享一個(gè)細(xì)節(jié)很多人會(huì)在MaterialApp里同時(shí)設(shè)置theme和darkTheme但在項(xiàng)目初期其實(shí)沒(méi)必要先保證一套主題足夠統(tǒng)一比提前做多皮膚更重要。多皮膚會(huì)引入大量邊界判斷前期只會(huì)拖慢進(jìn)度。3.2 命名路由和頁(yè)面跳轉(zhuǎn)的取舍Flutter 里頁(yè)面跳轉(zhuǎn)有兩條路Navigator.push直接傳頁(yè)面實(shí)例或者用命名路由。我在這次項(xiàng)目里用了后者。routes: { /: (context) const SplashPage(), /home: (context) const HomePage(), /detail: (context) DetailPage(argument: argument), }命名路由的好處是跳轉(zhuǎn)時(shí)只需要拼字符串代碼里不會(huì)出現(xiàn)大量import頁(yè)面類的引用而且在需要做登錄攔截、深鏈跳轉(zhuǎn)時(shí)會(huì)方便很多。當(dāng)然直接傳參數(shù)拼路由字符串有一個(gè)困擾——參數(shù)多了怎么辦我的處理方式是定義一個(gè)DetailArgument類把列表頁(yè)傳給詳情頁(yè)的所有字段打包成一個(gè)對(duì)象路由只傳這一個(gè)對(duì)象。這樣點(diǎn)進(jìn)詳情頁(yè)時(shí)不會(huì)因?yàn)閰?shù)列表太長(zhǎng)而眼瞎。3.3 全局配置獨(dú)立成文件接口地址、緩存過(guò)期時(shí)間、分頁(yè)大小、圖片占位圖這些環(huán)境級(jí)常量我集中放在了constants/app_config.dart里。用abstract final class包一層靜態(tài)常量后面切換到正式環(huán)境只需要改一個(gè)文件里的 API baseUrl。abstract final class AppConfig { static const String apiBaseUrl https://api.example.com; static const int pageSize 20; static const Duration cacheExpire Duration(days: 1); }這個(gè)習(xí)慣再往后延伸到多環(huán)境構(gòu)建時(shí)你只需要配合--dart-define就能實(shí)現(xiàn)測(cè)試、預(yù)發(fā)、正式三套環(huán)境的切換?，F(xiàn)在先把配置文件獨(dú)立出來(lái)等于給未來(lái)留了條后路。4. 數(shù)據(jù)模型和網(wǎng)絡(luò)層先把數(shù)據(jù)能不能順暢進(jìn)來(lái)解決掉4.1 模型設(shè)計(jì)少一點(diǎn)手寫多一點(diǎn)規(guī)范信息流應(yīng)用的核心數(shù)據(jù)無(wú)外乎一個(gè)文章摘要對(duì)象封面圖、標(biāo)題、摘要、發(fā)布時(shí)間、內(nèi)容正文。我定義模型時(shí)遵循了一條很實(shí)用的原則模型的職責(zé)只有兩個(gè)——序列化和反序列化。所有業(yè)務(wù)邏輯都不寫在模型類里。class ArticleModel { final String id; final String title; final String summary; final String coverUrl; final String content; final DateTime publishedAt; const ArticleModel({ required this.id, required this.title, required this.summary, required this.coverUrl, required this.content, required this.publishedAt, }); factory ArticleModel.fromJson(MapString, dynamic json) { return ArticleModel( id: json[id] as String, title: json[title] as String, summary: json[summary] as String, coverUrl: json[cover_url] as String? ?? , content: json[content] as String? ?? , publishedAt: DateTime.tryParse(json[published_at] as String? ?? ) ?? DateTime.now(), ); } MapString, dynamic toJson() { return { id: id, title: title, summary: summary, cover_url: coverUrl, content: content, published_at: publishedAt.toIso8601String(), }; } }注意幾個(gè)細(xì)節(jié)coverUrl和content我都給了空字符串兜底而不是直接as String強(qiáng)轉(zhuǎn)因?yàn)檎鎸?shí)后端返回的數(shù)據(jù)經(jīng)常缺字段空值處理不當(dāng)會(huì)在渲染層崩掉publishedAt用了tryParse加兜底當(dāng)前時(shí)間避免偶發(fā)的時(shí)間格式解析崩潰。4.2 dio 封裝把攔截器用到極致raw 的 dio 使用方式很簡(jiǎn)單但一進(jìn)入項(xiàng)目實(shí)戰(zhàn)我會(huì)立刻做一層封裝。不為了抽象而抽象而是為了三個(gè)非常現(xiàn)實(shí)的需求統(tǒng)一設(shè)置超時(shí)時(shí)間和請(qǐng)求頭不用每個(gè)請(qǐng)求重復(fù)寫統(tǒng)一處理業(yè)務(wù)錯(cuò)誤碼把請(qǐng)求成功但業(yè)務(wù)失敗和網(wǎng)絡(luò)異常分開統(tǒng)一打印日志接口調(diào)試的時(shí)候用得上class ApiClient { ApiClient._internal() { _dio Dio( BaseOptions( baseUrl: AppConfig.apiBaseUrl, connectTimeout: const Duration(seconds: 10), receiveTimeout: const Duration(seconds: 10), headers: {Accept: application/json}, ), ); _dio.interceptors.add( InterceptorsWrapper( onRequest: (options, handler) { // 這里可以統(tǒng)一加 token handler.next(options); }, onResponse: (response, handler) { final code response.data[code]; if (code ! 0) { handler.reject(DioException( requestOptions: response.requestOptions, message: response.data[message] ?? 業(yè)務(wù)錯(cuò)誤, type: DioExceptionType.badResponse, )); return; } // 接口真正的數(shù)據(jù)藏在 data 里 response.data response.data[data]; handler.next(response); }, onError: (error, handler) { // 統(tǒng)一異常提示文案 handler.next(error); }, ), ); } static final ApiClient instance ApiClient._internal(); final Dio _dio; Dio get dio _dio; }這套封裝最常用的場(chǎng)景其實(shí)是后面調(diào)試階段——開代理抓包時(shí)需要加自定義 header改動(dòng)只落在onRequest一處全 App 生效。我建議每個(gè)人在項(xiàng)目初期都做類似封裝后面省下的時(shí)間遠(yuǎn)超前期花費(fèi)的時(shí)間。4.3 數(shù)據(jù)服務(wù)層的另一個(gè)職責(zé)把數(shù)據(jù)喂給頁(yè)面之前先處理成頁(yè)面想要的形狀有些團(tuán)隊(duì)會(huì)把 service 層做得很薄直接返回模型列表。我在這次項(xiàng)目里除了返回模型還封裝了一個(gè)重要的能力錯(cuò)誤轉(zhuǎn)換成用戶可讀的提示。比如網(wǎng)絡(luò)斷開時(shí)Service 層會(huì)返回一個(gè)ApiException里面帶上messageUI 層拿到這個(gè)異常后直接展示在錯(cuò)誤視圖上不用做二次判斷。class ArticleService { FutureListArticleModel fetchArticles({required int page, int pageSize AppConfig.pageSize}) async { try { final response await ApiClient.instance.dio.get( /articles, queryParameters: {page: page, page_size: pageSize}, ); final listJson response.data as Listdynamic; return listJson .map((e) ArticleModel.fromJson(e as MapString, dynamic)) .toList(); } on DioException catch (e) { throw ApiException( message: e.type DioExceptionType.connectionTimeout ? 網(wǎng)絡(luò)有點(diǎn)慢請(qǐng)稍后再試 : 加載失敗請(qǐng)檢查網(wǎng)絡(luò), ); } } }這樣 UI 層永遠(yuǎn)只面對(duì)兩種結(jié)果成功拿到模型列表或者拿到一個(gè)用戶能看懂的錯(cuò)誤文案。判斷邏輯不散落在頁(yè)面各處長(zhǎng)期維護(hù)的體驗(yàn)會(huì)好很多。5. 狀態(tài)管理用 Riverpod但真正復(fù)雜的是頁(yè)面里怎么組織狀態(tài)5.1 為什么狀態(tài)管理從 Provider 換成了 Riverpod如果你早期用過(guò) Flutter 官方的 Provider能明顯感覺(jué)到它簡(jiǎn)單但也有幾個(gè)讓人別扭的痛點(diǎn)依賴 BuildContext 才能讀狀態(tài)測(cè)試的時(shí)候必須包一層 Provider 結(jié)構(gòu)。Riverpod 最大的改觀是Provider 聲明和組件樹解耦了任何地方都能通過(guò) ref 讀到狀態(tài)代碼組織起來(lái)更接近依賴注入的思路。我在這次項(xiàng)目里用到的全局狀態(tài)只有兩類文章列表的異步加載狀態(tài)、以及當(dāng)前的請(qǐng)求分頁(yè)參數(shù)?？雌饋?lái)不多但 Riverpod 在處理頁(yè)面銷毀后狀態(tài)要不要保留這個(gè)問(wèn)題上非常順手。緩存的是 Provider 實(shí)例化的對(duì)象可以跨頁(yè)面保持這對(duì)詳情頁(yè)從列表頁(yè)讀取數(shù)據(jù)緩存很有用。5.2 AsyncNotifier 的寫法省掉所有手動(dòng) setState我實(shí)際上用的是AsyncNotifier因?yàn)樗鸭虞d中、成功、失敗三個(gè)狀態(tài)統(tǒng)一塞進(jìn)了一個(gè)AsyncValue里。頁(yè)面里只需要看AsyncValue當(dāng)前的快照來(lái)決定渲染加載動(dòng)畫、錯(cuò)誤視圖還是列表。class ArticleListNotifier extends AsyncNotifierListArticleModel { int _page 1; bool _hasMore true; override FutureListArticleModel build() async { return _fetchPage(); } FutureListArticleModel _fetchPage() async { final list await ref.read(articleServiceProvider).fetchArticles(page: _page); return list; } Futurevoid refresh() async { _page 1; _hasMore true; state const AsyncLoading(); state await AsyncValue.guard(_fetchPage); } Futurevoid loadMore() async { if (_hasMore) { final next await ref.read(articleServiceProvider).fetchArticles(page: _page 1); if (next.isEmpty) { _hasMore false; return; } state AsyncData([...?state.value ?? [], ...next]); _page; } } }注意refresh()里我用了AsyncValue.guard而不是自己寫 try-catch這是 Riverpod 提供的便捷方法能自動(dòng)把異常包成AsyncErrorUI 層拿到它直接展示錯(cuò)誤視圖方便得很。5.3 列表頁(yè)的 UI 組裝邊角狀態(tài)幾乎比主要邏輯還多一個(gè)信息流首頁(yè)正常狀態(tài)是列表除此之外還要處理空列表、初次加載中、刷新失敗、加載更多失敗、加載到底部等狀態(tài)。大多數(shù)人寫列表頁(yè)只放一個(gè) ListView結(jié)果一旦網(wǎng)絡(luò)慢或斷網(wǎng)用戶體驗(yàn)就很糟。我的做法是用AsyncValue.when分三路渲染再在error分支里區(qū)分是否已有歷史數(shù)據(jù)。如果當(dāng)前state.value不為空說(shuō)明是刷新失敗就保留列表并在頂部彈個(gè) SnackBar如果state.value為空說(shuō)明是首次加載失敗才展示全屏錯(cuò)誤視圖。final articlesAsync ref.watch(articleListProvider); return articlesAsync.when( data: (articles) RefreshIndicator( onRefresh: () ref.read(articleListProvider.notifier).refresh(), child: ListView.builder( itemCount: articles.length 1, itemBuilder: (context, index) { if (index articles.length) { return const _NoMoreFooter(); } return ArticleCard(article: articles[index]); }, ), ), loading: () const Center(child: CircularProgressIndicator()), error: (err, stack) ErrorView(message: err.toString()), );這個(gè)拆分是真的實(shí)用上線后愿意把列表頁(yè)做完善的人和只跑通 Demo 的人頁(yè)面的皮實(shí)程度一眼就能看出來(lái)。6. 圖片、緩存、還有那個(gè)下拉刷新的隱藏坑6.1 圖片緩存不要手寫但要了解原理信息流頁(yè)面最容易卡的地方就是圖片。服務(wù)器返回的封面圖如果不做緩存每次滾出視野再滾回來(lái)就要重新下載基本等于災(zāi)難。這次我用cached_network_image一行代碼接入CachedNetworkImage( imageUrl: article.coverUrl, fit: BoxFit.cover, placeholder: (context, url) const ShimmerBox(), errorWidget: (context, url, error) const Icon(Icons.broken_image), )它內(nèi)部會(huì)緩存到內(nèi)存和磁盤滾動(dòng)回訪不再重新請(qǐng)求網(wǎng)絡(luò)。有一點(diǎn)必須提醒圖片占位圖不要用默認(rèn)的灰色方塊我只是寫了一個(gè)極簡(jiǎn)的ShimmerBox一個(gè)帶淺色背景的 Container就能讓首屏加載的觀感提升一個(gè)檔次。一個(gè)背景色循環(huán)動(dòng)畫的封裝半天就能寫好收益很值。6.2 列表詳情頁(yè)的本地緩存策略我這次給詳情頁(yè)做了一個(gè)先展示緩存、再靜默更新的策略。具體實(shí)現(xiàn)進(jìn)入詳情頁(yè)時(shí)先用文章的 id 去本地緩存找歷史記錄包括標(biāo)題、內(nèi)容、時(shí)間如果有緩存立即展示緩存內(nèi)容同時(shí)發(fā)起網(wǎng)絡(luò)請(qǐng)求拿到最新數(shù)據(jù)后刷新頁(yè)面并更新緩存如果當(dāng)前斷網(wǎng)就停在緩存頁(yè)面并提示當(dāng)前顯示的是離線緩存這個(gè)策略的代碼核心非常簡(jiǎn)單但能實(shí)打?qū)嵦嵘脩羧蹙W(wǎng)體驗(yàn)。我用shared_preferences存緩存 JSON因?yàn)樗钱惒降?、開銷小詳情頁(yè)數(shù)據(jù)這種單條對(duì)象用鍵值存儲(chǔ)足夠了。class DetailCacheService { static const String _keyPrefix detail_; final SharedPreferences _prefs; Futurevoid save(String articleId, ArticleModel article) async { await _prefs.setString(_keyPrefix articleId, jsonEncode(article.toJson())); } ArticleModel? read(String articleId) { final raw _prefs.getString(_keyPrefix articleId); if (raw null) return null; return ArticleModel.fromJson(jsonDecode(raw) as MapString, dynamic); } }如果換更大的項(xiàng)目建議改成數(shù)據(jù)庫(kù)或文件存儲(chǔ)一兩個(gè)頁(yè)面用 prefs 清爽夠用。6.3 下拉刷新的一個(gè)隱藏坑Flutter 的RefreshIndicator默認(rèn)嵌套在ListView里很順暢但有一個(gè)常見(jiàn) bug當(dāng)列表內(nèi)容不滿一屏?xí)r手勢(shì)下拉經(jīng)常觸發(fā)不了刷新。原因是ListView默認(rèn)只要內(nèi)容不到一屏就沒(méi)有足夠的滾動(dòng)空間下拉手勢(shì)會(huì)被識(shí)別成普通滑動(dòng)。解決辦法是給ListView加一個(gè)AlwaysScrollableScrollPhysics()ListView.builder( physics: const AlwaysScrollableScrollPhysics(), itemCount: articles.length 1, ... )這個(gè)小改動(dòng)如果你不提前知道真機(jī)調(diào)試時(shí)會(huì)覺(jué)得明明寫了 RefreshIndicator 為什么拉不動(dòng)特別浪費(fèi)時(shí)間。7. 詳情頁(yè)、路由參數(shù)和返回刷新平時(shí)最容易忽略的聯(lián)動(dòng)邏輯7.1 詳情頁(yè)布局與生命周期詳情頁(yè)的布局相對(duì)簡(jiǎn)單頂部標(biāo)題、作者和時(shí)間、封面大圖、正文文本。但有一個(gè)業(yè)務(wù)細(xì)節(jié)值得注意詳情頁(yè)可能會(huì)從列表頁(yè)進(jìn)入也可能從收藏列表搜索頁(yè)進(jìn)入。不管從哪進(jìn)詳情頁(yè)都需要知道自己展示的是哪篇文章。我在前面提到過(guò)用一個(gè)DetailArgument打包參數(shù)class DetailArgument { final String articleId; final String title; final String coverUrl; const DetailArgument({ required this.articleId, this.title , this.coverUrl , }); }跳轉(zhuǎn)時(shí)Navigator.pushNamed(context, /detail, arguments: DetailArgument( articleId: article.id, title: article.title, coverUrl: article.coverUrl, ));詳情頁(yè)拿到articleId之后先裝飾性地展示傳入的標(biāo)題和封面讓用戶感覺(jué)頁(yè)面秒開再實(shí)際請(qǐng)求正文內(nèi)容請(qǐng)求回來(lái)后再替換成完整數(shù)據(jù)。這比進(jìn)入詳情頁(yè)轉(zhuǎn)圈等接口的體驗(yàn)好太多。7.2 詳情頁(yè)返回列表頁(yè)時(shí)的狀態(tài)保留有時(shí)候用戶從列表點(diǎn)進(jìn)詳情在詳情頁(yè)喜歡了某篇文章回到列表時(shí)希望能反映這個(gè)狀態(tài)。我這次把喜歡狀態(tài)放在 Riverpod 的全局 Provider 里而不是 DetailPage 的局部 State。這樣詳情頁(yè)更新了喜歡狀態(tài)列表項(xiàng)通過(guò)監(jiān)聽同一個(gè) Provider 自動(dòng)刷新。final favoriteIdsProvider StateProviderSetString((ref) String{});列表頁(yè)的 ArticleCard 用ref.watch(favoriteIdsProvider.select((v) v.contains(article.id)))來(lái)決定紅心是否點(diǎn)亮。返回列表時(shí)不用手動(dòng)刷新任何東西狀態(tài)天然同步。這是狀態(tài)管理分離 UI 和邏輯之后最爽的一點(diǎn)。8. 調(diào)試技巧、打包配置、以及我在這個(gè)項(xiàng)目里最想分享的三句話8.1 日志與調(diào)試Flutter DevTools 是神器聯(lián)網(wǎng)應(yīng)用調(diào)試時(shí)最剛需的是看請(qǐng)求參數(shù)和響應(yīng)數(shù)據(jù)。dio 自帶的LogInterceptor在 debug 模式開起來(lái)就夠了if (!kReleaseMode) { _dio.interceptors.add(LogInterceptor(responseBody: true)); }真機(jī)調(diào)試時(shí)我最常用的工具是 Flutter DevTools 里的 Network 面板和 Inspector。前者能看請(qǐng)求耗時(shí)和數(shù)據(jù)體后者能實(shí)時(shí)查看 Widget 樹排查布局溢出非常直觀。開發(fā)時(shí)發(fā)現(xiàn)渲染問(wèn)題先打開 Inspector 看父級(jí)約束一大半問(wèn)題當(dāng)場(chǎng)就能定位。8.2 Android 打包的配置要點(diǎn)先用flutter build apk --release打出安裝包前有幾步別漏確認(rèn)ApplicationId改成自己的包名在AndroidManifest.xml里給發(fā)布版本加好網(wǎng)絡(luò)權(quán)限默認(rèn) debug 有release 可能沒(méi)開如果用了網(wǎng)絡(luò)明文地址Android 9 以上系統(tǒng)默認(rèn)禁止明文 HTTP需要配置usesCleartextTraffictrue或者做網(wǎng)絡(luò)安全配置。一個(gè)小細(xì)節(jié)發(fā)布前把a(bǔ)ndroid/app/build.gradle里的minifyEnabled保持默認(rèn) false。Flutter 的 release 構(gòu)建體積本來(lái)不小開啟混淆并不能像原生那樣顯著瘦身反而可能引入 runtime 問(wèn)題新手期沒(méi)必要碰。8.3 iOS 與 macOS 環(huán)境的注意點(diǎn)如果你主要在 Windows 上開發(fā)最后需要一臺(tái) macOS 來(lái)打包 iOS 版本。這點(diǎn)我在項(xiàng)目開始就提醒了Flutter 項(xiàng)目跨端能力確實(shí)好但 Apple 平臺(tái)的構(gòu)建環(huán)節(jié)繞不開 macOS。提前確認(rèn)好公司/團(tuán)隊(duì)有沒(méi)有 Mac再?zèng)Q定最終交付哪幾個(gè)平臺(tái)。也可以在項(xiàng)目早期就把 iOS 目錄生成好避免后面想發(fā) iOS 還得回來(lái)補(bǔ)配置。提示我在實(shí)戰(zhàn)中踩過(guò)一個(gè)特別無(wú)腦的坑——用flutter create .時(shí)沒(méi)有先生成 iOS 目錄結(jié)果真正要發(fā) iOS 時(shí)補(bǔ)生成導(dǎo)致丟了一些平臺(tái)特有配置。項(xiàng)目創(chuàng)建時(shí)就把所有目標(biāo)平臺(tái)的目錄一次性生成之后不想要可以刪但別等要的時(shí)候再補(bǔ)。8.4 三句實(shí)操心得第一項(xiàng)目實(shí)戰(zhàn)的進(jìn)度不取決于你會(huì)多少而取決于你能不能把一個(gè)功能從網(wǎng)絡(luò)走到界面完整跑通。比起反復(fù)研究十幾個(gè)包不如把一兩條數(shù)據(jù)流徹底打通。第二處理異常時(shí)的體驗(yàn)決定了別人愿不愿意持續(xù)用你的 App。網(wǎng)絡(luò)錯(cuò)誤頁(yè)面不能只顯示一串英文異常至少提供重試按鈕加載失敗時(shí)要保留上次數(shù)據(jù)而不是直接白屏。這套邏輯在初期就要寫進(jìn)列表頁(yè)模板里后面每個(gè)頁(yè)面都復(fù)用。第三從一開始就給工程留一層替換的余地。數(shù)據(jù)源的替換、接口的替換、ui 主題的替換分別隔離到 service、provider、theme 三層里。這個(gè)項(xiàng)目未來(lái)不管是接入真實(shí)后端、改成別的題材還是派生出新 App都會(huì)變得非常輕松。9. 關(guān)于這個(gè)項(xiàng)目的后續(xù)擴(kuò)展信息流只是骨架到這里第一個(gè)實(shí)戰(zhàn)項(xiàng)目的核心流程已經(jīng)完整走通了啟動(dòng)頁(yè)加載、首頁(yè)列表、網(wǎng)絡(luò)異常處理、詳情頁(yè)緩存、下拉刷新、返回聯(lián)動(dòng)狀態(tài)、打包發(fā)布的前置配置。說(shuō)實(shí)話這個(gè)骨架的復(fù)用性比我做之前預(yù)想的還要高。我真切建議你把這份代碼跑起來(lái)之后試著做三個(gè)方向的擴(kuò)展把數(shù)據(jù)源從模擬接口換成本地 JSON 或真實(shí)后端給列表加上分類 tab加一個(gè)簡(jiǎn)單的搜索頁(yè)。每一件事都不會(huì)動(dòng)搖已經(jīng)搭好的架構(gòu)——這就是分模塊帶來(lái)的底氣。如果你碰到與文章里不同的報(bào)錯(cuò)或現(xiàn)象大概率出在環(huán)境版本上。優(yōu)先確認(rèn)三樣?xùn)|西Flutter SDK 版本、dio 版本、Riverpod 版本。版本組合不同API 細(xì)節(jié)會(huì)有差異但整體思路完全一致。下次實(shí)戰(zhàn)我準(zhǔn)備把登錄流程和 token 刷新、本地?cái)?shù)據(jù)庫(kù)、通知推送這幾個(gè)更貼近商業(yè)項(xiàng)目的模塊拆開講到時(shí)候再繼續(xù)。