Flutter: プラグインフレームワークでのC / C ++との統合のサポート

@ jason-simmonsはGradleについて最もよく知っています。 .soを取得したら、ロードするのを確実に支援できます。

buildSrcの下に、gradleビルドバージョンを設定するための別のプロパティがあることがわかりました。 2.2.2にアップデートした後、私は進歩し、.soのロードを確認することができ、Javaから呼び出すことができます。

おそらく、C / C ++コードからDartにHostMessagesを送信するためのCAPIも追加する必要があります。

はい、お願いします。 C-> Javaコールバックは安くはないのではないかと疑っています。

これに関する更新はありますか？ 共有ライブラリにコンパイルされたC ++コードを呼び出すクロスプラットフォームアプリを構築するためのFlutterを検討します。これが、唯一の主要な停止点です。

これは今日可能です（そして@jtrunickは彼の出荷アプリでそうしました）が、最初にJavaまたはObj-Cを介してバウンスする必要があります。

つまり、 https：//flutter.io/platform-channels/を使用して、DartからObj-C / Javaに通信し、次にObj-C / JavaからC ++コードに電話をかけることができます。 このバグは、これに対するより直接的なサポートの追加と、Obj-C / Javaパススルーの回避の可能性をカバーしています。

DartVMはC ++で実装されているので、C共有ライブラリを直接（たとえばdlopenを介して）呼び出すためのより簡単な（安全性が低い場合）方法があるべきではありませんか？ 基本的な（安全でない/実験的な）サポートにはどのくらいの変更が必要ですか？

https://www.dartlang.org/articles/dart-vm/native-extensionsはAndroidまたはiOSで利用できますか？

この要件は、いくつかのGoogleアプリから聞いています。

• そのようなアプリの1つは、待ち時間を短縮するためにカメラを操作するための独自のC ++ライブラリを作成しました。 これらのライブラリはプラットフォーム固有であり、可能な限り迅速に動作するように最適化されています。 このようなアプリでは、可能な限り低いレイテンシでこれらのライブラリを呼び出すことが重要です。 彼らにPlatformChannel + JNIを通過させることは、Androidではそれを達成しません。

• AndroidとiOSの実装間で共有できるようにC ++でビジネスロジックコンポーネントを作成する高度なモバイルチームがあります。 これらのライブラリとの直接統合をサポートするFlutterは、そこにある最高のクロスプラットフォームフレームワークであるという立場をさらに強固なものにするでしょう。

これは_必須_ではないと思います。 ただし、これはFlutterが他のクロスプラットフォームソリューションとさらに差別化できる領域の1つです。

そのようなアプリの1つは、待ち時間を短縮するためにカメラを操作するための独自のC ++ライブラリを作成しました。 [...] PlatformChannel + JNIを強制的に通過させることは、Androidではそれを達成しません。

C ++からJavaに、そしてその逆に移行するためのAndroidでのソリューションは何でしたか？

本当に必要な場合は、モバイルプラットフォームでDartネイティブ拡張機能を許可できます。 現在、 dart_api.hのシンボルは公開していません。 スイッチを切り替える前に、次のことを決定する必要があります。

• メインのFlutterエンジンダイナミックライブラリにない可能性のあるメソッドからの唯一のエントリポイントであるDartコードをAOTコンパイラに認識させる方法を理解します。 そうしないと、ツリーシェイクパスがコードを削除する可能性があります。
• ネイティブ拡張機能の構築とパッケージ化に関するガイダンスを提供します（AndroidとiOSのそれぞれのGradleとXcode）。
• dart_api.hのルーチンにいくつかのABI安定性保証を提供します。 ほぼ安定していますが、さまざまなモードを考慮して進化していると思います。

これまでのところ、プラットフォームチャネルメカニズムは、より単純なユースケースには適切であるように思われます。

C ++からJavaに、そしてその逆に移行するためのAndroidでのソリューションは何でしたか？

私はそれらのユースケースを深く調べていません。 彼らはC ++で非常に低遅延の通信を必要とするすべてのビットを書いたようです。 パフォーマンスが重要なユースケースにJNIを使​​用しているかどうかを尋ねます（私の直感は違います）。

それは本当にFlutter側で何ができるかにかかっています。 JNIよりも大幅に高速な相互運用機能を提供できれば、これらのチームにとって大きな勝利になります。 C ++コードベースを縮小し、アプリ側にシフトすることができます。 相互運用のパフォーマンスがJNIに匹敵する場合、ここでは大きな勝利は見られません。 彼らはおそらく、現在行っていることを継続し、PlatformChannelを使用することができます。

これは、そのようなチームにFlutterに切り替える特別な理由を与えることです。 これがブロッカーであるとは聞いたことがないので、それに応じて優先順位を付けてください。

あなたの言っていることが正しく理解できれば、現在の解決策は、Javaの最小限のロジックでC ++のすべてのロジック（カメラ+ UI）を使用することであり、このロジックのUI部分をDartに移動することが望まれます。低レイテンシのUI <->カメラの双方向性を失うことなく。

彼らの糸脱毛の状況について話していただけますか？ Camera + UI用のスレッドは1つだけですか？

@chinmaygardeは、

+1

この問題の進展はありますか？

すでにdjinniを使用して、さまざまなプラットフォーム間でロジックを共有しています。 Java / Objc-Cを行き来するのではなく、DartとC ++の間で相互運用ができれば素晴らしいと思います。

DartがC / C ++と統合できる場合、モバイルが大量のネイティブライブラリを再利用し、JNIまたはObjective C ++を使用して特定のプラットフォームにバインドする必要がないことは素晴らしいアイデアだと思います。

https://github.com/mono/CppSharpを検討しました

RealmのようなC ++ベースのデータベースをC ++に直接統合すると、パフォーマンスが大幅に向上し、開発者の生産性が向上します:-) JNIを上下に移動するのは無駄です。

コンピュータービジョン（おそらくOpenCVを使用）を実行するARアプリのFlutterを検討しています。効率的で直接的な、Dart-C ++相互運用機能が大きなプラスのポイントになります。 計算の面でやりがいのあるアプリをやっている他の多くの人々がこのニーズを共有するかもしれないと想像します。

誰かがC ++相互運用機能がまだ利用できないことを確認できますか？ パッケージを使用して実行できますか？

@tofutim Direct c / c ++相互運用機能はまだ利用できないため、この問題がまだ発生しているのはなぜプラットフォームチャネルを使用してから、Obj-C / Javaを使用してC ++コードを操作することができます。 それは素晴らしいことではありませんが、現時点で私たちが持っているすべてのものです。

誰かがC ++相互運用機能がまだ利用できないことを確認できますか？ パッケージを使用して実行できますか？

プラットフォームライブラリと相互運用するために、プラットフォームチャネルメカニズムが現在の推奨事項です。

ネイティブ拡張機能のドキュメントで説明されているよりパフォーマンスの高いメカニズムを簡単に追加できます。 ただし、 dart_api.hから公開されたシンボルのABI安定性の保証については知りません。 @ a-sivaと@eseidelGoogleがそのような保証が存在することを確認できれば、私はそれらのシンボルをTonicのサブセットを作成できます。

私の理解では、このバグは、完全にC / C ++プラグインを簡単に作成できるようにするためのC-APIとツールフックの提供に関するものです（Obj-C / Javaシミングは必要ありませんが、platform_channelsを介して非同期です）。

現時点では、ネイティブ拡張のような同期メソッドを検討する必要はないと思います。 （しかし、正直なところ、私はそれを@Hixieまたは@cbrackenに任せています）。

@eseidel

現時点では、ネイティブ拡張のような同期メソッドを検討する必要はないと思います

何故ですか？

Cコードを呼び出す現在のアプローチは、 Dart -> Java -> C
JNIを2回横断しますよね？
初回：プラットフォームチャネル経由でdartからJava （内部では
2回目： JNI経由でJava -> C

例として、私のプロジェクトのニーズの観点からは、安定性の保証がなくても（たとえば実験的な機能として） dart_api.hアクセスできれば、すでに十分です。 私の主な関心事は、バイナリデータ（画像）の大きな塊をダート側からC側に移動し、マーシャリングや理想的なコピーを行わずに元に戻すことです。 Unity / Monoはそれを実現します。

dart-sdkの問題31960から、現在の分離の実装ではコピーせずにデータを渡すことができない場合があることを理解しています（ただし、理論的には、分離Aで作成されたバッファーが分離Bに渡された後は使用されなくなったことを検出できるはずです。したがって、その所有権はコピーせずに譲渡できます。その前に計画はありますか？）が、少なくとも分離内でCとの間でマーシャリングがない場合は、それは良いことです。

マーシャリングは、間もなく着陸するように見えるフラットバッファーで回避できます： https ：
または、1バイトのみのフィールドを使用するprotobufメッセージを使用します。

もちろん、これには大量のバイトコピーが必要になるため、すべてのユースケースに適しているわけではありません。

私はここに提示された少なくとも3つの異なる欲求を聞いています：

1. Java / Obj-C接着剤を大量に追加することなく、C / C ++コードのみを使用してFlutterのプラグインを簡単に作成する方法が必要です（これは、このバグについての私の最初の理解であり、私たちができる/すべきだと確信しています） 。
2. 大量のデータをDartにすばやく出し入れする方法/低レイテンシで移動する方法などが必要です。 （おそらく、C ++を含むさまざまな言語からのものです。これは非常に有効なケースのようです！例を含む別のバグを提出することを強くお勧めします。）
3. 同期呼び出し/オブジェクトを使用してDartを拡張する方法が必要ですか？ （たとえば、ネイティブ拡張機能やその他の方法？これも完全に実行可能です。APIの安定性に関して潜在的な問題があります。アクションを実行する前に、特定のユースケースについて詳しく知りたいと思います。）

上記を読んだことからの私のフィードバックは、いくつかの追加のバグを分割することを検討する必要があるということです。 確かにC ++相互運用機能にいくらか投資する必要がありますが、この長いスレッドから、どの正確なユースケースにどのような順序で対処する必要があるかを判断するのは困難です。

利害関係者は、希望するユースケースで新しいバグを報告し、それらをここにリンクすることをいとわない/可能でしょうか？ この問題領域への一般的な関心を追跡するために、この問題を開いたままにしておいてください。

パフォーマンスと2.上記に関して：Flutterのplatform_channelsのパフォーマンスは改善される可能性があると確信していますが（すべてのユースケースをカバーするために他のプラグイン/相互運用メソッドが必要になる可能性があります）、具体的なものが必要になりますFlutterのplatform_channelsのパフォーマンスが、アクションを実行する前のボトルネックであるユースケース（おそらくそれらは存在し、私はそれらを見たことがありませんか？）。 システムのパフォーマンスを最適化した私の経験では、私の本能はしばしば間違っています。 JNIやplatform_channelsのようなものは潜在的なボトルネックのように感じますが、実際には測定するまでわかりません。

皆様のご協力とフィードバックに改めて感謝いたします。

Java / Obj-C接着剤を大量に追加することなく、C / C ++コードのみを使用してFlutterのプラグインを簡単に作成する方法が必要です（これは、このバグについての私の最初の理解であり、私たちができる/すべきだと確信しています） 。

それはまた、フラッターのためのより良いsqlite統合を与えるでしょう+暗号、sshおよび他のもののためのたくさんのC / Rustライブラリがあります。 それを簡単に使えるといいですね。

@eseidel

少なくとも3つの異なる欲求が提示されていると聞いています

私の1への投票。）

Flutterのドキュメントを読むと、Cをサポートするようにプラットフォームチャネルを拡張するのはかなり「簡単」なはずです。
唯一の斬新なことは、おそらく_動的共有オブジェクト_を現在のプロセスにロードする方法でしょう。

_Android-C_-usageは次のようになります。

#include <ndk-version.h>
#include "methodchannel.h"
#include "methodchannels.h"

MethodChannel* flutter_channels;

__attribute__((constructor))
void
on_library_load() {
    flutter_channels = NULL;
}

__attribute__((destructor))
void
on_library_unload() {
    while (MethodChannel* channel = MethodChannels_pop(flutter_channels)) {
        MethodChannel_delete(channel);
    }
}

#define str(a) #a

void
{{pluginClass}}_on_method_call(MethodCall* call, Result* result) {
    if (strcmp("getPlatformVersion", call.method) == 0) {
        Result_success(result, "Android " str(__NDK_BUILD__));
    } else {
        Result_not_implemented();
    }
}

void
{{pluginClass}}_register_with(Registrar* registrar) {
    MethodChannel* channel = MethodChannel_new(Registrar_messenger(registrar), "{{projectName}}");
    flutter_channels = MethodChannels_push(flutter_channels, channel);
    MethodChannel_set_call_handler({{pluginClass}}_on_method_call)
}

概念的には、少なくとも_Android-C_の場合、JavaとCの組み合わせを処理する方法を決定する必要があります。

@eseidelGoogle
現在、JavaおよびSwiftラッパーを介してgolangコードを公開しており、レイテンシーは私たちが直面しているかなりの問題です。
どうして ？

• 多くのプラットフォーム間でビジネスロジックを共有する必要があります。
• 画面共有などのビデオおよび画像機能用。
• DBの場合。

あなたが直接レベルでgolangサポートを追加することができれば、それは抱擁の違いを生むでしょう！
モバイル用のgolangコードのコンパイルも、LDFLagsの魔法がなくても非常に簡単なので、人気があると思います。 現在メソッドチャネルを使用している他のいくつかのgolangコーダーも知っています。
シリアル化に関しては、現在Protobufsとflatbuffersを使用しています。

例：
https://github.com/dnfield/flatbuffers/blob/master/samples/sample_binary.go

フクシアでは、これはFIDLで行われ、c、rust、golangにバインドされています。
使い方はとても素晴らしく、埋め込みボードで錆やゴランを試して楽しんでいます。

iOSとJavaを介してfidlのものを公開することも可能であるはずです。
それは、モバイルとデスクトップでのフクシアとフラッターの間の素晴らしいランプを与えるでしょう。
私が遊んでいるだけのアイデア

@eseidelGoogle
Hiixeは、FIDLはフクシアのジルコンのカーネルコードに依存しているため、FIDLをFlutterレベルで実行することはできないと私に言いました。 したがって、Flutter内でFIDL IPCスタイルの機能を複製する唯一の方法は、FIDLバージョンをFlutterエンジンに書き込むことです。 しかし、それから私はそれで遊んでいて、それがフラットバッファーに非常に似ていることに気づきました。 だから、FlutterとFlutterのcppまたはgolangまたはrustレイヤーの間のシリアル化レイヤーにFlatBuffersを使用しないのはなぜですか？ ？

これに+1するだけで、Superpoweredというライブラリを使用したフラッターアプリができます。 SuperpoweredはC ++で記述されており、JavaおよびJNIタイプのものを使用して対話し、プラットフォームチャネルを使用してJavaコードと通信します。 仲買人を飛ばせたらいいのにと思います。

これはさらに、Realmのような人気のあるモバイルライブラリのコアがC / C ++で記述されており、java / objc / swiftの仲介者を扱いたくないため、フラッターバージョンの作成を妨げています。

これらの理由から、一般的な安定性は別として、この問題は現時点で最も必要なフラッターの変更の1つだと思います。 （より具体的には、 @ eseidelGoogleのリストで1位です。）

プラットフォーム拡張機能でJava / JNIをバイパスする（つまり、開発者のためにJavaグルーレイヤーを非表示/自動化するだけではない）という議論を聞きたい場合は、Superpoweredがそのトピックについて多くのことを述べています： https ：

@pnico Java / JNIをバイパスする必要があるとこれがどのように主張しているのか説明できますか？ オーディオ処理コードはC ++で記述されるべきだと言っているようです。 （これは、JNIまたはその他の手段で呼び出すことができないという意味ではありません）

@ csga5000あなたは完全に正しいです、それは意味がありません：D JNIは、もっと難解なことをしようとしない限り、おそらくパフォーマンスに実際に影響を与えることはないでしょう。 それは本当に利便性/保守性に帰着すると思います。おそらく、よりアプリ固有のコードをJava / C ++からDartに移動する機能があると思います。

@pnicoは、JINIを介して呼び出すことができると言っていると思いますが、JINIはレイテンシーを追加しすぎます。
したがって、パフォーマンスが問題です。
はい・いいえ ？？

これは、主に暗号関連の作業に大きな違いをもたらす可能性があります。

また、私はAndroid Thingsを想定していますが、実験を見たり行ったりしたことはありません。
およびcでもdartでもないタイミングセンシティブgpioのベンチマーク
年。

2018年6月9日土曜日、10：52 Eddy WM、 notifications @ github.comは次のように書いています。

これは、主に暗号関連の作業に大きな違いをもたらす可能性があります。

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/flutter/flutter/issues/7053#issuecomment-395927258 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AFHMcSI2JDHbgv3iYrStDN5mlzkQ8XEkks5t6xxMgaJpZM4K-PLw
。

それ以来、何か進展はありますか？

これが解決されるまで、ac / c ++ libを統合する方法を示すフラッタープラグインの例に関する推奨事項はありますか？ ジンニは

それが解決されるまで、ネイティブのandroidおよびiosコードを記述してc / c ++を統合し、プラットフォームチャネルを使用してdartコードにインターフェイスする唯一の方法

プラットフォームチャネルを使用するプラグインを実装しました（jarファイルとCocoaPodsに）。 同じc / c ++ lib（androidとiosの両方）に統合する方法を示すプラグインの例を探しています。 何かお勧めはありますか？

@ mmcc007これは、Javaまたは

Java： https ： + use + C％2B％2B＆sourceid = opera＆ie = UTF-8＆oe = UTF-8

Swift： https ：

例が本当に必要な場合は、superpoweredがどのようにそれを推奨するかを確認できます（これは私が知っているものです）： https ：
サンプルフォルダを参照してください。 例：https：//github.com/superpoweredSDK/Low-Latency-Android-iOS-Linux-Windows-tvOS-macOS-Interactive-Audio-Platform/tree/master/Examples_Android/SuperpoweredRecorder/app/src/main内にcpp /RecorderExample.cppのコードを参照するjava / com / superpowered / recorder / MainActivity.java

@ csga5000最初のレビューではかなり簡単に見えるようです。 それでも、動作しているフラッタープラグインを調べてみるといいでしょう。 ありがとう。

このために+1。 C ++を使用したフラッターアプリの実用的な例は好評です

golangに対してこれを行うプロジェクトがあり、同じアプローチだと思います
C ++にも使用できます。

golangプログラムはjsonrpcを使用します。
次に、あなたがする必要があるのは、jsonrpcであなた自身のgolangコードを前に出すことです。

そうすれば、すべてがとても簡単です。

プラットフォームチャネルは、不可知論的なシリアル化としてJSONのみをサポートしていると思います
フォーマット ？

2018年7月18日水曜日、16：50 Jefferson Bledsoe、 notifications @ github.com
書きました：

このために+1。 C ++を使用したフラッターアプリの実用的な例は次のようになります
好評

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/flutter/flutter/issues/7053#issuecomment-405958345 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ATuCwkPbb9vLdoaEwM-bLhYPZxtyQ5Vjks5uH0sqgaJpZM4K-PLw
。

こんにちは、何かニュースはありますか？

このスレッドの誰かがSuperpoweredライブラリをフラッターアプリに直接統合したかどうかを知りたいだけですか？

はい@ skills-up私たちはそれをしました。 オープンソースプロジェクトではないので、表示できません。 しかし、以前に私のヒントを見た場合は、それがあなたのやり方です。 ただし、CPUアーキテクチャごとにフラッターアプリを作成する必要があるかもしれません。

Dartから直接ではなく、JNI / Javaを介して行ったことを理解しています。 プラットフォーム固有のコードを完全に回避することは可能かどうか疑問に思いました。

ただし、CPUアーキテクチャごとにフラッターアプリを作成する必要があるかもしれません。

アーキテクチャごとに個別のアプリを意味しますか、それともサポートされているすべてのアーキテクチャを指定するだけですか？

ところで、私たちはすでにJavaでネイティブに書かれた動作するアプリを持っています。 ただし、iOSアプリも作成する必要があるので、（Swift / XCodeに労力を費やすのではなく）フラッターで作成する方が、単一のコードベースの利点を活用して、将来の保守性の観点からより理にかなっているのではないかと思いました。

良い。 レルムは皆さんが方法を提供するのを待っています： https ：

lukaspili：みんながまだ待っていると思います：flutter / flutter＃7053
bmunkholm： @lukaspiliはい、それは確かに前提条件です。

その価値のために、私もこれを待っています。 あなたたちが適切な配管を手に入れるまで、XFアプリをフラッターディットに置き換えることを実際に検討することはできません。 現在のところ、Xamarinはこの部門の水から羽ばたきを吹き飛ばしています。

このパーティーに遅れましたが、このスレッドには大きな+1があります。

私はデスクトップアプリを開発しています。私の見解はコード行として（デスクトップ用）：

Flutter - Dart + C++ > Qt ? partyTime() : makeDoWithElectronOrQt()

FlutterがC ++のファーストクラスのサポートを提供できれば、「モバイルファースト」だけでなく、世界初のクロスプラットフォームアプリケーション開発の絶対的な勝者になる可能性があると思います。 Qtは小規模な開発者にとって高価であり、意見があり、最新のC ++を採用しておらず、実際に競合するものはありません。FlutterはUIパイの少なくとも一部を食べ​​ることができますか？

PS：私は反ダートではありません、それは別の新しいC＃/ Go / Rust / etcです。 新しいプラットフォームにとっては非常に生産的かもしれないが、高性能デスクトップ（ここで私の興味）アプリケーションの世界はしっかりとC ++であり、広範なOSとライブラリのサポートを備えた競合言語であり、それ自体がノットの速度で進歩している言語です（そうではありません） C）、そして私はFlutterがそれに値すると思います！

近い将来、フラッターがC ++をサポートすることはないと思いますが、現在は確かに不可能です。 そして、私はDartを非常に好みます-フラッターを使用してもC ++でアプリを作成するには、さらに多くの労力が必要になります。 そして、C ++がデスクトップサポートに直接変換されるとは思いません。それでもかなりのコードを記述する必要があり、dartVMはとにかくデスクトップで機能するはずです。 ほとんどのアプリケーションでパフォーマンスはごくわずかだと思います。

結局、グーグルは相互運用性をサポートしたいと思っているので、サポートされている言語またはその言語の組み合わせを使用して、すべてのプラットフォーム用のフラッターアプリを作成できます。 しかし、フクシアがリリースされたとき、またはリリースされた後になるまで、私はそれを期待していませんでした。 今のところ、彼らの目標は、コードを一度簡単に記述できるようにすることです。 ダーツは、使いやすく、学習しやすく、効率的で、とにかくグーグルの言語の1つであるため、その目標に一致します。 ファーストクラスのC ++をサポートしているという平均的なユーザーにとって、実際的な利点はほとんどありません。 モバイルアプリのパフォーマンスはごくわずかであり、C ++を使用したプラットフォームチャネルを使用すると、既存のC ++ライブラリを使用して対話する場合に便利です。 明るい面では、彼らが最終的にデスクトップをサポートするためにフラッターを意図していることを確信できます（少なくともフクシアのカピバラですが、そこで止まるとは思えません）。

このスレッドは、dart / flutterからのC ++との直接統合のサポートに関するものであり、近い将来に登場する可能性があります。

flutterがC ++をサポートするとは思わない
ファーストクラスのC ++をサポートしているという平均的なユーザーにとって、実際的な利点はほとんどありません。

Flutter / DartがC ++に対してどれほど優れているかではなく、現在のエコシステムに適合するために必要な統合のポイント/容易さについてです。 業界標準である共有オブジェクト（名前を挙げればOpenCV）としてライブラリの長いリストが存在しますが、人々がDartでそれらを書き直すことを期待することはできませんか？

モバイルアプリのパフォーマンスはごくわずかであり、C ++を使用したプラットフォームチャネルを使用すると、既存のC ++ライブラリを使用して対話する場合に便利です。

まったく逆に、このコンテキストではチャネルの使用は最適ではありません。メモリ（画像）上の大きなバイナリオブジェクトを操作する必要があるユースケースについて考えてみてください。次のいずれかが必要になります。
1-これらのバイナリをC ++メモリとの間でコピーします
2- JNIと連携して、ライブラリーとインターフェースします（そして、これらのバイナリーに動的に割り当てられたポインターを処理します）
チャネルを使用することによって発生する値/パラメータのシリアル化/逆シリアル化のオーバーヘッドについては言及していません。

優れたフレームワークは、それが導入する新しい機能/パラダイムと、C ++がその一部であることを否定できない現在のエコシステム/レガシーとの統合がいかに簡単かの間のバランスです。

@nhachicha @ csga5000は、C ++を直接統合することが重要であることに異議を唱えていませんでした。 彼は、Dartコードを必要とせずに、FlutterをC ++から直接使用できるかどうかを尋ねる以前のコメントに返信していました。

モバイルアプリのパフォーマンスはごくわずかであり、C ++を使用したプラットフォームチャネルを使用すると、既存のC ++ライブラリを使用して対話する場合に便利です。
@nhachichaこれ以上同意できませんでした。

真実は、歯を噛むパフォーマンスを必要としないアプリケーション（多くあります）のためのものです。それなら、マスターするのが難しいC ++をより生産的なものに交換してみませんか？ Dartよりもはるかに人気のある/確立された）言語：

• C＃/。NetCoreランタイム
• Javascript / Typescript V8ランタイム（その時点ではほとんどブラウザーがありますが、それは何ですか）
• さび（これも速い！）
• GoLang
• Python
• [ここにお気に入りを挿入] ...

そして、私が個人的にこれらの言語のいくつかを毎日愛し、使用しているのと同じように、CとC ++はLinuxのコアであるため、Android、iOS、およびWindows、MacOS、その他のデスクトップなどのデスクトッププラットフォームです。 上記の言語の半分（Dartを含む）はC ++で書かれています。 最先端のテクノロジーには、AI（TensorflowはC ++、Caffe C ++、PytorchはPythonではCなど）、Augmented Realityライブラリ、AAAゲームエンジン、GPU（CUDA）に近づく必要があるものなど、調整されたネイティブパフォーマンスが何度も必要です。 、C / C ++から呼び出されます）。

Flutterレンダリングエンジン自体がC ++ （ネイティブ、高性能、バッテリー/メモリ/ CPU効率）で

_補足として、フォームの検証からピクセルシェーダーまで、すべてをC / C ++で書くことに完全に慣れていますが、それがこのリポジトリを見ている多くの人々の見解であるふりをしているわけではありません-それはC ++を見つけたからです生産性の高い言語-しかし、完全に個人的な選択です。_

これが、C ++統合が必要な主な理由の1つです。

https://github.com/realm/realm-object-server/issues/55

C / C ++統合を実現するには2つの簡単な方法があります。

• C ++でメソッドチャネルの実装を提供する
• DartVMネイティブ拡張サポートを提供する

残念ながら、これらの両方には、私たちがそれらを追求することを妨げる大きな欠点があります：

• メソッドチャネルはオーバーヘッドの高い抽象化ですが、オーバーヘッドの低い相互作用が望ましい場合は、C / C ++統合が要求されます。 つまり、メソッドチャネルは実際には問題を解決しません。
• Dart VMネイティブ拡張機能では、Dart VM C APIを使用する必要があります。特にAPIが十分に古くなく、深刻なリファクタリングが必要であるという事実を考えると、外部依存関係をあまり多く導入することは望ましくない場合があります。

より望ましい代替案は、 dart:ffi導入であるように思われます。これは、ネイティブコードに直接バインドできるようにする、Dart VMのコアコンポーネントであり、次のような記述を可能にします。

import 'dart:ffi' as ffi;

// Bind foo to symbol _foo from library libxyz.so with signature
// int32_t (int32_t, double, char*).
@ffi.import("libxyz.so", name: '_foo',
            signature: ffi.Signature(ffi.Int32, [ffi.Int32, ffi.Double, ffi.PChar]))
extern int foo(int foo, double x, String foo);

私たちはこのようなFFIを長い間実装することにある程度の関心を持っていました。近い将来、このFFIを試すことを期待していますが、具体的なスケジュールについては確約しません。

@ kirbyfan64は正確に右、@nailgilazievは、@bytesoftly私はちょうど私がダーツのフラッターサポートC ++ INPLACEを作るために、その多くの理由/需要がないと思うと言っていた、C ++統合が必要とされていないと言うしようとしていないよされています-しかし、統合が必要ないと言っているのではありません。 @mralephが言っていることは、私には賢く聞こえます。

@mralephDartinoにはFFIの同様の実装がありました。 復活するのはどれほど難しいですか？

@listepoの一部です。 DartinoのFFIの実装は非常に動的でした。これは、Dart1よりもかなり静的なDart2に必要なものではありません。

ゲームの後半ですが、別のユースケースがあります。暗号化の目的で、cファイルとメソッドをdartに含めたいと思います。

私たちが望んでいるのは次のとおりです。
1）iOSとAndroidで同じコード。つまり、ObjCまたはJNIレイヤーを通過しません。
2）うまくいけば、たとえばJNIを2回実行する場合よりも効率的な実装です。
3）AngularDartなどのフォローアップWebアプリ、またはこのプロジェクトを使用したフォローアップデスクトップアプリでdartモデルコードを再利用する可能性： https ：

私たちが欲しいものは、上記のポイント2 @ eseidelGoogleに最も近いと思います。 同期サポートに関しては、非同期関数をコンストラクターで使用できないため、「持っていると便利」だと思います。コンストラクターでは、クイックハッシュ計算などを実行する必要があります。 しかし、ダーツの非同期的な方法に慣れると、同期サポートは、上記のポイント1）〜3）を達成するための一般的な可能性ほど重要ではないように見えます。

@mralephによって提案されたようにFFIを使用すると、これは私の前のコメントのように1）-3）を可能にしますか、それとも異なるプラットフォーム（Android、iOS、...）で異なるコードが必要であることを意味しますか？

@CryptUser C / C ++コードがすべてのプラットフォームで同じである場合、FFIを介して呼び出すためのDartコードもすべてのプラットフォームで同じになります。

@mralephいいですね！ 元の問題の賛成が200を超えていることを考えると、これを優先する機会はありますか？

@mraleph DartのどこかにFFIの未解決の問題がありますか？

@dnfield私はちょうど今1つを提出しましたhttps://github.com/dart-lang/sdk/issues/34452

C / C ++ / Rustコードを記述して、ffiで使用できるようにしたいと思います。

例：

Androidタブレット（Android 4.4）でフラッターをテストします。
フラッターはすぐに実行されます。
しかし、プラットフォームチャネルを使用するsqfliteで1000行を読み取ろうとすると、ばかばかしいほど遅くなります。
理由：sqliteカーソルリーダーを使用できません。

しかし、sqliteライブラリを直接使用できれば、同じクエリがすぐに実行されます。 （xamarinとネイティブandroidプロジェクトでテスト済み）。

現在、これに取り組む最善の方法について話し合っています。 上記のhttps://github.com/flutter/flutter/issues/7053#issuecomment-377711814で述べたように、この問題には多くの部分があり、おそらく分割する必要があります。 :)

しかし、FFIの調査に関心のあるエンジニアが何人か見つかりました（https://github.com/flutter/flutter/issues/7053#issuecomment-415161464に記載されています）。 現在の焦点は1.0を公開することですが、それが完了すると、これはリストの上位になります。 今後ともよろしくお願いいたします。 共有する進捗状況がさらに進んだら、この問題を更新します。

私はMatlab / Simulinkユーザーでもあります。 高度に最適化されたcpu固有のc / cppコードを生成できます。 アルゴリズムをフラッターに統合したい。 私はたくさんの画像処理アルゴリズムを持っています。 ネイティブコード用のバインディングジェネレータが必要です。 そうしないと、ダーツフラッターの経験をすべて忘れてしまい、xamarinまたは自分に合ったものを学び始めます。

進捗をスピードアップできますか？

DartとCの間で相互運用するのは、非常に大きな苦痛です。

プロセスを急ぐことは、高品質の製品をもたらす可能性は低いです。 準備ができたら準備ができています。 :-)

プロセスを急ぐことは、高品質の製品をもたらす可能性は低いです。 準備ができたら準備ができています。 :-)

さて、私が言おうとしたのは、これを解決するためにより多くのリソースと労力を費やすことができるように、優先順位を上げたいと思うかもしれないということでした。 「今後数年間で修正される」「目標」をターゲットにした現在、1386の未解決の問題があることをご存知でしょう。

スレッドをもう一度読んだ後、 @ eseidelGoogleが、

「ゴール」は間違ったバケットである可能性があります。 :) @mralephには、私たちが話しているようにhttps://github.com/dart-lang/sdk/issues/34452を探索している人がい

これは、現在Dart側でプロトタイピングしているFFIの

ご覧になり、ご意見をお聞かせください。

私はそのようなものを使ったことがないので、FFIの部分についてはあまり言えません。
しかし、私はパブの統合がどのように見えるのか疑問に思っています。

FFIを利用するパブリッシングパッケージはどのように処理されますか？
FFIを使用する消費パッケージはどのように処理されますか？

@zoechi pub統合についてはまだ説明していません。

それらは今日のFlutterプラグインと同様に機能するはずです-消費するアプリケーションにコンパイル/リンクできるプラットフォーム/アーキテクチャの適切なソースおよび/またはバイナリを含みます。

パブの観点からは、それは大したことではないはずです-パッケージに含まれているより大きなバイナリファイルがあるかもしれないことを除いて。

それらをFlutterプロジェクトに統合するには、Flutterツールの終わりを中心にいくつかの作業を行う必要があります。これらは、現在のAndroid / iOSプラグインとまったく同じようには機能しません。

この問題をより焦点を絞った状態に保つために、pub-integrationをdart-lang / pubの問題に移動する必要がありますか？

「visiondoc」を読みましたが、ようやく霧の中から形が見えてきました。

その間、私はもっと違うことを考えていました。

つまり、 Flatbuffersを（再）使用して

メッセージパッシングアプローチも、現在のストリームベースのアーキテクチャ（Bloc、Rx）とより一致しています。 コンパイラは適切な場合に適切なリングバッファを生成したり、呼び出し先がデータをより長く保持する必要がある単純な「呼び出し先の解放」を想定したりする可能性があるため、メモリ管理に関する懸念もなくなります。

しかし、正直に言うと、Flutter（Fuchsia）エコシステムにシームレスに統合され、Dartアプリ内からCPUに最適化されたネイティブコードを使用できるようになる場合は、あらゆる形式のffiを称賛します。

@ohirあなたが想像していたことは、バグとして提示された問題のいくつかに対する別の解決策になるでしょう。 このバグは、C ++に関連するあらゆるものの汎用キャッチオールに進化しました。 ：/（以前のコメントで述べたように）このバグをより小さなものに分割する必要があると思います。 FFIの作業は、この分野で構築する唯一のソリューションではない可能性があります。

@eseidelGoogleこれに関する進展はありますか？ 現在、ffmpegを介して実行される可能性のある重いビデオ処理タスクを実装するプロジェクトがあります。現在のdartパッケージは実行可能なソリューションを提供できないため、フラッターがffmpeglibを直接呼び出すのを熱心に待っています。

これらのページ間UIベースのアプリの場合、AndroidとiOSの両方でダブルコーディング作業を行うよりも、フラッターが本当に良い選択だと思います。5年前にこのような素敵な機器を使用していた場合、アプリ業界全体が変更されます。 ただし、現在のフラッターの利点は、以前の方法ですでに十分に機能しているため、フラッターに移行する企業にとって息をのむようなものではありませんが、UI以外のタスクでは、ダーツが最上位の要件よりもはるかに遅れています。

ダーツがこれらのタスクに適していない、または実行可能でないことを意味するわけではありませんが、フラッターエコシステムに含まれる可能性のある通常のIT企業の観点から、必要なのはクロスを使用してコストを削減することです。プラットフォームコーディング方法は、クライアント側のデータ処理、ビデオ/オーディオ、ARスタッフなど、c / c ++を介してすでに実行されているアルゴリズムがあれば、最も優れた機能を実現できる場合に限ります。 彼らがダートラングを使用してそれを再実装または再発明することは本当に難しいです。

重要な解決策は、フラッターがc ++と通信するための直接的かつ効率的な方法を導入することです。これは「クロスプラットフォーム」のものの最優先事項であるとさえ思います。UIスタッフ向けのダーツは完璧であり、通常のデータロジックも可能です。ダーツで行われますが、フラッターは、聖なる新しいものを再構築するよりも、長くてもアクティブで効率的なc ++エコシステムにマージする方がはるかに優れています！

本当の「クロスプラットフォーム」コーディング体験の夢は、C ++を内部に持ち、Javaコードをまったく使用せず、ocコードをまったく使用しないdartUIスタッフです。 わはは、それが起こるのが待ちきれません！

@smellbee ffmpegコマンドラインを使用できませんか？

@smellbee私は偉業です私はこれに答えるのにふさわしい人ではありません。 @eseidelGoogleこれに関するニュースはありますか？

@smellbee ffmpegコマンドラインを使用できませんか？

これはクライアント側の作業であり、ffmpeg libを使用してビデオフレームをレンダリングし、インスタントフィードバックストリームを生成します。コマンドラインを使用することは可能ですか？

@smellbee私は偉業です私はこれに答えるのにふさわしい人ではありません。 @eseidelGoogleこれに関するニュースはありますか？

申し訳ありませんが、「es」と入力すると、自動的に完了しましたが、気づきませんでした。 @ eseidelGoogleに表示されることを願っています。

ダート側で作業が進行中です。2019年第1四半期に準備が整うことを望んでいます。

これは大きな機能であり、正しく機能させたいと考えています。Dartのさまざまな実行モードでうまく機能させたいので、詳細を検討する際はご容赦ください。

Dart側の作業を追跡するdart-lang / sdk＃34452をフォローできます。

Dart FFIを使用すると、DartからC関数を呼び出すことができます。
しかし、C ++の機能（クラス、標準コンテナー、スマートポインター、例外）についてはどうでしょうか。
最小限のボイラープレートでC ++クラスをDartにエクスポートする可能性を期待できますか？

もう1つの非常に重要な機能は、非同期サポートです。別のスレッドでC ++コードを実行し、メソッドからFuture / Streamを返す機能です。

@ t-artikov C ++の相互運用性を直接サポートする現在の計画はありません。 これは複雑すぎます。 人間工学的にC ++と相互運用できるのは、C ++だけです。

C ++との高レベルの相互運用に関心がある場合は、APIのようなCを介してC ++ APIを公開する独自の相互運用レイヤーを構築する必要があります。

もう1つの非常に重要な機能は、非同期サポートです。別のスレッドでC ++コードを実行し、メソッドからFuture / Streamを返す機能です。

これはパッケージとして構築できると思います。 これを構築できるように、適切なプリミティブを提供することを確認する必要があります。

Dart FFIを使用すると、DartからC関数を呼び出すことができます。
しかし、C ++の機能（クラス、標準コンテナー、スマートポインター、例外）についてはどうでしょうか。
最小限のボイラープレートでC ++クラスをDartにエクスポートする可能性を期待できますか？

C ++がダーツを呼び出す方法がある限り、それらは可能だと思います。C++は、C ++が心配していることを処理し、呼び出されたり呼び出したりすることでダーツと通信します。低レベルの操作を公開する必要はありません。ダーツの使いやすさを損なうダーツ。

もう1つの非常に重要な機能は、非同期サポートです。別のスレッドでC ++コードを実行し、メソッドからFuture / Streamを返す機能です。

また、dartにはすでに非同期メカニズムがあるため、スレッドがC ++指向であるかどうかに関係なく、C ++部分が必要なときにいつでもdartを呼び出すことができ、「Isolate」がその役割を果たします。

それは私が@mralephだと思うものです、私が間違っているなら私を訂正してください;）

@mraleph
実際、他の言語との優れたC ++相互運用の例があります。
https://github.com/boostorg/python
https://github.com/ThePhD/sol2
https://github.com/dropbox/djinni
Dart / Flutterが箱から出して同様のメカニズムを提供することを願っています。

C ++との高レベルの相互運用に関心がある場合は、APIのようなCを介してC ++ APIを公開する独自の相互運用レイヤーを構築する必要があります。

このアプローチがどのように適用できるかを明確にするために、例として次のС++クラスを使用してそれを示してください。

struct MyObject
{
    std::string name;
    std::vector<int> data;
};

class MyService
{
    // Can throw std::exception
    std::shared_ptr<MyObject> createObject(std::string name, std::vector<int> data);
};

Dartから使用できるように

var service = MyService();
var object = service.createObject("foo", [1, 2, 3]);
assert(object.name == "foo");
assert(object.data[0] == 1);

@ t-artikov boostorg::pythonとsol2両方が、実際に私のポイントを非常によく示しています。 これは他の言語と相互運用するためのC ++ライブラリであり、その逆ではないことに注意してください。 Dart FFIは、C APIを呼び出すDart中心の方法であり、Dartを呼び出すC ++中心の方法ではありません。

このアプローチがどのように適用できるかを明確にするために、例として次のС++クラスを使用してそれを示してください。

このようなものを書く（または何らかのツールで生成する）必要があります。

// To be compiled together with your code.
typedef std::shared_ptr<MyObject>* MyObjectPtr;

MyService* MyService_create() {
  return new MyService();
}

void MyService_destroy(MyService* ptr) {
  delete ptr;
}

MyObjectPtr MyService_createObject(MyService* ptr, const char* name, int* data, size_t size) {
  try {
    return new std::shared_ptr<MyObject>(createObject());
  } catch (...) {
    return nullptr;
  }
}

const char* MyObject_getName(MyObjectPtr obj) {
  return (*obj)->name.c_str();
}

int* MyObject_data(MyObjectPtr obj) {
  return (*obj)->data.data();
} 

void MyObject_destroy(MyObjectPtr obj) {
  delete obj;
}

// To be included on the Dart side.
@ffi.External()
external Pointer<Void> MyService_create();
@ffi.External()
external void MyService_destroy(Pointer<Void> ptr);
@ffi.External<Pointer<Void> Function(Pointer<Void>, Pointer<Void>, Pointer<Void>, Int32)>()
external Pointer<Void> MyService_createObject(Pointer<Void> service, String name, Int32List data, int size);
@ffi.External()
external String MyObject_getName(Pointer<Void> obj);
@ffi.External()
external Pointer<Int32> MyObject_data(Pointer<Void> obj);
@ffi.External()
external void MyObject_destroy(Pointer<Void> ptr);

class MyService {
  final Pointer<Void> _impl;
  MyService() : _impl = ffi.anchor(MyService_create(), MyService_destroy);

  MyObject create(String name, List<int> values) {
    final Int32List data = Int32List.fromList(values);
    return MyObject._(MyService_createObject(_impl, name, data, data.length));
  }

  static _destroy(Pointer<Void> ptr) {
    return MyService_destroy(ptr);
  }
}

class MyObject {
  final Pointer<Void> _impl;

  MyObject._(Pointer<Void> impl) : _impl = anchor(impl, MyObject.destroy);

  String get name => MyObject_getName(_impl);
  Int32List data => MyObject_data(_impl).as<Int32List>();

  static void destroy(Pointer<Void> ptr) { MyObject_destroy(ptr); }
}

これは他の言語と相互運用するためのC ++ライブラリであり、その逆ではないことに注意してください。

あなたは間違っています、彼らはC ++クラスを他の言語に公開することを可能にします。
https://www.boost.org/doc/libs/1_68_0/libs/python/doc/html/tutorial/tutorial/exposed.html

DartFFIの例をありがとう。
いくつかの欠陥があります。C++例外をDart側に渡す必要があります。 MyObject.dataはこのようには機能しません（ポインターのみを取得し、データサイズは取得しません）。
しかし、その考えは明らかです。

私の意見では、そのようなコードは冗長すぎて手動で記述できません。
このプロセスが新しいDartFFI FlutterEngineバインディングに対して自動化されるかどうかを楽しみにしています。

C ++の相互運用性のためのランタイムバインディングはほぼ不可能です（ジェネリックス、多重継承、演算子のオーバーロード、マングルされた名前などをどのように処理しますか...）。 多くの困難な試み（BridJ、CppSharpなど）がありましたが、私の理解では、人々はC相互運用機能が最も実行可能なオプションであると考えています。

公式の相互運用性開発者がC ++で実現できる非常に一般的なソリューションはありそうにありません。 Kotlin / Nativeはそれを提供していません。 スカラネイティブiether。 .NETのいずれか（Microsoft C ++の相互運用機能は常に奇妙または静的です）。 JNIは、静的コンパイルが関係する場合にのみC ++相互運用機能をサポートします。 Python BoostGluのようなものは手動で書く必要があります。 サードパーティのグループなら誰でもJNAeratorのようなものを開発できます（つまり、あなたはそれを行うことができ、Dart / Flutterチームがそれを達成することを期待する必要はありません）。

本当の答えがないこの会話に続いて、私はクロスプラットフォームであり、完全なC ++サポートを備えたQtに固執すると思います。 Flutterを次のプロジェクトで試してみようと思っていたのですが、今はそうは思いません。どうもありがとうございました。

FlutterがC ++で記述されていれば、他の言語との相互運用が容易に可能であったとしたら、もっと良かったかもしれません。 C ++でフラッターを書き直す試みはありますか？

今、議論は不必要に広がっていると思います。

私たちは、フラッターの開発ロードマップに何があるか（またはないか）を知っています。
したがって、特定のユースケースで使用する（または使用しない）ことを決定できます。

開発アジェンダを変更しようとしても有用性が見当たらない、または
この点を超えて、特定のアーキテクチャの実装を要求します。

ありがとう、
Gaurav

2019年2月25日月曜日午後10時51分bhauj、 notifications @ github.comは次のように書いています。

FlutterがC ++で記述されていれば、もっと良かったかもしれません。
他の言語との相互運用は簡単に可能でした。 は
C ++でフラッターを書き直そうとする試みはありますか？

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/flutter/flutter/issues/7053#issuecomment-467098455 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AZ86acDpZgNeyezx40uxe_c5E2xZHWxaks5vRBumgaJpZM4K-PLw
。

実際、Flutterは私が知っているようにC ++で書かれていますが、Flutterでのプログラミングは、VMで実行されるインタープリターLanguageDartでのみ実行できます。 しかし、ダートからフラッターのC ++パートに到達するチャンスはまだありません...

したがって、これを読み、優れたクロスプラットフォーム開発のAppdevelopmentで一般的なユースケースを持っている人は誰でも、Flutterは、必要に応じてC ++を直接使用することを許可せず、Qt C ++などの別のクロスプラットフォームフレームワークを使用します。

私にとって、C ++は、ほとんどすべての技術で最小公分母であるため、Cross-Plattform-Developmentに不可欠です。

@aqmappdesigners

VMで実行されるインタプリタ言語ダート

それは正確ではありません。

FlutterはDartVMをデバッグモードで使用します。これにより、ホットリロードも可能になります。
リリースビルドでは、DartはC ++のようなバイナリコードにコンパイルされます。

@zoechiありがとう、私はこれを知りませんでした。 それはパフォーマンスに良いですね

それはパフォーマンスに良いですね

Apples AppStoreの要件です。

dart:ffiプロトタイプは、APIの決定を決定するところまで進んでいます。 （いくつかの設計上の決定については、ここで説明し

十分な情報に基づいて設計を決定するために、バインドするCAPIの例をさらに増やしてください。 これまでのところ、この問題はSQLite、Realm、OpenCV、Superpowered、およびffmpegに言及しています。 考慮すべき他のAPIはありますか？

@dcharkesそれが役立つかどうかはわかりませんが、AndroidのTelegramはJNIを介してC ++でネットワーキングを行います。
https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/jni/TgNetWrapper.cpp
また、ffmpegを使用してGIFの再生を処理し、Androidビットマップに直接書き込みます。
https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/jni/gifvideo.cpp

登録フォームのlibphonenumberとlibpostalを介して電話とアドレスを解析する方法があると興味深いかもしれません。 また、 glfw + flutter- embedderと、いつか完全にdartで書かれたデスクトップアプリが表示されるかもしれません。

SQLiteとレルムの場合は+1。 Couchbaseもご覧ください

Firebase C ++ APIは興味深いでしょうか？ https://firebase.google.com/docs/reference/cpp/

あまり調べていませんが、iOSとAndroidのプラグインをC ++と直接通信する単一のプラグインに置き換えることができるかもしれないと考えていました。

一部の暗号ライブラリは、錆からリングのような愛を得る必要があります-https：//github.com/briansmith/ring

OpenCV、Realm、SqlCipherの場合は+1（https://github.com/sqlcipher/sqlcipher）

暗号化ライブラリ。 特にlibsodiumまたはtink。

https://github.com/google/tink

https://libsodium.gitbook.io/doc/

すでにフラッターナトリウムライブラリがあり、プラットフォームチャネルを介して各プラットフォームのlibsodiumラッパーと通信し、次にネイティブと通信します。

mapbox-glhttps ： //github.com/mapbox/mapbox-gl-nativeなどのカスタムマッピングライブラリ

https://github.com/deltachat/deltachat-c​​oreを介したFlutterのSMTP / IMAP処理（chat-over-email用）は、私が直接使用したいものです。

言い換えるほど大胆な場合、一般的な使用例は次のとおりです。

1. 低遅延のオーディオ/ビデオハードウェアアクセス（Superpoweredなど）
2. ハードウェア支援のA / V処理（ffmpegなど）
3. TCPベースのソケットアクセス、XMPP /その他のネットワーク指向プロトコル用
   （チャット、プッシュ通知の場合）
4. プロセスレベルのアップグレード（ルートアクセス）/スレッドの生成
   クロスプラットフォーム互換の方法（システムアプリ、マルチタスク、エミュレーター用）

もっと多くのユースケースがあるかもしれませんが、これらは私のところに来る主なものです
マインド。

例を提供してくれてありがとう！ これは非常に役立ちます。

@ kills-upは、抽象的な分類ではなく、具体的な例にはるかに関心があることに注意してください。 これは、具体的な例でFFIの人間工学を評価したいためです。

不思議なことに、C ++との間で最適なインターフェイスを提供する言語の1つは、OOへのアプローチが完全に異なるにもかかわらず、強力なマクロ+ビルドシステムを介したRustです。

クライアント証明書を使用してSOAPリクエストとxmlファイル（XMLDSig、Xades l）にデジタル署名する必要があるため、OpenSSLと言います。
Dart自体にはBoringSSLがありますが、Dartを介して公開されているのはその一部だけです。 したがって、次善の策は、フラッターからネイティブのopensslライブラリを呼び出すことです

スパムではないことを願っていますが、JNIを経由せずに、テンソルフローライトとの統合を改善したいと考えています。これは、ビデオ操作に最適です。

あまり調べていませんが、iOSとAndroidのプラグインをC ++と直接通信する単一のプラグインに置き換えることができるかもしれないと考えていました。

C ++のサポートとは別に、Goと直接通信できるプラグインがあれば素晴らしいでしょう。 現在、UIの応答性を低下させるgomobile＆flutterプラットフォームチャネルを通過することについて話し合っています。 FlutterでGoとC ++をネイティブにサポートすることで、複数のプラットフォームで統一されたコードベース（ビジネスロジック/アルゴリズム）を維持することもできます。

ネイティブライブラリアクセスの場合は+1。

Android / iOS用のプラットフォームチャネルを作成せずにVulkan / MoltenVKにアクセスし、2つのプラグインを維持したいと思います（これも巨大です）。 これにより、Dartでのみ開発しながら、3Dアプリケーションを構築してテクスチャウィジェットにレンダリングできるようになります。 プラットフォームチャネルは、ハッキーな回避策のように見えます。 プラットフォームごとにラッパーを記述せずにネイティブライブラリにアクセスし、そのライブラリの新しいバージョンがある場合は常にそれらを維持したいと思います。
この機能はもっと多くの開発者を引き付けると思います。

はい、plzはフラッターからネイティブライブラリに直接アクセスします。
flutterでc ++ライブラリを使用したいと思います。

はい、plzはフラッターからネイティブライブラリに直接アクセスします。
flutterでc ++ライブラリを使用したいと思います。

現在、フィードバックを得るために早期プレビューを提供したいと考えています。

詳細については、 Dartトラッキングバグのアップデートをご覧ください。

@ mit-mitこれはこの問題に役立ちますか：

パーティーに遅れましたが、SQLCipher @ dcharkes @ mralephの場合は+1

@ doc-rjこれで、SQLCipherのバインドを実験して、経験に関するフィードバックを提供できるようになるはずです。 このコメントを参照してください。

リクエストは非常に多様であるため、私たち自身が特定のライブラリバインディングを提供することを実際に目指しているわけではないことを強調したいと思いますが、CAPIを使用してすべての人と誰もが任意のライブラリにバインドできるようにすることを目指しています。

マルチプラットフォームが発表された今、この必要性は高まっていると思います。

これはロードマップの一部ですか？

@felemedeiros作業は進行中ですこのコメントを参照してください。

あまり調べていませんが、iOSとAndroidのプラグインをC ++と直接通信する単一のプラグインに置き換えることができるかもしれないと考えていました。

C ++のサポートとは別に、Goと直接通信できるプラグインがあれば素晴らしいでしょう。 現在、UIの応答性を低下させるgomobile＆flutterプラットフォームチャネルを通過することについて話し合っています。 FlutterでGoとC ++をネイティブにサポートすることで、複数のプラットフォームで統一されたコードベース（ビジネスロジック/アルゴリズム）を維持することもできます。

FlutterからGoライブラリAPIを現在どのように呼び出しているかについての記事を書きました。 興味のある人には役立つかもしれません。 https://medium.com/@archan.paul/using -go-library-in-flutter-a04e3496aa05

FlutterアプリにC ++コードを追加するにはどうすればよいですか？

FlutterアプリにC ++コードを追加するにはどうすればよいですか？

今のところ唯一の選択肢は、C ++-> JNI（Androidの場合）-> PlatformChannelを使用して、同じことをよりエレガントに行う方法があると思います。

ezored（http://ezored.com）というプロジェクトを作成しました。 それはすでにjavaとobjcにあるので、他のものに変換する必要なしに複雑なオブジェクトをFlutterに渡すことができれば素晴らしいでしょう。 誰でもezoredを使用してSDKを生成（またはビルド済みのダウンロード）して、ネイティブとDart間のFlutter統合をテストできます。 リクエスト、解析、データベースを使用したクラッド、およびデモSDKの多くのものがすでに実装されています。

Flutterグループを検索しましたが、オブジェクトとオブジェクトのリストをFlutterに直接渡す方法がありません。

助けてくれてありがとう。

新しい進歩はありますか？ 2。5年以上経ったようです...

@fzyzcjy私たちはそれに取り組んでいます。 初期のプレビューをリリースしました。 参加方法については、 https： //github.com/dart-lang/sdk/issues/34452#issuecomment-482136759を参照して

この初期のプレビュー以降、Intel 32、Arm 64、およびArm 32のサポートが追加されました。これらのプラットフォームは、安定版または開発版ではまだリリースされておらず、DartSDKのマスターブランチでのみ利用できます。 進捗状況はここで追跡されてい

@dcharkesそれを聞いてとても幸せです！ 素晴らしい仕事をありがとう！

進捗はありますか？

ステータスの更新と追加情報については、 https：//github.com/dart-lang/sdk/issues/34452を参照して

Flutterを使用してWebアプリを作成する場合、ACライブラリでffiを使用することは可能ですか？

Flutterを使用してWebアプリを作成する場合、ACライブラリでffiを使用することは可能ですか？

それはありそうもない。 理論的には長期的にはWebAssemblyを使用してサポートできますが、現在取り組んでいることではありません。

@ with-本当にと？

Flutterを使用してWebアプリを作成する場合、ACライブラリでffiを使用することは可能ですか？

それはありそうもない。 理論的には長期的にはWebAssemblyを使用してサポートできますが、現在取り組んでいることではありません。

なぜWebAssemblyが必要なのですか？ 将来、WebAssemblyに再構築するように依頼できる場合は、今すぐASM.jsに再構築するように依頼できます。

@ nic-hartleyそれは良い考えですが、課題はネイティブコードをコンパイルする方法ではなく、Dart（JSとしてコンパイル）とネイティブコードの間のブリッジを作成することです。

ネイティブFFIはパフォーマンス上の理由から非常に低レベルであり、asm.jsまたはWebAssemblyに簡単に変換することはできません。

明確にするために、私たちの実装は非常に低レベルであることを意味します-それは確かに興味深い機能ですが、提供するにはかなりの作業が必要になります。

flutterは、c ++をサポートするまではおもちゃにすぎません。

FlutterがC ++と簡単に相互運用できるようになるまで（ブリッジライブラリがなく、パフォーマンスが低下しない）、既存のネイティブライブラリに投資している大規模なアプリケーションやアプリケーションに採用されることはないということを他の人も同じように考えています。ここで、パフォーマンスが最優先されます。

現在、React Nativeでさえブリッジを使用しているため、FFIの実装を試みるという点では、Flutterは実際には時代を先取りしているように見えます。

C ++との統合は、AppKitを使用するiOSでは簡単です。 これは、React Nativeではなく、比較する必要があるものです。

UWPとC ++も簡単です。

私も一般的に「DartFFIの取り組みをサポートする」パーティーに参加していますが...

XamarinはUWPよりも適切な比較かもしれませんが、XamarinのクロスプラットフォームビューはFlutterのビューほどカスタマイズ可能ではなく、見栄えを良くするために多くのネイティブコードが必要になることがよくありました。

本当じゃない。 Flutterとは異なり、XamarinにはネイティブAPI（Xamarin.iOSおよびXamarin.Android）へのプラットフォームバインディングがあり、アプリ開発者はプラットフォーム固有の実装を独自の言語（C＃/。NET）で簡単に作成できます。 この問題は言語機能に関するものであり、UIウィジェットのAPIデザインと混在させないでください。

ネイティブAPIの使用法はたくさんありコードの場合、Xamarin.Android自体（バックエンドプラットフォームバックエンドの1つ）でも、ネイティブコードの使用はごくわずかであり、アプリ開発者はネイティブコードを記述しません。

また、React NativeやXamarinとは異なり、Flutterは完全なフレームワークを提供するため、Flutterフレームワーク全体をAppKitなどと比較することは完全に公正な観点です。

C ++統合に関して他のすべてよりはるかに進んでいるQtフレームワークについて誰も言及していないのは奇妙なことです

QTはC ++です。 そして、そもそも不利なライセンスを持っています。

2019年8月12日月曜日、06：41 Vladyslav Stelmakhovskyi、<
[email protected]>は次のように書いています：

はるか先のQtフレームワークについて誰も言及していないのは奇妙なことです
C ++統合に関するその他すべて

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/flutter/flutter/issues/7053?email_source=notifications&email_token=AGDYMWXHTJUBUW64LEOO27TQEDSWNA5CNFSM4CXY6LYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORWS
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AGDYMWTNMTM7QUOY2BEIPM3QEDSWNANCNFSM4CXY6LYA
。

QtはC ++およびQML（JSエンジン）です
どのようなライセンスですか？ LGPL？ GPL？ 何が問題なのですか？

最初はIANALですが、私が理解しているように、QtのほとんどはLGPL（IDEなどはGPLです）です。つまり、静的リンクを明示的に禁止していませんが、アプリケーションがライセンスを遵守している間は実行が困難な言語があります。クローズドソースです。

技術的には、LGPLのみを使用し、オブジェクトファイル（およびおそらく命令）を提供して、ユーザーがライブラリの別のバージョンに対して再リンクできる可能性がある場合は、LGPLの要件を満たしています。 しかし、Qt Companyはその事実を宣伝していないと確信しています。したがって、一般的な概念は、静的ライブラリをデプロイできないということです。つまり、高額なライセンス料を支払わずにアプリをアプリストアでリリースすることはできません。 そして、私はオブジェクトファイルを提供することについて間違っているかもしれません、それはそれについての私の理解です、そして私は誰かがそれをしているのかどうかわかりません。

Androidは、LGPLでより明示的に許可されている動的に読み込まれるライブラリを許可するため、より簡単ですが、正直なところ、アプリのサイズを小さくするために、静的リンクもおそらく望ましいでしょう。つまり、同じ問題が発生します。

こんにちは@cpboyd 、私はこれを反対方向から見ていると思います。 プラットフォーム固有のUIフレームワーク上に構築されたアプリがすでにあり、各プラットフォームで既存のC ++ライブラリの膨大なコレクションを利用できます。 Flutterはクロスプラットフォームであることは理解していますが、これは素晴らしいことですが、実際に（既存のコードで）使用できない場合は、クロスプラットフォーム以外のUIを使用する方がよいでしょう。 唯一の問題は、将来のOS（Fuchsiaなど）でFlutter＆Dartを使用する必要があるが、このユースケースを許可しない場合です。 その場合、既存のコードベースが大きい人は無視する可能性があります。

Flutter / Dartが「Web」アプリ（つまり、バックエンドがWeb上にある）を念頭に置いて設計されているのか、プロのデスクトップアプリケーション開発者のニーズに真剣に検討されているのかはわかりません。 最終的に、このような決定は、アプリストア上の多くのアプリケーションの数と品質に影響を与える可能性があります。 UIKitを使用してiOS用の高品質のプロフェッショナルアプリを作成でき、数百万行の既存のコードを利用できる場合でも、Fuchsia / Flutter / Dart向けに開発している場合は、（パフォーマンスコストがほぼゼロで）作成できません。私が開発しないOSとプラットフォームになります。

私の投稿の目的は、Flutterを他のクロスプラットフォームまたは非クロスプラットフォームのライブラリと比較することではなく、開発者のサブセットにとって重要なユースケースを強調することです。

Dart FFIは興味深いものです。sqlliteの例を_非常に_簡単に読んだところ、PInvokeを使用したC＃に似ていますが、残念ながら、C ++には適していません。これは、扱うほぼすべてのタイプでラッピングが必要になるか、次のように記述する必要があるためです。 C ++をラップするための完全に汎用的なタイプレスインターフェイスシステム。 次のObj-Cクラスの使いやすさと比較すると、どちらも特に魅力的ではありません。

#include <mylib/mytype.h>
<strong i="11">@implementation</strong> MyView
{
    MyLib::MyType *_pMyType;
}
<strong i="12">@end</strong>

または、C ++ / WinRTを使用したUWP：

#include <mylib/mytype.h>
class MyUserControl : public UserControl
{
    MyLib::MyType *_pMyType;
};

ありがとう ：-）

@Hixie @MarkIngramUKどちらもクロスプラットフォームではないので、それが私のポイントでした。
AppKitはAppleのみですが、UWPはWindowsのみです。
おそらく、FlutterがDartの代わりにSwiftまたはC＃を使用していた場合、すでに同じレベルのサポートがありますが、それはまったく異なる議論です。
XamarinはUWPよりも適切な比較かもしれませんが、XamarinのクロスプラットフォームビューはFlutterのビューほどカスタマイズ可能ではなく、見栄えを良くするために多くのネイティブコードが必要になることがよくありました。
私の提案はまだ残っています：C ++でFlutterを使用したい場合は、DartチームのFFIプレビューに参加して、私たち全員のサポートを改善するのに役立ててください😃

この問題は言語機能に関するものであり、UIウィジェットのAPIデザインと混在させないでください。

@atsushieno確かに、それがこのディスカッションが

次のObj-Cクラスの使いやすさと比較すると、どちらも特に魅力的ではありません。

@MarkIngramUKこれは、Dartチームがhttps://groups.google.com/forum/#!forum/dart-ffiで見たいと思っている種類のフィードバックであると確信してい

私はezored（https://ezored.com）というプロジェクトを持っています。これは、C ++のSDKおよびアプリケーション用のC ++ブートストラッププロジェクトです。 モバイルプロジェクト（AndroidおよびiOS）で使用しています。 デフォルトのSDKを使用してフラッターするプロジェクトを作成するためにFFIが終了するのを待っています。

デフォルトの実装（pocoプロジェクト、openssl、sqlite、統合された特定のプラットフォームコード）でわかるように、SDKにはすべてのプラットフォームで同じコードがあるため、C ++に問題はなく、新機能の開発にかかる時間が短縮されます。ブリッジコードなど）。

私のオプションでは、これが最良の方法です。

• C ++バックエンドを備えたiOSおよびAndroid（ezored）
• バックエンドとしてのFlutterとC ++

プロジェクトに開始を追加してください:)

Kotlin Multiplatformは回避策であり、完璧な考えではありません。 まだhttps://github.com/dart-lang/sdk/issues/34452を待つ必要があり

Unity3dは、C＃VM [1]に基づくエンジンにフラッターを移植しているようです。その世界では、C＃とC ++の間で話し合うのはまともです。 たぶん、彼らがいくつかの問題をどのように解決したか、彼らのリポジトリを見てみる価値があります。 彼らは次のように述べています：「UIWidgetsは主にFlutterから派生しています」。 また、React Native Campと、TurboModulesを使用した新しいアプローチについても見ていきます。
1）同期と非同期の両方および
2）マーシャリングはありません
3）CだけでなくC ++もサポートします

私は両方のキャンプをチアリーダーしています。

[1] https://github.com/UnityTech/UIWidgets

Dart 2.5の時点で、これ（ dart:ffi ）はプレビュー中です：
https://medium.com/dartlang/announcing-dart-2-5-super-charged-development-328822024970

素晴らしいニュース！

うーん...フラッターでオーボエを使うだけで十分ですか？..

https://github.com/google/oboe

@ rg4realうん！ ただし、OboeインターフェースはC ++であるため、いくつかのCラッパーを作成する必要があります。

開始手順については、 https：//github.com/flutter/flutter/wiki/Binding-to-native-code-via-FFIを参照して

https://github.com/atsushieno/oboe-sharp/tree/master/nativeで機能する場合は、C＃バインディング用に作成したoboe-c.soを再利用できます。

@ sjindel-google、それはいくつかの素晴らしいニュースです！

したがって、クラスと関数を作成して、C ++とCコードの間にブリッジを作成する必要があります。 そして、そのクラスを使用して、Dartコードからその関数を呼び出すことができます。 そうだと思います。

@atsushieno 、ありがとうございます。 見てます。 私の場合、橋を作る方法がわかりません（経験不足）。 しかし、オーボエを正確に演奏するという全体的な目標を達成することができましたか？ 良かったですか？

@ rg4real私は、低レイテンシのオーディオよりも単純なAPI（OpenSLESと比較して）のためだけにそれを行っていました。 レイテンシーを真剣に考えているなら、Xamarin.Androidは使用しません。 あなたがオーボエ（またはその背後にあるAAudio）について話しているなら、私はそれをFluidsynthで使用します、そしてそれはうまく機能します。 ただし、OpenSLESと比較して「どれだけ優れている」かはわかりません。

メモリの管理方法に関するガイドはありますか？

C ++コードがnew / mallocを使用してメモリを作成し、dartコードに戻る場合、そのメモリを解放する方法。

c ++コード
void foo（char ** out）{
* out = new char [25];
}

| out |に割り当てられたメモリを削除する方法ダーツコードからの変数？

Dart 2.5を使用している場合は、 .free()にPointerます。 dev / masterブランチを使用している場合、このメソッドはpackage:ffi https：//github.com/dart-lang/ffi/blob/master/lib/src/allocation.dart#L70に移動しました。

コメントによると-「[allocate]と同等の方法で割り当てられたポインタに対してのみ使用できます。」 --free（）は、allocate（）メソッドを使用してメモリが割り当てられている場合にのみ使用できます。

例えば
ffi.Pointerptr = ffi.Pointer。割り当てる（）;
ptr.free（）;

これは、dartコードからnewまたはmallocを使用してC ++側で割り当てられたメモリを解放するのに役立ちますか？

長いメモリなどとしてを通して割り当てられたmalloc 、いずれかダートまたはC ++を介して、それを使って解放することができるfree 。

ダート2.6では、私たちは、使用DynamicLibrary.lookupFunction("free")定義するためにfree 、それはまったく同じになりますので、ダートでfreeプログラムのC ++一部のように。 （ free複数のバージョンをバイナリにリンクしている場合を除きます。）

この機能はすべてのFlutterチャネルで（ベータ版で）一般的に利用可能になっているため、この問題を解決します。 私たちはこの問題を改善し続けています。 詳細な問題については、 https：//github.com/dart-lang/sdk/issues/newにファイルして

C ++クラスをC互換にするのは面倒です。 plzは、C ++クラスを直接呼び出す機能を作成します

+1 C ++をサポートできますか？

@KaungZawHtetと@ fzyzcjy-このために新しい問題を開くことを検討してください（おそらくフラッターではなくdart-langで）。

私はこの問題をロックするつもりです-それを購読している多くの人々がいますが、それの当初の目標はかなり明確に解決されています。

はい、新しい問題については、次のリンクを使用してファイルしてください： https ：