生產(chǎn)中的 flutter 應用程序中的灰屏是一種通用占位符，當框架遇到問題無法渲染預期用戶界面時就會顯示。是的，所以基本上是出現(xiàn)問題時的后備指示器。

有趣的是，這只出現(xiàn)在發(fā)布模式下。在任何其他模式下運行都會顯示紅色錯誤屏幕，并說明導致錯誤的原因。 （檢查此處以了解各種類型的構建模式。）此類錯誤的常見原因是：

• 未處理的異常：這些是運行時發(fā)生的錯誤，未使用 try-catch 塊捕獲。
• 渲染錯誤：這些是渲染布局時引起的問題，例如，在 Column 、 Row 或 Flex 小部件外部使用 Expanded 時引起的問題。

以下是可能導致灰屏的代碼示例：

class HomeView extends HookWidget {
  const HomeView({super.key});
  @override
  Widget build(BuildContext context) {
    const widget = null;
    return Scaffold(
      appBar: AppBar(
        title: Text(
          'Gallery',
          style: Theme.of(context).textTheme.headlineLarge,
        ),
      ),
      body: widget!,
    );
  }
}

在這里，我們犯了一個明顯的錯誤，在我們知道的 null 小部件上使用了 bang 運算符(!)，這導致在非發(fā)布模式下出現(xiàn)紅屏，在發(fā)布模式下出現(xiàn)灰屏。

需要注意的是，我們不建議在不更新的情況下將部件明確設置為空值，空值錯誤是一個常見錯誤，而上述操作是重現(xiàn)該錯誤的簡單方法。

調(diào)試模式下的紅色錯誤屏幕（左）和發(fā)布模式下的灰色屏幕（右）的圖像

自定義錯誤屏幕

為了顯示更用戶友好的消息而不是灰屏，我們將策略性地在 main 函數(shù)中放置一行代碼。該行充當預防措施，確保每當發(fā)生未處理的異常時都會顯示自定義錯誤屏幕。

void main() {
  ErrorWidget.builder = (_) => const AppErrorWidget(); // This line does the magic!
  runApp(MyApp());
}

有條件的紅屏（可選）：

也許您希望在開發(fā)過程中看到默認的紅色錯誤屏幕以進行調(diào)試。您可以通過將 ErrorWidget.builder 賦值包裝在檢查當前構建模式的 if 語句中來實現(xiàn)此目的：

void main() {
  if (kReleaseMode) ErrorWidget.builder = (_) => const AppErrorWidget();
  runApp(MyApp());
}

下一步涉及創(chuàng)建 AppErrorWidget 本身的內(nèi)容。該小部件將確定發(fā)生未處理的異常時用戶看到的內(nèi)容。

class AppErrorWidget extends StatelessWidget {
  const AppErrorWidget({super.key});

  @override
  Widget build(BuildContext context) {
    return const Material(
      color: Colors.white,
      child: Padding(
        padding: EdgeInsets.all(24),
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          mainAxisSize: MainAxisSize.min,
          children: [
            Icon(
              Icons.warning,
              size: 200,
              color: Colors.amber,
            ),
            SizedBox(height: 48),
            Text(
              'So... something funny happened',
              textAlign: TextAlign.center,
              style: TextStyle(
                fontSize: 24,
                fontWeight: FontWeight.bold,
              ),
            ),
            SizedBox(height: 16),
            Text(
              'This error is crazy large it covers your whole screen. But no worries'
              ' though, we\'re working to fix it.',
              textAlign: TextAlign.center,
              style: TextStyle(
                fontSize: 16,
              ),
            ),
          ],
        ),
      ),
    );
  }
}

雖然鼓勵自定義應用程序的體驗，但 ErrorWidget.builder 上的 Flutter 文檔提醒我們，調(diào)用錯誤小部件時視圖處于不穩(wěn)定狀態(tài)。構建（可能還有布局）期間的異常會使系統(tǒng)處于脆弱狀態(tài)。為了最大限度地減少進一步的問題，返回的小部件應該做最少的工作。 LeafRenderObjectWidget （如默認的 RenderErrorBox ）非常適合處理意外約束。

ErrorWidget.builder 的幕后花絮

現(xiàn)在我們知道，當渲染預期 UI 的過程中發(fā)生錯誤時， ErrorWidget.builder 就會被調(diào)用，但是這到底是如何實現(xiàn)的呢？

如果我們深入研究 Flutter 的框架，我們會在構建或重建小部件時看到一個名為 _updateChild() 的方法。

void _updateChild() {
  try {
    final Widget child = (widget as _RawView).builder(this, _effectivePipelineOwner);
    _child = updateChild(_child, child, null);
  } catch (e, stack) {
    final FlutterErrorDetails details = FlutterErrorDetails(
      exception: e,
      stack: stack,
      library: 'widgets library',
      context: ErrorDescription('building $this'),
      informationCollector: !kDebugMode ? null : () => <DiagnosticsNode>[
        DiagnosticsDebugCreator(DebugCreator(this)),
      ],
    );
    FlutterError.reportError(details);
    final Widget error = ErrorWidget.builder(details);
    _child = updateChild(null, error, slot);
  }
}

我們可以看到 ErrorWidget.builder 屬性用于根據(jù)提供的 FlutterErrorDetails 檢索自定義錯誤小部件；然后更新 _child 變量以顯示自定義錯誤小部件而不是原始子小部件。

提升開發(fā)者體驗

定制向用戶呈現(xiàn)錯誤的方式是改善用戶體驗的關鍵一步。雖然 ErrorWidget.builder 幫助我們在出現(xiàn)錯誤時管理用戶體驗，但它并沒有為生產(chǎn)環(huán)境中的開發(fā)人員提供有價值的見解。本地調(diào)試不再是一種選擇，那么我們?nèi)绾渭皶r了解用戶設備上發(fā)生的錯誤呢？

這就是我們利用 FlutterError.onError 回調(diào)的力量的地方。讓我們看看這是如何完成的：

void main() {
  if (kReleaseMode) ErrorWidget.builder = (_) => const AppErrorWidget();

  FlutterError.onError = (details) {
    FlutterError.dumpErrorToConsole(details);
    if (!kReleaseMode) return;
    // 發(fā)送到您的 crashlytics 服務...
  };

  runApp(MyApp());
}

我們添加了一行新代碼，它將新的回調(diào)函數(shù)分配給 FlutterError.onError 屬性。每當使用 FlutterError.reportError 報告錯誤時都會調(diào)用此回調(diào)。

在回調(diào)內(nèi)部， FlutterError.dumpErrorToConsole(details) 通過將錯誤詳細信息轉儲到控制臺來幫助我們了解幕后情況。這對于在部署或分階段部署期間可能存在對用戶設備的訪問受限的調(diào)試目的非常有用。

最后的注釋行 ( // 發(fā)送到您的 crashlytics 服務... ) 強調(diào)了這種方法的真正威力。在這里，您可以集成您選擇的錯誤報告服務（例如 Crashlytics）以發(fā)送詳細的錯誤報告以供分析。

注意：此行包含在 if 語句中，以確保它僅在調(diào)試或分析模式下執(zhí)行 ( !kReleaseMode )。

避免灰屏的最佳錯誤處理實踐

我們已經(jīng)了解了導致灰屏的原因以及出現(xiàn)灰屏時如何更好地處理它；我們還應該介紹的一件事是，作為開發(fā)人員可以采取哪些措施來避免出現(xiàn)灰屏。其中一些是：

• 擁抱 try-catch ：將關鍵代碼部分包裝在 try-catch 塊內(nèi)。這允許您捕獲潛在的異常并提供優(yōu)雅的回退機制。
• 少用 Bang 運算符 (!)：bang 運算符 (!) 是 null 斷言檢查的快捷方式，但如果用于不確定是否為非 null 的值，可能會導致意外錯誤。更多地使用條件表達式 (??) 或 null 感知訪問運算符 (?.)。
• 徹底的應用程序測試：結合使用單元、小部件、集成和手動測試來幫助在問題出現(xiàn)在生產(chǎn)中之前識別和解決問題。
• 尊重 Widget 約束：Flutter 中的每個 Widget 都有局限性和預期的使用模式；避免在其限制之外使用它們，例如在可滾動視圖中使用 Spacer 。

結論：擁抱不可避免的事情

錯誤處理是任何編寫良好的 Flutter 應用程序的重要組成部分。當您努力編寫干凈的代碼并預測潛在問題時，異常情況必然會發(fā)生。通過實施 ErrorWidget.builder ，您可以確保即使發(fā)生意外情況，您的用戶也會看到清晰且內(nèi)容豐富的消息，而不是令人困惑的灰屏，并且通過 FlutterError.onError 您可以確保您記錄這些意外錯誤，并且可以更輕松地調(diào)試和修復這些錯誤。

以上就是Flutter中灰屏問題的原因及解決方法的詳細內(nèi)容，更多關于Flutter中灰屏問題的資料請關注腳本之家其它相關文章！

最新評論