Harmony Nextの来年のバージョンで AOSP のサポートが正式に剥奪されるということは皆さんも聞いたことがあると思いますが、これを踏まえて質問をまとめておきましたが、その際に既存アプリの Harmony Next との互換性について次のように述べました。 :

また、ファーウェイは現在主流のクロスプラットフォームソリューションの適応を先導しており、リバース適応サポートも積極的に提供しており、将来的には調和のためのFlutterと同様のコミュニティサポートが行われると推定されています。

予期せぬことに、HDC カンファレンスからわずか 1 か月後、一部のネチズンは、OpenHarmony の Flutter バージョンがオープンソースであることを思い出しました: https://gitee.com/openharmony-sig/flutter_flutter. これは驚くべきことであり、また「合理的」です。多くのフレームワークの中で、Harmony と Flutter の関係は最も切り離せないものであると言えます。

関係

Harmony と Flutter の間に密接な関係があるのはなぜですか? ArkUI であろうと ArkUI-X であろうと、Flutter は多かれ少なかれその基盤となるサポートに含まれているからです。

たとえば、ArkUI のフレームワークarkui_ace_engineでは、よく知られた Flutter コードがたくさん表示されますが、ここで少し特殊なのは、下の図のStackコントロールのように、これらのコードはすべて C++ で実装されていることです。

さらに、ArkUI に加えて、ファーウェイはクロスプラットフォーム開発をサポートするために ArkUI フレームワークを拡張する ArkUI- Xもオープンソース化しています。クロスプラットフォームの基礎となるロジックのこの部分も Flutter と Skia のサポートから来ています。

OpenHarmony は Flutter とは異なり、上位開発に ArkTS と ArkUI を使用し、Node.js の仕様に基づいて開発されたネイティブモジュール拡張機能開発フレームワークのセットである NAPI (Native API) を呼び出します。

NAPI は JS と C/C++ コード間の相互アクセスを実現します。つまり、dart ffi の効果と同様に、ArkTS を直接呼び出すことができ、C/C++ をシームレスに呼び出すことができます。

たとえば、getDefaultDisplaySyncArkUI-X でデバイスの画面情報を取得する場合、Android システムの場合、ets のコードは napi を介して C++ 層の DisplayInfo オブジェクトを呼び出し、次に jni を介して java の DisplayInfo オブジェクトを呼び出します。

 var dsp = display.getDefaultDisplaySync();

実際、これは Flutter にとって非常に重要です。Napi は Flutter が Harmony OS と互換性を持つために不可欠な部分だからです。

Flutter では、C/C++ への直接呼び出しに加えて、Dart は Channel を経由せずに Objective-C/Swift および Java/Kotlin への直接呼び出しもサポートしているためです。

Objective-C/Swift 相互運用はpackage:ffigen 経由です。

ffigen:
  name: AVFAudio
  description: Bindings for AVFAudio.
  language: objc
  output: 'avf_audio_bindings.dart'
  headers:
    entry-points:
      - '/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/AVFAudio.framework/Headers/AVAudioPlayer.h'

Java/kotlin はjnigen を介した呼び出しをサポートしていますが、まだ実験段階です。

output:
  c:
    library_name: example
    path: src/example/
  dart:
    path: lib/example.dart
    structure: single_file

source_path:
  - 'java/'
classes:
  - 'dev.dart.Example'

したがって、将来、Harmony OS では、 napi gen と同様のサポートがさらに必要になるでしょう。

互換性がある

今回 OpenHarmony をサポートする Flutter コミュニティバージョンは、主に OpenHarmony 関連のオープンソースエコロジカルプロジェクトをインキュベートするために使用される組織openharmony-sigから提供されています。

さらに、openharmony 組織の下で、sig_crossplatformuiにも、Taro が主導するいくつかのクロスプラットフォームサポートプランがあります。

OpenHarmony のフラッター (OP Flutter と呼ばれる) バージョンの現在のブランチはバージョン 3.7 である必要があります。これは単なるオープンソースであるため、フラッターツールの説明は現在 Linux での使用のみをサポートしていますが、将来的にはこのリズムに遅れないようにする必要があると考えています。問題ありません。

以下の分析は、2023-09-18 の内容の一部に基づいています。将来的には必ず新しい変更が発生します。ここでは主にいくつかのアイデアと方向性を提供します。

SIG コミュニティは主に 2 つのプロジェクトに適応しています: OP flutterとOP flutter Engine . 現在の提出物によると、OP flutter は現在主に hap の構築をサポートするフラッターツールを追加しています。

環境検出を追加する
ツールの下にカスタマイズを実装しbuild_hap.dart、Hongmeng デバイスの識別などをサポートします。
create に対応する ets テンプレートを提供します

実行サポートに関しては、主に OP フラッターエンジンを通じて実装され、メインコードは対応するohos/ディレクトリに追加されます。

OPフラッターエンジンの変更内容から判断すると、主にshell/platform/androidオリジナルのコードをコピーして調整したもので、例えばGL Contextのコード部分は現状ではほとんど違いすぎています。

さらに、皆さんがもっと気になるのは、OP で Impeller がサポートされているかどうかです。現在、OP Flutter Engine には Impeller 用の特定のプリセットがあるようですが、 Flutter が Android で Impeller を正式にリリースしていないため有効になっていません。今は急ぐ必要はないようです。

フォント部分に関しては、OPのFlutterがデフォルトで使用するようですがsans-serif、これはHongmengのHarmonyOS Sansと一致するはずです。

リフレッシュレートに関しては、現時点では 60hz がデフォルトでハードコーディングされていることがわかります。将来的には、napi やその他のサポートを通じて実際のリフレッシュレートを取得できるようになるはずです。動的リフレッシュレートのサポートについて心配する必要はありません。。

なお、バージョンの問題により、OP Flutter Engineでは部分再描画操作が残されていますが、実はFlutterはAndroidでの部分再描画を正式に無効化しています、Androidでの部分再描画は問題が多すぎるため、この機能は廃止されました。直接ブロックされました。

Flutterは部分リペイントを再開する前に別途Vulkan Impellerに適応することを正式に計画しており、これはOP Flutter Engineにとっても歴史的な負担となる可能性があり、将来的にはOP FlutterもImpellerに続くものと推測されています。

もちろんプラットフォームが異なるため、OP Flutter Engineにもデータ型の変換処理など別途実装が必要なロジックがあり、Androidではshell/platform/android/platform_view_android_jni_impl.ccに相当しますが、OPでは、これは、shell/platform/ohos/napi/platform_view_ohos_napi.cppに対応します。

最後に、Flutter の適応は、埋め込みやツールの適応だけでなく、新しいチャネルやプラグインのサポートも含まれます。現在、SIG もこれに取り組んでいるようです。いくつかの一般的に使用されている、またはよく知られているプラグインコミュニティが徐々にサポートを追加する予定です。大変な仕事のように思えますが、Harmony が AOSP から脱却し、独自のエコシステムを構築する歴史的な一歩となることは間違いありません。

やっと

この記事を通して、FlutterとHarmonyの「因果関係」を簡単に理解していただけると思いますが、Flutter開発にとってHarmony Nextは比較的良い新しいプラットフォームとなるでしょう。

もちろん、これは ArkTS と ArkUI を学習できないという意味ではありません。パッケージ化された構築であれ napi であれ、Harmony プラットフォーム自体のサポートと切り離せないものであり、「すべてが学習されるのを待っている」というコミュニティ環境では、それは完全にコミュニティのサポートに依存しています。それは明らかに非現実的です。重要な瞬間に、「十分な食料と衣服を用意する」ためには「自分でやる」必要があります。

Harmony が Flutter のサポートを開始しました。Harmony と Flutter の間の原因と結果について話しましょう

関係

互換性がある

やっと

おすすめ