A one-stop workbench for Flutter

I. はじめに

Flutter のワンコード・マルチターミナルという特徴により、端末側開発者の人的リソースが解放され、開発効率の向上がもたらされます。初期段階におけるデュアルターミナルの開発人員数と開発効率向上の需要のミスマッチを背景に、Tao Te 技術チームは Alibaba Group の中でもいち早く Flutter をビジネスに導入したチームの一つです。

ワンコード・マルチターミナルの利便性がある一方で、開発環境の構築、デュアルターミナルのエンジニアリング環境、煩雑な統合リリースフローなど、開発プロセスにおいてさまざまな問題が生じています。開発者の痛みを深く理解するため、チーム内でアンケート調査を実施しました。

開発幸福度指数と開発プロセスで直面するさまざまな問題について調査を行った結果は以下の通りです。

開発幸福度指数の平均スコアは 3.38（5 段階評価）でした。開発幸福度に影響する問題を分析した結果、一般的に開発効率に影響すると考えられる問題が特定されました。中でも最も順位が高いのは、開発環境 + エンジニアリング環境（Flutter 関連）の構築、開発およびデバッグ（Flutter 関連）などの問題です。

次に、これらの問題の具体的な痛みと、これらの問題を解決する際に直面した課題を見ていきます。

2 問題と課題

問題 1
開発幸福度に影響する問題の中で、以下の 3 つの側面がより顕著です。

1）開発環境の問題

開発環境の設定はコーディング前の作業であり、新人がチームの開発体験に対して抱く第一印象にも影響します。Flutter は Android と iOS の両方の環境設定を含むため、もう一方の端末に不慣れな開発者にとっては非常に手間がかかり、参入障壁が高くなっています。さらに、ローカルの Flutter バージョンの不一致、Flutter バージョン管理ツールの欠如、ドキュメントの散在やタイムリーな更新の不足などにより、チームメンバーのエネルギーが大幅に消費されています。

2）エンジニアリング環境の問題

開発環境の問題を解決した後、エンジニアリング環境の問題にも取り組む必要があります。デュアルターミナルのエンジニアリング構造は複雑で、特定の端末に不慣れな開発者にとってはコンパイル問題の解決が困難です。多くの開発者がもう一方の端末でのプロジェクト設定を諦め、慣れ親しんだ端末でのみデバッグを行うのが通常となっており、Flutter のデュアルターミナル開発の理念に反する状態になっています。

コメント：チームの調査とインタビューによると、新人開発者が Flutter の開発環境とエンジニアリング環境の基本環境を構築するには 1 日かかり、その後 2〜3 日をかけてさまざまなコンパイル問題に対処する必要があります。特に iOS 関連環境は、Android 開発者にとって完全に動作させるまで非常に困難です。

3）統合フローの問題

コードの開発とテストが完了した後、統合ステップが多く、プラットフォーム間の切り替えが頻繁に発生し、統合フローが分断されており、完全な SOP が確立されていません。統合プロセス全体は時間がかかり、品質の問題も発生しやすくなっています。

コメント：既存の Flutter モジュールの統合フローは 6 つのステップに分かれています：1 モジュールブランチのマージ -> 2 モジュールの新規タグバージョン生成 -> 3 メインプロジェクトのモジュールバージョン番号変更 -> 4 メインプロジェクトのコードマージ -> 5 メインプロジェクトのバージョン番号生成 -> 6 公式パッケージの提出。ステップが煩雑で、Aone、MTL などのプラットフォーム間を行き来し、さまざまなバージョン番号を手動で操作する必要があるため、オンライン品質問題を引き起こしやすくなっています。

課題 2

これらの問題を解決するため、これまでドキュメントやスクリプトが蓄積されてきましたが、ドキュメントは手順やコマンドが多く、一つでも間違えると環境構築の誤りにつながる可能性があります。さらに、ドキュメントがタイムリーに更新されていない場合もあります。

デスクトップ GUI 形式の開発ワークベンチがあれば、開発者が日常の開発で直面するさまざまな問題をそこで解決でき、新人もこのワークベンチを使って迅速に開発を開始できます。幸福度は質的な向上を遂げると考えられます。

そこで、デスクトップ側の開発ワークベンチを構築することを決定しました。この目標を実現する過程で、多くの課題にも直面しました。

1）開発者のアクセスと使用コストをいかに削減するか

アクセスコストと使用コストです。開発ワークベンチはそもそもツールソフトウェアです。操作自体が複雑で、さまざまなドキュメントを読む必要があるとすれば、ツールソフトウェアのシンプルで使いやすいという本来の目的から逸脱してしまいます。したがって、関連機能を開発する際は、複雑な操作をワンクリックで実現しなければなりません。ソフトウェア環境のワンクリック設定、エンジニアリング環境のワンクリック設定、ワンクリック統合リリースなど、多くの機能をこの考え方に基づいて実装しました。
既存の開発環境とエンジニアリング環境との互換性も考慮する必要があります。新人開発者を除き、ほとんどの開発者のコンピュータにはすでに何らかの環境が整っています。開発者の既存の使用習慣を変更せずに、既存の環境と共存させる方法も重要な検討事項です。

2）アーキテクチャ設計の合理性をいかに確保するか

開発ワークベンチを、誰もが参加して共に構築できるオープンなプラットフォームにしたいと考えています。個人の時間は限られており、ワークベンチ自体もツールセットの集約として、より多くの開発者の参加と、より多くのアイデアの実装が必要です。そのため、リポジトリの権限管理とプラグインフレームワークの設計が非常に重要になります。

3）新技術の実装にあたり、関連問題を自ら探求し解決する必要がある

デスクトップ開発ワークベンチの開発では、Flutter Desktop 技術を採用しています（理由は技術調査部分で詳述します）。現在、中国国内では Flutter Desktop 技術の本番環境での導入事例は少なく、関連経験もまだ比較的乏しい状況です。時には、自ら問題を探索し解決する必要があります。

次に、これらの問題を解決するために iBox で設計したコア機能と、これらの機能がどのように問題に対処するかを見ていきます。

3 技術全景

1 技術調査

業界におけるクライアント側開発ワークベンチの開発状況は以下の通りです。

業界：EasyBox、MBox などのツール。これらのツールの核心は、Native 環境構築における開発効率の低さを解決することにあります。一方、Git と Cocoapods を深くラップし、開発モードを統一しています。

Tao Te：いくつかの分散したスクリプトツールも存在します。しかし全体的に見て、開発環境の設定、開発・デバッグ、統合リリースなどの問題はまだ解決されていません。

全体的に、クライアント側開発ワークベンチが導入される機会があります。業界では試みているチームがあり、Tao Te にも Flutter 開発プロセスにおける痛みとニーズがあります。デスクトップ側の開発を行う以上、デスクトップ側開発フレームワークの選択が最初の検討事項となります。現在主流のデスクトップ側開発フレームワークは主に 2 種類あります。

フロントエンド向け Electron：JavaScript、HTML、CSS でデスクトップアプリを構築。

クライアント向け Flutter Desktop：Flutter でデスクトップアプリを構築。

通常、技術選定を行う際は、問題解決、チームの状況、技術分野、ビジネストレンドなどの側面を検討します。

問題解決：Electron と Flutter Desktop のどちらのソリューションも、我々の問題を解決できます。パフォーマンスに差異はありますが、これが最も懸念している点ではありません。

チームの状況：クライアント側開発者は Flutter に精通しており、クライアント側開発者の参入コストが低く、他端末の人的リソースに依存しません。この点から、Flutter Desktop の方が優れています。

技術分野：Electron、Flutter Desktop のどちらも前進しています。Flutter チームが今年リリースした Flutter 2.10 では、Windows プラットフォームが正式に安定版サポートに組み込まれ、今年中に Linux、MacOS などのプラットフォームの安定版サポートも完了する予定です。

ビジネストレンド：ワークベンチは将来的にすべてのプラットフォームに拡張される可能性があります。たとえば、デスクトップ側では開発ワークベンチ、モバイル側（Android & iOS）では iBox がアプリケーションウィジェットセットや Ant Partners のようなアプリ、Web 側ではデータダッシュボードとなります。この観点から、Flutter Desktop の方が優れています。また、ウィジェットやその他のコンポーネントをワークベンチ上に表示したいと考えています。Flutter ベースで実装すれば、WYSIWYG が実現できます。これは非常に優れた体験になります。
以上の検討に基づき、最終的に Flutter Desktop を選択しました。開発フレームワークが決まったところで、iBox のアーキテクチャ設計を見ていきます。

2 機能設計

iBox のコアポジショニング

iBox は、Flutter Desktop 技術スタックに基づく、ワンストップで多様化・カスタマイズ可能な開発ワークベンチです。開発環境から統合リリースまでの全プロセスに開発サポートを提供します。コア機能には、ワークベンチ、開発環境、プロジェクト管理、エンジン管理、コミュニティエコシステム、変更オーダー管理、ツールボックスなどがあります。

機能設計において、iBox はワークベンチ、研究開発、リリース、ツールボックスの 4 つの主要セクションに分かれています。そのうち、研究開発、リリース、ツールボックスにはそれぞれ多くのサブモジュール機能が含まれています。
ワークベンチ、開発環境・プロジェクト管理、コミュニティエコシステム、変更オーダー管理のコア機能を中心に、iBox の全体機能を把握していただきます。

ワークベンチ

最近の変更オーダー、共通プラットフォームへのクイックアクセスなどの機能を提供し、共通機能にワンクリックで直接アクセスできるようにします。さらに、ワークベンチには技術展示バナーの機能も予約されており、チーム内外の優れた技術成果を表示できます。将来的には、当番リマインダー、統合リマインダー、リリースリマインダーなどをワークベンチに表示することも検討されています。

開発環境・エンジニアリング管理

開発環境 + プロジェクト管理は、ローカル開発に迅速に入る方法を解決します。新人開発者がチーム開発に参加する場合、コンピュータを受け取ってから開発に入るまでに、一般的に開発環境設定とエンジニアリング環境設定の 2 つのフローを経る必要があります。

このプロセスでは、さまざまなドキュメントを読んでそれに従って操作する必要があります。ドキュメントがタイムリーに更新されておらず、操作エラーが発生することもよくあります。エラーが発生すると、Google で検索したり周囲の同僚に聞いたりする必要があります。プロセス全体に時間がかかり、手間もかかります。

iBox の開発環境とプロジェクトマネージャーの 2 つの機能モジュールは、ワンクリック操作で上記の問題を解決します。

まず、開発環境は Flutter、Android、iOS の開発環境の確認とワンクリック設定機能を提供し、特定の端末に不慣れな開発者でもより便利に自身の開発環境を設定できるようにします。以下に示します。

次に、プロジェクト管理は、混合プロジェクト内の Flutter、Android、iOS などのシェルプロジェクトの環境検出やワンクリック環境設定機能を提供し、複雑で困難な環境設定の問題を解決します。以下に示します。

エンジニアリング環境の複雑さは、Flutter、Android、iOS のコンパイルを含む点にあります。コンパイルプロセスはローカル環境の差異によっても変化し、さまざまなコンパイルエラーが発生するため、開発者は対応に苦慮します。iBox は環境からプロジェクトまでさまざまなエラータイプを整理し、エラー情報を表示します。以下の通りです。

開発者にエンジニアリング環境のどこに問題があるかを知らせるだけでなく、エンジニアリング環境のワンクリック修復機能も提供します。ワンクリック修復機能は、まずキャッシュを削除し（flutter clean、ロックファイルの削除など）、その後以下のプロセスに従ってプロジェクト全体を再実行し、プロジェクト環境が修復されることを確保します。以下の通りです。

開発環境とプロジェクト管理の 2 つの機能モジュールが連携し、開発者の環境設定困難な問題を真に解決します。同時に、Android と iOS の間の垣根を取り払い、もう一方の端末に不慣れな開発者でも、この端末でのデバッグやパッケージングを行えるようにします。

コミュニティエコシステム

社内外ともに Flutter に多くの機能コンポーネントを貢献していますが、これらのコンポーネントを表示する統一された場所がなく、開発者は使用する際に pub ライブラリで検索する必要があります。

iBox のコミュニティエコシステム機能は、Flutter コミュニティ（社内外）のエンジン、UI コンポーネント、ルーティング、ダイナミクスなど、さまざまな側面の技術蓄積を表示します。特に UI コンポーネントについて、iBox 自体が Flutter ベースで開発されているため、これらの UI コンポーネントの Dart コードを iBox 上で直接表示・操作できます。この WYSIWYG 体験は非常に優れており、以下に示します。

変更オーダー管理

従来の開発プロセスでは、Flutter の開発フローが比較的煩雑で、これらのフローは開発者が手動で操作する必要がありました。以下に示します。

開発開始：iBox は Aone 要件を関連付けて変更オーダーをワンクリックで作成し、同時に新しい変更ブランチを作成して現在の変更に必要なエンジニアリング環境を準備します。
開発中：ワンクリックで Android & iOS のデュアルターミナルパッケージを開き、変更リポジトリの CR をワンクリックで提出します。
開発完了：ワンクリックで統合を提出し、提出プロセス中に上記の統合ステップが自動的に完了します。
これらのワンクリック操作は Flutter 開発の効率を大幅に向上させるだけでなく、Flutter のブランチ管理と統合方法を標準化し、個人の随意な操作によるエンジニアリング問題を回避します。

以上が iBox の第 1 フェーズで計画・完了した機能です。前述したチームの開発プロセスのさまざまな問題を根本的に解決します。同時に、Xianyu が統合リリースの飛魚ワークベンチを私たちのために実践してくれたことに感謝します。

3 アーキテクチャ設計

iBox のアーキテクチャ設計では、主に以下の問題に取り組んでいます。

問題 1：iBox は一定規模を持つ GUI ソフトウェアです。各機能モジュールのコードをどのように便利かつ安全に組織するか。
問題 2：iBox は共同構築面向であるため、iBox 自体の開発体験をいかに確保するか。
問題 3：共同構築と開放性を確保しながら、ソフトウェアの全体的な品質とパフォーマンスをいかに保証するか。
上記の問題への考察を通じて、iBox には垂直方向のレイヤード設計と水平方向のモジュール設計を採用しました。具体的には以下の通りです。

問題 1：異なる機能をモジュールとして設計し、各モジュールのソースコードは相互に独立しています。これにより、ソースコードリポジトリの権限を細かく制御でき、異なるモジュール間の変更が相互に影響を与えません。

問題 2：git repo に基づくマルチリポジトリ管理。git を使用して単一リポジトリを操作でき、git repo を使用して複数リポジトリでのコード同期、コード提出、コードレビューなどの操作も行えます。これにより、iBox のマルチリポジトリ協業の開発体験が確保されます。

問題 3：各モジュールの基本アーキテクチャ設計を統一。ソースコードの組織方法、状態管理スキームなどを含み、静的スキャンを通じてこれらの規約の実装を確保します。

サードパーティライブラリの参照を制限し、サードパーティライブラリのバージョンを指定します（^ 記号を使用したバージョン指定は行いません。例：url_launcher: ^6.0.20）。^ で指定したバージョンは、最後の 2 つのバージョンが自動的にアップグレードされます（flutter upgrade 時に pubspec.lock ファイルが再生成される際）、パッケージング時に予期しないバージョンが使用され、品質問題を引き起こす可能性があります（最近の url_launcher の url_launcher_macos の自動アップグレードによりリンクが開けない問題を参照 issue1 issue2）。
全体のアーキテクチャの全体像は以下の通りです。

上記のアーキテクチャ図から、補助機能が基本モジュールとして他のコア機能に基本能力を提供していることがわかります。次に、プロジェクトからモジュールの順に具体的な設計スキームを説明します。

まず、全体のプロジェクト設計です。
次に、具体的なモジュールの設計です。

エンジニアリング構造

全体のプロジェクトはマルチリポジトリ設計を採用しています。この設計を採用した理由は、iBox がチーム横断の開発を含むためです。マルチリポジトリにより各モジュールのソースコードを相互に独立させ、異なるモジュールが相互に干渉しないようにします。

iBox は git-repo に基づいてマルチリポジトリ管理を実装しており、リポジトリ構造は以下の通りです。

ibox がメインプロジェクト、ibox_common が基本モジュールで、他のモジュールは ibox_common に依存します。iBox を開発する開発者は、いくつかの簡単なコマンドだけで iBox の全ソースコードプロジェクトを同期できます。

その後、自身のモジュールで開発やコード提出を行い、相互に干渉することなく作業できます。全体のプロジェクト設計を説明したところで、各モジュールの設計を見ていきます。

モジュール設計

各モジュールのコア機能は UI インタラクションとロジックインタラクションの処理です。従来のクライアントの命令型 UI フレームワークとは異なり、Flutter は宣言型 UI フレームワークを採用しており、UI の変更を駆動するのは状態（State）です。以下に示します。

Flutter における状態とは、ウィジェット間またはウィジェット内部に保存・伝達されるデータや情報のことです。短期状態とアプリケーション状態に分けられます。

短期状態（ephemeral state）：ユーザー UI 状態または部分状態とも呼ばれ、ウィジェット内で完全に独立した状態です。ウィジェットツリーの他の部分はこの状態にアクセスする必要がなく、状態アーキテクチャ（ScopedModel、Redux）を使用してこの状態を管理する必要もありません。StatefulWidget だけで十分です。

アプリケーション状態（app state）：アプリケーションの複数の部分で共有される短期状態ではない状態で、ユーザーはセッション中にこの状態を保持します。

したがって、状態管理は UI とロジックコアを記述する際に直面する問題であり、ソースコードの組織方法にも影響します。Flutter の状態管理の公式ドキュメントでは、14 種類の状態管理ソリューションが提供されています。公式推奨ソリューションを中心に議論し、他のソリューションについては興味のある方が公式ドキュメントを参照してください。

まず、2 つのネイティブ状態管理方法を見ていきます。

setState：通常、ウィジェット内部の短期状態の処理に使用されます。

InheritedWidget：setState はウィジェット内部の短期状態のみを処理できます。アプリケーション状態を処理し、ウィジェットツリー間で通信する必要がある場合は、InheritedWidget を使用する必要があります。InheritedWidget はサブウィジェットにデータとサービスを提供できます。

setState は適用シーンが比較的限られており、InheritedWidget は開発者にとって低レベルすぎて使用が複雑です。公式ソリューションに制約があるため、コミュニティが提供するより推奨されるソリューションを見ていきます。

Provider：InheritedWidget コンポーネントをラップし、より簡単に使用・再利用できるようにします。

Riverpod：Provider の改善に基づいた、レスポンシブな状態管理・依存性注入フレームワークです。コンパイル時に安全で、DevTools デバッグをサポートし、Flutter 自体に依存しません。

実際、Provider と Riverpod の著者はどちらも Remi Rousselet です。Riverpod という名前は Provider の文字を並べ替えて得られたものです。主に Provider の機能的欠陥を解決するためにリリースされました。以下の通りです。

上記の比較に基づき、最終的に Riverpod ソリューションを選択し、それに伴ってモジュールのソースコード構造を設計しました。以下の通りです。

UI ロジックを記述する一般的なフローは以下の通りです。

ui 部分にページやコンポーネントを記述します。
service にデータ関連のロジックを記述します。
provider に関連する provider クラスを記述します。service の関数を呼び出すことができます。
ui やその他の必要な場所で provider を参照し、関連ロジックを操作します。
この方法により、UI とロジックの分離・疎結合が実現し、UI 部分は自由にイテレーションでき、ロジック部分も再利用できます。

以上が iBox の全体的なアーキテクチャ設計で、簡略化されたプラグインソリューションに相当します。将来的により豊富なプラグインエコシステムを持つためには、VSCode のようなプラグインマーケットのリリースを検討しますが、現時点では十分に使用できています。

プラグイン設計により、さまざまなモジュールを自由に組み合わることが可能になりました。異なるチームには異なるモジュール機能が必要です。アプリバリアント（variant）機能をリリースしており、異なるアプリバリアントには異なるタブバー設定があります。パッケージング時に、異なるチーム向けに異なる機能のパッケージを作成できます。

4 オンライン効果

開発プロセスのコアペインポイントにおける iBox 使用前後の比較


しばらく使用した後、iBox ユーザーから多くの良いフィードバックをいただきました。

「ワンクリックインストールは非常に使いやすく、開発の時間を大幅に節約できました。以前はあちこちでダウンロード、インストール、設定を行い、バージョン競合の問題を解決するのに多くの時間を浪費していました。」
「今回のバージョンでは完全にモバイル対応された iBox が統合され、使用感が非常に素晴らしいです。」

「Flutter 環境の設定や、煩雑な統合などの問題が大幅に簡素化されました。」

さらに、iBox はまだ初期段階にあり、プロダクトとしてイテレーション・運用していきたいと考えています。このため、iBox に対して異なる観点からの運用指標も設計しました。以下の通りです。


最も注目の機能モジュールランキング

運用データシステムは長期的な構築が必要です。その後の機能イテレーションと体験最適化にとって重要な指導的意義があります。開発者もユーザーであり、ブレインストーミングのみに依存する機能は皆に認められない可能性があります。

4 技術まとめ

iBox に取り組む前に、Flutter について理論的な調査を行いました。「アーキテクチャからソースコードまで：Flutter のレンダリングメカニズムを一文で理解する」という記事を執筆しましたが、生産実践に適用する良い機会がありませんでした。今回の iBox 開発で多くのことを学びました。この機会に、Flutter Desktop 技術の生産実践での応用について説明します。

1 Flutter Desktop の発展の歴史

2018 年 2 月 15 日に Flutter チームが flutter-desktop-embedding プロジェクトを開始してから 4 年が経過し、その過程には浮き沈みがありました。初期の本番環境非サポートから Flutter 2.10 のリリースを経て、Windows プラットフォームでの本番環境アプリ開発が正式にサポートされるようになりました。Flutter Desktop の発展の歴史は以下の通りです。

2022.02.15、Flutter 2.10 がリリースされ、Windows プラットフォームが率先して安定版に入り、生産レベルのアプリ開発に使用できるようになりました。他のプラットフォームも積極的に準備中です。
2022 年、Flutter チームは Windows、Linux、MacOS の順に段階的に進行し、主流デスクトッププラットフォームのサポートを安定チャネルにもたらし、最終的に Flutter の「ワンコード・マルチプラットフォーム」というビジョンを実現する予定です。

2 Flutter Desktop のコミュニティエコシステム

Android や iOS へのサポートと同様に、Flutter は Windows などのプラットフォームに基づいて Embedder を実装しています。Embedder の上位層は C++ Engine と Dart Framework です。Windows などのプラットフォーム上でのメッセージの翻訳と送信を担当し、全体のアーキテクチャは以下の通りです。

コメント：Linux や MacOS などの他のデスクトッププラットフォームも同様の実装構造を持っています。より詳細な内容については、platform の実装を参照してください。

デスクトップアプリケーションとモバイルアプリケーションには類似点があります。たとえば以下の通りです。

これにより、既存の Flutter コミュニティコンポーネントの大部分はデスクトップ側でも利用可能ですが、両者には差異もあります。たとえば以下の通りです。

これらの差異に基づき、Flutter はデスクトッププラットフォームに対してターゲットを絞ったサポートも提供しています。以下の通りです。

画像は Announcing Flutter for Windows から引用

iBox の開発過程中、ネイティブ機能も多数使用しました。以下に Flutter Desktop で一般的に使用されるコミュニティコンポーネントの一部をまとめました。

既存のコミュニティコンポーネントは基本的に開発ニーズを満たしています。

3 Flutter Desktop のアプリケーションシーン

iBox は Flutter Desktop 技術の有意義な探求であり、プロダクトにさらなる可能性をもたらし、プロダクトの到達範囲の境界を拡大しました。

では、Flutter Desktop はどのようなアプリケーションシーンに適しているでしょうか。

企業内で使用されるツールソフトウェア。特にチームの人員が不足している中で、迅速にツールや機能を実装したい場合。

企業向け ToB アプリケーション。レジ、Ele.me 加盟店など。

チームが既に Flutter ベースのモバイルアプリケーションを開発しており、一部の機能をデスクトップに拡張したい場合。

どのような技術にも長所と短所があり、Flutter Desktop にも不適切なアプリケーションシーンがあります。以下の通りです。

デスクトップ側のネイティブ機能に強く依存するアプリケーション。デスクトップ側のコミュニティエコシステムサポートはモバイル側ほど完全ではなく、機能不足に遭遇した場合はゼロから構築する必要があるため。

もちろん、技術も常に進化しており、現在の問題も将来的に解決される可能性があります。筆者は Flutter Desktop 技術の発展に非常に期待しています。