Flutter: Поддержка интеграции с C / C ++ во фреймворке плагинов

@ jason-simmons знает о Gradle больше всего. Как только у нас будет .so, я определенно могу помочь с его загрузкой.

Я обнаружил, что в buildSrc есть еще одно свойство для установки версии сборки gradle. После обновления до 2.2.2 я продвинулся вперед и смог проверить, что .so загружается и может быть вызван из Java.

Предположительно нам также потребуется добавить C API для отправки сообщений HostMessages из кода C / C ++ в Dart.

Да, пожалуйста. У меня есть подозрение, что обратный вызов C-> Java может быть не из дешевых.

Есть новости по этому поводу? Рассмотрение Flutter для создания кроссплатформенного приложения, которое вызывает код C ++, скомпилированный в общую библиотеку, и это единственная основная точка остановки.

Это возможно сегодня (и @jtrunick сделал это в своем приложении для доставки), но сначала вам нужно отскочить через Java или Obj-C.

то есть вы можете использовать https://flutter.io/platform-channels/ для разговора из Dart с Obj-C / Java, а затем из вызова Obj-C / Java в свой код C ++. Эта ошибка касается добавления более прямой поддержки для этого и, возможно, избежания сквозной передачи Obj-C / Java.

Поскольку виртуальная машина Dart реализована на C ++, не должно ли быть более простого (хотя и менее безопасного) способа прямого вызова разделяемых библиотек C (скажем, через dlopen)? Сколько изменений потребуется для базовой (небезопасной / экспериментальной) поддержки?

Что-то вроде этого: https://www.dartlang.org/articles/dart-vm/native-extensions доступно на android или ios?

Мы слышали это требование от пары приложений Google:

• Одно из таких приложений написало свои собственные библиотеки C ++ для управления камерой, чтобы уменьшить задержку. Эти библиотеки зависят от платформы и оптимизированы для максимально быстрой работы. Вызов этих библиотек с минимально возможной задержкой имеет решающее значение для таких приложений. Принуждение их к прохождению через PlatformChannel + JNI не приведет к этому на Android.

• Существуют продвинутые мобильные группы, которые пишут компоненты бизнес-логики на C ++, чтобы иметь возможность делиться ими между своими реализациями Android и iOS. Flutter, поддерживающий прямую интеграцию с этими библиотеками, еще больше укрепит его позицию как лучшего кроссплатформенного фреймворка.

Я не думаю, что это _обязательно_. Однако это одна из областей, в которой Flutter может еще больше отличаться от других кроссплатформенных решений.

Одно из таких приложений написало свои собственные библиотеки C ++ для управления камерой, чтобы уменьшить задержку. [...] Принуждение их к прохождению через PlatformChannel + JNI не приведет к этому на Android.

Каково было их решение на Android для перехода с C ++ на Java и обратно?

Если это действительно необходимо, мы можем разрешить использование собственных расширений Dart на мобильных платформах. Прямо сейчас мы не показываем символы в dart_api.h . Прежде чем мы сможем щелкнуть выключателем, нам нужно будет принять решение о следующем:

• Выясните, как сделать так, чтобы компилятор AOT знал о коде Dart, единственной точкой входа которого является метод, который может отсутствовать в основной динамической библиотеке движка Flutter. В противном случае проход встряхивания дерева может избавить от кода.
• Предоставьте руководство по созданию и упаковке собственных расширений (Gradle и Xcode для Android и iOS соответственно).
• Предоставьте некоторые гарантии стабильности ABI для подпрограмм в dart_api.h . Хотя он в основном стабилен, я считаю, что он все еще развивается, чтобы учитывать различные режимы.

Пока что механизм каналов платформ, кажется, был адекватен для более простых случаев использования.

Каково было их решение на Android для перехода с C ++ на Java и обратно?

Я не вдавался в подробности их использования. Казалось, что они написали все биты, которые требуют связи с очень малой задержкой, на C ++. Я спрошу, используют ли они какой-либо JNI для случаев использования, критичных к производительности (мне кажется, нет).

Это действительно зависит от того, что мы умеем делать на стороне Flutter. Если мы сможем предоставить взаимодействие, которое будет значительно быстрее, чем JNI, это станет большой победой для этих команд. Они могут уменьшить свою кодовую базу на C ++ и больше перейти на сторону приложений. Если наша производительность взаимодействия сравнима с JNI, то я не вижу здесь большой победы. Вероятно, они могли бы продолжить то, что делают сейчас, и использовать PlatformChannel.

Речь идет о том, чтобы дать таким командам дополнительную причину перейти на Flutter. Я не слышал о том, чтобы это был блокировщик, поэтому расставьте приоритеты соответственно.

Если я правильно понимаю, о чем вы говорите, вы говорите, что текущие решения должны иметь всю логику (камера + пользовательский интерфейс) на C ++ с минимальной логикой в ​​Java, и есть желание переместить часть этой логики пользовательского интерфейса в Dart, без потери интерактивности UI <-> камеры с малой задержкой.

Можете ли вы рассказать о том, какова их ситуация с потоками? У них только одна ветка для камеры + UI?

@chinmaygarde может приблизить нас к решению этой проблемы с его текущей работой над API для встраивания.

+1

Есть ли прогресс в решении этой проблемы?

Мы уже использовали djinni для обмена логикой на разных платформах. Было бы здорово, если бы мы могли взаимодействовать между Dart и C ++, вместо того, чтобы переключаться между Java / Objc-C.

Если Dart сможет интегрироваться с C / C ++, я думаю, что для мобильных устройств будет хорошей идеей повторно использовать тонну нативной библиотеки и не нужно привязываться к конкретной платформе с использованием JNI или Objective C ++.

Вы рассматривали https://github.com/mono/CppSharp? У них уже есть синтаксический анализ и AST для c ++, а также поддержка нескольких целевых языков. Возможно, вы могли бы создать генератор Dart для CppSharp?

Интеграция базы данных на основе C ++, такой как Realm, непосредственно в C ++ позволит добиться значительной производительности и повышения продуктивности разработчиков :-) Переходить вверх / вниз с помощью JNI было бы такой тратой.

Я рассматриваю Flutter для приложения AR, выполняющего компьютерное зрение (возможно, с использованием OpenCV), и эффективное и прямое взаимодействие Dart-C ++ было бы важным положительным моментом. Я полагаю, что многие другие люди, создающие сложные приложения с точки зрения вычислений, могут разделить эту потребность.

Можете ли вы подтвердить, что взаимодействие с C ++ по-прежнему недоступно? Можно ли это сделать с помощью пакетов?

@tofutim Прямое каналы платформы, а затем использовать Obj-C / Java для взаимодействия с вашим кодом C ++. Это не здорово, но это все, что у нас есть на данный момент.

Можете ли вы подтвердить, что взаимодействие с C ++ по-прежнему недоступно? Можно ли это сделать с помощью пакетов?

Для взаимодействия с библиотеками платформы в настоящее время рекомендуется использовать механизм

Более производительный механизм, описанный в документе о собственных расширениях, можно добавить тривиально. Однако мне неизвестны какие-либо гарантии стабильности ABI для символов, представленных в dart_api.h . Если @ a- siva и Tonic в качестве удобных оболочек вокруг C API для простоты использования с C ++.

Насколько я понимаю, эта ошибка связана с предоставлением C-API и инструментария, чтобы упростить использование полностью плагина C / C ++ (не требуется шиммирование Obj-C / Java, но все еще асинхронно через platform_channels).

Я не думаю, что в настоящее время нам следует рассматривать синхронные методы как собственные расширения. (Но, честно говоря, я доверяю это

@eseidel

Я не думаю, что в настоящее время мы должны рассматривать синхронные методы, такие как собственные расширения.

это почему?

Текущий подход к вызову C code: Dart -> Java -> C
Мы дважды пересекаем JNI , верно?
первый раз: от dart до Java через каналы платформы (под капотом используется вызов JNI , верно?)
второй раз: Java -> C через JNI

Например, с точки зрения потребностей моего проекта, наличие доступа к dart_api.h даже без гарантии стабильности (например, в качестве экспериментальной функции) уже было бы достаточно хорошо. Моя основная задача - переместить большие двоичные данные (изображения) со стороны Dart на сторону C и обратно без маршалинга и, в идеале, копирования. Unity / Mono достигает этого .

Из выпуска dart-sdk 31960 я понимаю, что текущая реализация изолятов может не позволять передавать данные без копирования (хотя теоретически должно быть возможно обнаружить, что буфер, созданный в изоляторе A, больше не используется после передачи для изоляции B и, следовательно, его право собственности может быть передано без копирования ... какого-либо плана на этом фронте?), но если хотя бы внутри изолированного объекта нет маршалинга в / из C это было бы хорошо.

Маршаллинга можно избежать с помощью плоских буферов, которые, похоже, скоро появятся: https://github.com/google/flatbuffers/pull/4676
Или с сообщениями protobuf, использующими только одно байтовое поле.

Конечно, это влечет за собой копирование большого количества байтов, что не подходит для всех случаев использования.

Я слышу как минимум три разных желания, представленных здесь:

1. Хотел бы способ легко написать плагин для Flutter, используя только код C / C ++, без необходимости добавлять кучу клея Java / Obj-C (это было мое первоначальное понимание этой ошибки и то, что я определенно думаю, что мы можем / должны сделать) .
2. Хотелось бы иметь способ быстро переместить большой объем данных в / из Dart / с малой задержкой / и т. Д. (Предположительно из разных языков, включая C ++. Это звучит как очень веский случай! Я настоятельно рекомендую зарегистрировать отдельную ошибку, включая пример.)
3. Хотите способ расширить Dart синхронными вызовами / объектами? (например, собственные расширения или другие методы? Это также вполне выполнимо. Существуют потенциальные трудности со стабильностью API, и я думаю, что мы хотели бы узнать больше о конкретном варианте использования, прежде чем принимать меры.)

Мой отзыв о прочтении вышеизложенного состоит в том, что нам следует рассмотреть возможность устранения некоторых дополнительных ошибок. Нам определенно нужно вложить немного средств в взаимодействие с C ++, но из этого длинного потока трудно определить, какие именно варианты использования мы должны рассмотреть и в каком порядке?

Хотят ли / смогут ли заинтересованные стороны сообщать о новых ошибках с желаемыми вариантами использования и ссылаться на них здесь? С радостью оставляю этот вопрос открытым, чтобы отслеживать общий интерес к этому проблемному пространству.

Что касается производительности и 2. выше: хотя я уверен, что производительность Flutter platform_channels может быть улучшена (и что нам, вероятно, потребуются другие подключаемые / межоперационные методы для покрытия всех случаев использования), нам понадобятся некоторые конкретные варианты использования (может быть, они существуют, и я их не видел?), где производительность Flutter platform_channels является узким местом, прежде чем мы примем меры. Мой опыт оптимизации производительности систем показывает, что мои инстинкты часто ошибаются. Даже если такие вещи, как JNI или platform_channels, кажутся потенциальными узкими местами, мы не узнаем, пока не проведем измерения.

Еще раз спасибо всем за вашу помощь и отзывы!

Хотел бы способ легко написать плагин для Flutter, используя только код C / C ++, без необходимости добавлять кучу клея Java / Obj-C (это было мое первоначальное понимание этой ошибки и то, что я определенно думаю, что мы можем / должны сделать) .

это также улучшит интеграцию sqlite для flutter + существует множество библиотек C / Rust для шифрования, ssh и прочего. Было бы здорово иметь возможность легко этим пользоваться.

@eseidel

Я слышу как минимум три разных желания

Мой голос за 1.)

После прочтения документации Flutter должно быть довольно «просто» расширить каналы платформы для поддержки C.
Единственным новшеством, вероятно, будет способ загрузки _ динамических общих объектов_ в текущий процесс.

Я могу представить, что использование _Android-C_ будет выглядеть примерно так:

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

MethodChannel* flutter_channels;

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

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

#define str(a) #a

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

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

Концептуально, по крайней мере для _Android-C_, вам нужно будет решить, как обрабатывать комбинацию Java и C.

@eseidelGoogle
В настоящее время мы предоставляем код golang через оболочки Java и swift, и задержка является заметной проблемой, с которой мы сталкиваемся.
Почему ?

• Нам нужно разделять бизнес-логику между многими платформами.
• Для функций видео и изображений, таких как совместное использование экрана.
• Для БД.

Если вы сможете добавить поддержку голанга на прямом уровне, это будет иметь значение!
Компиляция кода golang для мобильных устройств также очень проста без какой-либо магии LDFLags, поэтому я думаю, что это будет популярно. Я знаю еще несколько кодировщиков golang, которые в настоящее время также используют каналы метода.
Что касается сериализации, в настоящее время мы используем Protobufs и flatbuffers.

Пример:
https://github.com/dnfield/flatbuffers/blob/master/samples/sample_binary.go

В фуксии это делается с помощью FIDL, и у него есть привязки к c, ржавчине и голангу.
Его довольно круто использовать, и я с удовольствием пробовал ржавчину и голанг на встроенной плате.

Должна быть возможность открывать файлы fidl через iOS и java.
Это даст хороший переход между фуксией и трепетанием на мобильных и настольных компьютерах.
Просто идея, с которой я играю

@eseidelGoogle
Hiixe сказал мне, что FIDL не может быть выполнен на уровне Flutter, потому что FIDL полагается на код ядра из zircon в Fuchsia. Таким образом, единственный способ воспроизвести функциональность стиля FIDL IPC во Flutter - это написать версию FIDL в движке Flutter. Но потом я поигрался с ним и заметил, что он очень похож на Flatbuffers. Так почему бы просто не использовать FlatBuffers для уровня сериализации между Flutter и cpp, или golang, или слоем ржавчины на Flutter. ?

Просто +1 к этому, у нас есть приложение Flutter, использующее библиотеку под названием Superpowered. Superpowered написан на C ++, затем мы используем элементы типа java и JNI для взаимодействия с ним, которые мы, в свою очередь, используем каналы платформы для общения с кодом Java. Было бы неплохо, если бы мы могли пропустить среднего человека.

Это дополнительно связано с тем, что популярные мобильные библиотеки, такие как Realm, не могут создавать флаттер-версии, потому что их ядро ​​написано на C / C ++, и они также не хотят иметь дело с посредником java / objc / swift.

По этим причинам, помимо общей стабильности, я думаю, что эта проблема - одно из самых необходимых изменений в флаттере на данный момент. (В частности, №1 в списке @eseidelGoogle .)

Если вы хотите услышать аргумент в пользу обхода Java / JNI в расширениях платформы (т. Е. Не просто скрытия / автоматизации связующего слоя Java для разработчика), Superpowered может многое сказать по этой теме: https://www.youtube. com / watch? v = LzIuir3r6Co

@pnico Не могли бы вы объяснить, как это утверждает, что Java / JNI должен быть двусторонним? Кажется, это говорит лишь о том, что ваш код обработки звука должен быть написан на C ++. (Это не значит, что вы не можете вызвать его через JNI или каким-либо другим способом)

@ csga5000, вы совершенно правы, это не имело смысла: D JNI, вероятно, не повлияет на производительность, если вы не пытаетесь делать более эзотерические вещи. Я думаю, это действительно сводится к удобству / ремонтопригодности, и я предполагаю, что, возможно, возможность перенести больше кода, специфичного для приложения, из Java / C ++ в Dart.

Я думаю, что @pnico говорит, что он МОЖЕТ вызвать его через JINI, но JINI добавляет слишком большую задержку.
Итак, перфоманс - это проблема.
да нет ??

Это может иметь огромное значение в основном для работы, связанной с криптовалютой.

Также я предполагаю, что для Android Things, хотя я не видел и не проводил экспериментов
и тесты для чувствительного к времени gpio ни в c, ни в дротике для более чем
год.

Сб., 9 июня 2018 г., 10:52 Эдди WM, [email protected] написал:

Это может иметь огромное значение в основном для работы, связанной с криптовалютой.

-
Вы получаете это, потому что подписаны на эту беседу.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/flutter/flutter/issues/7053#issuecomment-395927258 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AFHMcSI2JDHbgv3iYrStDN5mlzkQ8XEkks5t6xxMgaJpZM4K-PLw
.

Есть ли прогресс с тех пор?

Пока эта проблема не будет решена, есть ли рекомендация для примера плагина flutter, который показывает, как интегрировать ac / c ++ lib? Джинни - хороший способ пойти?

Пока он не будет решен, единственный способ интегрировать c / c ++ - написать собственный код для Android и iOS, а затем взаимодействовать с кодом дротика с помощью каналов платформы.

Я реализовал плагины, которые используют каналы платформы (для файлов jar и CocoaPods). Я ищу пример плагина, который показывает, как интегрироваться в одну и ту же библиотеку c / c ++ (как для Android, так и для iOS). Какие-нибудь рекомендации?

@ mmcc007 Это то, как вы это делаете в java или 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

Вы можете увидеть, как superpowered рекомендует вам это сделать, если вам действительно нужен пример (это только один, о котором я знаю): https://github.com/superpoweredSDK/Low-Latency-Android-iOS-Linux-Windows-tvOS-macOS- Интерактивная аудио-платформа
См. Папки с примерами. Например, в https://github.com/superpoweredSDK/Low-Latency-Android-iOS-Linux-Windows-tvOS-macOS-Interactive-Audio-Platform/tree/master/Examples_Android/SuperpoweredRecorder/app/src/main есть java / com / superpowered / recorder / MainActivity.java, который ссылается на код в cpp / RecorderExample.cpp

@ csga5000 Похоже, что это было бы достаточно просто ... при первом обзоре. Еще было бы неплохо посмотреть через работающий плагин флаттера. Спасибо.

+1 за это. Любые рабочие примеры приложения flutter, использующего c ++, будут хорошо приняты.

Есть проект, который делает это для голанга, и я думаю, что такой же подход
может использоваться и для c ++.

Программа golang использует jsonrpc.
Тогда все, что вам нужно сделать, это создать собственный код golang с помощью jsonrpc.

Тогда все очень просто.

Я думаю, что каналы платформы ТОЛЬКО поддерживают JSON в качестве независимой сериализации.
формат?

В среду, 18 июля 2018 г., 16:50 Джефферсон Бледсо, [email protected]
написал:

+1 за это. Любые рабочие примеры приложения flutter с использованием C ++ будут
Хорошо принят

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/flutter/flutter/issues/7053#issuecomment-405958345 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ATuCwkPbb9vLdoaEwM-bLhYPZxtyQ5Vjks5uH0sqgaJpZM4K-PLw
.

Привет, есть новости?

Просто хотите знать, удалось ли кому-нибудь в этой ветке интегрировать библиотеку Superpowered непосредственно в приложение Flutter?

Да @ skills-up, мы это сделали. Просто не в проекте с открытым исходным кодом, поэтому я не могу показать. Но если вы видели мои советы ранее, значит, вы это делаете именно так. Вам может потребоваться создать приложение flutter для каждой архитектуры процессора, хотя

Насколько я понимаю, вы сделали это через JNI / Java, а не напрямую через dart. Мне было интересно, можно ли вообще избежать кода, специфичного для платформы.

Вам может потребоваться создать приложение flutter для каждой архитектуры процессора, хотя

Вы имеете в виду отдельное приложение для каждой архитектуры или просто указываете все поддерживаемые архитектуры?

Кстати, у нас уже есть работающее приложение, написанное на Java. Однако теперь, когда нам нужно создать приложение для iOS, мне было интересно, будет ли создание такого приложения во флаттере (вместо затраченных усилий на Swift / XCode) более разумным с точки зрения будущей ремонтопригодности с преимуществом единой базы кода.

Хорошо. Realm ждет, чтобы вы, ребята, предоставили способ: https://github.com/realm/realm-object-server/issues/55

lukaspili: думаю, все еще ждут: flutter / flutter # 7053
bmunkholm: @lukaspili Да, это обязательно.

Как бы то ни было, я тоже этого жду. Не могу действительно подумать о замене приложений XF на флаттер, пока вы, ребята, не получите надлежащую сантехнику. В его нынешнем виде Xamarin выдувает флаттер из воды в этом отделе.

Поздно к этой вечеринке, но большой +1 для этой темы.

Я разрабатываю настольные приложения, мой взгляд как строка кода (для рабочего стола):

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

Если Flutter может предложить первоклассную поддержку C ++, я думаю, что этот общий подход может стать абсолютным победителем для разработки кроссплатформенных приложений, причем не только «сначала мобильные», но и впервые в мире. Qt дорогостоящий для небольших разработчиков, самоуверен и не поддерживает современный C ++, и ничто по-настоящему не конкурирует, может ли Flutter съесть хотя бы часть своего UI-пирога?

PS: Я не анти-дартс, это очередной новый C # / Go / Rust / etc. конкурирующим языком, который может быть суперпродуктивным для новой платформы, но мир высокопроизводительных настольных приложений (мой интерес здесь) - это твердо C ++ с обширной поддержкой ОС и библиотек, язык, который сам движется вперед со скоростью узлов (это не C), и я думаю, что Flutter этого заслуживает!

Я не думаю, что flutter будет поддерживать C ++ в ближайшем будущем, а сейчас это определенно невозможно. И я, со своей стороны, чрезвычайно предпочитаю Dart - написание приложений на C ++ даже с флаттером потребует гораздо больше усилий. И я не думаю, что C ++ напрямую влияет на поддержку настольных компьютеров, им все равно придется написать довольно много кода, а виртуальная машина dart в любом случае должна работать для настольных компьютеров. Я считаю, что для большинства приложений производительность ничтожна.

Я думаю, что в конечном итоге Google хочет поддерживать совместимость, чтобы вы могли писать приложения флаттера для любых без исключения платформ, используя любые поддерживаемые языки или даже их комбинацию. Но я бы не ожидал этого до тех пор, пока не будет выпущен Fuchsia. На данный момент их цель - упростить однократное написание кода. Dart соответствует этой цели, поскольку он прост в использовании / изучении, эффективен и в любом случае является одним из языков Google. Я действительно не вижу почти никакой практической пользы для среднего пользователя в наличии первоклассной поддержки C ++. В мобильном приложении производительность незначительна, и использование каналов платформы с C ++ было бы удобно для взаимодействия с существующими библиотеками C ++. С другой стороны, вы можете быть уверены, что они в конечном итоге намереваются использовать флаттер для поддержки рабочего стола (ну, по крайней мере, капибара Fuchsia, но я сомневаюсь, что они остановятся на этом).

Этот поток посвящен поддержке прямой интеграции с C ++ от dart / flutter, которая, надеюсь, может появиться в ближайшем будущем.

Я не думаю, что flutter будет поддерживать C ++
Я действительно не вижу почти никакой практической пользы для среднего пользователя в наличии первоклассной поддержки C ++.

Речь идет не о том, насколько хорош Flutter / Dart по сравнению с C ++, а о простоте интеграции, необходимой для того, чтобы вписаться в текущую экосистему. Существует длинный список библиотек в виде общих объектов (OpenCV, чтобы назвать один), которые являются отраслевым стандартом, вы не можете ожидать, что люди переписывают их в Dart?

В мобильном приложении производительность незначительна, и использование каналов платформы с C ++ было бы удобно для взаимодействия с существующими библиотеками C ++.

Напротив, использование каналов в этом контексте неоптимально. Подумайте о случаях использования, когда вам нужно работать с большим двоичным объектом в памяти (изображениями), вам потребуется либо:
1- Скопируйте эти двоичные файлы из / в память C ++
2- Работа с JNI для взаимодействия с библиотекой (и обработки указателей, динамически выделяемых этим двоичным файлам)
не говоря уже о накладных расходах на сериализацию / десериализацию значений / параметров, которые вы несете при использовании каналов.

Хорошая структура - это баланс между новыми функциями / парадигмами, которые он вводит, и тем, насколько легко интегрироваться с текущей экосистемой / наследием, частью чего мы не можем отрицать, что C ++ является частью.

@nhachicha @ csga5000 не напрямую использовать Flutter

В мобильном приложении производительность незначительна, и использование каналов платформы с C ++ было бы удобно для взаимодействия с существующими библиотеками C ++.
@nhachicha Я не могу с этим согласиться.

Правда для приложений, которым не нужна производительность прикуса (а их много), тогда почему бы не поменять сложный для освоения C ++ на что-то более продуктивное, на самом деле, зачем останавливаться только на Dart, почему бы не занять место в любом из этих суперпопулярных, ( намного более популярных / признанных, чем Dart) языков:

• Среда выполнения C # /. Net Core
• Среда выполнения Javascript / Typescript V8 (на тот момент у вас был бы почти браузер, но что с того)
• Ржавчина (тоже быстро!)
• GoLang
• Python
• [Вставьте сюда свой любимый] ...

И хотя я лично люблю и использую некоторые из этих языков каждый день, C и C ++ лежат в основе Linux, следовательно, Android, iOS и настольных платформ, таких как Windows, MacOS и другие настольные компьютеры. Половина из перечисленных выше языков (включая Dart) написана на C ++. Передовые технологии снова и снова требуют настраиваемой собственной производительности, такой как AI (Tensorflow - это C ++, Caffe C ++, Pytorch - это C под Python и т. Д.), Библиотеки дополненной реальности, игровые движки AAA и все, что необходимо для графического процессора (CUDA , вызывается из C / C ++).

По той же причине, по которой движок рендеринга Flutter сам написан на C ++ (собственный, высокопроизводительный, эффективный аккумулятор / память / ЦП), я думаю, было бы здорово разблокировать максимально возможную производительность, когда это необходимо, не приближаясь к управляемой среде выполнения. и просто поддерживает C ++. Это отличает Flutter от других фреймворков, таких как Xamarin и Nativescript, которые, честно говоря, предлагают аналогичный опыт разработки (с использованием обоих) только с разными языками, почему бы не сделать флаттер особенным, а не просто «Dart one»?

_ В качестве примечания, я полностью дома, когда пишу все на C / C ++, от проверки формы до пиксельных шейдеров, но я не притворяюсь, что это мнение многих людей, просматривающих это репо, - и это потому, что я считаю C ++ высокопроизводительный язык - однако выбор полностью личный.

Это одна из основных причин, по которой нам нужна интеграция с C ++.

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

Есть два простых способа интеграции C / C ++:

• Обеспечить реализацию канала метода на C ++
• Обеспечить поддержку собственных расширений Dart VM

К сожалению, у обоих из них есть серьезные недостатки, которые не позволяют нам их преследовать:

• Каналы методов представляют собой абстракцию с высокими накладными расходами, в то время как интеграция C / C ++ требуется, когда желательны взаимодействия с низкими накладными расходами. Это означает, что каналы метода на самом деле не решат проблему.
• Собственные расширения Dart VM требуют, чтобы люди использовали Dart VM C API - может быть нежелательно вводить слишком много внешних зависимостей от этого, особенно с учетом того факта, что API не устарел и требует серьезного рефакторинга.

Кажется, что более желательной альтернативой является введение dart:ffi - основного компонента виртуальной машины Dart, который позволит напрямую связываться с собственным кодом, позволяя людям писать что-то вроде:

import 'dart:ffi' as ffi;

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

У нас был определенный интерес к реализации такого FFI в течение долгого времени - я ожидал, что мы поэкспериментируем с ним в ближайшее время, но я не буду связывать какие-либо конкретные сроки.

@ kirbyfan64 Совершенно верно, @nailgilaziev , @bytesoftly Я не пытаюсь сказать, что интеграция с C ++ не нужна, я просто сказал, что не думаю, что существует столько причин / требований для поддержки флаттера C ++ INPLACE of dart - но Я не говорю, что интеграция не нужна. То, что говорит @mraleph , кажется мне умным.

@mraleph У Дартино была аналогичная реализация для FFI . Насколько сложно воскресить?

@listepo его части. Реализация FFI в Дартино была очень динамичной - это не то, что нам нужно для Dart 2, который значительно более статичен, чем Dart 1.

Поздно в игре, но вот еще один вариант использования: мы хотели бы включить c-файлы и методы в dart для криптографических целей.

Мы надеемся на следующее:
1) Идентичный код для iOS и Android, т.е. без прохождения уровней ObjC или JNI.
2) Надеюсь, это более эффективная реализация, чем при прохождении, например, JNI дважды.
3) Возможность повторно использовать код модели дротика в последующем веб-приложении, например, в AngularDart, или последующих настольных приложениях с использованием этого проекта: https://github.com/google/flutter-desktop-embedding

Я считаю, что то, что мы хотим, ближе всего к пункту 2 @eseidelGoogle, упомянутому выше. Что касается синхронной поддержки, я считаю, что это «приятно иметь», так как асинхронные функции не могут использоваться в конструкторе, где можно выполнить, например, быстрое вычисление хэша. Но для того, чтобы привыкнуть к асинхронному способу Darts, синхронная поддержка оказывается менее важной, чем общая возможность достижения пунктов 1) -3) выше.

Использование FFI, как предлагает @mraleph , позволит ли это использовать 1) -3), как в моем предыдущем комментарии, или это будет означать, что на разных платформах (Android, iOS, ...) нужен другой код?

@CryptUser, если ваш код C / C ++ одинаков на всех платформах, код Dart для его вызова через FFI также будет одинаковым на всех платформах.

@mraleph Звучит здорово! Учитывая, что исходный выпуск получил более 200 одобрений, есть ли шанс повысить его приоритет?

@mraleph есть ли где-нибудь открытая проблема для FFI в Dart?

@dnfield Я только что подал его https://github.com/dart-lang/sdk/issues/34452

Я хотел бы иметь возможность писать код на C / C ++ / Rust и использовать его поверх ffi.

Пример:

Тестирую флаттер на планшете android (Android 4.4).
флаттер бегать быстро.
Но когда я пытаюсь прочитать 1000 строк с sqflite, которые используют канал платформы, это смешно медленно.
Причина: я не могу использовать программу чтения курсора sqlite.

но если бы я мог напрямую использовать библиотеку sqlite, тот же запрос был бы мгновенным. (протестировано с помощью xamarin и собственного проекта Android).

Мы обсуждаем прямо сейчас, как лучше всего подойти к этому. Как отмечалось выше в https://github.com/flutter/flutter/issues/7053#issuecomment-377711814, эта проблема состоит из многих частей и, вероятно, ее необходимо разделить. :)

Но мы нашли некоторых инженеров, заинтересованных в изучении FFI (как указано в https://github.com/flutter/flutter/issues/7053#issuecomment-415161464). Сейчас мы сосредоточены на выпуске версии 1.0, но как только это будет сделано, она будет одной из первых в списке. Еще раз спасибо за все ваши отзывы. Мы обновим эту проблему, когда у нас будет больше информации о прогрессе.

Я также являюсь пользователем Matlab / Simulink. Я могу сгенерировать высокооптимизированный код c / cpp для конкретного процессора. Я хочу интегрировать свой алгоритм в флаттер. У меня много алгоритмов обработки изображений. Мне нужен генератор привязки для нативных кодов. В противном случае я забуду все свои переживания, связанные с трепетанием дротиков, и начну изучать xamarin или что-то, что мне подходит.

Можем ли мы ускорить прогресс?

Просто такая огромная боль - взаимодействовать между Дарт и Си.

Спешка вряд ли приведет к получению продукта хорошего качества. Он будет готов, когда будет готов. :-)

Спешка вряд ли приведет к получению продукта хорошего качества. Он будет готов, когда будет готов. :-)

Что ж, я попытался сказать, что мы, возможно, захотим повысить приоритет, чтобы мы могли приложить больше ресурсов и усилий для решения этой проблемы. Вы знаете, что на данный момент существует 1386 открытых проблем, нацеленных на «Цель», которые будут «исправлены в ближайшие годы».

Прочитав ветку еще раз, я заметил, что

«Гол» может оказаться неправильным ведром. :) У @mraleph есть кто-то, изучающий https://github.com/dart-lang/sdk/issues/34452, как мы говорим. По крайней мере, это часть решения.

Вот документ о видении FFI, который мы в настоящее время создаем на стороне Dart.

Пожалуйста, взгляните и дайте нам знать, что вы думаете.

Я не могу много сказать о части FFI, потому что я никогда не использовал что-то подобное,
но мне интересно, как будет выглядеть интеграция пабов.

Как будет обрабатываться публикация пакетов, использующих FFI?
Как будет обрабатываться использование пакетов, использующих FFI?

@zoechi, мы еще не обсуждали интеграцию pub .

Они должны иметь возможность работать аналогично плагинам Flutter сегодня - включать соответствующие платформе / архитектуре источники и / или двоичные файлы, которые могут быть скомпилированы / связаны с приложением-потребителем.

С точки зрения паба, это не должно иметь большого значения, за исключением того, что в пакет могут быть включены бинарные файлы большего размера.

Тем не менее, потребуется некоторая работа над инструментами Flutter, чтобы интегрировать их в проекты Flutter - они действительно не будут работать так же, как плагины Android / iOS сегодня.

Следует ли перенести интеграцию пабов в категорию «dart-lang / pub», чтобы эта проблема оставалась более сфокусированной?

Я прочитал «документ о видении» и, наконец, вижу фигуры в тумане.

Тем временем я размышлял о другом.

А именно (повторного) использования Flatbuffers для создания чего-то вроде NativeChannels. Во время выполнения (AOT) это будет сводиться к передаче указателя, тогда как во время разработки это позволит мне использовать существующие инструменты для «нативной» стороны, написанные не только на C / C ++, но также написанные на Go или Rust.

Подход к передаче сообщений также больше соответствует текущим архитектурам на основе потоков (Bloc, Rx). Это также снимает любые опасения по поводу управления памятью, поскольку компилятор может генерировать подходящие кольцевые буферы, где это необходимо, или предполагать простые «освобождения вызываемого», когда вызываемый объект должен дольше удерживать данные.

Но, честно говоря, я буду приветствовать любую форму ffi, если она будет бесшовно интегрирована в экосистему Flutter (Fuchsia) и позволит мне использовать оптимизированный для процессора собственный код из приложения Dart.

@ohir то, что вы

@eseidelGoogle есть прогресс в этом

Для этих приложений, основанных на постраничном интерфейсе, теперь флаттер, я думаю, действительно хороший выбор, чем переход к двойному кодированию как на Android, так и на iOS ， если бы мы были 5 лет назад с таким прекрасным оборудованием ， вся индустрия приложений могла бы быть изменен. Однако преимущества флаттера прямо сейчас не так впечатляют для компаний, переходящих на него, потому что они уже достаточно хорошо справились со старым способом, но для некоторых задач, не связанных с пользовательским интерфейсом, дротик далеко отстает от главного требования.

это не означает, что дротик в один прекрасный день не годится и не жизнеспособен для решения этих задач, но с точки зрения нормальной ИТ-компании, которая может быть включена в экосистему флаттера, им нужно снизить затраты за счет использования перекрестного платформенный метод кодирования только в том случае, если могут быть реализованы самые лучшие классные функции, такие как обработка данных на стороне клиента, видео / аудио, персонал AR и т. д., если какой-то алгоритм они уже реализовали через c / c ++. им действительно сложно реализовать или заново изобрести его, используя dart lang.

и ключевым решением является введение прямого и эффективного способа взаимодействия flutter с c ++, я даже думаю, что это один из главных приоритетов "кроссплатформенной" вещи, дротик для UI-персонала идеален, некоторая нормальная логика данных также может быть сделано в дротике, но для флаттера гораздо лучше слиться с длинной, но все еще активной и эффективной экосистемой С ++, чем перестраивать новую священную!

Мечта о реальном «кроссплатформенном» кодировании - это дартс-штучка пользовательского интерфейса с C ++ за капотом, без кода Java вообще, без кода Oc. вахаха, мне не терпится увидеть, как это произойдет!

@smellbee Разве вы не можете использовать командную строку ffmpeg?

@smellbee I featr Я не тот, кто на это отвечает. @eseidelGoogle есть новости по этому

@smellbee Разве вы не можете использовать командную строку ffmpeg?

это работа на стороне клиента, использование ffmpeg lib для рендеринга видеокадров для создания мгновенного потока обратной связи, можно ли использовать командную строку?

@smellbee I featr Я не тот, кто на это отвечает. @eseidelGoogle есть новости по этому

извините за это, я набрал "es", и он автоматически завершился, я этого не заметил .... надеюсь, @eseidelGoogle это увидит

Работа над Dart продолжается - мы надеемся, что что-то будет готово в первом квартале 2019 года.

Это важная функция, и мы хотели бы понять ее правильно: поскольку мы хотим, чтобы она отлично работала в различных режимах выполнения для Dart, пожалуйста, будьте терпеливы, пока мы прорабатываем детали.

Вы можете следить за dart-lang / sdk # 34452, который отслеживает работу на стороне Dart.

Dart FFI позволит вызывать C-функции из Dart.
Но как насчет возможностей C ++ - классов, контейнеров std, интеллектуальных указателей, исключений?
Можем ли мы рассчитывать на возможность экспорта классов C ++ в Dart с минимальным набором шаблонов?

Еще одна очень важная особенность - поддержка асинхронности - возможность запускать код C ++ в отдельном потоке и возвращать Future / Stream из методов.

@ t-artikov В настоящее время нет планов по прямой поддержке взаимодействия с C ++. Это слишком сложно. Единственное, что может эргономично взаимодействовать с C ++, - это C ++.

Если вас интересует высокоуровневое взаимодействие с C ++, вам нужно будет создать свой собственный уровень взаимодействия, который предоставляет ваш C ++ API через C-подобный API.

Еще одна очень важная особенность - поддержка асинхронности - возможность запускать код C ++ в отдельном потоке и возвращать Future / Stream из методов.

Я думаю, что это можно построить как пакет. Нам просто нужно убедиться, что мы предоставляем правильные примитивы, чтобы это можно было построить.

Dart FFI позволит вызывать C-функции из Dart.
Но как насчет возможностей C ++ - классов, контейнеров std, интеллектуальных указателей, исключений?
Можем ли мы рассчитывать на возможность экспорта классов C ++ в Dart с минимальным набором шаблонов?

Если у C ++ есть способ вызвать dart ， Я думаю, что это возможно ， C ++ позаботится о том, о чем беспокоится C ++ ， и взаимодействует с dart, вызывая или вызывая, нет необходимости подвергать какие-либо низкоуровневые манипуляции для дротик, который разрушит простоту использования дротика.

Еще одна очень важная особенность - поддержка асинхронности - возможность запускать код C ++ в отдельном потоке и возвращать Future / Stream из методов.

И у dart уже есть свой асинхронный механизм ， так что ， ориентирован ли поток на C ++ или нет, не имеет значения ， до тех пор, пока часть C ++ может вызывать dart всякий раз, когда это необходимо, а «Isolate» может выполнять эту работу.

Я так думаю @mraleph , поправьте меня, если я ошибаюсь;)

@mraleph
Фактически, есть примеры отличного взаимодействия C ++ с другими языками.
https://github.com/boostorg/python
https://github.com/ThePhD/sol2
https://github.com/dropbox/djinni
Я надеюсь, что Dart / Flutter предоставит аналогичный механизм из коробки.

Если вас интересует высокоуровневое взаимодействие с C ++, вам нужно будет создать свой собственный уровень взаимодействия, который предоставляет ваш C ++ API через C-подобный API.

Чтобы было понятно, как этот подход применим, не могли бы вы продемонстрировать его на примере следующих классов С ++:

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

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

Чтобы его можно было использовать из Дарта

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

@ t-artikov и boostorg::python и sol2 самом деле очень хорошо иллюстрируют мою точку зрения. Обратите внимание, что это библиотеки C ++ для взаимодействия с другими языками, а не наоборот. Dart FFI - это ориентированный на Dart способ вызова API-интерфейсов C, а не на ориентированный на C ++ способ вызова Dart.

Чтобы было понятно, как этот подход применим, не могли бы вы продемонстрировать его на примере следующих классов С ++:

Вам нужно будет написать (или сгенерировать каким-либо инструментом) что-то вроде этого.

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

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

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

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

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

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

void MyObject_destroy(MyObjectPtr obj) {
  delete obj;
}

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

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

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

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

class MyObject {
  final Pointer<Void> _impl;

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

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

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

Обратите внимание, что это библиотеки C ++ для взаимодействия с другими языками, а не наоборот.

Вы ошибаетесь, они позволяют выставлять классы C ++ другим языкам.
https://www.boost.org/doc/libs/1_68_0/libs/python/doc/html/tutorial/tutorial/exposing.html

Спасибо за ваш пример Dart FFI.
Есть некоторые недостатки: исключение C ++ должно передаваться на сторону Dart; и MyObject.data не будет работать таким образом (он получает только указатель, но не размер данных).
Но идея ясна.

На мой взгляд, такой код слишком многословен, чтобы писать его вручную.
Я с нетерпением жду возможности увидеть, будет ли этот процесс автоматизирован для новых привязок Dart FFI Flutter Engine.

Связывание во время выполнения для взаимодействия с C ++ практически невозможно (как вы справляетесь с универсальными шаблонами, множественным наследованием, перегрузками операторов, искаженными именами и т. Д.). Было много трудных попыток (BridJ, CppSharp и т. Д.), И, насколько я понимаю, люди считают взаимодействие с C наиболее жизнеспособным вариантом.

Маловероятно, что официальные разработчики совместимости могут достичь для C ++ очень общего решения. Kotlin / Native этого не предлагает. Scala-нативный iether. .NET тоже (взаимодействие Microsoft C ++ всегда либо странно, либо статично). JNI поддерживает взаимодействие C ++ только при статической компиляции. Что-то вроде python boost glue нужно писать вручную. Любая сторонняя группа может разрабатывать такие вещи, как JNAerator (т.е. ВЫ можете это делать, не нужно ожидать, что команды Dart / Flutter добьются этого).

После этого разговора без реального ответа, я думаю, что буду придерживаться Qt, который является кросс-платформенным и имеет полную поддержку C ++. Я как раз думал попробовать Flutter в моем следующем проекте, но теперь не хочу, спасибо большое!

Было бы лучше, если бы flutter был написан на C ++, с которым взаимодействие с любым другим языком было бы легко возможно. Есть ли попытка переписать флаттер на C ++?

Я думаю, что обсуждение сейчас излишне затягивается.

Мы знаем, что входит (или не входит) в план развития флаттера.
Соответственно, мы можем решить использовать (или не использовать) его для конкретных случаев использования.

Я не вижу никакой пользы в попытках изменить повестку дня в области развития или
требующие конкретной архитектурной реализации, за пределами этой точки.

Спасибо,
Гаурав

В пн, 25 февраля 2019 г., 22:51 bhauj, [email protected] написал:

Было бы лучше, если бы флаттер был написан на C ++, с
взаимодействие с любым другим языком было бы легко возможным. Является
есть ли попытки переписать флаттер на C ++?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/flutter/flutter/issues/7053#issuecomment-467098455 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AZ86acDpZgNeyezx40uxe_c5E2xZHWxaks5vRBumgaJpZM4K-PLw
.

На самом деле Flutter, насколько я знаю, написан на C ++, но программировать на Flutter можно только с помощью интерпретатора Language Dart, который работает в виртуальной машине. Но у вас еще нет шанса перейти от Dart к C ++ части Flutter ...

Итак, кто бы ни читал это и имеет общий вариант использования в Appdevelopment хорошей кроссплатформенной разработки, Flutter не разрешит прямое использование C ++, если он вам нужен, а затем используйте другую кроссплатформенную платформу, такую ​​как Qt C ++.

Для меня C ++ необходим для кросс-платформенной разработки, потому что это наименьший общий знаменатель почти во всех технологиях.

@aqmappdesigners

интерпретатор Language Dart, который работает на виртуальной машине

Это не совсем так.

Flutter использует виртуальную машину Dart в режиме отладки, что также делает возможной горячую перезагрузку.
В релизных сборках Dart компилируется в двоичный код наподобие C ++.

@zoechi Спасибо, я этого не знал. Звучит хорошо для выступления

Звучит хорошо для выступления

и является требованием для Apples App Store.

Прототип dart:ffi продвинулся до точки, когда мы принимаем решения по API. (Некоторые дизайнерские решения обсуждаются здесь .)

Чтобы принимать обоснованные дизайнерские решения, нам нужно больше примеров того, какие API-интерфейсы C вы хотите связать. Пока что в этом выпуске упоминаются SQLite, Realm, OpenCV, Superpowered и ffmpeg. Какие еще API нам следует рассмотреть?

@dcharkes Я не знаю, помогает ли это, но Telegram в Android поддерживает работу с C ++ через JNI:
https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/jni/TgNetWrapper.cpp
Он также обрабатывает воспроизведение GIF с помощью ffmpeg, напрямую записывая на растровые изображения Android:
https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/jni/gifvideo.cpp

Было бы интересно найти способ парсить телефоны и адреса с помощью libpostal для регистрационных форм. Также glfw + flutter-embedder и, возможно, однажды мы увидим настольное приложение, полностью написанное на dart.

+1 для SQLite и Realm. Также посмотрите Couchbase , у них есть общее ядро ​​C ++ с C SDK.

Будет ли интересен API Firebase C ++? https://firebase.google.com/docs/reference/cpp/

Не очень разбирался в этом, но думал, что, возможно, удастся заменить плагины iOS и Android одним плагином, который напрямую общается с C ++.

Некоторым крипто-библиотекам стоит полюбить кольцо из ржавчины - https://github.com/briansmith/ring

+1 для OpenCV, Realm, SqlCipher (https://github.com/sqlcipher/sqlcipher)

библиотеки криптографии. В частности libsodium или tink.

https://github.com/google/tink

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

Уже есть библиотека flutter -odium, она общается по каналам платформы с оболочками libsodium на каждой платформе, а затем с нативной.

Пользовательские библиотеки сопоставления, такие как mapbox-gl https://github.com/mapbox/mapbox-gl-native

Обработка SMTP / IMAP (для чата по электронной почте) для Flutter через https://github.com/deltachat/deltachat-core - это то, что я хотел бы использовать напрямую.

Если я позволю себе смелость перефразировать, распространенные варианты использования приведены ниже:

1. Аппаратный доступ к аудио / видео с низкой задержкой (например, сверхмощный)
2. Аппаратная обработка аудио / видео (например, ffmpeg)
3. Доступ к сокетам на основе TCP, для XMPP / других сетевых протоколов
   (для чата push-уведомления)
4. Обновление уровня процесса (корневой доступ) / порождение потоков в
   кроссплатформенная совместимость (для системных приложений, многозадачности, эмуляторов)

Могут быть и другие варианты использования, но это основные из них.
разум.

Спасибо всем за примеры! Это очень полезно.

@ skills-up обратите внимание, что нас гораздо больше интересуют конкретные примеры, а не абстрактная классификация. Это потому, что мы хотим оценить эргономику FFI на конкретных примерах.

Как ни странно, одним из языков, который предлагает лучший интерфейс с / на C ++, является Rust с его мощной системой макросов + сборки, несмотря на совершенно иной подход к объектно-ориентированному программированию.

Я бы сказал OpenSSL, поскольку нам нужно подписывать запросы мыла и файлы xml (XMLDSig, Xades l) цифровой подписью с использованием клиентских сертификатов.
Сам Dart имеет BoringSSL, но только его часть доступна через Dart. Итак, следующая лучшая вещь - это вызов собственных библиотек openssl из flutter

Надеюсь, я не рассылаю спам, но я также хотел бы иметь лучшую интеграцию с tenorflow lite, а не через JNI, что было бы отлично для операций с видео.

Не очень разбирался в этом, но думал, что, возможно, удастся заменить плагины iOS и Android> одним плагином, который напрямую общается с C ++.

Помимо поддержки C ++, будет здорово, если есть плагин, который может напрямую общаться с Go. Прямо сейчас мы говорим о Go через каналы платформы gomobile и flutter, что замедляет отзывчивость пользовательского интерфейса. Наличие встроенной поддержки Go и C ++ во Flutter также поможет нам поддерживать единую кодовую базу (бизнес-логику / алгоритм) для нескольких платформ.

+1 для доступа к родной библиотеке.

Я хотел бы получить доступ к Vulkan / MoltenVK без необходимости создавать каналы платформы для Android / iOS и поддерживать два плагина (которые тоже были бы огромными). Это позволило бы создавать 3D-приложения и выполнять рендеринг в виджетах «Текстура» при разработке только в Dart. Каналы платформы кажутся хакерским обходным решением. Я бы предпочел получить доступ к собственным библиотекам без необходимости писать оболочку для каждой платформы и поддерживать их всякий раз, когда для этой библиотеки появляется новая версия.
Я думаю, эта функция привлечет гораздо больше разработчиков.

Да, пожалуйста, прямой доступ к родной библиотеке из флаттера.
Я хотел бы использовать некоторую библиотеку c ++ во флаттере.

Да, пожалуйста, прямой доступ к родной библиотеке из флаттера.
Я хотел бы использовать некоторую библиотеку c ++ во флаттере.

Сейчас мы подошли к тому моменту, когда мы хотели бы предложить предварительный просмотр, чтобы получить отзывы.

Для получения дополнительных сведений см. Обновление в статье об

@ mit-mit Поможет ли это решить эту проблему: могу ли я вызвать или использовать библиотеку python с флаттером ?

Поздно на вечеринку, но +1 за SQLCipher @dcharkes @mraleph

@ doc-rj, сейчас мы находимся на стадии, когда вы сможете поэкспериментировать с привязкой SQLCipher и поделиться с нами своими впечатлениями. См. Этот комментарий .

Я хотел бы подчеркнуть, что мы на самом деле не стремимся предоставлять какие-либо конкретные привязки библиотек сами - потому что запросы чрезвычайно разнообразны, но мы стремимся сделать возможным привязку к любой библиотеке с помощью C API для всех и каждого.

Я предполагаю, что потребность в этом возрастает сейчас, когда было объявлено о мультиплатформенности.

Это часть какой-либо дорожной карты?

@felemedeiros, работа продолжается - если у вас есть библиотека, к которой вы хотите привязать с помощью FFI, я настоятельно рекомендую начать работу над привязками, чтобы предоставить нам обратную связь. См. Этот комментарий для информации.

Не очень разбирался в этом, но думал, что, возможно, удастся заменить плагины iOS и Android> одним плагином, который напрямую общается с C ++.

Помимо поддержки C ++, будет здорово, если есть плагин, который может напрямую общаться с Go. Прямо сейчас мы говорим о Go через каналы платформы gomobile и flutter, что замедляет отзывчивость пользовательского интерфейса. Наличие встроенной поддержки Go и C ++ во Flutter также поможет нам поддерживать единую кодовую базу (бизнес-логику / алгоритм) для нескольких платформ.

Я написал статью о том, как мы сейчас вызываем API библиотеки Go из Flutter. Это может быть полезно для кого-то интересующегося. https://medium.com/@archan.paul/using -go-library-in-flutter-a04e3496aa05

Как я могу добавить код c ++ в приложение Flutter?

Как я могу добавить код c ++ в приложение Flutter?

Я думаю, что сейчас единственный вариант - использовать C ++ -> JNI (для Android) -> PlatformChannel, пока у нас не будет более элегантного способа сделать то же самое !!

Я создал проект под названием ezored (http://ezored.com). Было бы неплохо, если бы я мог передавать сложные объекты во Flutter без необходимости конвертировать в другие вещи, поскольку они уже находятся в java и objc. Любой желающий может использовать ezored для создания SDK (или загрузить готовую версию), чтобы протестировать интеграцию Flutter между нативной версией и Dart. В нем есть запросы, синтаксический анализ, использование базы данных и многое другое в демонстрационном SDK, уже реализованном.

Я ищу в группах флаттера, но у меня нет возможности напрямую передать объекты и список объектов во Flutter.

Спасибо за любую помощь.

Есть новый прогресс? Кажется, прошло больше 2,5 лет ...

@fzyzcjy, мы над этим работаем. Мы выпустили предварительную версию. См. Https://github.com/dart-lang/sdk/issues/34452#issuecomment -482136759 о том, как принять участие.

Начиная с этой ранней предварительной версии, мы добавили поддержку Intel 32, Arm 64 и Arm 32. Эти платформы еще не выпущены в стабильной версии или для разработки, они доступны только в основной ветке Dart sdk. Здесь отслеживается прогресс.

@dcharkes Так рада это слышать! Спасибо за вашу большую работу!

Какой-либо прогресс?

Обновления статуса и дополнительную информацию можно найти на странице https://github.com/dart-lang/sdk/issues/34452. Самый верхний комментарий содержит самое последнее обновление.

При использовании flutter для создания веб-приложения возможно ли использование ffi с библиотекой ac?

При использовании flutter для создания веб-приложения возможно ли использование ffi с библиотекой ac?

Это маловероятно. Теоретически в долгосрочной перспективе это может поддерживаться с помощью WebAssembly, но в настоящее время мы не над этим работаем.

@ с-с действительно？

При использовании flutter для создания веб-приложения возможно ли использование ffi с библиотекой ac?

Это маловероятно. Теоретически в долгосрочной перспективе это может поддерживаться с помощью WebAssembly, но в настоящее время мы не над этим работаем.

Зачем нужен WebAssembly? Если вы можете попросить людей перестроиться на WebAssembly в будущем, вы можете попросить их перестроиться на ASM.js сейчас.

@ nic-hartley Это хорошая идея, но проблема не в том, как скомпилировать собственный код, а в создании моста между Dart (скомпилированным как JS) и собственным кодом, какую бы форму он ни принял.

Собственный FFI очень низкоуровневый по соображениям производительности и не может быть легко переведен в asm.js или WebAssembly.

Чтобы уточнить, я имею в виду, что наша реализация очень низкоуровневая - это, безусловно, интересная функция, но для ее реализации потребуется значительная работа.

флаттер - это всего лишь игрушка, пока он не поддерживает c ++

Я пришел сюда, чтобы повторить то же самое, что и другие: до тех пор, пока Flutter не сможет легко взаимодействовать с C ++ (без библиотеки моста и без потери производительности), он никогда не будет принят крупномасштабными приложениями с инвестициями в существующие собственные библиотеки или приложения. где производительность является наивысшим приоритетом.

Я отмечу, что даже React Native в настоящее время использует мост, поэтому похоже, что Flutter на самом деле опережает все попытки реализовать FFI.

Интеграция с C ++ в iOS с AppKit проста. Это то, с чем мы должны сравнивать, а не с React Native.

UWP и C ++ тоже тривиальны.

Я в целом тоже за партию "поддержи усилия Dart FFI" ...

Xamarin может быть более подходящим сравнением, чем UWP, но кроссплатформенные представления Xamarin не были настолько настраиваемыми, как Flutter, и часто требовали большого количества нативного кода, чтобы выглядеть достойно.

Это неправда. В отличие от Flutter, Xamarin имеет привязку платформы к собственному API (например, Xamarin.iOS и Xamarin.Android), и разработчикам приложений легко написать реализацию для конкретной платформы на своем собственном языке (C # /. NET). Эта проблема связана с особенностями языка и не должна смешиваться с дизайном API виджетов пользовательского интерфейса.

Существует много использования собственных API , но нет вызова собственного кода, где Flutter был бы на той же лодке (хотя Xamarin не требует написания Java или ObjC там, без взлома отражения в коде приложения). Для нативного кода , даже в самом Xamarin.Android (одном из бэкэндов серверной платформы) нативный код используется очень мало, а разработчики приложений не пишут нативный код.

И в отличие от React Native или Xamarin, Flutter предоставляет полную структуру, поэтому вполне справедливо сравнивать всю структуру Flutter с такими вещами, как AppKit.

странно, что никто даже не упоминает фреймворк Qt, который намного опережает все остальное в части интеграции с C ++

QT - это C ++. И изначально имеет неблагоприятную лицензию.

В пн, 12 авг 2019, 06:41 Владислав Стельмаховский, <
[email protected]> написал:

странно, что никто даже не упоминает фреймворк Qt, который далеко впереди
все остальное, что касается интеграции с C ++

-
Вы получаете это, потому что подписаны на эту беседу.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/flutter/flutter/issues/7053?email_source=notifications&email_token=AGDYMWXHTJUBUW64LEOO27TQEDSWNA5CNFSM4CXY6LYKYY3PNVWWK3TUL52HS4DFVREXG63LVMVBOD5
или отключить поток
https://github.com/notifications/unsubscribe-auth/AGDYMWTNMTM7QUOY2BEIPM3QEDSWNANCNFSM4CXY6LYA
.

Qt - это C ++ и QML (движок JS)
Какая лицензия? LGPL? GPL? что с этим не так?

Во-первых, IANAL, но, насколько я понимаю, большая часть Qt - это LGPL (IDE и т. Д. - GPL), что означает, что в нем есть язык, который, хотя и не запрещает явно статическое связывание, затрудняет выполнение при соблюдении лицензии, если ваше приложение с закрытым исходным кодом.

Технически, если вы используете только LGPL и предоставляете свои объектные файлы (и, возможно, инструкции), чтобы пользователи могли повторно ссылаться на другую версию библиотеки, вы удовлетворяете требованиям LGPL. Но я почти уверен, что компания Qt не афиширует этот факт, поэтому общая концепция заключается в том, что вы не можете развернуть статические библиотеки, что означает, что вы не можете выпустить свое приложение в магазине приложений, не уплатив их грабительские лицензионные сборы. И я могу ошибаться, предоставляя объектные файлы, это просто мое понимание этого, и я не знаю, делают ли это какие-либо компании.

Android проще, потому что он позволяет динамически загружать библиотеки, которые более явно разрешены в LGPL, но, честно говоря, статическое связывание, вероятно, было бы предпочтительнее и там, чтобы уменьшить размер приложения, что означает столкновение с той же проблемой.

Привет @cpboyd , мне кажется, я смотрю на это с противоположной стороны. У нас уже есть приложения, построенные на конкретных платформах пользовательского интерфейса, где каждая платформа позволяет нам использовать нашу обширную коллекцию существующих библиотек C ++. Я понимаю, что Flutter кроссплатформенный, и это здорово, но если я действительно не смогу его использовать (с моим существующим кодом), мне лучше просто придерживаться некросс-платформенного пользовательского интерфейса. Единственный камень преткновения возникает, когда будущая ОС (например, Fuchsia) требует использования Flutter & Dart, но не допускает этого варианта использования. В этом случае он, вероятно, будет проигнорирован кем-либо, у кого есть большая кодовая база.

Полагаю, я не уверен, разрабатываются ли Flutter / Dart с учетом «веб-приложений» (т.е. там, где серверные части находятся в сети), или серьезно учитываются потребности профессиональных разработчиков настольных приложений. В конечном итоге подобные решения могут повлиять на количество и качество многих приложений в магазине приложений. Если я могу написать высококачественное профессиональное приложение для iOS с помощью UIKit, используя миллионы строк существующего кода, но я не могу (с почти нулевой стоимостью производительности), если я разрабатываю для Fuchsia / Flutter / Dart, тогда это будет быть ОС и платформой, для которой я бы не стал разрабатывать.

Целью моих сообщений является не сравнение Flutter с другими кроссплатформенными или некросс-платформенными библиотеками, а выявление вариантов использования, которые важны для некоторой части разработчиков.

Dart FFI интересен тем, что из очень_ краткого прочтения примера sqllite он похож на C # с PInvoke, но, к сожалению, он не подходит для C ++, поскольку либо почти каждый тип, с которым вы имеете дело, потребует упаковки, либо вам придется написать некоторая полностью универсальная безтиповая интерфейсная система для оболочки C ++. Ни один из них не выглядит особенно привлекательным, если сравнить его с простотой следующего класса Obj-C:

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

Или UWP с C ++ / WinRT:

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

Спасибо :-)

@Hixie @MarkIngramUK Ни один из них не является кроссплатформенным, на что я и
AppKit предназначен только для Apple, а UWP - только для Windows.
Возможно, если бы Flutter использовал Swift или C # вместо Dart, то у нас уже был бы такой же уровень поддержки, но это совершенно другой аргумент.
Xamarin может быть более подходящим сравнением, чем UWP, но кроссплатформенные представления Xamarin не были настолько настраиваемыми, как Flutter, и часто требовали большого количества нативного кода, чтобы выглядеть достойно.
Мое предложение все еще остается в силе: если вы хотите использовать Flutter с C ++, вам следует принять участие в предварительном просмотре FFI команды Dart и помочь улучшить поддержку для всех нас 😃

Эта проблема связана с особенностями языка и не должна смешиваться с дизайном API виджетов пользовательского интерфейса.

@atsushieno Конечно, и поэтому это обсуждение было бы более продуктивным на форуме Dart FFI ... Flutter - это фреймворк. Дротик - это язык.

Ни один из них не выглядит особенно привлекательным, если сравнить его с простотой следующего класса Obj-C:

@MarkIngramUK Я уверен, что это именно тот отзыв, который команда Dart хотела бы увидеть на https://groups.google.com/forum/#!forum/dart -ffi

У меня есть проект под названием ezored (https://ezored.com), который представляет собой проект начальной загрузки C ++ для SDK и приложений на C ++. Используем в мобильных проектах (android и iOS). Я жду завершения FFI, чтобы создать проект, который будет использовать SDK по умолчанию для flutter.

У нас нет проблем с C ++, и время разработки новых функций сокращается, поскольку SDK имеет один и тот же код для всех платформ, как вы можете видеть в реализации по умолчанию (проект poco, openssl, sqlite, интегрированный код конкретной платформы с кодом моста и т. д.).

В моем варианте это лучший способ:

• iOS и Android с бэкэндом C ++ (ezored)
• Flutter и C ++ как бэкэнд

Смело добавляйте старт проекту :)

Kotlin Multiplatform может быть обходным решением, а не идеальной мыслью. Еще нужно дождаться https://github.com/dart-lang/sdk/issues/34452

Похоже, что Unity3d каким-то образом переносит флаттер на свой движок, основанный на C # VM [1] - в этом мире разговоры между C # и C ++ вполне приличны. Возможно, стоит взглянуть на их репо, как они решили некоторые проблемы. Они заявляют: «UIWidgets в основном унаследован от Flutter». Я также хотел бы взглянуть на реагирующий родной лагерь и их новый подход с TurboModules - их решение может иметь преимущество перед подходом флаттера, поскольку будет
1) как синхронный, так и асинхронный и
2) не будет маршаллинга и
3) будет поддерживать не только C, но и C ++

Я болею за оба лагеря.

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

Начиная с Dart 2.5, это ( dart:ffi ) теперь находится в предварительной версии:
https://medium.com/dartlang/announcing-dart-2-5-super-charged-development-328822024970

Отличные новости!

Ммм ... Достаточно ли будет использовать гобой с Flutter? ..

https://github.com/google/oboe

@ rg4real Ага! Но вам нужно будет написать несколько оболочек C, поскольку интерфейс Oboe находится на C ++.

Вы можете увидеть https://github.com/flutter/flutter/wiki/Binding-to-native-code-via-FFI для инструкций по началу работы.

Вы можете повторно использовать мои oboe-c.so которые я написал для своих привязок C #, если это работает https://github.com/atsushieno/oboe-sharp/tree/master/native

@ sjindel-google, отличные новости!

Поэтому мне нужно создать мост между кодом C ++ и C, создав классы и функции. А затем я могу использовать эти классы и вызывать эту функцию из кода Dart. Думаю, это правильно.

@atsushieno , спасибо. Я смотрю. Не знаю, как наводить мосты в моем случае (отсутствие опыта). Но удалось ли вам достичь своей общей цели - точной игры на гобое? Это было так хорошо?

@ rg4real Я делал это просто для более простого API (по сравнению с OpenSLES), чем аудио с низкой задержкой. Если бы я серьезно относился к задержкам, я бы не стал использовать Xamarin.Android. Если вы говорите о гобое (или стоящем за ним AAudio), то я использую его в Fluidsynth, и он хорошо работает. Не уверен, насколько хорош AAudio по сравнению с OpenSLES.

Есть ли руководство по управлению памятью?

Если код C ++ создает память с помощью new / malloc и возвращается к коду dart, как освободить эту память.

код c ++
void foo (char ** out) {
* out = новый символ [25];
}

Как удалить память, назначенную | out | переменная из кода дротика?

Если вы используете Dart 2.5, на Pointer есть .free() Pointer . Если вы находитесь в ветке dev / master, этот метод переместил package:ffi https://github.com/dart-lang/ffi/blob/master/lib/src/allocation.dart#L70.

Согласно комментарию - «Его можно использовать только против указателей, выделенных способом, эквивалентным [allocate]». - free () можно использовать только в том случае, если память выделяется с помощью метода allocate ().

например
ffi.Pointerptr = ffi.Pointer.allocate ();
ptr.free ();

Это позаботится об освобождении памяти, которая выделяется на стороне C ++ с использованием либо new, либо malloc из кода dart?

Пока память была выделена через malloc , либо через Dart, либо через C ++, ее можно освободить с помощью free .

В Dart 2.6 мы используем DynamicLibrary.lookupFunction("free") для определения free в Dart, поэтому он будет точно таким же free что и в части программы на C ++. (Если вы не связываете несколько версий free в свой двоичный файл.)

Закрытие этой проблемы, поскольку эта функция теперь общедоступна (в бета-версии) во всех каналах Flutter. Мы продолжаем исправлять проблему. Если у вас возникли подробные проблемы, пожалуйста, сообщите о них на странице https://github.com/dart-lang/sdk/issues/new.

делать классы c ++ для совместимости с c беспорядочно. Пожалуйста, создайте возможность напрямую вызывать классы c ++

+1 Может у нас будет поддержка C ++?

@KaungZawHtet и @fzyzcjy - пожалуйста, подумайте об открытии нового выпуска (возможно, на dart-lang, а не на flutter).

Я собираюсь заблокировать эту проблему - на нее подписалось много людей, но ее первоначальная цель довольно четко решена.

Да, о новых проблемах отправляйте по этой ссылке: https://github.com/dart-lang/sdk/issues/new?labels=library-ffi , area-vm