【文章內容使用 Gemini 1.5 Pro 自動產生】

Flutter 是否提升了開發人員的生產力？

Flutter 團隊持續進行每季一次的使用者調查，以收集您，也就是 Flutter 開發人員的意見。2022 年的第一份調查於 2 月 22 日至 3 月 3 日進行，並透過 Flutter IDE 外掛、docs.flutter.dev 網站和 Twitter 進行訪問，超過 8,000 人參與了調查。

Flutter 仍然受到大多數開發人員的喜愛（93% 對 Flutter 感到滿意），甚至創下了有史以來「非常滿意」的最高百分比（60%）！這一點值得注意，因為自上次季度調查（2021 年 11 月至 2022 年 2 月）以來，Flutter 開發人員的數量增加了 10% 以上。我們很高兴看到，即使社群不斷增長，Flutter 仍然能够保持高水準的滿意度。

在此次調查中，我們重點關注以下四個主題：

• IDE 外掛：我們可以做些什麼來改進 Flutter 的 IDE 外掛支援？
• Dart 可擴展性：當 Flutter 專案規模越來越大時，Dart 工具是否會變慢或無回應？
• 遊戲開發：您是否對遊戲開發感興趣？ （更多資訊請參閱即將發布的部落格文章。）
• Flutter 對開發人員的價值：Flutter 是否實現了對開發人員做出的承諾？

我們不會視您的支持為理所當然，我們會密切关注顯示我們可以進一步改進的指標。我們意识到，改进的空间总是存在的，在本文中，我们将告诉您更多关于我们所学到的知识以及这些信息如何推动我们的路线图。

IDE 外掛

根據此次調查，63.5% 的開發人員對 Flutter 的 IDE 外掛「非常滿意」。那麼其他開發人員呢？為什麼他們沒有完全滿意？

如以下圖所示，沒有任何單一項目能突出顯示為沒有對 IDE 外掛完全滿意的原因。對 Android Studio/IntelliJ 和 VS Code 用戶來說，缺少功能（35%）是最主要的原因，但外掛速度慢（29%）、記憶體消耗（28%）、外掛有 bug（26%）都收到了不少票數。（當受訪者點擊 IDE 中的調查連結時，會記錄 IDE 類型）。

「IntelliJ」標籤也包含 Android Studio 用戶。

當我們詢問缺少或支援不完善的功能時，重構和快速修復被選為需要更好地支援的兩個最主要功能。這多少令人驚訝，因為我們沒有預料到重構會排名最高。此外，我們也驚訝地發現 Android Studio/IntelliJ 用戶非常關心導航，儘管我們理解 Android Studio/IntelliJ 用戶比 VS Code 用戶更關心 Android 整合。開發人員對 UI 建立器也有很大興趣。

總之，我們現在對 Flutter 開發人員的需求有了更清晰的理解。但是，我們將透過各種研究繼續了解改進關注領域所需的內容。

Dart 工具

Dart 工具（例如 Dart 分析器、編譯器、DevTools 和 IDE 外掛）使使用這種語言變得更加容易。我們從一些開發人員那裡得知，當 Flutter 專案規模很大時，Dart 工具可能會變慢甚至無回應。我們希望在下次調查中評估這個問題的普遍程度和嚴重程度。

從此次調查中我們發現，大約四分之一的開發人員遇到过這種情況（24.5%），其中近一半人表示，這對開發工作造成了極其負面的影響（16.7%）或中等負面的影響（29.6%）。

我們預計這些數字會更低，我們渴望在這方面有所改進，因此我們計劃與一些對后续对话表示兴趣的開發人員聯繫，以重現問題，並最終提高工具的效能。

Flutter 對開發人員的價值

Flutter 承諾提供一個框架，可以從單個程式碼庫構建美麗、快速、跨平台的應用程式。在本次調查中，我們探討了 Flutter 開發人員是否認為我們實現了這些價值。

我們向那些將現有應用程式轉換為 Flutter 的開發人員和從頭開始創建新 Flutter 應用程式的開發人員提問了不同的問題。允許選擇多個答案，59.2% 的開發人員從頭開始創建了新應用程式，26.5% 的開發人員要么將現有應用程式轉換為 Flutter，要么將 Flutter 組件添加到現有應用程式中。

對於那些使用 Flutter 創建新應用程式的開發人員，我們詢問他們在何種程度上同意關於與其他 Google 服務的整合、開發生產力和目標平台的三个陳述。我們發現，超過 90% 的開發人員同意「與我使用過的其他技術相比，Flutter 缩短了構建和發布新應用程式的時間」（92.1%），並且同意「Flutter 使我的應用程式能夠面向更多平台」。(92.2%)

類似的問題也詢問了那些將 Flutter 應用於現有應用程式的開發人員。90.7% 的開發人員同意「與之前相比，Flutter 使我的應用程式能夠更快速地開發」，85.3% 的開發人員同意「與之前相比，Flutter 使我的應用程式能夠在更多平台上提供」。我們還發現，84.8% 的開發人員同意「Flutter 使我的應用程式比以前更美觀」。

當然，我們也聽到了 Flutter 可以改进的地方，例如為所有支援的平台提供更多外掛、添加更多文件、提高感知效能、更好地與其他工具整合等等。一些評論還提到，某些問題領域在多年的調查之後依然沒有改變。雖然我們努力解决這些問題並改進產品，但我們感謝您的耐心！不過，我們很高兴了解到，我们的開發人员正以更高效的方式面向更多平台。

總結

特別感謝所有參與我們調查的人！Flutter 團隊成員每季度都会花時間分析和消化反馈，并为下一个季度及以后做出决策。我們會繼續收集您的意見，以了解我們可以做些什麼來讓您使用 Flutter 的体验更加愉快和高效。

Flutter 的 UX 研究團隊也在進行各種使用者體驗研究。如果您有興趣參與，請註冊以參加未來研究。

請繼續參與並分享您的想法。我們下次調查再见！

Flutter 是否提升了開發人員的生產力？ 最初發佈在 Medium 上的 Flutter，人們在那裡透過突出顯示和回應這個故事來繼續討論。

【文章內容使用 Gemini 1.5 Pro 自動產生】

敲鑼打鼓… 宣布 Flutter 拼圖 Hack 大賽得獎者！

Flutter 拼圖 Hack 大賽 邀請參賽者發揮創意，重新詮釋經典的滑動拼圖。可以說，作品讓評審們驚豔不已！

超過 5,500 位來自 120 多個國家、各個經驗層次的開發人員參與了 Flutter 拼圖 Hack 大賽。在公布各個類別的獲獎者之前，我們想向所有參與挑戰的開發者致敬。Flutter 社群再次團結一致，打造出非凡的成果。我們聚在一起參加了關於 動畫、Firebase 主機 和 滑動拼圖基礎 的演講。然後，看到 Flutter 開發人員打造出令人驚嘆的滑動拼圖陣容，一路分享亮點，為您最喜歡的拼圖投票，真是令人興奮。感謝大家！

成為如此熱情且充滿創意的社群的一份子，真是太棒了。誰能想到有這麼多不同的方法來建立一個簡單的滑動拼圖遊戲？🤷‍♂️

廢話不多說… 頒獎時間到！

各個類別的獲獎者

最佳執行

Planets，作者：Jyotirmoy Paul

這個專案在許多方面給評審們留下了深刻印象，包括出色的動畫運用、程式碼品質和純粹的創意。除了程式碼本身，Jyotirmoy 還分享了一些過程中很棒的學習時刻 - 看看他的分享，如果您有興趣。

最具創意

The Werewolves Escape，作者：Ahmad Ayaz Noor 和他的團隊

這個功能豐富的專案結合了 Flutter 在網頁、行動和桌面端的優點。故事線讓滑動拼圖遊戲的趣味提升到了一個全新的層級。查看他們的 作品提交頁面，了解這個團隊在建立這個專案時學到了什麼。

最佳動畫/設計

Retro Slide Puzzle，作者：Ashish Beck

這個拼圖的精緻視覺效果立刻吸引了評審們的注意。這個專案融合了流暢的 Rive 動畫、聲音外掛、自動完成和其他功能，讓遊戲體驗令人難以置信地令人滿足。

最佳跨平台

Slide Party，作者：Duong Bui Dai

您是否曾經想過與朋友比賽，看誰能最快解開一個滑動拼圖？這個拼圖讓您夢想成真！不僅如此，由於 Flutter 的靈活性，玩家甚至不需要在同一台設備或作業系統上。

超過 40 位獲獎者！

儘管這些是各個類別的獲獎者，但從這麼多創意中選出獲獎者幾乎是不可能的。Flutter 拼圖 Hack 大賽還有超過 30 位其他獲獎者，以及許多其他優秀的參賽作品。前往 flutter.dev/events/puzzle-hack 查看獲獎者，並親自嘗試他們的拼圖！

宣布 Flutter 拼圖 Hack 大賽得獎者！ 最初發佈在 Flutter 上的 Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。

http://creativecommons.org/licenses/by/4.0/

【文章內容使用 Gemini 1.5 Pro 自動翻譯產生】

Dart 非同步程式設計：串流

本文涵蓋了反應式程式設計的基礎之一：串流，它們是 Stream 類型的物件。

如果您已閱讀我們先前關於 Futures 的文章，您可能記得 每個 Future 代表一個單一值（錯誤或資料），以非同步方式傳遞。串流的工作方式類似，只是它不是單一物件，串流可以隨著時間傳遞零個或多個值和錯誤。

本文最初發表於 2020 年 2 月。此版本將包含的程式碼更新為可空安全性。

本文是基於《Flutter in Focus》影片系列《Dart 中的非同步程式設計》的第三篇文章。第一篇文章 Isolates and event loops 涵蓋了 Dart 支援背景工作的基礎知識。第二篇 Futures 討論了 Future 類別。

如果您喜歡透過觀看或聆聽來學習，本文中的所有內容都包含在以下影片中。

注意：本文中的程式碼已更新，以反映影片於 2019 年 6 月 28 日發佈後發生的最佳實務和 Dart 語言的變化（包括可空安全性）。

如果您考慮單一值與相同類型的 迭代器 的關係，那就是 Future 與串流的關係：Future 代表具有單一響應的單一請求，而串流代表具有多個響應的單一請求。

就像 Futures 一樣，關鍵是在事先決定 1) 當資料準備就緒時要做什麼，2) 發生錯誤時要做什麼，以及 3) 串流完成時要做什麼。與 Futures 一樣，在這個過程中，Dart 事件迴圈仍然在運行。

事件迴圈阻塞

例如，如果您使用 File 類別的 openRead() 方法從檔案讀取資料，此方法會返回一個串流。

資料塊從磁碟讀取並到達事件迴圈。Dart 函式庫查看它們並說：「啊，有人正在等待這個」，將資料加入到串流中，然後將其發送到您的應用程式。

當另一段資料到達時——它就會進入並出來。基於計時器的串流和從網路通訊端串流資料也與事件迴圈一起工作，使用時鐘和網路事件。

監聽串流

接下來要了解的是如何使用串流提供的資料。

假設您有一個類別，它提供一個串流，每秒發出一個新的整數（1、2、3、4、5…）。您可以使用 listen() 方法訂閱串流。唯一的必需參數是一個函數。

1
2
3
4
5

final myStream = NumberCreator().stream;

final subscription = myStream.listen(
    (data) => print('Data: $data'),
);

每次串流發出新值時，都會呼叫該函數並列印該值：

1
2
3
4
5

Data: 1
Data: 2
Data: 3
Data: 4
...

這就是 listen() 的工作原理。

重要：預設情況下，串流設定為單一訂閱。它們會保留其值，直到有人訂閱，並且它們在其整個生命週期中只允許一個監聽器。如果您嘗試兩次監聽同一個串流，則會收到異常。

幸運的是，Dart 也提供廣播串流。您可以使用 asBroadcastStream() 方法從單一訂閱串流建立廣播串流。廣播串流的工作方式與單一訂閱串流相同，但它們可以有多個監聽器。

廣播串流的另一個區別：如果在資料準備就緒時沒有人在監聽，則該資料會被丟棄。

1
2
3
4
5
6
7
8
9

final myStream = NumberCreator().stream;

final subscription = myStream.listen(
  (data) => print('Data: $data'),
);

final subscription2 = myStream.listen(
  (data) => print('Data again: $data'),
);

讓我們回到第一個 listen() 呼叫，因為還有一些事情要討論。

如前所述，串流可以像 Futures 一樣產生錯誤。透過將 onError 函數加入到 listen() 呼叫中，您可以捕獲和處理任何錯誤。

還有一個 cancelOnError 屬性，預設情況下為 true，但可以設定為 false，以便即使在發生錯誤後也能保持訂閱繼續進行。

您可以新增 onDone 函數，以便在串流完成傳送資料時執行一些程式碼，例如檔案已完全讀取完畢時。

結合所有四個參數——onError、onDone、cancelOnError 和必需的參數 (onData)——您可以預先準備好應對任何情況。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

final myStream = NumberCreator().stream;

final subscription = myStream.listen(
  (data) {
    print('Data: $data');
  },
  onError: (err) {
    print('Error!');
  },
  cancelOnError: false,
  onDone: () {
    print('Done!');
  },
);

提示： listen() 返回的物件本身有一些有用的方法。它被稱為 StreamSubscription，您可以使用它來暫停、繼續，甚至取消資料流。

1
2
3
4
5

final subscription = myStream.listen(...);

subscription.pause();
subscription.resume();
subscription.cancel();

使用和操作串流

現在您已經知道如何使用 listen() 訂閱串流並接收資料事件，讓我們來談談讓串流真正酷炫的地方：操作它們。

一旦您在串流中獲得了資料，許多操作就會突然變得流暢而優雅。

讓我們回到之前的數字串流。

使用名為 map() 的方法，您可以從串流中獲取每個值，並動態地將其轉換為其他內容。給 map() 一個執行轉換的函數，它會返回一個新的串流，其類型與函數的返回值相符。

現在不再是整數串流，而是一個字串串流。在末尾呼叫一個 listen()，將 print() 函數傳遞給它，現在它會直接從串流中列印字串——非同步地，當它們到達時。

1
2
3

NumberCreator().stream
    .map((i) => 'String $i')
    .listen(print);

1
2
3
4
5

String 1
String 2
String 3
String 4
*/

您可以像這樣連結許多方法。例如，如果您只想列印偶數，則可以使用 where() 過濾串流。給它一個測試函數，該函數為每個元素返回一個布林值，它會返回一個新的串流，該串流只包含通過測試的值。

1
2
3
4

NumberCreator().stream
    .where((i) => i % 2 == 0)
    .map((i) => 'String $i')
    .listen(print);

1
2
3
4

String 2
String 4
String 6
String 8

distinct() 方法是另一個好方法。對於使用 Redux store 的應用程式，該 store 會在 onChange 串流中發出新的應用程式狀態物件。

您可以使用 map() 將狀態物件串流轉換為應用程式一部分的視圖模型串流。然後，您可以使用 distinct() 方法獲取一個串流，該串流會過濾掉連續的相同值（以防 store 啟動一個不影響視圖模型中資料子集的更改）。

然後，您可以監聽並在獲得新的視圖模型時更新 UI。

1
2
3
4

myReduxStore.onChange
    .map((s) => MyViewModel(s))
    .distinct()
    .listen( /* update UI */ )

Dart 內建了其他方法，您可以使用它們來調整和修改您的串流。此外，當您準備好使用更進階的功能時，還有 Dart 團隊維護的 async 套件，可在 pub.dev 上獲得。它包含可以合併兩個串流、快取結果以及執行其他基於串流的魔術的類別。

若要獲得更多串流魔術，請查看 stream_transform 套件。

建立串流

最後，還有一個值得一提的更進階的主題是如何建立您自己的串流。

就像 Futures 一樣，大多數情況下，您將使用網路函式庫、檔案函式庫、狀態管理等為您建立的串流，但您可以使用 StreamController 建立自己的串流。

讓我們回到我們一直使用的 NumberCreator 範例。這是它的實際程式碼：

1
2
3
4
5
6
7
8
9
10
11
12

class NumberCreator {
  NumberCreator() {
    Timer.periodic(const Duration(seconds: 1), (timer) {
      _controller.sink.add(_count);
      _count += 1;
    });
  }

  final _controller = StreamController<int>();
  var _count = 0;
  Stream<int> get stream => _controller.stream;
}

如您所見，它會持續計數，並使用計時器每秒增加一次計數。然而，有趣的是串流控制器。

StreamController 從頭開始建立一個全新的串流，並讓您可以存取它的兩端。有串流端本身，資料到達的地方。（我們在本文中一直在使用這個。）

1

Stream<int> get stream => _controller.stream;

還有接收端，這是將新資料加入到串流的地方：

1

_controller.sink.add(_count);

NumberCreator 使用了這兩個。當計時器關閉時，它會將最新的計數加入到控制器的接收端，然後它會使用公共屬性公開控制器的串流，以便其他物件可以訂閱它。

使用串流構建 Flutter Widget

現在我們已經介紹了建立、操作和監聽串流，讓我們來談談如何在 Flutter 中使用它們來構建 Widget。

如果您閱讀了先前關於 Futures 的文章，您可能記得 FutureBuilder。您給它一個 Future 和一個構建器方法，它會根據 Future 的狀態構建 Widget。

對於串流，有一個類似的 Widget 稱為 StreamBuilder。給它一個像 number creator 那樣的串流和一個構建器方法，它會在每次串流發出新值時重建其子 Widget。

1
2
3
4
5
6
7

StreamBuilder<String>(
  stream: NumberCreator().stream.map((i) => 'String $i'),
  builder: (context, snapshot) {
    // 構建一些 Widget
    throw UnimplementedError("Case not handled yet");
  },
);

snapshot 參數是一個 AsyncSnapshot，就像 FutureBuilder 一樣。

1
2
3
4
5
6
7
8
9

StreamBuilder<String>(
  stream: NumberCreator().stream.map((i) => 'String $i'),
  builder: (context, snapshot) {
    if (snapshot.connectionState == ConnectionState.waiting) {
      return const Text('No data yet.');
    }
    throw UnimplementedError("Case not handled yet");
  },
);

您可以檢查其 connectionState 屬性以查看串流是否尚未傳送任何資料，或者它是否已完全完成。

1
2
3
4
5
6
7
8
9
10
11

StreamBuilder<String>(
  stream: NumberCreator().stream.map((i) => 'String $i'),
  builder: (context, snapshot) {
    if (snapshot.connectionState == ConnectionState.waiting) {
      return const Text('No data yet.');
    } else if (snapshot.connectionState == ConnectionState.done){
      return const Text('Done!');
    }
    throw UnimplementedError("Case not handled yet");
  },
);

您可以使用 hasError 屬性來處理資料值，並查看最新值是否為錯誤。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

StreamBuilder<String>(
  stream: NumberCreator().stream.map((i) => 'String $i'),
  builder: (context, snapshot) {
    if (snapshot.connectionState == ConnectionState.waiting) {
      return const Text('No data yet.');
    } else if (snapshot.connectionState == ConnectionState.done) {
      return const Text('Done!');
    } else if (snapshot.hasError) {
      return const Text('Error!');
    } else {
      return Text(snapshot.data ?? '');
    }
  },
);

最重要的是要確保您的構建器知道如何處理串流的所有可能狀態。一旦您掌握了這一點，它就可以對串流的任何操作做出反應。（有關更多資訊，包括您可以使用的 DartPad 實例，請參閱 StreamBuilder API 頁面。）

總結

本文涵蓋了串流的含義、如何從串流中獲取值、操作這些值的方法，以及 StreamBuilder 如何幫助您在 Flutter 應用程式中使用串流值。

您可以從 Dart 和 Flutter 文件中了解更多關於串流的資訊：

• 在 dart.dev 上，請參閱串流教學、命令列應用程式教學 以及函式庫導覽的 串流部分。
• 在 flutter.dev 上，請參閱 使用 WebSockets，其中包含一個使用 StreamBuilder 的範例。

敬請期待本系列的更多文章。接下來我們將討論 async 和 await。這是 Dart 提供的兩個關鍵字，可幫助您保持非同步程式碼的簡潔性和可讀性。

同時，您可以在我們的 YouTube 頻道上觀看關於《Dart 中的非同步程式設計》的下一部影片系列，或者訪問我們的網站以獲取更多關於 Dart 和 Flutter 的資訊。

Dart 非同步程式設計：串流 最初發佈於 Medium 上的 Dart，人們在那裡透過醒目顯示和回應這個故事來繼續對話。

【文章內容使用 Gemini 1.5 Pro 自動翻譯產生】

徵求 Google Summer of Code 2022 貢獻者

Google Summer of Code (GSoC) 是一個全球性的計畫，旨在讓學生開發者參與開源軟體開發。Google 贊助學生在夏季與一個指導性的開源組織合作進行一個 12 週以上的程式設計專案。在過去的 17 年裡，已有超過 18,000 名學生參與了 Google Summer of Code。

我們很高興地宣布，Dart 將在 2022 年的 Google Summer of Code 中擔任指導組織（這是第三次！）。查看成果文章，了解更多關於 2020 年和 2021 年的優秀專案。

您有興趣嗎？

現在就開始閱讀 專案構想列表，找到符合您的技能和興趣的專案。正式申請必須在 4 月 19 日之前提交，但鼓勵潛在申請者提交早期草稿並徵求回饋。

Dart 團隊預計會有足夠的導師，但只會接受少數申請，因此也請查看 其他指導組織。

如果您有關於 Dart 和 GSoC 的具體問題，請在我們 專用的郵件列表 中提問。

有關 Google Summer of Code 的更多資訊，請觀看下面的影片。或者閱讀 Google Summer of Code 貢獻者指南。

我們期待您的參與！

Google Summer of Code 2022 貢獻者 最初發佈於 Medium 的 Dart，人們在那裡透過醒目顯示和回應這個故事來繼續討論。

【文章內容使用 Gemini 1.5 Pro 自動翻譯產生】

大型 Dart 專案的漸進式空安全遷移

對於一個簡單的小套件來說，Dart 空安全遷移 需要 1-2 個小時的工作量，但對於一個大型專案來說，這可能是一場長達數月的馬拉松。理想情況下，您希望逐步遷移您的專案——在馬拉松期間，您希望保持您的專案可擴展、可維護且易於發佈。

我已經將一個大型專案遷移到空安全，並決定整理一些步驟和技巧，以說明如何使遷移過程可靠且高效，希望它能節省您的時間。

步驟 1：轉換為非健全的空安全

首先，將您的專案遷移到非健全的空安全。

首先將您的依賴項升級到空安全版本。非健全的空安全並不要求所有依賴項都是空安全的。但是，強烈建議等到所有上游依賴項都遷移完畢後再進行遷移，因為遷移依賴項可能會迫使您重新審視您自己程式碼中的遷移決策。對於相互依賴的套件，您可能被迫無序遷移，或者同時遷移這些套件（許多相互依賴的套件大多只在測試中相互引用）。請遵循 dart.dev 上的指南 在遷移程式碼之前盡可能升級更多依賴項。

接下來，更新套件的 Dart SDK，並使用以下步驟將每個未遷移的函式庫標記為 legacy：

1. 確保您的 IDE（VSCode、IntelliJ / Android Studio）已安裝 Dart 外掛。
2. 在 IDE 中打開您的套件，並確保沒有編譯錯誤。
3. 更新 pubspec.yaml 檔案中的 dart_sdk 依賴項，以要求版本範圍：>=2.12.0 <3.0.0。
4. IDE 將突出顯示尚未啟用空安全的函式庫中的空安全相關錯誤。透過在每個受影響檔案的頂部加入註釋 // @dart=2.9 來移除錯誤。即使您的 main.dart 檔案沒有錯誤，也要將註釋加入其中，以保持應用程式以非健全模式運行，直到您準備好切換為止。
5. 驗證所有測試是否通過，並將變更提交到您的主分支。如果您的測試已經是空安全的，您將需要命令列標誌 --no-sound-null-safety 來抑制空安全錯誤。

啟動應用程式時，請確保您在控制台中看到「以非健全的空安全模式運行」。

現在您已準備好一次遷移一個函式庫到健全的空安全。

步驟 2：迭代到健全的空安全

選擇一個或一組要遷移的函式庫。

專業提示：如果您選擇的函式庫很大，您可能希望在遷移之前將其分解成較小的函式庫。

使用 dart pub deps 建立專案的依賴圖。最好自下而上地遷移套件；從依賴樹中的葉子開始，然後向上迭代到根。但是，如果您的專案具有依賴循環，這可能是不可能的，而且不遵循此順序也沒關係。

使用 遷移工具 遷移函式庫（或一組函式庫）：

1. 透過執行 dart migrate --skip-import-check 啟動互動式遷移工具。您可能希望 cd 到包含所選函式庫的目錄，以便在樹中更容易導航。
2. 透過取消選取左側面板中檔案視圖樹的根來取消選取所有內容。（如有興趣，請投票支持新增 取消選取所有 按鈕。）
3. 使用 Control+F 找到您要遷移的檔案。
4. 選取檔案，然後點擊 應用遷移。您可以透過兩種方式進行調整：(1) 在應用遷移之前使用註釋來調整工具的選擇，或 (2) 在應用遷移之後使用 IDE 來評估欄位、參數和變數的可空性。
5. 在 IDE 中打開套件。修復錯誤，並在檔案中搜尋工具可能不準確的情況（請參見下面的潛在問題列表）。進行更正並使用 lint 警告以互動方式清理上游和下游程式碼。

您將無法修復兩個 lint 錯誤：

1. import_of_legacy_library_into_null_safe（在已遷移的函式庫中）
2. avoid_redundant_argument_values（在 legacy 函式庫中）

現在，使用註釋停用這些錯誤。您將在遷移完成後清理這些錯誤。

需要注意的潛在工具不準確性：

1. 加入的類型 dynamic 或 num。您很可能知道應該使用哪種特定類型來代替。
2. 在大多數情況下，bool? 可以透過預設值變為 bool。
3. 類型轉換（搜尋 as）可能意味著該工具沒有加入泛型類型參數。加入之後，lint 會指示轉換已變得不必要，可以移除。
4. 在某些情況下，該工具會使泛型參數上的界限可空，而最好將其設為不可空（搜尋 ?> 和 ?,）。
5. 該工具可能會使某些內容可空，而使用 late 或 late final 可以更好地表達，或者可以重構以允許在建構函式的初始化列表中進行初始化。（如有興趣，請投票支持新增 lint。）
6. 使用空斷言運算子 ! 而不先檢查空值可能意味著變數或參數實際上應該是非空的。（如有興趣，請投票支持新增 lint。）
7. 該工具以 collection as Iterable<TheType> 的形式為集合加入轉換。有時，此變更只是使已經隱式的轉換變得明確。但是，在其他情況下，由於泛型引數的可空性不匹配，這些轉換可能會引入 執行時錯誤。如有疑問，請考慮將轉換替換為每個元素的顯式轉換（例如，collection.cast<TheType>()），或考慮使用 package:collection 中的 whereNotNull 擴展方法。
8. 如果變數、欄位或參數是可空的，但可空性僅在測試中使用，則可能應該重構程式碼以移除該標識符的可空性。

（感謝 Kenzie Davisson 幫助我識別出這些情況。）

步驟 3：清理

遷移所有函式庫後，請執行一些最終清理：

1. 清理禁用 lint 的註釋。
2. 將剩餘的依賴項升級到空安全版本。
3. 確保您的應用程式中沒有剩餘的 //@dart = 2.9 註釋。此時，啟動應用程式時，您應該在控制台中看到「以健全的空安全模式運行」。如果您沒有看到此訊息，則可能是您的函式庫尚未遷移（搜尋 // @dart = 2.9），或者依賴項尚未遷移。
4. 確保應用程式仍然可以正常運行，並且測試通過。由於健全模式啟用了更強的執行時保證，因此當您啟用健全空安全時，您可能會看到新的執行時錯誤，您需要修復這些錯誤（儘管不太可能）。通常這是將可空集合（例如 List<int?>）轉換為不可空集合類型（例如 List<int>）的結果。

祝您遷移順利！

大型 Dart 專案的漸進式空安全遷移 最初發佈在 Dart 上的 Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。

【文章內容使用 Gemini 1.5 Pro 自動翻譯產生】

託管私有的 Dart 套件庫

我們最近發布的 Dart 2.15 版本增加了對私有套件庫的支援。套件庫是一個託管 Dart 套件的伺服器，供 dart pub 客戶端使用。這篇文章討論了如何將私有套件庫與 pub.dev 一起使用，並利用 Dart 2.15 中引入的新的權杖驗證機制。

此功能已被 Cloudsmith 和 JFrog Artifactory 採用，它們提供自定義套件庫作為服務：

為什麼要使用自定義套件庫？

預設套件庫 pub.dev 由 Dart 團隊運營。它促進了 Dart 套件的發布以供公開使用，並允許任何 Dart 開發人員只需將套件的名稱添加到他們的 pubspec 檔案中即可使用這些套件。這使得活躍的生態系統可以建立豐富的 Dart 套件集合。但是，在以下情況下，自定義套件庫可能很有用：

1. 在組織內共享私有套件。這可能是一個希望在其成員之間共享內部專有套件，而不是與公眾共享的組織。
2. 在企業環境中嚴格控制依賴項。一些公司希望明確地為批准使用的特定 套件版本 建立允許清單。這可能是為了執行程式碼審查策略或許可證合規性。
3. 沒有公共網際網路存取的 sécurisé 環境。一些組織在一個監管環境中運作，在該環境中不允許連接到公共網際網路，進而也不允許連接到 pub.dev。這通常適用於政府機構/承包商和一些銀行服務提供商。

只需要共享一些專有套件的組織（情況 1）可能會使用 git 依賴項。這是一個強大的機制，因為 dart pub 客戶端命令會調用 git 客戶端來複製 git 依賴項——透過這種方式，您可以使用 SSH 金鑰驗證複製依賴項，並使用 GitHub/GitLab 團隊管理權限。由於 GitHub 支援使用 Yubikey 的 SSH，此設定在某些情況下效果很好。

但是，在版本解決方面，dart pub 中的 git 依賴項有一些限制。當使用 git 依賴項時，dart pub 只會複製 pubspec.yaml 中指定的標籤/分支/引用，因為沒有嘗試多個版本依賴項的機制。因此，使用私有自定義套件庫可能很有吸引力，因為自定義套件庫可以向 dart pub 客戶端提供版本清單，允許 版本解決器 選擇相容的版本並避免衝突。它還可以輕鬆地使用 dart pub outdated 和 dart pub upgrade --major-versions 升級私有和公共依賴項。

Git 依賴項不支援尋求 更嚴格的依賴項控制（情況 2）或使用 沒有網際網路存取的 sécurisé 環境（情況 3）的組織，因為許多套件必須鏡像。在這些情況下，幾乎總是最好只有一個自定義套件庫鏡像 pub.dev 的允許清單子集。

使用自定義套件庫

從 Dart 2.15 開始，您可以使用 簡短形式的託管依賴項 語法依賴於來自自定義套件庫的套件：

1
2
3
4
5
6

dependencies:
  foo:
    hosted: https://dart-packages.example.com
    version: ^1.4.0
environment: 
  sdk: >=2.15.0 <3.0.0

簡短形式的語法需要 SDK 約束 >=2.15.0，因為舊版本的 Dart SDK 不支援此語法。如果您不想擔心語法，也可以只使用 dart pub add 命令從自定義套件庫中添加依賴項：

1
2
3
4

$ dart pub add foo --hosted https://dart-packages.example.com
Resolving dependencies... 
+ foo 1.4.0
Changed 1 dependency!

使用託管依賴項語法，可以將來自自定義套件庫的依賴項與來自官方套件庫的依賴項混合使用。以下範例依賴於來自 dart-packages.example.com 儲存庫的套件 foo 和來自 pub.dev 的套件 retry：

1
2
3
4
5
6
7

dependencies:
  retry: ^3.0.0
  foo:
    hosted: https://dart-packages.example.com
    version: ^1.4.0
environment: 
  sdk: >=2.15.0 <3.0.0

當使用自定義套件庫共享私有套件時（情況 1），這很有用。但是對於 更嚴格的依賴項控制（情況 2）或在 沒有網際網路存取的 sécurisé 環境（情況 3）中工作，最好覆蓋預設套件庫。

覆蓋預設套件庫

預設情況下，dart pub get 會從 pub.dev 獲取依賴項，除非使用託管依賴項語法指定自定義套件庫。但是，可以使用環境變數 PUB_HOSTED_URL 覆蓋 預設套件庫。當鏡像 pub.dev 的子集時（情況 2 或 3），此方法特別有用，因為無需更新 pubspec.yaml 檔案以引用自定義套件庫 URL。例如，只需編寫以下內容即可：

1
2
3

dependencies:
  retry: ^3.0.0
  foo: ^1.0.0

如果套件 retry 和 foo 的允許清單版本被複製到自定義套件庫，並且環境變數 PUB_HOSTED_URL 指向自定義套件庫 URL，則 pub get 可以按如下方式工作：

1
2
3
4
5
6

$ export PUB_HOSTED_URL=https://dart-packages.example.com
$ dart pub get
Resolving dependencies... 
+ retry 3.1.0
+ foo 1.4.0
Changed 2 dependencies!

當建置伺服器位於公司防火牆後面，並且不允許外部網路連線以避免當有人忘記設定 PUB_HOSTED_URL 時的意外注入攻擊時，這種方法效果最佳。同樣，建議在 pubspec.yaml 中設定 publish_to: <hosted-url>，以避免意外發布到 pub.dev（當未定義 PUB_HOSTED_URL 時）。

針對自定義套件庫進行驗證

大多數自定義套件庫可能是需要驗證的私有套件庫。Dart 2.15 引入了 dart pub token 命令來管理驗證權杖。對自定義套件庫的請求使用秘密權杖進行驗證。您可以從自定義套件庫獲取秘密權杖，並將其傳遞給 dart pub token add <hosted-url>，它會提示輸入權杖，如下所示：

1
2
3

$ dart pub token add https://dart-packages.example.com
Enter secret token: [輸入秘密權杖]
Requests to "dart-packages.example.com" will now be authenticated using the secret token.

從 CI 環境進行驗證

在 CI 中運行時，通常可以將 秘密儲存在環境變數中，雖然可以使用 echo $TOKEN | dart pub token add <hosted-url> 傳遞秘密，但也可以告訴 dart pub 在與特定自定義儲存庫通信時從環境變數中讀取秘密：

1
2

$ dart pub token add https://dart-packages.example.com --env-var MY_SECRET_TOKEN
Requests to "https://dart-packages.example.com" will now be authenticated using the secret token stored in the environment variable "MY_SECRET_TOKEN".

這可確保 dart pub 不會實際將秘密儲存在其設定檔中，而只是儲存它應該從環境變數 $MY_SECRET_TOKEN 中讀取秘密的事實。這允許在 CI 環境中操作時僅將秘密儲存在環境變數中，並降低了如果執行環境在 CI 作業之間共享時秘密意外洩露的風險。

發布到自定義套件庫

要將套件發布到自定義套件庫，您需要在 pubspec.yaml 中指定 publish_to: <hosted-url>，然後運行 dart pub publish。這使用與 dart pub get 使用的相同的權杖進行驗證。至少，您的 pubspec.yaml 檔案應如下所示：

1
2
3
4
5
6
7

name: mypkg
version: 1.0.0
publish_to: https://dart-packages.example.com
dependencies:
  meta: ^1.7.0
environment:
  sdk: >=2.15.0 <3.0.0

運行 dart pub publish 時，務必查看提供的資訊。在確認發布操作之前，您應始終執行以下操作：

• 檢查套件將發布到的 URL。
• 查看要包含在套件中的檔案清單。
• 考慮套件驗證建議。例如：

1
2
3
4
5
6
7
8
9
10
11

$ dart pub publish
Publishing mypkg 1.0.0 to https://dart-packages.example.com
|-- CHANGELOG.md
|-- LICENSE
|-- README.md
|-- lib
|   '-- mypkg.dart
'-- pubspec.yaml
Package validation found the following potential issue:
* It's strongly recommended to include a "homepage" or "repository" field in your pubspec.yaml
...

對於發布到自定義儲存庫，建議 可能不 重要，但提供套件的元資料通常很有用。在 pub.dev 上，具有正確元資料和文件的套件得分更高 pub 分數。

可以透過使用環境變數 PUB_HOSTED_URL 覆蓋 預設套件庫 來發布到自定義儲存庫，但是，如果您這樣做，強烈建議您在 pubspec.yaml 檔案中指定 publish_to: <hosted-url>；這可以防止您意外地將專有套件發布到公共儲存庫。如果您不想將專有套件發布到 任何 套件儲存庫，請指定 publish_to: none 以防止意外發布。

取得自定義套件庫

如前所述，自定義套件庫可作為多個商業供應商提供的服務，從而減輕您託管和維護自己的自定義套件庫的負擔。

Cloudsmith 中的權杖驗證

自 2020 年以來，Cloudsmith 一直提供私有和公共 Dart 套件庫。Cloudsmith 最近宣布 支援其 Dart 套件庫產品的權杖驗證。有關更多資訊，請查看 Cloudsmith 文件。

JFrog Artifactory 中的 Dart 支援

JFrog Artifactory 最近 宣布支援自定義 Dart 套件庫，包括支援分層儲存庫和從 pub.dev 上的公共套件庫鏡像套件。有關更多資訊，請查看 JFrog Artifactory 文件。

結語

對於那些想要編寫自己的自定義套件庫的人，我們發布了一個關於 提供 Dart 套件庫的規範。它相當簡單，但如果您不清楚某些方面，或者您有任何改進建議，請隨時在 pub.dev 儲存庫 上提交問題。

託管私有 Dart 套件庫 最初發佈在 Medium 的 Dart 上，人們在那裡透過突出顯示和回應這個故事來繼續討論。

【文章內容使用 Gemini 1.5 Pro 自動產生】

在提交截止日期之前完成你的專案！

距離 Flutter Puzzle Hack 提交截止日期只剩下幾天了。我們對到目前為止看到的拼圖感到興奮，並且迫不及待地想看到更多！別忘了，獎品包括 4 台配備齊全的 MacBook、大量 Flutter 周邊商品以及超過 40 位獲獎者的現金，因此請務必提交您的作品，以爭取獲得這些很棒的獎品。

歡迎來到 Flutter 社群

隨著最終提交日期的迅速臨近，我們想藉此機會歡迎許多新開發人員加入 Flutter 社群。我們迫不及待地想看看你們會做出什麼，當然，從你們的 Flutter Puzzle Hack 提交開始！

宣布我們的評審

為了慶祝 Flutter Puzzle Hack 的最後一周，我們很高興能宣布我們的評審，包括許多自 Flutter 成立以來就一直幫助構建此框架的 Flutter 老將。提交拼圖 Hack 作品是一個絕佳的機會，可以讓您在世界上頂尖的 Flutter 專家評審您的作品。

• Justin McCandless，Flutter 框架軟體工程師
• Casey Hillers，Flutter 工程軟體工程師
• Christian Padilla，Flutter 外掛軟體工程師
• Devon Carew，Flutter 軟體工程師
• Greg Spencer，Flutter 框架/桌面軟體工程師
• Michael Goderbauer，Flutter 框架首席軟體工程師
• Craig Labenz，Flutter 開發者關係工程師
• Yusuf Mohsinally，Flutter 工程軟體工程師
• Laura Willis，Flutter 和 Firebase 產品行銷主管
• Jay Chang，Flutter 產品行銷經理
• Kelvin Boateng，Flutter 產品行銷經理
• Huan Lin，Flutter on iOS 軟體工程師
• Eric Windmill，Firebase 和 Flutter 開發者關係工程師

告訴我們您何時提交

無論您還在構思您的想法，還是已經提交了您的應用程式，請在 Twitter 上使用標籤 #FlutterPuzzleHack 標記我們，我們一定會與 Flutter 社群分享您的作品。

例如，看看 Twitter 使用者 Roaa 正在為 這個 作品做些什麼：

仍然有時間！

如果您還在考慮開始提交，現在還不晚。查看 樣板應用程式，部落格文章 解釋了應用程式的工作原理，然後前往 flutterhack.devpost.com 查看挑戰規則。

距離 Flutter Puzzle Hack 提交截止日期只剩下幾天了 + 宣布評審 最初發佈在 Flutter 上的 Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。

http://creativecommons.org/licenses/by/4.0/

【文章內容使用 Gemini 1.5 Pro 自動翻譯產生】

快速修復分析問題

如果您像我一樣，太多的開發時間都花在修復分析器找到的問題（診斷）上。如果您曾經希望它可以更容易，那麼我有一些好消息要告訴您。分析器產生的許多診斷都可以使用快速修復自動修復。

快速修復 是一種自動編輯，旨在修復特定診斷報告的問題。在 Dart 診斷訊息 文章中，我們查看了以下程式碼：

更正訊息建議了兩種解決問題的方法：「嘗試使存取成為條件式（使用 ‘?.’）或向目標添加 null 檢查（’!’）。」

如果您點擊突出顯示的區域（帶有紅色波浪線的區域），您會在編輯器左側看到一個燈泡圖示。如果您將滑鼠懸停在它上面，則可以點擊以打開包含可用快速修復的選單。

選單中提供了兩種建議的更正。選擇其中一個會將更改應用於您的程式碼。例如，如果您選擇第一個修復，它會將程式碼更新為以下內容：

讓我們先快速了解一下如何在 IntelliJ IDEA 和 Visual Studio Code 中應用修復，然後再看一個更強大的快速修復示例。

IntelliJ IDEA

編輯器中的上下文動作選單如下所示：

您可以透過從編輯器中的上下文選單中選擇「顯示上下文動作」或使用其鍵盤等效項（Windows 和 Linux 上為 Alt+Enter，macOS 上為 Option+Enter）來存取相同的列表。

當您將滑鼠懸停在突出顯示的區域上時，您也可以直接從懸停文字中調用這些修復。如果修復太多，則還有一個 更多動作 項目也會打開選單：

如果這還不夠，您還可以從 Dart 分析視圖中的上下文選單中調用可用的修復：

Visual Studio Code

編輯器中的程式碼動作選單如下所示：

前兩項是快速修復，其他項是重構。您可以透過使用其鍵盤等效項（Windows 和 Linux 上為 **Control+.**，MacOS 上為 **Command+.**）或從編輯器中的懸停文字中選擇 快速修復… 來存取相同的列表：

您也可以從「問題」面板中的上下文選單中調用它們：

另一個例子

雖然上面的修復可以節省您查找更正訊息然後手動進行編輯的時間和精力，但不可否認，添加單個字元並不是一個很大的時間節約。但是，某些修復可以提高生產力。請考慮以下程式碼：

診斷告訴您「await 表達式只能在異步函數中使用。」假設您不想使用同步 I/O，則更正方法是用 async 關鍵字標記函數的主體。這樣做會導致另一個錯誤，告訴您方法的返回類型需要是 Future，因此您最終還需要更新返回類型。

幸運的是，有一個針對原始問題的快速修復：

選擇此修復不僅會添加修飾符，還會更新返回類型，讓您一步即可解決問題：

總結

並非每個問題都可以自動修復，並且並非每個可以修復的問題都有快速修復。儘管如此，下次您需要修復診斷時，絕對值得檢查一下是否有可用的快速修復。如果您沒有看到應該有快速修復的診斷的修復，請透過 建立 dart-lang/sdk 問題 告知我們。

分析問題的快速修復 最初發佈在 Dart 上的 Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。

【文章內容使用 Gemini 1.5 Pro 自動產生】

2021 年第四季使用者調查結果：關於空安全、生態系統、文字編輯和行動開發

去年 11 月，Flutter UX 團隊進行了第 15 次季度使用者調查。調查透過 Flutter 的 IDE 外掛、YouTube、Twitter 和網站宣布。在兩個星期內，我們收集了 10,105 份回覆，創下歷史新高，我們了解到 Flutter 開發人員對 Flutter 仍然感到滿意。對 Flutter 感到滿意的人的比例為 92%，自 2019 年第四季以來一直保持穩定。

透過調查，Flutter 團隊也更詳細地了解 Flutter 的優缺點，並據此設定未來任務的優先順序。在這次調查中，我們詢問了以下四個主題，以深入了解這些領域。

• 空安全
• 生態系統
• 文字編輯
• 行動開發

為了讓調查簡短，我們向不同的群組詢問了不同的問題，因此您可能沒有看到所有這四個主題。無論如何，我們從所有參與者那裡收到了有意義的、具有統計意義的回饋。作為一個開源專案，我們試圖盡可能透明地公開我們收集的數據，因此我們在此分享結果和我們的收穫。

Dart 空安全

Dart 空安全的穩定版本於 2021 年 3 月 發佈。這是該語言中最大的新增功能之一，我們提供了一個遷移工具和一個 指南 來幫助開發人員將現有程式碼遷移到空安全。我們想了解遷移的體驗對您來說如何，這樣我們就可以在未來嘗試進行類似語言變更時做得更好。

總體而言，過去 6 個月使用過 Dart 空安全的 89.5% 的人對此功能感到滿意。那些先前有空安全經驗的人（例如 Kotlin）更有可能對此功能感到滿意（+3 個百分點）。Dart 空安全最大的好處是「程式碼中的錯誤減少了」（79.4%），其次是「更容易理解的程式碼」（49.7%）。

有趣的是，39.9% 的人表示他們的所有程式碼都從一開始就使用空安全。鑑於調查是在穩定版空安全推出後僅 8 個月實施的，因此調查顯示了 Flutter 和 Dart 的快速發展，吸引了新的開發人員。這個結果也顯示了，59% 遷移程式碼的人以某種方式使用了遷移工具（22.0%+19.6%+6.7%=22.0%）。

總體而言，調查結果支持繼續發展 Dart 語言使其變得更好。我們將繼續改進並在過程中考慮您的體驗。請繼續提供您的回饋！

生態系統

隨著 Flutter 不斷成熟，其套件和外掛生態系統也得到了改善。這項改善包括來自社群的貢獻，以及 Flutter Favorites、Plus 外掛 和 Weekly Package 等程式和促銷活動。如下所示，對生態系統的滿意度在過去 2 年中提高了 7 個百分點。

然而，我們仍然聽到您說，仍然有許多套件和外掛需要改進。為了更好地了解您的需求，我們詢問了「過去 3 個月是否有任何 Flutter 或 Dart 套件降低了您的應用程式開發生產力？」當 3,698 人中有 28.7% 對此問題回答「是」時，我們列出了 42 種不同的套件類型，並詢問了哪些套件降低了生產力。排名前 15 的套件如下。

Firebase 被 Flutter 使用者廣泛使用，這導致了相對較多的投票（22.1%）。我們將繼續投入到 Firebase 外掛（「FlutterFire」外掛）中。例如，去年 12 月，我們 發佈了 FlutterFire 外掛的穩定版本 並對其進行了標準化。這意味著所有 FlutterFire 外掛現在都使用相同底層版本的 SDK，開發人員在混合和匹配外掛時不會遇到版本不兼容問題。我們計劃監控此情況，並希望在下次詢問這個問題時看到 Firebase 變成開發人員更有效的服務。

上面圖表中另一個值得注意的是，42 個常見項目無法涵蓋所有需求，而 19.2% 的人選擇指定降低生產力的「其他」類型的套件和外掛。這突出了我們只是一個社群才能解決的各種需求。

對於這些套件，最大的挑戰是功能完整性——23.1% 的人表示套件的功能不完整，因此他們必須使用多個套件才能實現類似功能，或者無法滿足他們的需求。

Flutter 團隊一直在努力改進我們第一方外掛的開發過程，使其更容易維護和改進。例如，webview_flutter 3.0 最近發佈，以解決許多頂級功能需求，我們將繼續投資於解決該外掛和其他外掛中投票數最高的議題。

即使我們自己繼續投入到 Flutter 和 Dart 團隊擁有的 數百個套件 中 ， 這些都是 Flutter 社群可以發揮關鍵作用的領域。當我們都投入套件開發時，我們都會受益！

文字編輯

Flutter 提供了內建的 Widget，例如 TextField、TextFormField（以及它們的 Cupertino 對應物），以及各種套件，讓您可以在應用程式中加入文字編輯功能。當需要實作 live 篩選和格式化（例如，僅數字的電話號碼或價格輸入欄位）或豐富的文字編輯器（例如程式碼或數學公式編輯器）時，這會很快變得複雜。

從這次調查中，我們了解到大約 86.7% 的中級或高級經驗開發人員嘗試在他們的應用程式中加入文字編輯功能，而且對文字編輯功能的滿意度從單行 (82.3%) 和 live 篩選和格式化 (82.2%) 下降到多行 (69.6%) 和豐富文字編輯器 (66.6%)。

根據這個回饋，核心框架團隊計劃建立穩固的基本豐富文字編輯功能和 API 來支援套件。此外，團隊計劃更好地宣傳現有功能並建立更多範例。同時，您可以探索關於文字編輯變更的 設計文件 以查找有用的文件，以及 這個 GitHub 議題，以了解進度。這項工作已經進行得很好，一些低階 API 現在已經在 master channel 中。

我們也聽說了與支援不同語言相關的挑戰。例如，我們清楚地聽到 RTL 和雙向文字（例如阿拉伯語）無法正常運作。雖然沒有書面路線圖，但我們計劃很快大力推動更好地支援 RTL 和雙向文字編輯。

行動開發

由於行動平台（iOS 和 Android）是 Flutter 最初正式支援的平台，因此大多數人都有在過去 6 個月內開發 iOS 或 Android 應用程式的經驗。團隊想更好地了解特定於平台的問題，例如與除錯和發佈相關的挑戰，以便團隊能夠更好地為其工程工作設定優先順序。

在除錯方面，在兩個平台上，使用者在加入或升級套件或外掛時，經常需要處理特定於平台的問題。雖然在許多情況下除錯 Android 問題並不常見，但值得注意的是，在 Android 上除錯以優化效能比 iOS 更常見。

我們還了解到，在發佈應用程式時，處理 Xcode（iOS）和 Gradle（Android）是最常見的問題，這與我們的直覺一致。我們已經讓 Flutter CLI 顯示針對常見 Gradle 錯誤的使用者友善錯誤訊息，這個功能已在最新更新 Flutter 2.10 中發佈。

我們將繼續改進這些構建系統錯誤的呈現方式，使其更容易理解和操作。對於 iOS，我們將在未來的版本 (相關議題在此) 中加入 flutter build ipa 功能，使發佈變得更容易。更多 Xcode 設定也會自動填充到新專案 (議題) 中。對於 Android，我們正在開發一個自動遷移工具，它將有助於查找 Gradle 配置檔案中的細微差異。

接下來是什麼？

開發人員越來越多地將 Flutter 作為他們主要工作的一部分使用。Flutter 團隊將繼續聆聽並使用您的回饋來塑造我們的技術。如果您有任何緊急問題，請在 GitHub 上提交議題。

Flutter 季度使用者調查將繼續尋找重要問題的答案。您也可以在 GitHub 上發佈您的研究想法。請留意下一次調查。此外，請考慮透過 註冊參加未來的 UX 研究 來參與其他研究。

再次感謝所有提供回饋的人！

2021 年第四季使用者調查結果：關於空安全、生態系統、文字編輯和行動開發 最初發佈在 Flutter 上的 Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。

【文章內容使用 Gemini 1.5 Pro 自動產生】

Flutter 在 2022 年的策略和路線圖

Flutter 在我們建立成長和動能的過程中所關注的領域

每年，我們和其他 Google 的大型團隊一樣，都會進行規劃過程，以設定我們在未來一年的目標和重點領域。通常，產品團隊會嚴格保護這些文件，因為它們可能包含商業敏感資訊，或與競爭優勢領域相關。然而，作為一個開源專案，我們認為透明度是一種美德：它可以讓人們更信賴我們的未來和方向，並讓其他人更清楚地了解他們的投資如何與我們的投資相連。

因此，今天我們首次與整個社群分享我們的 年度策略文件。在這個文件中，我們表達了我們的使命，分享了一些指導原則，並描述了我們計劃在未來一年進行的主要投資。出於必要，我們做了一些小幅度修改（例如，商業敏感資料或對未宣布產品的參考），但我們相信這提供了對我們計劃良好的概述。這個策略文件應該與我們 wiki 上的 工程路線圖 一起閱讀，後者提供了有關我們正在開發的功能的更多細節。

關於以上句子中使用「我們」這個詞的一個重要說明，這可能被理解為「那些 Google 付錢讓他們在 Flutter 上工作的人」。Flutter 是 Google 內外許多貢獻者的成果。雖然 Google 是最大的贊助商，以付費貢獻者的數量衡量，但它不是唯一的貢獻者。在過去的一年裡，數千名個人為該專案貢獻了他們的智慧財產和勞動力，從個人到 Canonical、Microsoft、ByteDance 和阿里巴巴等大型企業。

因此，雖然策略文件描述了 Google 的投資並分享了這些決策背後的理由，但它並不打算限制他人對 Flutter 的貢獻方式。我們希望我們的作品能夠很好地滿足整個社群的需求，但我們預計分享這個文件的一個好處是，其他人將看到他們自己的投資機會，無論是建立在 Google 計劃貢獻的作品之上，還是填補我們沒有優先考慮的領域。

這方面的例子包括 Sony 在 嵌入式 Linux 上的工作；Toyota 和其他汽車公司在 汽車級 Linux 中使用 Flutter 的投資，以及三星和其他公司將 Flutter 移植到 Tizen 的工作。雖然這些工作都沒有列在我們的策略文件中，但它仍然是 Flutter 專案的一部分，就像 Google 貢獻的任何程式碼一樣。當然，還有數萬個建立在框架之上的套件，其中絕大多數來自 Google 之外的開發人員。

最後一個免責聲明：我們的策略可能會隨著時間推移而演變，因為我們將繼續與社群互動，以及商業優先順序和策略的變化。因此，這裡所述的任何內容都不要被視為具有約束力的承諾，即使我們計劃將其作為我們的指南。

Flutter 在 2022 年：策略和路線圖 最初發佈在 Flutter 上的 Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。

http://creativecommons.org/licenses/by/4.0/