Flutter: 플러그인 프레임워크에서 C/C++와 통합 지원

@jason-simmons는 Gradle에 대해 가장 잘 알고 있습니다. .so가 있으면 로드하는 데 도움이 될 수 있습니다.

buildSrc 아래에 gradle 빌드 버전을 설정하는 또 다른 속성이 있음을 발견했습니다. 2.2.2로 업데이트한 후 진행했고 .so 로드를 확인할 수 있었고 Java에서 호출할 수 있습니다.

아마도 우리는 C/C++ 코드에서 Dart로 HostMessage를 보내기 위한 C API를 추가해야 할 것입니다.

예, 부탁합니다. C->Java 콜백이 저렴하지 않을 수 있다는 의심이 듭니다.

이에 대한 업데이트가 있습니까? 공유 라이브러리로 컴파일된 C++ 코드를 호출하는 크로스 플랫폼 앱을 구축하기 위해 Flutter를 고려하고 있으며 이것이 유일한 주요 중지 지점입니다.

이것은 오늘날 가능하지만( @jtrunick 은 그의 배송 앱에서 그렇게 했습니다), 먼저 Java 또는 Obj-C를 통해 반송해야 합니다.

즉, https://flutter.io/platform-channels/ 를 사용하여 Dart에서 Obj-C/Java로 통신한 다음 Obj-C/Java에서 C++ 코드로 호출할 수 있습니다. 이 버그는 이에 대한 직접적인 지원을 추가하고 잠재적으로 Obj-C/Java 통과를 피하는 것을 다룹니다.

Dart VM은 C++로 구현되었으므로 C 공유 라이브러리를 직접 호출하는 더 쉬운(안전하지 않더라도) 방법이 없어야 합니까(예: dlopen을 통해)? 기본(안전하지 않은/실험적인) 지원을 위해 얼마나 많은 변경이 필요합니까?

Android 또는 ios에서 https://www.dartlang.org/articles/dart-vm/native-extensions를 사용할 수 있습니까?

몇 가지 Google 앱에서 이 요구사항을 들었습니다.

• 이러한 앱 중 하나는 대기 시간을 줄이기 위해 카메라를 작동하기 위한 자체 C++ 라이브러리를 작성했습니다. 이러한 라이브러리는 플랫폼에 따라 다르며 최대한 빨리 작동하도록 최적화되어 있습니다. 가능한 가장 짧은 대기 시간으로 이러한 라이브러리를 호출하는 것은 이러한 앱에 중요합니다. 강제로 PlatformChannel + JNI를 통과하도록 하면 Android에서 이를 달성할 수 없습니다.

• Android와 iOS 구현 간에 공유할 수 있도록 C++로 비즈니스 논리 구성 요소를 작성하는 고급 모바일 팀이 있습니다. 이러한 라이브러리와의 직접 통합을 지원하는 Flutter는 최고의 크로스 플랫폼 프레임워크라는 입지를 더욱 공고히 할 것입니다.

나는 이것이 _필수품이라고 생각하지 않습니다. 그러나 이것은 Flutter가 다른 크로스 플랫폼 솔루션과 더욱 차별화할 수 있는 영역 중 하나입니다.

이러한 앱 중 하나는 대기 시간을 줄이기 위해 카메라를 작동하기 위한 자체 C++ 라이브러리를 작성했습니다. [...] 강제로 PlatformChannel + JNI를 통과하도록 하면 Android에서 이를 달성할 수 없습니다.

C++에서 Java로 또는 그 반대로 전환하기 위한 Android의 솔루션은 무엇이었습니까?

정말 필요한 경우 모바일 플랫폼에서 Dart 기본 확장을 허용할 수 있습니다. 지금은 dart_api.h 의 기호를 노출하지 않습니다. 스위치를 전환하기 전에 다음을 결정해야 합니다.

• AOT 컴파일러가 기본 Flutter 엔진 동적 라이브러리에 없을 수도 있는 메서드에서 오는 유일한 진입점인 Dart 코드를 인식하도록 하는 방법을 알아보세요. 그렇지 않으면 트리 쉐이킹 패스가 코드를 제거할 수 있습니다.
• 기본 확장(Android 및 iOS용 각각 Gradle 및 Xcode) 빌드 및 패키징에 대한 지침을 제공합니다.
• dart_api.h 의 루틴에 대해 일부 ABI 안정성 보장을 제공합니다. 대부분 안정적이지만 다양한 모드를 설명하기 위해 여전히 진화하고 있다고 생각합니다.

지금까지는 플랫폼 채널 메커니즘이 더 간단한 사용 사례에 적합했던 것 같습니다.

C++에서 Java로 또는 그 반대로 전환하기 위한 Android의 솔루션은 무엇이었습니까?

나는 그들의 사용 사례를 깊이 들여다보지 않았습니다. C++에서 대기 시간이 매우 짧은 통신이 필요한 모든 비트를 작성한 것 같습니다. 성능이 중요한 사용 사례에 JNI를 사용하는지 묻습니다(내 직감은 아니오).

Flutter 측에서 무엇을 할 수 있는지에 달려 있습니다. JNI보다 훨씬 빠른 interop을 제공할 수 있다면 이 팀에게 큰 승리가 될 것입니다. 그들은 C++ 코드베이스를 축소하고 앱 측으로 더 많이 이동할 수 있습니다. Interop 성능이 JNI와 비슷하다면 여기서 큰 승리를 볼 수 없습니다. 그들은 아마도 지금 하고 있는 일을 계속하고 PlatformChannel을 사용할 수 있습니다.

이는 이러한 팀이 Flutter로 전환할 추가 이유를 제공하기 위한 것입니다. 이것이 차단이라는 말을 들어 본 적이 없으므로 그에 따라 우선 순위를 지정하십시오.

당신이 말하는 것을 올바르게 이해한다면 현재 솔루션은 Java의 최소한의 논리로 C++의 모든 논리(카메라+UI)를 갖는 것이며 이 논리의 UI 부분을 Dart로 옮기고자 한다는 것입니다. 대기 시간이 짧은 UI<->카메라 상호 작용을 잃지 않고.

그들의 스레딩 상황에 대해 이야기할 수 있습니까? 카메라+UI용 스레드가 하나만 있습니까?

@chinmaygarde 는 갈 수 있습니다.

+1

이 문제에 진전이 있습니까?

우리는 이미 djinni 를 사용하여 다양한 플랫폼에서 로직을 공유하고 있습니다. Java/Objc-C를 통해 왔다 갔다 하는 것보다 Dart와 C++ 사이에 상호 운용성을 가질 수 있다면 좋을 것입니다.

Dart가 C/C++와 통합될 수 있다면 모바일에서 수많은 네이티브 라이브러리를 재사용하고 JNI 또는 Objective C++를 사용하여 특정 플랫폼에 바인딩할 필요가 없는 것이 좋은 아이디어라고 생각합니다.

https://github.com/mono/CppSharp 를 고려해 보셨습니까

Realm과 같은 C++ 기반 데이터베이스를 C++에 직접 통합하면 상당한 성능과 개발자 생산성 향상을 달성할 수 있습니다 :-) JNI를 통해 위/아래로 이동하는 것은 낭비입니다.

저는 컴퓨터 비전(아마도 OpenCV 사용)을 수행하는 AR 앱용 Flutter를 고려하고 있으며 효율적이고 직접적인 Dart-C++ 상호 운용성이 주요 긍정적인 포인트가 될 것입니다. 계산 측면에서 까다로운 앱을 수행하는 다른 많은 사람들이 이러한 요구 사항을 공유할 수 있다고 생각합니다.

C++ interop을 여전히 사용할 수 없다는 것을 누군가 확인할 수 있습니까? 패키지를 사용하여 수행할 수 있습니까?

@tofutim Direct c/c++ interop은 여전히 ​​사용할 수 없으므로 이 문제가 여전히 열려 있습니다. 그러나 플랫폼 채널 을 사용한 다음 Obj-C/Java를 사용하여 C++ 코드와 상호 작용할 수 있습니다. 위대하지는 않지만 현재 우리가 가진 전부입니다.

C++ interop을 여전히 사용할 수 없다는 것을 누군가 확인할 수 있습니까? 패키지를 사용하여 수행할 수 있습니까?

플랫폼 라이브러리와 상호 운용하기 위해 플랫폼 채널 메커니즘은 여전히 ​​현재 권장 사항입니다.

기본 확장 문서에 설명된 보다 성능이 뛰어난 메커니즘을 간단하게 추가할 수 있습니다. 그러나 dart_api.h 에서 노출된 기호에 대한 ABI 안정성 보장에 대해 @eseidelGoogle 이 그러한 보장이 존재함을 확인할 수 있다면, 나는 최대한 빨리 해당 기호를 노출하기 시작할 수 있습니다. 선택적으로 C++에서 사용하기 쉽도록 C API 주변의 편리한 래퍼로 Tonic 의 하위 집합을 만들 수 있습니다.

내 이해는 이 버그가 C-API 및 도구 후크를 제공하여 완전히 C/C++ 플러그인을 쉽게 가질 수 있도록 한다는 것입니다(Obj-C/Java shimming이 필요하지 않지만 여전히 platform_channels을 통해 비동기화됨).

현재로서는 네이티브 확장과 같은 동기 메서드를 고려해야 한다고 생각하지 않습니다. (그러나 솔직히 나는 그것을 @Hixie 또는 @cbracken으로 연기합니다).

@seidel

현재로서는 네이티브 확장과 같은 동기 메서드를 고려해야 한다고 생각하지 않습니다.

왜 그런 겁니까?

C 코드를 호출하는 현재 접근 방식은 Dart -> Java -> C
우리는 JNI를 두 번 교차합니다.
처음: 플랫폼 채널을 통해 dart 에서 Java 로(후드에서 JNI 호출 사용, 맞죠?)
두 번째: Java -> JNI 를 통한 C

예를 들어, 내 프로젝트의 요구 사항의 관점에서 안정성 보장 없이도 dart_api.h 액세스할 수 있으면(예: 실험 기능으로) 이미 충분할 것입니다. 내 주요 관심사는 마샬링 및 이상적으로는 복사하지 않고 Dart 쪽에서 C 쪽으로 큰 이진 데이터(이미지) 덩어리를 이동하는 것입니다. Unity/Mono 는 이를 달성합니다 .

dart-sdk 문제 31960 에서 현재 격리 구현이 복사 없이 데이터를 전달하는 것을 허용하지 않을 수 있음을 이해합니다(이론적으로는 격리 A에서 생성된 버퍼가 격리 B에 전달된 후 더 이상 사용되지 않음을 감지할 수 있어야 하지만 따라서 해당 소유권은 복사하지 않고 양도될 수 있습니다. 그 전면에 대한 계획이 없습니까?), 그러나 적어도 격리 내에서 C 로/에서 마샬링이 없다면 좋을 것입니다.

곧 도착할 것으로 보이는 플랫 버퍼로 마샬링을 피할 수 있습니다. https://github.com/google/flatbuffers/pull/4676
또는 단일 바이트 전용 필드를 사용하는 protobuf 메시지와 함께.

물론 이것은 많은 양의 바이트 복사를 수반하므로 모든 사용 사례에 적합하지 않습니다.

나는 여기에 제시된 적어도 세 가지 다른 욕망을 듣고 있습니다.

1. Java/Obj-C 글루를 추가할 필요 없이 C/C++ 코드만 사용하여 Flutter용 플러그인을 쉽게 작성할 수 있는 방법을 원합니다(이것이 이 버그에 대한 저의 원래 이해였으며 확실히 할 수/해야 한다고 생각하는 것입니다) .
2. 대용량 데이터를 Dart 안팎으로 빠르게/낮은 대기 시간으로 이동하는 방법을 원합니다. (아마도 C++를 포함한 다양한 언어에서 온 것 같습니다. 이것은 매우 타당한 경우처럼 들립니다! 예제를 포함하여 별도의 버그를 제출하는 것이 좋습니다.)
3. 동기 호출/객체로 Dart를 확장하는 방법을 원하십니까? (예: 기본 확장 또는 기타 방법? 이 또한 완전히 가능합니다. API 안정성과 관련하여 잠재적인 어려움이 있으며 조치를 취하기 전에 특정 사용 사례에 대해 더 자세히 알고 싶습니다.)

위의 내용을 읽은 후 피드백은 몇 가지 추가 버그를 분리하는 것을 고려해야 한다는 것입니다. 확실히 C++ inter-op에 약간의 투자가 필요하지만 이 긴 스레드에서 어떤 정확한 사용 사례를 어떤 순서로 처리해야 하는지 결정하기가 어렵습니다.

이해 관계자가 원하는 사용 사례와 함께 새로운 버그를 신고하고 여기에 다시 연결할 수 있습니까? 이 문제 영역에 대한 일반적인 관심을 추적하기 위해 이 문제를 열어 두게 되어 기쁩니다.

성능과 관련하여 2. 위: Flutter의 platform_channels 성능이 향상될 수 있다고 확신하지만(모든 사용 사례를 다루기 위해 다른 플러그인/상호 운용 방법이 필요할 가능성이 있음) 우리는 몇 가지 구체적인 사항을 원할 것입니다. Flutter의 platform_channels 성능이 조치를 취하기 전에 병목 현상이 발생하는 사용 사례(아마도 존재하지만 내가 본 적이 없을까요?). 시스템 성능 최적화에 대한 나의 경험은 내 직감이 종종 잘못되었다는 것입니다. JNI 또는 platform_channels와 같은 것들이 잠재적인 병목 현상처럼 느껴지지만 측정할 때까지는 실제로 알 수 없습니다.

도움과 피드백을 주신 모든 분들께 다시 한 번 감사드립니다!

Java/Obj-C 글루를 추가할 필요 없이 C/C++ 코드만 사용하여 Flutter용 플러그인을 쉽게 작성할 수 있는 방법을 원합니다(이것이 이 버그에 대한 저의 원래 이해였으며 확실히 할 수/해야 한다고 생각하는 것입니다) .

그것은 또한 플러터를 위한 더 나은 sqlite 통합을 제공할 것입니다 + 크립토, ssh 및 기타 항목을 위한 수많은 C/Rust 라이브러리가 있습니다. 간편하게 사용할 수 있어서 좋더라고요.

@seidel

나는 적어도 세 가지 다른 욕망이 제시되는 것을 듣고 있습니다.

내 투표 1.)

Flutter 문서를 읽으면 C를 지원하도록 플랫폼 채널을 확장하는 것이 상당히 "간단"해야 합니다.
유일한 새로운 것은 아마도 현재 프로세스에 _동적 공유 객체_를 로드하는 방법일 것입니다.

_Android-C_-usage가 다음과 같을 것이라고 상상할 수 있습니다.

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

MethodChannel* flutter_channels;

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

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

#define str(a) #a

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

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

개념적으로 최소한 _Android-C_의 경우 Java와 C의 조합을 처리하는 방법을 결정해야 합니다.

@eseidelGoogle
우리는 현재 자바와 스위프트 래퍼를 통해 golang 코드를 공개하고 있으며 대기 시간은 우리가 겪고 있는 상당한 문제입니다.
왜요 ?

• 우리는 많은 플랫폼 간에 비즈니스 로직을 공유해야 합니다.
• 화면 공유와 같은 비디오 및 이미지 기능용.
• DB용.

포옹 차이를 만들 것입니다 직접적인 수준에서 golang 지원을 추가할 수 있다면!
모바일용 golang 코드 컴파일도 LDFLag 마법 없이 매우 쉬워서 인기가 있을 것 같아요. 현재 Method Channels도 사용하고 있는 몇 가지 다른 golang 코더를 알고 있습니다.
직렬화에 관해서는 현재 Protobufs와 플랫 버퍼를 사용합니다.

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

자홍색에서 이것은 FIDL로 수행되며 c, rust 및 golang에 대한 바인딩이 있습니다.
사용하기에 꽤 훌륭하고 임베디드 보드에서 녹과 golang을 시험해 보는 것을 즐겼습니다.

iOS 및 Java를 통해 fidl 항목을 노출하는 것도 가능해야 합니다.
그것은 모바일과 데스크탑에서 자홍색과 플러터 사이에 좋은 진입로를 줄 것입니다.
내가 가지고 노는 생각

@eseidelGoogle
Hiix는 FIDL이 Fuchsia에 있는 zircon의 커널 코드에 의존하기 때문에 Flutter 수준에서 FIDL을 수행할 수 없다고 말했습니다. 따라서 Flutter 내에서 FIDL IPC 스타일 기능을 복제하는 유일한 방법은 Flutter 엔진에 FIDL 버전을 작성하는 것입니다. 그러나 나는 그것을 가지고 놀다가 Flatbuffers와 매우 유사하다는 것을 알아차렸습니다. 그렇다면 Flutter와 cpp 사이의 직렬화 레이어에 FlatBuffers를 사용하거나 Flutter의 golang 또는 rust 레이어를 사용하지 않는 이유는 무엇입니까? ?

이것에 +1하면 Superpowered라는 라이브러리를 사용하는 flutter 앱이 있습니다. Superpowered는 C++로 작성되었으며 Java 및 JNI 유형 항목을 사용하여 상호 작용하고 플랫폼 채널을 사용하여 Java 코드와 대화합니다. 우리가 중간 사람을 건너뛸 수 있다면 확실히 좋을 것입니다.

이것은 또한 Realm과 같은 인기 있는 모바일 라이브러리의 핵심이 C/C++로 작성되고 java/objc/swift 중개자를 다루기를 원하지 않기 때문에 플러터 버전을 만드는 것을 방해합니다.

이러한 이유로 일반적인 안정성을 제외하고 이 문제는 현재 Flutter에서 가장 필요한 변경 사항 중 하나라고 생각합니다. (더 구체적으로 @eseidelGoogle 의 목록에서 1위입니다.)

플랫폼 확장에서 Java/JNI를 우회하는 것에 대한 주장을 듣고 싶다면(즉, 개발자를 위한 Java 글루 레이어를 숨기거나 자동화하는 것뿐만 아니라) Superpowered는 https://www.youtube 에서 해당 주제에 대해 할 말이 많습니다

@pnico 이것이 Java/JNI가 바이패스되어야 한다고 주장하는 방법을 설명할 수 있습니까? 오디오 처리 코드가 C++로 작성되어야 하는 것보다 조금 더 많은 것을 말하는 것 같습니다. (즉, JNI나 다른 방법으로 호출할 수 없다는 의미는 아닙니다.)

@ csga5000 당신이 완전히 옳았습니다. 그것은 말이되지 않습니다. D JNI는 아마도 더 난해한 일을하려고하지 않는 한 실제로 성능에 영향을 미치지 않을 것입니다. 나는 그것이 정말로 편리함/유지보수 가능성으로 귀결된다고 생각합니다. 그리고 아마도 더 많은 앱별 코드를 Java/C++에서 Dart로 옮기는 기능일 것입니다.

@pnico 가 JINI를 통해 호출할 수 있지만 JINI가 대기 시간을 너무 많이 추가한다고 말하는 것
따라서 성능이 문제입니다.
예 아니오 ??

이것은 주로 암호화 관련 작업에 큰 차이를 만들 수 있습니다.

또한 나는 실험을 보거나 만들지 않았지만 Android Things에 대해 가정합니다.
c나 dart 모두에서 타이밍에 민감한 gpio에 대한 벤치마크
년도.

2018년 6월 9일 토요일 10:52 Eddy WM, 알림 @github.com 작성:

이것은 주로 암호화 관련 작업에 큰 차이를 만들 수 있습니다.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/flutter/flutter/issues/7053#issuecomment-395927258 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AFHMcSI2JDHbgv3iYrStDN5mlzkQ8XEkks5t6xxMgaJpZM4K-PLw
.

그 이후로 어떤 진전이 있습니까?

이 문제가 해결될 때까지 ac/c++ 라이브러리를 통합하는 방법을 보여주는 예시 플러터 플러그인에 대한 권장 사항이 있습니까? djinni 가 좋은 방법인가요?

해결될 때까지 네이티브 android 및 ios 코드를 작성하는 c/c++를 통합한 다음 플랫폼 채널을 사용하여 dart 코드에 인터페이스하는 유일한 방법

나는 플랫폼 채널을 사용하는 플러그인을 구현했습니다(jar 파일 및 CocoaPods에). 동일한 c/c++ 라이브러리(안드로이드 및 ios 모두)에 통합하는 방법을 보여주는 예제 플러그인을 찾고 있습니다. 추천 사항이 있습니까?

@ mmcc007 Java 또는 swift에서 수행하는 방법입니다.

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

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

당신은 당신이 정말로 예를 원한다면 당신이 그것을 어떻게 강력 하진 권장 볼 수있다 (이것은 단지 하나의 내가 아는입니다) : 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 에는 cpp/RecorderExample.cpp의 코드를 참조하는 java/com/superpowered/recorder/MainActivity.java

@csga5000 첫 리뷰로

이것에 대해 +1. C++를 사용하는 플러터 앱의 모든 작동 예제는 호평을 받을 것입니다.

golang에 대해이 작업을 수행하는 프로젝트가 있으며 동일한 접근 방식이라고 생각합니다.
C++에도 사용할 수 있습니다.

golang 프로그램은 jsonrpc를 사용합니다.
그런 다음 jsonrpc를 사용하여 자신의 golang 코드를 앞에 표시하기만 하면 됩니다.

그러면 모든 것이 매우 쉽습니다.

플랫폼 채널은 불가지론적 직렬화로 JSON만 지원한다고 생각합니다.
형식 ?

2018년 7월 18일 수요일 16:50 Jefferson Bledsoe, 알림 @github.com
썼다:

이것에 대해 +1. C++를 사용하는 플러터 앱의 작동 예는 다음과 같습니다.
잘 받았습니다

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/flutter/flutter/issues/7053#issuecomment-405958345 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ATuCwkPbb9vLdoaEwM-bLhYPZxtyQ5Vjks5uH0sqgaJpZM4K-PLw
.

안녕하세요, 어떤 소식이 있습니까?

이 스레드의 누군가가 Superpowered 라이브러리를 Flutter 앱에 직접 통합했는지 알고 싶습니까?

예 @skills-up 우리 가 해냈습니다. 오픈 소스 프로젝트가 아니기 때문에 보여줄 수 없습니다. 하지만 앞서 내 팁을 본다면 그렇게 하는 것입니다. 각 CPU 아키텍처에 대한 Flutter 앱을 빌드해야 할 수도 있습니다.

나는 당신이 다트에서 직접적으로가 아니라 JNI/Java를 통해 했다는 것을 이해합니다. 플랫폼별 코드를 모두 피할 수 있는지 궁금합니다.

각 CPU 아키텍처에 대한 Flutter 앱을 빌드해야 할 수도 있습니다.

각 아키텍처에 대해 별도의 앱을 의미합니까, 아니면 지원되는 모든 아키텍처를 지정하기만 하면 되나요?

BTW, 우리는 이미 기본적으로 Java로 작성된 작동하는 앱을 가지고 있습니다. 그러나 이제 iOS 앱도 만들어야 하므로 (Swift/XCode에 노력을 들이는 대신) 플러터로 만드는 것이 단일 코드 기반의 이점과 함께 향후 유지 관리 측면에서 더 의미가 있는지 궁금했습니다.

잘. Realm은 여러분이 방법을 제공하기를 기다리고 있습니다: https://github.com/realm/realm-object-server/issues/55

lukaspili : 다들 아직 기다리고 있는 것 같아요: flutter/flutter#7053
bmunkholm: @lukaspili 네, 그건 확실히 전제 조건입니다.

그만한 가치가 있기 때문에 나도 이것을 기다리고 있습니다. 여러분이 적절한 배관을 얻을 때까지 XF 앱을 flutter로 교체하는 것을 실제로 조사할 수 없습니다. 현재 상태로 Xamarin은 이 부서에서 물 밖으로 펄럭입니다.

이 파티에 늦었지만 이 스레드에 대해 큰 +1입니다.

저는 데스크탑 앱을 개발합니다. 제 보기는 한 줄의 코드(데스크톱용)입니다.

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

Flutter가 C++에 대한 최고 수준의 지원을 제공할 수 있다면 일반적인 접근 방식이 "모바일 우선"뿐만 아니라 세계 최초의 크로스 플랫폼 애플리케이션 개발에서 절대적인 승자가 될 수 있다고 생각합니다. Qt는 소규모 개발자에게 비싸고 독단적이며 현대적인 C++를 수용하지 않으며 실제로 경쟁할 만한 것이 없습니다. Flutter가 UI 파이의 적어도 일부를 먹을 수 있습니까?

추신: 저는 다트를 반대하는 것이 아니라 또 다른 새로운 C#/Go/Rust/etc입니다. 새로운 플랫폼에서는 매우 생산적일 수 있지만 고성능 데스크탑(여기서 내 관심) 응용 프로그램의 세계는 확고한 C++이며, 광범위한 OS 및 라이브러리 지원을 제공하며, 언어 자체가 빠른 속도로 발전하고 있습니다. C), Flutter는 그럴 자격이 있다고 생각합니다!

나는 플러터가 가까운 장래에 C++를 지원할 것이라고 생각하지 않으며, 지금은 확실히 불가능합니다. 그리고 저는 Dart를 엄청나게 선호합니다. C++로 앱을 작성하는 데에도 플러터가 포함된 경우 훨씬 더 많은 노력이 필요합니다. 그리고 저는 C++가 데스크탑 지원으로 직접 변환된다고 생각하지 않습니다. 그들은 여전히 ​​상당한 양의 코드를 작성해야 하고 dart VM은 어쨌든 데스크탑에서 작동해야 합니다. 대부분의 응용 프로그램에서 성능이 무시할 만하다고 생각합니다.

결국 Google은 상호 운용성을 지원하여 지원되는 언어 또는 해당 언어의 조합을 사용하여 모든 플랫폼에 대한 플러터 앱을 작성할 수 있기를 원한다고 생각합니다. 하지만 Fuchsia가 출시될 때까지는 그렇게 기대하지 않을 것입니다. 현재 그들의 목표는 코드를 한 번 쉽게 작성할 수 있도록 하는 것입니다. Dart는 사용/배우기 쉽고 효율적이며 어쨌든 Google의 언어 중 하나이기 때문에 그 목표에 부합합니다. 일급 C++ 지원을 받는 일반 사용자에게는 실질적인 이점이 거의 없다고 생각합니다. 성능은 모바일 앱에서 무시할 수 있는 수준이며, C++가 포함된 플랫폼 채널을 사용하면 기존 C++ 라이브러리와 상호 작용할 때 편리합니다. 밝은 면에서, 당신은 그들이 데스크탑을 지원하기 위해 결국 flutter를 의도한다는 것을 확신할 수 있습니다(적어도 Fuchsia의 카피바라, 그러나 그들이 거기서 멈출지는 의심스럽습니다).

이 스레드는 dart/flutter에서 직접 통합 w/ C++를 지원하는 것에 관한 것으로, 가까운 시일 내에 제공될 수 있기를 바랍니다.

나는 flutter가 C++를 지원할 것이라고 생각하지 않습니다.
일급 C++ 지원을 받는 일반 사용자에게는 실질적인 이점이 거의 없다고 생각합니다.

Flutter/Dart가 C++에 비해 얼마나 뛰어난지 문제가 아니라 현재 에코시스템에 맞추기 위해 필요한 통합의 요점/쉬움에 관한 것입니다. 라이브러리의 긴 목록은 업계 표준인 공유 개체(예: OpenCV)로 존재합니다. 사람들이 Dart에서 라이브러리를 다시 작성할 것이라고 기대할 수 없습니까?

성능은 모바일 앱에서 무시할 수 있는 수준이며, C++가 포함된 플랫폼 채널을 사용하면 기존 C++ 라이브러리와 상호 작용할 때 편리합니다.

이와 정반대로 채널을 사용하는 것은 이 컨텍스트에서 차선책입니다. 메모리(이미지)에서 큰 이진 개체로 작업해야 하는 사용 사례를 생각하면 다음 중 하나가 필요합니다.
1- 이 바이너리를 C++ 메모리에서/로 복사합니다.
2- JNI를 사용하여 라이브러리와 인터페이스하고 이 바이너리에 동적으로 할당된 포인터를 처리합니다.
채널을 사용하여 발생하는 직렬화/역직렬화 값/매개변수 비용의 오버헤드는 언급하지 않습니다.

좋은 프레임워크는 그것이 도입하는 새로운 기능/패러다임과 C++가 일부인 것을 부정할 수 없는 현재 에코시스템/레거시와 얼마나 쉽게 통합할 수 있는지 사이의 균형입니다.

@nhachicha @csga5000 은 C++를 직접 통합하는 것이 중요하다는 데 동의하지 않았습니다. 그는 Flutter를 Dart 코드 없이도 C++에서 직접 사용할 수 있는지 묻는 이전 의견에 답했습니다.

성능은 모바일 앱에서 무시할 수 있는 수준이며, C++가 포함된 플랫폼 채널을 사용하면 기존 C++ 라이브러리와 상호 작용할 때 편리합니다.
@nhachicha 더 동의할 수 없습니다.

진실은 이빨을 깨는 성능이 필요하지 않은 응용 프로그램(많음)에 대한 것입니다. 그렇다면 마스터 C++를 더 생산적인 것으로 바꾸지 않는 이유는 무엇입니까? 사실 Dart만 사용하는 것이 좋습니다. Dart보다 훨씬 더 대중적/확립) 언어:

• C#/.Net Core 런타임
• Javascript/Typescript V8 런타임
• 녹(또한 빠름!)
• 고랑
• 파이썬
• [여기에 즐겨찾기 삽입]...

그리고 개인적으로 이러한 언어 중 일부를 매일 사랑하고 사용하는 만큼 C 및 C++는 Linux의 핵심이므로 Android, iOS 및 Windows, MacOS 및 기타 데스크톱과 같은 데스크톱 플랫폼입니다. 위의 언어 중 절반(Dart 포함)은 C++로 작성되었습니다. 최첨단 기술은 AI(Tensorflow는 C++, Caffe C++, Pytorch는 Python에서 C 등), 증강 현실 라이브러리, AAA 게임 엔진 및 GPU(CUDA)에 가까워야 하는 모든 것과 같은 조정된 기본 성능을 계속해서 요구합니다. , C/C++에서 호출됨).

Flutter 렌더링 엔진 자체가 C++ (네이티브, 고성능, 배터리/메모리/cpu 효율)로

_참고로 저는 양식 유효성 검사에서 픽셀 셰이더에 이르기까지 모든 것을 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 VM의 핵심 구성 요소로 다음과 같은 것을 작성할 수 있습니다.

import 'dart:ffi' as ffi;

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

우리는 오랫동안 이와 같은 FFI를 구현하는 데 상당한 관심을 가지고 있었습니다. 가까운 장래에 FFI를 실험할 것으로 예상하지만 구체적인 일정에 대해서는 약속하지 않겠습니다.

@kirbyfan64 맞습니다, @nailgilaziev , @bytesoftly C++ 통합이 필요하지 않다고 말하는 것이 아니라 그냥 플러터 지원을 C++ INPLACE of dart - 하지만 통합이 필요하지 않다고 말하는 것이 아닙니다. @mraleph 가 말하는 것은 나에게 똑똑하게 들립니다.

@mraleph The Dartino는 FFI에 대해 유사한 구현을 했습니다. 부활하는 것이 얼마나 어려운 일입니까?

@listepo의 일부입니다. Dartino의 FFI 구현은 매우 역동적이었습니다. 이것은 Dart 1보다 훨씬 더 정적인 Dart 2에 대해 원하는 것이 아닙니다.

게임에 늦었지만 여기에 또 다른 사용 사례가 있습니다. 암호화 목적으로 c 파일과 메서드를 다트에 포함하고 싶습니다.

우리가 바라는 것은 다음과 같습니다.
1) iOS 및 Android용 동일한 코드, 즉 ObjC 또는 JNI 계층을 거치지 않습니다.
2) 예를 들어 JNI를 두 번 통과할 때보다 더 효율적인 구현을 바랍니다.
3) AngularDart와 같은 후속 웹 앱 또는 이 프로젝트를 사용하는 후속 데스크톱 앱에서 dart 모델 코드를 재사용할 수 있는 가능성: https://github.com/google/flutter-desktop-embedding

우리가 원하는 것이 위에서 언급한 @eseidelGoogle의 2

@mraleph가 제안한 대로 FFI를 사용하면 이전 의견에서와 같이 1)-3)이 허용

@CryptUser C/C++ 코드가 모든 플랫폼에서 동일한 경우 FFI를 통해 호출하는 Dart 코드도 모든 플랫폼에서 동일합니다.

@mraleph 잘

@mraleph 어딘가에 Dart의 FFI에 대한 미해결 문제가 있습니까?

@dnfield 지금 바로 제출했습니다 https://github.com/dart-lang/sdk/issues/34452

C/C++/Rust 코드를 작성하고 ffi를 통해 사용할 수 있기를 바랍니다.

예시:

Android 태블릿(Android 4.4)에서 플러터를 테스트합니다.
펄럭이는 빠르게 실행.
그러나 플랫폼 채널을 사용하는 sqflite로 1000 행을 읽으려고하면 엄청나게 느립니다.
이유 : sqlite 커서 리더를 사용할 수 없습니다.

하지만 sqlite 라이브러리를 직접 사용할 수 있다면 동일한 쿼리가 즉시 실행됩니다. (xamarin 및 기본 Android 프로젝트로 테스트됨).

우리는 지금 이 문제에 가장 잘 접근하는 방법에 대해 논의하고 있습니다. 위의 https://github.com/flutter/flutter/issues/7053#issuecomment-377711814에서 언급했듯이 이 문제에는 많은 부분이 있으며 아마도 분할해야 할 것입니다. :)

그러나 FFI 탐색에 관심이 있는 일부 엔지니어를 찾았습니다(https://github.com/flutter/flutter/issues/7053#issuecomment-415161464 참조). 지금 우리의 초점은 1.0을 출시하는 것입니다. 그러나 일단 완료되면 이것은 목록에서 가장 높을 것입니다. 귀하의 지속적인 피드백에 다시 한 번 감사드립니다. 공유할 진행 상황이 더 있으면 이 문제를 업데이트하겠습니다.

저도 Matlab/Simulink 사용자입니다. 고도로 최적화된 CPU 특정 c/cpp 코드를 생성할 수 있습니다. 내 알고리즘을 플러터에 통합하고 싶습니다. 나는 많은 이미지 처리 알고리즘을 가지고 있습니다. 네이티브 코드에 대한 바인딩 생성기가 필요합니다. 그렇지 않으면 나는 모든 다트 플러터 경험을 잊어버리고 자마린이나 나에게 맞는 것을 배우기 시작할 것입니다.

진행 속도를 높일 수 있습니까?

Dart와 C를 상호 운용하는 것은 엄청난 고통입니다.

프로세스를 서두른다고 해서 좋은 품질의 제품이 나오지는 않을 것입니다. 준비되면 준비됩니다. :-)

프로세스를 서두른다고 해서 좋은 품질의 제품이 나오지는 않을 것입니다. 준비되면 준비됩니다. :-)

글쎄, 내가 말하려고 했던 것은 우리가 이 문제를 해결하는 데 더 많은 자원과 노력을 기울일 수 있도록 우선 순위를 높이고 싶을 수도 있다는 것입니다. "향후 몇 년 내에 수정될" "목표"를 목표로 하는 현재 1386개의 미해결 문제가 있다는 것을 알고 있습니다.

스레드를 다시 한 번 읽은 후 @eseidelGoogle에서 Flutter 1.0이 준비된 후에 이것이 더 높은 우선순위를 갖게 될 것이라고 말했습니다. 제 고민을 잘 해결했다고 생각합니다.

"목표"가 잘못된 버킷일 수 있습니다. :) @mraleph 는 우리가 말하는 동안 https://github.com/dart-lang/sdk/issues/34452 를 탐색하는 사람이 있습니다. 그것은 적어도 솔루션의 일부입니다.

다음은 현재 Dart 측에서 프로토타이핑 중인 FFI에 대한 비전 문서 입니다.

살펴보고 어떻게 생각하는지 알려주세요.

FFI 부분은 그런걸 써본적이 없어서 뭐라 말을 못하겠는데
하지만 펍 통합이 어떻게 보일지 궁금합니다.

FFI를 사용하는 게시 패키지는 어떻게 처리됩니까?
FFI를 사용하는 패키지를 어떻게 처리합니까?

@zoechi 우리는 아직 pub 통합에 대해 논의하지 않았습니다.

오늘날 Flutter 플러그인과 유사하게 작동할 수 있어야 합니다. 플랫폼/아키텍처에 적합한 소스 및/또는 소비 애플리케이션으로 컴파일/링크할 수 있는 바이너리를 포함합니다.

펍의 관점에서 보면 패키지에 더 큰 바이너리 파일이 포함될 수 있다는 점을 제외하고는 큰 문제가 되지 않습니다.

Flutter 프로젝트에 통합하려면 Flutter 도구 끝부분에 약간의 작업이 필요합니다. 현재 Android/iOS 플러그인과 완전히 동일하게 작동하지 않을 것입니다.

이 문제에 더 집중하기 위해 pub-integration을 dart-lang/pub 문제로 옮겨야 합니까?

나는 '비전 문서'를 읽었고 마침내 안개 사이로 모양이 보입니다.

그 동안 나는 훨씬 다른 것에 대해 생각하고 있었다.

즉, Flatbuffer 를 (재)사용하여

메시지 전달 방식은 현재 스트림 기반 아키텍처(Bloc, Rx)와도 일치합니다. 컴파일러가 적절한 경우 적절한 링 버퍼를 생성하거나 호출 수신자가 데이터를 더 오래 보유해야 하는 간단한 '호출 수신자 해제'를 가정할 수 있으므로 메모리 관리에 대한 우려도 무효화됩니다.

하지만 솔직히 말해서 Flutter(Fuchsia) 생태계에 매끄럽게 통합되고 Dart 앱 내에서 cpu에 최적화된 네이티브 코드를 사용할 수 있게 된다면 어떤 형태의 ffi에도 박수를 보내겠습니다.

@ohir 당신이 상상했던 것은 버그에 나타난 일부 문제에 대한 또 다른 해결책이 될 것입니다. 이 버그는 C++와 관련된 모든 것을 포괄하는 범용으로 발전했습니다. :/ 나는 (이전 의견에서 언급했듯이) 이 버그를 더 작은 것으로 나눌 필요가 있다고 생각합니다. FFI 작업은 우리가 이 분야에서 구축하는 유일한 솔루션이 아닐 수도 있습니다.

@eseidelGoogle 이에 대한 진전이 있습니까? 현재 dart 패키지는 실행 가능한 솔루션을 제공할 수 없기 때문에 ffmpeg를 통해 수행할 수 있는 무거운 비디오 처리 작업을 구현해야 하는 프로젝트가 있습니다. 우리는 flutter가 ffmpeg lib를 직접 호출하기를 간절히 기다리고 있습니다.

페이지 간 UI 기반 앱의 경우 이제 플러터는 Android와 ios 모두에서 이중 코딩 작업으로 전환하는 것보다 정말 좋은 선택이라고 생각합니다. 변경됩니다. 그러나 현재 Flutter의 이점은 이전 방식으로 이미 충분히 작업을 수행했기 때문에 회사로 마이그레이션하는 회사에게 숨이 막힐 정도는 아닙니다.

dart가 언젠가는 그 작업에 적합하지 않거나 실행 가능하지 않다는 것을 의미하지는 않지만 플러터 생태계에 포함될 수 있는 일반 IT 회사의 관점에서 필요한 것은 크로스를 사용하여 비용을 줄이는 것입니다. 플랫폼 코딩 방법은 클라이언트 측 데이터 처리, 비디오/오디오, AR 직원 등과 같이 이미 c/c++를 통해 수행한 일부 알고리즘이 있는 한 가장 멋진 기능을 달성할 수 있는 경우에만 가능합니다. 그들이 dart lang을 사용하여 그것을 다시 구현하거나 재발명하는 것은 정말 어렵습니다.

그리고 핵심 솔루션은 flutter가 C++와 통신할 수 있는 직접적이고 효율적인 방법을 도입하는 것입니다. 저는 이것이 "크로스 플랫폼"의 최우선 순위라고 생각합니다. UI 직원을 위한 dart는 완벽하고 일부 일반 데이터 논리도 가능합니다. 다트에서 수행되지만, 새로운 것을 재구축하는 것보다 플러터가 길지만 여전히 활동적이고 효율적인 C++ 생태계에 병합하는 것이 훨씬 낫습니다!

진정한 "크로스 플랫폼" 코딩 경험의 꿈은 내부에 C++가 있고 Java 코드가 전혀 없고 OC 코드가 전혀 없는 dart UI 직원입니다. 와하하, 나는 그것이 일어나는 것을보고 싶어 기다릴 수 없습니다!

@smellbee ffmpeg 명령줄을 사용할 수 없습니까?

@smellbee I featr 이 질문에 답할 수 있는 사람이 아닙니다. @eseidelGoogle 이에 대한 소식이 있습니까?

@smellbee ffmpeg 명령줄을 사용할 수 없습니까?

ffmpeg lib를 사용하여 비디오 프레임을 렌더링하여 즉각적인 피드백 스트림을 생성하는 클라이언트 측 작업입니다. 명령줄을 사용할 수 있습니까?

@smellbee I featr 이 질문에 답할 수 있는 사람이 아닙니다. @eseidelGoogle 이에 대한 소식이 있습니까?

죄송합니다. "es"를 입력했고 자동으로 완료 되었지만 눈치채지 못했습니다.

작업은 Dart 쪽에서 진행 중입니다. 우리는 2019년 1분기에 무언가를 준비할 수 있기를 바랍니다.

그것은 큰 기능이며 우리는 그것을 올바르게 만들고 싶습니다. 우리는 Dart의 다양한 실행 모드에서 훌륭하게 작동하기를 원하므로 세부 사항을 처리하는 동안 우리를 기다려주십시오.

Dart 측에서 작업을 추적하는 dart-lang/sdk#34452를 따를 수 있습니다.

Dart FFI를 사용하면 Dart에서 C 함수를 호출할 수 있습니다.
그러나 C++ 기능(클래스, 표준 컨테이너, 스마트 포인터, 예외)은 어떻습니까?
최소한의 상용구로 C++ 클래스를 Dart로 내보낼 가능성을 기대할 수 있습니까?

또 다른 중요한 기능은 비동기 지원입니다. C++ 코드를 별도의 스레드에서 실행하고 메서드에서 Future/Stream을 반환하는 기능입니다.

@t-artikov C++ 상호 운용성을 직접 지원할 계획은 현재 없습니다. 너무 복잡합니다. C++와 인체공학적으로 상호 운용할 수 있는 유일한 것은 C++입니다.

C++와의 높은 수준의 상호 운용성에 관심이 있다면 C와 같은 API를 통해 C++ API를 노출하는 고유한 상호 운용성 계층을 구축해야 합니다.

또 다른 중요한 기능은 비동기 지원입니다. C++ 코드를 별도의 스레드에서 실행하고 메서드에서 Future/Stream을 반환하는 기능입니다.

패키지로 만들 수 있을 것 같아요. 우리는 이것이 구축될 수 있도록 올바른 프리미티브를 제공하는지 확인해야 합니다.

Dart FFI를 사용하면 Dart에서 C 함수를 호출할 수 있습니다.
그러나 C++ 기능(클래스, 표준 컨테이너, 스마트 포인터, 예외)은 어떻습니까?
최소한의 상용구로 C++ 클래스를 Dart로 내보낼 가능성을 기대할 수 있습니까?

C++에서 dart를 호출할 수 있는 방법이 있는 한, 그런 일이 가능하다고 생각합니다. C++는 C++가 걱정하는 것을 처리하고 호출되거나 호출하여 dart와 통신하므로 저수준 조작을 노출할 필요가 없습니다. 다트의 사용 편의성을 파괴하는 다트.

또 다른 중요한 기능은 비동기 지원입니다. C++ 코드를 별도의 스레드에서 실행하고 메서드에서 Future/Stream을 반환하는 기능입니다.

그리고 dart는 이미 비동기식 메커니즘을 가지고 있습니다. 따라서 C++ 부분이 필요할 때마다 dart를 호출할 수 있고 "격리"가 작업을 수행할 수만 있다면 스레드가 C++ 지향적인지 여부는 차이가 없습니다.

그것이 내가 생각하는 것입니다 @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);
};

Dart에서 사용할 수 있도록

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

@t-artikov boostorg::python 및 sol2 둘 다 실제로 내 요점을 잘 보여줍니다. 이것은 다른 언어와 상호 운용하기 위한 C++ 라이브러리이지 그 반대가 아닙니다. Dart FFI는 Dart를 호출하는 C++ 중심 방식이 아니라 C API를 호출하는 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 interop이 가장 실행 가능한 옵션이라고 생각합니다.

공식 상호 운용성 개발자가 C++에 대해 달성할 수 있는 매우 일반적인 솔루션은 거의 없습니다. Kotlin/Native는 이를 제공하지 않습니다. 스칼라 네이티브 iether. .NET(Microsoft C++ interop은 항상 이상하거나 정적임). JNI는 정적 컴파일이 관련된 경우에만 C++ interop을 지원합니다. 파이썬 부스트 글루와 같은 것은 수동으로 작성해야 합니다. 모든 제3자 그룹은 JNAerator와 같은 것을 개발할 수 있습니다.

실제 답변이 없는 이 대화에 이어 저는 크로스 플랫폼이고 완전한 C++ 지원을 제공하는 Qt를 고수할 것이라고 생각합니다. 다음 프로젝트에 Flutter를 시도해 보고 싶었지만 지금은 그렇지 않습니다. 정말 감사합니다!

flutter가 C++로 작성되어 다른 언어와의 상호 운용이 쉽게 가능했다면 더 좋았을 것입니다. C++에서 flutter를 다시 작성하려는 시도가 있습니까?

지금 논의가 불필요하게 확대되고 있다고 생각합니다.

우리는 Flutter의 개발 로드맵에 무엇이 있는지(또는 그렇지 않은지) 알고 있습니다.
따라서 특정 사용 사례에 대해 사용(또는 사용하지 않음)을 결정할 수 있습니다.

개발 의제를 변경하는 데 아무런 도움이 되지 않거나
이 지점을 넘어서는 특정 아키텍처 구현이 필요합니다.

감사 해요,
가우라프

2019년 2월 25일 월요일 오후 10시 51분 bhauj, 알림 @github.com이(가) 작성했습니다.

flutter가 C++로 작성되었더라면 더 좋았을 것입니다.
다른 언어와의 상호 운용성이 쉽게 가능했을 것입니다. ~이다
C++에서 flutter를 다시 작성하려는 시도가 있습니까?

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/flutter/flutter/issues/7053#issuecomment-467098455 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AZ86acDpZgNeyezx40uxe_c5E2xZHWxaks5vRBumgaJpZM4K-PLw
.

실제로 Flutter는 C++로 작성된 것으로 알고 있지만 Flutter 프로그래밍의 경우 VM에서 실행되는 인터프리터 Language Dart로만 수행할 수 있습니다. 하지만 아직 Dart에서 Flutter의 C++ 부분으로 이동할 기회가 없습니다...

따라서 이 글을 읽고 좋은 크로스 플랫폼 개발 앱 개발의 일반적인 사용 사례가 있는 사람이라면 Flutter에서 C++를 직접 사용하는 것을 허용하지 않을 것입니다. 필요한 경우 Qt C++와 같은 다른 크로스 플랫폼 프레임워크를 사용하세요.

나에게 C++는 거의 모든 기술에서 가장 낮은 공통 분모이기 때문에 플랫폼 간 개발에 필수적입니다.

@aqmappdesigners

VM에서 실행되는 인터프리터 Language Dart

정확하지 않습니다.

Flutter는 디버그 모드에서 Dart VM을 사용하므로 핫 리로드도 가능합니다.
릴리스 빌드에서 Dart는 C++와 같은 바이너리 코드로 컴파일됩니다.

@zoechi 감사합니다, 나는 이것을 몰랐습니다. 성능에 좋은 것 같다.

성능에 좋은 것 같다.

Apples App Store의 요구 사항입니다.

dart:ffi 프로토타입은 API 결정을 결정하는 지점까지 진행되었습니다. (일부 디자인 결정은 여기에서 논의

정보에 입각한 디자인 결정을 내리기 위해 바인딩하려는 C API에 대한 더 많은 예가 필요합니다. 지금까지 이 문제에서는 SQLite, Realm, OpenCV, Superpowered 및 ffmpeg에 대해 언급했습니다. 고려해야 할 다른 API가 있습니까?

@dcharkes 도움이되는지 모르겠지만 Android의 Telegram은 JNI를 통해 C++에서 네트워킹을 수행합니다.
https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/jni/TgNetWrapper.cpp
또한 ffmpeg로 GIF 재생을 처리하여 Android Bitmaps에 직접 작성합니다.
https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/jni/gifvideo.cpp

등록 양식에 대해 libphonenumber 및 libpostal 을 통해 전화 및 주소를 구문 분석하는 방법이 있으면 흥미로울 수 있습니다. 또한 glfw + flutter- embedder 그리고 언젠가는 완전히 다트로 작성된 데스크탑 앱을 보게 될 것입니다.

SQLite 및 Realm의 경우 +1. Couchbase 도 살펴보십시오. C SDK와 함께 공통 C++ 코어가 있습니다.

Firebase C++ API가 재미있을까요? https://firebase.google.com/docs/reference/cpp/

자세히 살펴보진 않았지만 iOS 및 Android 플러그인을 C++와 직접 대화하는 단일 플러그인으로 대체할 수 있을 것이라고 생각했습니다.

일부 암호화 라이브러리는 ring from rust - https://github.com/briansmith/ring 과 같은 사랑을 받아야 합니다.

OpenCV, Realm, SqlCipher의 경우 +1(https://github.com/sqlcipher/sqlcipher)

암호화 라이브러리. 특히 libsodium 또는 팅크.

https://github.com/google/tink

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

이미 flutter-sodium 라이브러리가 있으며 플랫폼 채널을 통해 각 플랫폼의 libsodium 래퍼와 통신한 다음 기본으로 통신합니다.

mapbox-gl https://github.com/mapbox/mapbox-gl-native 와 같은 사용자 지정 매핑 라이브러리

https://github.com/deltachat/deltachat-core 를 통한 Flutter의 SMTP/IMAP 처리(이메일 채팅용)는 직접 사용하고 싶은 것입니다.

내가 너무 과감하게 바꿔 말하면 일반적인 사용 사례는 다음과 같습니다.

1. 지연 시간이 짧은 오디오/비디오 하드웨어 액세스(예: Superpowered)
2. 하드웨어 지원 A/V 처리(예: ffmpeg)
3. XMPP/기타 네트워크 지향 프로토콜용 TCP 기반 소켓 액세스
   (채팅, 푸시 알림용)
4. 프로세스 수준 업그레이드(루트 액세스) / 스레드 생성
   플랫폼 간 호환 방식(시스템 앱, 멀티태스킹, 에뮬레이터용)

더 많은 사용 사례가 있을 수 있지만 이것들은 내
정신.

예제를 제공해 주신 모든 분들께 감사드립니다! 이것은 매우 도움이 됩니다.

@skills-up 우리는 추상적인 분류보다 구체적인 예에 ​​훨씬 더 관심이 있습니다. 구체적인 사례를 통해 FFI의 인체 공학을 평가하고 싶기 때문입니다.

이상하게도 C++에서/로 최고의 인터페이스를 제공하는 언어 중 하나는 OO에 대해 완전히 다른 접근 방식을 가지고 있음에도 불구하고 강력한 매크로 + 빌드 시스템을 통해 Rust입니다.

클라이언트 인증서를 사용하여 비누 요청과 xml 파일(XMLDSig, Xades l)에 디지털 서명을 해야 하기 때문에 OpenSSL이라고 말하고 싶습니다.
Dart 자체에는 BoringSSL이 있지만 그 중 일부만 Dart를 통해 노출됩니다. 그래서 차선책은 플러터에서 네이티브 openssl 라이브러리를 호출하는 것입니다.

스팸이 아니기를 바랍니다. 그러나 JNI를 거치지 않고 tensorflow lite와 더 잘 통합되기를 원합니다. 이는 비디오 작업에 유용할 것입니다.

자세히 살펴보진 않았지만 iOS 및 Android 플러그인을 > C++와 직접 통신하는 단일 플러그인으로 대체할 수 있다고 생각했습니다.

C++를 지원하는 것 외에도 Go와 직접 대화할 수 있는 플러그인이 있다면 정말 좋을 것입니다. 지금 우리는 UI 응답 속도를 늦추는 gomobile 및 flutter 플랫폼 채널을 통해 Go에 대해 이야기하고 있습니다. Flutter에서 Go 및 C++를 기본적으로 지원하면 여러 플랫폼에 대해 균일한 코드 기반(비즈니스 논리/알고리즘)을 유지하는 데 도움이 됩니다.

기본 라이브러리 액세스의 경우 +1입니다.

Android/iOS용 플랫폼 채널을 만들고 두 개의 플러그인을 유지하지 않고도 Vulkan/MoltenVK에 액세스하고 싶습니다. 그러면 Dart에서만 개발하면서 3D 애플리케이션을 빌드하고 텍스처 위젯으로 렌더링할 수 있습니다. 플랫폼 채널은 해키 해결 방법처럼 보입니다. 각 플랫폼에 대한 래퍼를 작성하지 않고 기본 라이브러리에 액세스하고 해당 라이브러리에 대한 새 버전이 있을 때마다 유지 관리하고 싶습니다.
이 기능은 더 많은 개발자를 끌어들일 것이라고 생각합니다.

예, plz는 flutter에서 네이티브 라이브러리에 직접 액세스합니다.
Flutter에서 C++ 라이브러리를 사용하고 싶습니다.

예, plz는 flutter에서 네이티브 라이브러리에 직접 액세스합니다.
Flutter에서 C++ 라이브러리를 사용하고 싶습니다.

이제 피드백을 받기 위해 조기 미리보기를 제공하고자 합니다.

자세한 내용 은 Dart 추적 버그 업데이트 를 참조하세요.

@mit-mit 이것이 이 문제에 도움이 될까요? Flutter와 함께 파이썬 라이브러리를 호출하거나 사용할 수 있습니까?

파티에 늦었지만 SQLCipher @dcharkes @mraleph의 경우 +1

@doc-rj 우리는 이제 SQLCipher 바인딩을 실험하고 경험에 대한 피드백을 제공할 수 있어야 하는 단계에 있습니다. 이 주석을 참조하십시오.

요청이 매우 다양하기 때문에 우리가 실제로 특정 라이브러리 바인딩을 제공하는 것을 목표로 하지 않는다는 점을 강조하고 싶습니다. 그러나 우리는 모든 사람과 누구나 C API를 사용하여 모든 라이브러리에 바인딩할 수 있도록 하는 것을 목표로 합니다.

멀티플랫폼이 발표되면서 그 필요성이 높아진 것 같아요.

이것은 로드맵의 일부입니까?

@felemedeiros 작업이 진행 중입니다. FFI를 사용하여 바인딩하려는 라이브러리가 있는 경우 피드백을 제공하기 위해 바인딩 작업을 시작하는 것이 좋습니다. 정보는 이 댓글 을 참조하세요.

자세히 살펴보진 않았지만 iOS 및 Android 플러그인을 > C++와 직접 통신하는 단일 플러그인으로 대체할 수 있다고 생각했습니다.

C++를 지원하는 것 외에도 Go와 직접 대화할 수 있는 플러그인이 있다면 정말 좋을 것입니다. 지금 우리는 UI 응답 속도를 늦추는 gomobile 및 flutter 플랫폼 채널을 통해 Go에 대해 이야기하고 있습니다. Flutter에서 Go 및 C++를 기본적으로 지원하면 여러 플랫폼에 대해 균일한 코드 기반(비즈니스 논리/알고리즘)을 유지하는 데 도움이 됩니다.

현재 Flutter에서 Go 라이브러리 API를 호출하는 방법에 대한 기사를 작성했습니다. 관심 있는 사람에게 유용할 수 있습니다. https://medium.com/@archan.paul/using -go-library-in-flutter-a04e3496aa05

Flutter 앱에 C++ 코드를 추가하려면 어떻게 해야 하나요?

Flutter 앱에 C++ 코드를 추가하려면 어떻게 해야 하나요?

현재로서는 C++ -> JNI(Android용) -> PlatformChannel 방식을 사용하는 것이 더 우아한 방법이 될 때까지 선택하는 것뿐인 것 같습니다!!

ezored(http://ezored.com)라는 프로젝트를 만들었습니다. 이미 Java 및 objc에 있으므로 다른 것으로 변환할 필요 없이 복잡한 객체를 Flutter에 전달할 수 있다면 좋을 것입니다. 누구나 ezored를 사용하여 SDK를 생성(또는 미리 빌드된 다운로드)하여 네이티브와 Dart 간의 Flutter 통합을 테스트할 수 있습니다. 요청, 구문 분석, 데이터베이스를 사용한 crud 및 이미 구현된 데모 SDK의 많은 것들이 있습니다.

Flutter 그룹에서 검색하지만 개체와 개체 목록을 Flutter에 직접 전달할 방법이 없습니다.

도움을 주셔서 감사합니다.

새로운 진전이 있습니까? 2.5년은 넘게 흘렀던 것 같다...

@fzyzcjy 작업 중입니다. 우리는 초기 미리보기를 출시했습니다. 참여 방법은 https://github.com/dart-lang/sdk/issues/34452#issuecomment -482136759를 참조

이 초기 미리 보기 이후로 Intel 32, Arm 64 및 Arm 32에 대한 지원이 추가되었습니다. 이러한 플랫폼은 아직 안정 버전이나 개발 버전으로 출시되지 않았으며 Dart sdk의 마스터 브랜치에서만 사용할 수 있습니다. 여기에서 진행 상황을 추적하고

@dcharke 그 소식을

어떤 진전이 있습니까?

상태 업데이트 및 추가 정보는 https://github.com/dart-lang/sdk/issues/34452 를 참조

Flutter를 사용하여 웹 앱을 만들 때 ac 라이브러리와 함께 ffi를 사용할 수 있습니까?

Flutter를 사용하여 웹 앱을 만들 때 ac 라이브러리와 함께 ffi를 사용할 수 있습니까?

그럴 가능성은 없습니다. 이론적으로 장기적으로 WebAssembly를 사용하여 지원할 수 있지만 현재 작업 중인 것은 아닙니다.

@ with-with 정말?

Flutter를 사용하여 웹 앱을 만들 때 ac 라이브러리와 함께 ffi를 사용할 수 있습니까?

그럴 가능성은 없습니다. 이론적으로 장기적으로 WebAssembly를 사용하여 지원할 수 있지만 현재 작업 중인 것은 아닙니다.

WebAssembly가 필요한 이유는 무엇입니까? 사람들에게 미래에 WebAssembly로 다시 빌드하도록 요청할 수 있다면 지금 ASM.js로 다시 빌드하도록 요청할 수 있습니다.

@nic-hartley 좋은 생각이지만 문제는 네이티브 코드를 컴파일하는 방법이 아니라 Dart(JS로 컴파일된)와 네이티브 코드 사이에 다리를 만드는 것입니다. 형식이 무엇이든 상관없습니다.

기본 FFI는 성능상의 이유로 매우 낮은 수준이며 asm.js 또는 WebAssembly로 쉽게 변환될 수 없습니다.

명확히 하자면, 우리의 구현이 매우 낮은 수준이라는 것을 의미합니다. 이것은 확실히 흥미로운 기능이지만 제공하려면 상당한 작업이 필요할 것입니다.

flutter는 C++를 지원하기 전까지는 장난감일 뿐입니다.

Flutter가 C++와 쉽게 상호 운용할 수 있을 때까지(브리지 라이브러리가 없고 성능 저하 없이) 기존 기본 라이브러리에 대한 투자가 있는 대규모 응용 프로그램이나 응용 프로그램에 절대 채택되지 않을 것이라는 동일한 요점을 다른 사람들이 되풀이하기 위해 여기에 왔습니다. 성능이 가장 높은 우선 순위입니다.

React Native도 현재 브리지를 사용하므로 FFI를 구현하려는 측면에서 Flutter가 실제로 앞서 가고 있는 것으로 보입니다.

C++와의 통합은 AppKit을 사용하는 iOS에서 간단합니다. 이것이 React Native가 아니라 우리가 비교해야 하는 것입니다.

UWP 및 C++도 간단합니다.

나는 일반적으로 "다트 FFI 노력 지원" 파티에도 동의하지만...

Xamarin은 UWP보다 더 적절한 비교일 수 있지만 Xamarin의 교차 플랫폼 보기는 Flutter만큼 사용자 정의할 수 없었고 종종 보기 좋게 보기 위해 많은 네이티브 코드가 필요했습니다.

이것은 사실이 아닙니다. Flutter와 달리 Xamarin에는 기본 API(예: Xamarin.iOS 및 Xamarin.Android)에 대한 플랫폼 바인딩이 있으며 앱 개발자는 자체 언어(C#/.NET)로 플랫폼별 구현을 쉽게 작성할 수 있습니다. 이 문제는 언어 기능에 관한 것이며 UI 위젯 API 디자인과 혼합되어서는 안 됩니다.

네이티브 API 사용은 많지만 네이티브 코드 호출은 없습니다. 여기서 Flutter는 같은 배에 있습니다(Xamarin은 앱 코드에 리플렉션 해킹 없이 Java 또는 ObjC를 작성할 필요가 없지만). 네이티브 코드 의 경우 Xamarin.Android 자체(백엔드 플랫폼 백엔드 중 하나)에서도 네이티브 코드의 사용은 거의 없으며 앱 개발자는 네이티브 코드를 작성하지 않습니다.

그리고 React Native나 Xamarin과 달리 Flutter는 완전한 프레임워크를 제공하는 것이므로 전체 Flutter 프레임워크를 AppKit과 같은 것들과 비교하는 것은 전적으로 공정한 관점입니다.

아무도 C++ 통합에 관한 다른 모든 것보다 훨씬 앞서 있는 Qt 프레임워크에 대해 언급조차 하지 않는 것이 이상합니다.

QT는 C++입니다. 그리고 처음부터 불리한 라이센스를 가지고 있습니다.

2019년 8월 12일 월요일, 06:41 Vladyslav Stelmakhovskyi, <
[email protected]>은 다음과 같이 썼습니다.

아무도 훨씬 앞서있는 Qt 프레임 워크에 대해 언급조차하지 않는 것이 이상합니다.
C++ 통합에 관한 기타 모든 것

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/flutter/flutter/issues/7053?email_source=notifications&email_token=AGDYMWXHTJUBUW64LEOO27TQEDSWNA5CNFSM4CXY6LYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNNMVXH
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AGDYMWTNMTM7QUOY2BEIPM3QEDSWNANCNFSM4CXY6LYA
.

Qt는 C++ 및 QML(JS 엔진)입니다.
무슨 라이센스? LGPL? GPL? 뭐가 문제야?

먼저 IANAL이지만 내가 이해하는 것처럼 Qt의 대부분은 LGPL(IDE 등은 GPL임)입니다. 즉, 정적 링크를 명시적으로 금지하지는 않지만 응용 프로그램의 경우 라이선스를 준수하면서 수행하기 어려운 언어가 있음을 의미합니다. 비공개 소스입니다.

기술적으로 LGPL만 사용하고 사용자가 잠재적으로 다른 버전의 라이브러리에 대해 다시 연결할 수 있도록 개체 파일(및 아마도 지침)을 제공하면 LGPL의 요구 사항을 충족하는 것입니다. 그러나 나는 Qt Company가 그 사실을 광고하지 않는다고 확신합니다. 따라서 일반적인 개념은 정적 라이브러리를 배포할 수 없다는 것입니다. 즉, 과도한 라이선스 비용을 지불하지 않고는 앱 스토어에 앱을 출시할 수 없다는 것을 의미합니다. 그리고 개체 파일을 제공하는 것에 대해 내가 틀릴 수 있습니다. 그것은 단지 그것에 대한 나의 이해이며, 어떤 회사가 그렇게 하고 있는지 모르겠습니다.

Android는 LGPL에서 더 명시적으로 허용되는 동적으로 로드된 라이브러리를 허용하기 때문에 더 쉽습니다.

안녕하세요 @cpboyd님 , 저는 이것을 반대 방향에서 보고 있는 것 같습니다. 우리는 이미 플랫폼별 UI 프레임워크에 구축된 앱을 가지고 있으며, 각 플랫폼에서 기존 C++ 라이브러리의 방대한 컬렉션을 활용할 수 있습니다. Flutter가 크로스 플랫폼이라는 것은 이해하지만, 실제로 사용할 수 없다면(기존 코드와 함께) 크로스 플랫폼이 아닌 UI를 고수하는 것이 좋습니다. 유일한 문제는 미래의 OS(예: Fuchsia)가 Flutter & Dart의 사용을 요구하지만 이 사용 사례를 허용하지 않는 경우입니다. 이 경우 기존 코드베이스가 큰 사람은 무시할 수 있습니다.

Flutter/Dart가 "웹" 앱(즉, 백엔드가 웹에 있는 곳)을 염두에 두고 설계되고 있는지, 아니면 전문 데스크톱 응용 프로그램 개발자의 요구 사항에 대해 진지하게 고려하고 있는지 잘 모르겠습니다. 궁극적으로 이와 같은 결정은 앱 스토어에 있는 많은 애플리케이션의 수와 품질에 영향을 미칠 수 있습니다. 수백만 줄의 기존 코드를 활용하여 UIKit을 사용하여 iOS용 고품질 전문 앱을 작성할 수 있지만 Fuchsia/Flutter/Dart용으로 개발하는 경우에는 그렇게 할 수 없습니다(성능 비용이 거의 0에 가까움). 내가 개발하지 않을 OS 및 플랫폼이 될 것입니다.

내 게시물의 목적은 Flutter를 다른 크로스 플랫폼 또는 비 크로스 플랫폼 라이브러리와 비교하는 것이 아니라 일부 개발자에게 중요한 사용 사례를 강조하는 것입니다.

Dart FFI는 흥미롭습니다. sqllite 예제의 _very_ 간략한 읽기에서 PInvoke가 있는 C#과 유사해 보이지만 불행히도 처리하는 거의 모든 유형에 래핑이 필요하거나 다음을 작성해야 하기 때문에 C++에는 적합하지 않습니다. C++를 래핑하기 위한 완전히 일반적인 유형이 없는 인터페이스 시스템. 다음 Obj-C 클래스의 용이성과 비교할 때 둘 다 특히 매력적이지 않습니다.

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

또는 C++/WinRT를 사용하는 UWP:

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

감사 해요 :-)

@Hixie @MarkIngramUK 둘 다 크로스 플랫폼이
AppKit은 Apple 전용이고 UWP는 Windows 전용입니다.
아마도 Flutter가 Dart 대신 Swift 또는 C#을 사용했다면 이미 동일한 수준의 지원을 받았을 것입니다. 하지만 이는 완전히 다른 주장입니다.
Xamarin은 UWP보다 더 적절한 비교일 수 있지만 Xamarin의 교차 플랫폼 보기는 Flutter만큼 사용자 정의할 수 없었고 종종 보기 좋게 보기 위해 많은 네이티브 코드가 필요했습니다.
제 제안은 여전히 ​​남아 있습니다. C++와 함께 Flutter를 사용하려면 Dart 팀의 FFI 미리 보기에 참여하고 우리 모두에 대한 지원을 개선하는 데 도움을 주셔야 합니다 😃

이 문제는 언어 기능에 관한 것이며 UI 위젯 API 디자인과 혼합되어서는 안 됩니다.

@atsushieno 물론입니다. 그렇기 때문에 이 토론이 Dart FFI 포럼에서 더 생산적일 것입니다... Flutter는 프레임워크입니다. 다트는 언어입니다.

다음 Obj-C 클래스의 용이성과 비교할 때 둘 다 특히 매력적이지 않습니다.

@MarkIngramUK 이것이 Dart 팀이 https://groups.google.com/forum/#!forum/dart -ffi에서 보고 싶어하는 피드백과 정확히 일치한다고 확신합니다.

C++의 SDK 및 애플리케이션을 위한 C++ 부트스트랩 프로젝트인 ezored(https://ezored.com)라는 프로젝트가 있습니다. 모바일 프로젝트(Android 및 iOS)에서 사용하고 있습니다. FFI가 완료되어 기본 SDK를 flutter로 사용할 프로젝트를 만들기를 기다리고 있습니다.

기본 구현(poco 프로젝트, openssl, sqlite, 특정 플랫폼 코드 통합 브리지 코드 등).

내 선택에는 이것이 가장 좋은 방법입니다.

• C++ 백엔드가 있는 iOS 및 Android(ezored)
• Flutter 및 C++를 백엔드로 사용

자유롭게 프로젝트에 시작을 추가하세요 :)

Kotlin Multiplatform은 완벽한 생각이 아니라 해결 방법이 될 수 있습니다. 아직 https://github.com/dart-lang/sdk/issues/34452 를 기다려야 합니다.

Unity3d는 C# VM[1]을 기반으로 하는 엔진에 플러터를 어떻게든 이식하고 있는 것 같습니다. 그 세계에서는 C#과 C++ 간의 대화가 적절합니다. 그들이 어떻게 일부 문제를 해결했는지 그들의 리포지토리를 살펴볼 가치가 있습니다. 그들은 "UIWidget은 주로 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 넵! 그러나 Oboe 인터페이스가 C++로 되어 있기 때문에 일부 C 래퍼를 작성해야 합니다.

시작 지침은 https://github.com/flutter/flutter/wiki/Binding-to-native-code-via-FFI 에서 확인할 수 있습니다.

https://github.com/atsushieno/oboe-sharp/tree/master/native 가 작동하는 경우 C# 바인딩에 대해 작성한 oboe-c.so 를 재사용할 수 있습니다.

@sjindel-google, 멋진 소식입니다!

따라서 클래스와 함수를 만들어 C++와 C 코드 사이에 다리를 만들어야 합니다. 그런 다음 해당 클래스를 사용하고 Dart 코드에서 해당 함수를 호출할 수 있습니다. 맞다고 생각합니다.

@atsushieno님 , 감사합니다. 살펴보고 있습니다. 내 경우에는 다리를 만드는 방법을 잘 모르겠습니다(경험 부족). 하지만 정확한 오보에 연주라는 전반적인 목표를 달성했습니까? 그게 그렇게 좋았어?

@rg4real 저는 대기 시간이 짧은 오디오보다 단순한 API(OpenSLES에 비해)를 위해 그렇게 하고 있었습니다. 내가 대기 시간에 대해 정말로 진지했다면 Xamarin.Android를 사용하지 않을 것입니다. 당신은 (뒤에 또는 AAudio) 오보에 대해 얘기한다면, 나는 그것을 사용합니까 Fluidsynth 그것은 잘 작동합니다. AAudio가 OpenSLES와 비교했을 때 "얼마나 좋은지" 확실하지 않습니다.

메모리 관리 방법에 대한 지침이 있습니까?

C++ 코드가 new/malloc을 사용하여 메모리를 생성하고 다트 코드로 반환하는 경우 해당 메모리를 해제하는 방법.

C++ 코드
무효 foo(char** out) {
*out = 새로운 char[25];
}

|out|에 할당된 메모리를 삭제하는 방법 다트 코드의 변수?

Dart 2.5를 사용 중이라면 .free() 에 Pointer .free() Pointer 있습니다. dev/master 브랜치에 있다면 이 방법이 package:ffi https://github.com/dart-lang/ffi/blob/master/lib/src/allocation.dart#L70으로 이동했습니다.

주석에 따라 - "[할당]과 동일한 방식으로 할당된 포인터에 대해서만 사용할 수 있습니다." - free()는 assign()메소드를 사용하여 메모리를 할당해야만 사용할 수 있다.

예
ffi.포인터ptr = ffi.포인터.할당();
ptr.free();

이것은 다트 코드에서 new 또는 malloc을 사용하여 C++ 측에 할당된 메모리를 해제하는 것을 처리합니까?

메모리가 malloc 통해 할당된 한 Dart 또는 C++를 통해 free 로 해제할 수 있습니다.

다트 2.6에서 우리는 사용 DynamicLibrary.lookupFunction("free") 정의 free 가 될 수 있도록, 다트 정확히 같은 free 프로그램의 C ++ 부분에있다. ( free 의 여러 버전을 바이너리에 연결하지 않는 한.)

이 기능이 이제 모든 Flutter 채널에서 일반적으로 사용 가능하므로(베타 버전) 이 문제를 종료합니다. 계속해서 문제를 개선하고 있습니다. 자세한 문제가 있는 경우 https://github.com/dart-lang/sdk/issues/new에 제출

C++ 클래스를 C 호환성으로 만드는 것은 지저분합니다. plz는 C++ 클래스를 직접 호출하는 기능을 만듭니다.

+1 C++를 지원할 수 있습니까?

@KaungZawHtet 및 @fzyzcjy - 이에 대한 새 발행(아마도 flutter보다는 dart-lang으로)을 여는 것을 고려하십시오.

이 문제를 잠그겠습니다. 많은 사람들이 구독하고 있지만 원래 목표는 꽤 명확하게 해결되었습니다.

예, 새로운 문제의 경우 다음 링크를 사용하여 제출하십시오. https://github.com/dart-lang/sdk/issues/new?labels=library-ffi ,area-vm