Xamarin C # 및 Java로 작성된 Android 앱의 성능을 비교하는 벤치 마크 (코드 및 결과)가 있습니까?

Xamarin C # 및 Java로 작성된 Android 앱의 성능을 비교하는 벤치 마크 (코드 및 결과)가 있습니까? [닫은]

---

Xamarin은 Android에서 모노 구현과 C # 컴파일 된 앱이 Java 코드보다 빠르다고 주장했습니다. 다른 안드로이드 플랫폼에서 매우 유사한 Java 및 C # 코드에서 실제 벤치 마크를 수행하여 그러한 주장을 확인하고 코드와 결과를 게시 할 수 있습니까?

2013 년 6 월 18 일 추가됨

답이 없었으며 다른 사람들이 수행 한 벤치 마크를 찾을 수 없으므로 내 테스트를하기로 결정했습니다. 불행히도 내 질문은 "잠긴"상태로 유지되므로 답변으로 게시 할 수 없으며 질문 만 편집하십시오. 이 질문을 다시 열려면 투표하십시오. 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 파일에 대해 몇 가지 테스트를 실행했습니다. 각 실행은 10 개의 파일 모두에서 5 번 수행되었으며 3 개의 서로 다른 장치와 하나의 에뮬레이터의 총 시간이 아래에 게시되어 있습니다. 디버깅을 사용하지 않고 "릴리스"빌드 만 테스트했습니다.

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

Java : 총 시간 (5 회) : 12361ms, 파일 읽기 총량 : 13304ms

C # : 총 시간 (5 회) : 17504ms, 파일 읽기 총량 : 17956ms

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

Java : 총 시간 (5 회) : 8947ms, 파일 읽기 총계 : 9186ms

C # : 총 시간 (5 회) : 9884ms, 파일 읽기 총량 : 10247ms

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

Java : 총 시간 (5 회) : 9742ms, 파일 읽기 총계 : 10111ms

C # : 총 시간 (5 회) : 10459ms, 파일 읽기 총계 : 10696ms

에뮬레이터-인텔 (Android 4.2, API 17)

Java : 총 시간 (5 회) : 2699ms, 파일 읽기 총계 : 3127ms

C # : 총 시간 (5 회) : 2049ms, 파일 읽기 총량 : 2182ms

에뮬레이터-인텔 (Android 2.3.7, API 10)

Java : 총 시간 (5 회) : 2992ms, 파일 읽기 총계 : 3591ms

C # : 총 시간 (5 회) : 2049ms, 파일 읽기 총량 : 2257ms

에뮬레이터-Arm (Android 4.0.4, API 15)

Java : 총 시간 (5 회) : 41751ms, 파일 읽기 총계 : 43866ms

C # : 총 시간 (5 회) : 44136ms, 파일 읽기 총량 : 45109ms

간단한 토론

내 테스트 코드에는 주로 텍스트 파싱, 대체 및 Regex 검색이 포함되어 있으며 다른 코드 (예 : 더 많은 숫자 연산)의 경우 결과가 다를 수 있습니다. ARM 프로세서가 장착 된 모든 장치에서 Java는 Xamarin C # 코드보다 성능이 우수합니다. 가장 큰 차이점은 Android 2.3에서 C # 코드가 약 1에서 실행되는 것입니다. Java 속도의 70 %

Intel HAX 기술을 사용하는 Intel 에뮬레이터에서 에뮬레이터는 빠른 virt 모드로 실행됩니다. Xamarin C # 코드는 Java보다 훨씬 빠르게 샘플 코드를 약 1.35 배 빠르게 실행합니다. 아마도 모노 가상 머신 코드와 라이브러리가 ARM보다 인텔에서 훨씬 더 최적화되어 있습니까?

2013 년 7 월 8 일 수정

방금 Oracle VirtualBox에서 실행되는 Genymotion Android 에뮬레이터를 설치했으며 다시 ARM 프로세서를 에뮬레이션하지 않고 기본 Intel 프로세서를 사용합니다. Intel HAX 에뮬레이터와 마찬가지로 C #도 훨씬 빠르게 실행됩니다. 내 결과는 다음과 같습니다.

Genymotion 에뮬레이터-Intel (Android 4.1.1, API 16)

Java : 총 시간 (5 회) : 2069ms, 파일 읽기 총계 : 2248ms

C # : 총 시간 (5 회) : 1543ms, 파일 읽기 총계 : 1642ms

그런 다음 Xamarin.Android 베타 버전 4.7.11에 대한 업데이트가 있으며 Mono 런타임의 일부 변경 사항을 언급하는 릴리스 정보가 있음을 알았습니다. 일부 ARM 장치를 신속하게 테스트하기로 결정했으며 놀랍게도 C # 숫자가 향상되었습니다.

BN Nook XD +, ARM (Android 4.0)

Java : 총 시간 (5 회) : 8103ms, 파일 읽기 총량 : 8569ms

C # : 총 시간 (5 회) : 7951ms, 파일 읽기 총량 : 8161ms

와! C #이 이제 Java보다 낫습니까? Galaxy Note 2에서 테스트를 반복하기로 결정했습니다.

삼성 Galaxy Note 2-ARM (Android 4.1.1)

Java : 총 시간 (5 회) : 9675ms, 파일 읽기 총계 : 10028ms

C # : 총 시간 (5 회) : 9911ms, 파일 읽기 총계 : 10104ms

여기서 C #은 약간 느리게 보이지만이 숫자로 인해 일시 정지가 발생했습니다. Note 2의 프로세서 속도가 더 빠르더라도 Nook HD +보다 시간이 더 긴 이유는 무엇입니까? 답 : 절전 모드. Nook에서는 노트 2에서 비활성화되었습니다. 절전 모드가 비활성화 된 상태에서 테스트하기로 결정했습니다 (활성화 된 경우 프로세서 속도도 제한됨).

Samsung Galaxy Note 2-ARM (Android 4.1.1), 절전 기능 비활성화

Java : 총 시간 (5 회) : 7153ms, 파일 읽기 총량 : 7459ms

C # : 총 시간 (5 회) : 6906ms, 파일 읽기 총량 : 7070ms

놀랍게도 C #은 ARM 프로세서의 Java보다 약간 빠릅니다. 큰 개선!

2013 년 7 월 12 일 수정

우리 모두는 속도를 위해 원시 코드를 능가하는 것이 없으며 Java 또는 C #에서 문장 스플리터의 성능에 만족하지 못했으며 특히 개선해야합니다 (더 느리게 만들어야 함). C ++로 다시 작성하기로 결정했습니다. 다음은 절전 모드가 비활성화 된 상태에서 Galaxy Note 2의 기본 속도와 Java 속도를 비교 한 것입니다 (예를 들어 이전 테스트보다 작은 파일 세트).

Java : 총 시간 (5 회) : 3292ms, 파일 읽기 총계 : 3454ms

기본 엄지 : 총 시간 (5 회) : 537ms, 파일 읽기 총 시간 : 657ms

기본 암 : 총 시간 (5 회) : 458ms, 파일 읽기 총계 : 587ms

필자의 특정 테스트에서는 네이티브 코드가 Java보다 6-7 배 빠릅니다. 주의 사항 : Android에서 std :: regex 클래스를 사용할 수 없으므로 단락 나누기 또는 html 태그를 검색하는 고유 한 루틴을 작성해야했습니다. 정규식을 사용하는 PC에서 동일한 코드에 대한 초기 테스트는 Java보다 약 4 ~ 5 배 빠릅니다.

휴! char * 또는 wchar * 포인터로 원시 메모리를 다시 깨우면 20 년이 더 젊어졌습니다. :)

2013 년 7 월 15 일 수정

Dot42로 훨씬 더 나은 결과를 얻으려면 2013 년 7 월 30 일의 수정 사항으로 아래를 참조하십시오.

약간의 어려움으로 C # 테스트를 Android의 또 다른 C # 플랫폼 인 Dot42 (버전 1.0.1.71 베타)로 이식 할 수있었습니다. 예비 결과에 따르면 Intel 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로 비싼 상호 운용성이 필요하지 않습니다.

비교를 위해 ARM 장치에서도 테스트를 실행합니다. 여기서 Dot42 코드는 Xamarin C #보다 "배속"만 2 배 느립니다. 내 결과는 다음과 같습니다.

HTC Nexus One Android 2.3.7 (ARM)

Java : 총 시간 (5 회) : 12187ms, 파일 읽기 총량 : 13200ms

Xamarin C # : 총 시간 (5 회) : 13935ms, 파일 읽기 총계 : 14465ms

Dot42 C # : 총 시간 (5 회) : 26000ms, 파일 읽기 총량 : 27168ms

삼성 Galaxy Note 2, Android 4.1.1 (ARM)

Java : 총 시간 (5 회) : 6895ms, 파일 읽기 총량 : 7275ms

Xamarin C # : 총 시간 (5 회) : 6466ms, 파일 읽기 총량 : 6720ms

Dot42 C # : 총 시간 (5 회) : 11185ms, 파일 읽기 총량 : 11843ms

인텔 에뮬레이터, Android 4.2 (x86)

Java : 총 시간 (5 회) : 2389ms, 파일 읽기 총계 : 2770ms

Xamarin C # : 총 시간 (5 회) : 1748ms, 파일 읽기 총량 : 1933ms

Dot42 C # : 총 시간 (5 회) : 5150ms, 파일 읽기 총량 : 5459ms

저에게는 Xamarin C #이 최신 ARM 장치에서 Java보다 약간 빠르며 이전 Nexus One에서는 약간 느리다는 점도 흥미로 웠습니다. 누구나이 테스트를 실행하려면 알려 주시면 GitHub에서 소스를 업데이트하겠습니다. Intel 프로세서가 장착 된 실제 Android 장치에서 결과를 보는 것이 특히 흥미로울 것입니다.

2013 년 7 월 26 일 업데이트

최신 Xamarin.Android 4.8 및 오늘 출시 된 dot42 1.0.1.72 업데이트를 사용하여 벤치 마크 앱으로 다시 컴파일 된 빠른 업데이트만으로 이전에보고 된 결과와 큰 차이가 없습니다.

2013 년 7 월 30 일 업데이트-dot42에 대한 더 나은 결과

Java 코드의 Robert 's (dot42 제조업체에서) 포트를 사용하여 Dot42를 다시 테스트했습니다. Xamarin을 위해 처음 수행 된 C # 포트에서 ListArray와 같은 일부 고유 Java 클래스를 C # 고유의 List 클래스로 대체했습니다. Robert는 Dot42 소스 코드가 없으므로 Java에서 다시 포팅하여 원래 Java 클래스를 사용했습니다. Dot42에 도움이되는 그러한 장소는 Xamarin과 같이 Mono가 아닌 Java와 같은 Dalvik VM에서 실행되기 때문에 추측합니다. 이제 Dot42 결과가 훨씬 좋습니다. 내 테스트의 로그는 다음과 같습니다.

2013 년 7 월 30 일-Dot42 C #에서 더 많은 Java 클래스로 Dot42 테스트

인텔 에뮬레이터, 안드로이드 4.2

Dot42, StringBuilder.Replace ()를 사용한 Greg의 코드 (Xamarin에서와 같이) :
총 시간 (5 회 실행) : 3646ms, 파일 읽기 총계 : 3830ms

Dot42, String.Replace ()를 사용하는 Greg의 코드 (Java 및 Robert의 코드에서와 같이) :
총 시간 (5 회 실행) : 3027ms, 파일 읽기 총계 : 3206ms

Dot42, Robert 's Code :
총 시간 (5 회) : 1781ms, 파일 읽기 총 시간 : 1999ms

Xamarin :
총 시간 (5 회) : 1373ms , 파일 읽기 총 시간 : 1505ms

Java :
총 시간 (5 회) : 1841ms, 파일 읽기 총계 : 2044ms

ARM, Samsung Galaxy Note 2, 절전, Android 4.1.1

Dot42, StringBuilder.Replace ()를 사용하는 Greg의 코드 (Xamarin에서와 같이) :
총 시간 (5 회 실행) : 10875ms, 파일 읽기 총계 : 11280ms

Dot42, String.Replace ()를 사용하는 Greg의 코드 (Java 및 Robert의 코드에서와 같이) :
총 시간 (5 회 실행) : 9710ms, 파일 읽기 총계 : 10097ms

Dot42, Robert 's Code :
총 시간 (5 회) : 6279ms, 파일 읽기 총량 : 6622ms

Xamarin :
총 시간 (5 회) : 6201ms , 파일 읽기 총량 : 6476ms

Java :
총 시간 (5 회) : 7141ms, 파일 읽기 총량 : 7479ms

나는 아직도 Dot42가 갈 길이 멀다고 생각한다. Java와 같은 클래스 (예 : ArrayList)가 있고 성능이 좋으면 Java에서 C #으로 코드를 포팅하는 것이 약간 쉬워집니다. 그러나 이것은 내가 많이하지 않을 것입니다. 오히려 네이티브 C # 클래스 (예 : List)를 사용하는 기존 C # 코드 (라이브러리 등)를 사용하고 싶습니다. 현재 dot42 코드에서 느리게 수행되고 Xamarin에서는 매우 잘 수행됩니다.

그렉

---

예, Xamarin의 모노 가상 머신은 Android에서 사용되는 Google의 Dalvik보다 더 인상적입니다. HTC Flyer 및 Acer Iconia Tab 태블릿을 사용하여 Java Dalvik에 대해 Mono를 통해 Android의 C # 포트를 벤치마킹하고 Android를 C #으로 구현하고 실제로 Java 기반 Dalvik을 우회하는 벤치 마크로 테스트했습니다.

---

I came across this interesting post

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

이 정보가 도움이 되길 바랍니다.

---

최근에 앱에 Xamarin을 사용하여 조사했습니다. 우리는 Windows RT 버전의 앱을 위해 이미 작성한 C # 코드를 활용했습니다. Android 버전에 대한 일부 세부 정보를 다시 작성해야했습니다.

우리가 발견 한 것은 Xamarin C #의 I / O가 Java보다 약 2 배 느리다는 것입니다. 우리의 응용 프로그램은 I / O가 많이 제한됩니다. 우리는 아직 이것의 원인을 발견하지 못했지만 현재 마샬링으로 인한 것으로 가정하고 있습니다. 우리는 대부분 Mono VM 내부에 머 무르려고 노력하지만 Mono가 실제로 디스크에 액세스하는 방법을 모릅니다.

또한 C # 코드는 SQLite.NET ( https://github.com/praeclarum/sqlite-net )을 사용한다고 알려줍니다 . SQLite.NET 코드를 사용하는 동일한 반입도 Android의 Java SQLite 랩퍼를 사용하는 것보다 2 배 느립니다. 소스 코드를 살펴본 후 C .dll에 직접 바인딩되는 것처럼 보이므로 너무 느린 이유를 모르겠습니다. 한 가지 가능성은 네이티브에서 Java로 문자열을 마샬링하는 것이 C #에서 네이티브보다 Xamarin보다 안드로이드에서 더 빠를 수 있습니다.

---

이것은 내가 당신과 공유하고 싶은 또 다른 업데이트 된 블로그 게시물 입니다. 그는 Xamarin과 IO 및 Android의 네이티브 코드 및 Cordova를 비교합니다.

간단히 말해서, Xamarin은 때로는 원시 코드보다 성능이 우수합니다. 그는 앱 크기,로드 시간, Azure 서비스 및 소수 계산에서 목록로드를 테스트했습니다.

즐겨!

편집 : 죽은 링크를 업데이트하고 2 부가 있음을 알았습니다.

---

다음은 두 가지 장치에서 네이티브, Xamarin 및 Xamarin 사이의 다른 테스트에서 찾은 몇 가지 정보입니다.

Samsung Galaxy A7 : Android OS 버전 : 6.0 중앙 처리 장치 : Octa-core 1.9 GHz Cortex-A53 RAM : 3GB 디스플레이 해상도 : 1920 × 1080

iPhone 6s : iOS 버전 : 10.3.3 중앙 처리 장치 : 듀얼 코어 1.84 GHz 트위스터 RAM : 2 GB 디스플레이 해상도 : 1334 × 750

비교는 몇 가지 일반적인 기능에 대해 이루어지며 각각 고유 한 응용 프로그램이 있습니다.

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

각 테스트는 여러 번 반복되며 그래프는 평균 결과를 보여줍니다.

---

안녕하세요 월드

---

나머지 API

OpenWeatherMap API를 사용하여 앱이 REST API를 통해 요청을 보내고 추가 데이터 처리없이 응답을 다시받는 데 걸리는 시간을 측정하기위한 테스트 세트입니다.

---

JSON 작업 테스트는 모든 Xamarin 앱에서 JSON 객체를 직렬화 및 직렬화 해제하기 위해 Newtonsoft Json.net 프레임 워크를 사용하여 수행되었습니다. 기본 Android 직렬화 및 역 직렬화는 Jackson과 GSON의 두 Java 라이브러리를 사용하여 테스트되었습니다.

처음에는 처음부터 두 번, 캐시 된 정보와 작업이있는 두 번은 두 번 실행됩니다.

첫 실행 :

(Native iOS JSON Operations는이 테스트를 중단하고 Xamarin은 두 번째 테스트에 참여합니다)

---

사진 작업

먼저 세 가지 해상도로 이미지를로드하십시오.

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

이 테스트의 Xamarin.Forms 결과에 대해 확신이없는 것 같으므로 그래프에 포함되지 않았습니다.

---

SQLite 작업

테스트 된 두 가지 작업 :

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.

---

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.

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/

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

---

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.

Android nativly comes with multipe forms to execute code in:

• RenderScript (CPU and 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.

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

Xamarin and why it can be slower

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

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.

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.

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/

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.

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?

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.

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

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

---

It's pretty old tests but could be relevant: 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)

참고 URL : https://stackoverflow.com/questions/17134522/does-anyone-have-benchmarks-code-results-comparing-performance-of-android-ap