Flutter: Admite la integración con C / C ++ en el marco de complementos

@ jason-simmons sabe más sobre Gradle. Una vez que tengamos un .so, definitivamente puedo ayudar a cargarlo.

Encontré que en buildSrc hay otra propiedad para configurar la versión de compilación de Gradle. Después de actualizar a 2.2.2, he progresado y pude verificar las cargas .so y se puede llamar desde Java.

Presumiblemente, también necesitaríamos agregar una API C para enviar HostMessages desde el código C / C ++ a Dart.

Sí, por favor. Tengo la sospecha de que la devolución de llamada C-> Java puede no ser barata.

¿Algún avance en esto? Considerar Flutter para construir una aplicación multiplataforma que llama al código C ++ compilado en una biblioteca compartida, y este es el único punto de parada importante.

Esto es posible hoy (y @jtrunick lo hizo en su aplicación de envío), pero primero debes rebotar a través de Java u Obj-C.

es decir, puede usar https://flutter.io/platform-channels/ para hablar desde Dart a Obj-C / Java y luego desde Obj-C / Java llamar a su código C ++. Este error cubre la adición de soporte más directo para esto y, potencialmente, evitar el paso a través de Obj-C / Java.

Dado que Dart VM está implementado en C ++, ¿no debería haber una forma más fácil (aunque menos segura) de llamar directamente a las bibliotecas compartidas de C (por ejemplo, a través de dlopen)? ¿Cuánto cambio se requeriría para el soporte básico (inseguro / experimental)?

¿Hay algo como esto: https://www.dartlang.org/articles/dart-vm/native-extensions disponible en Android o iOS?

Hemos escuchado este requisito de un par de aplicaciones de Google:

• Una de esas aplicaciones escribió sus propias bibliotecas de C ++ para operar la cámara y reducir la latencia. Estas bibliotecas son específicas de la plataforma y están optimizadas para funcionar lo más rápido posible. Invocar estas bibliotecas con la latencia más baja posible es fundamental para este tipo de aplicaciones. Obligarlos a pasar por PlatformChannel + JNI no logrará eso en Android.

• Existen equipos móviles avanzados que escriben componentes de lógica empresarial en C ++ para poder compartirlos entre sus implementaciones de Android e iOS. Flutter, que admite la integración directa con esas bibliotecas, consolidaría aún más su posición de ser el mejor marco multiplataforma que existe.

No creo que esto sea un _debe tener_. Sin embargo, esta es un área en la que Flutter puede diferenciarse aún más de otras soluciones multiplataforma.

Una de esas aplicaciones escribió sus propias bibliotecas de C ++ para operar la cámara y reducir la latencia. [...] Obligarlos a pasar por PlatformChannel + JNI no logrará eso en Android.

¿Cuál fue su solución en Android para pasar de C ++ a Java y viceversa?

Si es realmente necesario, podemos permitir extensiones nativas de Dart en las plataformas móviles. En este momento, no exponemos los símbolos en dart_api.h . Tendremos que decidir lo siguiente antes de poder activar el interruptor:

• Descubra cómo hacer que el compilador AOT conozca el código de Dart cuyo único punto de entrada es de un método que puede no estar en la biblioteca dinámica principal del motor Flutter. De lo contrario, el pase de agitación del árbol puede eliminar el código.
• Proporcione orientación sobre la creación y el empaquetado de extensiones nativas (Gradle y Xcode para Android e iOS respectivamente).
• Proporcione algunas garantías de estabilidad ABI para las rutinas en dart_api.h . Aunque es mayormente estable, creo que todavía está evolucionando para dar cuenta de los distintos modos.

Hasta ahora, el mecanismo de canales de las plataformas parece haber sido adecuado para los casos de uso más simples.

¿Cuál fue su solución en Android para pasar de C ++ a Java y viceversa?

No he examinado a fondo su caso de uso. Parece que han escrito todos los bits que necesitan una comunicación de muy baja latencia en C ++. Preguntaré si usan algún JNI para casos de uso de rendimiento crítico (mi intuición es no).

Realmente depende de lo que podamos hacer del lado de Flutter. Si podemos proporcionar una interoperabilidad que sea significativamente más rápida que JNI, sería una gran victoria para estos equipos. Pueden reducir su base de código C ++ y cambiar más al lado de la aplicación. Si nuestro rendimiento de interoperabilidad es comparable al de JNI, no veo una gran victoria aquí. Probablemente podrían continuar con lo que están haciendo ahora y usar PlatformChannel.

Se trata de darles a estos equipos una razón adicional para cambiarse a Flutter. No he oído que esto sea un bloqueador, así que priorice en consecuencia.

Si entiendo lo que está diciendo correctamente, está diciendo que las soluciones actuales son tener toda la lógica (cámara + UI) en C ++ con lógica mínima en Java, y el deseo es mover la parte de UI de esta lógica a Dart, sin perder la interactividad de la cámara <-> UI de baja latencia.

¿Puedes hablar sobre cómo es su situación de enhebrado? ¿Tienen solo un hilo para cámara + interfaz de usuario?

@chinmaygarde podría acercarnos a resolver esto con su trabajo actual en la API de inserción.

+1

¿Algún progreso con este problema?

Ya hemos estado usando djinni para compartir lógicas en diferentes plataformas. Sería genial si pudiéramos tener interoperabilidad entre Dart y C ++, en lugar de tener que ir y venir a través de Java / Objc-C.

Si Dart puede integrarse con C / C ++, creo que es una gran idea para dispositivos móviles reutilizar una tonelada de biblioteca nativa y no es necesario vincularse a una plataforma específica usando JNI u Objective C ++.

¿Ha considerado https://github.com/mono/CppSharp? Ya tienen el análisis y AST en su lugar para c ++, así como soporte para múltiples lenguajes de destino. ¿Quizás podría crear un generador de Dart para CppSharp?

La integración de una base de datos basada en C ++ como Realm directamente en C ++ lograría un rendimiento significativo y un aumento de la productividad del desarrollador :-) Subir / bajar a través de JNI sería un desperdicio.

Estoy considerando Flutter para una aplicación de AR que hace visión por computadora (probablemente usando OpenCV), y una interoperabilidad Dart-C ++ eficiente y directa sería un punto positivo importante. Me imagino que muchas otras personas que hacen aplicaciones desafiantes en términos de computación podrían compartir esta necesidad.

¿Alguien puede confirmar que la interoperabilidad de C ++ todavía no está disponible? ¿Se puede hacer usando paquetes?

@tofutim La canales de plataforma y luego usar Obj-C / Java para interactuar con su código C ++. No es genial, pero es todo lo que tenemos en este momento.

¿Alguien puede confirmar que la interoperabilidad de C ++ todavía no está disponible? ¿Se puede hacer usando paquetes?

Para interoperar con bibliotecas de plataforma, el mecanismo de canales de plataforma sigue siendo la recomendación actual.

Un mecanismo más eficaz descrito en el documento de extensiones nativas se puede agregar trivialmente. Sin embargo, no conozco ninguna garantía de estabilidad ABI para los símbolos expuestos de dart_api.h . Si @ a-siva y @eseidelGoogle pueden confirmar que existen tales garantías, puedo comenzar a exponer esos símbolos lo antes posible. Opcionalmente, podemos crear un subconjunto de Tonic como envoltorios convenientes alrededor de la API de C para facilitar su uso desde C ++.

Tengo entendido que este error se trata de proporcionar una C-API y enlaces de herramientas para que sea fácil tener un complemento totalmente C / C ++ (no se requiere shimming Obj-C / Java, pero sigue siendo asincrónico a través de platform_channels).

No creo que debamos considerar métodos sincrónicos como extensiones nativas en este momento. (Pero, sinceramente, lo dejo a

@eseidel

No creo que debamos considerar métodos sincrónicos como extensiones nativas en este momento

¿porqué es eso?

El enfoque actual para llamar al código C es Dart -> Java -> C
Cruzamos JNI dos veces, ¿verdad?
primera vez: dart a Java través de los canales de la plataforma (bajo el capó se utilizó una llamada JNI , ¿verdad?)
segunda vez: Java -> C vía JNI

Como ejemplo, desde el punto de vista de las necesidades de mi proyecto, tener acceso a dart_api.h incluso sin garantía de estabilidad (como una característica experimental, por ejemplo) ya sería suficientemente bueno. Mi principal preocupación es mover grandes manchas de datos binarios (imágenes) desde el lado de Dart al lado de C y viceversa sin ordenar e idealmente copiar. Unity / Mono lo logra .

Desde el número 31960 de dart-sdk, entiendo que la implementación actual de los aislamientos podría no permitir pasar datos sin copiarlos (aunque en teoría debería ser posible detectar que el búfer creado en el aislamiento A no se usa más después de pasar al aislamiento B y por lo tanto su propiedad puede ser transferida, sin copiar ... ¿algún plan en ese frente?), pero si al menos dentro de un aislamiento no hay clasificación hacia / desde C , sería bueno.

Marshalling podría evitarse con flatbuffers que parece aterrizar pronto: https://github.com/google/flatbuffers/pull/4676
O con mensajes protobuf usando un solo campo de bytes.

Por supuesto, esto implica una gran cantidad de copias de bytes, por lo que no es ideal para todos los casos de uso.

Escucho al menos tres deseos diferentes presentados aquí:

1. Me gustaría una forma de escribir fácilmente un complemento para Flutter usando solo código C / C ++ sin tener que agregar un montón de pegamento Java / Obj-C (esa fue mi comprensión original de este error y algo que definitivamente creo que podríamos / deberíamos hacer) .
2. Quisiera una forma de mover un gran volumen de datos dentro / fuera de Dart rápidamente / con baja latencia / etc. (Presumiblemente de una variedad de lenguajes, incluido C ++. ¡Esto suena como un caso muy válido! Recomiendo encarecidamente presentar un error por separado que incluya un ejemplo).
3. ¿Le gustaría una forma de extender Dart con llamadas / objetos sincrónicos? (¿Por ejemplo, extensiones nativas u otros métodos? Esto también es totalmente factible. Existen posibles dificultades en torno a la estabilidad de la API, y creo que nos gustaría aprender más sobre el caso de uso específico antes de tomar medidas).

Mi comentario al leer lo anterior es que deberíamos considerar separar algunos errores adicionales. Definitivamente necesitamos invertir algo en C ++ inter-op, pero es difícil determinar a partir de este largo hilo qué casos de uso exactos debemos abordar y en qué orden.

¿Estarían las partes interesadas dispuestas / capaces de presentar nuevos errores con sus casos de uso deseados y vincularlos aquí? Feliz de dejar este tema abierto para rastrear el interés general en este espacio de problemas.

Con respecto al rendimiento y 2. arriba: aunque estoy seguro de que el rendimiento de los canales de plataforma de Flutter podría mejorarse (y que probablemente necesitemos otros métodos de plugin / inter-op para cubrir todos los casos de uso), querremos algo concreto casos de uso (¿tal vez existen y no los he visto?) donde el rendimiento de los canales de plataforma de Flutter es un cuello de botella antes de que tomemos medidas. Mi experiencia con la optimización del rendimiento de los sistemas es que mis instintos a menudo están equivocados. Aunque cosas como JNI o ​​platform_channels se sienten como posibles cuellos de botella, en realidad no lo sabremos hasta que midamos.

¡Gracias de nuevo a todos por su ayuda y comentarios!

Me gustaría una forma de escribir fácilmente un complemento para Flutter usando solo código C / C ++ sin tener que agregar un montón de pegamento Java / Obj-C (esa fue mi comprensión original de este error y algo que definitivamente creo que podríamos / deberíamos hacer) .

eso también daría una mejor integración sqlite para flutter + hay toneladas de bibliotecas C / Rust para crypto, ssh y otras cosas. Sería genial poder usarlo con tanta facilidad.

@eseidel

Escucho al menos tres deseos diferentes presentados

Mi voto por 1.)

Al leer los documentos de Flutter, debería ser bastante "simple" extender los canales de plataforma para admitir C.
Lo único nuevo probablemente sería una forma de cargar _objetos compartidos dinámicos_ en el proceso actual.

Me imagino que el uso de _Android-C_ se parece a:

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

Conceptualmente, al menos para _Android-C_, tendría que decidir cómo manejar la combinación de Java y C.

@eseidelGoogle
Actualmente exponemos el código golang a través de Java y envoltorios rápidos y la latencia es un problema apreciable al que nos enfrentamos.
Por qué ?

• Necesitamos compartir la lógica empresarial entre muchas plataformas.
• Para funciones de video e imagen como compartir pantalla.
• Para DB.

¡Si puede agregar soporte de golang a nivel directo, eso marcaría una diferencia de abrazo!
Compilar código golang para dispositivos móviles también es muy fácil sin la magia de LDFLags, así que creo que sería popular. Conozco algunos otros codificadores de golang que actualmente también utilizan los canales de método.
En cuanto a la serialización, actualmente usamos Protobufs y flatbuffers.

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

En fucsia esto se hace con FIDL y tiene enlaces a c, rust y golang.
Es bastante increíble de usar y he disfrutado probando rust y golang en una placa incorporada.

Debería ser posible exponer las cosas fidl a través de iOS y Java también.
Eso daría una buena entrada entre fucsia y aleteo en móviles y computadoras de escritorio.
Solo una idea con la que estoy jugando

@eseidelGoogle
Hiixe me dijo que FIDL no se puede hacer a nivel de Flutter porque FIDL se basa en el código del kernel de zircon en Fuchsia. Entonces, la única forma de replicar la funcionalidad de estilo FIDL IPC dentro de Flutter sería escribir una versión FIDL en el motor Flutter. Pero luego estaba jugando aroudn con él y noté que es bastante similar a Flatbuffers. Entonces, ¿por qué no usar FlatBuffers para la capa de serialización entre Flutter y cpp o golang o rust layer en Flutter? ?

Solo haga +1 en esto, tenemos una aplicación Flutter que usa una biblioteca llamada Superpowered. Superpowered está escrito en C ++, luego usamos elementos de tipo java y JNI para interactuar con él, que a su vez usamos canales de plataforma para hablar con el código Java. Ciertamente sería bueno si pudiéramos omitir al intermediario.

Esto se debe a que esto impide que las bibliotecas móviles populares como Realm hagan versiones de flutter porque su núcleo está escrito en C / C ++ y tampoco quieren tratar con un intermediario java / objc / swift.

Por esas razones, además de la estabilidad general, creo que este problema es uno de los cambios más necesarios en flutter en este momento. (Más específicamente # 1 en la lista de @eseidelGoogle ).

Si desea escuchar un argumento para omitir Java / JNI en las extensiones de la plataforma (es decir, no solo ocultar / automatizar la capa de pegamento de Java para el desarrollador), Superpowered tiene mucho que decir sobre ese tema: https://www.youtube. com / watch? v = LzIuir3r6Co

@pnico ¿Puede explicar cómo esto es argumentar que Java / JNI debería ser bipassed? Parece estar diciendo poco más que su código de procesamiento de audio debería estar escrito en C ++. (Lo que no significa que no pueda llamarlo a través del JNI o ​​por cualquier otro medio)

@ csga5000 tienes toda la razón, eso no tenía sentido: D JNI probablemente no afectará el rendimiento realmente a menos que estés tratando de hacer cosas más esotéricas. Supongo que realmente se reduce a la conveniencia / facilidad de mantenimiento, y supongo que tal vez la capacidad de mover más código específico de la aplicación de Java / C ++ a Dart

Creo que @pnico está diciendo que PUEDE llamarlo a través de JINI, pero que JINI agrega demasiada latencia.
Entonces el perf es el problema.
sí No ??

Este podría marcar una gran diferencia principalmente para el trabajo relacionado con la criptografía.

También supongo que para Android Things, aunque no he visto ni hecho experimentos
y puntos de referencia para cronometrar gpio sensible ni en c ni en dardo durante más de un
año.

El sábado 9 de junio de 2018 a las 10:52, Eddy WM, [email protected] escribió:

Este podría marcar una gran diferencia principalmente para el trabajo relacionado con la criptografía.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/flutter/flutter/issues/7053#issuecomment-395927258 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AFHMcSI2JDHbgv3iYrStDN5mlzkQ8XEkks5t6xxMgaJpZM4K-PLw
.

¿Algún progreso desde entonces?

Hasta que se resuelva este problema, ¿hay alguna recomendación para un complemento de flutter de ejemplo que muestre cómo integrar ac / c ++ lib? ¿ Djinni es un buen camino a seguir?

Hasta que se resuelva, la única forma de integrar c / c ++ escribiendo código nativo de Android e ios y luego interactuando con el código de dardos utilizando canales de plataforma

Implementé complementos que usan canales de plataforma (para archivos jar y CocoaPods). Estoy buscando un complemento de ejemplo que muestre cómo integrarse en la misma biblioteca c / c ++ (tanto para Android como para iOS). ¿Alguna recomendación?

@ mmcc007 Así es como se hace en Java o Swift.

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

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

Puede ver cómo superpowered recomienda que lo haga si realmente quiere un ejemplo (es solo uno que conozco): https://github.com/superpoweredSDK/Low-Latency-Android-iOS-Linux-Windows-tvOS-macOS- Plataforma de audio interactiva
Vea las carpetas de ejemplos. Por ejemplo, dentro de https://github.com/superpoweredSDK/Low-Latency-Android-iOS-Linux-Windows-tvOS-macOS-Interactive-Audio-Platform/tree/master/Examples_Android/SuperpoweredRecorder/app/src/main hay java / com / superpowered / recorder / MainActivity.java que hace referencia al código en cpp / RecorderExample.cpp

@ csga5000 Parece que sería razonablemente sencillo ... en la primera revisión. Aún así, sería bueno mirar a través de un complemento de flutter que funcione. Gracias.

+1 para esto. Cualquier ejemplo funcional de una aplicación de flutter que use c ++ sería bien recibido

Hay un proyecto que hace esto para golang y creo que el mismo enfoque
también se puede utilizar para c ++.

El programa golang usa jsonrpc.
Entonces todo lo que necesita hacer es presentar su propio código golang con jsonrpc.

Entonces todo es muy fácil.

Creo que los canales de la plataforma SOLO admiten JSON como serialización agnóstica
formato ?

El miércoles 18 de julio de 2018 a las 16:50 Jefferson Bledsoe, [email protected]
escribió:

+1 para esto. Cualquier ejemplo funcional de una aplicación de flutter que use c ++ sería
bien recibido

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/flutter/flutter/issues/7053#issuecomment-405958345 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ATuCwkPbb9vLdoaEwM-bLhYPZxtyQ5Vjks5uH0sqgaJpZM4K-PLw
.

Hola alguna noticia

¿Solo quiero saber si alguien en este hilo ha logrado integrar la biblioteca Superpowered directamente en una aplicación de flutter?

Sí @ skills-up lo hemos logrado. Simplemente no en un proyecto de código abierto, así que no puedo mostrarlo. Pero si ve mis consejos antes, así es como lo hace. Sin embargo, es posible que deba crear su aplicación Flutter para cada arquitectura de CPU

Entiendo que lo ha hecho a través de JNI / Java y no directamente desde dart. Me preguntaba si es posible evitar por completo el código específico de la plataforma.

Sin embargo, es posible que deba crear su aplicación Flutter para cada arquitectura de CPU

¿Te refieres a una aplicación separada para cada arquitectura, o simplemente especificas todas las arquitecturas compatibles?

Por cierto, ya tenemos una aplicación en funcionamiento escrita de forma nativa en Java. Sin embargo, ahora que también tenemos que crear una aplicación para iOS, me preguntaba si crear una en Flutter (en lugar de gastar esfuerzos en Swift / XCode) tendría más sentido desde la perspectiva de la capacidad de mantenimiento futura, con el beneficio de una única base de código.

Bien. Realm está esperando que ustedes brinden una forma: https://github.com/realm/realm-object-server/issues/55

lukaspili: Supongo que todos siguen esperando: aleteo / aleteo # 7053
bmunkholm: @lukaspili Sí, eso es un requisito previo seguro.

Por lo que vale, también estoy esperando esto. Realmente no puedo pensar en reemplazar las aplicaciones XF con flutter ídem hasta que tengan la plomería adecuada. Tal como está actualmente, Xamarin sopla aleteo fuera del agua en este departamento.

Tarde para esta fiesta pero un gran +1 para este hilo.

Desarrollo aplicaciones de escritorio, mi vista como una línea de código (para escritorio):

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

Si Flutter puede ofrecer soporte de primera clase para C ++, creo que su enfoque general podría ser un ganador absoluto para el desarrollo de aplicaciones multiplataforma, no solo una "primicia para dispositivos móviles" sino una primicia mundial. Qt es caro para los pequeños desarrolladores, es obstinado y no adopta el C ++ moderno y nada realmente compite, ¿podría Flutter comerse al menos parte de su pastel de UI?

PD: No soy anti-Dart, es otro nuevo C # / Go / Rust / etc. lenguaje competitivo que puede ser muy productivo para una nueva plataforma, pero el mundo de las aplicaciones de escritorio de alto rendimiento (mi interés aquí) es firmemente C ++, con un amplio soporte para sistemas operativos y bibliotecas, un lenguaje que avanza a un ritmo acelerado en sí mismo (no es C), ¡y creo que Flutter se lo merece!

No creo que flutter admita C ++ en ningún momento en el futuro cercano, y ciertamente no es posible ahora. Y yo, por mi parte, prefiero enormemente a Dart: escribir aplicaciones en C ++ incluso con flutter requeriría mucho más esfuerzo. Y no creo que C ++ se traduzca directamente en soporte de escritorio, todavía tendrían que escribir bastante código y la máquina virtual dart debería funcionar para escritorio de todos modos. Creo que el rendimiento es insignificante para la mayoría de las aplicaciones.

Creo que, al final, Google quiere admitir la interoperabilidad para que pueda escribir aplicaciones de flutter para todas y cada una de las plataformas utilizando cualquier idioma compatible o incluso una combinación de dichos idiomas. Pero no esperaría eso hasta bien cuando o después de que se lance Fuchsia. Por ahora, su objetivo es facilitar la escritura de código una vez. Dart coincide con ese objetivo ya que es fácil de usar / aprender, eficiente y uno de los idiomas de Google de todos modos. Realmente no veo casi ninguna ventaja práctica para el usuario promedio de tener soporte C ++ de primera clase. El rendimiento es insignificante en una aplicación móvil, y el uso de canales de plataforma con C ++ sería conveniente para interactuar con las bibliotecas de C ++ existentes. En el lado positivo, puede estar seguro de que eventualmente pretenden que flutter sea compatible con el escritorio (bueno, al menos el capibara de Fuchsia, pero dudo que se detenga allí).

Este hilo trata sobre el soporte de la integración directa con C ++ desde dart / flutter, que con suerte podría llegar en un futuro próximo.

No creo que flutter sea compatible con C ++
Realmente no veo casi ninguna ventaja práctica para el usuario promedio de tener soporte C ++ de primera clase.

No se trata de lo increíble que es Flutter / Dart frente a C ++, se trata más del punto / facilidad de las integraciones que necesita para encajar en el ecosistema actual. Existe una larga lista de bibliotecas como objeto compartido (OpenCV, por nombrar una) que son el estándar de la industria, ¿no puede esperar que la gente las reescriba en Dart?

El rendimiento es insignificante en una aplicación móvil, y el uso de canales de plataforma con C ++ sería conveniente para interactuar con las bibliotecas de C ++ existentes.

Todo lo contrario, el uso de canales es subóptimo en este contexto, piense en los casos de uso en los que necesita trabajar con un objeto binario grande en la memoria (imágenes), necesitaría:
1- Copie estos binarios desde / hacia la memoria C ++
2- Trabajar con JNI para interactuar con la biblioteca (y manejar punteros asignados dinámicamente a estos binarios)
sin mencionar la sobrecarga de serializar / deserializar el costo de los valores / parámetros en el que incurre al usar los canales.

Un buen marco es un equilibrio entre las nuevas características / paradigmas que presenta frente a la facilidad de integración con el ecosistema / legado actual, del cual no podemos negar que C ++ forma parte.

@nhachicha @ csga5000 no estaba en desacuerdo con que la integración directa de C ++ era importante; estaba respondiendo a un comentario anterior preguntando si Flutter podría usarse directamente desde C ++ , como en, sin necesidad de ningún código Dart.

El rendimiento es insignificante en una aplicación móvil, y el uso de canales de plataforma con C ++ sería conveniente para interactuar con las bibliotecas de C ++ existentes.
@nhachicha No podría estar más de acuerdo.

La verdad es para las aplicaciones que no necesitan un rendimiento mordaz (que son muchas), entonces, ¿por qué no cambiar el C ++ difícil de dominar por algo más productivo? De hecho, ¿por qué detenerse solo en Dart? muchos idiomas más populares / establecidos que Dart):

• Tiempo de ejecución de C # /. Net Core
• Tiempo de ejecución de Javascript / TypeScript V8 (casi tendrías un navegador en ese momento, pero y qué)
• Rust (¡también rápido!)
• GoLang
• Pitón
• [Inserte su favorito aquí] ...

Y aunque personalmente amo y uso algunos de esos lenguajes todos los días, C y C ++ son el núcleo de Linux, por lo tanto, Android, iOS y plataformas de escritorio como Windows, MacOS y otros equipos de escritorio. La mitad de los lenguajes anteriores (incluido Dart) están escritos en C ++. Las tecnologías de vanguardia requieren una y otra vez un rendimiento nativo ajustado, como AI (Tensorflow es C ++, Caffe C ++, Pytorch es C bajo Python, etc.), bibliotecas de realidad aumentada, motores de juegos AAA y cualquier cosa que necesite acercarse a una GPU (CUDA , llamado desde C / C ++).

Por la misma razón que el motor de renderizado Flutter está escrito en C ++ (nativo, alto rendimiento, batería / memoria / CPU eficiente), creo que sería estupendo desbloquear el mejor rendimiento posible, cuando sea necesario, sin acercarse a un tiempo de ejecución administrado. y simplemente apoyando C ++. Esto diferenciaría a Flutter de otros frameworks como Xamarin y Nativescript, que honestamente ofrecen una experiencia de desarrollo similar (habiendo usado ambos) solo con diferentes lenguajes, ¿por qué no hacer que flutter sea especial en lugar de simplemente "el de Dart"?

_Como nota al margen, estoy totalmente en casa escribiendo todo en C / C ++, desde la validación de formularios hasta los sombreadores de píxeles, pero no pretendo que esa sea la opinión de muchas personas que miran este repositorio, y eso es porque encuentro C ++ a lenguaje altamente productivo, sin embargo, una elección totalmente personal.

Esta es una de las principales razones por las que necesitamos la integración de C ++

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

Hay dos formas sencillas de realizar la integración de C / C ++:

• Proporcionar implementación de canal de método en C ++
• Proporcionar compatibilidad con la extensión nativa de Dart VM

Desafortunadamente, ambos tienen importantes inconvenientes que nos impiden seguirlos:

• Los canales de método tienen una alta abstracción de sobrecarga, mientras que la integración de C / C ++ se solicita cuando se desean interacciones de baja sobrecarga. Lo que significa que los canales de métodos no resolverían realmente el problema.
• Las extensiones nativas de Dart VM requieren que las personas usen la API de Dart VM C; puede que no sea deseable introducir demasiadas dependencias externas en eso, especialmente dado que la API no envejeció bien y requiere una refactorización seria.

Parece que una alternativa más deseable es la introducción de dart:ffi , un componente central de Dart VM que permitiría vincularse directamente al código nativo y permitir a las personas escribir algo como:

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

Tuvimos cierto interés en implementar una FFI como esta durante mucho tiempo; esperaría que experimentemos con ella en algún momento en el futuro cercano, pero no me comprometería con ningún cronograma concreto.

@ kirbyfan64 Es exactamente correcto, @nailgilaziev , @bytesoftly No estoy tratando de decir que la integración de C ++ no es necesaria, solo estaba diciendo que no creo que haya mucha razón / demanda para hacer que flutter sea compatible con C ++ en lugar de dardo, pero No estoy diciendo que la integración no sea necesaria. Lo que dice @mraleph me suena inteligente.

@mraleph El Dartino tuvo una implementación similar para FFI . ¿Qué tan difícil es resucitar?

@listepo partes de él. La implementación de FFI de Dartino fue muy dinámica; esto no es algo que queremos para Dart 2, que es considerablemente más estático que Dart 1.

Tarde en el juego, pero aquí hay otro caso de uso: nos gustaría incluir archivos cy métodos en dart con fines criptográficos.

Lo que esperaríamos es lo siguiente:
1) Código idéntico para iOS y Android, es decir, no pasar por capas ObjC o JNI.
2) Es de esperar una implementación más eficiente que cuando se pasa por, por ejemplo, JNI dos veces.
3) Posibilidad de reutilizar el código del modelo de dardos en una aplicación web de seguimiento, por ejemplo, en AngularDart, o aplicaciones de escritorio de seguimiento utilizando este proyecto: https://github.com/google/flutter-desktop-embedding

Creo que lo que queremos está más cerca del punto 2 @eseidelGoogle mencionado anteriormente. En cuanto al soporte sincrónico, lo considero "bueno tener", ya que las funciones asincrónicas no se pueden usar en un constructor, donde uno podría querer realizar, por ejemplo, un cálculo rápido de hash. Pero al acostumbrarse a la forma asíncrona de Dardos, el soporte sincrónico parece menos importante que la posibilidad general de lograr los puntos 1) -3) anteriores.

Usando FFI como lo sugiere @mraleph , ¿esto permitiría 1) -3) como en mi comentario anterior, o significaría que se necesita un código diferente en diferentes plataformas (Android, iOS, ...)?

@CryptUser si su código C / C ++ es el mismo en todas las plataformas, el código de Dart para llamarlo a través de FFI también sería el mismo en todas las plataformas.

@mraleph ¡ Suena genial! Dado que el número original tiene más de 200 pulgares hacia arriba, ¿hay alguna posibilidad de aumentar la prioridad en esto?

@mraleph, ¿hay un problema abierto para FFI en Dart en algún lugar?

@dnfield Acabo de presentar uno https://github.com/dart-lang/sdk/issues/34452

Me encantaría poder escribir código C / C ++ / Rust y poder usarlo sobre ffi

Ejemplo:

Pruebo flutter en una tableta Android (Android 4.4).
aleteo corre rápido.
Pero cuando intento leer 1000 filas con sqflite que usan el canal de la plataforma, es ridículamente lento.
la razón: no puedo usar el lector de cursor sqlite.

pero si pudiera usar directamente la biblioteca sqlite, la misma consulta es instantánea. (probado con xamarin y el proyecto nativo de Android).

Estamos discutiendo ahora cuál es la mejor manera de abordar esto. Como se señaló anteriormente en https://github.com/flutter/flutter/issues/7053#issuecomment-377711814, este problema tiene muchas partes y probablemente deba dividirse. :)

Pero hemos encontrado algunos ingenieros interesados ​​en explorar una FFI (como se indica en https://github.com/flutter/flutter/issues/7053#issuecomment-415161464). Nuestro enfoque en este momento es lograr que 1.0 salga por la puerta, pero una vez hecho esto, ocupará un lugar destacado en la lista. Gracias nuevamente por todos sus comentarios continuos. Actualizaremos este problema cuando tengamos más avances para compartir.

También soy usuario de Matlab / Simulink. Puedo generar código c / cpp específico de CPU altamente optimizado. Quiero integrar mi algoritmo en flutter. Tengo muchos algoritmos de procesamiento de imágenes. Necesito un generador de enlaces para códigos nativos. De lo contrario, olvidaré todas mis experiencias de dardos y comenzaré a aprender xamarin o algo que me quede bien.

¿Podemos acelerar el progreso?

Es un gran dolor interoperar entre Dart y C.

No es probable que acelerar el proceso dé como resultado un producto de buena calidad. Estará listo cuando esté listo. :-)

No es probable que acelerar el proceso dé como resultado un producto de buena calidad. Estará listo cuando esté listo. :-)

Bueno, lo que traté de decir fue que podríamos querer aumentar la prioridad para poder poner más recursos y esfuerzo en resolver esto. Usted sabe que hay 1386 problemas abiertos a partir de ahora que apuntan a "Objetivo" que se "solucionará en los próximos años".

Después de leer el hilo una vez más, noté que @eseidelGoogle dijo que esto tendrá mayor prioridad después de que Flutter 1.0 esté listo. Creo que ha abordado bien mi preocupación.

"Objetivo" puede ser el grupo equivocado. :) @mraleph tiene a alguien explorando https://github.com/dart-lang/sdk/issues/34452 mientras hablamos. Eso es parte de una solución al menos.

Aquí está el documento de visión para el FFI que actualmente estamos creando en el lado de Dart.

Por favor, eche un vistazo y díganos lo que piensa.

No puedo decir mucho sobre la parte FFI porque nunca usé algo así,
pero me pregunto cómo será la integración de pub.

¿Cómo se manejarían los paquetes de publicación que hacen uso de FFI?
¿Cómo se manejarían los paquetes consumidores que usan FFI?

@zoechi aún no hemos hablado de la integración de pub .

Deberían poder funcionar de manera similar a los complementos de Flutter en la actualidad: incluyen fuentes y / o binarios apropiados para la plataforma / arquitectura que se pueden compilar / vincular en la aplicación de consumo.

Desde la perspectiva de un pub, no debería ser un gran problema, excepto que puede haber archivos binarios más grandes incluidos en el paquete.

Sin embargo, sería necesario trabajar un poco en el extremo de las herramientas de Flutter para integrarlas en los proyectos de Flutter; en realidad, no funcionarían de la misma manera que los complementos de Android / iOS en la actualidad.

¿Debería trasladarse la integración de pub a un tema de dart-lang / pub para mantener este tema más enfocado?

He leído 'vision doc' y por fin veo formas a través de la niebla.

Mientras tanto, estaba reflexionando sobre algo muy diferente.

Es decir, de (re) usar Flatbuffers para hacer algo como NativeChannels. En el momento de la ejecución (AOT) se reduciría a pasar el puntero, mientras que en el tiempo de desarrollo me permitiría aprovechar las herramientas existentes para el lado "nativo" escrito no solo en C / C ++ sino también en Go o Rust.

El enfoque de paso de mensajes también está más en línea con las arquitecturas actuales basadas en flujos (Bloc, Rx). También anula cualquier preocupación acerca de la gestión de la memoria, ya que el compilador podría generar búferes de anillo adecuados cuando sea apropiado o asumir simples 'llamadas liberadas' donde una persona llamada necesita retener datos por más tiempo.

Pero para ser honesto, aplaudiré cualquier forma de ffi si se integra sin problemas en el ecosistema Flutter (Fuchsia) y me permite usar código nativo optimizado para cpu desde la aplicación Dart.

@ohir lo que habías imaginado sería otra solución para algunos de los problemas presentados. Este error evolucionó hasta convertirse en un catch-all de propósito general para todo lo relacionado con C ++. : / Sospecho (como he señalado en comentarios anteriores) que necesitamos dividir este error en otros más pequeños. El trabajo de FFI puede no ser la única solución que construimos en este espacio.

@eseidelGoogle ¿ algún progreso en esto? ahora mismo tenemos un proyecto que necesita implementar tareas pesadas de procesamiento de video que podrían realizarse a través de ffmpeg, ya que el paquete de dart actual no puede proporcionar una solución viable, estamos esperando ansiosamente que flutter llame a ffmpeg lib directamente.

Para esas aplicaciones basadas en la interfaz de usuario de página a página, ahora flutter creo que es una buena opción que recurrir al trabajo de doble codificación tanto en Android como en iOS, si estuviéramos hace 5 años con un equipo tan encantador, toda la industria de las aplicaciones podría ser cambiado. Sin embargo, las ventajas de flutter en este momento no son tan impresionantes para las empresas que migran a él, porque ya lo habían hecho bastante bien con el método antiguo, pero para algunas tareas que no eran de interfaz de usuario, el dardo está muy por detrás del requisito principal.

no significa que dart no sea bueno ni viable para esas tareas algún día, pero desde el punto de vista de una empresa de TI normal que podría estar incluida en el ecosistema de flutter, lo que necesitan es reducir el costo mediante el uso de una cruz el método de codificación de la plataforma solo si se pueden lograr las características más interesantes, como el procesamiento de datos del lado del cliente, video / audio, personal de AR, etc., siempre que algún algoritmo ya lo hayan hecho a través de c / c ++. es realmente difícil para ellos volver a implementarlo o reinventarlo usando dart lang.

y la solución clave es introducir la forma directa y eficiente para que flutter se comunique con c ++, incluso creo que esta es la primera prioridad de una cosa "multiplataforma", dardo para el personal de la interfaz de usuario es perfecto, algo de lógica de datos normal también puede ser hecho en dardo, pero es mucho mejor para flutter fusionarse en el largo pero aún activo y eficiente ecosistema de c ++ en lugar de reconstruir uno nuevo y santo.

El sueño de una verdadera experiencia de codificación "multiplataforma" es el personal de la interfaz de usuario de Dart con c ++ detrás del capó, sin código Java en absoluto, sin código OC en absoluto. ¡Wahaha, no puedo esperar a que suceda!

@smellbee ¿No puedes usar la línea de comando ffmpeg?

@smellbee Me temo que no soy el indicado para responder a esta pregunta. @eseidelGoogle ¿ alguna novedad sobre esto?

@smellbee ¿No puedes usar la línea de comando ffmpeg?

es un trabajo del lado del cliente, usando ffmpeg lib para renderizar cuadros de video para producir un flujo de retroalimentación instantánea, ¿es posible usar la línea de comando?

@smellbee Me temo que no soy el indicado para responder a esta pregunta. @eseidelGoogle ¿ alguna novedad sobre esto?

lo siento, escribí "es" y se completó automáticamente, no me di cuenta ... espero que @eseidelGoogle pueda verlo

El trabajo está en progreso en el lado de Dart; esperamos tener algo listo en el primer trimestre de 2019.

Es una característica importante y nos gustaría hacerlo bien: como queremos que funcione bien en diferentes modos de ejecución para Dart, por favor tengan paciencia con nosotros mientras resolvemos los detalles.

Puede seguir dart-lang / sdk # 34452 que rastrea el trabajo en el lado de Dart.

Dart FFI permitirá llamar a funciones C desde Dart.
Pero, ¿qué pasa con las características de C ++: clases, contenedores estándar, punteros inteligentes, excepciones?
¿Podemos esperar la posibilidad de exportar clases de C ++ a Dart con un mínimo de repetición?

Otra característica bastante importante es el soporte asincrónico: la capacidad de ejecutar código C ++ en un hilo separado y devolver Future / Stream desde métodos.

@ t-artikov Actualmente no hay planes para admitir directamente la interoperabilidad de C ++. Esto es demasiado complicado. Lo único que puede interoperar ergonómicamente con C ++ es C ++.

Si está interesado en la interoperabilidad de alto nivel con C ++, deberá crear su propia capa de interoperabilidad que exponga su API de C ++ a través de una API similar a C.

Otra característica bastante importante es el soporte asincrónico: la capacidad de ejecutar código C ++ en un hilo separado y devolver Future / Stream desde métodos.

Creo que esto se puede construir como un paquete. Solo debemos asegurarnos de proporcionar las primitivas correctas para que esto pueda construirse.

Dart FFI permitirá llamar a funciones C desde Dart.
Pero, ¿qué pasa con las características de C ++: clases, contenedores estándar, punteros inteligentes, excepciones?
¿Podemos esperar la posibilidad de exportar clases de C ++ a Dart con un mínimo de repetición?

Siempre que haya una manera de que C ++ llame a dart, creo que esas cosas son posibles, C ++ se encarga de lo que preocupa a C ++, y se comunica con dart al ser llamado o llamando, no es necesario exponer ninguna manipulación de bajo nivel a dardo que destruirá la facilidad de uso de dardo.

Otra característica bastante importante es el soporte asincrónico: la capacidad de ejecutar código C ++ en un hilo separado y devolver Future / Stream desde métodos.

Y dart ya tiene su mecanismo asincrónico, por lo que, si un hilo está orientado a C ++ o no, no importa, siempre que la parte de C ++ pueda llamar a dart siempre que sea necesario, y un "Aislar" puede hacer el trabajo.

Eso es lo que pienso @mraleph ,

@mraleph
De hecho, hay ejemplos de gran interoperabilidad de C ++ con otros lenguajes.
https://github.com/boostorg/python
https://github.com/ThePhD/sol2
https://github.com/dropbox/djinni
Espero que Dart / Flutter proporcione un mecanismo similar listo para usar.

Si está interesado en la interoperabilidad de alto nivel con C ++, deberá crear su propia capa de interoperabilidad que exponga su API de C ++ a través de una API similar a C.

Para dejar en claro cómo se aplica este enfoque, ¿podría demostrarlo utilizando las siguientes clases С ++ como ejemplo:

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

Para que pueda usarse desde Dart

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

@ t-artikov tanto boostorg::python como sol2 ilustran muy bien mi punto. Tenga en cuenta que se trata de bibliotecas de C ++ para interoperar con otros lenguajes, no al revés. Dart FFI es una forma centrada en Dart de llamar a las API de C, no una forma centrada en C ++ de llamar a Dart.

Para dejar en claro cómo se aplica este enfoque, ¿podría demostrarlo utilizando las siguientes clases С ++ como ejemplo:

Tendría que escribir (o generar con alguna herramienta) algo como esto.

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

Tenga en cuenta que se trata de bibliotecas de C ++ para interoperar con otros lenguajes, no al revés.

Te equivocas, permiten exponer clases de C ++ a otros lenguajes.
https://www.boost.org/doc/libs/1_68_0/libs/python/doc/html/tutorial/tutorial/exposing.html

Gracias por su ejemplo de Dart FFI.
Hay algunas fallas: la excepción de C ++ debe pasarse al lado de Dart; y MyObject.data no funcionará de esta manera (solo obtiene el puntero, pero no el tamaño de los datos).
Pero la idea es clara.

En mi opinión, dicho código es demasiado detallado para escribirlo manualmente.
Espero ver si este proceso se automatizará para las nuevas fijaciones de Dart FFI Flutter Engine.

La vinculación en tiempo de ejecución para la interoperabilidad de C ++ es casi imposible (cómo se manejan los genéricos, la herencia múltiple, las sobrecargas de operadores, los nombres destrozados, etc.). Ha habido muchos intentos difíciles (BridJ, CppSharp, etc.) y, según tengo entendido, la gente considera que la interoperabilidad de C es la opción más viable.

Es poco probable que haya una solución muy genérica que los desarrolladores de interoperabilidad oficiales puedan lograr para C ++. Kotlin / Native no ofrece eso. éter nativo de scala. .NET (la interoperabilidad de Microsoft C ++ es siempre extraña o estática). JNI admite la interoperabilidad de C ++ solo cuando se trata de compilación estática. Algo como el pegamento de refuerzo de Python debe escribirse manualmente. Cualquier grupo de terceros puede desarrollar cosas como JNAerator (es decir, USTED puede hacerlo, no es necesario esperar que los equipos de Dart / Flutter lo logren).

Después de esta conversación sin una respuesta real, creo que me quedaré con Qt, que es Cross-Plattform y tiene soporte completo para C ++. Estaba pensando en darle una oportunidad a Flutter para mi próximo proyecto, pero ahora no lo haré, ¡muchas gracias!

Hubiera sido mejor si flutter se hubiera escrito en C ++, con lo que la interoperabilidad con cualquier otro lenguaje hubiera sido fácilmente posible. ¿Hay algún intento de reescribir flutter en C ++?

Creo que la discusión se está estirando innecesariamente ahora.

Sabemos lo que está (o no) en la hoja de ruta del desarrollo de flutter.
En consecuencia, podemos decidir usarlo (o no usarlo) para casos de uso específicos.

No veo ninguna utilidad en intentar cambiar la agenda de desarrollo, o
exigiendo una ejecución arquitectónica específica, más allá de este punto.

Gracias,
Gaurav

El lunes 25 de febrero de 2019 a las 10:51 p. M. Bhauj, [email protected] escribió:

Podría haber sido mejor si flutter se hubiera escrito en C ++, con
cuya interoperabilidad con cualquier otro idioma hubiera sido fácilmente posible. Es
¿Hay algún intento de reescribir flutter en C ++?

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/flutter/flutter/issues/7053#issuecomment-467098455 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AZ86acDpZgNeyezx40uxe_c5E2xZHWxaks5vRBumgaJpZM4K-PLw
.

En realidad, Flutter está escrito en C ++, pero para programar en Flutter solo se puede hacer con el intérprete Language Dart que se ejecuta en una máquina virtual. Pero aún no tienes la oportunidad de pasar de Dart a la parte C ++ de Flutter ...

Entonces, quien lea esto y tenga el caso de uso común en el desarrollo de aplicaciones de un buen desarrollo multiplataforma, Flutter no permitirá el uso directo de C ++ si lo necesita, entonces use otro marco multiplataforma como Qt C ++.

Para mí, C ++ es esencial para el desarrollo entre plataformas porque es el mínimo común denominador en casi todas las tecnologías.

@aqmappdesigners

intérprete Language Dart que se ejecuta en una máquina virtual

Eso no es exacto.

Flutter usa Dart VM en modo de depuración, lo que también hace posible la recarga en caliente.
En las versiones de lanzamiento, Dart se compila en código binario como C ++.

@zoechi Gracias, no sabía esto. Eso suena bien para la actuación.

Eso suena bien para la actuación.

y es un requisito para Apples App Store.

El prototipo dart:ffi ha progresado hasta el punto en que estamos decidiendo sobre las decisiones de API. ( Aquí se analizan algunas decisiones de diseño).

Para tomar decisiones de diseño informadas, nos gustaría obtener más ejemplos sobre las API de C que le gustaría vincular. Hasta ahora, este problema menciona SQLite, Realm, OpenCV, Superpowered y ffmpeg. ¿Alguna otra API que debamos considerar?

@dcharkes No sé si ayuda, pero Telegram en Android hace redes en C ++ a través de JNI:
https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/jni/TgNetWrapper.cpp
También maneja la reproducción de GIF con ffmpeg, escribiendo directamente en mapas de bits de Android:
https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/jni/gifvideo.cpp

Podría ser interesante tener una forma de analizar teléfonos y direcciones a través de libphonenumber y libpostal para formularios de registro. También glfw + flutter-embedder y tal vez algún día veamos una aplicación de escritorio completamente escrita en dart.

+1 para SQLite y Realm. También mire Couchbase , tienen un núcleo C ++ común con un C SDK.

¿Serían interesantes las apis de Firebase C ++? https://firebase.google.com/docs/reference/cpp/

No lo investigó mucho, pero estaba pensando que podría reemplazar los complementos de iOS y Android con un solo complemento que habla directamente con C ++.

Algunas bibliotecas de cifrado deberían recibir algo de amor como ring from rust: https://github.com/briansmith/ring

+1 para OpenCV, Realm, SqlCipher (https://github.com/sqlcipher/sqlcipher)

Bibliotecas de criptografía. Particularmente libsodium o tink.

https://github.com/google/tink

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

Ya hay una biblioteca de flutter-sodium, se comunica a través de los canales de la plataforma con los envoltorios libsodium en cada plataforma y luego con los nativos.

Bibliotecas de mapas personalizados como mapbox-gl https://github.com/mapbox/mapbox-gl-native

El manejo de SMTP / IMAP (para chat por correo electrónico) para Flutter a través de https://github.com/deltachat/deltachat-core es algo que me encantaría usar directamente.

Si puedo ser tan atrevido como para parafrasear, los casos de uso comunes son los siguientes:

1. Acceso al hardware de audio / video de baja latencia (como, Superpoderes)
2. Procesamiento a / v asistido por hardware (como, ffmpeg)
3. Acceso a socket basado en TCP, para XMPP / otros protocolos orientados a la red
   (para chat, notificaciones push)
4. Actualizaciones de nivel de proceso (acceso raíz) / subprocesos de generación en
   de manera compatible multiplataforma (para aplicaciones del sistema, multitarea, emuladores)

Puede haber más casos de uso, pero estos son los principales que llegan a mi
mente.

¡Gracias a todos por dar ejemplos! Esto es muy útil.

@ skills-up tenga en cuenta que estamos mucho más interesados ​​en ejemplos concretos que en una clasificación abstracta. Eso es porque queremos evaluar la ergonomía de FFI en ejemplos concretos.

Curiosamente, uno de los lenguajes que ofrece la mejor interfaz desde / hacia C ++ es Rust, a través de su potente sistema macro + build, a pesar de tener un enfoque completamente diferente de OO.

Diría OpenSSL, ya que necesitamos firmar digitalmente las solicitudes de jabón y los archivos xml (XMLDSig, Xades l) utilizando certificados de cliente.
Dart en sí tiene BoringSSL, pero solo una parte está expuesta a través de Dart. Así que la siguiente mejor opción es llamar a las bibliotecas de openssl nativas desde flutter

Espero no estar enviando spam, pero también me gustaría tener una mejor integración con tensorflow lite, sin pasar por JNI, eso sería genial para las operaciones de video

No lo investigué mucho, pero estaba pensando que podría reemplazar los complementos de iOS y Android> con un solo complemento que habla directamente con C ++.

Además de ser compatible con C ++, será increíble si hay un complemento que pueda comunicarse con Go directamente. En este momento estamos hablando de Go through gomobile & flutter platform channels, lo que ralentiza la capacidad de respuesta de la interfaz de usuario. Tener soporte nativo de Go y C ++ en Flutter también nos ayudará a mantener una base de código uniforme (lógica de negocios / algoritmo) para múltiples plataformas.

+1 para acceso a la biblioteca nativa.

Me gustaría acceder a Vulkan / MoltenVK sin tener que crear canales de plataforma para Android / iOS y mantener dos complementos (que también serían enormes). Eso permitiría crear aplicaciones 3D y renderizar en un widget de textura, mientras que solo se desarrolla en Dart. Los canales de la plataforma simplemente parecen una solución hacky. Prefiero acceder a las bibliotecas nativas sin tener que escribir un contenedor para cada plataforma y mantenerlas siempre que haya una nueva versión para esa biblioteca.
Creo que esta función atraerá a muchos más desarrolladores.

Sí, por favor, acceda directamente a la biblioteca nativa desde flutter.
Me gustaría usar alguna biblioteca de C ++ en flutter.

Sí, por favor, acceda directamente a la biblioteca nativa desde flutter.
Me gustaría usar alguna biblioteca de C ++ en flutter.

Ahora estamos en un punto en el que nos gustaría ofrecer una vista previa anticipada para recibir comentarios.

Para obtener más detalles, consulte la actualización en el error de seguimiento de Dart .

@ mit-mit ¿Esto ayudará con este problema: puedo llamar o usar la biblioteca de Python con flutter ?

Tarde para la fiesta, pero +1 para SQLCipher @dcharkes @mraleph

@ doc-rj, ahora estamos en la etapa en la que debería poder experimentar con la vinculación de SQLCipher y darnos su opinión sobre su experiencia. Vea este comentario .

Me gustaría enfatizar que en realidad no pretendemos proporcionar enlaces de biblioteca específicos por nosotros mismos, porque las solicitudes son extremadamente diversas, pero nuestro objetivo es hacer posible que todos puedan vincularse a cualquier biblioteca con una API C.

Supongo que la necesidad de esto aumenta ahora que se ha anunciado la multiplataforma.

¿Es esto parte de alguna hoja de ruta?

@felemedeiros, el trabajo está en progreso; si tiene una biblioteca a la que desea vincularse usando FFI, le sugiero que comience a trabajar en las vinculaciones para proporcionarnos comentarios. Consulte este comentario para obtener información.

No lo investigué mucho, pero estaba pensando que podría reemplazar los complementos de iOS y Android> con un solo complemento que habla directamente con C ++.

Además de ser compatible con C ++, será increíble si hay un complemento que pueda comunicarse con Go directamente. En este momento estamos hablando de Go through gomobile & flutter platform channels, lo que ralentiza la capacidad de respuesta de la interfaz de usuario. Tener soporte nativo de Go y C ++ en Flutter también nos ayudará a mantener una base de código uniforme (lógica de negocios / algoritmo) para múltiples plataformas.

Escribí un artículo sobre cómo actualmente estamos llamando a la API de la biblioteca Go desde Flutter. Puede ser útil para alguien interesado. https://medium.com/@archan.paul/using -go-library-in-flutter-a04e3496aa05

¿Cómo puedo agregar código c ++ en la aplicación Flutter?

¿Cómo puedo agregar código c ++ en la aplicación Flutter?

Supongo que en este momento la única opción es tomar C ++ -> JNI (para Android) -> PlatformChannel hasta que tengamos una forma más elegante de hacer lo mismo.

Creé un proyecto llamado ezored (http://ezored.com). Sería bueno si puedo pasar objetos complejos a Flutter sin necesidad de convertirlos a otra cosa, ya que ya está en java y objc. Cualquiera puede usar ezored para generar el SDK (o descargarlo previamente) para probar la integración de Flutter entre nativo y Dart. Tiene solicitudes, análisis, crud usando la base de datos y muchas cosas en el SDK de demostración ya implementado.

Busco en grupos de aleteo pero no tengo ninguna forma de pasar los objetos y la lista de objetos a Flutter directo.

Gracias por cualquier ayuda.

¿Algún nuevo progreso? Parece que han pasado más de 2,5 años ...

@fzyzcjy estamos trabajando en ello. Lanzamos una vista previa anticipada. Consulte https://github.com/dart-lang/sdk/issues/34452#issuecomment -482136759 sobre cómo participar.

Desde esta primera vista previa, hemos agregado soporte para Intel 32, Arm 64 y Arm 32. Estas plataformas aún no se lanzaron en estable o dev, solo están disponibles en la rama maestra de Dart sdk. Aquí se realiza un seguimiento del progreso.

@dcharkes ¡ Qué feliz de escuchar eso! ¡Gracias por tu gran trabajo!

¿Cualquier progreso?

Para obtener actualizaciones de estado e información adicional, consulte https://github.com/dart-lang/sdk/issues/34452. El comentario más destacado tiene la actualización más reciente.

Al usar flutter para crear una aplicación web, ¿será posible usar ffi con la biblioteca de CA?

Al usar flutter para crear una aplicación web, ¿será posible usar ffi con la biblioteca de CA?

Eso no es probable. Teóricamente, a más largo plazo, podría ser compatible con WebAssembly, pero eso no es algo en lo que estemos trabajando actualmente.

@ con-con realmente？

Al usar flutter para crear una aplicación web, ¿será posible usar ffi con la biblioteca de CA?

Eso no es probable. Teóricamente, a más largo plazo, podría ser compatible con WebAssembly, pero eso no es algo en lo que estemos trabajando actualmente.

¿Por qué requeriría WebAssembly? Si puede pedirles a las personas que reconstruyan a WebAssembly en el futuro, puede pedirles que reconstruyan a ASM.js ahora.

@ nic-hartley Es una buena idea, pero el desafío no es cómo compilar el código nativo, sino crear el puente entre Dart (compilado como JS) y el código nativo, cualquiera que sea la forma que adopte.

El FFI nativo es de muy bajo nivel por razones de rendimiento y no se puede traducir fácilmente a asm.js o WebAssembly.

Para aclarar, quiero decir que nuestra implementación es de muy bajo nivel; sin duda es una característica interesante, pero llevaría un trabajo considerable para entregarla.

flutter es solo un juguete hasta que admita c ++

Vine aquí para hacerme eco de los mismos puntos de otros, que hasta que Flutter pueda interoperar fácilmente con C ++ (sin biblioteca puente y sin penalización de rendimiento) nunca será adoptado por aplicaciones a gran escala con inversiones en bibliotecas nativas o aplicaciones existentes. donde el rendimiento es la máxima prioridad.

Notaré que incluso React Native usa un puente actualmente, por lo que parece que Flutter está realmente por delante de la curva en términos de intentar implementar una FFI.

La integración con C ++ es trivial en iOS con AppKit. Eso es con lo que deberíamos compararnos, no con React Native.

UWP & C ++ también es trivial.

Aunque, en general, también estoy a favor de la fiesta de "apoyo al esfuerzo de Dart FFI" ...

Xamarin podría ser una comparación más apropiada que UWP, pero las vistas multiplataforma de Xamarin no eran tan personalizables como las de Flutter y, a menudo, requerían mucho código nativo para lucir decente.

Esto no es verdad. A diferencia de Flutter, Xamarin tiene enlaces de plataforma a la API nativa (es decir, Xamarin.iOS y Xamarin.Android), y es fácil para los desarrolladores de aplicaciones escribir una implementación específica de la plataforma en su propio lenguaje (C # /. NET). Este problema tiene que ver con la función del idioma y no debe mezclarse con el diseño de la API del widget de la interfaz de usuario.

Hay muchos usos de API nativas, pero no invocación de código nativo, donde Flutter estaría en el mismo barco (aunque Xamarin no requiere escribir Java u ObjC allí, sin truco de reflexión en el código de la aplicación). Para el código nativo, incluso en el propio Xamarin.Android (uno de los backends de la plataforma backend), el uso de código nativo es muy pequeño y los desarrolladores de aplicaciones no escriben código nativo.

Y a diferencia de React Native o Xamarin, Flutter proporcionará su marco completo, por lo que es un punto de vista completamente justo que comparemos todo el marco de Flutter con cosas como AppKit.

es extraño que nadie mencione el marco Qt, que está muy por delante de todo lo demás con respecto a la integración de C ++

QT es C ++. Y tiene una licencia desfavorable para empezar.

El lun, 12 de agosto de 2019, 06:41 Vladyslav Stelmakhovskyi, <
[email protected]> escribió:

es extraño que nadie mencione el marco Qt, que está muy por delante
todo lo demás con respecto a la integración de C ++

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/flutter/flutter/issues/7053?email_source=notifications&email_token=AGDYMWXHTJUBUW64LEOO27TQEDSWNA5CNFSM4CXY6LYKYY3PNVWWK3TUL52HS4DFVREXG43VMDVN5W63 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AGDYMWTNMTM7QUOY2BEIPM3QEDSWNANCNFSM4CXY6LYA
.

Qt es C ++ y QML (motor JS)
¿Qué licencia? LGPL? GPL? ¿Qué tiene de malo?

En primer lugar, IANAL, pero según tengo entendido, la mayor parte de Qt es LGPL (el IDE, etc.son GPL), lo que significa que tiene un lenguaje que, si bien no prohíbe expresamente los enlaces estáticos, dificulta hacerlo sin dejar de adherirse a la licencia si su aplicación es de código cerrado.

Técnicamente, si usa solo LGPL y proporciona sus archivos de objeto (y probablemente instrucciones) para que los usuarios puedan potencialmente volver a vincularse con una versión diferente de la biblioteca, está cumpliendo los requisitos de LGPL. Pero estoy bastante seguro de que Qt Company no anuncia ese hecho, por lo que la concepción común es que no puede implementar bibliotecas estáticas, lo que significa que no puede lanzar su aplicación en la tienda de aplicaciones sin pagar sus exorbitantes tarifas de licencia. Y puedo estar equivocado al proporcionar archivos de objetos, eso es solo lo que entiendo y no sé si alguna compañía lo está haciendo.

Android es más fácil porque permite bibliotecas cargadas dinámicamente que están más explícitamente permitidas bajo la LGPL, pero honestamente, la vinculación estática probablemente también sea preferible allí para mantener el tamaño de la aplicación bajo, lo que significa encontrarse con el mismo problema.

Hola @cpboyd , creo que estoy viendo esto desde la dirección opuesta. Ya tenemos aplicaciones creadas en marcos de interfaz de usuario específicos de la plataforma, donde cada plataforma nos permite utilizar nuestra amplia colección de bibliotecas de C ++ existentes. Entiendo que Flutter es multiplataforma, lo cual es genial, pero a menos que realmente pueda usarlo (con mi código existente), es mejor que me quede con una interfaz de usuario que no sea multiplataforma. El único problema surge cuando un sistema operativo futuro (por ejemplo, Fuchsia) requiere el uso de Flutter & Dart, pero no permite este caso de uso. En ese caso, es probable que sea ignorado por cualquier persona con grandes bases de código existentes.

Supongo que no estoy seguro de si Flutter / Dart se están diseñando con aplicaciones "web" (es decir, dónde están los backends en la web) en mente, o si se están considerando seriamente las necesidades de los desarrolladores de aplicaciones de escritorio profesionales. En última instancia, decisiones como esta pueden afectar la cantidad y la calidad de muchas aplicaciones en una tienda de aplicaciones. Si puedo escribir una aplicación profesional de alta calidad para iOS usando UIKit, utilizando millones de líneas de código existente, pero no puedo (con un costo de rendimiento cercano a cero) si estoy desarrollando para Fuchsia / Flutter / Dart, entonces eso sería Ser un sistema operativo y una plataforma para los que no desarrollaría.

El objetivo de mis publicaciones no es comparar Flutter con otras bibliotecas multiplataforma o no multiplataforma, es resaltar casos de uso que son importantes para un subconjunto de desarrolladores.

El Dart FFI es interesante, a partir de la lectura _muy_ breve del ejemplo de sqllite , se ve similar a C # con PInvoke, pero desafortunadamente eso no es adecuado para C ++, ya que casi todos los tipos con los que trabaja necesitarían un ajuste, o tendría que escribir algún sistema de interfaz sin tipo totalmente genérico para envolver el C ++. Ninguno de ellos es particularmente atractivo cuando lo comparas con la facilidad de la siguiente clase de Obj-C:

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

O UWP con C ++ / WinRT:

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

Gracias :-)

@Hixie @MarkIngramUK Ninguno de ellos es multiplataforma, que era mi punto.
AppKit es solo para Apple, mientras que UWP es solo para Windows.
Quizás si Flutter hubiera usado Swift o C # en lugar de Dart, entonces ya tendríamos el mismo nivel de soporte, pero ese es un argumento completamente diferente.
Xamarin podría ser una comparación más apropiada que UWP, pero las vistas multiplataforma de Xamarin no eran tan personalizables como las de Flutter y, a menudo, requerían mucho código nativo para lucir decente.
Mi sugerencia aún permanece: si desea usar Flutter con C ++, debe participar en la vista previa de FFI del equipo de Dart y ayudar a mejorar el soporte para todos nosotros 😃

Este problema tiene que ver con la función del idioma y no debe mezclarse con el diseño de la API del widget de la interfaz de usuario.

@atsushieno Seguro, y es por eso que esta discusión sería más productiva en el foro de Dart FFI ... Flutter es el marco. Dart es el idioma.

Ninguno de ellos es particularmente atractivo cuando lo comparas con la facilidad de la siguiente clase de Obj-C:

@MarkIngramUK Estoy seguro de que ese es exactamente el tipo de comentarios que al equipo de Dart le encantaría ver en https://groups.google.com/forum/#!forum/dart -ffi

Tengo un proyecto llamado ezored (https://ezored.com) que es un proyecto de arranque de C ++ para SDK y aplicaciones en C ++. Lo estamos utilizando en proyectos móviles (Android e iOS). Estoy esperando que FFI termine para crear un proyecto que usará el SDK predeterminado en Flutter.

No tenemos ningún problema con C ++ y el tiempo de desarrollo de nuevas características se reduce, ya que el SDK tiene el mismo código en todas las plataformas, como puede ver en la implementación predeterminada (proyecto poco, openssl, sqlite, código de plataforma específico integrado con código puente, etc.).

En mi opción, esta es la mejor manera:

• iOS y Android con backend C ++ (ezored)
• Flutter y C ++ como backend

Siéntase libre de agregar un comienzo al proyecto :)

Kotlin Multiplatform podría ser una solución alternativa, no un pensamiento perfecto. Todavía necesito esperar https://github.com/dart-lang/sdk/issues/34452

Unity3d parece de alguna manera portar flutter a su motor que está basado en C # VM [1] - en ese mundo hablar entre C # y C ++ es decente. Quizás valga la pena echar un vistazo a su repositorio sobre cómo resolvieron algunos problemas. Afirman: "UIWidgets se deriva principalmente de Flutter". También echaría un vistazo a react native camp y su nuevo enfoque con TurboModules: su solución podría tener una ventaja sobre el enfoque flutter, ya que será
1) tanto síncronos como asíncronos y
2) no habrá ninguna clasificación y
3) admitirá no solo C sino C ++

Estoy animando a ambos bandos.

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

A partir de Dart 2.5, esto ( dart:ffi ) ahora está en vista previa:
https://medium.com/dartlang/announcing-dart-2-5-super-charged-development-328822024970

¡Una gran noticia!

Mmm ... ¿será suficiente usar Oboe con Flutter? ..

https://github.com/google/oboe

@ rg4real ¡Sí! Pero, necesitará escribir algunos envoltorios de C ya que la interfaz de Oboe está en C ++.

Puede ver https://github.com/flutter/flutter/wiki/Binding-to-native-code-via-FFI para obtener instrucciones sobre cómo comenzar.

Puede reutilizar mi oboe-c.so que escribí para mis enlaces de C #, si eso funciona https://github.com/atsushieno/oboe-sharp/tree/master/native

@ sjindel-google, ¡son buenas noticias!

Entonces necesito crear un puente entre el código C ++ y C creando clases y funciones. Y luego puedo usar esas clases y llamar a esa función desde un código Dart. Creo que eso es correcto.

@atsushieno , gracias. Estoy echando un vistazo. No estoy seguro de cómo hacer puentes en mi caso (falta de experiencia). Pero, ¿lograste lograr tu objetivo general de tocar con precisión el oboe? ¿Fue tan bueno?

@ rg4real Estaba haciendo eso simplemente para una API más simple (en comparación con OpenSLES) que el audio de baja latencia. Si fuera realmente serio acerca de la latencia, no usaría Xamarin.Android. Si estás hablando de Oboe (o AAudio detrás de él), entonces lo uso en Fluidsynth y funciona bien. Sin embargo, no estoy seguro de "qué tan bueno" es AAudio en comparación con OpenSLES.

¿Existe alguna guía sobre cómo se gestiona la memoria?

Si el código C ++ crea una memoria usando new / malloc y vuelve al código dart, cómo liberar esa memoria.

código c ++
void foo (char ** out) {
* out = new char [25];
}

Cómo borrar la memoria asignada a | out | variable del código de dardo?

Si estás en Dart 2.5, hay un .free() en Pointer . Si está en la rama dev / master, este método movió package:ffi https://github.com/dart-lang/ffi/blob/master/lib/src/allocation.dart#L70.

Según el comentario: "Solo se puede usar contra punteros asignados de manera equivalente a [asignar]". - free () solo se puede usar si la memoria se asigna usando el método allocate ().

p.ej
ffi.Pointerptr = ffi.Pointer.asignar();
ptr.free ();

¿Esto se encarga de liberar la memoria que se asigna en el lado C ++ usando new o malloc desde el código dart?

Siempre que la memoria se haya asignado a través de malloc , ya sea mediante Dart o C ++, se puede liberar con free .

En Dart 2.6 usamos DynamicLibrary.lookupFunction("free") para definir free en Dart, por lo que será exactamente el mismo free que en la parte C ++ del programa. (A menos que esté vinculando varias versiones de free en su binario).

Cerrando este problema, ya que esta función ahora está disponible de forma general (en versión beta) en todos los canales de Flutter. Seguimos mejorando el problema. Para cualquier problema detallado, preséntelo en https://github.com/dart-lang/sdk/issues/new.

Hacer que las clases de C ++ sean compatibles con C es complicado. por favor haga la capacidad para llamar directamente a clases de c ++

+1 ¿Podemos tener soporte para C ++?

@KaungZawHtet y @fzyzcjy : considere abrir un nuevo número (probablemente en dart-lang en lugar de flutter) para esto.

Voy a bloquear este problema: hay muchas personas suscritas, pero su objetivo original está claramente resuelto.

Sí, para problemas nuevos, preséntelos mediante este enlace: https://github.com/dart-lang/sdk/issues/new?labels=library-ffi , area-vm