Godot: حول مستقبل تصدير Android

أصوت لصالح الاقتراح 2.

إذا كنا نتحدث عن إعادة هيكلة آلية تصدير apk ، أعتقد أنه قد يكون من المهم معرفة الميزة المفقودة من Godot Engine:

1. محتوى APK الديناميكي : السماح بإنشاء apk أخف
2. تطبيق Google الفوري : يمكن للمستخدم تشغيل اللعبة / التطبيق الخاص بك دون تثبيته
3. الرموز التكيفية : تتطلب أحدث إصدارات Android (Android P ، وبعض Android 7.1+) رموزًا قابلة للتكيف.
4. معالج الأعطال: يفتقد Godot Engine إلى واجهة برمجة تطبيقات معطلة. بمعنى أنه عند تعطل محرك Godot ، يجب أن نكشف عن وظيفة تسمح للمستخدمين بإرسالها إلى تطبيق تحليل الأعطال المفضل لديهم
5. تعطل ANR الآن ، لذلك عند بدء اللعبة ، يجب أن نستخدم AsyncTask بدلاً من UIThread.

أثناء قيامنا بإعادة بناء آلية التصدير ، يجب علينا أيضًا إضافة هذه الميزات إلى Godot Engine.

تصويتي => 2

ربما هجين؟
استخدم الطريقة القديمة إذا لم يتم العثور على sdk للاختبار في وضع التصحيح ، ولكنه يتطلب تثبيت SDK لحزمة الإصدار. إذا تم العثور على sdk ، فاستخدمه في وضع التصحيح والإصدار.
أنا أصوت 2 ، لأنه دائمًا ما يكون شرطًا إذا كنت تعمل في نظام Android.

xsellier سأكون ممتنًا لأن هذه الحجة لا تتجاوز ما تم اقتراحه في OP ، إذا أراد شخص ما تنفيذ ما ذكرته ، فهذا أمر جيد ، ولكن دعنا من فضلك لا تخرج عن مسارها.

HeartoLazor الكود الأقل للمحافظة عليه هو أفضل منظمة imo ، لذلك إذا كنت تريد رقم 2 ، فإن Hybrid هي فكرة سيئة.

أنا أيضا أصوت للمقترح 2.

بمجرد إعداد أدوات Android ، فإن الكثير من العمل غير مؤلم إلى حد كبير ، مثل تنزيل sdk جديدة وبناء libs خارجية.

سيكون من الأسهل أيضًا إضافة مكتبات تابعة لجهات خارجية.

أنا أصوت للخيار 2

يبدو الخيار 2 أكثر ملاءمة. يعد Gradle أداة رائعة ، وإضافة المكتبات وإدارة عملية البناء أسهل بكثير من التدفق الحالي.

تصويتي للاقتراح 2

لقد أنشأت ذات مرة منشئ قالب android كملحق لـ 2.x.
https://github.com/vinod8990/godot-addon-aetc

ومع ذلك فإنني أصوت على الاقتراح 2.
إذا وضعنا معيارًا ، فحينئذٍ نحتاج إلى التأكد من أن الوحدة تزيل api أيضًا. إنه PIA ضخم عندما نحتاج إلى إزالة مكون إضافي أصلي (كما في حالة Unity).

التصويت -> الاقتراح 2: يبدو أنه الخيار الأكثر منطقية ، فإن Godot حاليًا وفي المستقبل القريب أفضل محرك لعبة لتطوير الأجهزة المحمولة وتكامل adob / الأدوات بشكل أفضل أمر لا بد منه عندما يتعلق الأمر بالتصدير إلى Android والمنصات المحمولة.

هل هذا يعني أيضًا أنه سيتم تحسين تصدير iOS أيضًا.؟ على الأقل في المستقبل القريب.

التصويت لـ Propsal 2: بعض تكامل المكتبة مطلوب لإعادة إنشاء apk مع ملفات خاصة بالتطبيق مثل google-services.json لـ firebase أو تخصيص strings.xml لـ facebook api. في Godot 2 ، كان لدي تصحيح SConstruct / SCsub / features.py وبعض ملفات القوالب من أجل دمج بعض lib بشكل صحيح.

يبدو أن هناك اتفاقًا في الغالب هنا .. لذلك أعتقد أن قرصنة APK يجب أن تختفي ، ويجب أن تكون قوالب التصدير إلى حد كبير دليل Android قبل تشغيل Gradle ..

أي شخص مستعد لتقديم اقتراح أو العلاقات العامة للخيار رقم 2؟ :)

حسنًا في الوقت الحالي ، لقد عانيت من الكثير من الألم عند إضافة المشاركة ووحدات Admob ، لأنه يوجد حاليًا خطأ في طريقة get_data من النسيج ، لذلك بعد التجميع وإلا ستخسر.

كما يجب أن يكون لدي تكوين محدد لجعل كل شيء يعمل معًا java و gradle وغير ذلك ، وهو أمر جيد ولكنه صعب.

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

لذا سيكون الخيار # 2 مع بعض مربعات الاختيار لتحسين نظام Android أمرًا رائعًا.

بالطبع أنا أقدر الجهد المبذول في خلق كل هذه البيئة التصديرية.

يبدو الرقم 2 أكثر نظافة ، لذا أعتقد أنه أفضل من الاستمرار في العمل على اختراق قد يؤدي إلى حدوث مشكلات في المستقبل.
قلقي الوحيد هو وقت النشر. يعد الاختبار حاليًا على نظام Android سريعًا حقًا ، ويعتمد بشكل أساسي على حجم أصولك. هل سيؤثر الخيار 2 بشدة على وقت الإنشاء؟
على أي حال ، ما زلت أعتقد أن هذا هو السبيل للذهاب. سيكون الأمر يتعلق بالاعتماد أكثر على مزامنة المشهد / البرنامج النصي للاختبار.

يعتبر Proposal 2 أفضل بكثير لأن Google Play يتطلب دائمًا إنشاء ملف apk باستخدام أحدث إصدار من Android SDK.

وأيضًا GDnative يشعر بالألم عندما أحاول الاندماج مع IAP لجهة خارجية وإعلانات من Amazon و Leadbolt وما إلى ذلك.

الاقتراح 2 بالتأكيد.

تم استخدام أساليب مماثلة بالفعل في بعض المشاريع الكبيرة مثل Cordova و Flutter . سيكون الخيار الرائع هو إمكانية فتح المشروع في Android Studio إذا أراد المستخدم التحكم بشكل أكبر في إنشاء APK.

يبدو الخيار 2 أنظف وأكثر مثل باقي Godot ... أي أنه تم بشكل صحيح.

لقد مررت للتو بألم الحصول على تصدير android للعمل. كان أكثر ما يتألم هو تثبيت (إصدارات) الأدوات الصحيحة ؛ كان التكوين في Godot سهلاً.
في كتابي ، إذا كان القيام بذلك بشكل صحيح ينطوي على قدر مماثل من الألم عند تثبيت الأدوات المناسبة ، فإنه لا يزال يمثل خطوة في الاتجاه الصحيح ، لذلك أنا أيضًا أصوت لصالح رقم 2.
أشارك المخاوف بشأن سرعة التشغيل على Android لتصحيح الأخطاء ، ولكن إذا لم أتمكن من إطلاقها في المتجر في النهاية ، فهذه مشكلة كبيرة تحتاج إلى معالجة ؛ أريد أن أعرف أن المتجر سيكون متاحًا عندما أكون جاهزًا للإفراج عنه.

بالتأكيد # 2 :)

أنا مع الخيار 2 - تثبيت Android sdk ليس مشكلة ، ويفتح الكثير من الاحتمالات الأخرى.

على مستوى عالٍ ، يبدو الأمر مشابهًا لطريقة عمل Flutter ، https://github.com/flutter/buildroot

هل يعني الخيار رقم 2 أنه يتعين علينا تجميع المحرك بالكامل بما في ذلك C ++ و Java code لتصدير ملف apk android لكل مشروع في كل مرة؟

هذا سيكون كارثة! يستخدم Cocos Creator مثل هذا العمل الرهيب.

Geequlim إذا فهمت بشكل صحيح ، ليس c ++ ولكن java.

أنا مع الخيار رقم 1 ، عندما أقوم ببعض التجارب أو سير عمل تصحيح الأخطاء ، لا أريد حزمة Android هذه لتصحيح مشروع صغير ، حافظ على طريقة الاختراق ، دع المبرمج يقوم بسير عمل SDK.

Geequlim نعم ، هذا هو قلقي أيضًا. إذا احتاج المشروع إلى إعادة تجميعه وتعبئته في ملف apk في كل مرة أشعر أن الأمر سيستغرق وقتًا طويلاً.

JFonSGeequlim ليست هناك حاجة إعادة تجميع كامل. لدى Gradle الكثير من تحسين وقت البناء ، لذا ستكون هناك حاجة إلى التجميع الكامل (c ++ و Java) فقط لأول مرة. أيضًا ، عند تطبيق مكون إضافي تابع لجهة خارجية ، فسوف يقوم بتعديل كود Java ، وسيرى Gradle أنه تم تغيير بعض الملفات وإضافة تبعية واحدة ، وسوف يقوم بإعادة تجميع الأجزاء التي تم تغييرها فقط. في معظم الأوقات ، سينسخ المصدر موارد المشروع (المشاهد والنصوص والأصول) إلى مجلد android ، وسيقوم Gradle بتعبئة ملف apk من ملفات المصدر المخزنة مؤقتًا وهذه الموارد وتشغيلها على جهاز Android ، وهذا لا ينبغي أن يستغرق الكثير من الوقت.

@ veloc1 لا يزال يتعين علينا تجميع محرك الحفرة لكل حدث مشروع لاختبار العروض التجريبية من الأصول lib ، أليس كذلك؟

قد يتعطل سير عمل بناء التدرج بسبب الكثير من التفاصيل ：

• تم تثبيت الإصدار الخاطئ من SDK.
• لا يمكن تنزيل التبعيات باستخدام اتصال شبكة سيئ (هذا موجود بالفعل في الصين بدون وكيل).
• تبلغ مساحة الذاكرة المتاحة للجهاز أقل من 4 جيجابايت ولكن يتعين على بعض SDK التابعة لجهات خارجية تمكين multiDexEnabled true للترجمة.
• ...

ولا يتم دائمًا إعادة تجميع gradle كما هو متوقع.

ربما أكون مخطئًا ، لكنني أعتقد أن رقم 1 عبارة عن كوب من الحليب ورقم 2 بقرة حلوب. هل انا صائب؟

Geequlim كما يمكنني أن أتخيل ، لا نحتاج حقًا إلى إعادة تجميع المحرك بالكامل. يمكن تعبئة جميع الرموز في المكتبة (لذلك ، يجب أن يعيد كل إصدار من إصدارات Godot إنشاء مكتبة android باستخدام محرك Godot). عند إنشاء المشروع ، يمكن لمحرر Godot فك ضغط قالب android في مجلد "android" مع فئة جافا واحدة ، وملف Gradle مع تبعية Godot Engine android المضمنة من maven (يعمل React Native بنفس الطريقة ، كما تذكرت).
بهذه الطريقة يمكننا تقليل وقت الإنشاء واستخدام الذاكرة وتحسين بساطة مشروع android.

لكنك على حق ، هذا يتضمن أيضًا الكثير من القيود.

وبعض التعليقات على قائمتك للأشياء التي يحتمل أن تكون مكسورة:

• لا تلعب SDK دورًا كبيرًا ، لأن محرك Godot لا يستخدم الكثير من الميزات من sdk الجديد. بالنسبة للمشاريع البسيطة ، سيكون أي SDK تقريبًا على ما يرام. أيضًا ، يمكن أتمتة تنزيل sdk المناسب.
• يمكن أن تكون مشكلة التبعية التي وصفتها مؤلمة. يمكننا تضمين التبعيات مع ارتباطات من maven ، ولكن يمكننا أيضًا وضع ملفات المكتبات (jar أو aar) في مجلد المشروع ، واستخدام التبعية ، لذلك مع اتصال الشبكة السيئ ، يمكنك تنزيل جميع التبعيات في أماكن أخرى ، ووضعها على عصا USB ونقلها للمشروع. ولكن يجب وصف ذلك بشكل كبير في وثائق التصدير.
• لا يؤثر Multidex والذاكرة على بعضهما البعض. يمكن تمكين Multidex دائمًا في نموذج المشروع. ستكون الذاكرة قيدًا أقوى. لا أستطيع أن أقول بالضبط ، ما مقدار الذاكرة المتوفرة التي ستكون مطلوبة لذلك ، ولكن هذا يجب أن يكون أكبر من 2 غيغابايت.

وهناك اختتام للتغييرات التي يجب تنفيذها في Godot (حسب الطريقة التي وصفتها أعلاه):

• قم بإنشاء مكتبة android ، تحتوي على نظام المحرك والمكوِّن الإضافي. (هذا صعب)
• أتمتة بناء مكتبة android عند الإصدار ووضعها على المخضرم.
• اصنع قالب مشروع أندرويد.
• اجمع مجموعة من البرامج النصية للتحقق من البيئة وتنزيل Gradle و Java و Android Sdk
• قم بإجراء تغييرات في محرك Godot ، لذلك عندما يقوم المستخدم بتشغيل مشروع على جهاز android ، يجب على المحرك نسخ جميع الموارد واستدعاء مهمة Gradle لبناء المشروع وتشغيله.
• توثيق لكل الأشياء.

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

هل يعني الخيار رقم 2 أنه يتعين علينا تجميع المحرك بالكامل بما في ذلك C ++ و Java code لتصدير ملف apk android لكل مشروع في كل مرة؟

لا .. لا أرى أي سبب لذلك. هذا هو الحال الآن ، ولكن سير العمل الجديد سيحصل ببساطة على مشروع android في حالة سابقة الإنشاء (مع ملفات Godot .so). تعد إضافة وحدات خارجية قمت بتنزيلها في أدلة أخرى (مثل Admob) أمرًا سهلاً حقًا مع Gradle ، لذا يمكنك نظريًا تنزيل هذا الدعم من مكتبة الأصول وسيعمل بشكل سحري.

@ veloc1

يوجد بالفعل نظام ملحق يقوم بتعديل Gradle build لإضافة أشياء ، والتي على الأرجح لن تحتاج إلى تغيير أو تغيير بسيط.

سيتألف سير عمل "التشغيل / التصدير" الجديد من:
1) بناء Gradle (إذا لم تحدث تغييرات ، فلن يتم فعل أي شيء ، يجب أن يكون ذلك سريعًا جدًا
2) من المحتمل تشغيل منطق التصدير الحالي لفك ضغط ملف APK وإضافة الملفات والمكونات الإضافية gdnative وما إلى ذلك وإعادة ضغطها مرة أخرى .. لذلك سيظل التوقيع يتم بواسطة Godot وليس Gradle على ما أعتقد.

وبالمثل ، أعتقد أن Godot يمكنه إجراء التعديل المطلوب على AndroidManifest.xml قبل الإنشاء (تغيير الاسم وإضافة الأذونات والأشياء الأخرى) وإضافة الرموز وما إلى ذلك لتسهيل الأمر على المستخدمين الذين قد لا يكونون ودودين مع كيفية عمل البيان. الشيء الجيد هو أن هذا يتم بطريقة غير مدمرة ، لذلك لا يزال بإمكانك إضافة الأشياء الخاصة بك إلى Manifest.

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

لم أكن متأكدًا من أن التوقيع يجب أن يكون من جانب جودو. يحتوي المكون الإضافي Android لـ Gradle على ميزة رائعة لذلك https://developer.android.com/studio/build/build-variants#signing ، لذلك عند التصدير ، نتحقق فقط من مخزن المفاتيح وكلمات المرور ، ويقوم Gradle بكل العمل.

وللبيان. عندما أقول عن نظام المكونات الإضافية ، أعني هذا الشيء بالضبط: كل مكون إضافي يعلن الأذونات ، وعند التصدير نجمع جميع المكونات الإضافية المضمنة وننشئ AndroidManifest.xml. وبهذه الطريقة يمكننا أيضًا تضمين خدمات المكتبة وأجهزة استقبال Braodcast.

بالنسبة لموارد مثل الاسم والرمز - ماذا عن موارد العناصر النائبة ، وعندما يتم تكوينها في إعدادات المشروع ، ما عليك سوى استبدال العناصر النائبة بقيم من إعدادات المشروع؟ لذلك ، لن يرى المستخدمون النهائيون كل هذه الأشياء الرهيبة على الإطلاق.

هل سيكون من الممكن باستخدام سير عمل التصدير الجديد الحصول على حزمة اللعبة خارج APK بدلاً من ضغطها مرة أخرى (مجلد أو .pck)؟

LinuxUserGD ليس Apk Expansion (.obb) لذلك؟
هناك بالفعل.

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

بالنسبة للبيان ، أود أن أبقيه قابلاً للتعديل يدويًا أيضًا.

التصميم الحالي مرن للغاية بحيث يمكنني تعديل القالب وإضافة / حذف كل ما أريد ولن يتدخل أي شيء عند إنشاء القوالب.

أعتقد أن شيئًا مثل نظام هجين سيعمل؟

لا شك أن الاقتراح 2 يبدو أفضل وأنظف وأكثر "لائقا".
reduz سلبيات الاقتراح 2؟ أتخيل أنها مشكلة فقط عندما لا يتوفر الإنترنت السريع.
Godot ، مثل Android Studio ، من المحتمل أن يمرر بسهولة (كملف نصي؟) إلى sdkmanager قائمة بالحزم المطلوبة لتنزيل https://developer.android.com/studio/command-line/sdkmanager

الاقتراح 2 ، بالتأكيد.

الاقتراح رقم 2. تثبيت Android SDK سهل للغاية في الوقت الحاضر!

reduz ، أنا أصوت للاقتراح 2. لكن من فضلك لا تنسى # 18141

الاقتراح 2. تم توثيق Gradle أيضًا لذا سيكون لدينا المزيد من الموارد. معظم مطوري الأجهزة المحمولة لديهم android sdk مثبتًا في مكان ما على نظامهم على أي حال.

الاقتراح 2

متى سيتم تنفيذ هذا ، أي معلومات أو أي شيء
@ akien-mga هل ما زالت علامة فارقة لـ 3.1؟

وفقًا لهذه المدونة من

سيكون Godot 3.1 إصدارًا يغطي مساحة أكبر بكثير مما يتوقعه مستخدمونا ، لذلك لم نعد بحاجة إلى ميزات جديدة كثيرًا. الميزة الكبيرة الوحيدة المخطط لها بعد الإصدار 3.1 هي نقل العرض إلى Vulkan ...

حسنًا ، يبدو أن ميزة المشكلة الحالية قد حظيت باهتمام كافٍ للنظر فيها لـ 3.2. هل هناك أي سبب لعدم إضافته في المدونة؟

نفد الوقت لدينا لإعادة تصنيع كبيرة لتصدير Android ، لذلك سيكون هذا 3.2.

نظرًا لأن android يقدم مجموعة متنوعة من المكونات الإضافية وقواعد البيانات التابعة لجهات خارجية (Firebase ، Cloud ، ML ،) ، يبدو أنه من الجيد تثبيت android sdk / jdk / ndk من أجل التطوير المستمر ، والسبب هو أن مكتبات android تتغير مع الإصدارات الموجودة هناك. بعض مكتبات التبعية مفقودة عند التصدير بدون تثبيت إصدار مناسب من sdk ، لكن هذا النهج على العكس من ذلك يتطلب من المستخدم أو المطور النهائي شحن المنتج بالكامل إلى نظام android الأساسي فقط من أجل الاختبار الذي يتطلب وقتًا إضافيًا يمكن إجراء طريقة بديلة مثل إنشاء تطبيق لنظام Android يستخدم android studio sdk و jdk على الجهاز للاختبار ، ويمكن للمستخدم ببساطة تشغيل التطبيق والاتصال بالكمبيوتر باستخدام منفذ كابل ثم تشغيل اللعبة في محرر godot نفسه وعرض التغييرات على الهاتف أو الهاتف المحمول. يستخدم الهاتف المحمول android sdk للكمبيوتر من خلال منفذها وبقدر ما يتعلق الأمر Proposal1 ، هناك القليل من الوقت الزائد كما أنه يتسم بالشفافية تقريبًا ، فلا داعي للقرصنة.
نظرًا لوجود مكتبات معينة في كود android kernel والتي إذا لم يتم تثبيتها ستؤدي في الغالب إلى تعطل وقت التشغيل مع java.lang.io.exceptions. هناك أيضًا مشكلة يجب معالجتها وهي أنه إذا تم إعطاء الاقتراح 1 الأسبقية ، فهذا يعني أن القرصنة منفصلة تحتوي كل إصدارات من android على تبعيات أكثر من تلك السابقة. أشبه بجهاز تحكم عن بعد ، فبإمكانك إنشاء تطبيق كامل أو تصدير الطريقة المعممة 2.
بقدر ما يتعلق الأمر بالقوالب ، يمكن استخدام قوالب تكيفية android8 +. بالإضافة إلى ذلك ، يمكن استخدام تحسينات لمحرك التطبيق (باستخدام SDK) لتقليل وقت إنشاء التطبيق (باستخدام sdk) لتحسين جامعي القمامة وأيضًا التحسينات مثل النهج القائم على الهيكل. تستخدم.
هذا هو وجهة نظري تمامًا ، إذا كان الأمر جيدًا ، فلدي بعض الخطط الموضوعة بخصوص التطبيق (android) الذي يستخدم sdk للجهاز لإنشاء لعبة التطبيق بشكل فوري.

يقبل Google Play الآن التطبيقات التي تم تحميلها بتنسيق Android App Bundle (AAB) الجديد.

يسمح هذا التنسيق لـ Google Play بإنشاء ملفات APK ديناميكيًا للعديد من أنواع الأجهزة ، وإحدى الميزات التي تؤثر بشكل مباشر على الألعاب المصنوعة في Godot هي تعبئة ملفات APK التي تحتوي فقط على المكتبة الأصلية المصممة لهندسة وحدة المعالجة المركزية.

هذا يعني أنه يمكن تحسين حجم التنزيل بشكل كبير من خلال جعل ملف APK الذي تم تنزيله بواسطة جهاز x86 يحتوي فقط على مكتبة x86 ، والمكتبة التي تم تنزيلها بواسطة arm64 تحتوي فقط على مكتبة arm64 وما إلى ذلك.

أعتقد أن أي نهج يتبعه Godot يجب أن يدعم تنسيق التعبئة الجديد هذا ، لكنني لا أعرف مدى سهولة "اختراق" حزمة AAB على عكس حزمة APK التي هي في الأساس ملف ZIP.

هذا يعني أنه يمكن تحسين حجم التنزيل بشكل كبير من خلال جعل ملف APK الذي تم تنزيله بواسطة جهاز x86 يحتوي فقط على مكتبة x86 ، والمكتبة التي تم تنزيلها بواسطة arm64 تحتوي فقط على مكتبة arm64 وما إلى ذلك.

لاحظ أن هذا ممكن بالفعل ، لكنه يتطلب عملاً يدويًا عن طريق إنشاء ملف APK واحد لكل بنية ثم تحميله على Google Play باستخدام دعم APK المتعدد الخاص به.

تم إصلاح ذلك من خلال # 27781 ، والذي ينفذ بشكل أساسي مزيجًا من 1 و 2. يتم الاحتفاظ بالنظام القديم للنشر بنقرة واحدة ، ولكن سيتم شحن الإصدارات الآن مع مصدر القالب المجمع مسبقًا والذي يمكن إعادة تجميعه في ملف APK جديد مع وحدات مخصصة / التغييرات الواضحة / إلخ. باستخدام Gradle.