Flutter: دعم التكامل مع C / C ++ في إطار عمل البرنامج المساعد

@ jason-simmons يعرف أكثر عن Gradle. بمجرد أن نحصل على ملف. لذلك ، يمكنني بالتأكيد المساعدة في تحميله.

لقد وجدت أنه تحت buildSrc هناك خاصية أخرى لتعيين إصدار بناء gradle. بعد التحديث إلى 2.2.2 ، تقدمت ، وتمكنت من التحقق من تحميلات .so ، وهو قابل للاستدعاء من Java.

من المفترض أننا سنحتاج أيضًا إلى إضافة واجهة برمجة تطبيقات C لإرسال رسائل HostMessages من كود C / C ++ إلى Dart.

نعم من فضلك. لدي شك في أن رد الاتصال C-> Java قد لا يكون رخيصًا.

أي تحديث على هذا؟ التفكير في Flutter لبناء تطبيق عبر الأنظمة الأساسية يستدعي كود C ++ الذي تم تجميعه في مكتبة مشتركة ، وهذه هي نقطة التوقف الرئيسية الوحيدة.

هذا ممكن اليوم (وقد فعل jtrunick ذلك في تطبيق الشحن الخاص به) ، ولكن عليك القفز عبر Java أو Obj-C أولاً.

على سبيل المثال ، يمكنك استخدام https://flutter.io/platform-channels/ للتحدث من Dart إلى Obj-C / Java ثم من استدعاء Obj-C / Java إلى كود C ++ الخاص بك. يغطي هذا الخطأ إضافة المزيد من الدعم المباشر لهذا ، ويحتمل تجنب عبور Obj-C / Java.

نظرًا لأن Dart VM يتم تنفيذه في C ++ ، فلا ينبغي أن يكون هناك طريقة أسهل (إذا كانت أقل أمانًا) للاتصال بمكتبات C المشتركة مباشرةً (لنقل عبر dlopen)؟ ما مقدار التغيير المطلوب للدعم الأساسي (غير الآمن / التجريبي)؟

هل شيء من هذا القبيل: https://www.dartlang.org/articles/dart-vm/native-extensions متاح على android أو iOS؟

لقد سمعنا هذا المطلب من اثنين من تطبيقات Google:

• كتب أحد هذه التطبيقات مكتبات C ++ الخاصة به لتشغيل الكاميرا لتقليل زمن الوصول. هذه المكتبات خاصة بالنظام الأساسي ومحسّنة للعمل في أسرع وقت ممكن. يعد استدعاء هذه المكتبات بأقل زمن انتقال ممكن أمرًا بالغ الأهمية لمثل هذه التطبيقات. لن يؤدي إجبارهم على المرور عبر PlatformChannel + JNI إلى تحقيق ذلك على Android.

• هناك فرق متنقلة متقدمة تقوم بكتابة مكونات منطق الأعمال في C ++ لتتمكن من مشاركتها بين تطبيقات Android و iOS. يدعم Flutter التكامل المباشر مع تلك المكتبات من شأنه أن يعزز مكانته باعتباره أفضل إطار عمل عبر الأنظمة الأساسية.

لا أعتقد أن هذا _يجب أن يكون_. ومع ذلك ، فهذه منطقة يمكن أن يميز Flutter نفسه فيها عن الحلول الأخرى المشتركة بين الأنظمة الأساسية.

كتب أحد هذه التطبيقات مكتبات C ++ الخاصة به لتشغيل الكاميرا لتقليل زمن الوصول. [...] إجبارهم على المرور عبر PlatformChannel + JNI لن يحقق ذلك على Android.

ما حلهم على Android للانتقال من C ++ إلى Java والعودة؟

إذا كان ذلك ضروريًا حقًا ، فيمكننا السماح بامتدادات Dart الأصلية على الأنظمة الأساسية للجوّال. في الوقت الحالي ، لا نكشف عن الرموز الموجودة في dart_api.h . سنحتاج إلى اتخاذ قرار بشأن ما يلي قبل أن نتمكن من قلب المفتاح:

• اكتشف كيفية جعل مترجم AOT على علم برمز Dart الذي تكون نقطة دخوله الوحيدة من طريقة قد لا تكون موجودة في المكتبة الديناميكية لمحرك Flutter الرئيسية. خلاف ذلك ، قد يتخلص ممر اهتزاز الشجرة من الكود.
• تقديم إرشادات حول إنشاء الإضافات الأصلية وتغليفها (Gradle & Xcode لنظامي Android و iOS على التوالي).
• قدم بعض ضمانات استقرار ABI للإجراءات في dart_api.h . على الرغم من أنها مستقرة في الغالب ، إلا أنني أعتقد أنها لا تزال تتطور لمراعاة الأنماط المختلفة.

حتى الآن ، يبدو أن آلية قنوات المنصات كانت مناسبة لحالات الاستخدام الأبسط.

ما حلهم على Android للانتقال من C ++ إلى Java والعودة؟

لم أتعمق في حالة استخدامها. يبدو أنهم كتبوا جميع البتات التي تحتاج إلى اتصال بزمن انتقال منخفض جدًا في C ++. سوف أسأل عما إذا كانوا يستخدمون أي JNI لحالات الاستخدام الحرجة للأداء (شعوري الغريزي هو لا).

يعتمد الأمر حقًا على ما يمكننا فعله في جانب Flutter. إذا تمكنا من توفير interop أسرع بكثير من JNI ، فسيكون ذلك فوزًا كبيرًا لهذه الفرق. يمكنهم تقليص قاعدة كود C ++ الخاصة بهم والتحول أكثر إلى جانب التطبيق. إذا كان أداء التشغيل المتداخل لدينا مشابهًا لأداء JNI ، فأنا لا أرى فوزًا كبيرًا هنا. ربما يمكنهم متابعة ما يفعلونه الآن واستخدام PlatformChannel.

يتعلق الأمر بإعطاء مثل هذه الفرق سببًا إضافيًا للتبديل إلى Flutter. لم أسمع عن كون هذا مانعًا ، لذا رتب الأولويات وفقًا لذلك.

إذا فهمت ما تقوله بشكل صحيح ، فأنت تقول أن الحلول الحالية هي أن يكون لديك كل المنطق (الكاميرا + واجهة المستخدم) في C ++ مع الحد الأدنى من المنطق في Java ، والرغبة هي نقل جزء واجهة المستخدم من هذا المنطق إلى Dart ، دون فقدان تفاعل الكاميرا <-> لوقت الاستجابة المنخفض لواجهة المستخدم.

هل يمكنك التحدث عن وضع الخيط الخاص بهم؟ هل لديهم خيط واحد للكاميرا + واجهة المستخدم؟

chinmaygarde قد يقربنا من حل هذه المشكلة من خلال عمله الحالي على واجهة برمجة تطبيقات التضمين.

+1

أي تقدم في هذه القضية؟

لقد استخدمنا بالفعل

إذا كان بإمكان Dart التكامل مع C / C ++ ، أعتقد أنه من الجيد للجوال إعادة استخدام عدد كبير من المكتبات الأصلية دون الحاجة إلى الارتباط بمنصة معينة باستخدام JNI أو Objective C ++.

هل فكرت في https://github.com/mono/CppSharp؟ لديهم بالفعل التحليل و AST في مكانه لـ C ++ ، بالإضافة إلى دعم لغات الهدف المتعددة. ربما يمكنك إنشاء مولد Dart لـ CppSharp؟

قد يؤدي دمج قاعدة بيانات تستند إلى C ++ مثل Realm مباشرةً في C ++ إلى تحقيق أداء كبير وزيادة إنتاجية المطورين :-) الصعود / الهبوط من خلال JNI سيكون بمثابة إهدار.

أنا أفكر في Flutter لتطبيق AR يقوم برؤية الكمبيوتر (ربما باستخدام OpenCV) ، وسيكون التشغيل المتداخل الفعال والمباشر Dart-C ++ نقطة إيجابية رئيسية. أتخيل أن العديد من الأشخاص الآخرين يقومون بتطبيقات صعبة من حيث الحساب قد يشاركونك هذه الحاجة.

هل يمكنك تأكيد عدم توفر إمكانية التشغيل المتداخل لـ C ++؟ هل يمكن أن يتم ذلك باستخدام الحزم؟

tofutim Direct c / c ++ interop لا يزال غير متاح ، ولهذا السبب لا تزال هذه المشكلة مفتوحة. ومع ذلك ، يمكنك استخدام قنوات النظام الأساسي ثم استخدام Obj-C / Java للتفاعل مع كود C ++ الخاص بك. إنه ليس رائعًا ولكنه كل ما لدينا في الوقت الحالي.

هل يمكنك تأكيد عدم توفر إمكانية التشغيل المتداخل لـ C ++؟ هل يمكن أن يتم ذلك باستخدام الحزم؟

للتفاعل مع مكتبات النظام الأساسي ، لا تزال آلية قنوات النظام الأساسي هي التوصية الحالية.

يمكن إضافة آلية أكثر كفاءة موصوفة في وثيقة الامتدادات الأصلية بشكل تافه. ومع ذلك ، لست على علم بأي ضمانات لاستقرار ABI للرموز المكشوفة من dart_api.h . إذا كان بإمكان @ a- siva و Tonic كأغلفة ملائمة حول C API لسهولة الاستخدام من C ++.

ما أفهمه هو أن هذا الخطأ يتعلق بتوفير C-API وخطافات الأدوات لتسهيل الحصول على مكون إضافي C / C ++ بالكامل (لا يلزم ملئ Obj-C / Java ، ولكن لا يزال غير متزامن من خلال platform_channels).

لا أعتقد أننا يجب أن نفكر في الأساليب المتزامنة مثل الامتدادات الأصلية في هذا الوقت. (لكن بصراحة أؤجل ذلك إلى Hixie أوcbracken).

eseidel

لا أعتقد أننا يجب أن نفكر في الأساليب المتزامنة مثل الامتدادات الأصلية في هذا الوقت

لماذا هذا؟

الأسلوب الحالي لاستدعاء رمز C هو Dart -> Java -> C
نعبر JNI مرتين ، أليس كذلك؟
أول مرة: dart إلى Java عبر قنوات النظام الأساسي (تحت غطاء محرك JNI تم استخدام استدعاء
المرة الثانية: Java -> C عبر JNI

على سبيل المثال ، من وجهة نظر احتياجات مشروعي ، فإن الوصول إلى dart_api.h حتى بدون ضمان الاستقرار (كميزة تجريبية على سبيل المثال) سيكون بالفعل جيدًا بما فيه الكفاية. شاغلي الرئيسي هو نقل الكتل الكبيرة من البيانات الثنائية (الصور) من جانب Dart إلى الجانب C والعكس بدون تنظيم ونسخ مثالي. الوحدة / مونو تحقق ذلك .

من إصدار dart-sdk 31960 ، أدركت أن التنفيذ الحالي للعزل قد لا يسمح بتمرير البيانات دون نسخ (على الرغم من أنه من الناحية النظرية يجب أن يكون من الممكن اكتشاف أن المخزن المؤقت الذي تم إنشاؤه في العزلة A لم يعد مستخدمًا بعد تمريره لعزل B وبالتالي يمكن نقل ملكيتها ، دون نسخ .. أي خطة على تلك الجبهة؟) ، ولكن إذا لم يكن هناك حشد من / إلى C ، فسيكون ذلك جيدًا.

يمكن تجنب Marshalling باستخدام Flatbuffers التي يبدو أنها ستهبط قريبًا: https://github.com/google/flatbuffers/pull/4676
أو مع رسائل protobuf باستخدام حقل بايت واحد فقط.

بالطبع ، هذا يستلزم كميات كبيرة من نسخ البايت لذا فهي ليست كبيرة لجميع حالات الاستخدام.

أسمع ثلاث رغبات مختلفة على الأقل معروضة هنا:

1. أرغب في طريقة لكتابة مكون إضافي بسهولة لـ Flutter باستخدام كود C / C ++ فقط دون الحاجة إلى إضافة مجموعة من غراء Java / Obj-C (كان هذا هو فهمي الأصلي لهذا الخطأ وشيء أعتقد بالتأكيد أنه يمكننا / ينبغي القيام به) .
2. هل ترغب في طريقة لنقل حجم كبير من البيانات داخل / خارج Dart بسرعة / مع زمن انتقال منخفض / إلخ. (من المفترض أن تكون من عدة لغات ، بما في ذلك C ++. يبدو هذا كحالة صالحة جدًا! أوصي بشدة بتقديم خطأ منفصل بما في ذلك مثال.)
3. هل ترغب في طريقة لتوسيع Dart بمكالمات / كائنات متزامنة؟ (على سبيل المثال ، الإضافات الأصلية أو الطرق الأخرى؟ هذا أيضًا قابل للتنفيذ تمامًا. هناك صعوبات محتملة حول استقرار واجهة برمجة التطبيقات ، وأعتقد أننا نرغب في معرفة المزيد حول حالة الاستخدام المحددة قبل اتخاذ أي إجراء.)

ملاحظاتي من قراءة ما ورد أعلاه هي أننا يجب أن نفكر في فصل بعض الأخطاء الإضافية. نحن بالتأكيد بحاجة إلى استثمار بعض الأشياء حول C ++ inter-op ، ولكن من الصعب تحديد من هذا الخيط الطويل لحالات الاستخدام الدقيقة التي يجب أن نعالجها وبأي ترتيب؟

هل ستكون الأطراف المهتمة مستعدة / قادرة على تقديم أخطاء جديدة مع حالات الاستخدام المرغوبة وربطها مرة أخرى هنا؟ يسعدني ترك هذه المسألة مفتوحة لتتبع الاهتمام العام في مساحة المشكلة هذه.

فيما يتعلق بالأداء و 2. أعلاه: على الرغم من أنني متأكد من أنه يمكن تحسين أداء قنوات النظام الأساسي لـ Flutter (وأننا سنحتاج على الأرجح إلى طرق إضافية / تفاعلية أخرى لتغطية جميع حالات الاستخدام) ، فسنحتاج إلى بعض الملموسة حالات الاستخدام (ربما تكون موجودة ولم أرها؟) حيث يمثل أداء قنوات النظام الأساسي لـ Flutter عقبة قبل أن نتخذ إجراءً. تجربتي في تحسين أداء الأنظمة هي أن غرائزي الغريزية غالبًا ما تكون خاطئة. على الرغم من أن أشياء مثل JNI أو platform_channels تبدو وكأنها اختناقات محتملة ، فإننا لن نعرف في الواقع حتى نقيس.

أشكركم مرة أخرى جميعًا على مساعدتكم وتعليقاتكم!

أرغب في طريقة لكتابة مكون إضافي بسهولة لـ Flutter باستخدام كود C / C ++ فقط دون الحاجة إلى إضافة مجموعة من غراء Java / Obj-C (كان هذا هو فهمي الأصلي لهذا الخطأ وشيء أعتقد بالتأكيد أنه يمكننا / ينبغي القيام به) .

هذا من شأنه أيضًا أن يوفر تكاملًا أفضل مع sqlite للرفرفة + هناك أطنان من مكتبات C / Rust للتشفير و ssh وأشياء أخرى. سيكون من الرائع أن تكون قادرًا على استخدام ذلك بسهولة.

eseidel

أسمع ما لا يقل عن ثلاث رغبات مختلفة مقدمة

تصويتي لـ 1.)

من خلال قراءة مستندات Flutter ، يجب أن يكون توسيع قنوات النظام الأساسي لدعم C.
قد يكون الشيء الجديد الوحيد على الأرجح طريقة لتحميل كائن (كائنات) ديناميكية مشتركة في العملية الحالية.

أتخيل أن استخدام Android-C يبدو مشابهًا لما يلي:

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

MethodChannel* flutter_channels;

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

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

#define str(a) #a

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

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

من الناحية المفاهيمية ، على الأقل بالنسبة لـ _Android-C_ ، عليك أن تقرر كيفية التعامل مع مزيج Java و C.

eseidelGoogle
نكشف حاليًا عن كود golang عبر Java وأغلفة سريعة ووقت الاستجابة يمثل مشكلة ملحوظة نواجهها.
لماذا ا ؟

• نحتاج إلى مشاركة منطق الأعمال بين العديد من المنصات.
• لوظائف الفيديو والصور مثل مشاركة الشاشة.
• ل DB.

إذا كنت قادرًا على إضافة دعم golang على المستوى المباشر من شأنه أن يحدث فرقًا كبيرًا!
يعد تجميع كود golang للجوال أيضًا أمرًا سهلاً للغاية بدون أي سحر LDFLags ، لذلك أعتقد أنه سيكون شائعًا. أعرف عددًا قليلاً من مبرمجي golang الآخرين الذين يستخدمون حاليًا قنوات الطريقة أيضًا.
فيما يتعلق بالتسلسل ، نستخدم حاليًا Protobufs و flatbuffers.

مثال:
https://github.com/dnfield/flatbuffers/blob/master/samples/sample_binary.go

في الفوشيه ، يتم ذلك باستخدام FIDL وله ارتباطات بـ c والصدأ والجولانج.
إنه رائع للاستخدام ولقد كنت أستمتع بتجربة الصدأ والجولانج على لوحة مدمجة.

يجب أن يكون من الممكن فضح الأشياء fidl من خلال iOS و java أيضًا.
هذا من شأنه أن يعطي فرقا جميلا بين الفوشيه والرفرفة على الهواتف المحمولة وسطح المكتب.
مجرد فكرة ألعب بها

eseidelGoogle
أخبرني Hiixe أن FIDL لا يمكن أن يتم على مستوى Flutter لأن FIDL يعتمد على كود النواة من الزركون في الفوشيه. لذا فإن الطريقة الوحيدة لتكرار وظيفة نمط FIDL IPC داخل Flutter هي كتابة إصدار FIDL في محرك Flutter. ولكن بعد ذلك كنت ألعب به aroudn ولاحظت أنه يشبه إلى حد بعيد Flatbuffers. فلماذا لا تستخدم فقط FlatBuffers لطبقة التسلسل بين Flutter و cpp أو golang أو طبقة الصدأ على Flutter. ؟

فقط +1 على هذا ، لدينا تطبيق flutter يستخدم مكتبة تسمى Superpowered. تمت كتابة Superpowered بلغة C ++ ، ثم نستخدم أشياء من نوع java و JNI للتفاعل معها ، والتي بدورنا نستخدم قنوات النظام الأساسي للتحدث مع كود Java. سيكون من الرائع بالتأكيد لو تمكنا من تخطي الرجل الأوسط.

هذا بالإضافة إلى ذلك مع هذا الأمر الذي يعيق مكتبات الجوال الشهيرة مثل Realm من إنشاء إصدارات flutter لأن جوهرها مكتوب بلغة C / C ++ وهم أيضًا لا يريدون التعامل مع وسيط java / objc / swift.

لهذه الأسباب ، وبصرف النظر عن الاستقرار العام ، أعتقد أن هذه القضية هي واحدة من أكثر التغييرات المطلوبة في الرفرفة في الوقت الحالي. (وبشكل أكثر تحديدًا رقم 1 في قائمة eseidelGoogle .)

إذا كنت تريد سماع حجة لتجاوز Java / JNI في امتدادات النظام الأساسي (على سبيل المثال ، ليس فقط إخفاء / أتمتة طبقة Java اللاصقة للمطور) ، فإن Superpowered لديها الكثير لتقوله حول هذا الموضوع: https://www.youtube. com / watch؟ v = LzIuir3r6Co

pnico هل يمكن أن تشرح كيف أن هذا يجادل بأن Java / JNI يجب أن يتم تجاوزهما؟ يبدو أنه يقول أكثر من أنه يجب كتابة كود معالجة الصوت بلغة C ++. (وهذا لا يعني أنه لا يمكنك الاتصال به من خلال JNI أو بأي وسيلة أخرى)

@ csga5000 أنت محق تمامًا ، هذا لا معنى له: ربما لن يؤثر D JNI على الأداء حقًا إلا إذا كنت تحاول القيام بمزيد من الأشياء الباطنية. أعتقد أن الأمر يتعلق حقًا بالراحة / إمكانية الصيانة ، وأعتقد أنه ربما تكون القدرة على نقل المزيد من التعليمات البرمجية الخاصة بالتطبيقات خارج Java / C ++ وإلى Dart

أعتقد أن pnico يقول إنه يمكنه الاتصال بها من خلال JINI ، لكن JINI تضيف الكثير من التأخير.
لذا فإن الأداء هو المشكلة.
نعم / لا ؟؟

قد يحدث هذا فرقًا كبيرًا في الغالب بالنسبة للعمل المرتبط بالعملات المشفرة.

أفترض أيضًا أن Android Things ، على الرغم من أنني لم أر أو أجري تجارب
والمعايير لتوقيت gpio الحساسة في لا c ولا dart لأكثر من a
عام.

في السبت ، 9 يونيو .2018 ، الساعة 10:52 ، كتب Eddy WM ، [email protected] :

قد يحدث هذا فرقًا كبيرًا في الغالب بالنسبة للعمل المرتبط بالعملات المشفرة.

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/flutter/flutter/issues/7053#issuecomment-395927258 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AFHMcSI2JDHbgv3iYrStDN5mlzkQ8XEkks5t6xxMgaJpZM4K-PLw
.

أي تقدم منذ ذلك الحين؟

حتى يتم حل هذه المشكلة ، هل هناك توصية بشأن مثال مكون إضافي للرفرفة يوضح كيفية دمج ac / c ++ lib؟ هل djinni طريقة جيدة للذهاب؟

حتى يتم حلها ، الطريقة الوحيدة لدمج c / c ++ كتابة كود android و ios الأصلي ، ثم التفاعل مع رمز dart باستخدام قنوات النظام الأساسي

لقد قمت بتطبيق مكونات إضافية تستخدم قنوات النظام الأساسي (لملفات jar و CocoaPods). أنا أبحث عن مثال مكون إضافي يوضح كيفية الدمج في نفس c / c ++ lib (لكل من android و ios). أي توصيات؟

@ mmcc007 كيف تفعل ذلك في جافا أو سويفت.

جافا: 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 java / com / superpowered / recorder / MainActivity.java الذي يشير إلى الكود في cpp / RecorderExample.cpp

@ csga5000 يبدو كما لو أنه سيكون مستقيمًا بشكل معقول .. في المراجعة الأولى. لا يزال من الجيد البحث من خلال مكون إضافي رفرفة يعمل. شكرا.

+1 لهذا. ومن شأن أي أمثلة عملية لج رفرفة التطبيق باستخدام ++ يكون قبولا حسنا

هناك مشروع يقوم بذلك من أجل غولانغ وأعتقد أنه نفس النهج
يمكن استخدامها لـ c ++ أيضًا.

يستخدم برنامج golang jsonrpc.
ثم كل ما عليك فعله هو تقديم كود golang الخاص بك باستخدام jsonrpc.

ثم كل شيء سهل للغاية.

أعتقد أن قنوات النظام الأساسي تدعم JSON فقط كتسلسل حيادي
صيغة ؟

يوم الأربعاء ، 18 يوليو 2018 ، الساعة 16:50 مساءً جيفرسون بليدسو ، [email protected]
كتب:

+1 لهذا. أي أمثلة عملية من التطبيق رفرفة باستخدام ج ++ سيكون
استقبال جيد

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/flutter/flutter/issues/7053#issuecomment-405958345 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ATuCwkPbb9vLdoaEwM-bLhYPZxtyQ5Vjks5uH0sqgaJpZM4K-PLw
.

مرحبا اي اخبار

هل تريد فقط معرفة ما إذا كان أي شخص في هذا الموضوع قد تمكن من دمج مكتبة Superpowered مباشرة في تطبيق flutter؟

نعم @ Skills-up لقد فعلنا ذلك. ليس فقط في مشروع مفتوح المصدر لذا لا يمكنني العرض. ولكن إذا رأيت نصائحي سابقًا ، فهذه هي الطريقة التي تقوم بها. قد تحتاج إلى إنشاء تطبيق flutter لكل بنية وحدة معالجة مركزية

أفهم أنك فعلت ذلك عبر JNI / Java وليس مباشرة من dart. كنت أتساءل عما إذا كان من الممكن تجنب التعليمات البرمجية الخاصة بالمنصة تمامًا.

قد تحتاج إلى إنشاء تطبيق flutter لكل بنية وحدة معالجة مركزية

هل تقصد تطبيقًا منفصلاً لكل بنية ، أو مجرد تحديد جميع البنى المدعومة؟

راجع للشغل ، لدينا بالفعل تطبيق عملي مكتوب أصلاً بلغة Java. ومع ذلك ، الآن بعد أن أصبح علينا إنشاء تطبيق iOS أيضًا ، كنت أتساءل عما إذا كان إنشاء تطبيق في رفرفة (بدلاً من بذل الجهود على Swift / XCode) سيكون أكثر منطقية من منظور قابلية الصيانة في المستقبل ، مع الاستفادة من قاعدة رمز واحدة.

حسنا. تنتظر Realm يا رفاق تقديم طريقة: https://github.com/realm/realm-object-server/issues/55

لوكاسبيلي: أعتقد أن الجميع ما زال ينتظر: رفرفة / رفرفة # 7053
bmunkholm: lukaspili نعم ، هذا شرط أساسي بالتأكيد.

لما يستحق ، أنا في انتظار هذا أيضًا. لا يمكن حقًا النظر في استبدال تطبيقات XF برفرفة كما سبق حتى تحصل يا رفاق على السباكة المناسبة. كما هو الحال حاليًا ، ينفخ Xamarin من الماء في هذا القسم.

متأخر على هذه الحفلة ولكن إجراء +1 كبير لهذا الموضوع.

أقوم بتطوير تطبيقات سطح المكتب ، وجهة نظري كسطر من التعليمات البرمجية (لسطح المكتب):

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

إذا كان بإمكان Flutter تقديم دعم من الدرجة الأولى لـ C ++ ، أعتقد أن النهج العام يمكن أن يكون الفائز المطلق لتطوير التطبيقات عبر الأنظمة الأساسية ، ليس فقط "الهاتف المحمول أولاً" ولكن الأول من نوعه في العالم. Qt باهظ الثمن بالنسبة للمطورين الصغار ، ولديه رأي ولا يحتضن C ++ الحديثة ولا شيء ينافسه حقًا ، فهل يمكن أن يأكل Flutter بعضًا من فطيرة واجهة المستخدم الخاصة به على الأقل؟

ملاحظة: أنا لست ضد Dart ، إنها C # / Go / Rust جديدة أخرى / إلخ. لغة منافسة قد تكون منتجة للغاية لمنصة جديدة ولكن عالم تطبيقات سطح المكتب عالية الأداء (اهتمامي هنا) هو C ++ بثبات ، مع دعم واسع النطاق لنظام التشغيل والمكتبة ، وهي لغة تتقدم بمعدل عقدة بحد ذاتها (إنها ليست ج) وأعتقد أن Flutter يستحقها!

لا أعتقد أن الرفرفة ستدعم C ++ في أي وقت في المستقبل القريب ، وهو بالتأكيد غير ممكن الآن. وأنا شخصياً أفضّل Dart - كتابة التطبيقات بلغة C ++ حتى مع الرفرفة تتطلب الكثير من الجهد. ولا أعتقد أن C ++ تترجم مباشرة إلى دعم سطح المكتب ، فلا يزال يتعين عليهم كتابة الكثير من التعليمات البرمجية ، ويجب أن يعمل dart VM لسطح المكتب على أي حال. أعتقد أن الأداء لا يكاد يذكر بالنسبة لمعظم التطبيقات.

أعتقد في النهاية أن Google تريد دعم إمكانية التشغيل البيني حتى تتمكن من كتابة تطبيقات flutter لأي وجميع الأنظمة الأساسية باستخدام أي لغات مدعومة أو حتى مجموعة من اللغات المذكورة. لكنني لا أتوقع ذلك حتى يتم إصدار الفوشيه أو بعده. هدفهم في الوقت الحالي هو تسهيل كتابة التعليمات البرمجية مرة واحدة. يطابق Dart هذا الهدف لأنه سهل الاستخدام / التعلم وفعال وإحدى لغات Google على أي حال. لا أرى حقًا أي ميزة عملية تقريبًا للمستخدم العادي في الحصول على دعم C ++ من الدرجة الأولى. الأداء لا يكاد يذكر في تطبيقات الأجهزة المحمولة ، واستخدام قنوات النظام الأساسي مع C ++ سيكون مناسبًا لغرض التفاعل مع مكتبات C ++ الحالية. على الجانب المشرق ، يمكنك أن تكون على يقين من أنهم يعتزمون في النهاية دعم الرفرفة لسطح المكتب (حسنًا على الأقل كابيبارا الفوشيه ، لكنني أشك في أنهم سيتوقفون عند هذا الحد).

يدور هذا الموضوع حول دعم التكامل المباشر w / C ++ من dart / flutter ، والذي نأمل أن يأتي في المستقبل القريب.

لا أعتقد أن الرفرفة ستدعم C ++
لا أرى حقًا أي ميزة عملية تقريبًا للمستخدم العادي في الحصول على دعم C ++ من الدرجة الأولى.

لا يتعلق الأمر بمدى روعة Flutter / Dart مقابل C ++ ، بل يتعلق أكثر بنقطة / سهولة عمليات الدمج التي تحتاجها لتلائم النظام البيئي الحالي. توجد قائمة طويلة من المكتبات ككائن مشترك (OpenCV لتسمية واحدة) وهي معيار الصناعة ، لا يمكنك أن تتوقع من الناس إعادة كتابتها في Dart؟

الأداء لا يكاد يذكر في تطبيقات الأجهزة المحمولة ، واستخدام قنوات النظام الأساسي مع C ++ سيكون مناسبًا لغرض التفاعل مع مكتبات C ++ الحالية.

على العكس تمامًا ، فإن استخدام القنوات هو دون المستوى الأمثل في هذا السياق ، فكر في حالات الاستخدام حيث تحتاج إلى العمل مع كائن ثنائي كبير على الذاكرة (الصور) ، ستحتاج إلى إما:
1- انسخ هذه الثنائيات من / إلى ذاكرة C ++
2- العمل مع JNI للتفاعل مع المكتبة (والتعامل مع المؤشرات المخصصة ديناميكيًا لهذه الثنائيات)
دون ذكر التكاليف العامة للتسلسل / إلغاء تسلسل القيم / المعلمات التي تتكبدها باستخدام القنوات.

إطار العمل الجيد هو التوازن بين الميزات / النماذج الجديدة التي يقدمها مقابل سهولة التكامل مع النظام البيئي / الإرث الحالي ، والذي لا يمكننا إنكار أن C ++ جزء منه.

nhachicha لم يكن csga5000 يختلف في أن الدمج المباشر لـ ++ C كان أمرًا مهمًا ؛ كان يرد على تعليق سابق يسأل عما إذا كان يمكن استخدام Flutter

الأداء لا يكاد يذكر في تطبيقات الأجهزة المحمولة ، واستخدام قنوات النظام الأساسي مع C ++ سيكون مناسبًا لغرض التفاعل مع مكتبات C ++ الحالية.
nhachicha لم أستطع الاتفاق أكثر.

الحقيقة هي للتطبيقات التي لا تحتاج إلى أداء عض الأسنان (وهو كثير) فلماذا لا تستبدل الصعب إتقان C ++ بشيء أكثر إنتاجية ، في الواقع لماذا تتوقف عند Dart وحدها ، لماذا لا تدخل في أي من هذه الشعبية الفائقة ، ( العديد من اللغات الأكثر شعبية / المنشأة من Dart):

• C # /. وقت تشغيل Net Core
• وقت تشغيل Javascript / Typescript V8 (سيكون لديك متصفح تقريبًا في هذه المرحلة ولكن ماذا في ذلك)
• الصدأ (سريع أيضًا!)
• GoLang
• بايثون
• [أدخل المفضلة لديك هنا] ...

وبقدر ما أحب شخصيًا وأستخدم بعض هذه اللغات كل يوم ، فإن C و C ++ هي في صميم Linux ، لذلك أنظمة Android و iOS وأنظمة سطح المكتب مثل Windows و MacOS وأجهزة سطح المكتب الأخرى. تمت كتابة نصف اللغات المذكورة أعلاه (بما في ذلك Dart) بلغة C ++. تتطلب التقنيات المتطورة مرارًا وتكرارًا أداءً أصليًا مضبوطًا ، مثل AI (Tensorflow هو C ++ و Caffe C ++ و Pytorch هو C تحت Python ، وما إلى ذلك) ، ومكتبات الواقع المعزز ، ومحركات ألعاب AAA وأي شيء يحتاج إلى الاقتراب من وحدة معالجة الرسومات (CUDA) ، تم استدعاؤه من C / C ++).

لنفس السبب الذي يجعل محرك تقديم Flutter مكتوبًا بلغة C ++ (أصلي ، أداء عالٍ ، بطارية / ذاكرة / وحدة معالجة مركزية فعالة) ، أعتقد أنه سيكون من الرائع فتح أفضل أداء ممكن ، عند الحاجة ، دون الاقتراب من وقت التشغيل المُدار وببساطة دعم C ++. هذا من شأنه أن يميز Flutter عن الأطر الأخرى مثل Xamarin و Nativescript ، والتي تقدم بصدق تجربة تطوير مماثلة (بعد أن استخدمت كليهما) فقط مع لغات مختلفة ، فلماذا لا تجعل الرفرفة مميزة بدلاً من مجرد "Dart one"؟

_ كملاحظة جانبية ، أنا في المنزل تمامًا مع كتابة كل شيء بلغة C / C ++ ، بدءًا من التحقق من صحة النموذج وحتى تظليل البكسل ، لكنني لا أتظاهر بأن هذه هي وجهة نظر العديد من الأشخاص الذين ينظرون إلى هذا الريبو - وهذا لأنني أجد C ++ a لغة منتجة للغاية - ومع ذلك فهي خيار شخصي تمامًا.

هذا هو أحد الأسباب الرئيسية التي تجعلنا بحاجة إلى تكامل 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);

كان لدينا قدر معين من الاهتمام بتنفيذ مؤسسة مالية أجنبية كهذه لفترة طويلة - أتوقع منا أن نجربها في وقت ما في المستقبل القريب ، لكنني لن ألتزم بأي جداول زمنية محددة.

@ kirbyfan64 صحيح تمامًا ، nailgilaziev ، bytesoftly أنا لا أحاول أن أقول إن تكامل C ++ ليس ضروريًا ، كنت أقول فقط لا أعتقد أن هناك الكثير من الأسباب / الطلب لجعل دعم الرفرفة C ++ بدلاً من dart - ولكن أنا لا أقول أن التكامل ليس ضروريًا. ما يقولهmraleph يبدو ذكيًا بالنسبة لي.

mraleph كان لدى Dartino تطبيق مماثل لـ FFI . ما مدى صعوبة القيامة؟

listepo أجزاء منه. كان تنفيذ Dartino لـ FFI ديناميكيًا للغاية - وهذا ليس شيئًا نريده لـ Dart 2 الذي يعد أكثر ثباتًا من Dart 1.

في وقت متأخر من اللعبة ، ولكن إليك حالة استخدام أخرى: نود تضمين ملفات c وطرقها في dart لأغراض التشفير.

ما نتمناه هو ما يلي:
1) رمز متطابق لنظامي iOS و Android ، أي عدم المرور بطبقات ObjC أو JNI.
2) أتمنى أن يكون التنفيذ أكثر كفاءة مما هو عليه عند المرور على سبيل المثال JNI مرتين.
3) إمكانية إعادة استخدام كود نموذج dart في تطبيق ويب للمتابعة ، على سبيل المثال في AngularDart ، أو متابعة تطبيقات سطح المكتب باستخدام هذا المشروع: https://github.com/google/flutter-desktop-embedding

أعتقد أن ما نريده هو الأقرب للنقطة 2eseidelGoogle المذكورة أعلاه. أما بالنسبة للدعم المتزامن ، فأنا أعتبره "أمرًا رائعًا" ، نظرًا لأنه لا يمكن استخدام الوظائف غير المتزامنة في المُنشئ ، حيث قد يرغب المرء في إجراء حساب تجزئة سريع ، على سبيل المثال. لكن التعود على طريقة Darts غير المتزامنة ، يبدو الدعم المتزامن أقل أهمية من الاحتمال العام لتحقيق النقاط 1) -3) أعلاه.

باستخدام FFI كما اقترحه mraleph ، هل سيسمح هذا بـ 1) -3) كما في تعليقي السابق ، أم سيعني أن هناك حاجة إلى رمز مختلف على منصات مختلفة (Android ، iOS ، ...)؟

CryptUser إذا كان

mraleph يبدو رائعا! بالنظر إلى أن الإصدار الأصلي يحتوي على أكثر من 200 إعجاب ، فهل هناك أي فرصة لزيادة الأولوية في هذا الأمر؟

mraleph هل هناك مشكلة مفتوحة لـ FFI في Dart في مكان ما؟

dnfield لقد قدمت واحدة الآن https://github.com/dart-lang/sdk/issues/34452

أحب أن أكون قادرًا على كتابة كود C / C ++ / Rust وأن أكون قادرًا على استخدامه عبر ffi

مثال:

أختبر الرفرفة على جهاز Android اللوحي (Android 4.4).
ركض رفرفة بسرعة.
ولكن عندما أحاول قراءة 1000 صف مع sqflite الذي يستخدم قناة النظام الأساسي ، يكون الأمر بطيئًا للغاية.
السبب: لا يمكنني استخدام قارئ المؤشر sqlite.

ولكن إذا كان بإمكاني استخدام مكتبة sqlite مباشرة ، فسيكون الاستعلام نفسه فوريًا. (تم اختباره باستخدام xamarin ومشروع android الأصلي).

نحن نناقش الآن أفضل السبل للتعامل مع هذا. كما هو مذكور أعلاه في https://github.com/flutter/flutter/issues/7053#issuecomment-377711814 ، تحتوي هذه المشكلة على العديد من الأجزاء وربما تحتاج إلى تقسيم. :)

لكننا وجدنا بعض المهندسين مهتمين باستكشاف مؤسسة مالية أجنبية (كما هو مذكور في https://github.com/flutter/flutter/issues/7053#issuecomment-415161464). ينصب تركيزنا الآن على إخراج 1.0 من الباب ، ولكن بمجرد القيام بذلك ، سيكون ذلك على رأس القائمة. شكرا مرة أخرى لجميع ملاحظاتك المستمرة. سنقوم بتحديث هذه المشكلة عندما يكون لدينا المزيد من التقدم للمشاركة.

أنا أيضًا مستخدم Matlab / Simulink. يمكنني إنشاء رمز c / cpp محدد للغاية لوحدة المعالجة المركزية. أريد دمج الخوارزمية الخاصة بي في الرفرفة. لدي الكثير من خوارزمية معالجة الصور. أحتاج إلى مولد ملزم للرموز الأصلية. وإلا فسوف أنسى كل خبراتي في لعبة dart-flutter وسأبدأ في تعلم xamarin أو أي شيء يناسبني.

هل يمكننا تسريع التقدم؟

إنه مجرد ألم كبير للتفاعل بين Dart و C.

من غير المحتمل أن يؤدي التعجيل بالعملية إلى الحصول على منتج جيد الجودة. سيكون جاهزًا عندما يكون جاهزًا. :-)

من غير المحتمل أن يؤدي التعجيل بالعملية إلى الحصول على منتج جيد الجودة. سيكون جاهزًا عندما يكون جاهزًا. :-)

حسنًا ، ما حاولت قوله هو أننا قد نرغب في زيادة الأولوية حتى نتمكن من وضع المزيد من الموارد والجهود لحل هذه المشكلة. أنت تعلم أن هناك 1386 مشكلة مفتوحة حتى الآن تستهدف "الهدف" والذي سيتم "إصلاحه في السنوات القادمة".

بعد قراءة الموضوع مرة أخرى ، لاحظت أن eseidelGoogle قال إن هذا سيحصل على أولوية أعلى بعد أن

قد يكون "الهدف" هو المجموعة الخطأ. :) mraleph لديه شخص ما يستكشف https://github.com/dart-lang/sdk/issues/34452 بينما نتحدث. هذا جزء من الحل على الأقل.

إليك مستند الرؤية الخاص بـ FFI الذي نعمل حاليًا على تصميم نماذج أولية على جانب Dart.

يرجى إلقاء نظرة وإخبارنا برأيك.

لا يمكنني قول الكثير عن جزء FFI لأنني لم أستخدم شيئًا كهذا أبدًا ،
لكني أتساءل كيف سيبدو التكامل في الحانة.

كيف سيتم التعامل مع حزم النشر التي تستخدم FFI؟
كيف سيتم التعامل مع الحزم المستهلكة التي تستخدم الغذاء الأجنبي؟

zoechi لم نناقش التكامل pub حتى الآن.

يجب أن يكونوا قادرين على العمل بشكل مشابه لملحقات Flutter اليوم - بما في ذلك المصادر المناسبة للمنصة / البنية و / أو الثنائيات التي يمكن تجميعها / ربطها بالتطبيق المستهلك.

من منظور الحانة ، لا ينبغي أن تكون مشكلة كبيرة - باستثناء أنه قد تكون هناك ملفات ثنائية أكبر مدرجة في الحزمة.

قد تكون هناك حاجة إلى بعض العمل على الرغم من نهاية أدوات Flutter للأشياء لدمجها في مشاريع Flutter - لن تعمل تمامًا مثل مكونات Android / iOS الإضافية اليوم.

هل يجب نقل تكامل الحانة إلى مشكلة dart-lang / pub لإبقاء هذه المشكلة أكثر تركيزًا؟

لقد قرأت "وثيقة الرؤية" وأخيراً أرى الأشكال من خلال الضباب.

في غضون ذلك كنت أفكر في شيء مختلف كثيرًا.

وهي (إعادة) استخدام Flatbuffers لصنع شيء مثل NativeChannels. عند تنفيذ وقت (AOT) ، سوف يتحول الأمر إلى تمرير المؤشر ، بينما في وقت التطوير سيسمح لي بالاستفادة من الأدوات الموجودة للجانب "الأصلي" المكتوب ليس فقط في C / C ++ ولكن مكتوب أيضًا في Go أو Rust.

نهج تمرير الرسائل هو أيضًا أكثر انسجامًا مع البنى القائمة على التدفق الحالي (Bloc ، Rx). إنه يفرغ أي قلق بشأن إدارة الذاكرة أيضًا ، حيث قد ينشئ المترجم مخازن مؤقتة مناسبة للحلقة عند الاقتضاء أو يفترض `` عمليات تحرير بسيطة '' حيث يحتاج المستدعي إلى الاحتفاظ بالبيانات لفترة أطول.

ولكن لكي أكون صادقًا ، سأشيد بأي شكل من أشكال ffi إذا كان سيتم دمجه بسلاسة في النظام البيئي Flutter (Fuchsia) واسمحوا لي باستخدام كود أصلي محسّن لوحدة المعالجة المركزية من داخل تطبيق Dart.

ohir ما كنت قد

eseidelGoogle أي تقدم في هذا؟ في الوقت الحالي ، لدينا مشروع يحتاج إلى تنفيذ مهام معالجة فيديو ثقيلة يمكن إجراؤها عبر ffmpeg نظرًا لأن حزمة dart الحالية لا يمكن أن توفر حلاً قابلاً للتطبيق نحن ننتظر بفارغ الصبر flutter لاستدعاء ffmpeg lib مباشرةً.

بالنسبة لتلك التطبيقات القائمة على واجهة المستخدم من صفحة إلى صفحة ، أعتقد أن الرفرفة الآن هي خيار جيد حقًا من التحول إلى عمل الترميز المزدوج على كل من android و ios إذا كنا في 5 سنوات مضت بمثل هذه المعدات الرائعة ， ربما صناعة التطبيقات بأكملها كن متغير. ومع ذلك ، فإن مزايا الرفرفة في الوقت الحالي لا تحبس الأنفاس بالنسبة للشركات التي تهاجر إليها لأنها قد حققت أداءً جيدًا بما يكفي بالطريقة القديمة ， ولكن بالنسبة لبعض المهام التي لا تتعلق بواجهة المستخدم فإن النبال هي وراء المتطلبات القصوى.

هذا لا يعني أن dart ليست جيدة ولا قابلة للتطبيق لتلك المهام يومًا ما ، ولكن من وجهة نظر شركة تكنولوجيا المعلومات العادية التي قد يتم تضمينها في النظام البيئي للرفرفة ، فإن ما يحتاجون إليه هو تقليل التكلفة باستخدام طريقة ترميز النظام الأساسي فقط إذا كان من الممكن تحقيق أفضل الميزات الرائعة ، مثل معالجة البيانات من جانب العميل ، والفيديو / الصوت ، وموظفي AR وما إلى ذلك طالما أن بعض الخوارزميات قاموا بها بالفعل عبر c / c ++. من الصعب حقًا عليهم إعادة تنفيذه أو إعادة اختراعه باستخدام dart lang.

والحل الرئيسي هو تقديم طريقة مباشرة وفعالة للرفرفة للتواصل مع ++ c ، حتى أنني أعتقد أن هذا هو الأولوية الأولى لشيء "عبر النظام الأساسي" ، فإن dart لموظفي UI مثالي ، ويمكن أيضًا أن يكون منطق البيانات العادي تم القيام به في لعبة dart ، ولكن من الأفضل بكثير دمج الرفرفة في النظام البيئي c ++ طويل ولكن لا يزال نشطًا وفعالًا بدلاً من إعادة بناء نظام جديد مقدس!

حلم تجربة تشفير "عبر الأنظمة الأساسية" هو فريق dart UI مع c ++ خلف الغطاء ، ولا يوجد كود جافا على الإطلاق ، ولا يوجد كود OC على الإطلاق. واهاها ، لا أطيق الانتظار لرؤية ذلك يحدث!

@ smellbee ألا يمكنك استخدام سطر أوامر ffmpeg؟

smellbee أنا مميز لست الشخص المناسب للإجابة على هذا. eseidelGoogle هل من أخبار عن هذا؟

@ smellbee ألا يمكنك استخدام سطر أوامر ffmpeg؟

إنه عمل من جانب العميل ، باستخدام ffmpeg lib لعرض إطارات الفيديو لإنتاج تدفق رجعي فوري ، هل من الممكن استخدام سطر الأوامر؟

smellbee أنا مميز لست الشخص المناسب للإجابة على هذا. eseidelGoogle هل من أخبار عن هذا؟

آسف لذلك ، لقد كتبت "es" ، وتم إكمالها تلقائيًا ، لم ألاحظ ذلك .... آمل أن يتمكن eseidelGoogle من رؤيته

العمل جار على جانب Dart - نأمل أن يكون لدينا شيء جاهز في الربع الأول من عام 2019.

إنها ميزة كبيرة ونود أن نحصل عليها بشكل صحيح: لأننا نريد أن نجعلها تعمل بشكل رائع عبر أوضاع تنفيذ مختلفة لـ Dart ، لذا يرجى تحملنا أثناء عملنا على التفاصيل.

يمكنك متابعة dart-lang / sdk # 34452 الذي يتتبع العمل على جانب Dart.

سيسمح Dart FFI باستدعاء وظائف C من Dart.
ولكن ماذا عن ميزات C ++ - الفئات ، وحاويات الأمراض المنقولة جنسياً ، والمؤشرات الذكية ، والاستثناءات؟
هل يمكننا توقع إمكانية تصدير فئات C ++ إلى Dart مع الحد الأدنى من النماذج المعيارية؟

ميزة أخرى مهمة للغاية هي الدعم غير المتزامن - القدرة على تشغيل كود C ++ على مؤشر ترابط منفصل وإرجاع Future / Stream من الأساليب.

@ t-artikov لا توجد خطط حالية لدعم إمكانية التشغيل البيني C ++ بشكل مباشر. هذا معقد للغاية. الشيء الوحيد الذي يمكن أن يتفاعل بشكل مريح مع C ++ هو C ++.

إذا كنت مهتمًا بالتداخل عالي المستوى مع C ++ ، فستحتاج إلى إنشاء طبقة التشغيل المتداخل الخاصة بك والتي تعرض واجهة برمجة تطبيقات C ++ الخاصة بك من خلال C مثل API.

ميزة أخرى مهمة للغاية هي الدعم غير المتزامن - القدرة على تشغيل كود C ++ على مؤشر ترابط منفصل وإرجاع Future / Stream من الأساليب.

أعتقد أنه يمكن بناء هذا كحزمة واحدة. يجب علينا فقط التأكد من أننا نقدم الأساسيات الصحيحة حتى يمكن بناء هذا.

سيسمح Dart FFI باستدعاء وظائف C من Dart.
ولكن ماذا عن ميزات C ++ - الفئات ، وحاويات الأمراض المنقولة جنسياً ، والمؤشرات الذكية ، والاستثناءات؟
هل يمكننا توقع إمكانية تصدير فئات C ++ إلى Dart مع الحد الأدنى من النماذج المعيارية؟

طالما أن هناك طريقة لـ C ++ لاستدعاء dart أعتقد أن هذه الأشياء ممكنة ， C ++ تعتني بما يثير قلق C ++ ， وتتواصل مع dart من خلال الاتصال أو الاتصال ، فلا داعي لفضح أي تلاعب منخفض المستوى لـ النبلة التي ستدمر سهولة استخدام السهام.

ميزة أخرى مهمة للغاية هي الدعم غير المتزامن - القدرة على تشغيل كود C ++ على مؤشر ترابط منفصل وإرجاع Future / Stream من الأساليب.

ولدى dart بالفعل آليتها غير المتزامنة ， لذلك ， سواء كان الخيط موجهًا لـ C ++ أم لا لا يحدث فرقًا طالما أن الجزء C ++ يمكنه استدعاء dart عند الحاجة ، ويمكن لـ "Isolate" القيام بالمهمة.

هذا ما أعتقدهmraleph ،

تضمين التغريدة
في الواقع ، هناك أمثلة على إمكانية التشغيل المتداخل C ++ الرائعة مع لغات أخرى.
https://github.com/boostorg/python
https://github.com/ThePhD/sol2
https://github.com/dropbox/djinni
آمل أن توفر Dart / Flutter آلية مماثلة خارج الصندوق.

إذا كنت مهتمًا بالتداخل عالي المستوى مع C ++ ، فستحتاج إلى إنشاء طبقة التشغيل المتداخل الخاصة بك والتي تعرض واجهة برمجة تطبيقات C ++ الخاصة بك من خلال 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 ++ لاستدعاء 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 لا يقدم ذلك. إيثر سكالا الأصلي. .NET إما (Microsoft C ++ interop دائمًا إما غريب أو ثابت). تدعم JNI إمكانية التشغيل المتداخل C ++ فقط في حالة وجود ترجمة ثابتة. يجب كتابة شيء مثل الغراء الداعم للثعبان يدويًا. يمكن لأي مجموعة طرف ثالث تطوير أشياء مثل JNAerator (على سبيل المثال ، يمكنك القيام بذلك ، ولا داعي لتوقع قيام فرق Dart / Flutter بتحقيق ذلك).

بعد هذه المحادثة بدون إجابة حقيقية ، أعتقد أنني سألتزم بـ Qt وهو شكل متقاطع ولديه دعم C ++ الكامل. كنت أفكر فقط في تجربة Flutter لمشروعي التالي ، لكنني الآن لن أفعل ذلك ، شكرًا جزيلاً!

كان من الأفضل كتابة الرفرفة بلغة C ++ ، والتي كان من الممكن بسهولة التعامل معها مع أي لغة أخرى. هل هناك أي محاولة لإعادة كتابة الرفرفة في C ++؟

أعتقد أن المناقشة تتسع بلا داع الآن.

نحن نعلم ما هو (أو لا يوجد) في خارطة طريق تطوير الرفرفة.
وفقًا لذلك ، يمكننا أن نقرر استخدامها (أو عدم استخدامها) لحالات استخدام محددة.

لا أرى أي فائدة في محاولة تغيير أجندة التنمية ، أو
يطالب بتنفيذ معماري محدد ، بعد هذه النقطة.

شكرا،
غوراف

في يوم الاثنين 25 فبراير ، 2019 ، الساعة 10:51 مساءً ، كتب بهوج ، [email protected] :

كان من الأفضل كتابة الرفرفة في C ++ ، مع
التي يمكن أن تتداخل مع أي لغة أخرى بسهولة. يكون
هل هناك أي محاولة لإعادة كتابة الرفرفة في C ++؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/flutter/flutter/issues/7053#issuecomment-467098455 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AZ86acDpZgNeyezx40uxe_c5E2xZHWxaks5vRBumgaJpZM4K-PLw
.

في الواقع ، فإن Flutter هو كما أعلم أنه مكتوب بلغة C ++ ولكن بالنسبة للبرمجة في Flutter لا يمكن القيام به إلا باستخدام مترجم Language Dart الذي يعمل في VM. لكن ليس لديك أي فرصة بعد للانتقال من Dart إلى جزء C ++ من Flutter ...

لذا أياً كان من يقرأ هذا ولديه حالة الاستخدام الشائعة في تطوير التطبيقات لتطوير جيد عبر الأنظمة الأساسية ، فلن يسمح Flutter بالاستخدام المباشر لـ C ++ إذا كنت في حاجة إليه ، ثم استخدم إطار عمل مشترك آخر مثل Qt C ++.

بالنسبة لي ، تعد C ++ ضرورية لـ Cross-Plattform-Development لأنها أقل قاسم مشترك في كل تقنية تقريبًا.

تضمين التغريدة

مترجم لغة دارت الذي يعمل في VM

هذا ليس دقيقا.

يستخدم Flutter Dart VM في وضع التصحيح ، مما يجعل أيضًا إعادة التحميل السريع ممكنًا.
في بنيات الإصدار ، يتم تجميع Dart إلى رمز ثنائي مثل C ++.

zoechi شكرا لك ، لم أكن أعرف هذا. هذا يبدو جيدا للأداء

هذا يبدو جيدا للأداء

وهو مطلب لمتجر Apples App Store.

لقد تقدم النموذج الأولي dart:ffi إلى النقطة التي نقرر فيها قرارات واجهة برمجة التطبيقات. (تتم مناقشة بعض قرارات التصميم هنا .)

لاتخاذ قرارات تصميم مستنيرة ، نود المزيد من الأمثلة حول واجهات برمجة تطبيقات C التي ترغب في ربطها. تشير هذه المشكلة حتى الآن إلى SQLite و Realm و OpenCV و Superpowered و ffmpeg. أي واجهات برمجة تطبيقات أخرى يجب أن نأخذها في الاعتبار؟

dcharkes لا أعرف ما إذا كان ذلك
https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/jni/TgNetWrapper.cpp
كما أنه يتعامل مع تشغيل GIF باستخدام ffmpeg ، والكتابة مباشرة على Android Bitmaps:
https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/jni/gifvideo.cpp

قد يكون من المثير للاهتمام أن يكون لديك طريقة لتحليل الهواتف والعناوين من خلال libpostal لاستمارات التسجيل. أيضًا glfw + flutter-embedder وربما يومًا ما سنرى تطبيق سطح مكتب مكتوبًا بالكامل في dart.

+1 لـ SQLite و Realm. يرجى أيضًا إلقاء نظرة على Couchbase ،

هل ستكون واجهات Firebase C ++ مثيرة للاهتمام؟ https://firebase.google.com/docs/reference/cpp/

لم يتم النظر في الأمر كثيرًا ، ولكن كان يعتقد أنه قد يكون قادرًا على استبدال مكونات iOS و Android الإضافية بمكوِّن إضافي واحد يتحدث إلى C ++ مباشرة.

يجب أن تحصل بعض مكتبات التشفير على بعض الحب مثل الحلقة من الصدأ - https://github.com/briansmith/ring

+1 لـ OpenCV و Realm و SqlCipher (https://github.com/sqlcipher/sqlcipher)

مكتبات التشفير. على وجه الخصوص libsodium أو tink.

https://github.com/google/tink

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

توجد بالفعل مكتبة flutter-sodium ، وهي تتحدث من خلال قنوات النظام الأساسي إلى أغلفة libsodium على كل منصة ، ثم إلى المحتوى الأصلي.

مكتبات الخرائط المخصصة مثل mapbox-gl https://github.com/mapbox/mapbox-gl-native

إن معالجة SMTP / IMAP (للدردشة عبر البريد الإلكتروني) لـ Flutter عبر https://github.com/deltachat/deltachat-core هو شيء أحب استخدامه مباشرة.

إذا كنت جريئًا جدًا في إعادة الصياغة ، فإن حالات الاستخدام الشائعة هي على النحو التالي:

1. الوصول إلى أجهزة الصوت / الفيديو بزمن انتقال منخفض (مثل ، Superpowered)
2. الأجهزة بمساعدة معالجة الصوت والفيديو (مثل ، ffmpeg)
3. الوصول إلى مأخذ التوصيل المستند إلى TCP ، لـ XMPP / البروتوكولات الأخرى الموجهة نحو الشبكة
   (للدردشة ، دفع الإخطارات)
4. ترقيات مستوى العملية (الوصول إلى الجذر) / سلاسل التفريخ بتنسيق
   طريقة متوافقة عبر الأنظمة الأساسية (لتطبيقات النظام ، تعدد المهام ، المحاكيات)

قد يكون هناك المزيد من حالات الاستخدام ، ولكن هذه هي الحالات الأولية التي تصلني
عقل _ يمانع.

شكرا لكم جميعا على تقديم أمثلة! هذا مفيد جدا.

@ Skills-up لاحظ أننا مهتمون أكثر بكثير بالأمثلة الملموسة ، بدلاً من التصنيف المجرد. هذا لأننا نريد تقييم بيئة عمل FFI على أمثلة محددة.

الغريب أن إحدى اللغات التي تقدم أفضل واجهة من / إلى C ++ هي Rust ، من خلال نظام الماكرو القوي + نظام البناء ، على الرغم من وجود نهج مختلف تمامًا عن OO.

أود أن أقول OpenSSL ، نظرًا لأننا نحتاج إلى التوقيع رقميًا على طلبات الصابون وملفات xml (XMLDSig ، Xades l) باستخدام شهادات العميل.
Dart نفسها بها BoringSSL ، لكن جزء منها فقط مكشوف من خلال Dart. لذا فإن أفضل شيء هو استدعاء opensl libs الأصلي من الرفرفة

آمل ألا أقوم بإرسال رسائل غير مرغوب فيها ، ولكني أرغب أيضًا في الحصول على تكامل أفضل مع Tensorflow lite ، وليس المرور عبر JNI ، وهذا سيكون رائعًا لعمليات الفيديو

لم يتم النظر في الأمر كثيرًا ، ولكن كان يعتقد أنه قد يكون قادرًا على استبدال المكونات الإضافية لنظامي التشغيل iOS و Android> بمكوِّن إضافي واحد يتحدث إلى C ++ مباشرة.

بصرف النظر عن دعم C ++ ، سيكون من الرائع أن يكون هناك مكون إضافي يمكنه التحدث إلى Go مباشرة. في الوقت الحالي نتحدث عن الانتقال من خلال قنوات منصة gomobile & flutter التي تبطئ استجابة واجهة المستخدم. سيساعدنا الحصول على دعم أصلي لـ Go و C ++ في Flutter أيضًا في الحفاظ على قاعدة رمز موحدة (منطق الأعمال / الخوارزمية) لأنظمة أساسية متعددة.

+1 للوصول إلى المكتبة الأصلية.

أرغب في الوصول إلى Vulkan / MoltenVK دون الحاجة إلى إنشاء قنوات نظام أساسي لنظام Android / iOS والحفاظ على مكونين إضافيين (والذي سيكون ضخمًا أيضًا). سيسمح ذلك ببناء تطبيقات ثلاثية الأبعاد وتحويلها إلى عنصر واجهة مستخدم Texture ، بينما يتم تطويره في Dart فقط. تبدو قنوات النظام الأساسي وكأنها حل بديل. أرغب في الوصول إلى المكتبات الأصلية دون الحاجة إلى كتابة غلاف لكل منصة والمحافظة عليها متى كان هناك إصدار جديد لتلك المكتبة.
أعتقد أن هذه الميزة ستجذب المزيد من المطورين.

نعم ، الرجاء الوصول المباشر للمكتبة الأصلية من الرفرفة.
أرغب في استخدام مكتبة c ++ في الرفرفة.

نعم ، الرجاء الوصول المباشر للمكتبة الأصلية من الرفرفة.
أرغب في استخدام مكتبة c ++ في الرفرفة.

نحن الآن في مرحلة نود أن نقدم فيها معاينة مبكرة للحصول على بعض التعليقات.

لمزيد من التفاصيل ، يرجى الاطلاع على التحديث في علة تتبع دارت .

@ mit-mit هل سيساعد هذا في حل هذه المشكلة: هل يمكنني الاتصال بمكتبة Python مع الرفرفة أو استخدامها ؟

في وقت متأخر إلى الحزب، ولكن +1 لSQLCipherdcharkesmraleph

@ doc-rj نحن الآن في المرحلة حيث يجب أن تكون قادرًا على تجربة ربط SQLCipher وإعطائنا ملاحظات على تجربتك. انظر إلى هذا التعليق .

أود التأكيد على أننا لا نهدف حقًا إلى توفير أي روابط مكتبة محددة لأنفسنا - لأن الطلبات متنوعة للغاية ، لكننا نهدف إلى تمكين الجميع وأي شخص من الارتباط بأي مكتبة باستخدام واجهة برمجة تطبيقات C.

أعتقد أن الحاجة إلى هذا تزداد الآن بعد أن تم الإعلان عن منصات متعددة.

هل هذا جزء من أي خارطة طريق؟

felemedeiros ، العمل قيد التقدم - إذا كان لديك مكتبة تريد هذا التعليق للحصول على معلومات.

لم يتم النظر في الأمر كثيرًا ، ولكن كان يعتقد أنه قد يكون قادرًا على استبدال المكونات الإضافية لنظامي التشغيل iOS و Android> بمكوِّن إضافي واحد يتحدث إلى C ++ مباشرة.

بصرف النظر عن دعم C ++ ، سيكون من الرائع أن يكون هناك مكون إضافي يمكنه التحدث إلى Go مباشرة. في الوقت الحالي نتحدث عن الانتقال من خلال قنوات منصة gomobile & flutter التي تبطئ استجابة واجهة المستخدم. سيساعدنا الحصول على دعم أصلي لـ Go و C ++ في Flutter أيضًا في الحفاظ على قاعدة رمز موحدة (منطق الأعمال / الخوارزمية) لأنظمة أساسية متعددة.

لقد كتبت مقالًا عن كيفية استدعاء Go Library API من Flutter. قد يكون مفيدا لشخص مهتم https://medium.com/@archan.paul/using -go-library-in-flutter-a04e3496aa05

كيف يمكنني إضافة كود c ++ على تطبيق Flutter؟

كيف يمكنني إضافة كود c ++ على تطبيق Flutter؟

أعتقد أن الخيار الوحيد الآن هو استخدام C ++ -> JNI (لنظام Android) -> طريقة PlatformChannel حتى يكون لدينا طريقة أكثر أناقة للقيام بنفس الشيء !!

لقد قمت بإنشاء مشروع يسمى ezored (http://ezored.com). سيكون أمرًا رائعًا إذا كان بإمكاني تمرير الكائنات المعقدة إلى Flutter دون الحاجة إلى التحويل إلى شيء آخر ، لأنه موجود بالفعل في Java و objc. يمكن لأي شخص استخدام ezored لإنشاء SDK (أو تنزيل تم إنشاؤه مسبقًا) لاختبار تكامل Flutter بين أصلي و Dart. يحتوي على طلبات ، وتحليل ، واستخدام خشن لقاعدة البيانات والكثير من الأشياء في SDK التجريبي الذي تم تنفيذه بالفعل.

أنا أبحث في مجموعات flutter ولكن ليس لدي أي طريقة لتمرير الكائنات وقائمة الكائنات إلى Flutter مباشرة.

شكرا في اي مساعدة.

أي تقدم جديد؟ يبدو أن أكثر من 2.5 سنة مرت ...

fzyzcjy نحن نعمل على ذلك. لقد أصدرنا معاينة مبكرة. راجع https://github.com/dart-lang/sdk/issues/34452#issuecomment -482136759 حول كيفية المشاركة.

منذ هذه المعاينة المبكرة قمنا بإضافة دعم Intel 32 و Arm 64 و Arm 32. لم يتم إصدار هذه الأنظمة الأساسية بعد على مستقر أو مطور ، فهي متوفرة فقط في الفرع الرئيسي لـ Dart sdk. يجري تتبع التقدم هنا .

dcharkes سعيد جدا لسماع ذلك! شكرا على عملك العظيم!

أي تقدم؟

للحصول على تحديثات الحالة والمعلومات الإضافية ، يرجى الاطلاع على https://github.com/dart-lang/sdk/issues/34452. يحتوي أعلى تعليق هناك على آخر تحديث.

عند استخدام flutter لإنشاء تطبيق ويب ، هل سيكون استخدام ffi مع مكتبة التيار المتردد ممكنًا؟

عند استخدام flutter لإنشاء تطبيق ويب ، هل سيكون استخدام ffi مع مكتبة التيار المتردد ممكنًا؟

هذا غير محتمل. من الناحية النظرية ، يمكن دعمه باستخدام WebAssembly ، ولكن هذا ليس شيئًا نعمل عليه حاليًا.

@ مع - مع حقا？

عند استخدام flutter لإنشاء تطبيق ويب ، هل سيكون استخدام ffi مع مكتبة التيار المتردد ممكنًا؟

هذا غير محتمل. من الناحية النظرية ، يمكن دعمه باستخدام WebAssembly ، ولكن هذا ليس شيئًا نعمل عليه حاليًا.

لماذا يتطلب WebAssembly؟ إذا كان بإمكانك أن تطلب من الأشخاص إعادة بناء WebAssembly في المستقبل ، فيمكنك أن تطلب منهم إعادة الإنشاء إلى ASM.js الآن.

@ nic-hartley إنها فكرة جيدة ، لكن التحدي ليس في كيفية تجميع الكود الأصلي ، بل في إنشاء الجسر بين Dart (المترجمة كـ JS) والكود الأصلي ، أيًا كان الشكل الذي يتخذه.

يعتبر FFI الأصلي منخفض المستوى للغاية لأسباب تتعلق بالأداء ولا يمكن ترجمته بسهولة إلى asm.js أو WebAssembly.

للتوضيح ، أعني أن مستوى التنفيذ لدينا منخفض للغاية - إنها بالتأكيد ميزة مثيرة للاهتمام ، لكن الأمر سيستغرق الكثير من العمل لتقديمها.

الرفرفة ليست سوى لعبة حتى تدعم c ++

لقد جئت إلى هنا لترديد نفس النقاط من قبل الآخرين ، حتى يتمكن Flutter من التفاعل بسهولة مع C ++ (بدون مكتبة جسر ، وبدون عقوبة أداء) ، لن يتم اعتماده أبدًا من خلال التطبيقات واسعة النطاق مع استثمارات في المكتبات الأصلية الحالية ، أو التطبيقات حيث يكون الأداء هو الأولوية القصوى.

سألاحظ أنه حتى React Native يستخدم جسرًا حاليًا ، لذلك يبدو أن Flutter هو في الواقع متقدم على المنحنى من حيث محاولة تنفيذ FFI.

يعد التكامل مع C ++ أمرًا بسيطًا على iOS مع AppKit. هذا ما يجب أن نقارنه وليس رد الفعل الأصلي.

UWP & C ++ تافهة أيضًا.

أنا بشكل عام مع حزب "دعم جهود Dart FFI" أيضًا ، على الرغم من ...

قد تكون Xamarin مقارنة أكثر ملاءمة من UWP ، لكن طرق عرض Xamarin عبر النظام الأساسي لم تكن تقريبًا قابلة للتخصيص مثل Flutter وغالبًا ما تتطلب الكثير من التعليمات البرمجية الأصلية للحصول على مظهر لائق.

هذا ليس صحيحا. على عكس Flutter ، يحتوي Xamarin على روابط النظام الأساسي بواجهة برمجة التطبيقات الأصلية (مثل Xamarin.iOS و Xamarin.Android) ، ويسهل على مطوري التطبيقات كتابة تنفيذ خاص بالنظام الأساسي بلغته الخاصة (C # /. NET). تتعلق هذه المشكلة بميزة اللغة ويجب عدم خلطها بتصميم واجهة برمجة تطبيقات واجهة المستخدم المصغرة.

هناك الكثير من استخدامات واجهة برمجة التطبيقات الأصلية ، ولكن لا يوجد استدعاء للكود الأصلي ، حيث سيكون Flutter على نفس القارب (على الرغم من أن Xamarin لا يتطلب كتابة Java أو ObjC هناك ، مع عدم وجود اختراق انعكاسي في كود التطبيق). بالنسبة إلى الكود الأصلي ، حتى في Xamarin.Android نفسه (أحد الخلفيات الخلفية لمنصة الواجهة الخلفية) ، فإن استخدام الكود الأصلي قليل جدًا ، ولا يكتب مطورو التطبيقات أي كود أصلي.

وعلى عكس React Native أو Xamarin ، فإن Flutter تقدم إطارها الكامل ، لذا فمن العدل تمامًا أن نقارن إطار عمل Flutter بأكمله بأشياء مثل AppKit.

من الغريب أنه لم يذكر أحد إطار Qt الذي يتقدم بفارق كبير عن كل شيء آخر فيما يتعلق بتكامل C ++

QT هي C ++. ولديه رخصة غير مواتية في البداية.

في الإثنين، 12 أغسطس 2019، 06:41 فلاديسلاف Stelmakhovskyi <
[email protected]> كتب:

من الغريب أن أحداً لم يذكر إطار عمل Qt الذي ينتظرنا كثيرًا
كل شيء آخر يتعلق بتكامل C ++

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/flutter/flutter/issues/7053؟email_source=notifications&email_token=AGDYMWXHTJUBUW64LEOO27TQEDSWNA5CNFSM4CXY6LYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63HS4DFVREXG43VMVBW63HS4DFVREXG43VMVBW63HS4DFVREXG43VMVBW63HS4DFVREXG43VMVBW63HS4DFVREXG43VMVBW63H2MV
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AGDYMWTNMTM7QUOY2BEIPM3QEDSWNANCNFSM4CXY6LYA
.

Qt هي C ++ و QML (محرك JS)
ما الترخيص؟ LGPL؟ GPL؟ ما العيب بها؟

أولاً من IANAL ، ولكن كما أفهمها ، فإن معظم Qt هو LGPL (IDE وما إلى ذلك هو GPL) ، مما يعني أنه يحتوي على لغة لا تمنع صراحة الربط الثابت ، إلا أنها تجعل من الصعب القيام بها أثناء الالتزام بالترخيص إذا كان طلبك هو مغلق المصدر.

من الناحية الفنية ، إذا كنت تستخدم LGPL فقط وقدمت ملفات الكائنات الخاصة بك (وربما الإرشادات) حتى يتمكن المستخدمون من إعادة الارتباط بإصدار مختلف من المكتبة ، فأنت تفي بمتطلبات LGPL. لكنني متأكد تمامًا من أن شركة Qt لا تعلن عن هذه الحقيقة ، لذا فإن المفهوم الشائع هو أنه لا يمكنك نشر مكتبات ثابتة مما يعني أنه لا يمكنك إطلاق تطبيقك في متجر التطبيقات دون دفع رسوم الترخيص الباهظة. وقد أكون مخطئًا بشأن توفير ملفات الكائنات ، وهذا مجرد فهمي لها ، ولا أعرف ما إذا كانت هناك أي شركة تقوم بذلك.

يعد Android أسهل لأنه يسمح بالمكتبات التي يتم تحميلها ديناميكيًا والتي يُسمح بها بشكل أكثر صراحة بموجب LGPL ، ولكن في جميع الروابط الثابتة بصراحة ، من المحتمل أن يكون هناك أيضًا الأفضل للحفاظ على حجم التطبيق منخفضًا مما يعني الوقوع في نفس المشكلة.

مرحبًا cpboyd ، أعتقد أنني أنظر إلى هذا من الاتجاه المعاكس. لدينا بالفعل تطبيقات مبنية على أطر عمل واجهة مستخدم خاصة بالنظام الأساسي ، حيث تتيح لنا كل منصة استخدام مجموعتنا الواسعة من مكتبات C ++ الحالية. أفهم أن Flutter عبارة عن منصة مشتركة ، وهو أمر رائع ، ولكن ما لم أتمكن من استخدامها بالفعل (مع الكود الحالي) ، فمن الأفضل أن ألتزم بواجهة مستخدم غير مشتركة بين الأنظمة الأساسية. تأتي النقطة الشائكة الوحيدة عندما يتطلب نظام تشغيل مستقبلي (مثل Fuchsia) استخدام Flutter & Dart ، لكنه لا يسمح بحالة الاستخدام هذه. في هذه الحالة ، من المحتمل أن يتجاهلها أي شخص لديه قواعد أكواد حالية كبيرة.

أعتقد أنني لست متأكدًا مما إذا كان يتم تصميم Flutter / Dart مع وضع تطبيقات "الويب" في الاعتبار (على سبيل المثال ، حيث توجد الخلفيات على الويب) ، أو أنه يتم الاهتمام بجدية باحتياجات مطوري تطبيقات سطح المكتب المحترفين. في نهاية المطاف ، يمكن أن تؤثر مثل هذه القرارات على عدد وجودة العديد من التطبيقات في متجر التطبيقات. إذا كان بإمكاني كتابة تطبيق احترافي عالي الجودة لنظام iOS باستخدام UIKit ، باستخدام ملايين الأسطر من الكود الحالي ، لكن لا يمكنني (بتكلفة أداء تقترب من الصفر) إذا كنت أقوم بتطوير Fuchsia / Flutter / Dart ، فحينئذٍ أن أكون نظامًا أساسيًا ونظامًا أساسيًا لن أطوره من أجله.

الهدف من منشوراتي ليس مقارنة Flutter بالمكتبات الأخرى التي تعمل عبر الأنظمة الأساسية أو التي لا تعمل عبر الأنظمة الأساسية ، بل لتسليط الضوء على حالات الاستخدام المهمة لمجموعة فرعية من المطورين.

يعد Dart FFI مثيرًا للاهتمام ، من قراءة _very_ الموجزة لمثال sqllite ، يبدو مشابهًا لـ C # مع PInvoke ، لكن لسوء الحظ هذا غير مناسب لـ C ++ ، حيث إن كل نوع تتعامل معه تقريبًا سيحتاج إلى التفاف ، أو يجب عليك الكتابة بعض أنظمة الواجهة العامة بالكامل بدون نوع للالتفاف في C ++. لا يكون أي من هذين الخيارين جذابًا بشكل خاص عند مقارنته بسهولة فئة Obj-C التالية:

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

أو UWP مع C ++ / WinRT:

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

شكرا :-)

HixieMarkIngramUK لا يوجد أي من هذين
AppKit مخصّص لـ Apple فقط ، بينما UWP يعمل بنظام Windows فقط.
ربما إذا استخدم Flutter Swift أو C # بدلاً من Dart ، فسنحصل بالفعل على نفس المستوى من الدعم ، لكن هذه حجة مختلفة تمامًا.
قد تكون Xamarin مقارنة أكثر ملاءمة من UWP ، لكن طرق عرض Xamarin عبر النظام الأساسي لم تكن تقريبًا قابلة للتخصيص مثل Flutter وغالبًا ما تتطلب الكثير من التعليمات البرمجية الأصلية للحصول على مظهر لائق.
لا يزال اقتراحي قائمًا: إذا كنت تريد استخدام Flutter مع C ++ ، فيجب عليك المشاركة في معاينة FFI لفريق Dart والمساعدة في تحسين الدعم لنا جميعًا 😃

تتعلق هذه المشكلة بميزة اللغة ويجب عدم خلطها بتصميم واجهة برمجة تطبيقات واجهة المستخدم المصغرة.

atsushieno بالتأكيد ، ولهذا السبب ستكون هذه المناقشة أكثر إنتاجية في منتدى Dart FFI ... Flutter هو إطار العمل. دارت هي اللغة.

لا يكون أي من هذين الخيارين جذابًا بشكل خاص عند مقارنته بسهولة فئة Obj-C التالية:

MarkIngramUK أنا متأكد من أن هذا هو بالضبط نوع التعليقات التي يحب فريق Dart الاطلاع عليها على https://groups.google.com/forum/#!forum/dart -ffi

لدي مشروع يسمى ezored (https://ezored.com) وهو مشروع تمهيد C ++ لحزم SDK والتطبيقات في C ++. نحن نستخدم في مشاريع الهاتف المحمول (Android و iOS). أنا في انتظار انتهاء FFI لإنشاء مشروع يستخدم SDK الافتراضي في الرفرفة.

ليس لدينا أي مشاكل مع C ++ ويتم تقليل وقت تطوير الميزات الجديدة ، نظرًا لأن SDK لها نفس الكود في جميع الأنظمة الأساسية ، كما ترى في التنفيذ الافتراضي (مشروع poco ، openssl ، sqlite ، كود نظام أساسي محدد متكامل مع رمز الجسر وما إلى ذلك).

في خياري هذا هو أفضل طريقة:

• iOS و Android مع خلفية C ++ (ezored)
• Flutter و C ++ كخلفية

لا تتردد في إضافة بداية للمشروع :)

يمكن أن يكون Kotlin Multiplatform حلاً بديلاً وليس فكرة مثالية. ما زلت بحاجة إلى انتظار https://github.com/dart-lang/sdk/issues/34452

يبدو أن Unity3d تقوم بطريقة ما بنقل الرفرفة إلى محركها الذي يعتمد على C # VM [1] - في هذا العالم يعد التحدث بين C # و C ++ أمرًا لائقًا. ربما يستحق إلقاء نظرة على الريبو الخاص بهم كيف حلوا بعض المشكلات. يذكرون أن: "UIWidgets مشتق بشكل أساسي من Flutter". أود أيضًا أن ألقي نظرة على رد فعل المعسكر الأصلي ونهجهم الجديد مع TurboModules - قد يكون للحل الخاص بهم نهج ميزة على الرفرفة حيث سيكون
1) متزامن وغير متزامن و
2) لن يكون هناك أي تنظيم و
3) لن يدعم C فقط ولكن C ++

أنا أشجع كلا المعسكرين.

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

اعتبارًا من Dart 2.5 ، هذا ( dart:ffi ) الآن في المعاينة:
https://medium.com/dartlang/announcing-dart-2-5-super-charged-development-328822024970

أخبار رائعة!

ط ط ط .. هل يكفي استخدام المزمار مع الرفرفة؟ ..

https://github.com/google/oboe

تضمين التغريدة لكن ، ستحتاج إلى كتابة بعض أغلفة C لأن واجهة Oboe في C ++.

يمكنك الاطلاع على https://github.com/flutter/flutter/wiki/Binding-to-native-code-via-FFI للحصول على إرشادات حول البدء.

يمكنك إعادة استخدام oboe-c.so الذي كتبته لربط C # الخاص بي ، إذا كان ذلك يعمل https://github.com/atsushieno/oboe-sharp/tree/master/native

@ sjindel-google ، هذه بعض الأخبار الرائعة!

لذلك أحتاج إلى إنشاء جسر بين كود C ++ و C عن طريق إنشاء فئات ووظائف. وبعد ذلك يمكنني استخدام تلك الفئات واستدعاء هذه الوظيفة من كود Dart. أعتقد أن ذلك صحيح.

atsushieno ، شكرًا لك. أنا ألقي نظرة. لست متأكدًا من كيفية بناء الجسور في حالتي (نقص الخبرة). لكن هل تمكنت من تحقيق هدفك العام المتمثل في اللعب الدقيق مع المزمار؟ هل كان ذلك جيدا؟

@ rg4real كنت أفعل ذلك لمجرد واجهة برمجة تطبيقات أبسط (مقارنة بـ OpenSLES) من الصوت ذي زمن الوصول المنخفض. إذا كنت جادًا حقًا بشأن وقت الاستجابة ، فلن أستخدم Xamarin.Android. إذا كنت تتحدث عن Oboe (أو AAudio خلفه) ، فأنا أستخدمه في

هل هناك أي دليل حول كيفية إدارة الذاكرة؟

إذا كان كود C ++ ينشئ ذاكرة باستخدام new / malloc ويعود إلى رمز dart ، كيف يتم تحرير تلك الذاكرة.

كود c ++
void foo (char ** out) {
* خارج = حرف جديد [25] ؛
}

كيف احذف الذاكرة المخصصة لـ | out | متغير من رمز دارت؟

إذا كنت تستخدم Dart 2.5 ، فهناك .free() على Pointer . إذا كنت في فرع dev / master ، فقد نقلت هذه الطريقة package:ffi https://github.com/dart-lang/ffi/blob/master/lib/src/allocation.dart#L70.

وفقًا للتعليق - "لا يجوز استخدامه إلا مقابل المؤشرات المخصصة بطريقة تعادل [التخصيص]." - يمكن استخدام () free فقط إذا تم تخصيص الذاكرة باستخدام طريقة التخصيص ().

على سبيل المثال
ffi.Pointerptr = ffi.Pointer.allocate () ؛
ptr.free () ،

هل هذا يعتني بتحرير الذاكرة المخصصة في جانب C ++ باستخدام إما new or malloc من dart code؟

طالما تم تخصيص الذاكرة من خلال malloc ، إما عبر Dart أو C ++ ، يمكن تحريرها بـ free .

في Dart 2.6 نستخدم DynamicLibrary.lookupFunction("free") لتعريف free في Dart ، لذلك سيكون بالضبط نفس free كما في جزء C ++ من البرنامج. (ما لم تكن تقوم بالربط في إصدارات متعددة من free في برنامجك الثنائي.)

إغلاق هذه المشكلة لأن هذه الميزة متاحة الآن بشكل عام (في مرحلة تجريبية) في جميع قنوات Flutter. نحن نواصل تحسين المشكلة. لأية مشاكل مفصلة ، يرجى إرسالها في https://github.com/dart-lang/sdk/issues/new.

جعل فصول c ++ للتوافق c فوضوي. بلز تجعل القدرة على استدعاء فئات c ++ مباشرة

+1 هل يمكننا الحصول على دعم C ++؟

KaungZawHtet و fzyzcjy - يرجى التفكير في فتح عدد جديد (ربما في dart-lang بدلاً من flutter) لهذا الغرض.

سأقوم بإغلاق هذه المشكلة - هناك الكثير من الأشخاص المشتركين فيها ، ولكن تم حل هدفها الأصلي بشكل واضح.

نعم ، بالنسبة للأعداد الجديدة ، يرجى إرسالها باستخدام هذا الرابط: https://github.com/dart-lang/sdk/issues/new؟