المحتوى
بدايةً من أسوأ النقاط ، يُظهر Android 5.0 بت 32 بت أن كود Java يشغل 296٪ أبطأ من C ، أو بعبارة أخرى 4 مرات أبطأ. مرة أخرى ، تذكر أن السرعة المطلقة ليست مهمة هنا ، بل الفرق في الوقت الذي يستغرقه تشغيل شفرة Java مقارنةً بالرمز C ، على نفس الجهاز. الإصدار 32 بت من نظام Android 4.4 KitKat مع Dalvik JVM أسرع بنسبة 237٪. بمجرد أن يتم الانتقال إلى Android 6.0 Marshmallow ، تبدأ الأمور في التحسن بشكل كبير ، مع إصدار 64 بت من نظام Android 6.0 الذي ينتج عنه أصغر الفرق بين Java و C.
الاختبار الثاني هو اختبار الرقم الأولي ، باستخدام التجربة بالقسمة. كما هو مذكور أعلاه يستخدم هذا الرمز 64 بتطويل أعداد صحيحة وبالتالي سوف تفضل معالجات 64 بت.
كما هو متوقع ، تأتي أفضل النتائج من Android الذي يعمل على معالجات 64 بت. بالنسبة إلى نظام أندرويد 6.0 ذي 64 بت ، فإن فارق السرعة صغير جدًا ، فقط 3٪. في حين أن الإصدار 64 بت من نظام Android 5.0 ، يبلغ 38٪. هذا يوضح التحسينات بين ART على Android 5.0 و تحسين مترجم المستخدمة من قبل ART في أندرويد 6.0. نظرًا لأن الإصدار 7.0 من Android 7.0 N لا يزال إصدارًا تجريبيًا للتطوير ، إلا أنني لم أقم بعرض النتائج ، إلا أنه يعمل بشكل عام بالإضافة إلى Android 6.0 M ، إن لم يكن أفضل. النتائج الأسوأ هي للإصدارات 32 بت من Android و الغريب أن Android 6.0 بت يعطي نتائج أسوأ للمجموعة.
الاختبار الثالث والأخير ينفذ وظيفة رياضية ثقيلة لمليون تكرار. الدالة لا حسابي صحيح وكذلك حساب النقطة العائمة.
وهنا لأول مرة لدينا نتيجة حيث جافا يعمل بالفعل أسرع من C! هناك نوعان من التفسيرات المحتملة لهذا وكلاهما يتعلق بالتحسين و Optimizingمترجم من أرمينيا. أولا ، ياptimizing كان من الممكن أن ينتج برنامج التحويل البرمجي المزيد من التعليمات البرمجية المثلى لـ AArch64 ، مع تخصيص تسجيل أفضل وما إلى ذلك ، من برنامج التحويل البرمجي C في Android Studio. أفضل مترجم يعني دائما أداء أفضل. أيضا يمكن أن يكون هناك طريق من خلال الرمز الذي Optimizingيمكن تحسين المحول البرمجي المحسوب لأنه لا يوجد له تأثير على النتيجة النهائية ، لكن المحول البرمجي C لم يكتشف هذا التحسين. أعلم أن هذا النوع من التحسين كان أحد أهم نقاط التركيز بالنسبة لـ Optimizingمترجم في أندرويد 6.0. نظرًا لأن الوظيفة مجرد اختراع خالص من جانبي ، فقد يكون هناك طريقة لتحسين الكود الذي يحذف بعض الأقسام ، لكنني لم أرها.السبب الآخر هو أن استدعاء هذه الوظيفة ، حتى مليون مرة ، لا يتسبب في تشغيل أداة تجميع مجمعي البيانات المهملة.
كما هو الحال مع اختبار الأعداد الأولية ، يستخدم هذا الاختبار 64 بتطويل أعداد صحيحة ، وهذا هو السبب في أن أفضل نتيجة تالية تأتي من الإصدار 64 بت من نظام Android 5.0. ثم يأتي الإصدار 32 بت من نظام Android 6.0 ، يليه الإصدار 32 بت من نظام Android 5.0 ، وأخيراً الإصدار 32 بت من نظام Android 4.4.
يتم إحتوائه
إجمالي C أسرع من Java ، ومع ذلك فقد تم تقليل الفجوة بين الاثنين بشكل كبير مع إصدار Android 6.0 Marshmallow 64 بت. بالطبع في العالم الواقعي ، فإن قرار استخدام Java أو C ليس بالأبيض والأسود. على الرغم من أن C له بعض المزايا ، فإن كل من Android UI وجميع خدمات Android وجميع واجهات برمجة تطبيقات Android مصممة ليتم استدعاؤها من Java. لا يمكن استخدام C إلا عندما تريد لوحة قماش OpenGL فارغة وتريد الرسم على قماش الرسم دون استخدام أي واجهات برمجة تطبيقات Android.
ومع ذلك ، إذا كان التطبيق الخاص بك يحتوي على بعض الأحمال الثقيلة التي يمكن القيام بها ، فيمكن نقل هذه الأجزاء إلى C وقد ترى تحسناً في السرعة ، ولكن ليس بالقدر الذي رأيته من قبل.
