Adakah yang memiliki tolok ukur (kode & hasil) yang membandingkan kinerja aplikasi Android yang ditulis dalam Xamarin C # dan Java? [Tutup]

544

Saya menemukan Xamarin mengklaim bahwa implementasi Mono mereka di Android dan aplikasi yang dikompilasi C # lebih cepat daripada kode Java. Adakah yang melakukan tolok ukur aktual pada kode Java dan C # yang sangat mirip pada platform Android yang berbeda untuk memverifikasi klaim tersebut, dapat memposting kode dan hasil?

Ditambahkan 18 Juni 2013

Karena tidak ada jawaban dan tidak dapat menemukan benchmark yang dilakukan oleh orang lain, memutuskan untuk melakukan tes saya sendiri. Sayangnya, pertanyaan saya tetap "terkunci" sehingga saya tidak dapat memposting ini sebagai jawabannya, hanya mengedit pertanyaan. Berikan suara untuk membuka kembali pertanyaan ini. Untuk C #, saya menggunakan Xamarin.Android Ver. 4.7.09001 (beta). Kode sumber, semua data yang saya gunakan untuk menguji dan menyusun paket APK ada di GitHub:

Java: https://github.com/gregko/TtsSetup_Java

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

Jika seseorang ingin mengulang pengujian saya pada perangkat atau emulator lain, saya akan tertarik untuk mempelajari hasilnya juga.

Hasil dari pengujian saya

Saya memindahkan kelas ekstraktor kalimat ke C # (dari aplikasi @Voice Aloud Reader) dan menjalankan beberapa tes pada 10 file HTML dalam bahasa Inggris, Rusia, Prancis, Polandia, dan Ceko. Setiap proses dilakukan 5 kali pada semua 10 file, dan total waktu untuk 3 perangkat berbeda dan satu emulator diposting di bawah ini. Saya menguji "Rilis" hanya build, tanpa debugging diaktifkan.

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

Java: Total waktu keseluruhan (5 kali berjalan): 12361 ms, dengan total pembacaan file: 13304 ms

C #: Total waktu keseluruhan (5 kali berjalan): 17504 ms, dengan total pembacaan file: 17956 ms

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

Java: Total waktu keseluruhan (5 kali berjalan): 8947 ms, dengan total pembacaan file: 9186 ms

C #: Total waktu keseluruhan (5 kali berjalan): 9884 ms, dengan total pembacaan file: 10247 ms

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

Java: Total waktu keseluruhan (5 kali berjalan): 9742 ms, dengan total pembacaan file: 10111 ms

C #: Total waktu keseluruhan (5 kali berjalan): 10459 ms, dengan total pembacaan file: 10696 ms

Emulator - Intel (Android 4.2, API 17)

Java: Total waktu keseluruhan (5 kali berjalan): 2699 ms, dengan total pembacaan file: 3127 ms

C #: Total waktu keseluruhan (5 kali berjalan): 2049 ms, dengan total pembacaan file: 2182 ms

Emulator - Intel (Android 2.3.7, API 10)

Java: Total waktu keseluruhan (5 kali berjalan): 2992 ms, dengan total pembacaan file: 3591 ms

C #: Total waktu keseluruhan (5 kali berjalan): 2049 ms, dengan total pembacaan file: 2257 ms

Emulator - Arm (Android 4.0.4, API 15)

Java: Total waktu keseluruhan (5 kali berjalan): 41751 ms, dengan total pembacaan file: 43866 ms

C #: Total waktu keseluruhan (5 kali berjalan): 44136 ms, dengan total pembacaan file: 45109 ms

Diskusi singkat

Kode pengujian saya sebagian besar berisi penguraian teks, penggantian, dan pencarian Regex, mungkin untuk kode lain (mis. Operasi yang lebih numerik) hasilnya akan berbeda. Pada semua perangkat dengan prosesor ARM, Java berkinerja lebih baik daripada kode Xamarin C #. Perbedaan terbesar adalah di bawah Android 2.3, di mana kode C # berjalan sekitar. 70% dari kecepatan Java.

Pada emulator Intel (dengan teknologi Intel HAX, emulator berjalan dalam mode cepat), kode Xamarin C # menjalankan kode sampel saya jauh lebih cepat daripada Java - sekitar 1,35 kali lebih cepat. Mungkin Mono kode mesin virtual dan perpustakaan jauh lebih baik dioptimalkan pada Intel daripada pada ARM?

Edit 8 Juli 2013

Saya baru saja menginstal emulator Android Genymotion, yang berjalan di Oracle VirtualBox, dan sekali lagi ini menggunakan prosesor Intel asli, bukan meniru prosesor ARM. Seperti halnya emulator Intel HAX, sekali lagi C # berjalan di sini jauh lebih cepat. Inilah hasil saya:

Emulator Genymotion - Intel (Android 4.1.1, API 16)

Java: Total waktu keseluruhan (5 kali berjalan): 2069 ms, dengan total pembacaan file: 2248 ms

C #: Total waktu keseluruhan (5 kali berjalan): 1543 ms, dengan total pembacaan file: 1642 ms

Saya kemudian memperhatikan bahwa ada pembaruan untuk Xamarin. Android beta, versi 4.7.11, dengan catatan rilis menyebutkan beberapa perubahan dalam runtime Mono juga. Memutuskan untuk dengan cepat menguji beberapa perangkat ARM, dan kejutan besar - nomor C # membaik:

BN Nook XD +, ARM (Android 4.0)

Java: Total waktu keseluruhan (5 kali berjalan): 8103 ms, dengan total pembacaan file: 8569 ms

C #: Total waktu keseluruhan (5 kali berjalan): 7951 ms, dengan total pembacaan file: 8161 ms

Wow! C # sekarang lebih baik dari Java? Memutuskan untuk mengulang tes pada Galaxy Note 2 saya:

Samsung Galaxy Note 2 - ARM (Android 4.1.1)

Java: Total waktu keseluruhan (5 kali berjalan): 9675 ms, dengan total pembacaan file: 10028 ms

C #: Total waktu keseluruhan (5 kali berjalan): 9911 ms, dengan total pembacaan file: 10104 ms

Di sini C # tampaknya hanya sedikit lebih lambat, tetapi angka-angka ini memberi saya jeda: Mengapa waktunya lebih lama dari pada Nook HD +, meskipun Note 2 memiliki prosesor yang lebih cepat? Jawabannya: mode hemat daya. Pada Nook, itu dinonaktifkan, pada Catatan 2 - diaktifkan. Memutuskan untuk menguji dengan mode hemat daya dinonaktifkan (seperti yang diaktifkan, itu juga membatasi kecepatan prosesor):

Samsung Galaxy Note 2 - ARM (Android 4.1.1), hemat daya dinonaktifkan

Java: Total waktu keseluruhan (5 kali berjalan): 7153 ms, dengan total pembacaan file: 7459 ms

C #: Total waktu keseluruhan (5 kali berjalan): 6906 ms, dengan total pembacaan file: 7070 ms

Sekarang, secara mengejutkan, C # sedikit lebih cepat dari Java pada prosesor ARM juga. Perbaikan besar!

Edit 12 Juli 2013

Kita semua tahu, bahwa tidak ada yang mengalahkan kode asli untuk kecepatan, dan saya tidak puas dengan kinerja pemecah kalimat saya di Jawa atau C #, terutama yang saya perlukan untuk memperbaikinya (dan dengan demikian membuatnya lebih lambat). Memutuskan untuk menulis ulang dalam C ++. Berikut ini adalah perbandingan kecil (yaitu kumpulan file yang lebih kecil dari pengujian sebelumnya, untuk alasan lain) dari kecepatan native vs Java pada Galaxy Note 2 saya, dengan mode hemat daya dinonaktifkan:

Java: Total waktu keseluruhan (5 kali berjalan): 3292 ms, dengan total pembacaan file: 3454 ms

Ibu jari asli: Total waktu keseluruhan (5 kali berjalan): 537 ms, dengan total pembacaan file: 657 ms

Lengan asli: Total waktu keseluruhan (5 kali berjalan): 458 ms, dengan total pembacaan file: 587 ms

Sepertinya untuk tes khusus saya, kode asli adalah 6 sampai 7 kali lebih cepat daripada Java. Peringatan: tidak dapat menggunakan std :: regex class di Android, jadi harus menulis rutinitas khusus saya sendiri untuk mencari paragraf istirahat atau tag html. Tes awal saya untuk kode yang sama pada PC menggunakan regex, sekitar 4 hingga 5 kali lebih cepat daripada Java.

Fiuh! Bangun memori mentah dengan pointer char * atau wchar * lagi, saya langsung merasa 20 tahun lebih muda! :)

Edit 15 Juli 2013

(Silakan lihat di bawah, dengan pengeditan 7/30/2013, untuk hasil yang lebih baik dengan Dot42)

Dengan sedikit kesulitan, saya berhasil memport tes C # saya ke Dot42 (versi 1.0.1.71 beta), platform C # lainnya untuk Android. Hasil awal menunjukkan bahwa kode Dot42 sekitar 3x (3 kali) lebih lambat dari Xamarin C # (v. 4.7.11), pada emulator Intel Android. Satu masalah adalah kelas System.Text.RegularExpressions di Dot42 tidak memiliki fungsi Split () yang saya gunakan dalam tes Xamarin, jadi saya menggunakan kelas Java.Util.Regex sebagai gantinya, dan Java.Util.Regex.Pattern.Split () , jadi di tempat khusus ini dalam kode, ada perbedaan kecil ini. Seharusnya tidak menjadi masalah besar. Dot42 mengkompilasi ke kode Dalvik (DEX), sehingga bekerja sama dengan Java pada Android secara native, tidak perlu interop mahal dari C # ke Java seperti Xamarin.

Sebagai perbandingan, saya juga menjalankan tes pada perangkat ARM - di sini kode Dot42 "hanya" 2x lebih lambat dari Xamarin C #. Inilah hasil saya:

HTC Nexus One Android 2.3.7 (ARM)

Java: Total waktu keseluruhan (5 kali berjalan): 12187 ms, dengan total pembacaan file: 13200 ms

Xamarin C #: Total waktu keseluruhan (5 kali berjalan): 13935 ms, dengan total pembacaan file: 14465 ms

Dot42 C #: Total waktu keseluruhan (5 kali berjalan): 26000 ms, dengan total pembacaan file: 27168 ms

Samsung Galaxy Note 2, Android 4.1.1 (ARM)

Java: Total waktu keseluruhan (5 kali berjalan): 6895 ms, dengan total pembacaan file: 7275 ms

Xamarin C #: Total waktu keseluruhan (5 kali berjalan): 6466 ms, dengan total pembacaan file: 6720 ms

Dot42 C #: Total waktu keseluruhan (5 kali berjalan): 11185 ms, dengan total pembacaan file: 11843 ms

Intel emulator, Android 4.2 (x86)

Java: Total waktu keseluruhan (5 kali berjalan): 2389 ms, dengan total pembacaan file: 2770 ms

Xamarin C #: Total waktu keseluruhan (5 kali berjalan): 1748 ms, dengan total pembacaan file: 1933 ms

Dot42 C #: Total waktu keseluruhan (5 kali berjalan): 5150 ms, dengan total pembacaan file: 5459 ms

Bagi saya, itu juga menarik untuk dicatat bahwa Xamarin C # sedikit lebih cepat dari Java pada perangkat ARM yang lebih baru dan sedikit lebih lambat pada Nexus One yang lama. Jika ada yang ingin menjalankan tes ini juga, beri tahu saya dan saya akan memperbarui sumber di GitHub. Akan sangat menarik untuk melihat hasil dari perangkat Android nyata dengan prosesor Intel.

Perbarui 7/26/2013

Hanya pembaruan cepat, disusun ulang oleh aplikasi benchmark dengan Xamarin.Android 4.8 terbaru, dan juga dengan pembaruan dot42 1.0.1.72 yang dirilis hari ini - tidak ada perubahan signifikan dari hasil yang dilaporkan sebelumnya.

Perbarui 7/30/2013 - hasil yang lebih baik untuk dot42

Uji ulang Dot42 dengan port Robert (dari pembuat dot42) kode Java saya ke C #. Pada port C # saya yang awalnya dilakukan untuk Xamarin, saya mengganti beberapa kelas Java asli, seperti ListArray, dengan kelas List asli ke C #, dll. Robert tidak memiliki kode sumber Dot42 saya, jadi ia porting lagi dari Jawa dan menggunakan kelas Java asli di tempat-tempat seperti itu, yang menguntungkan Dot42, saya kira karena berjalan di Dalvik VM, seperti Jawa, dan bukan di Mono, seperti Xamarin. Sekarang hasil Dot42 jauh lebih baik. Berikut ini adalah log dari pengujian saya:

7/30/2013 - Dot42 menguji dengan lebih banyak kelas Java di Dot42 C #

Intel emulator, Android 4.2

Dot42, Greg's Code menggunakan StringBuilder.Replace () (seperti pada Xamarin):
Total waktu keseluruhan (5 kali berjalan): 3646 ms, dengan total pembacaan file: 3830 ms

Dot42, Greg's Code menggunakan String.Replace () (seperti pada kode Java dan Robert):
Total waktu keseluruhan (5 kali): 3027 ms, dengan total pembacaan file: 3206 ms

Dot42, Kode Robert:
Total waktu keseluruhan (5 kali berjalan): 1781 ms, dengan total pembacaan file: 1999 ms

Xamarin:
Total waktu keseluruhan (5 kali berjalan): 1373 ms, dengan total pembacaan file: 1505 ms

Java:
Total waktu keseluruhan (5 kali berjalan): 1841 ms, dengan total pembacaan file: 2044 ms

ARM, Samsung Galaxy Note 2, hemat daya, Android 4.1.1

Dot42, Greg's Code menggunakan StringBuilder.Replace () (seperti pada Xamarin):
Total waktu keseluruhan (5 kali berjalan): 10875 ms, dengan total pembacaan file: 11280 ms

Dot42, Greg's Code menggunakan String.Replace () (seperti dalam Java dan Robert's code):
Total waktu keseluruhan (5 berjalan): 9710 ms, dengan total pembacaan file: 10097 ms

Dot42, Kode Robert:
Total waktu keseluruhan (5 kali): 6279 ms, dengan total pembacaan file: 6622 ms

Xamarin:
Total waktu keseluruhan (5 kali berjalan): 6201 ms, dengan total pembacaan file: 6476 ms

Java:
Total waktu keseluruhan (5 kali berjalan): 7141 ms, dengan total pembacaan file: 7479 ms

Saya masih berpikir bahwa Dot42 masih harus menempuh jalan panjang. Memiliki kelas seperti Java (mis. ArrayList) dan kinerja yang baik dengannya akan membuat kode porting dari Java ke C # sedikit lebih mudah. Namun, ini adalah sesuatu yang tidak mungkin saya lakukan banyak. Saya lebih suka ingin menggunakan kode C # yang ada (perpustakaan dll), yang akan menggunakan kelas C # asli (misalnya Daftar), dan itu akan berkinerja lambat dengan kode dot42 saat ini, dan sangat baik dengan Xamarin.

Greg

c# java android xamarin dot42 gregko
sumber
5
Mode DEBUG pada Nexus 7 4.2.2 dengan beberapa optimisasi pada string dan xamarin alpha 9: Total waktu: 3907 ms, dengan total pembacaan file: 4016. Apa artinya "5 berjalan"?
Softlion
1
"pertanyaan ini kemungkinan akan mengundang debat, argumen, pemungutan suara, atau diskusi panjang" <- lihat di atas;)
LearnCocos2D
2
@ LearnCocos2D - Saya hanya melaporkan hasil dan angka nyata, yaitu fakta. Tuan-tuan jangan membantah fakta :)
gregko
2
well, para ilmuwan melakukan;) ada perbedaan antara perilaku yang diamati dan fakta. Ada banyak lagi yang menjadi fakta, dan bahkan penerapan ke pengguna / situasi lain masih dipertanyakan. Ini adalah inti dari tolok ukur, mereka hanya menyajikan fakta di permukaan - sampai Anda mengetahui bahwa vendor x telah mengoptimalkan drivernya untuk aplikasi benchmark tertentu. Pada catatan terkait pernah terbukti bahwa air memiliki memori (yaitu tes homeopati), yang dibantah setelah bias tester dipertimbangkan dan dikesampingkan, kemudian gagal menunjukkan signifikansi statistik.
LearnCocos2D
3
ditambah, dengan versi +0.1 versi berikutnya, karakteristik performa layar ini dapat berubah secara signifikan - saat itulah semua upaya baik Anda yang disajikan di sini berubah dari "fakta" menjadi "diperdebatkan". Namun siapa pun yang datang ke sini mungkin menganggap ini sebagai fakta, dan menarik kesimpulan yang salah. Inti lain dari tolok ukur: mereka hanya mewakili saat tertentu dalam waktu dan versi perangkat lunak yang digunakan. Keesokan harinya mereka mungkin tidak lagi mencerminkan kenyataan. Anda harus terus menguji ulang hasilnya. Inilah sebabnya mengapa hasil di sini dapat dianggap subyektif dan tidak banyak berarti.
LearnCocos2D

Jawaban:

62

Ya, mesin virtual Xamarin Mono lebih mengesankan daripada Dalvik Google yang digunakan di Android. Saya telah mengujinya dengan tablet HTC Flyer dan Acer Iconia Tab untuk membandingkan port C # Android melalui Mono melawan Java Dalvik, dengan implementasi C # dari Android dengan baik dan benar-benar mengalahkan Dalvik yang berbasis di Jawa.

klvtsov
sumber
4
@PeterLawrey, silakan lihat pembaruan pertanyaan saya. Saya berniat untuk mem-porting beberapa bagian dari kode Java kehidupan nyata saya ke C # dan menjalankan tolok ukur, kemudian mempostingnya di sini - jika mereka membuka kembali pertanyaan saya, karena petugas keamanan menutupnya segera.
gregko
1
@PeterLawrey - Saya sekarang melakukan tes dan memposting hasil di StackOverflow, tetapi dalam Pertanyaan itu sendiri, karena masih tetap "terkunci" dan tidak dapat memposting jawaban. Jika Anda bisa, silakan tambahkan suara Anda untuk membuka kembali pertanyaan. Hasilnya menarik, pada ARM Java menang dengan mudah, pada Intel - kode C # di Mono jauh lebih cepat.
gregko
9
@regreg Perlu dicatat bahwa Anda melihat C # ditiru lebih cepat, tetapi Java lebih cepat pada telepon nyata. Bagi saya ini adalah perbedaan penting. Saya tidak akan khawatir tentang kinerja emulator, pada kenyataannya saya akan menyarankan Anda ingin emulator menjadi lambat / cepat seperti yang asli. Saya telah memilih untuk membuka kembali.
Peter Lawrey
14
Hati-hati saat menggunakan ekspresi reguler sebagai ujian untuk kinerja. Perbedaan algoritma dalam implementasi ET dapat membuat perbedaan besar. Apa yang mungkin Anda uji di atas adalah kualitas penerapan RE, bukan Dalvik atau Mono VM. Tes yang lebih baik adalah kode parsing tulisan tangan yang menggunakan algoritma yang identik dan jelas yang ditulis dengan gaya idiomatis untuk setiap bahasa.
Christopher
4
Jawaban ini tidak ada artinya tanpa penjelasan tentang bagaimana Anda menjalankan tes ini atau hasil tes. Seperti sekarang: sepenuhnya berdasarkan pendapat.
Rolf ツ
34

Kami baru-baru ini menyelidiki menggunakan Xamarin untuk suatu aplikasi. Kami menggunakan kode C # yang telah kami tulis untuk versi Windows RT dari aplikasi kami. Beberapa detail spesifik harus ditulis ulang untuk versi Android.

Apa yang kami temukan adalah bahwa I / O di Xamarin C # kira-kira 2x lebih lambat dari Java. Aplikasi kami sangat terikat I / O. Kami belum menemukan penyebabnya, tetapi saat ini kami mengasumsikan bahwa ini disebabkan oleh pengurutan. Meskipun kami mencoba untuk tetap berada di dalam Mono VM hampir sepanjang waktu, kami tidak tahu bagaimana Mono benar-benar mengakses disk.

Ia juga mengatakan bahwa kode C # kami menggunakan SQLite.NET ( https://github.com/praeclarum/sqlite-net ). Pengambilan yang identik menggunakan kode SQLite.NET juga 2x lebih lambat daripada menggunakan Java SQLite wrapper Android. Setelah melihat kode sumber, tampaknya mengikat langsung ke C. Dll, jadi saya tidak tahu mengapa itu jauh lebih lambat. Satu kemungkinan adalah bahwa membuat string dari bahasa asli ke Jawa mungkin lebih cepat di Android daripada asli ke C # ada di Xamarin.

Christopher
sumber
1
Ini sangat mungkin juga disebabkan oleh "binding" Xamerin perlu berinteraksi dengan sistem. Setiap panggilan sistem secara default masuk ke kelas Java tetapi perlu didelegasikan ke VM Mono, yang membutuhkan waktu. Hal yang sama juga terjadi secara terbalik. Saya telah menjelaskan ini sedikit lebih dalam jawaban saya: stackoverflow.com/a/46973819/1052697
Rolf ツ
33

Ini adalah posting blog yang lebih baru yang ingin saya bagi dengan Anda . Dia membandingkan Xamarin dengan kode asli dan Cordova pada IO dan Android.

Singkatnya, Xamarin terkadang melakukan lebih baik daripada kode asli. Dia menguji ukuran aplikasi, memuat waktu, memuat daftar dari layanan Azure dan perhitungan bilangan prima.

Nikmati!

Sunting: Saya memperbarui tautan mati dan saya perhatikan ada bagian 2

Daniel
sumber
11

Berikut adalah beberapa informasi yang saya temukan dalam tes lain antara solusi native, Xamarin dan Xamarin.

Samsung Galaxy A7 : Versi OS Android: 6.0 Unit pemrosesan pusat: Octa-core 1.9 GHz Cortex-A53 RAM: 3GB Resolusi layar: 1920 × 1080

iPhone 6s : Versi iOS: 10.3.3 Unit pemrosesan pusat: Dual-core 1.84 GHz Twister RAM: 2 GB Resolusi layar: 1334 × 750

Perbandingan dibuat pada beberapa fitur umum, masing-masing dengan aplikasi sendiri: 

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

Setiap tes diulang beberapa kali, grafik menunjukkan hasil rata-rata.

Halo Dunia

Perbandingan kinerja Basic Hellow World

API sisanya

Kumpulan tes yang bertujuan mengukur waktu yang dibutuhkan aplikasi untuk mengirim permintaan melalui REST API dan menerima kembali respons tanpa pemrosesan data lebih lanjut, menggunakan OpenWeatherMap API.

Istirahatkan perbandingan kinerja API

Uji Operasi JSON dibuat menggunakan kerangka Newsonoft Json.net untuk membuat cerita bersambung dan deserialisasi objek JSON di semua aplikasi Xamarin. Serialisasi dan deserialisasi Android asli diuji menggunakan dua perpustakaan Java: Jackson dan GSON.

Dua menjalankan dibuat, satu pertama dari awal dan yang kedua dengan info cache dan operasi

Lari pertama :

Serialisasi JSON dijalankan pertama kali

Deserialisasi JSON dijalankan pertama kali

(Operasi JSON Asli iOS membunuh tes ini btw, dan Xamarin bergabung di yang kedua)

Seriisasi JSON dijalankan kedua

JSON Deserialization dijalankan kedua

Operasi Foto

Muat pertama pada gambar dengan tiga resolusi berbeda: 

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

Gambar Pertama Muat Android

Image Pertama Muat di iOS

Sesuatu tampak tidak pasti tentang Xamarin. Hasil cetakan untuk tes ini, sehingga tidak termasuk dalam grafik.

Operasi SQLite

Dua operasi diuji: 

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

Dengan database yang memiliki 10.000 catatan. Semua operasi diproses secara internal pada perangkat.

Pertunjukan SQLite Android

Pertunjukan SQLite iOS

Xamarin Native (Xamarin.iOS / Xamarin.Android) menunjukkan diri mereka sebagai alternatif yang lebih baik untuk kode asli, sedangkan Xamarin.Form tampaknya lambat dalam banyak kasus, tetapi itu bisa menjadi solusi yang sangat baik untuk mengembangkan aplikasi yang sangat sederhana dengan cepat.

Tes lengkap berasal dari sumber ini:

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

Terima kasih telah memberikan saya penjelasan untuk meningkatkan jawaban saya, semoga ini sedikit membantu :)

Burgito
sumber
7

Performa

Kinerja adalah kata yang tidak jelas jika Anda tidak mendefinisikan apa yang Anda maksud dengan kinerja, jika itu kinerja komputasi yang sederhana, Xamarin dapat lebih cepat daripada Java tergantung pada sifat dari perhitungan tersebut.

Android nativly hadir dengan bentuk multipe untuk mengeksekusi kode di:

  • RenderScript (CPU dan GPU)
  • Jawa (SDK)
  • C ++ (NDK)
  • OpenGL (GPU)

Sangat jelas bahwa ketika mengeksekusi kode semakin asli solusinya semakin cepat. Bahasa berbasis run-time tidak akan pernah mengalahkan bahasa yang langsung berjalan pada CPU.

Tetapi di sisi lain jika Anda ingin mengukur kinerja penggunaan kehidupan nyata Java adalah propbaby akan lebih cepat daripada Xamarin.

Xamarin dan mengapa itu bisa lebih lambat

Ketika membandingkan Xamarin dengan aplikasi Java biasa, kinerjanya bisa lebih cepat bagi Xamarin karena bisa lebih lambat.

Dalam dunia nyata contoh aplikasi Xamarin sangat mungkin lebih lambat daripada aplikasi Java karena banyak panggilan Android / Java (sistem) perlu didelegasikan ke dan dari run-time Xamarin menggunakan bindings yang disebut.

Ada beberapa jenis ikatan yang penting untuk diketahui:

  • JNI (Java Native Interface): Ikatan yang digunakan dalam banyak aplikasi android untuk antarmuka antara kode Java (SDK) dan kode C ++ asli (NDK).
  • MCW (Managed Callable Wrappers): Ikatan yang tersedia di Xamarin untuk antarmuka dari kode C # yang dikelola ke kode Java (Android run-time).
  • ACW (Android Callable Wrappers): Ikatan yang tersedia di Xamarin untuk antarmuka dari kode Java (Android run-time) ke kode C # yang dikelola.

Lebih lanjut tentang MCW dan ACW di sini: https://developer.xamarin.com/guides/cross-platform/application_fundamentals/building_cross_platform_applications/part_1_-_understanding_the_xamarin_mobile_platform/

Bindings dalam hal kinerja sangat mahal. Menggunakan metode C ++ dari Java menambah biaya panggilan yang besar, memanggil metode C ++ dari dalam C ++ jauh lebih cepat.

Seseorang melakukan tes kinerja untuk menghitung berapa banyak operasi Java rata-rata biaya panggilan JNI: Berapa overhead kuantitatif untuk melakukan panggilan JNI?

Tetapi tidak hanya panggilan JNI yang mahal, begitu juga panggilan ke dan dari MCW dan ACW. Aplikasi Xamarin dunia nyata membuat banyak panggilan menggunakan binding dan karena penggunaan Xamarin di dunia nyata ini bisa (dan akan secara umum) lebih lambat daripada aplikasi Java biasa. Namun tergantung pada bagaimana aplikasi Xamarin dirancang, sangat mungkin bahwa pengguna bahkan tidak akan melihat perbedaannya.

TLDR / Kesimpulan: Xamarin perlu menggunakan semua jenis binding, yang memakan waktu mahal.

Selain binding, ada banyak faktor lain yang terlibat ketika berbicara tentang kinerja dunia nyata, misalnya: ukuran biner, memuat aplikasi dalam memori, operasi I / O dan banyak lagi. Sebuah posting blog yang menyelidiki beberapa hal ini dapat ditemukan di sini: https://magenic.com/thinking/mobile-development-platform-performance-part-2-native-cordova-classic-xamarin-xamarin-forms

Rolf ツ
sumber