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

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

• 未處理的異常：這些是運行時發(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)灰屏。

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

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

自定義錯誤屏幕

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

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

有條件的紅屏（可選）：

也許您希望在開發(fā)過程中看到默認的紅色錯誤屏幕以進行調(diào)試。您可以通過將 ErrorWidget.builder 賦值包裝在檢查當前構(gòu)建模式的 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,
              ),
            ),
          ],
        ),
      ),
    );
  }
}

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

ErrorWidget.builder 的幕后花絮

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

如果我們深入研究 Flutter 的框架，我們會在構(gòu)建或重建小部件時看到一個名為 _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)錯誤的方式是改善用戶體驗的關(guān)鍵一步。雖然 ErrorWidget.builder 幫助我們在出現(xiàn)錯誤時管理用戶體驗，但它并沒有為生產(chǎn)環(huán)境中的開發(fā)人員提供有價值的見解。本地調(diào)試不再是一種選擇，那么我們?nèi)绾渭皶r了解用戶設(shè)備上發(fā)生的錯誤呢？

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

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

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

  runApp(MyApp());
}

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

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

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

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

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

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

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

結(jié)論：擁抱不可避免的事情

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

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

最新評論