認真對待每時、每刻每一件事，把握當下、立即去做。

Flutter UI 性能優化實踐經驗，結合從“布局優化、渲染優化、實踐建議”幾個維度和具體代碼示例進行一個解析。

一. 布局優化

核心目標是減少布局計算量，避免布局重排（Relayout），提升布局效率。

1. 懶加載減少布局計算?

作用階段：布局階段。

優化邏輯：通過 Sliver 架構按需渲染可見區域子項，避免一次性計算所有子項的布局（如10萬條數據的列表）。

示例：使用 ListView.builder 實現懶加載（懶加載注重按需渲染），只構建可見項，避免一次性計算所有子項布局。

//  ? 錯誤寫法
Column(children: [
  Header(),
  ListView(children: items.map((e) => Item(e)).toList())
])

// ? 正確寫法
Column(children: [
  Header(),
  Expanded(child: ListView.builder(itemCount: items.length))
])

同時要注意避免在 Column 中嵌套 ListView 導致布局沖突：

Column 就像一個需要精確計算總高度的收納箱，它要求所有子組件（如Header、ListView）必須明確自己的“身高”（即確定的高度值）。如果子組件中存在一個“不確定身高”的成員（如默認狀態的 ListView），Column 就會卡住——因為它無法匯總總高度，系統直接報錯：“Vertical viewport was given unbounded height”（垂直視圖被賦予了無邊界高度）。

ListView 的設計邏輯是“盡可能占滿垂直空間”（類似一個永遠想長高的彈簧）。它默認會向父容器（Column）索要“無限高度”，以便滾動顯示所有內容。但當它被直接放進 Column 時，Column 會反問：“你到底多高？我得算總高度！”而ListView 卻回答：“我要多高取決于你給我的空間！”——雙方陷入“雞生蛋還是蛋生雞”的死循環。

Expanded 的“破局關鍵”：

• 約束重定向：Expanded 像一位“身高協調員”，它先接收 Column 分配的“剩余空間”（即 Column 總高度減去 Header 等固定高度后的值），再將這個有限高度強制塞給ListView。
• 強制約束：ListView 此時不再索要無限高度，而是乖乖適應分配到的有限空間，并在此空間內完成滾動區域的布局（僅渲染可見項，實現懶加載）。
• 總高度確定：Column 最終能計算出“Header高度 + ListView分配高度”的總和，布局成功完成。

2. 分幀渲染策略

作用階段：布局階段

優化邏輯：分幀渲染的本質是將原本可能超過 16.6ms 的構建任務拆解為多個子任務，分散到連續幀中執行，注重任務的拆分，避免單幀內布局計算超時（如16ms）導致卡頓。

示例：對長列表的逐項渲染或復雜動畫的分步計算。或在“過渡幀”僅通過占位符延遲真實內容加載，屬于視覺優化手段，未實際拆分構建任務。

用戶代碼通過 _showRealContent 控制占位符與真實內容的切換，僅減少首幀的構建壓力，但若 _buildReal() 本身耗時仍超過 16.6ms，依然會引發卡頓。真正的分幀渲染需結合 Future.delayed、compute 隔離計算或 ListView.builder 的懶加載機制。

2.1 過渡幀優化

過渡幀優化，本質上會增加總渲染時間，但改善了感知性能提升體驗。

bool _showRealContent = false;
@override
void initState() {
  super.initState();
  WidgetsBinding.instance.addPostFrameCallback((_) {
    setState(() => _showRealContent = true); // 下一幀加載真實內容
  });
}
Widget build(BuildContext context) => _showRealContent ? _buildReal() : _buildPlaceholder();

addPostFrameCallback 工作原理：WidgetsBinding.instance.addPostFrameCallback 會在當前幀繪制完成后執行回調函數，且回調只執行一次。

2.2 分幀渲染構建

2.2.1 使用 Future.delayed 分幀渲染

在順序加載大量小部件時，通過將任務拆分為多個異步幀執行，避免主線程阻塞，加載1000個 Widget 時，通過 Future.delayed 每幀添加10個，避免單幀布局計算量過大。

Future<void> _loadDataInFrames(List<Widget> widgets) async {
  for (var i = 0; i < widgets.length; i++) {
    await Future.delayed(Duration(milliseconds: 16)); // 約60fps的幀間隔
    setState(() {
      _visibleWidgets.add(widgets[i]); // 逐幀添加Widget到界面
    });
  }
}

2.2.2 使用 compute 或 Isolate 隔離計算

將耗時計算放到隔離線程，完成后分幀更新 UI，適合 CPU 密集型任務（如 JSON 解析、圖像處理）。

// 定義耗時計算函數（需為頂級函數或靜態方法）
static int _heavyCalculation(int input) {
  return input * 2; // 模擬復雜計算
}

// 在UI線程調用
void _startCalculation() async {
  final result = await compute(_heavyCalculation, 1000000);
  setState(() => _result = result); // 計算完成后更新UI
}

2.2.3 Keframe 組件庫

復雜頁面集成 Keframe 自動拆分組件樹為多幀渲染，卡頓減少50%。

FrameSeparateWidget(
  child: YourComplexWidget(), // 包裹復雜組件
)

3. RelayoutBoundary 布局邊界

作用階段：布局階段。

優化邏輯：通過設立布局邊界，阻止子節點尺寸變化向上傳遞，減少父節點的重新布局計算。

在開發中一般很不直接使用 RelayoutBoundary，我們可以使用三個條件來觸發 RelayoutBodudary 生效。

示例：在 ListView 子項中使用 SizedBox 固定高度，避免子項高度變化觸發父列表重新布局。

3.1 constraints.isTight

強約束，Widget 的 size 已經被確定，里面的子 Widget 做任何變化，size 都不會變。那么從該 Widget 開始里面的任意子 Wisget 做任意變化，都不會對外有影響，就會被添加 Relayout boundary（說添加不科學，因為實際上這種情況，它會把 size 指向自己，這樣就不會再向上遞歸而引起父 Widget 的 Layout了）。

3.2 parentUsesSize == false

實際上 parentUsesSize 與 sizedByParent 看起來很像，但含義有很大區別
parentUsesSize 表示父 Widget 是否要依賴子 Widget 的 size，如果是 false，子Widget 要重新布局的時候并不需要通知 parent，布局的邊界就是自身了。

3.3 sizedByParent == true

可以理解為?"尺寸由父級全權決定"?的布局模式。當 Widget 設置該屬性時，它的尺寸不依賴自身內容計算，而是完全服從父級分配的約束條件，就像學生按照老師指定的座位表入座，無需自己找位置。

父級主導?：尺寸由父級約束直接確定，跳過 Widget 自身的布局計算邏輯。

?非嚴格約束?：雖非isTight（嚴格約束），但通過父級規則（如 Flex 布局的剩余空間分配）仍能明確尺寸。

?性能優化?：避免子 Widget 重復計算尺寸，提升布局效率。

RelayoutBoundary 的設立原則是：?子節點尺寸變化不會影響父節點尺寸?。

若 sizedByParent == true，由于子節點尺寸完全依賴父節點約束，其自身尺寸變化不會向上傳遞影響父節點，因此自然滿足 RelayoutBoundary 的條件。

二. 渲染優化

核心目標減少繪制開銷，避免無效重繪（Repaint），提升渲染效率。

1. 控制刷新范圍

作用階段：渲染階段。

優化邏輯：通過 Provider.select() 或 ValueNotifier 精準實現局部狀態更新，減少不必要的重繪。- 狀態管理優化。

• Provider.select()：僅監聽特定狀態變化，觸發局部 Widget 重建。
• ValueNotifier：通過 ValueListenableBuilder 精準更新特定區域。

Selector<Model, String>(
  selector: (_, model) => model.title,
  builder: (_, title, __) => Text(title) // 僅title變化時重建
)

示例：列表中單個項的狀態更新時，僅重建該子項，而非整個列表。

2. 避免無效重建?

作用階段：渲染階段。

優化邏輯：通過 const 聲明靜態 Widget，在編譯時確定實例，避免運行時重復創建，減少繪制開銷。

示例：使用 const 構造函數聲明靜態 Widget，避免每次構建時重新創建相同內容：

const Text('靜態文本'), // ? 編譯期確定
Text('動態文本') // ? 每次重建

3. 隔離重繪區域

作用階段：渲染階段。

優化邏輯：通過設立重繪邊界，避免父（子）組件重繪觸發子（父）組件不必要重繪。

示例：對復雜子組件使用 RepaintBoundary 隔離重繪區域。?比如在動畫組件外包裹 RepaintBoundary，確保動畫重繪僅影響該邊界內區域，避免父組件連帶重繪：

RepaintBoundary(
  child: AnimatedContainer(...), // 獨立重繪的動畫組件
)

4. 避免 Clip、Opacity 等半透明組件等過渡使用

Clip（裁剪）：

• 渲染開銷：裁剪操作（尤其是 ClipPath 的自定義路徑）會觸發離屏渲染（Off-screen Rendering），需要 GPU 額外創建一個臨時緩沖區（Frame Buffer）來繪制裁剪后的內容，再合并到主幀緩沖區。復雜裁剪路徑（如貝塞爾曲線）會顯著增加 GPU 負載。
• 優化邏輯：減少不必要的裁剪（例如用 BoxDecoration 的borderRadius 替代 ClipRRect），或對靜態裁剪使用RepaintBoundary 緩存裁剪結果。

Opacity（透明度）：

• 渲染開銷：透明度變化會觸發組件及其子組件的重繪（因為需要重新計算顏色混合），且多層透明度疊加會導致合成階段（Composite）的層疊上下文（Stacking Context）增加，提升 GPU 合成復雜度。
• 優化邏輯：避免頻繁改變 Opacity 值（如動畫中用 AnimatedOpacity 替代手動更新），或對靜態透明組件使用 RepaintBoundary 隔離重繪。

三. 實踐建議

1. 長列表處理

使用 ListView.builder + 懶加載實現按需加載，配合 RepaintBoundary 隔離滾動項，其次結合 itemExtent 固定子項高度提升性能：

ListView.builder(
  itemCount: 10000,
  itemExtent: 56.0, // 固定高度避免動態計算
  itemBuilder: (ctx, i) => ListTile(title: Text('Item $i'))
)

結合 AutomaticKeepAliveClientMixin 實現狀態保持：

問題背景：在 ListView.builder 構建的長列表中，當列表項滾出可視區域時，Flutter 會銷毀其 Widget 樹并釋放內存（稱為“虛擬化列表”）。若列表項包含狀態（如輸入框內容、選中狀態、動畫進度），重新滾動回該位置時狀態會丟失。

解決方案：通過 AutomaticKeepAliveClientMixin 強制保留列表項的狀態，即使 Widget 被銷毀重建，狀態仍被緩存復用。

2. 動畫優化實踐

AnimatedBuilder 最佳實踐：預構建靜態子組件避免重復創建，相比直接在 builder 內創建子組件，性能更好。

AnimatedBuilder(
  animation: _animation,
  child: const HeavyWidget(), // ? 預構建
  builder: (_, child) => Transform.rotate(
    angle: _animation.value,
    child: child // 復用子組件
  )
)

使用 Tween 動畫?：優先使用輕量級動畫類型。

AnimationController(
  duration: const Duration(seconds: 1),
  vsync: this,
)..repeat(reverse: true);
final Animation<double> _animation = Tween(begin: 0.0, end: 1.0).animate(_controller);

3. ?圖片懶加載?

使用 cached_network_image 優化網絡圖片加載，高效加載和緩存網絡圖片，避免重復下載，提升性能。

CachedNetworkImage(
  imageUrl: 'https://example.com/image.jpg',
  placeholder: (_, __) => CircularProgressIndicator(),
  errorWidget: (_, __, ___) => Icon(Icons.error),
)

四. 工具與調試

1. 性能分析工具?

• 使用 DevTools 的 Performance 觀察緩存命中率、內存占用和 GPU 繪制時間，以及觀察視圖檢測超時幀（紅色標記）。
• 開啟 Repaint Rainbow 檢查過度重繪的 Widget。
• 通過 Timeline 視圖分析網絡請求次數和圖片加載耗時，確保懶加載生效。

2. ?構建模式?

始終在 profile 模式下測試性能，調試模式會引入額外性能開銷。：

flutter run --profile