c# - لتعلم - كتاب تعلم xamarin




هل لدى أي شخص معايير(رمز ونتائج) تقارن أداء تطبيقات Android المكتوبة في Xamarin C#و Java؟ (5)

أداء

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

يأتي Android nativly مزودًا بنماذج متعددة الأنماط لتنفيذ الشفرة في:

  • RenderScript (وحدة المعالجة المركزية ووحدة معالجة الرسومات)
  • جافا (SDK)
  • C ++ (NDK)
  • OpenGL (GPU)

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

ولكن من ناحية أخرى إذا كنت ترغب في قياس أداء الاستخدام الحقيقي ، فإن جافا هي propbaby ستكون أسرع ثم Xamarin.

Xamarin ولماذا يمكن أن يكون أبطأ

عند مقارنة Xamarin مع تطبيقات Java القديمة ، يمكن أن يكون الأداء أسرع من Xamarin حيث يمكن أن يكون أبطأ.

في العالم الحقيقي ، من المرجح جداً أن تكون تطبيقات Xamarin أبطأ من تطبيقات Java لأن الكثير من مكالمات Android / Java (النظام) تحتاج إلى تفويض من وإلى وقت Xamarin باستخدام الروابط المسماة.

هناك عدة أنواع مختلفة من الارتباطات التي من المهم معرفتها:

  • JNI (Java Native Interface): الربط المستخدم في العديد من تطبيقات android على واجهة بين Java code (SDK) و C ++ code (NDK).
  • MCW (الأغلفة القابلة للإدارة القابلة للإدارة): ملزمة متوفرة في Xamarin للواجهة من كود C # المُدار إلى شفرة Java (وقت تشغيل Android).
  • ACW ( أغلفة آندرويد القابلة للاتصال ): ملزمة متوفرة في Xamarin للواجهة من كود Java (وقت تشغيل Android) إلى كود C # مُدار.

المزيد عن MCW و ACW هنا: https://developer.xamarin.com/guides/cross-platform/application_fundamentals/building_cross_platform_applications/part_1_-_understanding_the_xamarin_mobile_platform/

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

قام شخص ما بإجراء اختبار أداء لحساب عدد عمليات Java في المتوسط ​​لتكاليف مكالمة JNI: ما هو مقدار الحمل الكمي لإجراء اتصال JNI؟

لكن مكالمات JNI ليست مكلفة فقط ، لذا فإن المكالمات من MCW و ACW. تطبيقات العالم الحقيقي Xamarin إجراء العديد من المكالمات باستخدام الارتباطات وبسبب استخدام هذا العالم الحقيقي لتطبيق Xamarin يمكن (وسيكون بشكل عام) أبطأ من تطبيق جافا قديم سهل. لكن اعتمادًا على كيفية تصميم تطبيق Xamarin ، من المحتمل جدًا ألا يلاحظ المستخدم الاختلاف.

TLDR / الخلاصة: يحتاج Xamarin لاستخدام الارتباطات alpolings ، التي تكون مكلفة الوقت.

إلى جانب الارتباطات ، هناك العديد من العوامل الأخرى التي ينطوي عليها الحديث عن الأداء في العالم الحقيقي ، على سبيل المثال: حجم الملف الثنائي ، تحميل التطبيق في الذاكرة ، عمليات الإدخال / الإخراج وغيرها الكثير. يمكن العثور على مشاركة مدونة تدرس بعض هذه الأشياء هنا: https://magenic.com/thinking/mobile-development-platform-performance-part-2-native-cordova-classic-xamarin-xamarin-forms

جئت عبر مزاعم Xamarin بأن تطبيق Mono على Android وتطبيقات C # المجمعة هي أسرع من Java البرمجية. هل قام أي شخص بأداء معايير فعلية على رمز Java و C # متشابهين جدًا على أنظمة أندرويد مختلفة للتحقق من هذه الادعاءات ، هل يمكن نشر الشفرة والنتائج؟

تمت إضافة 18 حزيران 2013

نظرًا لعدم وجود إجابة ولم تتمكن من العثور على مثل هذه المعايير من قبل الآخرين ، قررت إجراء اختباراتي الخاصة. لسوء الحظ ، يبقى سؤالي "مغلق" ، لذا لا يمكنني نشر هذا السؤال كإجابة ، فقط قم بتحرير السؤال. يرجى التصويت لإعادة فتح هذا السؤال. بالنسبة لـ C # ، استخدمت Xamarin.Android ver. 4.7.09001 (إصدار تجريبي). شفرة المصدر ، وجميع البيانات التي استخدمتها للاختبار ، وحزم APK المجمعة موجودة على GitHub:

جافا: https://github.com/gregko/TtsSetup_Java

C #: https://github.com/gregko/TtsSetup_C_sharp

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

النتائج من الاختبار الخاص بي

لقد نقلت فصيلة مستخرج الجملة إلى C # (من تطبيق @ Voice Aloud Reader) وأجري بعض الاختبارات على 10 ملفات html باللغات الإنجليزية والروسية والفرنسية والبولندية والتشيكية. تم تنفيذ كل تشغيل 5 مرات في جميع الملفات 10 ، ويتم نشر الوقت الإجمالي لمدة 3 أجهزة مختلفة ومحاكي واحد أدناه. لقد قمت باختبار إصدار "Release" فقط ، دون تمكين التصحيح.

HTC Nexus One Android 2.3.7 (API 10) - CyanogenMod ROM

Java: إجمالي الوقت الإجمالي (5 مسارات): 12361 مللي ثانية ، مع إجمالي قراءة الملف: 13304 مللي ثانية

C #: إجمالي الوقت الكلي (5 أشواط): 17504 مللي ثانية ، مع إجمالي قراءة الملف: 17956 مللي ثانية

Samsung Galaxy S2 SGH-I777 (Android 4.0.4، API 15) - CyanogenMod ROM

Java: إجمالي الوقت الإجمالي (5 مرات تشغيل): 8947 مللي ثانية ، مع إجمالي قراءة الملف: 9186 مللي ثانية

C #: الوقت الإجمالي الكلي (5 أشواط): 9884 مللي ثانية ، مع إجمالي قراءة الملف: 10247 مللي ثانية

Samsung GT-N7100 (Android 4.1.1 JellyBean، API 16) - Samsung ROM

Java: إجمالي الوقت الإجمالي (5 مرات تشغيل): 9742 مللي ثانية ، مع إجمالي قراءة الملف: 10111 مللي ثانية

C #: الوقت الإجمالي الكلي (5 أشواط): 10459 مللي ثانية ، مع إجمالي قراءة الملف: 10696 مللي ثانية

المحاكي - Intel (Android 4.2 و API 17)

Java: إجمالي الوقت الإجمالي (5 نقاط تشغيل): 2699 مللي ثانية ، مع إجمالي قراءة الملف: 3127 مللي ثانية

C #: إجمالي الوقت الكلي (5 أشواط): 2049 مللي ثانية ، مع إجمالي قراءة الملف: 2182 مللي ثانية

المحاكي - Intel (Android 2.3.7، API 10)

Java: إجمالي الوقت الإجمالي (5 نقاط تشغيل): 2992 مللي ثانية ، مع إجمالي قراءة الملف: 3591 مللي ثانية

C #: إجمالي الوقت الإجمالي (5 أشواط): 2049 مللي ثانية ، مع إجمالي قراءة الملف: 2257 مللي ثانية

المحاكي - الذراع (Android 4.0.4 ، API 15)

Java: إجمالي الوقت الإجمالي (5 أشواط): 41751 مللي ثانية ، مع إجمالي قراءة الملف: 43866 مللي ثانية

C #: الوقت الإجمالي الكلي (5 أشواط): 44136 مللي ثانية ، مع إجمالي قراءة الملف: 45109 مللي ثانية

مناقشة وجيزة

يحتوي كود الاختبار الخاص بي بشكل أساسي على تحليل النص ، واستبدال وبحث regex ، ربما عن التعليمات البرمجية الأخرى (مثل العمليات الرقمية أكثر) ستكون النتائج مختلفة. على جميع الأجهزة مع معالجات ARM ، كان أداء جافا أفضل من Xamarin C # code. كان أكبر اختلاف تحت Android 2.3 ، حيث تم تشغيل C # code في تقريبا. 70 ٪ من سرعة جافا.

على محاكي Intel (مع تقنية HAX Intel ، يعمل المحاكي في وضع التقديم السريع) ، يقوم كود Xamarin C # بتشغيل نموذج التعليمة البرمجية أسرع من Java - حوالي 1.35 مرة أسرع. ربما يتم تحسين رمز الجهاز الظاهري والمكتبات الأحادية بشكل أفضل في Intel مقارنةً بـ ARM؟

تحرير 8 يوليو 2013

لقد قمت بتركيب Genymotion Android emulator ، الذي يعمل في Oracle VirtualBox ، ومرة ​​أخرى هذا واحد يستخدم معالج Intel الأصلي ، وليس محاكاة معالج ARM. كما هو الحال مع محاكي Intel HAX ، يتم تشغيل C # مرة أخرى بشكل أسرع. وهنا نتائجي:

محاكي Genymotion - Intel (Android 4.1.1، API 16)

Java: إجمالي الوقت الإجمالي (5 نقاط تشغيل): 2069 مللي ثانية ، مع إجمالي قراءة الملف: 2248 مللي ثانية

C #: الوقت الإجمالي الكلي (5 أشواط): 1543 مللي ثانية ، مع إجمالي قراءة الملف: 1642 مللي ثانية

ثم لاحظت أن هناك تحديثًا ل Xamarin.Android beta ، الإصدار 4.7.11 ، مع ملاحظات الإصدار تذكر بعض التغييرات في وقت التشغيل الأحادي أيضًا. قررت بسرعة اختبار بعض الأجهزة ARM ، والمفاجأة الكبرى - تحسين أرقام C #:

BN Nook XD +، ARM (Android 4.0)

Java: إجمالي الوقت الإجمالي (5 أشواط): 8103 مللي ثانية ، مع إجمالي قراءة الملف: 8569 مللي ثانية

C #: الوقت الإجمالي الكلي (5 أشواط): 7951 مللي ثانية ، مع إجمالي قراءة الملف: 8161 مللي ثانية

نجاح باهر C # الآن أفضل من جافا؟ قررت تكرار الاختبار على Galaxy Note 2:

Samsung Galaxy Note 2 - ARM (Android 4.1.1)

Java: إجمالي الوقت الإجمالي (5 نقاط تشغيل): 9675 مللي ثانية ، مع إجمالي قراءة الملف: 10028 مللي ثانية

C #: الوقت الإجمالي الكلي (5 أشواط): 9911 مللي ثانية ، مع إجمالي قراءة الملف: 10104 مللي ثانية

هنا يبدو C # أبطأ قليلا ، ولكن هذه الأرقام أعطتني وقفة: لماذا الوقت أطول من Nook HD + ، على الرغم من أن Note 2 يحتوي على معالج أسرع؟ الجواب: وضع توفير الطاقة. على Nook ، تم تعطيله ، في الملاحظة 2 - ممكّن. قررت اختبار مع وضع توفير الطاقة تعطيل (كما هو الحال مع تمكين ، فإنه يحد أيضا سرعة المعالج):

سامسونج غالاكسي ملاحظة 2 - ARM (أندرويد 4.1.1) ، تعطيل توفير الطاقة

Java: إجمالي الوقت الإجمالي (5 مرات تشغيل): 7153 مللي ثانية ، مع إجمالي قراءة الملف: 7459 مللي ثانية

C #: الوقت الإجمالي الكلي (5 أشواط): 6906 مللي ثانية ، مع إجمالي قراءة الملف: 7070 مللي ثانية

الآن ، من المدهش أن C # أسرع قليلاً من Java على معالج ARM أيضاً. تحسن كبير!

تعديل 12 تموز 2013

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

Java: إجمالي الوقت الإجمالي (5 نقاط تشغيل): 3292 مللي ثانية ، مع إجمالي قراءة الملف: 3454 مللي ثانية

الإبهام الأصلي: إجمالي الوقت الإجمالي (5 أشواط): 537 مللي ثانية ، مع إجمالي قراءة الملف: 657 مللي ثانية

الذراع الأصلية: مجموع الوقت الإجمالي (5 أشواط): 458 مللي ثانية ، مع إجمالي قراءة الملف: 587 مللي ثانية

يشبه الاختبار الخاص بي ، الرمز الأصلي هو 6 إلى 7 مرات أسرع من جافا. التحذير: لا يمكن استخدام std :: regex class على Android ، لذلك كان عليه أن يكتب روتينات متخصصة خاصة أبحث عن فواصل الفقرات أو علامات html. كانت اختباراتي الأولية لنفس الشفرة على جهاز الكمبيوتر باستخدام regex ، أسرع بنحو 4 إلى 5 مرات من Java.

تفو! استيقظ الذاكرة الخام مع شار * أو wchar * مؤشرات مرة أخرى ، شعرت على الفور 20 سنة أصغر سنا! :)

تعديل 15 تموز 2013

(يرجى الاطلاع أدناه ، مع تعديلات من 30/30/2013 ، للحصول على نتائج أفضل بكثير مع Dot42)

مع بعض الصعوبة جربت إلى نقل اختبارات C # إلى Dot42 (الإصدار 1.0.1.71 بيتا) ، منصة C # أخرى للأندرويد. تظهر النتائج الأولية أن كود Dot42 هو حوالي 3x (3 مرات) أبطأ من Xamarin C # (v. 4.7.11) ، على محاكي Intel Android. مشكلة واحدة هي أن فئة System.Text.RegularExpressions في Dot42 لا تحتوي على الدالة Split () التي استخدمتها في اختبارات Xamarin ، لذا استخدمت فئة Java.Util.Regex بدلاً من ذلك ، و Java.Util.Regex.Pattern.Split ( ) ، لذلك في هذا المكان بالذات في الشفرة هناك اختلاف بسيط. لا ينبغي أن تكون مشكلة كبيرة رغم ذلك. Dot42 يجمع إلى رمز Dalvik (DEX) ، لذلك يتعاون مع جافا على الروبوت أصلا ، لا تحتاج إلى تكلفة التشغيل المتداخل من C # لجافا مثل Xamarin.

فقط للمقارنة ، وأنا أيضا تشغيل الاختبار على أجهزة ARM - هنا كود Dot42 هو "فقط" 2X أبطأ من Xamarin C #. وهنا نتائجي:

HTC Nexus One Android 2.3.7 (ARM)

Java: إجمالي الوقت الإجمالي (5 أشواط): 12187 مللي ثانية ، مع إجمالي قراءة الملف: 13200 مللي ثانية

Xamarin C #: الوقت الإجمالي الكلي (5 أشواط): 13935 مللي ثانية ، مع إجمالي قراءة الملف: 14465 مللي ثانية

Dot42 C #: إجمالي الوقت الكلي (5 أشواط): 26000 مللي ثانية ، مع إجمالي قراءة الملف: 27168 مللي ثانية

Samsung Galaxy Note 2 ، Android 4.1.1 (ARM)

Java: إجمالي الوقت الإجمالي (5 أشواط): 6895 مللي ثانية ، مع إجمالي قراءة الملف: 7275 مللي ثانية

Xamarin C #: الوقت الإجمالي الكلي (5 أشواط): 6466 مللي ثانية ، مع إجمالي قراءة الملف: 6720 مللي ثانية

Dot42 C #: الوقت الإجمالي الكلي (5 أشواط): 11185 مللي ثانية ، مع إجمالي قراءة الملف: 11843 مللي ثانية

محاكي إنتل ، أندرويد 4.2 (x86)

Java: إجمالي الوقت الإجمالي (5 مرات تشغيل): 2389 مللي ثانية ، مع إجمالي قراءة الملف: 2770 مللي ثانية

Xamarin C #: الوقت الإجمالي الكلي (5 أشواط): 1748 مللي ثانية ، مع إجمالي قراءة الملف: 1933 مللي ثانية

Dot42 C #: إجمالي الوقت الإجمالي (5 أشواط): 5150 مللي ثانية ، مع إجمالي قراءة الملف: 5459 مللي ثانية

بالنسبة لي كان من المثير للاهتمام أيضًا ملاحظة أن Xamarin C # أسرع قليلاً من Java على جهاز ARM أحدث ، وأبطأ قليلاً على Nexus One القديم. إذا كان أي شخص يرغب في إجراء هذه الاختبارات أيضًا ، فيرجى إبلاغي بذلك وسأقوم بتحديث مصادر GitHub. سيكون من المثير للاهتمام بشكل خاص رؤية النتائج من جهاز Android حقيقي باستخدام معالج Intel.

التحديث 7/26/2013

مجرد تحديث سريع ، وإعادة تجميعها من قبل تطبيقات القياسي مع أحدث Xamarin.Android 4.8 ، وأيضا مع التحديث dot42 1.0.1.72 صدر اليوم - لا تغييرات كبيرة من النتائج التي تم الإبلاغ عنها من قبل.

تحديث 7/30/2013 - نتائج أفضل لـ dot42

إعادة اختبار Dot42 مع ميناء روبرت (من صناع dot42) من رمز جافا الخاص بي إلى C #. في المنفذ C # الذي قمت به في البداية لـ Xamarin ، قمت باستبدال بعض فئات Java الأصلية ، مثل ListArray ، مع فئة List الأصلية إلى C # ، إلخ. لم يكن لدى Robert رمز مصدر Dot42 الخاص بي ، لذا قام بنقله مرة أخرى من Java واستخدام فئات Java الأصلية في هذه الأماكن ، والتي تستفيد Dot42 ، أعتقد أنه يعمل في دالفيك VM ، مثل جافا ، وليس في مونو ، مثل Xamarin. الآن نتائج Dot42 هي أفضل بكثير. في ما يلي سجل من الاختبار الخاص بي:

7/30/2013 - اختبارات Dot42 مع المزيد من فئات Java في Dot42 C #

محاكي إنتل ، أندرويد 4.2

Dot42 ، كود غريغ باستخدام StringBuilder.Replace () (كما هو الحال في Xamarin):
مجموع الوقت الإجمالي (5 أشواط): 3646 مللي ثانية ، مع إجمالي قراءة الملف: 3830 مللي ثانية

Dot42 ، كود غريغ باستخدام String.Replace () (كما في Java ورمز روبرت):
الوقت الإجمالي الكلي (5 أشواط): 3027 مللي ثانية ، مع إجمالي قراءة الملف: 3206 مللي ثانية

Dot42 ، رمز روبرت:
إجمالي الوقت الإجمالي (5 أشواط): 1781 مللي ثانية ، مع إجمالي قراءة الملف: 1999 مللي ثانية

Xamarin:
إجمالي الوقت الإجمالي (5 أشواط): 1373 مللي ثانية ، مع إجمالي قراءة الملف: 1505 مللي ثانية

جافا:
إجمالي الوقت الإجمالي (5 أشواط): 1841 مللي ثانية ، مع إجمالي قراءة الملف: 2044 مللي ثانية

ARM ، Samsung Galaxy Note 2 ، توفير الطاقة ، Android 4.1.1

Dot42 ، كود غريغ باستخدام StringBuilder.Replace () (كما هو الحال في Xamarin):
إجمالي الوقت الإجمالي (5 أشواط): 10875 مللي ثانية ، مع إجمالي قراءة الملف: 11280 مللي ثانية

Dot42 ، كود غريغ باستخدام String.Replace () (كما في Java ورمز روبرت):
إجمالي الوقت الإجمالي (5 أشواط): 9710 مللي ثانية ، مع إجمالي قراءة الملف: 10097 مللي ثانية

Dot42 ، رمز روبرت:
الوقت الإجمالي الكلي (5 أشواط): 6279 مللي ثانية ، مع إجمالي قراءة الملف: 6622 مللي ثانية

Xamarin:
إجمالي الوقت الإجمالي (5 أشواط): 6201 مللي ثانية ، مع إجمالي قراءة الملف: 6476 مللي ثانية

جافا:
الوقت الإجمالي الكلي (5 أشواط): 7141 مللي ثانية ، مع إجمالي قراءة الملف: 7479 مللي ثانية

ما زلت أعتقد أن Dot42 لديه طريق طويل لنقطعه. وجود طبقات تشبه جافا (مثل ArrayList) والأداء الجيد معهم ، من شأنه أن يجعل رمز porting من جافا إلى C # أسهل قليلا. ومع ذلك ، هذا شيء لن أقوم به على الأرجح. أود بدلاً من ذلك استخدام رمز C # الموجود (المكتبات وما إلى ذلك) ، والتي ستستخدم فئات C # الأصلية (مثل قائمة) ، والتي من شأنها أن تؤدي ببطء مع رمز dot42 الحالي ، وبشكل جيد للغاية مع Xamarin.

جريج


إليك بعض المعلومات التي وجدتها في اختبار آخر بين حلول Xamarin و Xamarin.Forms الأصلية (تتضمن الاختبارات أيضًا أداء iOS) على الجهازين التاليين:

Samsung Galaxy A7 : إصدار نظام التشغيل Android: 6.0 وحدة المعالجة المركزية: Octa-core 1.9 جيجاهرتز Cortex-A53 RAM: 3GB دقة الشاشة: 1920 × 1080

iPhone 6s : نسخة iOS: 10.3.3 وحدة المعالجة المركزية: Dual-core 1.84 GHz Twister RAM: 2 GB دقة الشاشة: 1334 × 750

يتم إجراء مقارنة على بعض الميزات الشائعة ، كل واحد مع تطبيقه الخاص:

- Basic “Hello World”
- REST API
- JSON Serialization/Deserialization
- Photo Loading
- SQL Database Insert and Get All

يتم نسخ كل اختبار عدة مرات ، وتظهر الرسوم البيانية متوسط ​​النتائج.

مرحبا بالعالم

Rest API

مجموعة من الاختبارات تهدف إلى قياس الوقت الذي يستغرقه التطبيق لإرسال طلب عبر واجهة برمجة تطبيقات REST وتلقي الرد مرة أخرى دون معالجة بيانات إضافية ، باستخدام واجهة برمجة التطبيقات OpenWeatherMap.

JSON Operations الاختبارات التي تم إجراؤها باستخدام إطار Newtonsoft Json.net لإجراء تسلسل وإلغاء تسلسل كائنات JSON في جميع تطبيقات Xamarin. تم اختبار تسلسل Android الأصلي وإلغاء التسلسل باستخدام مكتبتين جافا: جاكسون و GSON.

يتم إجراء مرحلتين ، الأولى من الصفر والثانية مع المعلومات والمحتويات المخزنة مؤقتًا

الجولة الأولى :

(عمليات iOS الأصلية JSON تقتل هذا الاختبار راجع للشغل ، و Xamarin ينضم إليه في الثانية)

عمليات الصور

التحميل الأول على الصور مع ثلاثة قرارات مختلفة:

Resolution – 858×569, Size – 868Kb
Resolution – 2575×1709, Size – 8Mb
Resolution – 4291×2848, Size – 28.9Mb

يبدو أن هناك شيئًا غير متأكد من نتائج Xamarin.Forms لهذا الاختبار ، لذا لا يتم تضمينه في الرسم البياني.

عمليات سكليتي

اختبار عمليتين:

BulkInsert: Loading rows of data into a database table.
GetAll: Retrieving all data from the database.

مع قواعد البيانات وجود 10000 السجلات. تمت معالجة جميع العمليات داخليًا على الأجهزة.

تظهر Xamarin Native (Xamarin.iOS / Xamarin.Android) بدائل جيدة إلى حد ما للشفرة الأصلية ، في حين أن Xamarin.Forms تبدو بطيئة في الكثير من الحالات ، لكنها يمكن أن تكون حلاً جيدًا لتطوير تطبيقات بسيطة حقًا.

يأتي الاختبار الكامل من هذا المصدر:

https://www.altexsoft.com/blog/engineering/performance-comparison-xamarin-forms-xamarin-ios-xamarin-android-vs-android-and-ios-native-applications/

شكرا لإعطائي التوضيحات لتعزيز جوابي ، ونأمل أن يساعد هذا قليلا :)


لقد تحققنا مؤخرًا من استخدام Xamarin لتطبيق. لقد استخدمنا كود C # الذي كتبناه بالفعل لإصدار Windows RT الخاص بتطبيقنا. كان لابد من إعادة كتابة بعض التفاصيل الخاصة بإصدار Android.

ما اكتشفناه هو أن I / O في Xamarin C # أبطأ مرتين تقريبًا من Java. لدينا التطبيق هو بشدة I / O ملزمة. لم نكتشف سبب هذا حتى الآن ، ولكن في الوقت الحالي نفترض أنه بسبب التعبئة. بينما نحاول البقاء داخل جهاز Mono VM في معظم الأوقات ، لا نعرف كيف يصل Mono فعليًا إلى القرص.

كما أنه يخبرنا أن كود C # الخاص بنا يستخدم SQLite.NET ( https://github.com/praeclarum/sqlite-net ). كما أن عمليات الجلب المتشابهة باستخدام شفرة SQLite.NET تكون أبطأ مرتين من استخدام Java SQLite wrapper. بعد النظر في شفرة المصدر ، يبدو أنه يرتبط مباشرة بـ C .dll ، لذلك لا أعرف لماذا أبطأ بكثير. أحد الاحتمالات هو أن تنظيم سلاسل من الأم إلى جافا قد يكون أسرع على الروبوت من الأصلي إلى C # على Xamarin.


نعم ، الجهاز الظاهري Xamarin Mono أكثر إثارة للإعجاب من Google Dalvik المستخدم في Android. لقد اختبرت ذلك مع أقراص HTC Flyer و Acer Iconia Tab لمعاينة منفذ C # من Android من خلال Mono ضد Java Dalvik ، مع تنفيذ C # من Android بشكل جيد وامتداد فعلي لـ Dalvik القائم على Java.






dot42