有没有人有比较用 Xamarin C# 和 Java 编写的 Android 应用程序的性能的基准（代码和结果）？

Does anyone have benchmarks (code & results) comparing performance of Android apps written in Xamarin C# and Java?

提问by gregko

I came across Xamarin claims that their Mono implementation on Android and their C# compiled apps are faster than Java code. Did anyone perform actual benchmarks on very similar Java and C# code on different Android platforms to verify such claims, could post the code and results?

我发现 Xamarin 声称他们在 Android 上的 Mono 实现和他们的 C# 编译应用程序比 Java 代码更快。有没有人在不同的 Android 平台上对非常相似的 Java 和 C# 代码执行实际基准测试以验证此类声明，可以发布代码和结果吗？

Added June 18, 2013

2013 年 6 月 18 日添加

Since there was no answer and could not find such benchmarks done by others, decided to do my own tests. Unfortunately, my question remains "locked" so I cannot post this as the answer, only edit the question. Please vote to re-open this question. For C#, I used Xamarin.Android Ver. 4.7.09001 (beta). The source code, all the data I used for testing and compiled APK packages are on GitHub:

由于没有答案并且找不到其他人完成的此类基准测试，因此决定进行自己的测试。不幸的是，我的问题仍然“锁定”，因此我无法将此作为答案发布，只能编辑问题。请投票重新打开这个问题。对于 C#，我使用了 Xamarin.Android 版本。4.7.09001（测试版）。源代码，我用于测试和编译APK包的所有数据都在GitHub上：

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

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

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

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

If someone would like to repeat my tests on other devices or emulators, I'd be interested to learn the results as well.

如果有人想在其他设备或模拟器上重复我的测试，我也有兴趣了解结果。

Results from my testing

我的测试结果

I ported my sentence extractor class to C# (from my @Voice Aloud Reader app) and run some tests on 10 HTML files in English, Russian, French, Polish and Czech languages. Each run was performed 5 times on all 10 files, and the total time for 3 different devices and one emulator are posted below. I tested "Release" builds only, without debugging enabled.

我将我的句子提取器类移植到 C#（来自我的 @Voice Aloud Reader 应用程序），并对 10 个英语、俄语、法语、波兰语和捷克语的 HTML 文件进行了一些测试。每次运行对所有 10 个文件执行 5 次，下面发布了 3 个不同设备和一个模拟器的总时间。我只测试了“发布”版本，没有启用调试。

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

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

Java: Grand total time (5 runs): 12361 ms, with file reading total: 13304 ms

Java：总计时间（5 次运行）：12361 毫秒，文件读取总计：13304 毫秒

C#: Grand total time (5 runs): 17504 ms, with file reading total: 17956 ms

C#：总计时间（5 次运行）：17504 毫秒，文件读取总计：17956 毫秒

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

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

Java: Grand total time (5 runs): 8947 ms, with file reading total: 9186 ms

Java：总计时间（5 次运行）：8947 毫秒，文件读取总计：9186 毫秒

C#: Grand total time (5 runs): 9884 ms, with file reading total: 10247 ms

C#：总计时间（5 次运行）：9884 毫秒，文件读取总计：10247 毫秒

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

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

Java: Grand total time (5 runs): 9742 ms, with file reading total: 10111 ms

Java：总计时间（5 次运行）：9742 毫秒，文件读取总计：10111 毫秒

C#: Grand total time (5 runs): 10459 ms, with file reading total: 10696 ms

C#：总计时间（5 次运行）：10459 毫秒，文件读取总计：10696 毫秒

Emulator - Intel (Android 4.2, API 17)

模拟器 - 英特尔（Android 4.2，API 17）

Java: Grand total time (5 runs): 2699 ms, with file reading total: 3127 ms

Java：总计时间（5 次运行）：2699 毫秒，文件读取总计：3127 毫秒

C#: Grand total time (5 runs): 2049 ms, with file reading total: 2182 ms

C#：总计时间（5 次运行）：2049 毫秒，文件读取总计：2182 毫秒

Emulator - Intel (Android 2.3.7, API 10)

模拟器 - 英特尔（Android 2.3.7，API 10）

Java: Grand total time (5 runs): 2992 ms, with file reading total: 3591 ms

Java：总计时间（5 次运行）：2992 毫秒，文件读取总计：3591 毫秒

C#: Grand total time (5 runs): 2049 ms, with file reading total: 2257 ms

C#：总计时间（5 次运行）：2049 毫秒，文件读取总计：2257 毫秒

Emulator - Arm (Android 4.0.4, API 15)

模拟器 - Arm（Android 4.0.4，API 15）

Java: Grand total time (5 runs): 41751 ms, with file reading total: 43866 ms

Java：总计时间（5 次运行）：41751 毫秒，文件读取总计：43866 毫秒

C#: Grand total time (5 runs): 44136 ms, with file reading total: 45109 ms

C#：总计时间（5 次运行）：44136 毫秒，文件读取总计：45109 毫秒

Brief discussion

简要讨论

My test code contains mainly text parsing, replacing and Regex searches, perhaps for other code (e.g. more numeric operations) the results would be different. On all devices with ARM processors, Java performed better than Xamarin C# code. The largest difference was under Android 2.3, where C# code run at approx. 70% of Java speed.

我的测试代码主要包含文本解析、替换和正则表达式搜索，对于其他代码（例如更多的数字运算），结果可能会有所不同。在配备 ARM 处理器的所有设备上，Java 的性能优于 Xamarin C# 代码。最大的区别是在 Android 2.3 下，其中 C# 代码运行速度约为 Java 速度的 70%。

On Intel emulator (with Intel HAX technology, emulator runs in fast virt mode), Xamarin C# code runs my sample code much faster than Java - about 1.35 time faster. Maybe Mono virtual machine code and libraries are much better optimized on Intel than on ARM?

在 Intel 模拟器（使用 Intel HAX 技术，模拟器在快速虚拟模式下运行）上，Xamarin C# 代码比 Java 运行我的示例代码快得多 - 大约快 1.35 倍。也许 Mono 虚拟机代码和库在 Intel 上比在 ARM 上优化得更好？

Edit July 8, 2013

编辑 2013 年 7 月 8 日

I just installed Genymotion Android emulator, which runs in Oracle VirtualBox, and again this one uses native Intel processor, not emulating ARM processor. As with Intel HAX emulator, again C# runs here much faster. Here are my results:

我刚刚安装了 Genymotion Android 模拟器，它在 Oracle VirtualBox 中运行，并且这个模拟器再次使用原生 Intel 处理器，而不是模拟 ARM 处理器。与英特尔 HAX 仿真器一样，C# 再次在这里运行得更快。这是我的结果：

Genymotion emulator - Intel (Android 4.1.1, API 16)

Genymotion 模拟器 - 英特尔（Android 4.1.1，API 16）

Java: Grand total time (5 runs): 2069 ms, with file reading total: 2248 ms

C#: Grand total time (5 runs): 1543 ms, with file reading total: 1642 ms

Java：总计时间（5 次运行）：2069 毫秒，文件读取总计：2248 毫秒

C#：总计时间（5 次运行）：1543 毫秒，文件读取总计：1642 毫秒

I then noticed that there was an update to Xamarin.Android beta, version 4.7.11, with release notes mentioning some changes in Mono runtime as well. Decided to quickly test some ARM devices, and big surprise - C# numbers improved:

然后我注意到 Xamarin.Android 测试版有一个更新，版本 4.7.11，发行说明中也提到了 Mono 运行时的一些变化。决定快速测试一些 ARM 设备，大惊喜 - C# 数字改进：

BN Nook XD+, ARM (Android 4.0)

BN Nook XD+, ARM (Android 4.0)

Java: Grand total time (5 runs): 8103 ms, with file reading total: 8569 ms

C#: Grand total time (5 runs): 7951 ms, with file reading total: 8161 ms

Java：总计时间（5 次运行）：8103 毫秒，文件读取总计：8569 毫秒

C#：总计时间（5 次运行）：7951 毫秒，文件读取总计：8161 毫秒

Wow! C# is now better than Java? Decided to repeat the test on my Galaxy Note 2:

哇！C#现在比Java好吗？决定在我的 Galaxy Note 2 上重复测试：

Samsung Galaxy Note 2 - ARM (Android 4.1.1)

三星 Galaxy Note 2 - ARM (Android 4.1.1)

Java: Grand total time (5 runs): 9675 ms, with file reading total: 10028 ms

C#: Grand total time (5 runs): 9911 ms, with file reading total: 10104 ms

Java：总计时间（5 次运行）：9675 毫秒，文件读取总计：10028 毫秒

C#：总计时间（5 次运行）：9911 毫秒，文件读取总计：10104 毫秒

Here C# seems to be only slightly slower, but these numbers gave me a pause: Why the time is longer than on Nook HD+, even though Note 2 has a faster processor? The answer: power saving mode. On Nook, it was disabled, on Note 2 - enabled. Decided to test with power saving mode disabled (as with enabled, it also limits the processor speed):

这里的 C# 似乎只是稍微慢了一点，但这些数字让我停顿了一下：为什么即使 Note 2 有更快的处理器，时间也比 Nook HD+ 上的时间长？答案是：省电模式。在 Nook 上，它被禁用，在 Note 2 上 - 启用。决定在禁用省电模式的情况下进行测试（与启用一样，它也会限制处理器速度）：

Samsung Galaxy Note 2 - ARM (Android 4.1.1), power saving disabled

三星 Galaxy Note 2 - ARM (Android 4.1.1)，禁用省电

Java: Grand total time (5 runs): 7153 ms, with file reading total: 7459 ms

C#: Grand total time (5 runs): 6906 ms, with file reading total: 7070 ms

Java：总计时间（5 次运行）：7153 毫秒，文件读取总计：7459 毫秒

C#：总计时间（5 次运行）：6906 毫秒，文件读取总计：7070 毫秒

Now, surprisingly, C# is slightly faster than Java on ARM processor as well. Big improvement!

现在，令人惊讶的是，C# 在 ARM 处理器上也比 Java 快一些。大改进！

Edit July 12, 2013

编辑 2013 年 7 月 12 日

We all know, that nothing beats native code for speed, and I was not satisfied with the performance of my sentence splitter in Java or C#, particularly that I need to improve it (and thus make it even slower). Decided to re-write it in C++. Here is a small (i.e. a smaller set of files than previous tests, for other reasons) comparison of the speed of native vs. Java on my Galaxy Note 2, with power saving mode disabled:

我们都知道，在速度方面，没有什么比本地代码更好的了，我对我的句子拆分器在 Java 或 C# 中的性能并不满意，特别是我需要改进它（从而使其更慢）。决定用 C++ 重写它。这是我的 Galaxy Note 2 上原生与 Java 速度的小型（即比以前的测试更小的文件集，出于其他原因）在禁用省电模式的情况下：

Java: Grand total time (5 runs): 3292 ms, with file reading total: 3454 ms

Java：总计时间（5 次运行）：3292 毫秒，文件读取总计：3454 毫秒

Native thumb: Grand total time (5 runs): 537 ms, with file reading total: 657 ms

本机拇指：总计时间（5 次运行）：537 毫秒，文件读取总计：657 毫秒

Native arm: Grand total time (5 runs): 458 ms, with file reading total: 587 ms

本机臂：总计时间（5 次运行）：458 毫秒，文件读取总计：587 毫秒

Looks like for my particular test, the native code is 6 to 7 times faster than Java. Caveat: could not use std::regex class on Android, so had to write my own specialized routines searching for paragraphs breaks or html tags. My initial tests of the same code on a PC using regex, were about 4 to 5 times faster than Java.

看起来对于我的特定测试，本机代码比 Java 快 6 到 7 倍。警告：无法在 Android 上使用 std::regex 类，因此必须编写自己的专门例程来搜索段落分隔符或 html 标签。我在 PC 上使用正则表达式对相同代码进行的初始测试比 Java 快大约 4 到 5 倍。

Phew! Waking raw memory with char* or wchar* pointers again, I instantly felt 20 years younger! :)

呼！再次用 char* 或 wchar* 指针唤醒原始记忆，我瞬间感觉年轻了 20 岁！:)

Edit July 15, 2013

编辑 2013 年 7 月 15 日

(Please see below, with edits of 7/30/2013, for much better results with Dot42)

（请参阅下文，并在 2013 年 7 月 30 日进行了编辑，以获得更好的 Dot42 效果）

With some difficulty, I managed to port my C# tests to Dot42 (version 1.0.1.71 beta), another C# platform for Android. Preliminary results show that Dot42 code is about 3x (3 times) slower than Xamarin C# (v. 4.7.11), on an Intel Android emulator. One problem is that System.Text.RegularExpressions class in Dot42 does not have the Split() function that I used in Xamarin tests, so I used Java.Util.Regex class instead, and Java.Util.Regex.Pattern.Split(), so in this particular place in the code, there is this small difference. Should not be a big problem though. Dot42 compiles to Dalvik (DEX) code, so it cooperates with Java on Android natively, does not need expensive interop from C# to Java like Xamarin.

遇到一些困难，我设法将我的 C# 测试移植到 Dot42（版本 1.0.1.71 beta），另一个适用于 Android 的 C# 平台。初步结果显示，在英特尔 Android 模拟器上，Dot42 代码比 Xamarin C# (v. 4.7.11) 慢约 3 倍（3 倍）。一个问题是 Dot42 中的 System.Text.RegularExpressions 类没有我在 Xamarin 测试中使用的 Split() 函数，所以我改用 Java.Util.Regex 类和 Java.Util.Regex.Pattern.Split() ，所以在代码中的这个特殊地方，有这么小的区别。不过应该问题不大。Dot42 编译为 Dalvik (DEX) 代码，因此它与 Android 上的 Java 原生协作，不需要像 Xamarin 那样从 C# 到 Java 的昂贵的互操作。

Just for comparison, I also run the test on ARM devices - here the Dot42 code is "only" 2x slower than Xamarin C#. Here are my results:

只是为了比较，我还在 ARM 设备上运行测试 - 这里的 Dot42 代码“仅”比 Xamarin C# 慢 2 倍。这是我的结果：

HTC Nexus One Android 2.3.7 (ARM)

HTC Nexus One Android 2.3.7 (ARM)

Java: Grand total time (5 runs): 12187 ms, with file reading total: 13200 ms

Xamarin C#: Grand total time (5 runs): 13935 ms, with file reading total: 14465 ms

Dot42 C#: Grand total time (5 runs): 26000 ms, with file reading total: 27168 ms

Java：总计时间（5 次运行）：12187 毫秒，文件读取总计：13200 毫秒

Xamarin C#：总计时间（5 次运行）：13935 毫秒，文件读取总计：14465 毫秒

Dot42 C#：总计时间（5 次运行）：26000 毫秒，文件读取总计：27168 毫秒

Samsung Galaxy Note 2, Android 4.1.1 (ARM)

三星 Galaxy Note 2，安卓 4.1.1 (ARM)

Java: Grand total time (5 runs): 6895 ms, with file reading total: 7275 ms

Xamarin C#: Grand total time (5 runs): 6466 ms, with file reading total: 6720 ms

Dot42 C#: Grand total time (5 runs): 11185 ms, with file reading total: 11843 ms

Java：总计时间（5 次运行）：6895 毫秒，文件读取总计：7275 毫秒

Xamarin C#：总计时间（5 次运行）：6466 毫秒，文件读取总计：6720 毫秒

Dot42 C#：总计时间（5 次运行）：11185 毫秒，文件读取总计：11843 毫秒

Intel emulator, Android 4.2 (x86)

英特尔模拟器，Android 4.2 (x86)

Java: Grand total time (5 runs): 2389 ms, with file reading total: 2770 ms

Xamarin C#: Grand total time (5 runs): 1748 ms, with file reading total: 1933 ms

Dot42 C#: Grand total time (5 runs): 5150 ms, with file reading total: 5459 ms

Java：总计时间（5 次运行）：2389 毫秒，文件读取总计：2770 毫秒

Xamarin C#：总计时间（5 次运行）：1748 毫秒，文件读取总计：1933 毫秒

Dot42 C#：总计时间（5 次运行）：5150 毫秒，文件读取总计：5459 毫秒

To me, it was also interesting to note that Xamarin C# is slightly faster than Java on a newer ARM device and slightly slower on the old Nexus One. If anyone would like to run these tests as well, please let me know and I'll update the sources on GitHub. It would be particularly interesting to see results from a real Android device with Intel processor.

对我来说，有趣的是，Xamarin C# 在较新的 ARM 设备上比 Java 略快，在旧的 Nexus One 上略慢。如果有人也想运行这些测试，请告诉我，我会更新 GitHub 上的源代码。看到带有英特尔处理器的真实 Android 设备的结果会特别有趣。

Update 7/26/2013

2013 年 7 月 26 日更新

Just a quick update, re-compiled by benchmark apps with the latest Xamarin.Android 4.8, and also with dot42 1.0.1.72 update released today - no significant changes from the results reported before.

只是一个快速更新，由具有最新 Xamarin.Android 4.8 和今天发布的 dot42 1.0.1.72 更新的基准应用程序重新编译 - 与之前报告的结果没有重大变化。

Update 7/30/2013 - better results for dot42

2013 年 7 月 30 日更新 - dot42 的结果更好

Re-tested Dot42 with Robert's (from dot42 makers) port of my Java code to C#. In my C# port done initially for Xamarin, I replaced some native Java classes, like ListArray, with List class native to C#, etc. Robert did not have my Dot42 source code, so he ported it again from Java and used original Java classes in such places, which benefits Dot42, I guess because it runs in Dalvik VM, like Java, and not in Mono, like Xamarin. Now Dot42 results are much better. Here is a log from my testing:

使用我的 Java 代码到 C# 的 Robert（来自 dot42 制造商）端口重新测试了 Dot42。在我最初为 Xamarin 完成的 C# 移植中，我用 C# 原生的 List 类替换了一些原生 Java 类，如 ListArray，等等。Robert 没有我的 Dot42 源代码，所以他再次从 Java 移植它并在这样的地方，有利于 Dot42，我猜是因为它在 Dalvik VM 中运行，如 Java，而不是在 Mono 中，如 Xamarin。现在 Dot42 的结果要好得多。这是我测试的日志：

7/30/2013 - Dot42 tests with more Java classes in Dot42 C#

Intel emulator, Android 4.2

Dot42, Greg's Code using StringBuilder.Replace() (as in Xamarin):
Grand total time (5 runs): 3646 ms, with file reading total: 3830 ms

Dot42, Greg's Code using String.Replace() (as in Java and Robert's code):
Grand total time (5 runs): 3027 ms, with file reading total: 3206 ms

Dot42, Robert's Code:
Grand total time (5 runs): 1781 ms, with file reading total: 1999 ms

Xamarin:
Grand total time (5 runs): 1373 ms, with file reading total: 1505 ms

Java:
Grand total time (5 runs): 1841 ms, with file reading total: 2044 ms

ARM, Samsung Galaxy Note 2, power saving off, Android 4.1.1

Dot42, Greg's Code using StringBuilder.Replace() (as in Xamarin):
Grand total time (5 runs): 10875 ms, with file reading total: 11280 ms

Dot42, Greg's Code using String.Replace() (as in Java and Robert's code):
Grand total time (5 runs): 9710 ms, with file reading total: 10097 ms

Dot42, Robert's Code:
Grand total time (5 runs): 6279 ms, with file reading total: 6622 ms

Xamarin:
Grand total time (5 runs): 6201 ms, with file reading total: 6476 ms

Java:
Grand total time (5 runs): 7141 ms, with file reading total: 7479 ms

2013 年 7 月 30 日 - 在 Dot42 C# 中使用更多 Java 类进行 Dot42 测试

英特尔模拟器，Android 4.2

Dot42，使用 StringBuilder.Replace() 的 Greg 代码（如在 Xamarin 中）：
总计时间（5 次运行）：3646 毫秒，文件读取总计：3830 毫秒

Dot42，使用 String.Replace() 的 Greg 代码（如 Java 和 Robert 的代码）：
总计时间（5 次运行）：3027 毫秒，文件读取总计：3206 毫秒

Dot42，罗伯特的代码：
总计时间（5 次运行）：1781 毫秒，文件读取总计：1999 毫秒

Xamarin：
总计时间（5 次运行）：1373 毫秒，文件读取总计：1505 毫秒

Java：
总计时间（5 次运行）：1841 毫秒，文件读取总计：2044 毫秒

ARM，三星 Galaxy Note 2，省电关闭，Android 4.1.1

Dot42，使用 StringBuilder.Replace() 的 Greg 代码（如在 Xamarin 中）：
总计时间（5 次运行）：10875 毫秒，文件读取总计：11280 毫秒

Dot42，使用 String.Replace() 的 Greg 代码（如 Java 和 Robert 的代码）：
总计时间（5 次运行）：9710 毫秒，文件读取总计：10097 毫秒

Dot42，罗伯特的代码：
总计时间（5 次运行）：6279 毫秒，文件读取总计：6622 毫秒

Xamarin：
总计时间（5 次运行）：6201 毫秒，文件读取总计：6476 毫秒

Java：
总计时间（5 次运行）：7141 毫秒，文件读取总计：7479 毫秒

I still think that Dot42 has a long way to go. Having Java-like classes (e.g. ArrayList) and a good performance with them would make porting code from Java to C# slightly easier. However, this is something I would not be likely to do a lot. I would rather want to use existing C# code (libraries etc.), which will use native C# classes (e.g. List), and that would perform slowly with the current dot42 code, and very well with Xamarin.

我仍然认为Dot42还有很长的路要走。拥有类似 Java 的类（例如 ArrayList）并且它们具有良好的性能将使将代码从 Java 移植到 C# 稍微容易一些。但是，这是我不太可能做很多事情的事情。我宁愿使用现有的 C# 代码（库等），这些代码将使用本机 C# 类（例如 List），并且使用当前的 dot42 代码执行速度会很慢，而使用 Xamarin 会很好。

Greg

格雷格

回答by klvtsov

Yeah, Xamarin's Mono virtual machine is more impressive than Google's Dalvik used in Android. I have tested it with HTC Flyer and Acer Iconia Tab tablets to benchmark the C# port of Android through Mono against Java Dalvik, with the C# implementation of Android well and truly trouncing the Java-based Dalvik.

是的，Xamarin 的 Mono 虚拟机比 Android 中使用的 Google 的 Dalvik 更令人印象深刻。我已经用 HTC Flyer 和 Acer Iconia Tab 平板电脑对其进行了测试，通过 Mono 对 Android 的 C# 端口与 Java Dalvik 进行了基准测试，Android 的 C# 实现很好，真正击败了基于 Java 的 Dalvik。

回答by Christopher

We recently investigated using Xamarin for an app. We utilized the C# code we had already written for the Windows RT version of our app. Some specific details had to be rewritten for the Android version.

我们最近调查了将 Xamarin 用于应用程序。我们使用了我们已经为我们的应用程序的 Windows RT 版本编写的 C# 代码。必须为 Android 版本重写一些特定的细节。

What we discovered is that I/O in Xamarin C# is approximately 2x slower than Java. Our app is heavily I/O bound. We have not discovered the cause of this yet, but at the moment we are assuming that it is due to marshaling. While we do try to stay inside the Mono VM most of the time, we do not know how Mono actually accesses the disk.

我们发现 Xamarin C# 中的 I/O 比 Java 慢大约 2 倍。我们的应用程序受 I/O 限制很大。我们还没有发现造成这种情况的原因，但目前我们假设这是由于编组造成的。虽然我们大部分时间都试图留在 Mono 虚拟机中，但我们不知道 Mono 实际如何访问磁盘。

It is also telling that our C# code uses SQLite.NET (https://github.com/praeclarum/sqlite-net). Identical fetches using the SQLite.NET code are also 2x slower than using Android's Java SQLite wrapper. After looking at the source code, it appears to bind directly to the C .dll, so I do not know why it's so much slower. One possibility is that marshaling strings from native to Java may be faster on Android than native to C# is on Xamarin.

这也说明我们的 C# 代码使用 SQLite.NET ( https://github.com/praeclarum/sqlite-net)。使用 SQLite.NET 代码的相同提取也比使用 Android 的 Java SQLite 包装器慢 2 倍。看了源码，好像是直接绑定到C .dll上的，不知道为什么这么慢。一种可能性是，在 Android 上将字符串从本机编组到 Java 可能比在 Xamarin 上编组到 C# 本机更快。

回答by Daniel

This is another more updated blog post I would like to share with you. He compares Xamarin to native code and Cordova on both IOs and Android.

这是我想与您分享的另一篇更新的博客文章。他将 Xamarin 与 IO 和 Android 上的本机代码和 Cordova 进行了比较。

In a nutshell, Xamarin performs sometimes better than native code. He tested the app size, load times, loading a list from Azure service and prime number computation.

简而言之，Xamarin 有时比本机代码执行得更好。他测试了应用程序大小、加载时间、从 Azure 服务加载列表和素数计算。

Enjoy!

享受！

Edit: I updated the dead link and I noticed that there is a part 2

编辑：我更新了死链接，我注意到有第 2 部分

回答by Venkataramana Madugula

I came across this interesting post

https://medium.com/@harrycheung/mobile-app-performance-redux-e512be94f976#.kfbauchtz

https://medium.com/@harrycheung/mobile-app-performance-redux-e512be94f976#.kfbauchtz

Hope this information helps.

希望这些信息有帮助。

回答by Denis Gordin

It's pretty old tests but could be relevant: https://github.com/EgorBo/Xamarin.Android-vs-Java

这是相当古老的测试，但可能是相关的：https: //github.com/EgorBo/Xamarin.Android-vs-Java

Arithmetic test

算术测试

Collections, generics, custom value types

集合、泛型、自定义值类型

Working with strings

使用字符串

UPD:new data with Google Pixel 2 (thanks yousha-aleayoub)

UPD：Google Pixel 2 的新数据（感谢yousha-aleayoub）

回答by Rolf ツ

Performance

表现

Performance is a vague word if you don't define what you mean by performance, if it's plain computation performance Xamarin can be faster than Java depending on the nature of the computation.

如果您没有定义性能的含义，则性能是一个模糊的词，如果它是简单的计算性能，根据计算的性质，Xamarin 可能比 Java 快。

Android nativly comes with multipe forms to execute code in:

Android 原生带有多种形式来执行代码：

• RenderScript (CPU and GPU)
• Java (SDK)
• C++ (NDK)
• OpenGL (GPU)

• RenderScript（CPU 和 GPU）
• Java (SDK)
• C++ (NDK)
• OpenGL (GPU)

It is quite obvious that when executing code the more native the solution the faster it will be. A run-time based language will never beat a language that directly runs on the CPU.

很明显，当执行代码时，解决方案越本地化，速度就越快。基于运行时的语言永远不会打败直接在 CPU 上运行的语言。

But on the other hand if you want to measure real-life usage performance Java is propbaby going to be faster then Xamarin.

但另一方面，如果你想衡量现实生活中的使用性能，Java 肯定会比 Xamarin 更快。

Xamarin and why it can be slower

Xamarin 以及为什么它会变慢

When comparing Xamarin with plain old Java applications, performance can very well be faster for Xamarin as it can be slower.

将 Xamarin 与普通的旧 Java 应用程序进行比较时，Xamarin 的性能可能会更快，因为它可能会更慢。

In a real world example Xamarin applications are very likely to be slower than Java applications because many Android/Java (system) calls need to be delegated to and from the Xamarin run-time using so called bindings.

在实际示例中，Xamarin 应用程序很可能比 Java 应用程序慢，因为需要使用所谓的绑定将许多 Android/Java（系统）调用委派到 Xamarin 运行时或从 Xamarin 运行时委派。

There are a few different types of bindings that are important to know:

有几种不同类型的绑定很重要：

• JNI (Java Native Interface):The binding used in many android applications to interface between Java code (SDK) and native C++ code (NDK).
• MCW (Managed Callable Wrappers):A binding that is available in Xamarin to interface from managed C# code to Java code (Android run-time).
• ACW (Android Callable Wrappers):A binding that is available in Xamarin to interface from Java code (Android run-time) to managed C# code.

• JNI（Java Native Interface）：许多Android应用程序中使用的绑定，用于在Java代码（SDK）和本机C++代码（NDK）之间进行接口。
• MCW（托管可调用包装器）：Xamarin 中提供的一种绑定，用于将托管 C# 代码连接到 Java 代码（Android 运行时）。
• ACW（Android 可调用包装器）：Xamarin 中提供的一种绑定，用于从 Java 代码（Android 运行时）到托管 C# 代码的接口。

More on MCW and ACW here: https://developer.xamarin.com/guides/cross-platform/application_fundamentals/building_cross_platform_applications/part_1_-_understanding_the_xamarin_mobile_platform/

有关 MCW 和 ACW 的更多信息，请访问：https: //developer.xamarin.com/guides/cross-platform/application_fundamentals/building_cross_platform_applications/part_1_-_understanding_the_xamarin_mobile_platform/

Bindings are in terms of performance very very costly. Invoking a C++ method from Java adds a huge overhead in calling time, calling a C++ method from within C++ is many many many times faster.

绑定在性能方面非常昂贵。从 Java 调用 C++ 方法会增加调用时间的巨大开销，从 C++ 调用 C++ 方法要快很多很多倍。

Someone did a performance test to calculate how many Java operations on average a JNI call costs: What is the quantitative overhead of making a JNI call?

有人做了一个性能测试，计算一次 JNI 调用平均花费多少 Java 操作：进行一次 JNI 调用的定量开销是多少？

But not only JNI calls are costly so are calls to and from MCW and ACW. Real world Xamarin applications make many calls using bindings and because of this real world usage of an Xamarin application can be (and will be in general) slower than a plain old Java application. However depending on how the Xamarin application was designed it is very likely that the user won't even notice the difference.

但不仅 JNI 调用成本高昂，往返 MCW 和 ACW 的调用也是如此。现实世界的 Xamarin 应用程序使用绑定进行许多调用，并且由于在现实世界中使用 Xamarin 应用程序可能（并且通常会）比普通的旧 Java 应用程序慢。但是，根据 Xamarin 应用程序的设计方式，用户很可能甚至不会注意到差异。

TLDR/Conclusion:Xamarin needs to using al sorts bindings, which are time costly.

TLDR/结论：Xamarin 需要使用各种绑定，这很费时间。

Besides bindings, there are many other factors involved when talking about real-world performance, for example: size of the binary, loading the app in memory, I/O operations and many more. A blog post that investigates some of these things can be found here: https://magenic.com/thinking/mobile-development-platform-performance-part-2-native-cordova-classic-xamarin-xamarin-forms

除了绑定，在谈论实际性能时还涉及许多其他因素，例如：二进制文件的大小、在内存中加载应用程序、I/O 操作等等。可以在此处找到调查其中一些事情的博客文章：https: //magenic.com/thinking/mobile-development-platform-performance-part-2-native-cordova-classic-xamarin-xamarin-forms

回答by Burgito

Here are a few informations I found in another test between native, Xamarin and Xamarin.Forms solutions (the tests also include iOS performances) on the two following devices :

以下是我在本机、Xamarin 和 Xamarin.Forms 解决方案（测试还包括 iOS 性能）之间在以下两个设备上进行的另一项测试中发现的一些信息：

Samsung Galaxy A7: Android OS version: 6.0 Central-processing unit: Octa-core 1.9 GHz Cortex-A53 RAM: 3GB Display resolution: 1920×1080

三星 Galaxy A7：Android 操作系统版本：6.0 中央处理器：八核 1.9 GHz Cortex-A53 内存：3GB 显示分辨率：1920×1080

iPhone 6s: iOS version: 10.3.3 Central-processing unit: Dual-core 1.84 GHz Twister RAM: 2 GB Display resolution: 1334×750

iPhone 6s：iOS 版本：10.3.3 中央处理器：双核 1.84 GHz Twister 内存：2 GB 显示分辨率：1334×750

Comparison is made on a few common features, each one with its own application :

比较了一些常见的功能，每一个都有自己的应用：

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

Each test is repeted several times, the graphs show the average results.

每个测试重复数次，图表显示平均结果。

---

---

Hello World

你好，世界

---

---

Rest API

休息API

Set of tests aimed at measuring the time it takes for the app to send a request through REST API and receive the response back without further data processing, using OpenWeatherMap API.

一组测试旨在测量应用程序使用 OpenWeatherMap API 通过 REST API 发送请求并接收响应而无需进一步数据处理所需的时间。

---

---

JSON OperationsTests made using Newtonsoft Json.net framework to serialize and deserialize JSON objects in all Xamarin apps. Native Android serialization and deserialization tested using two Java libraries: Hymanson and GSON.

JSON 操作测试使用 Newtonsoft Json.net 框架在所有 Xamarin 应用程序中序列化和反序列化 JSON 对象。使用两个 Java 库测试原生 Android 序列化和反序列化：Hymanson 和 GSON。

Two runs are made, one first from scratch and a second one with cached infos and operations

进行了两次运行，第一次从头开始，第二次使用缓存的信息和操作

First run :

第一次运行 ：

(Native iOS JSON Operations is killing this test btw, and Xamarin joins it in the second)

（本机 iOS JSON 操作正在扼杀这个测试 btw，而 Xamarin 在第二个加入它）

---

---

Photo Operations

照片操作

First load on images with three different resolutions :

首先加载具有三种不同分辨率的图像：

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

Something seemed unsure about the Xamarin.Forms results for this test, so it is not included in the graph.

此测试的 Xamarin.Forms 结果似乎有些不确定，因此未包含在图表中。

---

---

SQLite Operations

SQLite 操作

Two operations tested :

测试了两个操作：

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

With databases having 10,000 records. All operations were processed internally on devices.

数据库有 10,000 条记录。所有操作均在设备内部处理。

---

---

Xamarin Native (Xamarin.iOS/Xamarin.Android) show themselves as rather good alternatives to the native code, whereas Xamarin.Forms seems slow in a lot of cases, but it can be a really good solution to develop really simple applications fastly.

Xamarin Native (Xamarin.iOS/Xamarin.Android) 显示自己是本机代码的相当不错的替代品，而 Xamarin.Forms 在很多情况下似乎很慢，但它可以是快速开发非常简单的应用程序的非常好的解决方案。

Complete test comes from this source :

完整的测试来自这个来源：

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

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

Thank you for giving me the explanations to enhance my answer, hope this helps a little :)

感谢您给我解释以增强我的答案，希望这会有所帮助:)