在XAMARIN C和Java编写的Android应用程序的性能是否有基准(代码和结果)比较？

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

我发现Xamarin声称他们在Android和他们的C编译的应用程序上的单声道实现比Java代码快。在不同的Android平台上，是否有人对非常相似的Java和C代码执行实际的基准测试，以验证这些要求，可以发布代码和结果吗？

2013年6月18日增补

由于没有答案，也找不到其他人做的基准，所以决定自己做测试。不幸的是，我的问题仍然是"锁定"的，因此我不能将此作为答案发布，只能编辑问题。请投票重新打开这个问题。对于C，我使用了xamarin.android版本。4.7.09001(β)。源代码、我用于测试和编译APK包的所有数据都在Github上：

Java：HTTPS://GITHUBCOM/GRGKO/TSSETUPUBJAVA

C：https://github.com/gregko/ttssetup_c_sharp

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

我的测试结果

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

HTC Nexus One Android 2.3.7(API 10)-氰基元模式只读存储器

Java：总计时间(5次运行)：12361毫秒，文件读取总数：13304毫秒

C：总计时间(5次运行)：17504 ms，文件读取总计：17956 ms

三星Galaxy s2 SGH-I777(Android 4.0.4，API 15)-氰基mod ROM

Java：总计时间(5次运行)：8947毫秒，文件读取总数：9186毫秒

C：总计时间(5次运行)：9884 ms，文件读取总计：10247 ms

三星GT-N7100(Android 4.1.1 Jellybean，API 16)-三星ROM

Java：总计时间(5次运行)：9742毫秒，文件读取总数：10111毫秒

C：总计时间(5次运行)：10459 ms，文件读取总计：10696 ms

Emulator-Intel(Android 4.2，API 17)

Java：总计时间(5次运行)：2699毫秒，文件读取总数：3127毫秒

C：总计时间(5次运行)：2049 ms，文件读取总计：2182 ms

Emulator-Intel(Android 2.3.7，API 10)

Java：总计时间(5次运行)：2992毫秒，文件读取总数：3591毫秒

C：总计时间(5次运行)：2049 ms，文件读取总计：2257 ms

Emulator-ARM(Android 4.0.4，API 15)

Java：总计时间(5次运行)：41751毫秒，文件读取总数：43866毫秒

C：总计时间(5次运行)：44136 ms，文件读取总计：45109 ms

简要讨论

我的测试代码主要包含文本解析、替换和regex搜索，对于其他代码(例如更多的数字操作)，结果可能会有所不同。在所有具有ARM处理器的设备上，Java都比XAMARIN C代码更好。最大的差异是在Android 2.3下，其中C代码的运行速度约为Java速度的70%。

在英特尔仿真器上(用英特尔HAX技术，仿真器运行在快速VILT模式)，XAMARIN C代码的运行代码比Java快得多，大约快了1.35倍。也许单虚拟机代码和库在Intel上比在ARM上优化得更好？

编辑2013年7月8日

我刚刚安装了genymotion android模拟器，它在Oracle virtualbox中运行，而且这一个使用本机Intel处理器，而不是模仿ARM处理器。与Intel Hax Emulator一样，C_在这里运行得更快。以下是我的结果：

Genymotion Emulator-Intel(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

然后我注意到Xamarin.android测试版4.7.11有了更新，发行说明也提到了Mono运行时的一些变化。决定快速测试一些ARM设备，大大提高了C数字：

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

真的！C现在比Java好吗？决定在我的星系注2上重复测试：

三星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

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

三星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

现在，令人惊讶的是，C语言比ARM处理器上的Java稍微快一些。大进步！

编辑2013年7月12日

我们都知道，没有什么比本地代码更快，而且我不满意Java或C语言中的句子分割器的性能，特别是我需要改进它(从而使它变得更慢)。决定重新编写它在C++中。这里是一个小的(也就是比以前的测试更小的一组文件，因为其他原因)，比较我的Galaxy Note 2上的原生对Java的速度。

相关讨论

Nexus 7 4.2.2上的调试模式，对字符串和Xamarin Alpha 9进行了一些优化：总时间：3907 ms，文件读取总计：4016。"5次跑步"是什么意思？
同平台发布方式：总时间：2192 ms，文件读取总时间：2279
但是您的代码可以优化得更多。
@Softlion，谢谢你也测试这个！通过5次运行，我的意思是我按下"开始测试"按钮5次，然后按下手机上的"后退"按钮退出应用程序，然后它将5次运行的总时间输出到调试控制台。请给我发送建议的优化，最好是通过电子邮件或私人消息，因为我们不能在这里键入太多。但是我们必须以类似的方式优化Java代码，以便在C语言和Java之间有一个公平的比较。
你用的绳子太多了。您应该只使用一个StringBuilder和字符串索引。字符串是不可变的，并在每个连接上分配新的内存。您不应该使用"count()"而是"count"。这是一个"经典"错误。
@Softlion，我尽可能使用架线工。在C i中，我也用它们来搜索和替换字符，在Java中不能，因为它没有这个函数。不管怎样，出于本文的目的，搜索和替换字符并不重要，因为字符不会出现在我的测试文件中——搜索完成，但没有替换，所以不需要改变Java中的"不可变"字符串。我有许多类似的评论，介绍了提议的变更，对结果没有任何重大影响。请指出具体的变化，我可以再次测试。
@Softlion，我刚刚查看了我的c code for.count vs.count()-我正确使用了它们，列表使用.count，数组使用.count()，如string[]数组。这不是一个"经典"错误，否则只不过是一个语法错误，不能让代码编译…
count()是一个Linq方法，它读取整个可枚举的。对于数组，必须使用.length而不是count()。任何其他使用重字符串连接的地方，包括循环中，都不应该这样做。这意味着要重写算法，因为应该使用字符串索引+长度和最少数量的StringBuilder，而不是您所做的。另外，您应该使用静态regex，它们是线程安全的。
当你告诉我这样的方法时，请具体说明你说的是Java还是C语言。我猜Linq应该是C。由于您可以随时获取我的源代码，请根据您的建议修改它并发布结果。我在过去尝试过类似的修改，但没有发现性能有任何改进。对数组使用.count()的唯一地方是在主测试循环中，循环遍历10个文件的列表。无法想象这将如何改变基准结果。
我修改了它，但我对Git的理解不够。我只知道Java的基础知识，所以我不会告诉任何关于Java代码的事情。
@软狮，谢谢！如果可能的话，请与我分享Emial对C代码的修改(hyperionics.com的gregko)，我会运行一些测试并发布它们。在您的测试中，您看到了与您的代码模型有什么不同吗？我一直渴望学习，再次感谢！
我对apk的大小和运行时的内存消耗感到好奇？
@Numan-对于Xamarin，即同时嵌入Intel和Armeabi-V7a二进制文件的APK，该包大约为5.6 MB，内置于最新稳定Xamarin的发布模式中。对于dot42和Java，它低于200 kb。我不确定在Android上衡量内存使用的最佳方法是什么
@Gregko在Xamarin没有档案员吗？在ADT(Eclipse)中，您可以分析应用程序的内存使用情况。
@ NUMAN-Android调试监视器显示了非常类似的C和Java的堆使用(对于通过我的测试文件运行的单个MB大约为5 MB)。我看不出有任何方法来显示总进程内存使用情况，因为XAMARIN将占用更多，因为它需要先加载单运行库，然后再执行任何代码，而Java和DOT42C代码则直接在Dalvik VM中执行。
"这个问题可能会引起辩论、争论、投票或扩展讨论"<-见上文；)
@LearnCoCS2D-我只报告具体的结果和数字，即事实。先生们，不要争论事实：)
好吧，科学家们知道；)观察到的行为和事实之间有区别。它还有很多要变成事实，即使这样，对其他用户/情况的适用性仍然存在疑问。这是基准测试的关键所在，它们只是表面上呈现事实，直到您发现供应商X已经为特定的基准测试应用程序优化了其驱动程序。在相关的记录中，曾经有人证明水具有记忆性(即顺势疗法测试)，在考虑并排除测试者的偏见后，这一点被推翻，然后它没有显示出任何统计意义。
另外，随着下一个+0.1版本的推出，这些性能特性可能会发生显著的变化——也就是说，您在这里所做的所有努力都从"事实"变为"无意义"。然而，任何来到这里的人都可能认为这是事实，并得出错误的结论。基准测试的另一个关键点是：它们在给定的时间和所用软件的版本方面仅具有代表性。第二天，它们可能不再反映现实。你必须不断地重新测试结果。这就是为什么这里的结果可以被认为是主观的，几乎没有意义。
这是一个非常有趣的比较。请你也试着在android l上做比较好吗，因为art已经取代了dalvik，而且应该更快？
@AndroidDeveloper，我不再订阅Xamarin，因此无法在Xamarin端执行此操作。
Github上的链接已断开！
我投票决定将这个问题作为非主题结束，因为所包含的信息已过时3年，不符合任何可接受问题的当前标准。

是的，Xamarin的单虚拟机比谷歌在Android中使用的Dalvik更令人印象深刻。我已经用HTC FLIER和宏碁ICONICATIAL平板电脑测试了它，通过JavaDalvik的单声道对Android的C端口进行了测试，用Android的C实现实现了真正的基于Java的Dalvik。

相关讨论

@彼得·劳里，请看我对这个问题的最新情况。我确实打算将我的真实生活中的Java代码的一部分移植到C语言并运行基准，然后在这里发布它们——如果他们重新打开我的问题，那就是，因为这样的警卫人员几乎立即关闭它。
@我现在进行了测试，并在StackOverflow上发布了结果，但是在问题本身中，因为它仍然处于"锁定"状态，无法发布答案。如果可以，请添加投票以重新打开问题。结果很有意思，在ARM Java上获胜，英特尔上的莫诺河C代码快得多。
GRGGKO值得注意的是，你看到C的仿真速度更快，但是Java在真实电话上的速度更快。对我来说，这是一个重要的区别。我不担心模拟器的性能，事实上，我建议您希望模拟器和真实的一样慢/快。我投票决定重新开放。
@彼得·劳里，谢谢你的投票！还要注意的是，在ARM仿真器上，C语言的速度比Java慢。我认为英特尔上的单声道虚拟机和运行时都比ARM更好地优化和运行速度更快，或者英特尔上的Java Dalvik VM不如ARM好。也张贴在Xamarin论坛，也许他们会看看，并尝试优化单声道为手臂。
@Gregko我宁愿看到模拟器以与目标手机相同的速度运行。最好能让他们放慢速度来完成同样的任务。否则，它就没有测试环境那么好了，因为它的行为与实际情况非常不同。
@彼得拉弗里同意，很不幸，我没有任何手机与英特尔处理器进行比较。如果有人拥有这样的设备，也可以在那里运行我的测试并发布结果，那就太好了。
@Gregko Afaik，Intel处理器使用3倍的功率进行相同的处理，这就是为什么很少有Intel手机的原因。我怀疑桌上型手机可能是英特尔提供Linux等功能的，而你可能是运行Android的。
使用正则表达式作为性能测试时要小心。重新实现中的算法差异会造成巨大的差异。您可能在上面测试的是re的实现质量，而不是dalvik或mono vms。一个更好的测试是手工编写的解析代码，它使用相同的、显而易见的算法，这些算法以一种习惯于每种语言的风格编写。
GRGGKO你能更新帖子来反映Xamarin的新变化，并将它与原生Java进行比较吗？
@尤里迪塞01，我不使用也不再有Xamarin了，对不起…
如果不解释如何执行这些测试或测试结果，这个答案就毫无价值。就像现在一样：完全基于意见。

1	I came across this interesting post

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

Android App Performance

iOS App Performance

希望这些信息有帮助。

这是另一篇更新的博客文章，我想和你分享。他将Xamarin与iOS和Android上的原生代码和Cordova进行了比较。

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

享受！

编辑：我更新了死链接，发现有第2部分

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

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

它还告诉我们，我们的C代码使用sqlite.net(https://github.com/praeclarum/sqlite net)。使用SQLite .NET代码的相同获取速度也比使用Android的Java SQLite包装器慢2X。在查看了源代码之后，它似乎直接绑定到c.dll，所以我不知道为什么它会慢得多。一种可能是，在XAMARIN上，从原生到Java的字符串封送可能比Android上的原生到C的更快。

相关讨论

以下是我在本机、Xamarin和Xamarin之间的另一个测试中发现的一些信息。以下两个设备上的表单解决方案(测试还包括iOS性能)：

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

iPhone 6S：iOS版本：10.3.3中央处理单元：双核1.84GHz捻线机RAM：2 GB显示分辨率：1334×750

比较了几个常见的特性，每个特性都有自己的应用：

1
2
3
4
5

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

每个测试都要重复几次，图表显示了平均结果。

你好世界

Basic Hellow World performance comparison

REST API

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

Rest API performance comparison

JSON操作使用newtonsoft json.net框架对所有xamarin应用程序中的json对象进行序列化和反序列化的测试。使用两个Java库：杰克逊和GSON测试本机Android序列化和反序列化。

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

第一次运行：

JSON serialization first run

JSON deserialization first run

(原生iOS JSON操作正在杀死这个测试BTW，而XAMARIN在第二个测试中加入它)

JSON Serialization second run

JSON Deserialization second run

照片操作

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

1
2
3

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

Image First Load Android

Image First Load iOS

关于Xamarin，似乎有一些不确定的地方。形成了这个测试的结果，所以它不包含在图表中。

sqlite操作

测试了两个操作：

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

数据库有10000条记录。所有操作都在设备上进行了内部处理。

SQLite Android performances

SQLite iOS performances

Xamarin native(xamarin.ios/xamarin.android)显示自己是本机代码的相当好的替代品，而xamarin.forms在很多情况下似乎很慢，但它可以是一个非常好的解决方案来快速开发真正简单的应用程序。

完整测试来自以下来源：

Performance Comparison: Xamarin.Forms, Xamarin.iOS, Xamarin.Android vs Android and iOS Native Applications

谢谢你给我解释，以加强我的回答，希望这有点帮助：)

性能

性能是一个模糊的词，如果您不定义性能的含义，如果它是简单的计算性能，XAMARIN可以比Java更快，这取决于计算的性质。

Android Nativly提供了多个表单来执行以下代码：

renderscript(CPU和GPU)
Java(SDK)
C++(NDK)
OpenGL(GPU)

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

但另一方面，如果你想测量现实生活中的使用性能，Java将会比XAMARIN更快。

Xamarin和为什么会慢一点

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

在现实世界中，XAMARIN应用程序很可能比Java应用程序慢，因为许多Android /Java(系统)调用需要使用所谓绑定来向XAMARIN运行时和从XAMARIN运行时委托。

有几种不同类型的绑定需要了解：

JNI(Java本机接口)：在许多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/

绑定的性能非常昂贵。从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呼叫成本高昂，MCW和ACW之间的呼叫成本也很高。现实世界XAMARIN应用程序使用绑定进行许多调用，并且由于这个现实世界XAMARIN应用程序的使用(一般来说)会比普通的Java应用程序慢。但是，根据Xamarin应用程序的设计方式，用户很可能不会注意到这种差异。

TLDR/结论：Xamarin需要使用al-sorts绑定，这需要花费大量的时间。

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

这是一个相当古老的测试，但可能是相关的：https://github.com/egorbo/xamarin.android-vs-java

算术测试

enter image description here

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

enter image description here

使用字符串

enter image description here

upd:GooglePixel2的新数据(谢谢你的分享)

Pixel 2 tests

相关讨论