Flutter: Mendukung integrasi dengan C/C++ dalam kerangka plugin

@jason-simmons paling tahu tentang Gradle. Setelah kami memiliki .so, saya pasti dapat membantu memuatnya.

Saya memang menemukan bahwa di bawah buildSrc ada properti lain untuk mengatur versi gradle build. Setelah memperbarui ke 2.2.2 saya telah berkembang, dan dapat memverifikasi .so memuat, dan dapat dipanggil dari Java.

Agaknya kita juga perlu menambahkan C API untuk mengirim HostMessages dari kode C/C++ ke Dart.

Ya silahkan. Saya curiga bahwa panggilan balik C->Java mungkin tidak murah.

Ada pembaruan tentang ini? Mempertimbangkan Flutter untuk membangun aplikasi lintas platform yang memanggil kode C++ yang dikompilasi ke dalam pustaka bersama, dan ini adalah satu-satunya titik perhentian utama.

Ini mungkin hari ini (dan @jtrunick melakukannya di aplikasi pengirimannya), tetapi Anda harus memantul melalui Java atau Obj-C terlebih dahulu.

yaitu Anda dapat menggunakan https://flutter.io/platform-channels/ untuk berbicara dari Dart ke Obj-C/Java dan kemudian dari Obj-C/Java panggilan ke kode C++ Anda. Bug ini mencakup penambahan lebih banyak dukungan langsung untuk ini, dan berpotensi menghindari passthrough Obj-C/Java.

Karena Dart VM diimplementasikan dalam C++ bukankah seharusnya ada cara yang lebih mudah (jika kurang aman) untuk memanggil pustaka bersama C secara langsung (misalnya melalui dlopen)? Berapa banyak perubahan yang diperlukan untuk dukungan dasar (tidak aman/eksperimental)?

Apakah sesuatu seperti ini: https://www.dartlang.org/articles/dart-vm/native-extensions tersedia di android atau ios?

Kami telah mendengar persyaratan ini dari beberapa aplikasi Google:

• Salah satu aplikasi tersebut menulis pustaka C++ mereka sendiri untuk mengoperasikan kamera guna mengurangi latensi. Pustaka ini adalah platform khusus dan dioptimalkan untuk bekerja secepat mungkin. Memanggil pustaka ini dengan latensi serendah mungkin sangat penting untuk aplikasi semacam itu. Memaksa mereka untuk melalui PlatformChannel + JNI tidak akan mencapainya di Android.

• Ada tim seluler tingkat lanjut di luar sana yang menulis komponen logika bisnis di C++ untuk dapat membagikannya antara implementasi Android dan iOS mereka. Flutter yang mendukung integrasi langsung dengan library tersebut akan semakin memperkuat posisinya sebagai framework lintas platform terbaik di luar sana.

Saya tidak berpikir ini adalah _harus memiliki_. Namun, ini adalah satu area yang Flutter dapat membedakan dirinya lebih jauh dari solusi lintas platform lainnya.

Salah satu aplikasi tersebut menulis pustaka C++ mereka sendiri untuk mengoperasikan kamera guna mengurangi latensi. [...] Memaksa mereka untuk melalui PlatformChannel + JNI tidak akan mencapainya di Android.

Apa solusi mereka di Android untuk beralih dari C++ ke Java dan kembali?

Jika benar-benar diperlukan, kami dapat mengizinkan ekstensi asli Dart di platform seluler. Saat ini, kami tidak mengekspos simbol di dart_api.h . Kita perlu memutuskan hal-hal berikut sebelum kita dapat membalik sakelar:

• Cari tahu cara membuat kompiler AOT mengetahui kode Dart yang satu-satunya titik masuknya adalah dari metode yang mungkin tidak ada di pustaka dinamis mesin Flutter utama. Jika tidak, pass goyang pohon dapat menghilangkan kode.
• Berikan panduan tentang membuat dan mengemas ekstensi asli (Gradle & Xcode untuk Android & iOS masing-masing).
• Berikan beberapa jaminan stabilitas ABI untuk rutinitas di dart_api.h . Meskipun sebagian besar stabil, saya percaya itu masih berkembang untuk memperhitungkan berbagai mode.

Sejauh ini, mekanisme saluran platform tampaknya sudah memadai untuk kasus penggunaan yang lebih sederhana.

Apa solusi mereka di Android untuk beralih dari C++ ke Java dan kembali?

Saya belum melihat secara mendalam ke dalam kasus penggunaan mereka. Tampaknya mereka telah menulis semua bit yang membutuhkan komunikasi dengan latensi sangat rendah di C++. Saya akan bertanya apakah mereka menggunakan JNI untuk kasus penggunaan yang kritis terhadap kinerja (firasat saya tidak).

Itu sangat tergantung pada apa yang bisa kita lakukan di sisi Flutter. Jika kami dapat menyediakan interop yang jauh lebih cepat daripada JNI, itu akan menjadi kemenangan besar bagi tim-tim ini. Mereka dapat mengecilkan basis kode C++ dan menggeser lebih banyak ke sisi aplikasi. Jika kinerja interop kami sebanding dengan JNI maka saya tidak melihat kemenangan besar di sini. Mereka mungkin dapat melanjutkan apa yang mereka lakukan sekarang dan menggunakan PlatformChannel.

Ini tentang memberi tim semacam itu alasan tambahan untuk beralih ke Flutter. Saya belum pernah mendengar ini menjadi pemblokir, jadi prioritaskan dengan tepat.

Jika saya mengerti apa yang Anda katakan dengan benar, Anda mengatakan solusi saat ini adalah memiliki semua logika (kamera+UI) di C++ dengan logika minimal di Jawa, dan keinginannya adalah untuk memindahkan bagian UI dari logika ini ke Dart, tanpa kehilangan UI latensi rendah<->interaktivitas kamera.

Bisakah Anda berbicara tentang seperti apa situasi threading mereka? Apakah mereka hanya memiliki satu utas untuk kamera+UI?

@chinmaygarde mungkin membuat kita lebih dekat untuk menyelesaikan ini dengan pekerjaannya saat ini di API embedder.

+1

Ada kemajuan dengan masalah ini?

Kami telah menggunakan jin untuk berbagi logika di berbagai platform. Akan lebih bagus jika kita dapat memiliki interop antara Dart dan C++, daripada harus bolak-balik melalui Java/Objc-C.

Jika Dart dapat berintegrasi dengan C/C++, saya pikir itu ide bagus untuk seluler menggunakan kembali banyak perpustakaan asli dan tidak perlu mengikat ke platform tertentu menggunakan JNI atau Objective C++.

Sudahkah Anda mempertimbangkan https://github.com/mono/CppSharp? Mereka sudah memiliki parsing dan AST untuk c++, serta dukungan untuk beberapa bahasa target. Mungkin Anda bisa membuat generator Dart untuk CppSharp?

Mengintegrasikan database berbasis C++ seperti Realm secara langsung di C++ akan mencapai kinerja yang signifikan dan peningkatan produktivitas pengembang :-) Naik/turun melalui JNI akan sia-sia.

Saya sedang mempertimbangkan Flutter untuk aplikasi AR yang melakukan visi komputer (mungkin menggunakan OpenCV), dan interop Dart-C++ yang efisien dan langsung akan menjadi poin positif utama. Saya membayangkan banyak orang lain yang melakukan aplikasi yang menantang dalam hal komputasi mungkin berbagi kebutuhan ini.

Bisakah Anda mengonfirmasi bahwa interop C++ masih belum tersedia? Apakah bisa menggunakan paket?

@tofutim Interop c/c++ langsung masih belum tersedia maka mengapa masalah ini masih terbuka. Namun, Anda dapat menggunakan saluran platform dan kemudian menggunakan Obj-C/Java untuk berinteraksi dengan kode C++ Anda. Ini tidak bagus tapi hanya itu yang kami miliki saat ini.

Bisakah Anda mengonfirmasi bahwa interop C++ masih belum tersedia? Apakah bisa menggunakan paket?

Untuk beroperasi dengan perpustakaan platform, mekanisme saluran platform masih menjadi rekomendasi saat ini.

Mekanisme yang lebih berkinerja yang dijelaskan dalam dokumen ekstensi asli dapat ditambahkan dengan mudah. Namun, saya tidak mengetahui adanya jaminan stabilitas ABI untuk simbol yang diekspos dari dart_api.h . Jika @a-siva dan @eseidelGoogle dapat mengonfirmasi bahwa jaminan tersebut ada, saya dapat mulai mengekspos simbol tersebut secepatnya. Secara opsional, kita kemudian dapat mengukir subset Tonic sebagai pembungkus yang nyaman di sekitar C API untuk kemudahan penggunaan dari C++.

Pemahaman saya adalah bahwa bug ini adalah tentang menyediakan C-API dan kait perkakas untuk memudahkan memiliki plugin C/C++ sepenuhnya (tidak diperlukan shimming Obj-C/Java, tetapi masih asinkron melalui platform_channels).

Saya tidak berpikir kita harus mempertimbangkan metode sinkron seperti ekstensi asli saat ini. (Tapi sejujurnya saya menunda itu ke @Hixie atau @cbracken).

@eseidel

Saya tidak berpikir kita harus mempertimbangkan metode sinkron seperti ekstensi asli saat ini

mengapa demikian?

Pendekatan saat ini untuk memanggil kode C adalah Dart -> Java -> C
Kita melewati JNI dua kali, kan?
pertama kali: dart ke Java melalui saluran platform (di bawah kap panggilan JNI digunakan, kan?)
kedua kalinya: Java -> C melalui JNI

Sebagai contoh, dari sudut pandang kebutuhan proyek saya, memiliki akses ke dart_api.h bahkan tanpa jaminan stabilitas (sebagai fitur eksperimental misalnya) sudah cukup baik. Perhatian utama saya adalah memindahkan gumpalan besar data biner (gambar) dari sisi Dart ke sisi C dan kembali tanpa menyusun dan idealnya menyalin. Unity/Mono mencapai itu .

Dari masalah dart-sdk 31960 Saya mengerti bahwa implementasi isolat saat ini mungkin tidak memungkinkan untuk melewatkan data tanpa menyalin (walaupun secara teori dimungkinkan untuk mendeteksi bahwa buffer yang dibuat di isolat A tidak digunakan lagi setelah diteruskan ke isolat B dan oleh karena itu kepemilikannya dapat dialihkan, tanpa menyalin.. rencana apa pun di bagian depan itu?), tetapi jika setidaknya dalam isolasi tidak ada marshalling ke/dari C itu akan baik.

Marshalling dapat dihindari dengan flatbuffers yang tampaknya akan segera mendarat: https://github.com/google/flatbuffers/pull/4676
Atau dengan pesan protobuf menggunakan bidang hanya byte tunggal.

Tentu saja, ini memerlukan penyalinan byte dalam jumlah besar sehingga tidak bagus untuk semua kasus penggunaan.

Saya mendengar setidaknya tiga keinginan berbeda yang disajikan di sini:

1. Ingin cara untuk dengan mudah menulis plugin untuk Flutter hanya menggunakan kode C/C++ tanpa harus menambahkan banyak lem Java/Obj-C (itulah pemahaman asli saya tentang bug ini dan sesuatu yang saya pikir bisa/harus kita lakukan) .
2. Ingin cara untuk memindahkan volume besar data masuk/keluar dari Dart dengan cepat/dengan latensi rendah/dll. (Mungkin dari berbagai bahasa, termasuk C++. Ini terdengar seperti kasus yang sangat valid! Saya sangat menyarankan untuk mengajukan bug terpisah termasuk sebuah contoh.)
3. Ingin cara untuk memperluas Dart dengan panggilan/objek sinkron? (mis. ekstensi asli atau metode lain? Ini juga sepenuhnya dapat dilakukan. Ada potensi kesulitan seputar stabilitas API, dan saya rasa kami ingin mempelajari lebih lanjut tentang kasus penggunaan khusus sebelum mengambil tindakan.)

Umpan balik saya dari membaca di atas adalah bahwa kita harus mempertimbangkan untuk membagi beberapa bug tambahan. Kami pasti perlu menginvestasikan beberapa di sekitar C++ inter-op, tetapi sulit untuk menentukan dari utas panjang ini untuk kasus penggunaan yang tepat yang harus kami tangani dan dalam urutan apa?

Apakah pihak yang berkepentingan bersedia/mampu mengajukan bug baru dengan kasus penggunaan yang diinginkan dan menautkannya kembali ke sini? Senang membiarkan masalah ini terbuka untuk melacak minat umum dalam ruang masalah ini.

Sehubungan dengan kinerja dan 2. di atas: Meskipun saya yakin bahwa kinerja platform_channels Flutter dapat ditingkatkan (dan bahwa kami mungkin memerlukan metode plugin/inter-op lain untuk mencakup semua kasus penggunaan), kami akan menginginkan beberapa kasus penggunaan (mungkin ada dan saya belum melihatnya?) di mana kinerja platform_channels Flutter adalah hambatan sebelum kami mengambil tindakan. Pengalaman saya dengan mengoptimalkan kinerja sistem adalah bahwa insting saya sering salah. Meskipun hal-hal seperti JNI atau platform_channels terasa seperti potensi kemacetan, kami tidak akan benar-benar tahu sampai kami mengukurnya.

Sekali lagi terima kasih atas bantuan dan umpan balik Anda!

Ingin cara untuk dengan mudah menulis plugin untuk Flutter hanya menggunakan kode C/C++ tanpa harus menambahkan banyak lem Java/Obj-C (itulah pemahaman asli saya tentang bug ini dan sesuatu yang saya pikir bisa/harus kita lakukan) .

itu juga akan memberikan integrasi sqlite yang lebih baik untuk flutter + ada banyak perpustakaan C / Rust untuk crypto, ssh, dan hal-hal lain. Akan keren untuk bisa menggunakannya dengan mudah.

@eseidel

Saya mendengar setidaknya tiga keinginan berbeda disajikan

Suara saya untuk 1.)

Dari membaca dokumen Flutter, seharusnya cukup "sederhana" untuk memperluas Saluran Platform untuk mendukung C.
Satu-satunya hal baru yang mungkin akan menjadi cara memuat _dynamic shared object_(s) ke dalam proses saat ini.

Saya akan membayangkan _Android-C_-usage terlihat seperti:

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

Secara konseptual, setidaknya untuk _Android-C_, Anda harus memutuskan bagaimana menangani kombinasi Java dan C.

@eseidelGoogle
Saat ini kami mengekspos kode golang melalui Java dan pembungkus Swift dan latensi adalah masalah yang cukup besar yang kami hadapi.
mengapa ?

• Kita perlu berbagi logika bisnis di antara banyak platform.
• Untuk fungsionalitas video dan gambar seperti berbagi layar.
• Untuk DB.

Jika Anda dapat menambahkan dukungan golang di tingkat langsung, itu akan membuat perbedaan besar!
Mengkompilasi kode golang untuk seluler juga sangat mudah tanpa keajaiban LDFLags, jadi saya pikir itu akan populer. Saya tahu beberapa pembuat kode golang lain yang saat ini juga menggunakan Saluran Metode.
Sejauh serialisasi kami saat ini menggunakan Protobufs dan flatbuffers.

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

Di fuchsia ini dilakukan dengan FIDL dan memiliki binding ke c, rust dan golang.
Ini cukup mengagumkan untuk digunakan dan saya telah menikmati mencoba karat dan golang pada papan tertanam.

Seharusnya dimungkinkan untuk mengekspos hal-hal fidl melalui iOS dan Java juga.
Itu akan memberikan onramp yang bagus antara fuchsia dan flutter di ponsel dan desktop.
Hanya ide yang saya mainkan

@eseidelGoogle
Hiixe memberi tahu saya bahwa FIDL tidak dapat dilakukan di level Flutter karena FIDL bergantung pada kode kernel dari zirkon di Fuchsia. Jadi satu-satunya cara untuk mereplikasi fungsionalitas gaya FIDL IPC dalam Flutter adalah dengan menulis versi FIDL ke dalam mesin Flutter. Tapi kemudian saya bermain-main dengannya dan memperhatikan bahwa itu sangat mirip dengan Flatbuffers. JADI mengapa tidak menggunakan FlatBuffers saja untuk lapisan serialisasi antara Flutter dan cpp atau golang atau lapisan karat pada Flutter. ?

Cukup beri +1 pada ini, kami memiliki aplikasi flutter menggunakan perpustakaan yang disebut Superpowered. Superpowered ditulis dalam C++, kami kemudian menggunakan hal-hal jenis java dan JNI untuk berinteraksi dengannya, yang pada gilirannya kami menggunakan saluran platform untuk berbicara dengan kode Java. Pasti akan menyenangkan jika kita bisa melewatkan orang tengah.

Ini juga dengan menahan perpustakaan seluler populer seperti Realm dari membuat versi flutter karena intinya ditulis dalam C/C++ dan mereka juga tidak ingin berurusan dengan perantara Java/objc/swift.

Untuk alasan itu, selain stabilitas umum, saya pikir masalah ini adalah salah satu perubahan yang paling dibutuhkan dalam flutter saat ini. (Lebih khusus #1 di daftar @eseidelGoogle .)

Jika Anda ingin mendengar argumen untuk melewati Java/JNI dalam ekstensi platform (yaitu, tidak hanya menyembunyikan/mengotomatiskan lapisan lem Java untuk pengembang), Superpowered memiliki banyak hal untuk dikatakan tentang topik itu: https://www.youtube. com/watch?v=LzIuir3r6Co

@pnico Bisakah Anda menjelaskan bagaimana argumen ini bahwa Java/JNI harus di-bipass? Tampaknya mengatakan sedikit lebih dari kode pemrosesan audio Anda harus ditulis dalam C++. (Itu tidak berarti Anda tidak dapat menyebutnya melalui JNI atau dengan cara lain apa pun)

@csga5000 Anda benar sekali, itu tidak masuk akal :D JNI mungkin tidak akan benar-benar memengaruhi kinerja kecuali Anda mencoba melakukan lebih banyak hal esoteris. Saya kira itu benar-benar turun ke kenyamanan/pemeliharaan, dan saya kira mungkin kemampuan untuk memindahkan lebih banyak kode khusus aplikasi dari Java/C++ dan ke Dart

Saya pikir @pnico mengatakan bahwa dia BISA menyebutnya melalui JINI, tetapi JINI menambahkan terlalu banyak latensi.
Jadi perf adalah masalahnya.
ya Tidak ??

Yang ini mungkin membuat perbedaan besar sebagian besar untuk pekerjaan terkait crypto.

Saya juga berasumsi untuk Android Things, meskipun saya belum melihat atau membuat eksperimen
dan tolok ukur untuk gpio sensitif waktu baik di c maupun dart selama lebih dari a
tahun.

Pada Sabtu, 9 Juni 2018, 10:52 Eddy WM, [email protected] menulis:

Yang ini mungkin membuat perbedaan besar sebagian besar untuk pekerjaan terkait crypto.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/flutter/flutter/issues/7053#issuecomment-395927258 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AFHMcSI2JDHbgv3iYrStDN5mlzkQ8XEkks5t6xxMgaJpZM4K-PLw
.

Ada kemajuan sejak itu?

Sampai masalah ini diselesaikan, apakah ada rekomendasi untuk contoh plugin flutter yang menunjukkan cara mengintegrasikan ac/c++ lib? Apakah jinni cara yang baik untuk pergi?

Sampai diselesaikan, satu-satunya cara untuk mengintegrasikan c/c++ menulis kode android & ios asli, kemudian menghubungkan ke kode dart menggunakan saluran platform

Saya telah menerapkan plugin yang menggunakan saluran platform (untuk file jar dan CocoaPods). Saya mencari contoh plugin yang menunjukkan cara mengintegrasikan ke lib c/c++ yang sama (untuk Android dan ios). Ada rekomendasi?

@ mmcc007 Begitulah cara Anda melakukannya di Java atau 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

Anda dapat melihat bagaimana superpowered merekomendasikan Anda melakukannya jika Anda benar-benar menginginkan contoh (itu hanya satu yang saya tahu): https://github.com/superpoweredSDK/Low-Latency-Android-iOS-Linux-Windows-tvOS-macOS- Platform-Audio-Interaktif
Lihat folder contoh. Misalnya, dalam https://github.com/superpoweredSDK/Low-Latency-Android-iOS-Linux-Windows-tvOS-macOS-Interactive-Audio-Platform/tree/master/Examples_Android/SuperpoweredRecorder/app/src/main ada java/com/superpowered/recorder/MainActivity.java yang mereferensikan kode di cpp/RecorderExample.cpp

@csga5000 Sepertinya cukup lurus ke depan.. pada ulasan pertama. Masih akan menyenangkan untuk melihat melalui plugin flutter yang berfungsi. Terima kasih.

+1 untuk ini. Setiap contoh kerja dari aplikasi flutter yang menggunakan c++ akan diterima dengan baik

Ada proyek yang melakukan ini untuk golang dan saya pikir pendekatan yang sama
dapat digunakan untuk c++ juga.

Program golang menggunakan jsonrpc.
Maka yang perlu Anda lakukan adalah membuka kode golang Anda sendiri dengan jsonrpc.

Maka semuanya sangat mudah.

Saya pikir saluran platform HANYA mendukung JSON sebagai serialisasi agnostik
format?

Pada Rabu, 18 Jul 2018, 16:50 Jefferson Bledsoe, [email protected]
menulis:

+1 untuk ini. Contoh kerja aplikasi flutter apa pun yang menggunakan c++ adalah
diterima dengan baik

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/flutter/flutter/issues/7053#issuecomment-405958345 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/ATuCwkPbb9vLdoaEwM-bLhYPZxtyQ5Vjks5uH0sqgaJpZM4K-PLw
.

Hai, ada kabar?

Hanya ingin tahu apakah ada orang di utas ini yang berhasil mengintegrasikan perpustakaan Superpowered langsung ke aplikasi flutter?

Ya @skills-up kami telah melakukannya. Hanya saja tidak dalam proyek sumber terbuka jadi saya tidak bisa menunjukkannya. Tapi jika Anda melihat tips saya sebelumnya, begitulah cara Anda melakukannya. Anda mungkin perlu membuat aplikasi flutter untuk setiap arsitektur CPU

Saya mengerti Anda telah melakukannya melalui JNI/Java dan tidak langsung dari dart. Saya bertanya-tanya apakah mungkin untuk menghindari kode khusus platform sama sekali.

Anda mungkin perlu membuat aplikasi flutter untuk setiap arsitektur CPU

Maksud Anda aplikasi terpisah untuk setiap arsitektur, atau hanya menentukan semua arsitektur yang didukung?

BTW, kami sudah memiliki aplikasi yang berfungsi yang ditulis secara native di Java. Namun, sekarang kita harus membuat aplikasi iOS juga, saya bertanya-tanya apakah membuatnya dalam flutter (daripada mengeluarkan upaya pada Swift/XCode) akan lebih masuk akal dari perspektif pemeliharaan di masa depan, dengan manfaat dari satu basis kode.

Sehat. Realm menunggu kalian untuk memberikan jalan: https://github.com/realm/realm-object-server/issues/55

lukaspili : Saya kira semua orang masih menunggu: flutter/flutter#7053
bmunkholm: @lukaspili Ya itu prasyarat pasti.

Untuk apa nilainya, saya juga menunggu ini. Tidak dapat benar-benar melihat untuk mengganti aplikasi XF dengan flutter ditto sampai kalian mendapatkan pipa ledeng yang tepat. Saat ini berdiri, pukulan Xamarin bergetar keluar dari air di departemen ini.

Terlambat ke pesta ini tetapi +1 besar untuk utas ini.

Saya mengembangkan aplikasi desktop, pandangan saya sebagai baris kode (untuk desktop):

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

Jika Flutter dapat menawarkan dukungan kelas satu untuk C++, saya pikir pendekatan umum itu bisa menjadi pemenang mutlak untuk pengembangan aplikasi lintas platform, bukan hanya "pertama seluler" tetapi yang pertama di dunia. Qt mahal untuk pengembang kecil, berpendirian dan tidak merangkul C++ modern dan tidak ada yang benar-benar bersaing, dapatkah Flutter memakan setidaknya sebagian dari kue UI-nya?

PS: Saya bukan anti-Dart, ini C#/Go/Rust/etc baru. bahasa pesaing yang mungkin sangat produktif untuk platform baru tetapi dunia aplikasi desktop berkinerja tinggi (minat saya di sini) sangat C++, dengan dukungan OS dan perpustakaan yang luas, bahasa yang bergerak maju dengan kecepatan knot itu sendiri (bukan C), dan saya pikir Flutter layak mendapatkannya!

Saya tidak berpikir flutter akan mendukung C++ kapan pun dalam waktu dekat, dan itu tentu saja tidak mungkin sekarang. Dan saya sangat menyukai Dart - menulis aplikasi dalam C++ bahkan dengan flutter akan membutuhkan lebih banyak usaha. Dan saya tidak berpikir C++ secara langsung diterjemahkan ke dukungan desktop, mereka masih harus menulis sedikit kode, dan VM dart akan tetap berfungsi untuk desktop. Saya pikir kinerjanya dapat diabaikan untuk sebagian besar aplikasi.

Saya pikir pada akhirnya google ingin mendukung interoperabilitas sehingga Anda dapat menulis aplikasi flutter untuk semua dan semua platform menggunakan bahasa yang didukung atau bahkan kombinasi bahasa tersebut. Tapi saya tidak berharap itu sampai kapan atau setelah Fuchsia dirilis. Untuk saat ini, tujuan mereka adalah membuatnya mudah untuk menulis kode satu kali. Dart cocok dengan tujuan itu karena mudah digunakan/dipelajari, efisien, dan salah satu bahasa google. Saya benar-benar melihat hampir tidak ada keuntungan praktis bagi rata-rata pengguna yang memiliki dukungan C++ kelas satu. Performanya dapat diabaikan di aplikasi seluler, dan menggunakan saluran platform dengan C++ akan nyaman untuk tujuan berinteraksi dengan pustaka C++ yang ada. Sisi baiknya, Anda dapat yakin bahwa mereka pada akhirnya berniat untuk bergetar untuk mendukung desktop (setidaknya kapibara Fuchsia, tapi saya ragu mereka akan berhenti di situ).

Utas ini tentang mendukung integrasi langsung dengan C++ dari dart/flutter, yang diharapkan dapat hadir dalam waktu dekat.

Saya tidak berpikir flutter akan mendukung C++
Saya benar-benar melihat hampir tidak ada keuntungan praktis bagi rata-rata pengguna yang memiliki dukungan C++ kelas satu.

Ini bukan tentang seberapa hebat Flutter/Dart vs C++, ini lebih tentang titik/kemudahan integrasi yang Anda butuhkan agar sesuai dengan ekosistem saat ini. Daftar panjang perpustakaan ada sebagai objek bersama (OpenCV untuk menyebutkan satu) yang merupakan standar industri, Anda tidak dapat mengharapkan orang untuk menulis ulang mereka di Dart?

Performanya dapat diabaikan di aplikasi seluler, dan menggunakan saluran platform dengan C++ akan nyaman untuk tujuan berinteraksi dengan pustaka C++ yang ada.

Justru sebaliknya, menggunakan saluran kurang optimal dalam konteks ini, pikirkan tentang kasus penggunaan di mana Anda perlu bekerja dengan objek biner besar pada memori (gambar), Anda perlu:
1- Salin binari ini dari/ke memori C++
2- Bekerja dengan JNI untuk berinteraksi dengan perpustakaan (dan menangani pointer yang dialokasikan secara dinamis ke binari ini)
tidak menyebutkan biaya serialisasi/deserialisasi nilai/parameter yang Anda keluarkan dengan menggunakan saluran.

Kerangka kerja yang baik adalah keseimbangan antara fitur/paradigma baru yang diperkenalkan vs betapa mudahnya berintegrasi dengan ekosistem/warisan saat ini, yang tidak dapat kami sangkal adalah bagian dari C++.

@nhachicha @csga5000 tidak setuju bahwa mengintegrasikan C++ secara langsung itu penting; dia membalas komentar sebelumnya yang menanyakan apakah Flutter dapat langsung digunakan dari C++ , seperti, tanpa memerlukan kode Dart apa pun.

Performanya dapat diabaikan di aplikasi seluler, dan menggunakan saluran platform dengan C++ akan nyaman untuk tujuan berinteraksi dengan pustaka C++ yang ada.
@nhachicha Saya sangat setuju.

Sebenarnya untuk aplikasi yang tidak membutuhkan kinerja menggigit gigi (yang banyak) lalu mengapa tidak menukar yang sulit untuk menguasai C++ untuk sesuatu yang lebih produktif, sebenarnya mengapa berhenti di Dart saja, mengapa tidak memasukkan salah satu dari yang super populer ini, ( banyak bahasa yang lebih populer/mapan daripada Dart):

• C#/.Net Core runtime
• Javascript/Typescript V8 runtime (Anda hampir memiliki browser pada saat itu tetapi jadi apa)
• Karat (juga cepat!)
• GoLang
• Python
• [Masukkan favorit Anda di sini]...

Dan sebanyak saya pribadi menyukai dan menggunakan beberapa bahasa tersebut setiap hari, C dan C++ adalah inti dari Linux oleh karena itu Android, iOS, dan platform desktop seperti Windows, MacOS, dan desktop lainnya. Setengah dari bahasa di atas (termasuk Dart) ditulis dalam C++. Teknologi mutakhir berkali-kali membutuhkan kinerja asli yang disetel, seperti AI (Tensorflow adalah C++, Caffe C++, Pytorch adalah C di bawah Python, dll.), Pustaka Augmented Reality, mesin game AAA, dan apa pun yang perlu mendekati GPU (CUDA , dipanggil dari C/C++).

Untuk alasan yang sama bahwa mesin rendering Flutter itu sendiri ditulis dalam C++ (asli, kinerja tinggi, baterai/memori/cpu efisien), saya pikir akan sangat baik untuk membuka kunci kinerja terbaik, bila diperlukan, tanpa mendekati runtime terkelola dan hanya mendukung C++. Ini akan membedakan Flutter dari kerangka kerja lain seperti Xamarin dan Nativescript, yang sejujurnya menawarkan pengalaman pengembangan yang serupa (setelah menggunakan keduanya) hanya dengan bahasa yang berbeda, mengapa tidak membuat flutter khusus daripada hanya "yang Dart"?

_Sebagai catatan tambahan, saya benar-benar di rumah dengan menulis semuanya dalam C/C++, dari validasi formulir hingga pixel shader tapi saya tidak berpura-pura itulah pandangan banyak orang yang melihat repo ini - dan itu karena saya menemukan C++ a bahasa yang sangat produktif - benar-benar pilihan pribadi._

Ini adalah salah satu alasan utama kita membutuhkan Integrasi C++

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

Ada dua cara langsung untuk melakukan integrasi C/C++:

• Menyediakan implementasi saluran metode di C++
• Berikan dukungan ekstensi asli Dart VM

Sayangnya, kedua hal ini memiliki kelemahan utama yang menghalangi kami untuk mengejarnya:

• Saluran metode adalah abstraksi overhead tinggi - sementara integrasi C/C++ diminta ketika interaksi overhead rendah diinginkan. Artinya metode saluran tidak akan benar-benar menyelesaikan masalah.
• Ekstensi asli Dart VM mengharuskan orang untuk menggunakan Dart VM C API - mungkin tidak diinginkan untuk memperkenalkan terlalu banyak dependensi eksternal, terutama mengingat fakta bahwa API tidak menua dengan baik dan memerlukan beberapa refactoring serius.

Tampaknya alternatif yang lebih diinginkan adalah pengenalan dart:ffi - komponen inti Dart VM yang memungkinkan untuk mengikat langsung ke kode asli memungkinkan orang untuk menulis sesuatu seperti:

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

Kami memiliki minat tertentu dalam menerapkan FFI seperti ini untuk waktu yang lama - saya berharap kami akan bereksperimen dengannya dalam waktu dekat, tetapi saya tidak akan berkomitmen pada jadwal yang konkret.

@kirbyfan64 Tepat sekali, @nailgilaziev , @bytesoftly Saya tidak mencoba mengatakan integrasi C++ tidak diperlukan, saya hanya mengatakan saya tidak berpikir ada banyak alasan/permintaan untuk membuat dukungan flutter C++ INPLACE dari dart - tetapi Saya tidak mengatakan bahwa integrasi tidak diperlukan. Apa yang dikatakan @mraleph terdengar cerdas bagi saya.

@mraleph Dartino memiliki implementasi serupa untuk FFI . Seberapa sulit untuk dibangkitkan?

@listepo bagian dari itu. Implementasi FFI Dartino sangat dinamis - ini bukan sesuatu yang kami inginkan untuk Dart 2 yang jauh lebih statis daripada Dart 1.

Terlambat dalam permainan, tetapi ini adalah kasus penggunaan lain: Kami ingin memasukkan file dan metode c dalam dart untuk tujuan kriptografi.

Yang kami harapkan adalah sebagai berikut:
1) Kode identik untuk iOS dan Android, yaitu tidak melalui lapisan ObjC atau JNI.
2) Semoga pelaksanaannya lebih efisien dibandingkan saat melalui misal JNI dua kali.
3) Kemungkinan untuk menggunakan kembali kode model dart di aplikasi Web tindak lanjut misalnya di AngularDart, atau aplikasi desktop tindak lanjut menggunakan proyek ini: https://github.com/google/flutter-desktop-embedding

Saya yakin apa yang kita inginkan paling dekat dengan poin 2 @eseidelGoogle yang disebutkan di atas. Adapun dukungan sinkron, saya menganggapnya sebagai "baik untuk dimiliki", karena fungsi asinkron tidak dapat digunakan dalam konstruktor, di mana orang mungkin ingin melakukan misalnya perhitungan hash cepat. Tetapi membiasakan diri dengan cara async Darts, dukungan sinkron tampaknya kurang penting daripada kemungkinan umum untuk mencapai poin 1)-3) di atas.

Menggunakan FFI seperti yang disarankan oleh @mraleph , apakah ini memungkinkan 1)-3) seperti pada komentar saya sebelumnya, atau apakah itu berarti kode yang berbeda diperlukan pada platform yang berbeda (Android, iOS, ...)?

@CryptUser jika kode C/C++ Anda sama di semua platform, kode Dart untuk memanggilnya melalui FFI juga akan sama di semua platform.

@mraleph Kedengarannya bagus! Mengingat bahwa masalah asli memiliki lebih dari 200 jempol, apakah ada peluang untuk meningkatkan prioritas ini?

@mraleph apakah ada masalah terbuka untuk FFI di Dart di suatu tempat?

@dnfield Saya baru saja mengajukannya https://github.com/dart-lang/sdk/issues/34452

Saya ingin sekali dapat menulis kode C/C++/Rust dan dapat menggunakannya melalui ffi

Contoh:

Saya menguji flutter pada tablet Android (Android 4.4).
bergetar berlari dengan cepat.
Tetapi ketika saya mencoba membaca 1000 baris dengan sqflite yang menggunakan saluran platform, itu sangat lambat.
alasannya: saya tidak bisa menggunakan pembaca kursor sqlite.

tetapi jika saya bisa menggunakan langsung perpustakaan sqlite, permintaan yang sama instan. (diuji dengan xamarin dan proyek Android asli).

Kami sedang mendiskusikan sekarang bagaimana cara terbaik untuk mendekati ini. Seperti disebutkan di atas di https://github.com/flutter/flutter/issues/7053#issuecomment-377711814 masalah ini memiliki banyak bagian dan mungkin perlu dipecah. :)

Tetapi kami telah menemukan beberapa insinyur yang tertarik untuk menjelajahi FFI (seperti yang tercantum di https://github.com/flutter/flutter/issues/7053#issuecomment-415161464). Fokus kami saat ini adalah mengeluarkan 1.0, tetapi setelah selesai, ini akan menjadi yang teratas dalam daftar. Sekali lagi terima kasih atas semua umpan balik Anda yang berkelanjutan. Kami akan memperbarui masalah ini ketika kami memiliki lebih banyak kemajuan untuk dibagikan.

Saya juga pengguna Matlab/Simulink. Saya dapat menghasilkan kode c/cpp khusus cpu yang sangat dioptimalkan. Saya ingin mengintegrasikan algoritma saya ke dalam flutter. Saya memiliki banyak algoritma pemrosesan gambar. Saya memerlukan generator pengikat untuk kode asli. Kalau tidak, saya akan melupakan semua pengalaman dart-flutter saya dan saya akan mulai belajar xamarin atau sesuatu yang cocok untuk saya.

Bisakah kita mempercepat kemajuan?

Sangat sulit untuk bekerja sama antara Dart dan C.

Proses yang terburu-buru tidak akan menghasilkan produk berkualitas baik. Ini akan siap ketika sudah siap. :-)

Proses yang terburu-buru tidak akan menghasilkan produk berkualitas baik. Ini akan siap ketika sudah siap. :-)

Nah, apa yang saya coba katakan adalah bahwa kami mungkin ingin meningkatkan prioritas sehingga kami dapat menempatkan lebih banyak sumber daya dan upaya untuk menyelesaikan ini. Anda tahu bahwa ada 1386 masalah terbuka yang sekarang menargetkan "Tujuan" yang akan "diperbaiki di tahun-tahun mendatang".

Setelah membaca utasnya sekali lagi, saya perhatikan bahwa

"Gol" mungkin salah tempat. :) @mraleph memiliki seseorang yang menjelajahi https://github.com/dart-lang/sdk/issues/34452 saat kita berbicara. Itu bagian dari solusi setidaknya.

Berikut adalah dokumen visi untuk FFI yang saat ini kami buat prototipe di sisi Dart.

Silakan lihat dan beri tahu kami pendapat Anda.

Saya tidak bisa mengatakan banyak tentang bagian FFI karena saya tidak pernah menggunakan yang seperti itu,
tapi saya ingin tahu seperti apa integrasi pub nantinya.

Bagaimana paket penerbitan ditangani yang menggunakan FFI?
Bagaimana cara menangani paket konsumsi yang menggunakan FFI?

@zoechi kita belum membahas integrasi pub .

Mereka seharusnya dapat bekerja mirip dengan plugin Flutter hari ini - termasuk platform/arsitektur sumber yang sesuai dan/atau binari yang dapat dikompilasi/ditautkan ke dalam aplikasi yang digunakan.

Dari perspektif pub, seharusnya tidak menjadi masalah besar - kecuali bahwa mungkin ada file biner yang lebih besar yang disertakan dalam paket.

Perlu ada beberapa pekerjaan yang dilakukan meskipun di sekitar ujung alat Flutter untuk mengintegrasikannya ke dalam proyek Flutter - mereka tidak akan benar-benar berfungsi sama seperti yang dilakukan plugin Android/iOS saat ini.

Haruskah integrasi pub dipindahkan ke masalah dart-lang/pub agar masalah ini lebih fokus?

Saya telah membaca 'vision doc' dan akhirnya saya melihat bentuk-bentuk melalui kabut.

Sementara itu saya merenungkan sesuatu yang jauh berbeda.

Yaitu dari (kembali) menggunakan Flatbuffers untuk membuat sesuatu seperti NativeChannels. Pada saat mengeksekusi (AOT) itu akan bermuara pada pointer lewat, sementara pada waktu dev itu akan membiarkan saya memanfaatkan alat yang ada untuk sisi "asli" yang ditulis tidak hanya dalam C/C++ tetapi juga ditulis dalam Go atau Rust.

Pendekatan message passing juga lebih sejalan dengan arsitektur berbasis aliran saat ini (Bloc, Rx). Ini juga menghilangkan kekhawatiran tentang manajemen memori, karena kompiler mungkin menghasilkan buffer cincin yang sesuai jika sesuai atau menganggap 'pembebasan panggilan' sederhana di mana panggilan perlu menyimpan data lebih lama.

Tapi sejujurnya saya akan menghargai segala bentuk ffi jika itu akan diintegrasikan dengan mulus ke dalam ekosistem Flutter (Fuchsia) dan biarkan saya menggunakan kode asli yang dioptimalkan cpu dari dalam aplikasi Dart.

@ohir apa yang Anda bayangkan akan menjadi solusi lain untuk beberapa masalah yang disajikan bug. Bug ini berkembang menjadi tujuan umum untuk semua yang terkait dengan C++. :/ Saya menduga (seperti yang telah saya catat di komentar sebelumnya) kita perlu memecah bug ini menjadi yang lebih kecil. Pekerjaan FFI mungkin bukan satu-satunya solusi yang kami bangun di ruang ini.

@eseidelGoogle ada kemajuan dalam hal ini? saat ini kami memiliki proyek yang perlu menerapkan tugas pemrosesan video berat yang mungkin dilakukan melalui ffmpeg， karena paket dart saat ini tidak dapat memberikan solusi yang layak， kami dengan sabar menunggu flutter untuk memanggil ffmpeg lib secara langsung.

Untuk aplikasi berbasis UI halaman-ke-halaman itu, sekarang flutter menurut saya benar-benar pilihan yang baik daripada beralih ke pekerjaan pengkodean ganda di Android dan ios， jika kita berada di 5 tahun yang lalu dengan peralatan yang begitu indah， seluruh industri Aplikasi mungkin diubah. Namun, keuntungan dari flutter saat ini tidak terlalu menarik bagi perusahaan yang bermigrasi ke sana, karena mereka sudah melakukan cukup baik dengan cara lama, tetapi untuk beberapa tugas non-UI, panah jauh di belakang persyaratan teratas.

itu tidak berarti bahwa anak panah tidak baik atau layak untuk tugas-tugas itu suatu hari nanti, tetapi dalam pandangan perusahaan TI normal yang mungkin dimasukkan ke dalam ekosistem flutter, yang mereka butuhkan adalah mengurangi biaya dengan menggunakan lintas- metode pengkodean platform hanya jika fitur paling keren dapat dicapai, seperti pemrosesan data sisi klien, video/audio, staf AR dll selama beberapa algoritma telah dilakukan melalui c/c++. sangat sulit bagi mereka untuk menerapkan kembali atau menemukan kembali menggunakan dart lang.

dan solusi utamanya adalah memperkenalkan cara langsung dan efisien untuk flutter untuk berkomunikasi dengan c++, saya bahkan berpikir ini adalah prioritas pertama dari hal "lintas platform", panah untuk staf UI sempurna, beberapa logika data normal juga bisa dilakukan di dart, tetapi jauh lebih baik untuk flutter untuk bergabung ke dalam ekosistem c++ yang lama tetapi masih aktif dan efisien daripada membangun kembali yang baru yang suci!

impian pengalaman pengkodean "lintas platform" yang nyata adalah staf UI panah dengan c ++ di belakang kap, tidak ada kode java sama sekali, tidak ada kode oc sama sekali. wahahaha, saya tidak sabar untuk melihatnya terjadi!

@smellbee Tidak bisakah Anda menggunakan baris perintah ffmpeg?

@smellbee Saya rasa saya bukan orang yang tepat untuk menjawab ini. @eseidelGoogle ada berita tentang ini?

@smellbee Tidak bisakah Anda menggunakan baris perintah ffmpeg?

ini adalah pekerjaan sisi klien, menggunakan ffmpeg lib untuk membuat bingkai video untuk menghasilkan aliran balik umpan balik instan, apakah mungkin menggunakan baris perintah?

@smellbee Saya rasa saya bukan orang yang tepat untuk menjawab ini. @eseidelGoogle ada berita tentang ini?

maaf untuk itu, saya mengetik "es" , dan itu otomatis selesai, saya tidak menyadarinya .... semoga @eseidelGoogle bisa melihatnya

Pekerjaan sedang berlangsung di sisi Dart - kami berharap dapat menyiapkan sesuatu pada Q1 2019.

Ini adalah fitur besar dan kami ingin melakukannya dengan benar: karena kami ingin membuatnya bekerja dengan baik di berbagai mode eksekusi untuk Dart, jadi harap bersabar saat kami mengerjakan detailnya.

Anda dapat mengikuti dart-lang/sdk#34452 yang melacak pekerjaan di sisi Dart.

Dart FFI akan memungkinkan untuk memanggil fungsi C dari Dart.
Tapi bagaimana dengan fitur C++ - kelas, wadah std, pointer pintar, pengecualian?
Bisakah kita mengharapkan kemungkinan untuk mengekspor kelas C++ ke Dart dengan boilerplate minimum?

Fitur lain yang cukup penting adalah dukungan asinkron - kemampuan untuk menjalankan kode C++ pada utas terpisah dan mengembalikan Future/Stream dari metode.

@t-artikov Tidak ada rencana saat ini untuk mendukung interoperabilitas C++ secara langsung. Ini terlalu rumit. Satu-satunya hal yang secara ergonomis dapat interop dengan C++ adalah C++.

Jika Anda tertarik dengan interop tingkat tinggi dengan C++ maka Anda perlu membangun lapisan interop Anda sendiri yang mengekspos C++ API Anda melalui C seperti API.

Fitur lain yang cukup penting adalah dukungan asinkron - kemampuan untuk menjalankan kode C++ pada utas terpisah dan mengembalikan Future/Stream dari metode.

Saya pikir ini dapat dibangun sebagai satu paket. Kami hanya harus memastikan bahwa kami menyediakan primitif yang tepat sehingga ini dapat dibangun.

Dart FFI akan memungkinkan untuk memanggil fungsi C dari Dart.
Tapi bagaimana dengan fitur C++ - kelas, wadah std, pointer pintar, pengecualian?
Bisakah kita mengharapkan kemungkinan untuk mengekspor kelas C++ ke Dart dengan boilerplate minimum?

Selama ada cara bagi C++ untuk memanggil dart， Saya pikir hal itu mungkin C++ menangani apa yang dikhawatirkan C++，dan berkomunikasi dengan dart dengan dipanggil atau dipanggil, tidak perlu mengekspos manipulasi tingkat rendah apa pun ke dart yang akan merusak kemudahan penggunaan dart.

Fitur lain yang cukup penting adalah dukungan asinkron - kemampuan untuk menjalankan kode C++ pada utas terpisah dan mengembalikan Future/Stream dari metode.

Dan dart sudah memiliki mekanisme asinkronnya， jadi， apakah sebuah thread berorientasi C++ atau tidak, tidak ada bedanya，selama bagian C++ dapat memanggil dart kapan pun dibutuhkan, dan "Isolate" dapat melakukan pekerjaan itu.

Itu menurut saya @mraleph , koreksi saya jika saya salah ;)

@mraleph
Sebenarnya, ada contoh interop C++ yang bagus dengan bahasa lain.
https://github.com/boostorg/python
https://github.com/ThePhD/sol2
https://github.com/dropbox/djinni
Saya harap Dart/Flutter akan menyediakan mekanisme serupa di luar kotak.

Jika Anda tertarik dengan interop tingkat tinggi dengan C++ maka Anda perlu membangun lapisan interop Anda sendiri yang mengekspos C++ API Anda melalui C seperti API.

Untuk memperjelas bagaimana pendekatan ini dapat diterapkan, dapatkah Anda menunjukkannya menggunakan kelas ++ berikut sebagai contoh:

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

Sehingga dapat digunakan dari Dart

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

@t-artikov keduanya boostorg::python dan sol2 sebenarnya menggambarkan poin saya dengan sangat baik. Perhatikan bahwa ini adalah pustaka C++ untuk beroperasi dengan bahasa lain, bukan sebaliknya. Dart FFI adalah cara Dart centric untuk memanggil C API, bukan cara C++ centric untuk memanggil Dart.

Untuk memperjelas bagaimana pendekatan ini dapat diterapkan, dapatkah Anda menunjukkannya menggunakan kelas ++ berikut sebagai contoh:

Anda harus menulis (atau menghasilkan dengan beberapa alat) sesuatu seperti ini.

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

Perhatikan bahwa ini adalah pustaka C++ untuk beroperasi dengan bahasa lain, bukan sebaliknya.

Anda salah, mereka mengizinkan untuk mengekspos kelas C++ ke bahasa lain.
https://www.boost.org/doc/libs/1_68_0/libs/python/doc/html/tutorial/tutorial/exposing.html

Terima kasih atas contoh FFI Dart Anda.
Ada beberapa kekurangan: pengecualian C++ harus diteruskan ke sisi Dart; dan MyObject.data tidak akan bekerja dengan cara ini (hanya mendapatkan pointer, tetapi bukan ukuran data).
Tapi idenya jelas.

Menurut pendapat saya, kode seperti itu terlalu bertele-tele untuk ditulis secara manual.
Saya menantikan untuk melihat apakah proses ini akan diotomatisasi untuk binding Dart FFI Flutter Engine yang baru.

Pengikatan run-time untuk interoperabilitas C++ hampir tidak mungkin (bagaimana Anda menangani obat generik, pewarisan berganda, kelebihan operator, nama yang rusak, dll...). Ada banyak upaya sulit (BridJ, CppSharp, dll), dan menurut pemahaman saya, orang-orang menganggap C interop sebagai opsi yang paling memungkinkan.

Tidak mungkin ada solusi yang sangat umum yang dapat dicapai oleh orang-orang pengembang interoperabilitas resmi untuk C++. Kotlin/Native tidak menawarkan itu. skala-asli yaitu. .NET baik (interop Microsoft C++ selalu aneh atau statis). JNI mendukung interop C++ hanya di mana kompilasi statis terlibat. Sesuatu seperti lem python boost perlu ditulis secara manual. Grup pihak ketiga mana pun dapat mengembangkan hal-hal seperti JNAerator (yaitu ANDA dapat melakukannya, tidak perlu mengharapkan tim Dart/Flutter untuk mencapainya).

Mengikuti percakapan ini tanpa jawaban nyata, saya pikir saya akan tetap menggunakan Qt yang merupakan Cross-Plattform dan memiliki Dukungan C++ penuh. Saya hanya berpikir untuk mencoba Flutter untuk proyek saya berikutnya, tetapi sekarang saya tidak mau, terima kasih banyak!

Akan lebih baik jika flutter ditulis dalam C++, yang memungkinkan interop dengan bahasa lain dengan mudah. Apakah ada upaya untuk menulis ulang flutter di C++?

Saya pikir diskusi semakin tidak perlu diperpanjang sekarang.

Kami tahu apa yang ada (atau tidak) pada peta jalan pengembangan flutter.
Oleh karena itu, kita dapat memutuskan untuk menggunakan (atau tidak menggunakannya) untuk kasus penggunaan tertentu.

Saya tidak melihat ada gunanya mencoba mengubah agenda pembangunan, atau
menuntut implementasi arsitektur tertentu, di luar titik ini.

Terima kasih,
Gaurav

Pada Senin, 25 Februari 2019, 22:51, [email protected] menulis:

Akan lebih baik jika flutter ditulis dalam C++, dengan
yang interop dengan bahasa lain akan dengan mudah mungkin. Adalah
adakah upaya untuk menulis ulang flutter di C++?

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/flutter/flutter/issues/7053#issuecomment-467098455 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AZ86acDpZgNeyezx40uxe_c5E2xZHWxaks5vRBumgaJpZM4K-PLw
.

Sebenarnya Flutter seperti yang saya tahu ditulis dalam C++ tetapi untuk pemrograman di Flutter hanya bisa dilakukan dengan interpreter Language Dart yang berjalan di VM. Tetapi Anda belum memiliki kesempatan untuk beralih dari Dart ke C++ Bagian dari Flutter...

Jadi siapa pun yang membaca ini dan memiliki kasus penggunaan umum dalam Pengembangan Aplikasi Pengembangan Lintas Platform yang baik, Flutter tidak akan mengizinkan penggunaan langsung C++ jika Anda membutuhkannya, lalu gunakan Kerangka Lintas Platform lain seperti Qt C++.

Bagi saya C++ sangat penting untuk Cross-Plattform-Development karena ini adalah common denominator terendah di hampir setiap teknologi.

@aqmappdesigners

juru Bahasa Dart yang berjalan di VM

Itu tidak akurat.

Flutter menggunakan Dart VM dalam mode debug, yang juga memungkinkan pemuatan ulang panas.
Dalam rilis build Dart dikompilasi ke kode biner seperti C++.

@zoechi Terima kasih, saya tidak tahu ini. Kedengarannya bagus untuk kinerjanya

Kedengarannya bagus untuk kinerjanya

dan merupakan persyaratan untuk Apples App Store.

Prototipe dart:ffi telah berkembang ke titik di mana kami memutuskan keputusan API. (Beberapa keputusan desain dibahas di sini .)

Untuk membuat keputusan desain yang tepat, kami ingin lebih banyak contoh tentang API C apa yang ingin Anda ikat. Sejauh ini masalah ini menyebutkan SQLite, Realm, OpenCV, Superpowered, dan ffmpeg. Adakah API lain yang harus kami pertimbangkan?

@dcharkes Saya tidak tahu apakah itu membantu, tetapi Telegram di Android melakukan jaringan di C++ melalui JNI:
https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/jni/TgNetWrapper.cpp
Ini juga menangani pemutaran GIF dengan ffmpeg, langsung menulis di Android Bitmaps:
https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/jni/gifvideo.cpp

Mungkin menarik untuk memiliki cara mengurai telepon dan alamat melalui libphonenumber dan libpostal untuk formulir pendaftaran. Juga glfw + flutter-embedder dan mungkin suatu hari kita akan melihat aplikasi desktop yang seluruhnya ditulis dalam dart.

+1 untuk SQLite dan Realm. Silakan lihat juga Couchbase , mereka memiliki inti C++ yang sama dengan C SDK.

Apakah api Firebase C++ akan menarik? https://firebase.google.com/docs/reference/cpp/

Tidak banyak melihatnya, tetapi berpikir bahwa mungkin dapat menggantikan plugin iOS dan Android dengan satu plugin yang berbicara dengan C++ secara langsung.

Beberapa perpustakaan crypto harus mendapatkan cinta seperti cincin dari karat - https://github.com/briansmith/ring

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

perpustakaan kriptografi. Terutama libsodium atau tink.

https://github.com/google/tink

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

Sudah ada perpustakaan flutter-sodium, ia berbicara melalui saluran platform ke pembungkus libsodium di setiap platform, lalu ke asli.

Pustaka pemetaan khusus seperti mapbox-gl https://github.com/mapbox/mapbox-gl-native

Penanganan SMTP/IMAP (untuk chat-over-email) untuk Flutter melalui https://github.com/deltachat/deltachat-core adalah sesuatu yang ingin saya gunakan secara langsung.

Jika saya terlalu berani untuk memparafrasekan, kasus penggunaan yang umum adalah seperti di bawah ini:

1. Akses perangkat keras audio/video latensi rendah (seperti, Superpowered)
2. Pemrosesan a/v yang dibantu perangkat keras (seperti, ffmpeg)
3. Akses soket berbasis TCP, untuk XMPP/protokol berorientasi jaringan lainnya
   (untuk obrolan, pemberitahuan push)
4. Peningkatan tingkat proses (akses root) / utas pemijahan di
   cara yang kompatibel lintas platform (untuk aplikasi sistem, multitasking, emulator)

Mungkin ada lebih banyak kasus penggunaan, tetapi ini adalah yang utama yang datang ke saya
pikiran.

Terima kasih semuanya telah memberikan contoh! Ini sangat membantu.

@skills-up perhatikan bahwa kami jauh lebih tertarik pada contoh konkret, daripada klasifikasi abstrak. Itu karena kami ingin menilai ergonomi FFI pada contoh nyata.

Anehnya, salah satu bahasa yang menawarkan antarmuka terbaik dari/ke C++ adalah Rust, melalui sistem pembangunan makro + yang kuat, meskipun memiliki pendekatan yang sama sekali berbeda untuk OO.

Saya akan mengatakan OpenSSL, karena kita perlu menandatangani permintaan sabun dan file xml secara digital (XMLDSig, Xades l) menggunakan sertifikat klien.
Dart sendiri memiliki BoringSSL, tetapi hanya sebagian saja yang terekspos melalui Dart. Jadi hal terbaik berikutnya adalah memanggil lib openssl asli dari flutter

Semoga saya tidak melakukan spam, tetapi saya juga ingin memiliki integrasi yang lebih baik dengan tensorflow lite, tidak melalui JNI, yang akan bagus untuk operasi video

Tidak terlalu memperhatikannya, tetapi berpikir bahwa mungkin dapat mengganti plugin iOS dan Android > dengan satu plugin yang berbicara dengan C++ secara langsung.

Selain mendukung C++, alangkah baiknya jika ada plugin yang bisa berbicara langsung dengan Go. Saat ini kita sedang berbicara dengan Go melalui saluran platform gomobile & flutter yang memperlambat responsivitas UI. Memiliki dukungan asli Go dan C++ di Flutter juga akan membantu kami mempertahankan basis kode yang seragam (logika bisnis/algoritma) untuk berbagai platform.

+1 untuk akses perpustakaan asli.

Saya ingin mengakses Vulkan/MoltenVK tanpa harus membuat saluran platform untuk Android/iOS dan memelihara dua plugin (yang juga akan sangat besar). Itu akan memungkinkan membangun aplikasi 3D dan merender menjadi widget Tekstur, sementara hanya berkembang di Dart. Saluran platform sepertinya solusi peretasan. Saya lebih suka mengakses perpustakaan asli tanpa harus menulis pembungkus untuk setiap platform dan memeliharanya setiap kali ada versi baru untuk perpustakaan itu.
Saya pikir fitur ini akan menarik lebih banyak pengembang.

Ya, tolong langsung akses perpustakaan asli dari flutter.
Saya ingin menggunakan beberapa perpustakaan c++ di flutter.

Ya, tolong langsung akses perpustakaan asli dari flutter.
Saya ingin menggunakan beberapa perpustakaan c++ di flutter.

Kami sekarang berada pada titik di mana kami ingin menawarkan pratinjau awal untuk mendapatkan umpan balik.

Untuk detailnya, silakan lihat pembaruan di bug pelacakan Dart .

@mit-mit Akankah ini membantu masalah ini: dapatkah saya menelepon atau menggunakan pustaka python dengan flutter ?

Terlambat ke pesta, tetapi memberi +1 untuk SQLCipher @dcharkes @mraleph

@doc-rj kami sekarang berada pada tahap di mana Anda harus dapat bereksperimen dengan mengikat SQLCipher dan memberi kami umpan balik tentang pengalaman Anda. Lihat komentar ini .

Saya ingin menekankan bahwa kami tidak benar-benar bertujuan untuk menyediakan sendiri binding perpustakaan tertentu - karena permintaan sangat beragam, tetapi kami bertujuan untuk memungkinkan semua orang dan siapa saja untuk mengikat ke perpustakaan apa pun dengan C API.

Saya kira kebutuhan untuk ini meningkat sekarang karena multi-platform telah diumumkan.

Apakah ini bagian dari peta jalan?

@felemedeiros pekerjaan sedang berlangsung - jika Anda memiliki perpustakaan yang ingin Anda ikat menggunakan FFI, saya sangat menyarankan untuk mulai mengerjakan binding untuk memberi kami umpan balik. Lihat komentar ini untuk info.

Tidak terlalu memperhatikannya, tetapi berpikir bahwa mungkin dapat mengganti plugin iOS dan Android > dengan satu plugin yang berbicara dengan C++ secara langsung.

Selain mendukung C++, alangkah baiknya jika ada plugin yang bisa berbicara langsung dengan Go. Saat ini kita sedang berbicara dengan Go melalui saluran platform gomobile & flutter yang memperlambat responsivitas UI. Memiliki dukungan asli Go dan C++ di Flutter juga akan membantu kami mempertahankan basis kode yang seragam (logika bisnis/algoritma) untuk berbagai platform.

Saya menulis artikel tentang bagaimana kami saat ini memanggil API perpustakaan Go dari Flutter. Mungkin berguna bagi seseorang yang tertarik. https://medium.com/@archan.paul/using -go-library-in-flutter-a04e3496aa05

Bagaimana saya bisa menambahkan kode c++ di aplikasi Flutter?

Bagaimana saya bisa menambahkan kode c++ di aplikasi Flutter?

Saya kira saat ini satu-satunya pilihan adalah mengambil C++ -> JNI (untuk Android) -> cara PlatformChannel sampai kita memiliki cara yang lebih elegan untuk melakukan hal yang sama!!

Saya membuat proyek bernama ezored (http://ezored.com). Akan lebih baik jika saya dapat meneruskan objek kompleks ke Flutter tanpa perlu mengonversi ke hal lain, karena sudah ada di Java dan objc. Siapa pun dapat menggunakan ezored untuk membuat SDK (atau mengunduh bawaan) untuk menguji integrasi Flutter antara native dan Dart. Ini memiliki permintaan, parsing, mentah menggunakan database dan banyak hal dalam demo SDK sudah diterapkan.

Saya mencari di grup flutter tetapi tidak memiliki cara untuk meneruskan objek dan daftar objek ke Flutter secara langsung.

Terima kasih dalam bantuan apa pun.

Ada kemajuan baru? Tampaknya lebih dari 2,5 tahun telah berlalu ...

@fzyzcjy kami sedang mengerjakannya. Kami telah merilis pratinjau awal. Lihat https://github.com/dart-lang/sdk/issues/34452#issuecomment -482136759 tentang cara terlibat.

Sejak pratinjau awal ini, kami telah menambahkan dukungan untuk Intel 32, Arm 64, dan Arm 32. Platform ini belum dirilis di stable atau dev, mereka hanya tersedia di cabang master Dart sdk. Kemajuan sedang dilacak di sini .

@dcharkes Sangat senang mendengarnya! Terima kasih atas pekerjaan hebat Anda!

Adakah peningkatan?

Untuk pembaruan status dan informasi tambahan, silakan lihat https://github.com/dart-lang/sdk/issues/34452. Komentar paling atas di sana memiliki pembaruan terbaru.

Saat menggunakan flutter untuk membuat aplikasi web, apakah mungkin menggunakan ffi dengan perpustakaan ac?

Saat menggunakan flutter untuk membuat aplikasi web, apakah mungkin menggunakan ffi dengan perpustakaan ac?

Itu tidak mungkin. Secara teoritis jangka panjang dapat didukung menggunakan WebAssembly, tapi itu bukan sesuatu yang sedang kami kerjakan.

@ dengan-dengan benar-benar？

Saat menggunakan flutter untuk membuat aplikasi web, apakah mungkin menggunakan ffi dengan perpustakaan ac?

Itu tidak mungkin. Secara teoritis jangka panjang dapat didukung menggunakan WebAssembly, tapi itu bukan sesuatu yang sedang kami kerjakan.

Mengapa itu membutuhkan WebAssembly? Jika Anda dapat meminta orang untuk membangun kembali ke WebAssembly di masa mendatang, Anda dapat meminta mereka untuk membangun kembali ke ASM.js sekarang.

@nic-hartley Itu ide yang bagus, tetapi tantangannya bukanlah bagaimana mengkompilasi kode asli, itu dalam menciptakan jembatan antara Dart (dikompilasi sebagai JS) dan kode asli, apa pun bentuknya.

FFI asli memiliki tingkat yang sangat rendah karena alasan kinerja dan tidak dapat dengan mudah diterjemahkan ke dalam asm.js atau WebAssembly.

Untuk memperjelas, maksud saya implementasi kami adalah tingkat yang sangat rendah -- ini tentu saja merupakan fitur yang menarik, tetapi akan membutuhkan banyak usaha untuk mewujudkannya.

flutter hanyalah mainan sampai mendukung c++

Saya datang ke sini untuk menggemakan poin yang sama oleh orang lain, bahwa sampai Flutter dapat dengan mudah melakukan interop dengan C++ (tanpa perpustakaan jembatan, dan tanpa penalti kinerja) itu tidak akan pernah diadopsi oleh aplikasi skala besar dengan investasi di perpustakaan asli yang ada, atau aplikasi di mana kinerja adalah prioritas tertinggi.

Saya akan mencatat bahwa bahkan React Native menggunakan jembatan saat ini, jadi tampaknya Flutter sebenarnya lebih maju dalam hal mencoba mengimplementasikan FFI.

Integrasi dengan C++ sepele di iOS dengan AppKit. Itu yang harus kita bandingkan, bukan React Native.

UWP & C++ juga sepele.

Saya secara umum juga mendukung partai "mendukung upaya Dart FFI" ...

Xamarin mungkin merupakan perbandingan yang lebih tepat daripada UWP, tetapi tampilan lintas platform Xamarin hampir tidak dapat disesuaikan seperti Flutter dan sering kali membutuhkan banyak kode asli agar terlihat layak.

Ini tidak benar. Tidak seperti Flutter, Xamarin memiliki ikatan platform ke API asli (yaitu Xamarin.iOS dan Xamarin.Android), dan mudah bagi pengembang aplikasi untuk menulis implementasi khusus platform dalam bahasanya sendiri (C#/.NET). Masalah ini adalah tentang fitur bahasa dan tidak boleh dicampur dengan desain API widget UI.

Ada banyak penggunaan API asli, tetapi tidak ada pemanggilan kode asli, di mana Flutter akan berada di kapal yang sama (walaupun Xamarin tidak memerlukan penulisan Java atau ObjC di sana, tanpa peretasan refleksi dalam kode aplikasi). Untuk kode asli, bahkan di Xamarin.Android sendiri (salah satu backend platform backend) penggunaan kode asli sangat sedikit, dan pengembang aplikasi tidak menulis kode asli.

Dan tidak seperti React Native atau Xamarin, Flutter menyediakan kerangka kerja yang lengkap, jadi sangat wajar jika kami membandingkan seluruh kerangka kerja Flutter dengan hal-hal seperti AppKit.

aneh bahwa tidak ada yang menyebutkan kerangka kerja Qt yang jauh di depan segalanya tentang integrasi C++

QT adalah C++. Dan memiliki lisensi yang tidak menguntungkan untuk memulai.

Pada Senin, 12 Agustus 2019, 06:41 Vladyslav Stelmakhovskyi, <
[email protected]> menulis:

aneh bahwa tidak ada yang menyebutkan kerangka Qt yang jauh di depan
segala sesuatu yang lain tentang integrasi C++

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/flutter/flutter/issues/7053?email_source=notifications&email_token=AGDYMWXHTJUBUW64LEOO27TQEDSWNA5CNFSM4CXY6LYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WWW2Z
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AGDYMWTNMTM7QUOY2BEIPM3QEDSWNANCNFSM4CXY6LYA
.

Qt adalah C++ dan QML (mesin JS)
Lisensi apa? LGPL? GPL? apa salahnya?

Pertama dari IANAL, tetapi seperti yang saya pahami, sebagian besar Qt adalah LGPL (IDE dll adalah GPL), yang berarti ia memiliki bahasa yang meskipun tidak secara tegas melarang tautan statis, membuatnya sulit untuk dilakukan sambil tetap mematuhi lisensi jika aplikasi Anda adalah sumber tertutup.

Secara teknis, jika Anda hanya menggunakan LGPL dan menyediakan file objek Anda (dan mungkin instruksi) sehingga pengguna berpotensi menautkan ulang ke versi perpustakaan yang berbeda, Anda memenuhi persyaratan LGPL. Tapi saya cukup yakin Perusahaan Qt tidak mengiklankan fakta itu, jadi konsep umum adalah bahwa Anda tidak dapat menggunakan perpustakaan statis yang berarti Anda tidak bisa mendapatkan aplikasi Anda dirilis di app store tanpa membayar biaya lisensi yang terlalu tinggi. Dan saya mungkin salah dalam memberikan file objek, itu hanya pemahaman saya tentang itu, dan saya tidak tahu apakah ada perusahaan yang melakukan itu.

Android lebih mudah karena memungkinkan pustaka yang dimuat secara dinamis yang secara lebih eksplisit diizinkan di bawah LGPL, tetapi dalam semua, penautan statis yang jujur ​​mungkin akan lebih disukai di sana juga untuk menjaga ukuran aplikasi tetap rendah yang berarti mengalami masalah yang sama.

Hai @cpboyd , saya pikir saya melihat ini dari arah yang berlawanan. Kami sudah memiliki aplikasi yang dibangun di atas kerangka kerja UI khusus platform, di mana setiap platform memungkinkan kami untuk memanfaatkan koleksi besar pustaka C++ kami yang ada. Saya mengerti Flutter adalah lintas-platform, yang bagus, tetapi kecuali saya benar-benar dapat menggunakannya (dengan kode saya yang ada), maka saya lebih baik tetap menggunakan UI non-lintas-platform. Satu-satunya masalah muncul ketika OS masa depan (misalnya Fuchsia) memerlukan penggunaan Flutter & Dart, tetapi tidak mengizinkan kasus penggunaan ini. Dalam hal ini kemungkinan akan diabaikan oleh siapa pun dengan basis kode besar yang ada.

Saya kira saya tidak yakin apakah Flutter / Dart sedang dirancang dengan aplikasi "web" (yaitu di mana backend berada di web), atau pertimbangan serius sedang diberikan untuk kebutuhan pengembang aplikasi desktop profesional. Pada akhirnya keputusan seperti ini dapat memengaruhi jumlah, dan kualitas, banyak aplikasi di toko aplikasi. Jika saya dapat menulis aplikasi profesional berkualitas tinggi untuk iOS menggunakan UIKit, memanfaatkan jutaan baris kode yang ada, tetapi saya tidak dapat (dengan biaya kinerja hampir nol) jika saya mengembangkan untuk Fuchsia / Flutter / Dart, maka itu akan menjadi OS & platform yang tidak akan saya kembangkan.

Tujuan posting saya bukan untuk membandingkan Flutter dengan perpustakaan lintas platform atau non-platform lainnya, ini untuk menyoroti kasus penggunaan yang penting bagi sebagian pengembang.

Dart FFI menarik, dari _very_ pembacaan singkat contoh sqllite , terlihat mirip dengan C# dengan PINvoke, tapi sayangnya itu tidak cocok untuk C++, karena hampir setiap jenis yang Anda tangani akan membutuhkan pembungkus, atau Anda harus menulis beberapa sistem antarmuka tanpa tipe yang sepenuhnya generik untuk membungkus C++. Tak satu pun dari mereka yang sangat menarik ketika Anda membandingkannya dengan kemudahan kelas Obj-C berikut:

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

Atau UWP dengan C++/WinRT:

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

Terima kasih :-)

@Hixie @MarkIngramUK Tak satu pun dari itu lintas platform, yang merupakan maksud saya.
AppKit hanya untuk Apple, sedangkan UWP hanya untuk Windows.
Mungkin jika Flutter menggunakan Swift atau C# alih-alih Dart, maka kami sudah memiliki tingkat dukungan yang sama, tetapi itu argumen yang sama sekali berbeda.
Xamarin mungkin merupakan perbandingan yang lebih tepat daripada UWP, tetapi tampilan lintas platform Xamarin hampir tidak dapat disesuaikan seperti Flutter dan sering kali membutuhkan banyak kode asli agar terlihat layak.
Saran saya tetap: Jika Anda ingin menggunakan Flutter dengan C++, Anda harus berpartisipasi dalam pratinjau FFI tim Dart dan membantu meningkatkan dukungan untuk kita semua

Masalah ini adalah tentang fitur bahasa dan tidak boleh dicampur dengan desain API widget UI.

@atsushieno Tentu, dan itulah mengapa diskusi ini akan lebih produktif di forum Dart FFI... Flutter adalah kerangka

Tak satu pun dari mereka yang sangat menarik ketika Anda membandingkannya dengan kemudahan kelas Obj-C berikut:

@MarkIngramUK Saya yakin itulah jenis umpan balik yang ingin dilihat oleh tim Dart di https://groups.google.com/forum/#!forum/dart -ffi

Saya memiliki proyek bernama ezored (https://ezored.com) yang merupakan proyek bootstrap C++ untuk SDK dan aplikasi di C++. Kami menggunakan dalam proyek seluler (android dan iOS). Saya menunggu FFI selesai untuk membuat proyek yang akan menggunakan SDK default ke flutter.

Kami tidak memiliki masalah dengan C++ dan waktu pengembangan fitur baru berkurang, karena SDK memiliki kode yang sama ke semua platform, seperti yang Anda lihat dalam implementasi default (proyek poco, openssl, sqlite, kode platform spesifik terintegrasi dengan kode jembatan dll).

Dalam pilihan saya ini adalah cara terbaik:

• iOS dan Android dengan backend C++ (ezored)
• Flutter dan C++ sebagai backend

Jangan ragu untuk menambahkan awal ke proyek :)

Kotlin Multiplatform bisa menjadi solusi, bukan pemikiran yang sempurna. Masih perlu menunggu https://github.com/dart-lang/sdk/issues/34452

Unity3d tampaknya entah bagaimana mem-porting flutter ke mesin mereka yang didasarkan pada C# VM [1] - di dunia itu berbicara antara C# dan C++ layak. Mungkin layak untuk melihat repo mereka bagaimana mereka memecahkan beberapa masalah. Mereka menyatakan: "UIWidgets terutama berasal dari Flutter". Saya juga akan melihat reaksi kamp asli dan pendekatan baru mereka dengan TurboModules - solusi mereka mungkin memiliki keunggulan dibandingkan pendekatan flutter karena akan
1) baik sinkron dan asinkron dan
2) tidak akan ada marshalling dan
3) akan mendukung tidak hanya C tetapi C++

Saya pemandu sorak kedua kubu.

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

Pada Dart 2.5, ini ( dart:ffi ) sekarang dalam pratinjau:
https://medium.com/dartlang/announcing-dart-2-5-super-charged-development-328822024970

Kabar baik!

Mmm... Apakah cukup menggunakan Oboe dengan Flutter?..

https://github.com/google/oboe

@rg4real Ya! Tapi, Anda harus menulis beberapa pembungkus C karena antarmuka Oboe ada di C++.

Anda dapat melihat https://github.com/flutter/flutter/wiki/Binding-to-native-code-via-FFI untuk petunjuk memulai.

Anda dapat menggunakan kembali oboe-c.so saya yang saya tulis untuk binding C# saya, jika berhasil https://github.com/atsushieno/oboe-sharp/tree/master/native

@sjindel-google , itu adalah berita yang luar biasa!

Jadi saya perlu membuat jembatan antara kode C++ dan C dengan membuat kelas dan fungsi. Dan kemudian saya dapat menggunakan kelas itu dan memanggil fungsi itu dari kode Dart. Saya pikir itu benar.

@atsushieno , terima kasih. Saya melihat-lihat. Saya tidak yakin bagaimana membuat jembatan dalam kasus saya (kurang pengalaman). Tapi apakah Anda berhasil mencapai tujuan keseluruhan Anda bermain tepat dengan oboe? Apakah itu bagus?

@ rg4real Saya melakukan itu hanya untuk API yang lebih sederhana (dibandingkan dengan OpenSLES) daripada audio latensi rendah. Jika saya benar-benar serius tentang latency maka saya tidak akan menggunakan Xamarin.Android. Jika Anda berbicara tentang Oboe (atau AAudio di belakangnya), maka saya menggunakannya di Fluidsynth dan berfungsi dengan baik. Tidak yakin "seberapa bagus" AAudio dibandingkan dengan OpenSLES.

Apakah ada panduan tentang bagaimana memori dikelola?

Jika kode C++ membuat memori menggunakan new/malloc dan kembali ke kode dart, bagaimana cara mengosongkan memori itu.

kode c++
void foo(char** out) {
*keluar = karakter baru[25];
}

Bagaimana menghapus memori yang ditetapkan ke |out| variabel dari kode dart?

Jika Anda menggunakan Dart 2.5, ada .free() di Pointer . Jika Anda menggunakan cabang dev/master, metode ini memindahkan package:ffi https://github.com/dart-lang/ffi/blob/master/lib/src/allocation.dart#L70.

Sesuai komentar - "Ini hanya dapat digunakan terhadap pointer yang dialokasikan dengan cara yang setara dengan [mengalokasikan]." - free() hanya dapat digunakan jika memori dialokasikan menggunakan metode alokasi().

misalnya
ffi.Penunjukptr = ffi.Penunjuk.mengalokasikan();
ptr.gratis();

Apakah ini menangani membebaskan memori yang dialokasikan di sisi C++ menggunakan baru atau malloc dari kode dart?

Selama memori dialokasikan melalui malloc , baik melalui Dart atau C++, dapat dibebaskan dengan free .

Di Dart 2.6 kita menggunakan DynamicLibrary.lookupFunction("free") untuk mendefinisikan free di Dart, jadi free akan sama persis seperti di bagian C++ program. (Kecuali Anda menautkan dalam beberapa versi free ke biner Anda.)

Menutup masalah ini karena fitur ini sekarang tersedia secara umum (dalam versi beta) di semua saluran Flutter. Kami terus memperbaiki masalah ini. Untuk masalah terperinci apa pun, harap ajukan di https://github.com/dart-lang/sdk/issues/new.

membuat kelas c++ ke kompatibilitas c berantakan. tolong buat kemampuan untuk langsung memanggil kelas c++

+1 Bisakah kami memiliki dukungan C++?

@KaungZawHtet dan @fzyzcjy - harap pertimbangkan untuk membuka masalah baru (mungkin dalam dart-lang daripada bergetar) untuk ini.

Saya akan mengunci masalah ini - ada banyak orang yang berlangganan, tetapi tujuan awalnya telah diselesaikan dengan cukup jelas.

Ya, untuk masalah baru, harap ajukan menggunakan tautan ini: https://github.com/dart-lang/sdk/issues/new?labels=library-ffi ,area-vm