DingTalk Flutter クロス 4 端末ソリューションの設計と技術実践

この記事では、主にDingTalkがFlutterをベースに構築したクロスクアッドターミナルアプリケーションフレームワーク（コード名Dutter）を紹介します。内容は主に、FlutterEngineレベルでのソリューション設計、ベストプラクティス、問題箇所などです。同様の要求を持つチームにとって、この記事が参考になれば幸いです。

プロジェクト概要

1.1 ダッターとは何か

Dutter、または DingTalk Flutter は、DingTalk 内の Flutter 上に構築された、4 端末間の R&D フレームワークです。

Dutter プロジェクトは「Flutter から始まりましたが、Flutter 以上のものです」。このプロジェクトの主な目標は、Flutter のクロスプラットフォーム機能を活用して、ユーザーエクスペリエンスを犠牲にすることなく DingTalk のエンドサイド研究開発の効率を向上させ、それによって DingTalk エンドサイドの研究開発リソース不足や各エンドの人材の不均衡の問題を軽減することです。

1.2 現在の進捗状況

現在、Dutter運営フレームワークは、DingTalkの4つの端末の統合を完了し、一連の共創事業のグレースケールおよびパイロットプロジェクトを完了しました。現在、DingTalk の Flutter ベースの研究開発事業には、「スケジュール サインイン」、「+ パネル」、およびいくつかの内部グレースケール事業が含まれます。

プロジェクトの背景

私たちが Flutter を選択し、Dutter プロジェクトを開始した主な理由は次の 2 つです。

1. エンドサイド研究開発の効率を向上する。
2. Flutter テクノロジーをフォローアップします。

以下で簡単に説明します。

2.1 エンドサイド研究開発の効率化

DingTalk が開発 7 年目を迎える中、クライアント側の「ビジネス ニーズ」、「R&D リソース」、「技術の進化」の間の矛盾はますます激しくなっています。

• ビジネスプロダクトの同僚には優れたアイデアがたくさんあります。アイデアを実行するには、さまざまな場所で TL を見つけてリソースを争う必要があります。また、R&D リソースが不足しているため、ニーズのビジネス価値を繰り返し伝える必要があります。
• R&D の同僚は、多くの場合「1 対 N」の状況にあります。ビジネス ニーズ、安定性の保証、技術サポート、バグ修正などがあり、毎日の作業時間は基本的に飽和状態です。
• 技術チームは現状に満足するだけでなく、将来を見据える必要があります。日々のビジネス反復のニーズを満たすと同時に、今後 3 ～ 5 年間の開発ニーズを満たす技術プロジェクトに投資するためのリソースを割り当てる必要もあります。

上記の点は、技術的な研究開発リソースが不足しているという 1 つの問題にまとめることができます。上記の問題を解決するには、2 つの方法があります。1. 技術チームの規模を拡大し続けること。2. チームの研究開発効率を向上させること。

DingTalk 側の現在のチーム規模が 150 人近くであることを考えると、全体の規模は小さくなく、これ以上の拡大は難しいでしょう。チームの規模を無制限に拡大することはできないため、R&D 効率の改善の余地を探る必要があります。

• エンドサイドの技術スタッフは5つのプラットフォームに分かれており、分割後は各プラットフォームの人員が不足していました。
• 異なるプラットフォームを使用する学生は、基本的にテクノロジースタックの点で「孤立」しており、お互いを補うことはできません。
• あらゆるビジネス要求には、4 つ以上の当事者からの研究開発リソースが必要です。いずれかの当事者の人材が不足すると、ビジネスを実行できない可能性があります。
• 同じロジックの複数のコピーが実装されている場合、完全な一貫性を実現することは困難です。異なるプラットフォーム間でビジネス パフォーマンスに一貫性がないことが頻繁に発生し、やり直しや集中により効率性がさらに低下します。
• ビジネスがオンラインになった後は、さまざまなプラットフォームが個別に保守されるため、日々の技術サポート、バグ修正、その他のシナリオに複数の投資が必要になります。

このことから、クロスプラットフォーム技術を活用して技術者同士が「1つのコードですべてをカバー」できるようにし、本来は複数のプラットフォームと複数の技術者を必要としていた作業を1～2人のクラスメートで統合できれば、研究開発の効率を大幅に向上できることがわかります。

2.2 Flutterテクノロジーのフォローアップ

DingTalk にはすでに「ミニプログラム」や「H5」などのクロスターミナルテクノロジーがあります。効率性を向上させる必要がある場合、既存のテクノロジースタックを直接使用して目標を達成できますか? DingTalk クライアント チームにとって、クロスプラットフォーム用の Web ベースのソリューションを選択することは理論的には可能ですが、実際には期待される結果を達成するのは困難です。主な理由は2つあります。

1. 「ミニプログラム技術」は現在、人気のクロスターミナル技術です。その設計位置付けは、三者エコシステムの多様なシナリオを満たすことです。そのアーキテクチャ設計は、単一のポイントを繰り返し磨くのではなく、「大きくて完全」であることに重点を置いています。これは、DingTalk が重視する「専門性と精度」および「卓越性の追求」とは矛盾しています。
2. クライアント側の学生にとって、フロントエンド開発モデルは参入障壁が高く、R&D モデルも大きく異なります。より高いレベルの開発を行うには、ある程度の使用および開発経験が必要であり、それは初期段階である程度の「試行錯誤の余地」が必要であることを意味します。 DingTalk の現在のオンライン品質要件を考えると、これを満たすのは困難です。

Flutter は近年開発されたクロスプラットフォーム技術です。Web エコシステムとは異なり、ネイティブのようなアーキテクチャ設計に基づいており、ダイナミクスを選択的に放棄し、クロスプラットフォームに重点を置いています。同様のネイティブ パフォーマンスとエクスペリエンスを確保しながら、開発者は「一度開発すれば、複数の端末でビルドして実行できる」ようになります。したがって、ミニプログラム技術と比較して、Flutter はエンドサイドの技術チームの悩みを解決するのに適しています。

さらに、国内のクロスプラットフォーム技術の予備調査を行った結果、Flutter をベースとしたクロスプラットフォーム プロジェクトには、後発の優位性が明らかで、上限が高く、開発の可能性が大きく、長期的な投資価値も高いことがわかりました。

当社が業界におけるクロスプラットフォーム ソリューションを長期にわたって追跡した結果、現段階では「自己描画エンジン」が話題になっており、「自己描画エンジン」ソリューションのほとんどは、Flutter プロジェクトがオープンソース化されて人気が出た後から開始されたことがわかりました。この時点でのこの一致は偶然ではありません。主流のクロスプラットフォーム ソリューションの技術的実装の違いを説明するために、次の図を使用します。

上の図から、クロスプラットフォーム ソリューション デザイナーにとって、Flutter プロジェクトの最大の価値は、エコシステム向けにオープンソースで、適切に設計され、互換性が高く、高性能で、明確に定義された自己描画エンジンを提供していることであることがわかります。

このオープンソースの自己描画エンジンをベースに、スキルのあるチームは、わずかな変更を加えるだけで独自のクロスプラットフォーム ソリューションに適用し、ネイティブ コンポーネントを置き換え、Flutter のクロスプラットフォーム一貫性機能を再利用して、ソリューションのビジネス価値と技術的価値を高めることができます。

DingTalk に関しては、クロスプラットフォームへの現在の投資と目標を考慮すると、他のソリューションのように独自のクロスプラットフォーム自己描画エンジンをリリースする準備はまだできていません。しかし、技術的な観点から見ると、Flutter ベースのクロスプラットフォーム ソリューションを選択することで、一方では Flutter の技術的メリットをすぐに享受でき、提供される製品のパフォーマンスと品質を他の主流のソリューションと一貫したものにすることができます。他方では、このプロセスで関連する技術チームを育成し、その後のより深いカスタマイズと変革のための技術的準備を整えることもできます。

ソリューション設計

このセクションでは、DingTalk の Dutter クロスエンド フレームワークの設計について簡単に紹介し、いくつかの代表的な問題についてさらに説明します。

3.1 全体設計

Dutter コア モジュールは、次の 3 つの主要パッケージで構成されています。

1. Dutter ランタイム;
2. Dutter 開発キット;
3. ダッターOPSキット。

全体像は次の図に示されています。

• Dutter ランタイム: Flutter 上に構築された Dutter ランタイム環境は、Dutter の中核部分です。 Flutterが提供する基本機能に加え、コンテナ化されたコンポーネント、APIプラグイン、ビジネスモジュラーフレームワークなどの機能も提供します。また、同グループの AliFlutter プロジェクトに基づいて、Aion の動的機能がさらに拡張されました。 Dutter Runtime は、プロジェクトでこれまで私たちが全面的に取り組んできた部分でもあります。
• Dutter Dev Kit: 4 台以上の端末で開発を行う際に、異なるテクノロジー スタックを持つ学生のサポートと効率の問題を解決することを主な目的とする研究開発キットです。現在の投資は比較的限られており、将来的にはDingTalk R＆Dプラットフォームと統合される可能性があります。
• Dutter OPS キット: 運用保守キットは、主にダッシュボード監視などの Dutter 製品のリリースおよび運用保守関連の機能を搭載しています。現在の投資は比較的限定されており、将来的にはDingTalk R＆Dプラットフォームと統合される可能性があります。

上記の図を展開すると、フレームワークの全体的なモジュール図が得られます。これはおおよそ次のようになります。

下から上へ:

• 左下隅は「Dutter Runtime」関連のモジュールです。
• 右下は「Dutter OPS Kit」関連のモジュールです。
• 右上は「Dutter Dev Kit」関連のモジュールです。
• 左上はビジネスセクションです。

3.2 データ通信

データ通信は主に、Flutter とプラットフォーム間の 2 つの主要な通信方法、チャネルと FFI を指します。チャネルは、Flutter アプリケーションでは比較的一般的です。Flutter とプラットフォーム間の通信の設計のほとんどは、このモードに基づいています。その利点は、高い統合性、優れたカプセル化、簡単な使用です。欠点は、主に通信効率の問題です。FFI は、Flutter 2.0 で正式な機能としてリリースされました。その最大の特徴は、同期呼び出し、メモリ共有、高い実行効率ですが、使いやすさとスケーラビリティの点ではまだ改善の余地があります。

1  チャネル

チャネルに関しては、DingTalk側での使用方法と公式ドキュメントに本質的な違いはありません。私が共有したい経験は、チャネル数の管理に関するものです。公式のオリジナルデータには、チャネル管理に関する内容はあまり含まれていません。DingTalk の実際の使用経験に基づいて、共有用のチャネルを 1 ～ 2 つに集約して 1 つの業務に組み込み、共有チャネルに基づいて業務用の「応答」および「配信」インターフェースをカプセル化することをお勧めします。

これには主に次の利点があります。

1. パフォーマンスの安定性につながります。チャネルを制限することで、通信異常の可能性を減らし、通信パフォーマンスを向上させることができます。
2. これは管理に役立ち、特に「シングルエンジン/マルチエンジン」共存モードでは、合理的なカプセル化によって根本的な違いを解消できます。

上記の 2 つの点、特に 2 番目の点は、DingTalk のモバイル端末およびデスクトップ端末との互換性にとって非常に重要です。 「DingTalk Flutter デスクトップ アプリケーション ソリューション」で説明したように、現在、モバイル側ではシングル エンジン アーキテクチャを使用していますが、デスクトップ側ではマルチ エンジン アーキテクチャを使用しています。チャネルが適切にカプセル化されておらず、ビジネス関係者が FlutterEngine を直接登録して呼び出すことが許可されている場合、マルチエンジン モードでのコード管理コストが大幅に増加し、モバイル側とデスクトップ側の実装に一貫性がなくなります。

私たちの現在のアプローチは、FlutterEngine と Channel を Dutter フレームワークにカプセル化し、統合されたカプセル化されたインスタンスを上位レベルのインターフェースである DutterMethodChannel に公開することです。ビジネス レイヤー コードでは、基盤となるアーキテクチャがシングル エンジン モードかマルチ エンジン モードかを意識する必要はなく、統一されたルールとモードに従って関連サービスを登録または呼び出すだけで済みます。このモデルは、ビジネスでの使用の複雑さを軽減するだけでなく、基盤となるフレームワーク設計に大きな柔軟性をもたらし、その後のモバイル端末のマルチエンジン ソリューションへの切り替えを強力にサポートします。

2  国際金融公社

FFI は Flutter 2.0 で正式にリリースされました。Channel と比較した最大の利点は、実行効率が高く、パフォーマンス要件が高いシナリオに適していることです。この章では、FFI の具体的な使用法については触れませんが、FFI を使用する際にメモリ管理で注意する必要がある点について説明します。

現在のモバイル開発 (Java、OC、Swift) にはすべて自動メモリ管理のメカニズムがあることは周知の事実です。Flutter で使用される dart 言語にも、ガベージ コレクションに基づく自動メモリ管理機能があります。さまざまな言語は、独自のルールに従って独自の範囲内でメモリを合理的に管理し、メモリ空間の合理的かつ安定した適用を保証します。

ただし、FFI は関数間直接呼び出し方式であるため、メモリ共有メカニズムに基づいて呼び出しチェーンを簡素化しますが、メモリ管理に対する要件も高くなります。このモードでは、メモリ空間が適切に管理（割り当てと解放）されていない場合、ワイルドポインタやメモリリークが発生する可能性が高くなります。

公式ドキュメントの Flutter FFI および Dart FFI の章の紹介では、メモリ管理の説明は比較的限られています。関連するインターフェース情報を調べると、dart:ffi がメモリを手動で管理する方法を提供していることがわかります。

これに基づいて、Dutter FFI メモリ管理戦略を定義できます。まず、中核となる原則を定義する必要があります。

1. 割り当てと解放は相同です。実装の違いによるメモリ割り当てと解放の例外を回避するには、割り当てと解放のアルゴリズムのセットを使用する必要があります。
2. 「割り当てる者は誰でも解放しなければならない」という原則を満たす必要があります。

1と2に基づいて、FFI操作関連のインターフェースとデータ構造をカプセル化し、「Dutter FFI Bridge」モジュールに統合します。

カバレッジと複雑さを十分に考慮した結果、デフォルトの基本型に加えて、Dutter FFI インターフェースに String 型のサポートのみを追加しました。その他のデータ型については、ビジネス パーティがシリアル化して渡すことができます。送信プロセス中、固定長文字列の場合は、「UTF-8 エンコードされた char * 配列」を介して直接渡すことができます。可変長文字列 (呼び出しの戻り値など) の場合は、カスタム データ構造 DTFUInt8String を使用して渡す必要があります。実装に固有の事項:

1. 「同じソースからの割り当てと解放」の原則を満たすために、Dutter では、統合された割り当てと解放の実装として、dart:ffi の allocate メソッドと free メソッドを選択します。 Dutter フレームワークは、起動プロセス中にインターフェイス バインディングを実行し、カスタム データ構造に関連するメソッドをネイティブ側に渡します。ネイティブ側のすべての FFI インターフェイス メモリ割り当てシナリオは、バインディング インターフェイスを通じて実装されます。

2. 「割り当てた者は解放する」という原則を満たすために、Dutter FFI インターフェースではデフォルトで次の 3 つの原則に同意します。これに基づいて、ヒープ メモリの割り当てが DTFUInt8String の制御範囲内にあることを保証できます。DTFUInt8String オブジェクトのライフ サイクルが適切に処理されている限り、転送プロセス中のメモリ管理のセキュリティが保証されます。

3.3 メッセージバス

「メッセージバス」は、DingTalk の機能モジュールです。主に、さまざまなテクノロジー スタックに基づいて DingTalk 側で実装されたビジネス コミュニケーションの問題を解決します。たとえば、Flutter ベースのビジネスで、ミニプログラムに基づいて実装されたページ更新 UI に通知したい場合、この機能はメッセージバスを通じて実現できます。

メッセージ バスは、企業が運用環境間でシームレスに通信できるようにすることを目的とした、軽量のエンドツーエンドのスーパー チャネルとして位置付けられています。論理的には、「バス」、「コントローラ」、「登録と送信」の 3 つのモジュールが含まれます。実装の面では、「永続的なメッセージ」、「パイプライン分類」、「権限制御」などの方法を通じて、全体的な操作の信頼性、効率性、安全性を保証します。

3.4 モジュール性

DingTalk のエンドサイドビジネスの特性上、モジュール構造に細心の注意を払っています。 Flutter ビジネスで採用されているモジュール ソリューションは、DingTalk Native のモジュール フレームワークから開発されました。当社は、当初から Flutter ビジネス レイヤーの直接結合を排除することにこだわりました。

モジュール化は、研究開発の効率を向上させるだけでなく、ビジネス上および技術上の大きな価値をもたらします。例えば：

1. DingTalk の複数のバージョンを強力にサポートし、「標準 DingTalk」、「主要顧客 DingTalk」、「独自の DingTalk」などの複数のバージョンのコード共有の要件を満たします。
2. 優れた互換性を提供し、基本モジュールの柔軟なプラグインとアンプラグにより​​、モバイル端末とデスクトップ端末上の同じアーキテクチャに対する Dutter フレームワークの要件を満たします。
3. 豊富な拡張性を提供します。たとえば、Flutter を動的にしようとすると、他のモジュールの安定性に影響を与えることなく、モジュール化に基づいて既存のモジュールを低コストで動的に変換できます。

3.5 コンテナ化

コンテナ化は、DingTalk での Flutter の迅速な実装を強力に保証します。 DingTalk が H5 やミニプログラム プロジェクトで蓄積してきたコンテナ基盤を基に、Flutter シナリオにおけるコンテナ化の概念を継続的に参照し、設計と機能の面で迅速に接続します。一方で、既存のインフラストラクチャを迅速に再利用できるようになります。他方では、ビジネス開発の複雑さが軽減され、元のコンテナの共通機能が Flutter シナリオでも引き続き使用できるようになり、テクノロジー スタックを継続できるようになります。

開発タイムラインから見ると、DingTalk のクライアント側コンテナは次の 3 つのバージョンを経てきました。

• バージョン 1.0 では、主に「存在」の問題を解決し、コンテナーに関連するコア概念を定義します。
• バージョン v2.0 では、元のバージョンに基づいて「機能パッケージ」の概念を抽象化し、基本的なビジネス機能を複数の運用環境間で再利用できるようにします。
• バージョン v3.0 では、バージョン 2.0 に基づいて「ランタイム」と「拡張」がさらに抽象化され、コア実装レイヤーが「コンテナ ベース」になり、3 つの間の結合が弱くなります。

現在のコンテナ アーキテクチャに基づいて、将来の新しいテクノロジとの良好な互換性を確保できます。その後の開発で、Flutter に類似した新しいテクノロジー スタックに再度接続する必要が生じた場合、既存の標準に従って迅速に接続でき、コンセプト、機能、インフラストラクチャの面で最大限の再利用を確保できます。

3.6 コンポーネントライブラリ

DingTalk Flutterは現在、dingui_flutterとdingtalk_uikitの2つのコンポーネントライブラリセットを使用しています。その中で、dingui_flutterは現段階で私たちが注力している部分です。Dingui_flutterは、DingTalkビジュアルチームが提案したDingUIビジュアル仕様に従って実装されたFlutterバージョンコンポーネントのセットです。現在、コアコンポーネントは4エンドの互換性を実現できます。

dingui_flutter はコミュニティへの貢献を目標としていますが、現段階では安定性や完全性などの問題から、まだ DingTalk 内部で使用されています。成熟したらできるだけ早くオープンソース化する予定です。

フラッターデスクトップ

現在、DingTalkデスクトップ端末におけるFlutterの使用モードは、基本的にモバイル端末の場合と同じです。FlutterはDingTalkの機能モジュールであり、クライアント本体は依然として主に元のネイティブに基づいて実装されています。 Flutter ベースで実装された一部のサービスでは、起動時の遷移に Dutter フレームワークでカプセル化されたインターフェースが使用され、特定の遷移モードに応じて遷移アクションが実行されます。

上記の効果を実現するために、デスクトップアプリケーションでは主に以下の 3 つの問題を解決しました。

1. デスクトップ統合モードの問題。
2. Windows 32 ビットの問題。
3. エンジン アーキテクチャの互換性の問題。

上記の問題については後ほど一つずつ説明させていただきます。

4.1 デスクトップ統合モードの問題

Flutterは現在、デスクトップでのFlutterAppモードの使用のみをサポートしており、モバイル端末で広く使用されているFlutterModuleモードはまだサポートされていません。しかし、FlutterApp を通じて既存のクライアントに大規模な変更を加えることを期待するのは合理的でも現実的でもありません。したがって、デスクトップに Flutter を実装する際に最初に遭遇した問題は、Flutter をモジュールとして既存の DingTalk クライアントに統合する方法でした。

Flutter で構築された製品を分析したところ、FlutterApp と FlutterModule のコア製品に大きな違いはないことがわかりました。次の図に示すように、iOS 上の FlutterModule と macOS 上の FlutterApp を例に挙げます。

App.framework、Flutter.framework、Plugins.framework などのコア モジュールについては、FlutterApp と FlutterModule の両方が製品に含まれていることがわかります。主な違いは、補助プラグインの登録用に FlutterModule に FlutterPluginRegistrant.framework が追加されていることです。幸いなことに、実装のこの部分は複雑ではなく、カスタム ツールチェーンを通じて簡単に生成できます。

この考えに従って、Flutter デスクトップ統合ソリューションを整理することができます。

FlutterApp を使用してデスクトップの Flutter 関連モジュールを整理し、公式ツール チェーンに基づいて適切な拡張機能を作成します。元のビルド製品からモジュール化に必要な部分を抽出し、最後にプラグイン登録に必要なテンプレートコードを完成させます。最終製品が既存の DingTalk クライアントに統合された後、その使用方法は他のセカンドパーティ ライブラリと基本的に同じであり、既存の FlutterModule メソッドを参照して使用できます。

最終的なプロセスは次のとおりです。

Mac と Windows の製品統合図:

4.2 Windows 32 ビットの問題

Flutter は Windows 32 ビット システムをサポートしていないため、現段階では国内のデスクトップ エコシステムにおける Flutter の拡大を妨げる主な障害の 1 つとなっているはずです。この問題を解決するにあたり、DingTalk は基本的に、初期のデュアルプロセスから、途中での全体的な 64 ビット アップグレード、そして FFW まで、考えられるすべてのソリューションを試しましたが、上記のソリューションはさまざまな問題により最終的に実装できませんでした。

最終的には着陸に失敗しましたが、上記の試みの間に、非常に重要な 2 つの情報が得られました。

1. DartVM は Windows 32 ビット デバイスで実行できますが、JIT モードでの Dart コードの読み込みのみをサポートします。
2. Skia は Windows 32 ビット製品をコンパイルできます。

上記 2 点のサポートを受けて、DingTalk の Zhou Yong は最終的に Windows 32 ビット FlutterEngine をコンパイルするためのソリューションを模索し、JIT モードで Flutter コンパイル製品をロードして、最終的に Windows 側での使用要件を満たしました。

Windows プラットフォームで Flutter を使用するために、細かい部分を削ぎ落とした上で、次のことを行いました (詳しい内容については、後ほど特別記事で紹介します)。

1. FlutterEngine のビルド スクリプトを変更して、32 ビットの flutter_windows.dll をビルドできるようにします。
2. flutter_tool の FlutterPlugin コンパイル gn パラメータを変更して、32 ビットの生産検査製品を構築します。
3. セキュリティ難読化後、関連製品が DingTalk クライアントに統合されます。

上記の手順により、Windows 32 ビット DingTalk に Flutter を統合する主な作業が完了しました。JIT と AOT の機能には本質的な違いはありませんが、パフォーマンスには大きな違いがあります。グレースケール処理で見つかった主な問題は次のとおりです。

1. 起動速度が遅い: ホームページの読み込み時間は 2 秒以上かかります。
2. 一時メモリの使用量が多い: FlutterEngine オブジェクトが作成されるたびに、約 70 MB のメモリが消費されます。
3. コード実行効率が低い: ほとんどのシナリオではこの問題は明らかではありませんが、極端なシナリオではパフォーマンスの問題が依然として発生します。

したがって、現段階で私たちが採用したものは、公開ソリューションとしてしか考えられません。今後もこの分野への投資を増やし、できるだけ早く完全な Flutter を DingTalk Windows エンドに統合するよう努める必要があります。

4.3 エンジンアーキテクチャの互換性の問題

これは、デスクトップ実装プロセス中に遭遇した 3 番目の問題です。モバイル側では FlutterBoost に基づくシングルエンジン アーキテクチャを使用しているため、デスクトップ側では特殊な環境のため、マルチエンジン アーキテクチャのみを使用できます。

これにより、ビジネス関係者にいくつかの問題が発生しますが、最も深刻なのは、マルチエンジン環境によって発生する通信の混雑です。

この段階では、主にビジネス レイヤーの互換性を通じてこの問題を回避しています。つまり、マルチエンジン環境での通信の問題をサポートするために、DingTalk の「メッセージ バス」を使用しています。しかし、長期的には、複数のエンジンに対するフレンドリーなサポートが必要です。現在モバイル デバイスで利用可能な LightWeightEngine 機能をデスクトップに拡張し、その基盤を拡張して分離を打破し、ビジネス コードがメモリを完全に共有できるようにする必要があります。現在、このソリューションは AliFlutter プロジェクト チーム内で技術プロジェクトとして推進されており、設定された目標をできるだけ早く達成できることを期待しています。

要約する

現在、ダッタープロジェクトは基本的に第一段階の目標を達成しており、今後も以下の5つの分野に投資を続けていきます。

1. インフラストラクチャのアップグレード: モバイル FlutterEngine のアップグレード、flutter_boost のアップグレード、動的実装ソリューションの検討など。
2. パフォーマンスエクスペリエンスの向上：デスクトップパフォーマンスを向上させ、現在の公式サポート、インフラストラクチャの完全性、デスクトップ機能などによって引き起こされるパフォーマンスの問題の解決を最大限に高め、モバイル端末のレベルに合わせるよう努めます。
3. R&Dスイートの改善：DingTalkにワンストップのR&D環境を提供します。DingTalkのアプリケーション開発ニーズを満たすために、DingTalkの4つの端末向けのAliBoxベースのR&Dシナリオを拡張したいと考えています。
4. 安定性の強化: これにより、デスクトップ側、特に Windows 側の既存の安定性リスクが解決され、DingTalk 側の安定性要件が満たされます。
5. R&D 効率の向上: 事業範囲を拡大し、クロスエンドの Manulife をリリースし、DingTalk 側の R&D 効率をさらに向上します。