Flutter: Unterstützung der Integration mit C/C++ im Plugin-Framework

@jason-simmons weiß am besten über Gradle. Sobald wir eine .so haben, kann ich definitiv beim Laden helfen.

Ich habe festgestellt, dass es unter buildSrc eine weitere Eigenschaft zum Einstellen der Gradle-Build-Version gibt. Nach dem Update auf 2.2.2 habe ich Fortschritte gemacht und konnte überprüfen, ob .so geladen wird und von Java aus aufgerufen werden kann.

Vermutlich müssten wir auch eine C-API hinzufügen, um HostMessages von C/C++-Code an Dart zu senden.

Ja bitte. Ich habe den Verdacht, dass der C->Java-Callback möglicherweise nicht billig ist.

Gibt es hierzu Neuigkeiten? Betrachten Sie Flutter zum Erstellen einer plattformübergreifenden App, die C++-Code aufruft, der in eine gemeinsam genutzte Bibliothek kompiliert wurde, und dies ist der einzige wichtige Haltepunkt.

Dies ist heute möglich (und @jtrunick hat dies in seiner Versand-App getan), aber Sie müssen zuerst durch Java oder Obj-C springen.

dh Sie können https://flutter.io/platform-channels/ verwenden, um von Dart zu Obj-C/Java zu sprechen und dann von Obj-C/Java in Ihren C++-Code aufzurufen. Dieser Fehler umfasst das Hinzufügen direkterer Unterstützung dafür und das potenzielle Vermeiden des Obj-C/Java-Passthrough.

Da Dart VM in C++ implementiert ist, sollte es nicht eine einfachere (wenn auch weniger sichere) Möglichkeit geben, gemeinsam genutzte C-Bibliotheken direkt aufzurufen (z. B. über dlopen)? Wie viel Veränderung wäre für eine grundlegende (unsichere/experimentelle) Unterstützung erforderlich?

Ist so etwas wie folgt: https://www.dartlang.org/articles/dart-vm/native-extensions auf Android oder iOS verfügbar?

Wir haben diese Anforderung von einigen Google-Apps gehört:

• Eine solche App hat eigene C++-Bibliotheken für den Betrieb der Kamera geschrieben, um die Latenz zu reduzieren. Diese Bibliotheken sind plattformspezifisch und so optimiert, dass sie so schnell wie möglich funktionieren. Das Aufrufen dieser Bibliotheken mit der geringstmöglichen Latenz ist für solche Apps von entscheidender Bedeutung. Sie zu zwingen, PlatformChannel + JNI zu durchlaufen, wird dies auf Android nicht erreichen.

• Es gibt fortgeschrittene mobile Teams, die Geschäftslogikkomponenten in C++ schreiben, um sie zwischen ihren Android- und iOS-Implementierungen gemeinsam nutzen zu können. Flutter, das die direkte Integration mit diesen Bibliotheken unterstützt, würde seine Position als das beste plattformübergreifende Framework auf dem Markt weiter festigen.

Ich glaube nicht, dass dies ein _must have_ ist. Dies ist jedoch ein Bereich, in dem sich Flutter weiter von anderen plattformübergreifenden Lösungen unterscheiden kann.

Eine solche App hat eigene C++-Bibliotheken für den Betrieb der Kamera geschrieben, um die Latenz zu reduzieren. [...] Sie zu zwingen, PlatformChannel + JNI zu durchlaufen, wird dies auf Android nicht erreichen.

Was war ihre Lösung auf Android, um von C++ zu Java und zurück zu gelangen?

Wenn es wirklich notwendig ist, können wir native Dart-Erweiterungen auf den mobilen Plattformen zulassen. Im Moment legen wir die Symbole in dart_api.h nicht offen. Wir müssen uns über Folgendes entscheiden, bevor wir den Schalter umlegen können:

• Finden Sie heraus, wie Sie den AOT-Compiler auf Dart-Code aufmerksam machen, dessen einziger Einstiegspunkt von einer Methode stammt, die sich möglicherweise nicht in der dynamischen Hauptbibliothek der Flutter-Engine befindet. Andernfalls kann der Baumschüttelpass den Code entfernen.
• Bieten Sie Anleitungen zum Erstellen und Verpacken nativer Erweiterungen (Gradle und Xcode für Android bzw. iOS).
• Stellen Sie einige ABI-Stabilitätsgarantien für die Routinen in dart_api.h . Obwohl es größtenteils stabil ist, glaube ich, dass es sich noch weiterentwickelt, um die verschiedenen Modi zu berücksichtigen.

Bisher scheint der Kanalmechanismus der Plattform für einfachere Anwendungsfälle ausreichend zu sein.

Was war ihre Lösung auf Android, um von C++ zu Java und zurück zu gelangen?

Ich habe mich nicht eingehend mit ihrem Anwendungsfall befasst. Es schien, dass sie alle Bits geschrieben haben, die eine Kommunikation mit sehr geringer Latenz in C++ benötigen. Ich werde fragen, ob sie JNI für leistungskritische Anwendungsfälle verwenden (mein Bauchgefühl ist nein).

Es hängt wirklich davon ab, was wir auf Flutter-Seite tun können. Wenn wir einen Interop liefern können, der deutlich schneller ist als JNI, wäre dies ein großer Gewinn für diese Teams. Sie können ihre C++-Codebasis verkleinern und mehr auf die App-Seite verlagern. Wenn unsere Interop-Leistung mit JNI vergleichbar ist, sehe ich hier keinen großen Gewinn. Sie könnten wahrscheinlich das fortsetzen, was sie jetzt tun, und PlatformChannel verwenden.

Hier geht es darum, solchen Teams einen zusätzlichen Grund zu geben, zu Flutter zu wechseln. Ich habe noch nie davon gehört, dass dies ein Blocker ist, also priorisieren Sie entsprechend.

Wenn ich richtig verstehe, was Sie sagen, sagen Sie, dass aktuelle Lösungen darin bestehen, die gesamte Logik (Kamera + UI) in C++ mit minimaler Logik in Java zu haben, und der Wunsch besteht darin, den UI-Teil dieser Logik nach Dart zu verschieben. ohne die UI<->Kamera-Interaktivität mit geringer Latenz zu verlieren.

Können Sie über ihre Einfädelsituation sprechen? Haben sie nur den einen Thread für Kamera + Benutzeroberfläche?

@chinmaygarde könnte uns mit seiner aktuellen Arbeit an der Embedder-API der Lösung dieses

+1

Gibt es Fortschritte bei diesem Problem?

Wir haben Djinni bereits verwendet, um Logiken auf verschiedenen Plattformen zu teilen. Es wäre großartig, wenn wir Interop zwischen Dart und C++ haben könnten, anstatt über Java/Objc-C hin und her gehen zu müssen.

Wenn Dart in C/C++ integriert werden kann, denke ich, dass es eine großartige Idee für Mobilgeräte ist, eine Menge nativer Bibliotheken wiederzuverwenden und keine Bindung an eine bestimmte Plattform mit JNI oder Objective C++ erforderlich zu machen.

Haben Sie https://github.com/mono/CppSharp in Betracht gezogen

Die direkte Integration einer C++-basierten Datenbank wie Realm in C++ würde eine signifikante Leistungssteigerung und eine Steigerung der Entwicklerproduktivität bewirken :-) Ein Auf- und Abstieg über JNI wäre eine solche Verschwendung.

Ich ziehe Flutter für eine AR-App in Betracht, die Computer Vision macht (wahrscheinlich mit OpenCV), und eine effiziente und direkte Dart-C++-Interop wäre ein wichtiger positiver Punkt. Ich kann mir vorstellen, dass viele andere Leute, die anspruchsvolle Apps in Bezug auf die Berechnung erstellen, dieses Bedürfnis teilen könnten.

Kann jemand bestätigen, dass C++-Interop immer noch nicht verfügbar ist? Ist das mit Paketen möglich?

@tofutim Direct c/c++ Interop ist immer noch nicht verfügbar, daher ist dieses Problem noch offen. Sie können jedoch Plattformkanäle verwenden und dann Obj-C/Java verwenden, um mit Ihrem C++-Code zu interagieren. Es ist nicht großartig, aber es ist alles, was wir im Moment haben.

Kann jemand bestätigen, dass C++-Interop immer noch nicht verfügbar ist? Ist das mit Paketen möglich?

Für die Zusammenarbeit mit Plattformbibliotheken ist der Plattformkanalmechanismus immer noch die aktuelle Empfehlung.

Ein leistungsfähigerer Mechanismus, der im nativen Erweiterungsdokument beschrieben ist, kann auf einfache Weise hinzugefügt werden. Mir sind jedoch keine ABI-Stabilitätsgarantien für die von dart_api.h bereitgestellten Symbole @eseidelGoogle bestätigen können, dass solche Garantien bestehen, kann ich so Tonic als praktische Wrapper um die C-API herausarbeiten, um die Verwendung von C++ zu vereinfachen.

Nach meinem Verständnis geht es bei diesem Fehler um die Bereitstellung einer C-API und Tooling-Hooks, um ein vollständiges C/C++-Plugin zu vereinfachen (kein Obj-C/Java-Shmming erforderlich, aber immer noch asynchron über platform_channels).

Ich denke, wir sollten derzeit keine synchronen Methoden wie native Erweiterungen in Betracht ziehen. (Aber ehrlich gesagt verschiebe ich das auf @Hixie oder @cbracken).

@eseidel

Ich denke, wir sollten derzeit keine synchronen Methoden wie native Erweiterungen in Betracht ziehen

warum ist das so?

Der aktuelle Ansatz zum Aufrufen des C Codes ist Dart -> Java -> C
Wir überqueren JNI zweimal, oder?
erstes Mal: dart zu Java über Plattformkanäle (unter der Haube JNI- Aufruf verwendet, oder?)
zweites Mal: Java -> C über JNI

Als Beispiel wäre aus Sicht der Bedürfnisse meines Projekts der Zugriff auf dart_api.h auch ohne Stabilitätsgarantie (z. B. als experimentelle Funktion) bereits gut genug. Mein Hauptanliegen ist es, große Blobs von Binärdaten (Bildern) von der Dart-Seite auf die C Seite und zurück zu verschieben, ohne zu rangieren und idealerweise zu kopieren. Unity/Mono erreicht das .

Aus der Dart-sdk-Ausgabe 31960 verstehe ich, dass die aktuelle Implementierung von Isolaten möglicherweise keine Weitergabe von Daten ohne Kopieren zulässt (obwohl es theoretisch möglich sein sollte, zu erkennen, dass der in Isolat A erstellte Puffer nach der Übergabe an Isolat B nicht mehr verwendet wird und daher kann sein Eigentum übertragen werden, ohne es zu kopieren.. irgendein Plan an dieser Front?), aber wenn es zumindest innerhalb eines Isolats keine Rangierung nach / von C , wäre es gut.

Marshalling könnte mit Flatbuffern vermieden werden, die bald landen sollen: https://github.com/google/flatbuffers/pull/4676
Oder mit Protobuf-Nachrichten, die nur ein einzelnes Byte-Feld verwenden.

Dies bringt natürlich große Mengen an Byte-Kopien mit sich, also nicht für alle Anwendungsfälle geeignet.

Ich höre hier mindestens drei verschiedene Wünsche:

1. Ich würde gerne ein Plugin für Flutter nur mit C/C++-Code schreiben, ohne eine Menge Java/Obj-C-Kleber hinzufügen zu müssen (das war mein ursprüngliches Verständnis dieses Fehlers und etwas, von dem ich definitiv denke, dass wir es tun könnten/sollten) .
2. Ich möchte eine Möglichkeit haben, große Datenmengen schnell/mit geringer Latenz/usw. in/aus Dart zu verschieben. (Vermutlich aus einer Vielzahl von Sprachen, einschließlich C++. Das klingt nach einem sehr gültigen Fall! Ich würde dringend empfehlen, einen separaten Fehler mit einem Beispiel einzureichen.)
3. Möchten Sie Dart mit synchronen Anrufen/Objekten erweitern? (zB native Erweiterungen oder andere Methoden? Dies ist auch völlig machbar. Es gibt potenzielle Schwierigkeiten bei der API-Stabilität, und ich denke, wir möchten mehr über den spezifischen Anwendungsfall erfahren, bevor wir Maßnahmen ergreifen.)

Mein Feedback zum Lesen des Obigen ist, dass wir erwägen sollten, einige zusätzliche Fehler aufzuteilen. Wir müssen definitiv etwas in die C++-Inter-Op investieren, aber es ist schwer aus diesem langen Thread zu bestimmen, welche genauen Anwendungsfälle wir ansprechen sollten und in welcher Reihenfolge?

Wären Interessenten bereit/in der Lage, neue Bugs mit ihren gewünschten Use Cases einzureichen und hier wieder zu verlinken? Gerne lasse ich diese Ausgabe offen, um das allgemeine Interesse an diesem Problemraum zu verfolgen.

In Bezug auf Leistung und 2. oben: Obwohl ich mir sicher bin, dass die Leistung von Flutters platform_channels verbessert werden könnte (und dass wir wahrscheinlich andere Plugin-/Inter-Op-Methoden benötigen werden, um alle Anwendungsfälle abzudecken), möchten wir einige konkrete Anwendungsfälle (vielleicht gibt es sie und ich habe sie noch nicht gesehen?), bei denen die Leistung von Flutters platform_channels ein Engpass ist, bevor wir Maßnahmen ergreifen. Meine Erfahrung mit der Leistungsoptimierung von Systemen ist, dass mein Bauchgefühl oft falsch ist. Auch wenn sich Dinge wie JNI oder platform_channels wie potenzielle Engpässe anfühlen, wissen wir es erst, wenn wir messen.

Nochmals vielen Dank an alle für Ihre Hilfe und Ihr Feedback!

Ich würde gerne ein Plugin für Flutter nur mit C/C++-Code schreiben, ohne eine Menge Java/Obj-C-Kleber hinzufügen zu müssen (das war mein ursprüngliches Verständnis dieses Fehlers und etwas, von dem ich definitiv denke, dass wir es tun könnten/sollten) .

das würde auch eine bessere SQLlite-Integration für Flattern geben + es gibt Tonnen von C / Rust-Bibliotheken für Krypto, SSH und andere Dinge. Es wäre cool, so einfach zu verwenden.

@eseidel

Ich höre mindestens drei verschiedene Wünsche präsentiert

Meine Stimme für 1.)

Nach dem Lesen der Flutter-Dokumentation sollte es ziemlich "einfach" sein, die Plattformkanäle zu erweitern, um C zu unterstützen.
Die einzige neue Sache wäre wahrscheinlich eine Möglichkeit, _dynamische Shared Objects_(s) in den aktuellen Prozess zu laden.

Ich könnte mir vorstellen, dass die _Android-C_-Nutzung ungefähr so ​​aussieht:

#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)
}

Konzeptionell müsste man sich zumindest für _Android-C_ entscheiden, wie man mit der Kombination von Java und C umgeht.

@eseidelGoogle
Wir stellen derzeit Golang-Code über Java und Swift-Wrapper bereit, und die Latenz ist ein merkliches Problem, auf das wir stoßen.
warum ?

• Wir müssen die Geschäftslogik zwischen vielen Plattformen teilen.
• Für Video- und Bildfunktionen wie Bildschirmfreigabe.
• Für DB.

Wenn Sie in der Lage wären, Golang-Unterstützung auf direkter Ebene hinzuzufügen, würde das einen großen Unterschied machen!
Das Kompilieren von Golang-Code für Mobilgeräte ist auch ohne LDFLags-Magie sehr einfach, daher denke ich, dass es beliebt wäre. Ich kenne einige andere Golang-Codierer, die derzeit auch die Method Channels verwenden.
Was die Serialisierung angeht, verwenden wir derzeit Protobufs und Flatbuffer.

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

In Fuchsia geschieht dies mit FIDL und es hat Bindungen zu C, Rost und Golang.
Es ist ziemlich toll zu bedienen und ich habe es genossen, Rost und Golang auf einem eingebetteten Board auszuprobieren.

Es sollte möglich sein, das Fidl-Zeug auch über iOS und Java verfügbar zu machen.
Das würde eine schöne Onramp zwischen Fuchsia und Flattern auf Handys und Desktop geben.
Nur eine Idee, mit der ich spiele

@eseidelGoogle
Hiixe sagte mir, dass FIDL nicht auf Flutter-Ebene durchgeführt werden kann, da FIDL auf Kernel-Code von Zircon in Fuchsia angewiesen ist. Die einzige Möglichkeit, die FIDL-IPC-Stil-Funktionalität in Flutter zu replizieren, besteht darin, eine FIDL-Version in die Flutter-Engine zu schreiben. Aber dann habe ich damit herumgespielt und festgestellt, dass es Flatbuffers ziemlich ähnlich ist. Warum also nicht einfach FlatBuffers für die Serialisierungsschicht zwischen dem Flutter und der cpp- oder Golang- oder Rostschicht auf Flutter verwenden. ?

Nur +1 dazu, wir haben eine Flatter-App, die eine Bibliothek namens Superpowered verwendet. Superpowered ist in C++ geschrieben, wir verwenden dann Java- und JNI-Typen, um damit zu interagieren, die wir wiederum verwenden Plattformkanäle, um mit dem Java-Code zu kommunizieren. Es wäre sicherlich schön, wenn wir den Mittelsmann überspringen könnten.

Dies liegt auch daran, dass beliebte mobile Bibliotheken wie Realm davon abgehalten werden, Flatter-Versionen zu erstellen, da ihr Kern in C/C++ geschrieben ist und sie sich auch nicht mit einem java/objc/swift-Mittelsmann befassen wollen.

Aus diesen Gründen, abgesehen von der allgemeinen Stabilität, denke ich, dass dieses Problem derzeit eine der am dringendsten erforderlichen Änderungen beim Flattern ist. (Genauer gesagt Nr. 1 auf der Liste von @eseidelGoogle .)

Wenn Sie ein Argument für die Umgehung von Java/JNI in Plattformerweiterungen hören möchten (dh nicht nur die Java-Glue-Schicht für den Entwickler verstecken/automatisieren), hat Superpowered viel zu diesem Thema zu sagen: https://www.youtube. com/watch?v=LzIuir3r6Co

@pnico Können Sie erklären, wie dies argumentiert, dass Java/JNI bipassed werden sollte? Es scheint kaum mehr zu sagen, als Ihr Audioverarbeitungscode in C++ geschrieben sein sollte. (Was nicht bedeutet, dass Sie es nicht über das JNI oder auf andere Weise anrufen können)

@csga5000 du hast völlig recht, das machte keinen Sinn: D JNI wird sich wahrscheinlich nicht wirklich auf die Leistung auswirken, es sei denn, du versuchst mehr esoterische Sachen zu machen. Ich denke, es kommt wirklich auf die Bequemlichkeit/Wartbarkeit an, und ich denke, vielleicht die Möglichkeit, mehr App-spezifischen Code aus Java/C++ und in Dart zu verschieben

Ich denke, @pnico sagt, dass er es über JINI aufrufen kann, aber dass die JINI zu viel Latenz hinzufügt.
Die Perf ist also das Problem.
ja Nein ??

Dies könnte vor allem für kryptobezogene Arbeiten einen großen Unterschied machen.

Ich nehme auch für Android Things an, obwohl ich keine Experimente gesehen oder gemacht habe
und Benchmarks für zeitabhängiges gpio weder in c noch in dart für über a
Jahr.

Am Sa., 9. Juni 2018, 10:52 Uhr schrieb Eddy WM, [email protected] :

Dies könnte vor allem für kryptobezogene Arbeiten einen großen Unterschied machen.

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/flutter/flutter/issues/7053#issuecomment-395927258 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AFHMcSI2JDHbgv3iYrStDN5mlzkQ8XEkks5t6xxMgaJpZM4K-PLw
.

Gibt es seitdem Fortschritte?

Gibt es eine Empfehlung für ein Beispiel-Flatter-Plugin, das zeigt, wie die ac/c++-Lib integriert wird, bis das Problem gelöst ist? Ist Dschinni ein guter Weg?

Bis es gelöst ist, die einzige Möglichkeit, c/c++ zu integrieren, nativen Android- und iOS-Code zu schreiben und dann über Plattformkanäle mit dem Dart-Code

Ich habe Plugins implementiert, die Plattformkanäle verwenden (zu JAR-Dateien und CocoaPods). Ich suche nach einem Beispiel-Plugin, das zeigt, wie man in dieselbe c/c++-Bibliothek integriert (sowohl für Android als auch für iOS). Irgendwelche Empfehlungen?

@ mmcc007 So machen Sie es in Java oder Swift.

Java: https://www.google.com/search?client=opera&q=android+java+use+C%2B%2B&sourceid=opera&ie=UTF-8&oe=UTF-8

Schnell: https://www.google.com/search?client=opera&q=swift+use+C%2B%2B&sourceid=opera&ie=UTF-8&oe=UTF-8

Sie können sehen, wie superpowered Ihnen dies empfiehlt, wenn Sie wirklich ein Beispiel wollen (es ist nur eines, das ich kenne): https://github.com/superpoweredSDK/Low-Latency-Android-iOS-Linux-Windows-tvOS-macOS- Interaktive-Audio-Plattform
Siehe die Beispielordner. Innerhalb von https://github.com/superpoweredSDK/Low-Latency-Android-iOS-Linux-Windows-tvOS-macOS-Interactive-Audio-Platform/tree/master/Examples_Android/SuperpoweredRecorder/app/src/main gibt es java/com/superpowered/recorder/MainActivity.java, das auf Code in cpp/RecorderExample.cpp verweist

@csga5000 Es sieht so aus, als ob es ziemlich einfach wäre.. bei der ersten Überprüfung. Trotzdem wäre es schön, ein funktionierendes Flatter-Plugin zu durchsuchen. Vielen Dank.

+1 dafür. Alle funktionierenden Beispiele für eine Flatter-App mit C++ würden gut angenommen

Es gibt ein Projekt, das dies für Golang tut und ich denke, der gleiche Ansatz
kann auch für c++ verwendet werden.

Das golang-Programm verwendet jsonrpc.
Dann müssen Sie nur noch Ihren eigenen Golang-Code mit jsonrpc erstellen.

Dann ist alles ganz einfach.

Ich denke, Plattformkanäle unterstützen NUR JSON als agnostische Serialisierung
Format ?

Am Mittwoch, 18. Juli 2018, 16:50 Uhr Jefferson Bledsoe, [email protected]
schrieb:

+1 dafür. Alle funktionierenden Beispiele für eine Flatter-App, die c++ verwendet, wären
gut erhalten

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/flutter/flutter/issues/7053#issuecomment-405958345 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ATuCwkPbb9vLdoaEwM-bLhYPZxtyQ5Vjks5uH0sqgaJpZM4K-PLw
.

Hallo, irgendwelche Neuigkeiten?

Möchten Sie nur wissen, ob es jemandem in diesem Thread gelungen ist, die Superpowered-Bibliothek direkt in eine Flatter-App zu integrieren?

Ja @skills-up wir haben es geschafft. Nur nicht in einem Open-Source-Projekt, daher kann ich es nicht zeigen. Aber wenn Sie meine Tipps früher sehen, machen Sie es so. Möglicherweise müssen Sie Ihre Flatter-App jedoch für jede CPU-Architektur erstellen

Ich habe gehört, dass Sie dies über JNI/Java und nicht direkt über Dart getan haben. Ich habe mich gefragt, ob es möglich ist, plattformspezifischen Code ganz zu vermeiden.

Möglicherweise müssen Sie Ihre Flatter-App jedoch für jede CPU-Architektur erstellen

Sie meinen eine separate App für jede Architektur oder nur die Angabe aller unterstützten Architekturen?

Übrigens, wir haben bereits eine funktionierende App, die nativ in Java geschrieben wurde. Da wir jetzt jedoch auch eine iOS-App erstellen müssen, habe ich mich gefragt, ob die Erstellung einer App im Flatter-Modus (anstatt den Aufwand für Swift/XCode aufzuwenden) aus der Perspektive der zukünftigen Wartbarkeit mit dem Vorteil einer einzigen Codebasis sinnvoller wäre.

Brunnen. Realm wartet darauf, dass ihr einen Weg bereitstellt: https://github.com/realm/realm-object-server/issues/55

lukaspili : Ich schätze alle warten noch auf: flattern/flattern#7053
bmunkholm: @lukaspili Ja, das ist sicher eine Voraussetzung.

Für das, was es wert ist, warte ich auch darauf. Ich kann nicht wirklich in Betracht ziehen, XF-Apps durch Flattern zu ersetzen, bis Sie die richtigen Klempnerarbeiten gemacht haben. Nach derzeitigem Stand bläst Xamarin in dieser Abteilung aus dem Wasser.

Zu spät zu dieser Party, aber ein großes +1 für diesen Thread.

Ich entwickle Desktop-Apps, meine Ansicht als Codezeile (für Desktop):

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

Wenn Flutter erstklassige Unterstützung für C++ bieten kann, könnte sein allgemeiner Ansatz ein absoluter Gewinner für die plattformübergreifende Anwendungsentwicklung sein, nicht nur eine "Mobile-Premiere", sondern eine Weltneuheit. Qt ist teuer für kleine Entwickler, ist eigensinnig und unterstützt modernes C++ nicht und nichts kann wirklich mithalten. Könnte Flutter zumindest einen Teil seines UI-Kuchens essen?

PS: Ich bin kein Anti-Dart, es ist ein weiteres neues C#/Go/Rust/etc. konkurrierende Sprache, die für eine neue Plattform vielleicht super produktiv sein mag, aber die Welt der Hochleistungs-Desktop-Anwendungen (mein Interesse hier) ist fest C++ mit umfassender Betriebssystem- und Bibliotheksunterstützung, eine Sprache, die sich selbst mit einer Geschwindigkeit von Knoten entwickelt (ist es nicht). C), und ich denke, Flutter hat es verdient!

Ich glaube nicht, dass Flutter C++ in naher Zukunft unterstützen wird, und das ist jetzt sicherlich nicht möglich. Und ich für meinen Teil bevorzuge Dart enorm - das Schreiben von Apps in C++ selbst mit Flattern würde viel mehr Aufwand erfordern. Und ich glaube nicht, dass C++ direkt in die Desktop-Unterstützung übersetzt wird, sie müssten immer noch ziemlich viel Code schreiben, und die Dart-VM sollte sowieso für den Desktop funktionieren. Ich denke, die Leistung ist für die meisten Anwendungen vernachlässigbar.

Ich denke, am Ende möchte Google die Interoperabilität unterstützen, damit Sie Flatter-Apps für alle Plattformen mit allen unterstützten Sprachen oder sogar einer Kombination dieser Sprachen schreiben können. Aber das würde ich nicht erwarten, bis Fuchsia veröffentlicht wird. Im Moment ist es ihr Ziel, es einfach zu machen, Code einmal zu schreiben. Dart erfüllt dieses Ziel, da es einfach zu bedienen/lernbar, effizient und sowieso eine der Sprachen von Google ist. Ich sehe wirklich fast keinen praktischen Vorteil für den durchschnittlichen Benutzer, erstklassige C++-Unterstützung zu haben. Die Leistung ist in einer mobilen App vernachlässigbar, und die Verwendung von Plattformkanälen mit C++ wäre praktisch, um mit vorhandenen C++-Bibliotheken zu interagieren. Auf der positiven Seite können Sie sicher sein, dass sie schließlich beabsichtigen, dass Flattern den Desktop unterstützt (zumindest Fuchsias Wasserschwein, aber ich bezweifle, dass sie hier aufhören würden).

In diesem Thread geht es um die Unterstützung der direkten Integration mit C++ von dart/flatter, die hoffentlich in naher Zukunft kommen könnte.

Ich glaube nicht, dass flatter C++ unterstützt
Ich sehe für den durchschnittlichen Benutzer fast keinen praktischen Vorteil, eine erstklassige C++-Unterstützung zu haben.

Es geht nicht darum, wie großartig Flutter/Dart im Vergleich zu C++ ist, sondern eher um den Punkt/die Einfachheit der Integrationen, die Sie benötigen, um in das aktuelle Ökosystem zu passen. Es gibt eine lange Liste von Bibliotheken als Shared Objects (OpenCV, um nur eines zu nennen), die dem Industriestandard entsprechen. Sie können nicht erwarten, dass die Leute sie in Dart umschreiben?

Die Leistung ist in einer mobilen App vernachlässigbar, und die Verwendung von Plattformkanälen mit C++ wäre praktisch, um mit vorhandenen C++-Bibliotheken zu interagieren.

Im Gegenteil, die Verwendung von Kanälen ist in diesem Zusammenhang suboptimal. Denken Sie an Anwendungsfälle, in denen Sie mit einem großen binären Objekt im Speicher (Bildern) arbeiten müssen. Sie müssen entweder:
1- Kopieren Sie diese Binärdateien vom/in den C++-Speicher
2- Arbeiten Sie mit JNI, um eine Schnittstelle mit der Bibliothek herzustellen (und die diesen Binärdateien dynamisch zugewiesenen Zeiger zu behandeln)
ganz zu schweigen von den Kosten für das Serialisieren/Deserialisieren von Werten/Parametern, die Ihnen durch die Verwendung der Kanäle entstehen.

Ein gutes Framework ist ein Gleichgewicht zwischen den neuen Features/Paradigmen, die es einführt, und der einfachen Integration in das aktuelle Ökosystem/die aktuelle Legacy, von der wir nicht leugnen können, dass C++ ein Teil davon ist.

@nhachicha @csga5000 widersprach nicht, dass die direkte Integration von C++ wichtig sei; Er antwortete auf einen früheren Kommentar, in dem er gefragt wurde, ob Flutter direkt aus C++ verwendet werden könnte , wie in, ohne dass Dart-Code benötigt wird.

Die Leistung ist in einer mobilen App vernachlässigbar, und die Verwendung von Plattformkanälen mit C++ wäre praktisch, um mit vorhandenen C++-Bibliotheken zu interagieren.
@nhachicha Ich kann nicht mehr zustimmen.

Die Wahrheit gilt für Anwendungen, die keine Leistung beim Zähnebeißen benötigen (was viele sind). viele beliebtere/etabliertere Sprachen als Dart):

• C#/.Net Core-Laufzeit
• Javascript/Typescript V8-Laufzeit (Sie hätten zu diesem Zeitpunkt fast einen Browser, aber was soll's)
• Rost (auch schnell!)
• GoLang
• Python
• [Fügen Sie hier Ihren Favoriten ein]...

Und so sehr ich persönlich einige dieser Sprachen liebe und jeden Tag verwende, sind C und C++ der Kern von Linux, also Android, iOS und Desktop-Plattformen wie Windows, MacOS und andere Desktops. Die Hälfte der oben genannten Sprachen (einschließlich Dart) ist in C++ geschrieben. Spitzentechnologien erfordern immer wieder eine abgestimmte native Leistung wie KI (Tensorflow ist C++, Caffe C++, Pytorch ist C unter Python usw.), Augmented Reality-Bibliotheken, AAA-Game-Engines und alles, was in die Nähe einer GPU (CUDA , aufgerufen aus C/C++).

Aus dem gleichen Grund, aus dem die Flutter-Rendering-Engine selbst in C++ geschrieben ist (nativ, hohe Leistung, Batterie-/Speicher-/CPU-effizient), wäre es meiner Meinung nach super, bei Bedarf die bestmögliche Leistung freizuschalten, ohne sich einer verwalteten Laufzeit zu nähern und unterstützt einfach C++. Dies würde Flutter von anderen Frameworks wie Xamarin und Nativescript unterscheiden, die ehrlich gesagt eine ähnliche Entwicklungserfahrung bieten (nachdem sie beide verwendet haben), nur mit unterschiedlichen Sprachen.

_Nebenbei bemerkt, ich bin absolut zu Hause damit, alles in C/C++ zu schreiben, von der Formularvalidierung bis hin zu Pixel-Shadern, aber ich behaupte nicht, dass dies die Ansicht vieler Leute ist, die sich dieses Repository ansehen - und das liegt daran, dass C++ für mich ein sehr produktive Sprache - aber völlig eine persönliche Entscheidung._

Dies ist einer der Hauptgründe, warum wir die C++-Integration brauchen

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

Es gibt zwei einfache Möglichkeiten für die C/C++-Integration:

• Bereitstellung der Methodenkanalimplementierung in C++
• Bieten native Unterstützung für Dart VM-Erweiterungen

Leider haben beide große Nachteile, die uns daran hindern, sie zu verfolgen:

• Methodenkanäle sind Abstraktion mit hohem Overhead – während C/C++-Integration angefordert wird, wenn Interaktionen mit geringem Overhead erwünscht sind. Das bedeutet, dass Methodenkanäle das Problem nicht wirklich lösen würden.
• Die nativen Erweiterungen von Dart VM erfordern die Verwendung der Dart VM C-API. Es ist möglicherweise nicht wünschenswert, zu viele externe Abhängigkeiten davon einzuführen, insbesondere angesichts der Tatsache, dass die API nicht gut gealtert ist und einige ernsthafte Überarbeitungen erfordert.

Es scheint, dass eine wünschenswertere Alternative die Einführung von dart:ffi - einer Kernkomponente von Dart VM, die es ermöglichen würde, direkt an nativen Code zu binden und es den Leuten zu ermöglichen, etwas zu schreiben wie:

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);

Wir hatten schon lange ein gewisses Interesse daran, ein solches FFI zu implementieren - ich würde erwarten, dass wir in naher Zukunft damit experimentieren, aber ich würde mich nicht auf konkrete Zeitpläne festlegen.

@kirbyfan64 Ist genau richtig, @nailgilaziev , @bytesoftly Ich versuche nicht zu sagen, dass die C++-Integration nicht erforderlich ist, ich habe nur gesagt, dass es nicht so viele Gründe / Nachfragen gibt, um Flatter C++ INPLACE von Dart zu unterstützen - aber Ich sage nicht, dass Integration nicht nötig ist. Was @mraleph sagt, klingt für mich schlau.

@mraleph Das Dartino hatte eine ähnliche Implementierung für FFI . Wie schwer ist es, wieder aufzuerstehen?

@listepo Teile davon. Dartinos Implementierung von FFI war sehr dynamisch - das wollen wir nicht für Dart 2, das wesentlich statischer ist als Dart 1.

Zu spät zum Spiel, aber hier ist ein anderer Anwendungsfall: Wir möchten C-Dateien und -Methoden für kryptografische Zwecke in Dart einbinden.

Was wir uns erhoffen sind folgende:
1) Identischer Code für iOS und Android, dh kein Durchlaufen von ObjC- oder JNI-Schichten.
2) Hoffentlich eine effizientere Implementierung, als wenn Sie zB JNI zweimal durchlaufen.
3) Möglichkeit, den Dart-Modellcode in einer nachfolgenden Web-App, z. B. in AngularDart, oder nachfolgenden Desktop-Apps mit diesem Projekt wiederzuverwenden: https://github.com/google/flutter-desktop-embedding

Ich glaube, was wir wollen, kommt dem oben erwähnten Punkt 2

Würde dies bei Verwendung von FFI, wie von @mraleph vorgeschlagen , 1)-3) wie in meinem vorherigen Kommentar ermöglicht werden, oder würde dies bedeuten, dass auf verschiedenen Plattformen (Android, iOS, ...) ein anderer Code benötigt wird?

@CryptUser Wenn Ihr C/C++-Code auf allen Plattformen gleich ist, wäre der Dart-Code zum Aufrufen über FFI auch auf allen Plattformen gleich.

@mraleph Klingt toll! Gibt es angesichts der Tatsache, dass die ursprüngliche Ausgabe über 200 Daumen hoch hat, eine Chance, die Priorität zu erhöhen?

@mraleph gibt es irgendwo ein offenes Problem für FFI in Dart?

@dnfield Ich habe gerade einen eingereicht https://github.com/dart-lang/sdk/issues/34452

Ich würde gerne C/C++/Rust-Code schreiben und ihn über ffi . verwenden können

Beispiel:

Ich teste Flattern auf einem Android-Tablet (Android 4.4).
flattern schnell laufen.
Aber wenn ich versuche, 1000 Zeilen mit sqflite zu lesen, die den Plattformkanal verwenden, ist es lächerlich langsam.
Der Grund: Ich kann den SQLite-Cursor-Reader nicht verwenden.

aber wenn ich direkt die sqlite-Bibliothek verwenden könnte, ist die gleiche Abfrage sofort. (getestet mit xamarin und nativem Android-Projekt).

Wir diskutieren gerade, wie wir das am besten angehen. Wie oben in https://github.com/flutter/flutter/issues/7053#issuecomment-377711814 erwähnt, besteht dieses Problem aus vielen Teilen und muss wahrscheinlich aufgeteilt werden. :)

Wir haben jedoch einige Ingenieure gefunden, die daran interessiert sind, ein FFI zu untersuchen (wie in https://github.com/flutter/flutter/issues/7053#issuecomment-415161464) angegeben. Unser Fokus liegt im Moment darauf, 1.0 aus der Tür zu bekommen, aber sobald dies erledigt ist, wird dies ganz oben auf der Liste stehen. Nochmals vielen Dank für Ihr kontinuierliches Feedback. Wir werden dieses Problem aktualisieren, wenn wir weitere Fortschritte zu teilen haben.

Ich bin auch Matlab/Simulink-Benutzer. Ich kann hochoptimierten CPU-spezifischen c/cpp-Code generieren. Ich möchte meinen Algorithmus in Flattern integrieren. Ich habe viele Bildverarbeitungsalgorithmen. Ich brauche einen Binding-Generator für native Codes. Sonst vergesse ich all meine Dart-Flatter-Erfahrungen und fange an, xamarin oder etwas zu lernen, das zu mir passt.

Können wir den Fortschritt beschleunigen?

Es ist so ein großer Schmerz, zwischen Dart und C.

Wenn Sie den Prozess beschleunigen, wird dies wahrscheinlich nicht zu einem qualitativ hochwertigen Produkt führen. Es wird fertig sein, wenn es fertig ist. :-)

Wenn Sie den Prozess beschleunigen, wird dies wahrscheinlich nicht zu einem qualitativ hochwertigen Produkt führen. Es wird fertig sein, wenn es fertig ist. :-)

Nun, was ich sagen wollte, war, dass wir die Priorität möglicherweise erhöhen sollten, damit wir mehr Ressourcen und Anstrengungen auf die Lösung dieses Problems verwenden können. Sie wissen, dass es derzeit 1386 offene Probleme mit dem Ziel "Ziel" gibt, die "in den kommenden Jahren behoben" werden.

Nachdem ich den Thread noch einmal gelesen habe, ist mir aufgefallen, dass

"Ziel" kann der falsche Eimer sein. :) @mraleph hat jemanden, der https://github.com/dart-lang/sdk/issues/34452 untersucht, während wir sprechen. Das ist zumindest ein Teil einer Lösung.

Hier ist das Vision-Dokument für das FFI, das wir derzeit auf der Dart-Seite prototypieren.

Schauen Sie doch mal rein und teilen Sie uns Ihre Meinung mit.

Zum FFI-Teil kann ich nicht viel sagen, da ich so etwas noch nie benutzt habe,
aber ich frage mich, wie die Pub-Integration aussehen wird.

Wie würden Veröffentlichungspakete gehandhabt, die FFI verwenden?
Wie würde der Verbrauch von Paketen gehandhabt, die FFI verwenden?

@zoechi wir haben die pub Integration noch nicht besprochen.

Sie sollten in der Lage sein, ähnlich wie heutige Flutter-Plugins zu arbeiten - plattform-/architekturgerechte Quellen und/oder Binärdateien einschließen, die in die konsumierende Anwendung kompiliert/verknüpft werden können.

Aus Pub-Sicht sollte das keine große Sache sein – außer dass möglicherweise größere Binärdateien im Paket enthalten sind.

Es müsste jedoch einige Arbeit rund um das Flutter-Tooling-Ende der Dinge geleistet werden, um sie in Flutter-Projekte zu integrieren - sie würden nicht wirklich so funktionieren wie Android/iOS-Plugins heute.

Sollte die Pub-Integration in ein Dart-Lang/Pub-Problem verschoben werden, um dieses Problem stärker zu fokussieren?

Ich habe 'Vision Doc' gelesen und sehe endlich Formen durch den Nebel.

In der Zwischenzeit dachte ich über etwas ganz anderes nach.

Nämlich Flatbuffer (wieder) zu verwenden, um so etwas wie NativeChannels zu machen. Bei der Ausführung (AOT) würde es auf die Übergabe von Zeigern hinauslaufen, während ich zur Entwicklungszeit vorhandene Tools für die "native" Seite nutzen konnte, die nicht nur in C/C++, sondern auch in Go oder Rust geschrieben wurde.

Der Message-Passing-Ansatz entspricht auch mehr aktuellen Stream-basierten Architekturen (Bloc, Rx). Es macht auch jegliche Bedenken hinsichtlich der Speicherverwaltung überflüssig, da der Compiler gegebenenfalls geeignete Ringpuffer generieren oder einfache 'Aufgerufene freigeben' annehmen könnte, wenn ein Aufgerufener Daten länger speichern muss.

Aber um ehrlich zu sein, werde ich jede Form von ffi begrüßen, wenn sie sich nahtlos in das Ökosystem von Flutter (Fuchsia) einfügt und ich CPU-optimierten nativen Code aus der Dart-App heraus verwenden kann.

@ohir, was Sie sich vorgestellt hatten, wäre eine andere Lösung für einige der Probleme, die auftreten können. Dieser Fehler hat sich zu einem Allzweck-Catchall für alles, was mit C++ zu tun hat, entwickelt. :/ Ich vermute (wie ich in früheren Kommentaren bemerkt habe), dass wir diesen Fehler in kleinere aufteilen müssen. Die Arbeit von FFI ist möglicherweise nicht die einzige Lösung, die wir in diesem Bereich entwickeln.

@eseidelGoogle gibt es diesbezüglich Fortschritte? Im Moment haben wir ein Projekt, das schwere Videoverarbeitungsaufgaben implementieren muss, die möglicherweise über ffmpeg ausgeführt werden können, da das aktuelle Dart-Paket keine praktikable Lösung bieten kann. Wir warten gespannt darauf, dass Flutter ffmpeg lib direkt aufruft.

Für diese Seite-zu-Seite-UI-basierten Apps ist Flattern meiner Meinung nach wirklich eine gute Wahl, als sich auf die doppelte Codierung sowohl auf Android als auch auf iOS zu konzentrieren verändert sein. Allerdings sind die Vorteile von Flattern im Moment nicht so atemberaubend für Unternehmen, die dorthin migrieren, da sie mit dem alten Weg bereits gut genug gemacht haben, aber für einige Nicht-UI-Aufgaben liegt Dart weit hinter der obersten Anforderung zurück.

Es bedeutet nicht, dass Dart eines Tages für diese Aufgaben nicht gut oder praktikabel ist, aber aus der Sicht eines normalen IT-Unternehmens, das möglicherweise in das Flatter-Ökosystem eingebunden ist, müssen die Kosten durch den Einsatz eines Cross- Plattform-Codierungsmethode nur dann, wenn die coolsten Funktionen erreicht werden könnten, wie z. B. clientseitige Datenverarbeitung, Video/Audio, AR-Mitarbeiter usw. es ist wirklich schwer für sie, es mit dart lang neu zu implementieren oder neu zu erfinden.

und die Schlüssellösung besteht darin, die direkte und effiziente Möglichkeit für Flatter zur Kommunikation mit c++ einzuführen. Ich denke sogar, dass dies die erste Priorität einer "plattformübergreifenden" Sache ist, Dart für UI-Mitarbeiter ist perfekt, etwas normale Datenlogik kann auch sein in Dart gemacht, aber es ist viel besser für Flatter, in das lange, aber immer noch aktive und effiziente c++-Ökosystem zu verschmelzen, anstatt ein heiliges neues zu bauen!

Der Traum von einer echten "plattformübergreifenden" Programmiererfahrung ist das Dart-UI-Personal mit C++ hinter der Haube, überhaupt kein Java-Code, kein OC-Code. wahaha, ich kann es kaum erwarten zu sehen, dass es passiert!

@smellbee Können Sie die ffmpeg-Befehlszeile nicht verwenden?

@smellbee Ich bin nicht der Richtige, um darauf zu antworten. @eseidelGoogle gibt es dazu Neuigkeiten?

@smellbee Können Sie die ffmpeg-Befehlszeile nicht verwenden?

Es ist eine clientseitige Arbeit, bei der ffmpeg lib zum Rendern von Videoframes verwendet wird, um einen sofortigen Feedback-Stream zu erzeugen. Ist es möglich, die Befehlszeile zu verwenden?

@smellbee Ich bin nicht der Richtige, um darauf zu antworten. @eseidelGoogle gibt es dazu Neuigkeiten?

Entschuldigung dafür, ich habe "es" eingegeben und es wurde automatisch vervollständigt, ich habe es nicht bemerkt .... hoffe @eseidelGoogle kann es sehen

Die Arbeiten auf der Dart-Seite sind im Gange - wir hoffen, im ersten Quartal 2019 etwas fertig zu haben.

Es ist ein großes Feature, und wir möchten es richtig machen: Da wir es in verschiedenen Ausführungsmodi für Dart gut funktionieren lassen möchten, haben Sie bitte Geduld, wenn wir die Details ausarbeiten.

Sie können dart-lang/sdk#34452 folgen, das die Arbeit auf der Dart-Seite verfolgt.

Dart FFI ermöglicht den Aufruf von C-Funktionen von Dart.
Aber was ist mit den C++-Features - Klassen, Standardcontainer, intelligente Zeiger, Ausnahmen?
Können wir die Möglichkeit erwarten, C++-Klassen mit minimalem Boilerplate nach Dart zu exportieren?

Ein weiteres sehr wichtiges Feature ist die asynchrone Unterstützung – die Möglichkeit, C++-Code in einem separaten Thread auszuführen und Future/Stream von Methoden zurückzugeben.

@t-artikov Es gibt derzeit keine Pläne, die C++-Interoperabilität direkt zu unterstützen. Das ist zu kompliziert. Das einzige, was ergonomisch mit C++ interoperieren kann, ist C++.

Wenn Sie an High-Level-Interop mit C++ interessiert sind, müssen Sie Ihre eigene Interop-Schicht erstellen, die Ihre C++-API über eine C-ähnliche API verfügbar macht.

Ein weiteres sehr wichtiges Feature ist die asynchrone Unterstützung – die Möglichkeit, C++-Code in einem separaten Thread auszuführen und Future/Stream von Methoden zurückzugeben.

Ich denke, das kann als Paket gebaut werden. Wir sollten nur sicherstellen, dass wir die richtigen Primitive bereitstellen, damit dies gebaut werden kann.

Dart FFI ermöglicht den Aufruf von C-Funktionen von Dart.
Aber was ist mit den C++-Features - Klassen, Standardcontainer, intelligente Zeiger, Ausnahmen?
Können wir die Möglichkeit erwarten, C++-Klassen mit minimalem Boilerplate nach Dart zu exportieren?

Solange es eine Möglichkeit für C++ gibt, dart aufzurufen， Ich denke, diese Dinge sind möglich， C++ kümmert sich darum, worüber sich C++ Sorgen macht， und kommuniziert mit dart durch Aufrufen oder Aufrufen, keine Notwendigkeit, Manipulationen auf niedriger Ebene auszusetzen Dart, die die Benutzerfreundlichkeit von Dart zerstören wird.

Ein weiteres sehr wichtiges Feature ist die asynchrone Unterstützung – die Möglichkeit, C++-Code in einem separaten Thread auszuführen und Future/Stream von Methoden zurückzugeben.

Und dart hat bereits seinen asynchronen Mechanismus, also macht es keinen Unterschied, ob ein Thread C++ orientiert ist oder nicht, solange der C++-Teil dart bei Bedarf aufrufen kann und ein "Isolate" die Arbeit erledigen kann.

Das denke ich @mraleph , korrigiert mich wenn ich falsch

@mraleph
Tatsächlich gibt es Beispiele für großartige C++-Interop mit anderen Sprachen.
https://github.com/boosorg/python
https://github.com/ThePhD/sol2
https://github.com/dropbox/djinni
Ich hoffe, Dart/Flutter bietet einen ähnlichen Mechanismus aus der Box.

Wenn Sie an High-Level-Interop mit C++ interessiert sind, müssen Sie Ihre eigene Interop-Schicht erstellen, die Ihre C++-API über eine C-ähnliche API verfügbar macht.

Um zu verdeutlichen, wie dieser Ansatz anwendbar ist, könnten Sie ihn bitte am Beispiel der folgenden С++-Klassen demonstrieren:

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);
};

Damit es von Dart . verwendet werden kann

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

@t-artikov sowohl boostorg::python als auch sol2 veranschaulichen meinen Standpunkt sehr gut. Beachten Sie, dass dies C++-Bibliotheken für die Zusammenarbeit mit anderen Sprachen sind und nicht umgekehrt. Dart FFI ist eine Dart-zentrierte Methode zum Aufrufen von C-APIs, keine C++-zentrierte Methode zum Aufrufen von Dart.

Um zu verdeutlichen, wie dieser Ansatz anwendbar ist, könnten Sie ihn bitte am Beispiel der folgenden С++-Klassen demonstrieren:

Sie müssten so etwas schreiben (oder mit einem Tool generieren).

// 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); }
}

Beachten Sie, dass dies C++-Bibliotheken für die Zusammenarbeit mit anderen Sprachen sind und nicht umgekehrt.

Sie irren sich, sie ermöglichen es, C++-Klassen für andere Sprachen bereitzustellen.
https://www.boost.org/doc/libs/1_68_0/libs/python/doc/html/tutorial/tutorial/exposing.html

Vielen Dank für Ihr Dart FFI-Beispiel.
Es gibt einige Fehler: Die C++-Ausnahme sollte an die Dart-Seite übergeben werden; und das MyObject.data wird auf diese Weise nicht funktionieren (es bekommt nur den Zeiger, aber nicht die Datengröße).
Aber die Idee ist klar.

Meiner Meinung nach ist ein solcher Code zu ausführlich, um ihn manuell zu schreiben.
Ich bin gespannt, ob dieser Vorgang für die neuen Dart FFI Flutter Engine Bindungen automatisiert wird.

Die Laufzeitbindung für die C++-Interoperabilität ist nahezu unmöglich (wie gehen Sie mit Generika, Mehrfachvererbung, Operatorüberladungen, verstümmelten Namen usw. um). Es gab viele harte Versuche (BridJ, CppSharp usw.), und meines Wissens halten die Leute C-Interop für die praktikabelste Option.

Es gibt unwahrscheinlich eine sehr generische Lösung, die offizielle Entwickler von Interoperabilität für C++ erreichen können. Kotlin/Native bietet das nicht. Scala-native dh. .NET entweder (Microsoft C++ Interop ist immer entweder seltsam oder statisch). JNI unterstützt C++-Interop nur bei statischer Kompilierung. So etwas wie Python-Boost-Kleber muss manuell geschrieben werden. Jede Drittpartei-Gruppe kann Dinge wie JNAerator entwickeln (dh SIE können es tun, Sie müssen nicht erwarten, dass Dart / Flutter-Teams dies erreichen).

Nach diesem Gespräch ohne wirkliche Antwort denke ich, dass ich bei Qt bleiben werde, das Cross-Plattform ist und volle C++-Unterstützung bietet. Ich dachte nur daran, Flutter für mein nächstes Projekt auszuprobieren, aber jetzt werde ich es nicht tun, vielen Dank!

Es hätte besser sein können, wenn flatter in C++ geschrieben worden wäre, womit Interop mit jeder anderen Sprache problemlos möglich gewesen wäre. Gibt es einen Versuch, Flatter in C++ neu zu schreiben?

Ich denke, die Diskussion wird jetzt unnötig in die Länge gezogen.

Wir wissen, was auf der Entwicklungs-Roadmap von Flatter steht (oder nicht steht).
Dementsprechend können wir entscheiden, es für bestimmte Anwendungsfälle zu verwenden (oder nicht zu verwenden).

Ich sehe keinen Nutzen darin, die Entwicklungsagenda zu ändern, oder
darüber hinaus eine konkrete architektonische Umsetzung verlangen.

Vielen Dank,
Gaurav

Am Montag, 25. Februar 2019, 22:51 Uhr schrieb bhauj, [email protected] :

Es hätte besser sein können, wenn flatter in C++ geschrieben worden wäre, mit
welche Interoperabilität mit jeder anderen Sprache leicht möglich gewesen wäre. Ist
Gibt es einen Versuch, Flattern in C++ neu zu schreiben?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/flutter/flutter/issues/7053#issuecomment-467098455 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AZ86acDpZgNeyezx40uxe_c5E2xZHWxaks5vRBumgaJpZM4K-PLw
.

Eigentlich ist Flutter, wie ich weiß, in C++ geschrieben, aber die Programmierung in Flutter kann nur mit dem Interpreter Language Dart erfolgen, der in einer VM läuft. Aber Sie haben noch keine Chance, von Dart zum C++-Teil von Flutter zu gelangen...

Wer also dies liest und den gemeinsamen Anwendungsfall in der App-Entwicklung von guter Cross-Platform-Entwicklung hat, Flutter wird die direkte Verwendung von C++ nicht erlauben, wenn Sie es brauchen, dann verwenden Sie ein anderes Cross-Platform-Framework wie Qt C++.

Für mich ist C++ essenziell für Cross-Plattform-Entwicklung, weil es der kleinste gemeinsame Nenner in fast jeder Technologie ist.

@aqmappdesigners

Interpreter Language Dart, der in einer VM läuft

Das ist nicht richtig.

Flutter verwendet die Dart VM im Debug-Modus, wodurch auch Hot-Reload möglich ist.
In Release-Builds wird Dart in Binärcode wie C++ kompiliert.

@zoechi Danke, das wusste ich nicht. Das klingt gut für die Leistung

Das klingt gut für die Leistung

und ist eine Voraussetzung für Apples App Store.

Der dart:ffi Prototyp ist so weit fortgeschritten, dass wir über API-Entscheidungen entscheiden. (Einige Designentscheidungen werden hier besprochen.)

Um fundierte Designentscheidungen treffen zu können, möchten wir weitere Beispiele dafür, welche C-APIs Sie binden möchten. Bisher erwähnt diese Ausgabe SQLite, Realm, OpenCV, Superpowered und ffmpeg. Gibt es andere APIs, die wir in Betracht ziehen sollten?

@dcharkes Ich weiß nicht, ob es hilft, aber Telegram in Android vernetzt in C++ über JNI:
https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/jni/TgNetWrapper.cpp
Es verarbeitet auch die GIF-Wiedergabe mit ffmpeg und schreibt direkt auf Android-Bitmaps:
https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/jni/gifvideo.cpp

Es könnte interessant sein, eine Möglichkeit zu haben, Telefone und Adressen über libphonenumber und libpostal für Registrierungsformulare zu parsen. Auch glfw + -embedder und vielleicht sehen wir eines Tages eine komplett in Dart geschriebene Desktop-App.

+1 für SQLite und Realm. Bitte schauen Sie sich auch Couchbase an , sie haben einen gemeinsamen C++-Kern mit einem C-SDK.

Wäre die Firebase C++ API interessant? https://firebase.google.com/docs/reference/cpp/

Ich habe mich nicht viel damit befasst, dachte aber, dass die iOS- und Android-Plugins möglicherweise durch ein einziges Plugin ersetzt werden könnten, das direkt mit C++ kommuniziert.

Einige Kryptobibliotheken sollten etwas Liebe wie einen Ring von Rost bekommen - https://github.com/briansmith/ring

+1 für OpenCV, Realm, SqlCipher (https://github.com/sqlcipher/sqlcipher)

Kryptographie-Bibliotheken. Besonders Libnatrium oder Tink.

https://github.com/google/tink

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

Es gibt bereits eine Flatter-Natrium-Bibliothek, die über Plattformkanäle mit libsodium-Wrappern auf jeder Plattform kommuniziert, dann mit nativen.

Benutzerdefinierte Mapping-Bibliotheken wie mapbox-gl https://github.com/mapbox/mapbox-gl-native

SMTP / IMAP-Handling (für Chat-over-E-Mail) für Flutter über https://github.com/deltachat/deltachat-core würde ich gerne direkt verwenden.

Wenn ich so mutig sein darf, zu paraphrasieren, sind die folgenden häufigen Anwendungsfälle:

1. Audio-/Video-Hardwarezugriff mit geringer Latenz (z. B. Superpowered)
2. Hardware-unterstützte A/V-Verarbeitung (wie ffmpeg)
3. TCP-basierter Socket-Zugriff für XMPP/andere netzwerkorientierte Protokolle
   (für Chat, Push-Benachrichtigungen)
4. Upgrades auf Prozessebene (Root-Zugriff) / Spawnen von Threads in
   plattformübergreifend kompatibel (für System-Apps, Multitasking, Emulatoren)

Es mag mehr Anwendungsfälle geben, aber dies sind die wichtigsten, die mir einfallen
Verstand.

Vielen Dank an alle für die Bereitstellung von Beispielen! Das ist sehr hilfreich.

@skills-up Beachten Sie, dass wir viel mehr an konkreten Beispielen interessiert sind als an abstrakten Klassifizierungen. Denn wir wollen die Ergonomie von FFI an konkreten Beispielen beurteilen.

Seltsamerweise ist Rust eine der Sprachen, die die beste Schnittstelle von/zu C++ bietet, über sein leistungsstarkes Makro + Build-System, obwohl es einen völlig anderen Ansatz für OO hat.

Ich würde OpenSSL sagen, da wir Soap-Requests und XML-Dateien (XMLDSig, Xades l) mit Client-Zertifikaten digital signieren müssen.
Dart selbst hat BoringSSL, aber nur ein Teil davon ist durch Dart verfügbar. Als nächstes ist es also am besten, native Openssl-Bibliotheken von Flutter aufzurufen

Ich hoffe, ich spamme nicht, aber ich würde mir auch eine bessere Integration mit tensorflow lite wünschen, ohne JNI zu verwenden, das wäre großartig für Videooperationen

Ich habe mich nicht viel damit befasst, dachte aber, dass die iOS- und Android-Plugins möglicherweise > durch ein einzelnes Plugin ersetzt werden könnten, das direkt mit C++ kommuniziert.

Abgesehen von der Unterstützung von C++ wäre es großartig, wenn es ein Plugin gibt, das direkt mit Go kommunizieren kann. Im Moment sprechen wir mit Go über die Kanäle der Gomobile- und Flatter-Plattform, was die Reaktionsfähigkeit der Benutzeroberfläche verlangsamt. Die native Unterstützung von Go und C++ in Flutter wird uns auch helfen, eine einheitliche Codebasis (Geschäftslogik/Algorithmus) für mehrere Plattformen aufrechtzuerhalten.

+1 für nativen Bibliothekszugriff.

Ich möchte auf Vulkan/MoltenVK zugreifen, ohne Plattformkanäle für Android/iOS erstellen und zwei Plugins verwalten zu müssen (die auch riesig wären). Dies würde es ermöglichen, 3D-Anwendungen zu erstellen und in ein Textur-Widget zu rendern, während nur in Dart entwickelt wird. Die Plattformkanäle scheinen nur ein hackiger Workaround zu sein. Ich möchte lieber auf native Bibliotheken zugreifen, ohne für jede Plattform einen Wrapper schreiben zu müssen, und sie warten, wenn es eine neue Version für diese Bibliothek gibt.
Ich denke, diese Funktion würde viel mehr Entwickler anziehen.

Ja, bitte direkter Zugriff auf die native Bibliothek von flattern.
Ich würde gerne eine C++-Bibliothek bei Flutter verwenden.

Ja, bitte direkter Zugriff auf die native Bibliothek von flattern.
Ich würde gerne eine C++-Bibliothek bei Flutter verwenden.

Wir sind jetzt an einem Punkt angelangt, an dem wir gerne eine frühe Vorschau anbieten möchten, um Feedback zu erhalten.

Einzelheiten entnehmen Sie bitte dem Update im Dart-Tracking-Bug .

@mit-mit Hilft dies bei diesem Problem: Kann ich die Python-Bibliothek mit Flattern aufrufen oder verwenden ?

Zu spät zur Party, aber +1 für SQLCipher @dcharkes @mraleph

@doc-rj wir sind jetzt in der Phase, in der Sie mit der Bindung von SQLCipher experimentieren und uns Feedback zu Ihren Erfahrungen geben können. Siehe diesen Kommentar .

Ich möchte betonen, dass wir nicht wirklich beabsichtigen, selbst spezielle Bibliotheksbindungen bereitzustellen - da die Anfragen sehr vielfältig sind -, aber wir möchten es jedem und jedem ermöglichen, an jede Bibliothek mit einer C-API zu binden.

Ich denke, der Bedarf dafür steigt jetzt, da Multiplattform angekündigt wurde.

Ist das Teil einer Roadmap?

@felemedeiros die Arbeit ist im Gange - wenn Sie eine Bibliothek haben, an die Sie sich mit FFI binden möchten, empfehle ich dringend, mit der Arbeit an den Bindungen zu beginnen, um uns Feedback zu geben. Weitere Informationen finden Sie in diesem Kommentar .

Ich habe mich nicht viel damit befasst, dachte aber, dass die iOS- und Android-Plugins möglicherweise > durch ein einzelnes Plugin ersetzt werden könnten, das direkt mit C++ kommuniziert.

Abgesehen von der Unterstützung von C++ wäre es großartig, wenn es ein Plugin gibt, das direkt mit Go kommunizieren kann. Im Moment sprechen wir mit Go über die Kanäle der Gomobile- und Flatter-Plattform, was die Reaktionsfähigkeit der Benutzeroberfläche verlangsamt. Die native Unterstützung von Go und C++ in Flutter wird uns auch helfen, eine einheitliche Codebasis (Geschäftslogik/Algorithmus) für mehrere Plattformen aufrechtzuerhalten.

Ich habe einen Artikel darüber geschrieben, wie wir derzeit die Go-Bibliotheks-API von Flutter aufrufen. Es könnte für jemanden nützlich sein, der interessiert ist. https://medium.com/@archan.paul/using -go-library-in-flutter-a04e3496aa05

Wie kann ich der Flutter-App C++-Code hinzufügen?

Wie kann ich der Flutter-App C++-Code hinzufügen?

Ich denke, im Moment besteht die einzige Option darin, C++ -> JNI (für Android) -> PlatformChannel zu verwenden, bis wir eine elegantere Möglichkeit haben, dasselbe zu tun !!

Ich habe ein Projekt namens ezored (http://ezored.com) erstellt. Wäre schön, wenn ich komplexe Objekte an Flutter übergeben kann, ohne in andere Dinge konvertieren zu müssen, da es bereits in Java und objc vorhanden ist. Jeder kann ezored verwenden, um das SDK zu generieren (oder vorgefertigte herunterzuladen), um die Flutter-Integration zwischen nativem und Dart zu testen. Es hat Anfragen, Parsing, Crud mit Datenbank und viele Dinge im Demo-SDK bereits implementiert.

Ich suche in Flattergruppen, habe aber keine Möglichkeit, die Objekte und die Objektliste direkt an Flutter zu übergeben.

Danke für jede Hilfe.

Gibt es neue Fortschritte? Es scheint, dass mehr als 2,5 Jahre vergangen sind ...

@fzyzcjy wir arbeiten daran. Wir haben eine frühe Vorschau veröffentlicht. Unter https://github.com/dart-lang/sdk/issues/34452#issuecomment -482136759 erfahren Sie, wie Sie sich engagieren können.

Seit dieser frühen Vorschau haben wir Unterstützung für Intel 32, Arm 64 und Arm 32 hinzugefügt. Diese Plattformen sind noch nicht auf Stable oder Dev veröffentlicht, sie sind nur im Master-Zweig des Dart-SDK verfügbar. Fortschritte werden verfolgt hier .

@dcharkes Das freut mich sehr zu hören! Danke für deine tolle Arbeit!

Irgendein Fortschritt?

Statusaktualisierungen und zusätzliche Informationen finden Sie unter https://github.com/dart-lang/sdk/issues/34452. Der oberste Kommentar dort hat das neueste Update.

Ist die Verwendung von ffi mit ac-Bibliothek möglich, wenn Sie Flattern zum Erstellen einer Web-App verwenden?

Ist die Verwendung von ffi mit ac-Bibliothek möglich, wenn Sie Flattern zum Erstellen einer Web-App verwenden?

Das ist nicht wahrscheinlich. Theoretisch könnte es längerfristig mit WebAssembly unterstützt werden, aber daran arbeiten wir derzeit nicht.

@mit-mit really ？

Ist die Verwendung von ffi mit ac-Bibliothek möglich, wenn Sie Flattern zum Erstellen einer Web-App verwenden?

Das ist nicht wahrscheinlich. Theoretisch könnte es längerfristig mit WebAssembly unterstützt werden, aber daran arbeiten wir derzeit nicht.

Warum sollte es WebAssembly erfordern? Wenn Sie in Zukunft Leute bitten können, WebAssembly neu zu erstellen, können Sie sie jetzt bitten, ASM.js neu zu erstellen.

@nic-hartley Es ist eine gute Idee, aber die Herausforderung besteht nicht darin, den nativen Code zu kompilieren, sondern darin, die Brücke zwischen Dart (kompiliert als JS) und dem nativen Code zu schaffen, egal in welcher Form.

Das native FFI ist aus Performancegründen sehr niedrig und kann nicht einfach in asm.js oder WebAssembly übersetzt werden.

Zur Verdeutlichung meine ich, dass unsere Implementierung sehr niedrig ist – es ist sicherlich ein interessantes Feature, aber es würde beträchtliche Arbeit erfordern, um es zu liefern.

flattern ist nur ein Spielzeug, bis es c++ unterstützt

Ich bin hierher gekommen, um die gleichen Punkte von anderen zu wiederholen, dass, bis Flutter problemlos mit C++ interoperieren kann (ohne Brückenbibliothek und ohne Leistungseinbußen), es nie von großen Anwendungen mit Investitionen in vorhandene native Bibliotheken oder Anwendungen übernommen wird wo Leistung höchste Priorität hat.

Ich möchte anmerken, dass sogar React Native derzeit eine Brücke verwendet, sodass Flutter in Bezug auf die Implementierung eines FFI tatsächlich der Kurve voraus ist.

Die Integration mit C++ ist auf iOS mit AppKit trivial. Damit sollten wir vergleichen, nicht mit React Native.

UWP & C++ ist auch trivial.

Ich bin im Allgemeinen auch für die Party "Unterstützung von Dart FFI-Bemühen" ...

Xamarin ist möglicherweise ein geeigneterer Vergleich als UWP, aber die plattformübergreifenden Ansichten von Xamarin waren nicht annähernd so anpassbar wie die von Flutter und erforderten oft viel nativen Code, um anständig auszusehen.

Das ist nicht wahr. Im Gegensatz zu Flutter verfügt Xamarin über Plattformbindungen an die native API (dh Xamarin.iOS und Xamarin.Android), und es ist für App-Entwickler einfach, plattformspezifische Implementierungen in einer eigenen Sprache (C#/.NET) zu schreiben. Dieses Problem betrifft die Sprachfunktion und sollte nicht mit dem UI-Widget-API-Design vermischt werden.

Es gibt viele native API- Verwendungen, aber keinen nativen Codeaufruf, bei dem Flutter auf demselben Boot wäre (obwohl Xamarin dort kein Schreiben von Java oder ObjC erfordert, ohne Reflektions-Hack im App-Code). Für nativen Code wird selbst bei Xamarin.Android selbst (einem der Back-End-Plattform-Back-Ends) nur sehr wenig nativer Code verwendet, und App-Entwickler schreiben keinen nativen Code.

Und im Gegensatz zu React Native oder Xamarin soll Flutter sein komplettes Framework bereitstellen, daher ist es völlig fair, dass wir das gesamte Flutter-Framework mit Dingen wie AppKit vergleichen.

Es ist seltsam, dass niemand das Qt-Framework erwähnt, das allem anderen in Bezug auf die C++-Integration weit voraus ist

QT ist C++. Und hat zunächst eine ungünstige Lizenz.

Am Mo, 12 Aug 2019, 06:41 Uhr Vladyslav Stelmakhovskyi, <
[email protected]> schrieb:

Es ist seltsam, dass niemand das Qt-Framework erwähnt, das weit voraus ist
alles andere zur C++-Integration

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/flutter/flutter/issues/7053?email_source=notifications&email_token=AGDYMWXHTJUBUW64LEOO27TQEDSWNA5CNFSM4CXY6LYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJUBUWZ520de
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AGDYMWTNMTM7QUOY2BEIPM3QEDSWNANCNFSM4CXY6LYA
.

Qt ist C++ und QML (JS-Engine)
Welche Lizenz? LGPL? GPL? was ist daran falsch?

Zunächst einmal IANAL, aber wie ich es verstehe, ist der Großteil von Qt LGPL (die IDE usw. sind GPL), was bedeutet, dass es eine Sprache hat, die statisches Verlinken nicht ausdrücklich verbietet, es jedoch schwierig macht, die Lizenz einzuhalten, wenn Ihre Anwendung ist Closed-Source.

Technisch gesehen erfüllen Sie die Anforderungen der LGPL, wenn Sie nur LGPL verwenden und Ihre Objektdateien (und wahrscheinlich Anweisungen) bereitstellen, damit Benutzer möglicherweise erneut mit einer anderen Version der Bibliothek verlinken können. Aber ich bin mir ziemlich sicher, dass die Qt Company diese Tatsache nicht bewirbt, daher ist die gängige Auffassung, dass Sie keine statischen Bibliotheken bereitstellen können, was bedeutet, dass Sie Ihre App nicht im App Store veröffentlichen können, ohne die erpresserischen Lizenzgebühren zu zahlen. Und ich kann mich bei der Bereitstellung von Objektdateien irren, das ist nur mein Verständnis davon, und ich weiß nicht, ob das von Firmen gemacht wird.

Android ist einfacher, weil es dynamisch geladene Bibliotheken zulässt, die unter der LGPL expliziter erlaubt sind, aber ehrlich gesagt wäre auch dort statisches Verlinken vorzuziehen, um die App-Größe klein zu halten, was bedeutet, dass das gleiche Problem auftritt.

Hallo @cpboyd , ich glaube, ich sehe das aus der entgegengesetzten Richtung. Wir haben bereits Apps, die auf plattformspezifischen UI-Frameworks basieren, wobei jede Plattform es uns ermöglicht, unsere umfangreiche Sammlung bestehender C++-Bibliotheken zu nutzen. Ich verstehe, dass Flutter plattformübergreifend ist, was großartig ist, aber es sei denn, ich kann es tatsächlich verwenden (mit meinem vorhandenen Code), dann bin ich besser dran, einfach bei der nicht plattformübergreifenden Benutzeroberfläche zu bleiben. Der einzige Knackpunkt kommt, wenn ein zukünftiges Betriebssystem (zB Fuchsia) die Verwendung von Flutter & Dart erfordert, diesen Anwendungsfall jedoch nicht zulässt. In diesem Fall wird es wahrscheinlich von jedem mit großen vorhandenen Codebasen ignoriert.

Ich schätze, ich bin mir nicht sicher, ob Flutter / Dart mit "Web"-Apps entwickelt wurden (dh wo Backends im Web sind) oder ob die Bedürfnisse professioneller Desktop-Anwendungsentwickler ernsthaft berücksichtigt werden. Letztendlich können solche Entscheidungen die Anzahl und Qualität vieler Anwendungen in einem App Store beeinflussen. Wenn ich mit UIKit eine qualitativ hochwertige professionelle App für iOS schreiben kann, die Millionen von Zeilen vorhandenen Codes verwendet, aber nicht (mit nahezu null Leistungskosten), wenn ich für Fuchsia / Flutter / Dart entwickle, dann wäre das ein Betriebssystem und eine Plattform sein, für die ich nicht entwickeln würde.

Das Ziel meiner Beiträge ist es nicht, Flutter mit anderen plattformübergreifenden oder nicht plattformübergreifenden Bibliotheken zu vergleichen, sondern Anwendungsfälle hervorzuheben, die für eine Untergruppe von Entwicklern wichtig sind.

Das Dart FFI ist interessant, von der _sehr_ kurzen Lektüre des sqllite- Beispiels sieht es ähnlich aus wie C# mit PInvoke, aber leider ist das nicht für C++ geeignet, da entweder fast jeder Typ, mit dem Sie zu tun haben, umhüllt werden müsste, oder Sie müssten schreiben ein vollständig generisches typloses Schnittstellensystem zum Einschließen von C++. Keines davon ist besonders ansprechend, wenn man es mit der Leichtigkeit der folgenden Obj-C-Klasse vergleicht:

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

Oder UWP mit C++/WinRT:

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

Vielen Dank :-)

@Hixie @MarkIngramUK Keines davon ist plattformübergreifend, was mein Punkt war.
AppKit ist nur Apple, während UWP nur Windows ist.
Wenn Flutter Swift oder C# anstelle von Dart verwendet hätte, hätten wir vielleicht bereits das gleiche Maß an Unterstützung, aber das ist ein ganz anderes Argument.
Xamarin ist möglicherweise ein geeigneterer Vergleich als UWP, aber die plattformübergreifenden Ansichten von Xamarin waren nicht annähernd so anpassbar wie die von Flutter und erforderten oft viel nativen Code, um anständig auszusehen.
Mein Vorschlag bleibt trotzdem: Wer Flutter mit C++ nutzen möchte, sollte an der FFI-Preview des Dart-Teams teilnehmen und helfen, den Support für uns alle zu verbessern

Dieses Problem betrifft die Sprachfunktion und sollte nicht mit dem UI-Widget-API-Design vermischt werden.

@atsushieno Klar, und deshalb wäre diese Diskussion im Dart FFI-Forum produktiver ... Flutter ist der Rahmen. Dart ist die Sprache.

Keines davon ist besonders ansprechend, wenn man es mit der Leichtigkeit der folgenden Obj-C-Klasse vergleicht:

@MarkIngramUK Ich bin sicher, das ist genau die Art von Feedback, das das Dart-Team gerne unter https://groups.google.com/forum/#!forum/dart -ffi . sehen würde

Ich habe ein Projekt namens ezored (https://ezored.com), das ein C++-Bootstrap-Projekt für SDKs und Anwendungen in C++ ist. Wir verwenden in mobilen Projekten (Android und iOS). Ich warte darauf, dass FFI fertig ist, um ein Projekt zu erstellen, das das Standard-SDK für Flattern verwendet.

Wir haben keine Probleme mit C++ und die Zeit für die Entwicklung neuer Features wird verkürzt, da das SDK auf allen Plattformen den gleichen Code hat, wie Sie in der Standardimplementierung sehen können (poco-Projekt, openssl, sqlite, spezifischer Plattformcode integriert mit Brückencode usw.).

In meiner Variante ist dies der beste Weg:

• iOS und Android mit C++ Backend (ezored)
• Flutter und C++ als Backend

Fühlen Sie sich frei, dem Projekt einen Start hinzuzufügen :)

Kotlin Multiplatform könnte ein Workaround sein, kein perfekter Gedanke. Muss noch auf https://github.com/dart-lang/sdk/issues/34452 warten

Unity3d scheint irgendwie Flatter auf ihre Engine zu portieren, die auf C# VM basiert [1] - in dieser Welt ist es anständig, zwischen C# und C++ zu sprechen. Vielleicht lohnt es sich, einen Blick auf ihr Repo zu werfen, wie sie einige Probleme gelöst haben. Sie sagen: "UIWidgets ist hauptsächlich von Flutter abgeleitet". Ich würde mir auch das Reaction Native Camp und ihren neuen Ansatz mit TurboModulen ansehen - ihre Lösung könnte gegenüber dem Flatter-Ansatz einen Vorteil haben, da dies der Fall sein wird
1) sowohl synchron als auch asynchron und
2) es wird kein Rangieren geben und
3) wird nicht nur C, sondern auch C++ unterstützen

Ich leite beide Lager an.

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

Ab Dart 2.5 ist dies ( dart:ffi ) jetzt in der Vorschau:
https://medium.com/dartlang/announcing-dart-2-5-super-charged-development-328822024970

Großartige Neuigkeiten!

Mmm... Wird es ausreichen, Oboe mit Flutter zu benutzen?..

https://github.com/google/oboe

@rg4real Ja ! Sie müssen jedoch einige C-Wrapper schreiben, da die Oboe-Schnittstelle in C++ ist.

Anweisungen zu den ersten Schritten finden Sie unter https://github.com/flutter/flutter/wiki/Binding-to-native-code-via-FFI .

Sie können mein oboe-c.so , das ich für meine C#-Bindungen geschrieben habe, wiederverwenden, wenn das funktioniert https://github.com/atsushieno/oboe-sharp/tree/master/native

@sjindel-google , das sind tolle Neuigkeiten!

Ich muss also eine Brücke zwischen C++ und C-Code schlagen, indem ich Klassen und Funktionen erstelle. Und dann kann ich diese Klassen verwenden und diese Funktion aus einem Dart-Code aufrufen. Ich denke das ist richtig.

@atsushieno , danke. Ich schaue nach. Ich bin mir nicht sicher, wie man in meinem Fall Brücken baut (mangelnde Erfahrung). Aber haben Sie Ihr Gesamtziel des präzisen Spielens mit der Oboe erreicht? War es so gut?

@rg4real Ich habe das nur für eine einfachere API (im Vergleich zu OpenSLES) als für Audio mit geringer Latenz getan. Wenn ich es mit der Latenz wirklich ernst meinen würde, würde ich Xamarin.Android nicht verwenden. Wenn Sie von Oboe (oder AAudio dahinter) sprechen, verwende ich es in Fluidsynth und es funktioniert gut. Ich bin mir jedoch nicht sicher, "wie gut" AAudio mit OpenSLES verglichen wird.

Gibt es eine Anleitung zur Speicherverwaltung?

Wenn C++-Code mit new/malloc einen Speicher erstellt und zum Dart-Code zurückkehrt, wie kann dieser Speicher freigegeben werden.

c++-Code
void foo(char** out) {
*out = neues Zeichen[25];
}

So löschen Sie den Speicher, der |out| . zugewiesen ist variabel von Dartcode?

Wenn Sie Dart 2.5 verwenden, gibt es ein .free() auf Pointer . Wenn Sie sich im dev/master-Zweig befinden, wurde diese Methode um package:ffi https://github.com/dart-lang/ffi/blob/master/lib/src/allocation.dart#L70 verschoben

Laut Kommentar - "Es darf nur für Zeiger verwendet werden, die auf eine Weise zugewiesen wurden, die [allocate] entspricht." - free() kann nur verwendet werden, wenn Speicher mit der Methode allocate() zugewiesen wird.

z.B
ffi.Zeigerptr = ffi.Zeiger.zuordnen();
ptr.free();

Kümmert sich dies darum, Speicher freizugeben, der auf der C++-Seite entweder mit new oder malloc aus dem Dart-Code zugewiesen wurde?

Solange der Speicher über malloc zugewiesen wurde, entweder über Dart oder C++, kann er mit free freigegeben werden.

In Dart 2.6 verwenden wir DynamicLibrary.lookupFunction("free") , um free in Dart zu definieren, also ist es genau das gleiche free wie im C++-Teil des Programms. (Es sei denn, Sie verlinken mehrere Versionen von free in Ihre Binärdatei.)

Wir schließen dieses Problem, da diese Funktion jetzt allgemein (in der Beta-Phase) in allen Flutter-Kanälen verfügbar ist. Wir verbessern das Problem weiter. Bei detaillierten Problemen reichen Sie diese bitte unter https://github.com/dart-lang/sdk/issues/new ein.

c++-Klassen zu c-kompatibel zu machen, ist chaotisch. plz make Fähigkeit zum direkten Aufrufen von C++-Klassen

+1 Können wir C++-Unterstützung haben?

@KaungZawHtet und @fzyzcjy - bitte erwägen Sie dafür eine neue Ausgabe (wahrscheinlich in Dart-Lang statt Flattern) zu eröffnen.

Ich werde dieses Problem abschließen - es gibt viele Leute, das es abonniert hat, aber das ursprüngliche Ziel ist ziemlich klar gelöst.

Ja, für neue Ausgaben reichen Sie diese bitte über diesen Link ein: https://github.com/dart-lang/sdk/issues/new?labels=library-ffi ,area-vm