Java와 Xamarin C#로 작성된 Android 앱의 성능을 어떻게 비교합니까?어쨌든 정량 데이터(코드 및 결과)를 확인한다.
우연히 Xamarin의 Android에서의 Mono 실장 및 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
다른 장치나 에뮬레이터에 대한 테스트를 반복하고 싶은 사람이 있다면 그 결과도 알고 싶습니다.
테스트 결과
문장 추출기 클래스를 (@Voice Audio Reader 앱에서) C#으로 포팅하고 영어, 러시아어, 프랑스어, 폴란드어, 체코어로 된 10개의 HTML 파일에 대한 테스트를 수행했습니다.각 실행은 10개의 파일 모두에 대해 5회 수행되었으며, 3개의 다른 장치와 1개의 에뮬레이터에 대한 총 시간은 아래에 나와 있습니다.디버깅을 활성화하지 않고 "Release" 빌드만 테스트했습니다.
HTC Nexus One Android 2.3.7 (API 10) - Cyanogen Mod ROM
Java: 총 실행 시간(5회): 12361 ms, 파일 읽기 합계: 13304 ms
C#: 총 실행 시간(5회): 17504 ms, 파일 읽기 합계: 17956 ms
Samsung Galaxy S2 SGH-I777 (Android 4.0.4, API 15) - Cyanogen Mod ROM
Java: 총 실행 시간(5회): 8947 ms, 파일 읽기 합계: 9186 ms
C#: 총 실행 시간(5회): 9884 ms, 파일 읽기 합계: 10247 ms
삼성 GT-N7100 (Android 4.1.1 JellyBean, API 16) - 삼성 ROM
Java: 총 실행 시간(5회): 9742 ms, 파일 읽기 합계: 10111 ms
C#: 총 실행 시간(5회): 10459 ms, 파일 읽기 합계: 10696 ms
에뮬레이터 - 인텔 (Android 4.2, API 17)
Java: 총 실행 시간(5회): 2699 ms, 파일 읽기 합계: 3127 ms
C#: 총 실행 시간(5회): 2049 ms, 파일 읽기 합계: 2182 ms
에뮬레이터 - 인텔 (Android 2.3.7, API 10)
Java: 총 실행 시간(5회): 2992 ms, 파일 읽기 합계: 3591 ms
C#: 총 실행 시간(5회): 2049 ms, 파일 읽기 합계: 2257 ms
에뮬레이터 - 암(Android 4.0.4, API 15)
Java: 총 실행 시간(5회): 41751 ms, 파일 읽기 합계: 4386 ms
C#: 총 실행 시간(5회): 44136 ms, 파일 읽기 합계: 45109 ms
간단한 토론
테스트 코드에는 주로 텍스트 구문 분석, 치환 및 정규식 검색이 포함되며, 다른 코드(예를 들어 더 많은 숫자 연산)의 경우 결과가 다를 수 있습니다.ARM 프로세서를 탑재한 모든 디바이스에서 Java는 Xamarin C# 코드보다 뛰어난 성능을 보였습니다.가장 큰 차이는 Android 2.3에서 C# 코드가 Java 속도의 약 70%로 실행됩니다.
인텔의 에뮬레이터(인텔 HAX 테크놀로지에서는 에뮬레이터가 고속 버트 모드로 동작)에서는, Xamarin C#코드가 Java보다 훨씬 고속으로 샘플 코드를 실행합니다(약 1.35배 고속).모노 가상 머신의 코드와 라이브러리가 ARM보다 인텔에서 훨씬 최적화되어 있는 것은 아닐까요?
2013년 7월 8일 편집
Oracle Virtual Box에서 실행되는 Genymotion Android 에뮬레이터를 방금 설치했는데, 이것도 ARM 프로세서가 아니라 네이티브 Intel 프로세서를 사용합니다.인텔 HAX 에뮬레이터와 마찬가지로 C#의 동작은 고속입니다.결과는 다음과 같습니다.
Genymotion 에뮬레이터 - Intel (Android 4.1.1, API 16)
Java: 총 실행 시간(5회): 2069 ms, 파일 읽기 합계: 2248 ms
C#: 총 실행 시간(5회): 1543 ms, 파일 읽기 합계: 1642 ms
그때 Xamarin에 대한 업데이트가 있음을 알게 되었습니다.Android 베타 버전 4.7.11. 릴리즈 노트에는 Mono 런타임의 일부 변경 사항도 기재되어 있습니다.몇 가지 ARM 디바이스를 신속하게 테스트하기로 결정했지만 놀라운 결과 C# 수치가 개선되었습니다.
BN Nook XD+, ARM(Android 4.0)
Java: 총 실행 시간(5회): 8103 ms, 파일 읽기 합계: 8569 ms
C#: 총 실행 시간(5회): 7951 ms, 파일 읽기 합계: 8161 ms
와! C#이 자바보다 낫다고?Galaxy Note 2에서 테스트를 반복하기로 결정했습니다.
삼성 갤럭시 노트 2 - ARM (Android 4.1.1)
Java: 총 실행 시간(5회): 9675ms, 파일 읽기 합계: 10028ms
C#: 총 실행 시간(5회): 9911 ms, 파일 읽기 합계: 10104 ms
여기에서는 C#이 약간 느린 것처럼 보이지만, 이 수치로 인해 저는 잠시 멈춥니다.노트 2가 더 빠른 프로세서를 탑재하고 있는데, 왜 Nook HD+보다 시간이 더 오래 걸리는가?정답은 절전 모드입니다.Nook에서는 비활성화되어 있고, Note 2에서는 활성화되어 있습니다.전력 절약 모드를 무효로 해 테스트하기로 결정했다(유효하게 하면 CPU 속도도 제한됩니다).
Samsung Galaxy Note 2 - ARM(Android 4.1.1), 절전 비활성화
Java: 총 실행 시간(5회): 7153 ms, 파일 읽기 합계: 7459 ms
C#: 총 실행 시간(5회): 6906 ms, 파일 읽기 합계: 7070 ms
놀랍게도 C#은 ARM 프로세서의 Java보다 약간 더 빠릅니다.대폭 향상!
2013년 7월 12일 편집
네이티브 코드보다 빠른 것은 없다는 것을 우리는 모두 알고 있습니다.또, 자바나 C#에서의 문장 분할기의 퍼포먼스에 만족하지 않았습니다.특히, 그것을 개선할 필요가 있습니다(그 때문에, 한층 더 속도가 느려집니다).C++로 다시 쓰기로 했다.다음은 네이티브와 네이티브의 속도를 비교한 것입니다(기타 이유로 이전 테스트보다 작은 파일 세트).Galaxy Note 2의 Java(전력 절약 모드 비활성화):
Java: 총 실행 시간(5회): 3292 ms, 파일 읽기 합계: 3454 ms
네이티브 엄지: 총 실행시간(5회): 537밀리초, 파일 읽기 합계: 657밀리초
네이티브 암: 총 실행 시간(5회): 458 ms, 파일 읽기 합계: 587 ms
특정 테스트에서는 네이티브 코드가 Java보다 6~7배 빠른 것 같습니다.경고: Android에서는 std::regex 클래스를 사용할 수 없었기 때문에 문단 구분이나 HTML 태그를 검색하는 나만의 특별한 루틴을 작성해야 했습니다.regex를 사용하여 PC에서 동일한 코드를 처음 테스트했을 때 Java보다 약 4~5배 빨랐습니다.
휴! char* 또는 wchar* 포인터로 raw memory를 깨우니까 20년은 더 젊어진 것 같아! :)
2013년 7월 15일 편집
(Dot42로 훨씬 더 나은 결과를 얻으려면 2013년 7월 30일에 편집한 내용을 아래를 참조하십시오.)
간신히 C# 테스트를 Android용 또 다른 C# 플랫폼인 Dot42(버전 1.0.1.71 베타)에 포팅할 수 있었습니다.초기 결과에 따르면 Dot42 코드는 Intel Android 에뮬레이터의 Xamarin C# (v.4.7.11)보다 약 3배 느립니다.한 가지 문제는 그 시스템입니다.Dot42의 Text.RegularExpressions 클래스에는 Xamarin 테스트에서 사용한 Split() 함수가 없기 때문에 Java를 사용했습니다.Util.Regex 클래스 대신 Java.Util. Regex.양식.Split()는 코드의 이 특정 위치에 작은 차이가 있습니다.큰 문제는 아닐 겁니다Dot42는 Dalvik(DEX) 코드에 컴파일되므로 안드로이드 상에서 Java와 네이티브하게 연동되므로 Xamarin과 같이 C#에서 Java까지 고가의 인터op이 필요하지 않습니다.
비교를 위해 ARM 디바이스에서도 테스트를 실행합니다.여기서는 Dot42 코드가 Xamarin C#보다 2배 느립니다.결과는 다음과 같습니다.
HTC Nexus One Android 2.3.7 (ARM)
Java: 총 실행 시간(5회): 12187 ms, 파일 읽기 합계: 13200 ms
Xamarin C#: 총 실행 시간(5회): 13935 밀리초, 파일 읽기 합계: 14465 밀리초
Dot42 C#: 총 실행시간(5회): 26000밀리초, 파일 읽기 합계: 27168밀리초
삼성 갤럭시 노트 2, Android 4.1.1 (ARM)
Java: 총 실행 시간(5회): 6895 ms, 파일 읽기 합계: 7275 ms
Xamarin C#: 총 실행 시간(5회) : 6466 ms, 파일 읽기 합계: 6720 ms
Dot42 C#: 총 실행시간(5회): 11185 ms, 파일 읽기 합계: 11843 ms
인텔 에뮬레이터, Android 4.2 (x86)
Java: 총 실행 시간(5회): 2389 ms, 파일 읽기 합계: 2770 ms
Xamarin C#: 총 실행 시간(5회): 1748 ms, 파일 읽기 합계: 1933 ms
Dot42 C#: 총 실행시간(5회): 5150밀리초, 파일 읽기 합계: 5459밀리초
새로운 ARM 디바이스에서는 Xamarin C#이 Java보다 약간 빠르고 오래된 Nexus One에서는 약간 느리다는 점도 흥미로웠습니다.만약 이 테스트도 실행하고 싶은 사람이 있으면 알려주세요.GitHub의 소스를 업데이트 하겠습니다.인텔 프로세서를 탑재한 실제 Android 디바이스의 결과를 보는 것은 특히 흥미로울 것입니다.
2013년 7월 26일 갱신
최신 Xamarin으로 벤치마크 앱으로 재컴파일된 간단한 업데이트입니다.Android 4.8 및 dot42 1.0.1.72 업데이트도 오늘 출시되었으며 이전에 보고된 결과와 큰 변화는 없습니다.
2013년 7월 30일 업데이트 - dot42에 대한 더 나은 결과
Java 코드의 Robert 포트(dot42 메이커)에서 Dot42를 C#으로 재테스트.처음에 Xamarin용으로 실행된 C# 포트에서 ListArray와 같은 일부 네이티브 Java 클래스를 C# 네이티브 클래스로 대체했습니다.Robert는 내 Dot42 소스 코드를 가지고 있지 않기 때문에 Java에서 다시 포팅하여 원래 Java 클래스를 사용하였습니다.Dot42는 Java와 같은 Dalvik VM에서 실행되며 Xamarin과 같은 Mono에서 실행되지 않기 때문에 이점을 얻을 수 있습니다.이제 Dot42의 결과가 훨씬 좋아졌습니다.다음은 테스트 로그입니다.
2013년 7월 30일 - Dot42 C#의 Java 클래스가 많은 Dot42 테스트
인텔 에뮬레이터, Android 4.2
Dot42, StringBuilder는 Dot42, StringBuilder는 StringBuilder입니다.(Xamarin) :
실행ms, : ms (5회 실행): 3646밀리초, 3830밀리초Dot42, 트 dot dot dot dot dot dot dot dot dot dot 。Replace() (Java "Robert " " ) :
실행): 합계:(5회 실행): 3027밀리초, 3206밀리초Dot42, Robert's 드드 :
실행 ms, 1999 ms （ 5회 실행): 1,781 ms, 1999 ms★★★★★★★★★★★★★★★★★★:
실행ms, 합계: ms (5회 실행): 1373 ms, 1505 ms바바:
실행ms, msARM, 삼성 갤럭시 노트 2, 절전, Android 4.1.1
Dot42, StringBuilder는 Dot42, StringBuilder는 StringBuilder입니다.(Xamarin) :
실행 합계:(5회 실행): 10875밀리초, 11280밀리초Dot42, 트 dot dot dot dot dot dot dot dot dot dot 。Replace() (Java "Robert " " ) :
실행): ms, 합계: ms (5회 실행): 9710 ms, 10097 msDot42, Robert's 드드 :
실행): 합계:(5회 실행): 6279밀리초, 6622밀리초★★★★★★★★★★★★★★★★★★:
실행): : 6476밀리초(5회 실행): 6201밀리초, 6476밀리초바바:
실행 합계:(5회 실행): 7141밀리초, 7479밀리초
저는 아직도 닷42가 갈 길이 멀다고 생각합니다.Java와 같은 클래스(예를 들어 ArrayList)가 있고, 이러한 클래스(예: ArrayList)가 있으면 Java에서 C#으로 코드를 이식하는 것이 약간 쉬워집니다.하지만 이것은 내가 많이 할 것 같지 않은 일이다.기존 C# 코드(라이브러리 등)를 사용하고 싶습니다.이 코드는 네이티브 C# 클래스(List 등)를 사용하고, 현재의 dot42 코드에서는 동작이 느리고, Xamarin에서는 매우 양호합니다.
그렉
네, Xamarin의 Mono 가상 머신은 Android에서 사용되는 Google의 Dalvik보다 더 인상적입니다.HTC Flyer와 Acer Iconia Tab 태블릿으로 테스트하여 모노를 통해 Android의 C# 포트를 Java Dalvik에 대해 벤치마킹하고, Android의 C# 구현이 잘 되어 있고, Java 기반의 Dalvik을 완전히 파괴하고 있습니다.
I came across this interesting post
https://medium.com/@harrychung/mobile-app-performance-harryx-e4be94f976#.kfbauchtz
이 정보가 도움이 되길 바랍니다.
우리는 최근 앱에 Xamarin을 사용하는 것에 대해 조사했습니다.Windows RT 버전에서는 이미 작성한 C# 코드를 사용하고 있습니다.Android 버전을 위해 몇 가지 세부 사항을 다시 작성해야 했습니다.
Xamarin C#의 I/O는 Java보다 약 2배 느립니다.우리 앱은 I/O가 너무 많아요.그 원인은 아직 밝혀지지 않았지만, 현시점에서는 집결 때문이라고 추측하고 있습니다.대부분의 경우 모노 VM 내에 머무르려고 하지만 실제로 모노가 어떻게 디스크에 액세스하는지 알 수 없습니다.
또한 C# 코드가 SQLite를 사용하고 있음을 나타냅니다.NET ( https://github.com/praeclarum/sqlite-net) )SQLite를 사용한 동일한 가져오기.NET 코드는 또한 Android의 Java SQLite 래퍼를 사용하는 것보다 2배 느립니다.소스 코드를 보면 C.dll에 직접 바인드 되어 있는 것 같은데 왜 이렇게 느린지 모르겠어요.한 가지 가능성은 네이티브에서 Java로 이행하는 문자열이 C# 네이티브에서 Xamarin으로 이행하는 것보다 Android에서 더 빠를 수 있다는 것입니다.
또 다른 최신 블로그 투고입니다.그는 Xamarin을 IO와 Android 모두에서 네이티브 코드와 Cordova와 비교합니다.
한마디로 Xamarin은 네이티브 코드보다 뛰어난 성능을 발휘합니다.그는 앱 크기, 로드 시간, Azure 서비스에서 목록 로드 및 소수 계산을 테스트했습니다.
맛있게 드세요!
편집: 데드 링크를 업데이트했는데 파트 2가 있습니다.
다음은 네이티브인 Xamarin과 Xamarin 사이의 또 다른 테스트에서 발견한 몇 가지 정보입니다.다음 2개의 디바이스에서 솔루션 폼(테스트에는 iOS 퍼포먼스도 포함됩니다)
삼성 갤럭시 A7: Android OS 버전 6.0 중앙 처리 장치:Octa-core 1.9GHz Cortex-A53 RAM: 3GB 디스플레이 해상도: 1920×1080
iPhone 6s: iOS 버전: 10.3.3 중앙 처리 장치:듀얼코어 1.84GHz Twister RAM: 2GB 디스플레이 해상도: 1334×750
몇 가지 공통 기능을 비교합니다.각 기능에는 독자적인 애플리케이션이 있습니다.
- Basic “Hello World”
- REST API
- JSON Serialization/Deserialization
- Photo Loading
- SQL Database Insert and Get All
각 테스트는 여러 번 반복되며 그래프는 평균 결과를 보여 줍니다.
안녕 세계
Rest API
OpenWeatherMap API를 사용하여 REST API를 통해 요청을 보내고 데이터 처리 없이 응답을 받는 데 걸리는 시간을 측정하는 테스트 세트입니다.
JSON Operations Tests는 Newtonsoft Json.net 프레임워크를 사용하여 모든 Xamarin 앱에서 JSON 개체를 직렬화 및 직렬화 해제했습니다.네이티브 Android 시리얼화 및 디시리얼화 테스트는 Jackson과 GSON의 두 가지 Java 라이브러리를 사용하여 실시되었습니다.
첫 번째 실행과 캐시된 정보 및 운영이 포함된 두 번째 실행이 있습니다.
첫 번째 실행:
(네이티브 iOS JSON Operations는 이 테스트를 중단하고 있으며, Xamarin은 두 번째 테스트에 참여합니다.)
사진 조작
3가지 해상도의 이미지에 첫 번째 로드:
Resolution – 858×569, Size – 868Kb
Resolution – 2575×1709, Size – 8Mb
Resolution – 4291×2848, Size – 28.9Mb
자마린호에 대해 뭔가 확신이 없는 것 같았다.이 테스트의 결과를 형성하므로 그래프에 포함되지 않습니다.
SQLite 운영
테스트된 두 가지 동작:
BulkInsert: Loading rows of data into a database table.
GetAll: Retrieving all data from the database.
10,000개의 기록을 가진 데이터베이스로요모든 작업은 디바이스에서 내부적으로 처리되었습니다.
자마린 네이티브(자마린.i)OS/XAMARINAndroid)는 네이티브 코드에 대한 훌륭한 대체 수단인 반면 Xamarin은 그 자체입니다.많은 경우 폼이 느리지만 매우 간단한 애플리케이션을 빠르게 개발할 수 있는 매우 좋은 솔루션이 될 수 있습니다.
완전한 테스트는 다음 소스로부터 얻을 수 있습니다.
설명을 해주셔서 감사합니다.이것이 조금 도움이 되었으면 합니다:)
성능
퍼포먼스의 의미를 정의하지 않으면 퍼포먼스는 애매한 단어입니다.단순한 계산 퍼포먼스라면 계산의 성질에 따라서는 Java보다 Xamarin이 더 빠를 수 있습니다.
Android는 기본적으로 코드를 실행할 수 있는 멀티페 양식을 제공합니다.
- RenderScript (CPU 및 GPU)
- 자바(SDK)
- C++(NDK)
- OpenGL(GPU)
코드를 실행할 때 솔루션이 네이티브할수록 더 빨라지는 것은 분명합니다.런타임 기반 언어는 CPU에서 직접 실행되는 언어를 능가하지 않습니다.
한편 실제 사용 퍼포먼스를 측정하려면 Java가 Propbaby가 Xamarin보다 빠릅니다.
자마린과 왜 속도가 느려질 수 있는지
Xamarin을 일반 Java 애플리케이션과 비교하면 속도가 느릴 수 있으므로 Xamarin의 성능이 훨씬 더 빠를 수 있습니다.
실제 예에서 Xamarin 어플리케이션은 Java 어플리케이션보다 속도가 느릴 가능성이 높습니다.이는 많은 Android/Java(시스템) 콜이 소위 바인딩을 사용하여 Xamarin 런타임에 위임되어야 하기 때문입니다.
알아야 할 바인딩에는 몇 가지 유형이 있습니다.
- JNI(Java 네이티브 인터페이스):Java 코드(SDK)와 네이티브 C++ 코드(NDK) 사이의 인터페이스를 위해 많은 Android 애플리케이션에서 사용되는 바인딩입니다.
- MCW(Managed Callable Wrapper) :Xamarin에서 관리 대상 C# 코드에서 Java 코드로의 인터페이스(Android 런타임)에 사용할 수 있는 바인딩.
- ACW(안드로이드 콜 가능 래퍼):Java 코드(Android 런타임)에서 관리 대상 C# 코드로 인터페이스하기 위해 Xamarin에서 사용할 수 있는 바인딩입니다.
MCW 및 ACW에 대한 자세한 내용은http://https://developer.xamarin.com/guides/cross-platform/application_fundamentals/building_cross_platform_applications/part_1_-_understanding_the_xamarin_mobile_platform/ 를 참조해 주세요.
바인딩은 성능 면에서 매우 비용이 많이 듭니다.Java에서 C++ 메서드를 호출하면 호출 시간에 큰 오버헤드가 발생하며 C++ 내에서 C++ 메서드를 호출하는 것이 몇 배 빨라집니다.
JNI 콜비용의 평균 Java 운용수를 계산하기 위해 퍼포먼스 테스트를 실시했습니다.JNI 콜을 발신할 때의 정량적 오버헤드는 얼마입니까?
단, JNI 콜은 비용이 많이 들 뿐만 아니라 MCW 및 ACW와의 콜도 비용이 많이 듭니다.실제 Xamarin 어플리케이션은 바인딩을 사용하여 많은 콜을 발신합니다.이 때문에 Xamarin 어플리케이션의 실제 사용 속도는 일반 구 Java 어플리케이션보다 느릴 수 있습니다(일반적으로 느릴 수 있습니다).다만, Xamarin 애플리케이션의 설계에 따라서는, 유저는 그 차이를 깨닫지 못할 가능성이 매우 높습니다.
TLDR/결론: Xamarin은 여러 종류의 바인딩을 사용해야 하며, 시간이 많이 소요됩니다.
바인딩 외에도 실제 성능에 대해 이야기할 때 바이너리 크기, 메모리 내 앱 로드, I/O 작업 등 많은 요소가 포함됩니다.이 중 몇 가지를 조사하는 블로그 투고는, https://magenic.com/thinking/mobile-development-platform-performance-part-2-native-cordova-classic-xamarin-xamarin-forms 를 참조해 주세요.
꽤 오래된 테스트이지만 관련이 있을 수 있습니다.https://github.com/EgorBo/Xamarin.Android-vs-Java
산술 시험
컬렉션, 제네릭, 커스텀 값 유형
문자열 사용
UPD: Google Pixel 2의 새로운 데이터 (고맙습니다)
언급URL : https://stackoverflow.com/questions/17134522/how-to-compare-the-performance-of-android-apps-written-in-java-and-xamarin-c-a
'programing' 카테고리의 다른 글
| 대신 wget을 통해 Linux에서 Java JDK를 다운로드하면 라이센스 페이지가 표시됩니다. (0) | 2022.07.16 |
|---|---|
| NuxtJs에서 Facebook 픽셀을 Import하는 방법 (0) | 2022.07.16 |
| 페이지에서 vue 라우터 숨기기 (0) | 2022.07.16 |
| 많은 채널 x86 시스템의 메모리 대역폭 (0) | 2022.07.16 |
| 막연한 서비스 노동자 Nuxt JS의 속성 'register'을 읽을 수 없습니다. (0) | 2022.07.15 |