Android 또는 Java는 가상 머신에서 실행되므로 더 많은 전력을 사용합니까?


14

Android 애플리케이션은 기본적으로 가상 프로세서 인 JVM (Dalvik VM)에서 실행되며 모든 가상 명령어는 기본 칩셋의 기본 명령어에 매핑되어야하므로이 매핑으로 인해이 매핑의 오버 헤드로 인해 더 많은 전력을 소비합니까?

이 질문은 Java로 확장 될 수 있으며 "Java 응용 프로그램이 더 많은 전력을 사용합니까?"로 표현 될 수 있습니다. 이것이 안드로이드 전화가 다른 플랫폼 / 전화와 비교하여 무서운 배터리 수명을 갖는 이유입니까?

편집 : 대답을 바탕으로 JVM과 Dalvik에 대해 잘못 이야기했기 때문에 몇 가지 사항을 분명히했습니다. 이 비트에서는 Java에 대해 더 많은 전력을 사용하는지 묻고 예인 경우 개념적으로 Android에도 적용되며 배터리 수명이 줄어 듭니다.

문맥 : Wikipedia에서 인용하는 :

  1. Java 바이트 코드는 C 코드의 어셈블리 언어와 유사합니다.
  2. 컴파일러의 관점에서 볼 때 Java 가상 머신은 코드를 생성 할 수있는 명령어 세트 인 Java 바이트 코드를 가진 또 다른 프로세서 일뿐입니다.
  3. JVM에는 스택 아키텍처가 있습니다. Dalvik은 JVM과 동일한 유형의 가상화가 아니며 프로세스 아키텍처를 갖는 프로세스 가상 머신입니다.

Java 프로그래밍 언어는 바이트 코드 (조립식)로 컴파일되고 가상 프로세서에서 실행되므로 진정한 소프트웨어 코드 이식성을 제공합니다. 또한 Linux 용 JVM이 있고 Linux가 개방형 하드웨어로 이식되었으므로이 조합은 전체 스택에서 진정한 애플리케이션 이식성을 제공 할 수 있습니다.

전원 : 문제는 본질적으로 소프트웨어 코드 또는 응용 프로그램의 동일한 기능 집합에 대해 런타임 환경에 따른 CPU 클록 사이클의 백분율을 결정합니다. 이것은 최신 JVM의 JIT (Just-In-Time) 컴파일 환경에서 바이트 코드가 기본 칩셋의 기본 명령어로 컴파일 된 경우 런타임은 jit 컴파일 중에 만 활성화되어야합니다. 따라서 런타임 환경에서 CPU 소비 사이클이 얼마나 많이 소비되어 전력 소비 오버 헤드가 발생할 것으로 예상됩니다. 나는 전력 소비 측면에만 관심이 있으며 정적으로 유형이 지정되고 작성된 언어와 비교하여 상대적인 성능이 아니라 Java의 장점을 이해합니다. 관련 될 수있는 하위 질문 :

  • Java 런타임은 기능에 libc를 사용합니까?
  • 이러한 전력 소비 관련 포인트가 Dalvik VM 및 Android로 해석됩니까?
  • 화면 및 무선 칩셋에 대해 이야기하지 않고 Android의 배터리 소모를 일반화하는 대신 iPhone 5에 1440mAH 배터리가 장착되어 최신 Nexus 휴대 전화와 비교하여 작은 크기에 대해 이야기 할 수 있습니다. iphone-loyalist 친구가 이것이 나의 (멋진) 넥서스보다 그의 배터리 수명이 더 좋은 이유 일 수 있다고 주장했기 때문에이 전체 사고 (Java, Virtual processor, instruction mapping, Android)가 일어났습니다.

어쨌든 아래 답변에 감사드립니다.


1
배터리를 mAh로 비교하지 마십시오. 그것은 현재입니다. 이론적으로 10000000 mAh 배터리보다 더 큰 전력 (와트시)을 가진 2 mAh 배터리를 사용할 수 있습니다. 전압에 따라 다릅니다. Nexus 4에는 8Wh 배터리가 있고 iPhone 5에는 5.45Wh 배터리가 있습니다. 차이는 화면 크기 때문에 크게 달라집니다. Nexus 4는 4.7 인치 (대각선) 디스플레이를 사용하는 반면, iPhone 5는 4 인치이며 해상도는 더 높고 밝기는 높습니다 (608 cd / m ^ 2 vs. 500). 넥서스 4는 1.5GHz @ 쿼드 코어, 아이폰 5는 1.3GHz @ 듀얼 코어, 더 빠른 = 더 많은 배터리 사용
allquixotic

1
전체 플랫폼이 더 작은 물리적 공간, 더 작은 화면, 더 작은 CPU, 더 적은 코어, 더 적은 기능, 더 적은 성능, 더 적은, 더 적은, 더 작게 설계 되었기 때문에 기본적으로 iPhone은 더 작은 배터리로 더 오래 지속됩니다. 안드로이드 폰은 더 큰 코어, 더 많은 파워, 더 빠른 속도와 반대 방향으로 추세를 보이고 있습니다. 물론 동일한 배터리 수명을 얻으려면 훨씬 더 큰 배터리가 필요합니다. 때로는 큰 배터리조차도 소비를 제대로 보상하지 못하며,이 경우 배터리 수명이 나쁜 전화가 있습니다.
allquixotic

답변:


25

귀하의 질문은 많은 잘못된 가정을 기반으로 합니다. 정리해 보도록하겠습니다.

  • "JVM (Dalvik VM)"이라고 말하셨습니다. "비행기 (자전거)"라고 말하는 것과 같습니다. 이 두 가지는 서로 전혀 관련이 없습니다.

  • "... 기본적으로 가상 프로세서"라고 말했습니다. 간단히 거짓. 그것은 것입니다 하지 가 본질적으로 동등한 것으로, 단어 "가상 머신"글자 "VM은"기술적 인 맥락에서 사용할 때마다, 경우 VM웨어 워크 스테이션 . VMware와 같은 제품 은 실제로 CPU뿐만 아니라 전체 컴퓨터를 에뮬레이션하고 다른 운영 체제 위에서 운영 체제를 실행하기 때문입니다. Dalvik VM은 그런 식으로 작동 하지 않습니다 . 근처에도 안.

  • Java는 프로그래밍 언어 일뿐입니다. 구문입니다. Android / Dalvik 프로그램은 Java Virtual Machine에서 실행되는 Java라는 완전히 관련이없는 데스크탑 / 서버 프로그래밍 언어와 동일하거나 매우 유사한 구문을 사용합니다. 이론적으로 C 코드와 거의 동일한 속도의 Java 코드를 작성할 수 있습니다. 둘 다 고급 프로그래밍 언어이기 때문입니다. 악마는 라이브러리 호출의 구현과 런타임의 설계 방식에 대한 세부 사항에서 언어의 구문과 거의 관련이 없습니다.

  • Dalvik VM, Sun Java Hotspot JVM 또는 Java 프로그래밍 언어 구문이 높은 전력 소비를 담당한다는 것은 너무 일반적인 일입니다. 그 이유는 당신이 말하는 것을 다른 것의 성능과 비교해야하기 때문입니다 . 가장 일반적인 경우 두 플랫폼의 "최상의"기능을 비교할 때 원칙적으로 다른 플랫폼의 프로그램보다 빠르거나 빠른 Dalvik 앱을 만들 수 있습니다. iOS 및 JavaScript / HTML5를 포함하여 오늘날 거의 모든 프로그래밍 환경에서 표준으로 제공되는 자동 메모리 관리 및 JIT 컴파일 외에 Dalvik과 Objective-C, .NET, Ruby와는 별 차이가 거의 없습니다. Oracle Hotspot JVM, Python 등

  • "Java가 느리다"는 인식은 JIT (Just-In-Time Compiler)가 없거나 JIT의 기능이 매우 제한되어 있다는 점에서 이전 버전의 Java 문제로 인한 것입니다. JVM에는 JIT (Just-In Time) 컴파일러가 있습니다.아주 오랫동안 JIT 컴파일러는 프로세서 독립적 바이트 코드 (예 : Java 바이트 코드)를 가져와 CPU의 기본 명령어로 컴파일하는 런타임 (예 : JVM)의 일부입니다. 이 프로세스는 Java 프로그램이 시작될 때 수행되며 고급 JIT 컴파일러는 런타임시 개별 함수 또는 명령어를 최적화하여 관찰 된 결과에 따라 성능을 향상시킬 수 있습니다. 예를 들어, 매번 메소드가 호출 될 때마다 true를 리턴하지만 원래 바이트 코드에서 그렇게하는 것이 확실하지 않은 경우, JIT 컴파일러는 단지 true를 리턴 함을 인식하고 함수 호출을 하드로 대체합니다. "true"의 코딩 된 값. 이것은 하나의 예일뿐입니다.

  • JIT 컴파일 및 런타임 동적 코드 분석 기술은 최근 몇 년 동안 크게 발전했습니다. 컴퓨터 과학 커뮤니티의 많은 사람들은 또 다른 10 년 또는 2 년 안에 Java, C # 및 Ruby와 같이 동적으로 해석 / 컴파일 된 언어로 제공되는 정교한 분석이 매우 발전하여 대부분의 경우 이러한 언어가 더 빠르게 실행될 것이라고 믿고 있습니다 . C 및 C ++와 같이 정적으로 컴파일 된 언어보다 런타임 정적 컴파일러는 일반적으로 빌드 타임에 코드를 컴파일하는 것으로 제한되며 코드는 런타임에 수정되지 않기 때문입니다. 그러나 런타임 환경에서 프로그램의 코드를 다시 쓸 수있는 자체보다 효율적인 수행을 위해 실행하는 동안, 코드의 성능을 분석하고 코드의 복잡성 또는 CPU에서 실행되는 명령의 수를 줄 이도록 조정하여 달성 할 수있는 엄청난 양의 업사이드가 있습니다. 자주 호출되는 코드의 경우 분석을 수행하는 데 필요한 시간 투자는 더 빠른 코드를 반복해서 호출하는 성능 이점보다 훨씬 중요합니다.

  • Android Dalvik VM에는 JIT도 포함되어 있으며 Sun / Oracle JVM과 동일한 바이트 코드 형식을 사용하지 않습니다. Dalvik의 JIT는 메모리 부족 환경에 최적화되어 있으며 런타임 성능 향상에 따라 매우 향상되었습니다. 따라서 JVM과 Dalvik 은 각각의 Java 기반 런타임 환경에 대해 유사한 최적화를 구현 하지만 다소 우연의 일치입니다 .

  • Dalvik 자체도 잊지 마십시오. 리눅스 커널; 저수준 시스템 프로세스; Android 웹 브라우저 (Firefox 및 Chrome)의 핵심은 네이티브 C / C ++로 작성되었으므로 Dalvik 프로그램의 오버 헤드 문제는 없습니다. 이것은 iOS와 동일합니다. 순수한 안드로이드 에 대해 이야기 하고 있지만 그 위에있는 이동 통신사 / 타사 팽창이 아니라면 핵심 안드로이드를 구성하는 것의 대부분이 Dalvik을 사용하여 작성 되지 않습니다 .

  • Android의 애플리케이션 개발자는 선택에 따라 Dalvik을 우회하여 기본 코드를 작성할 수 있습니다. 애플리케이션 개발자가 Dalvik이 코드 성능에 병목 현상을 일으키거나 너무 많은 배터리를 소모한다고 생각하는 경우 Google의 승인을받지 않고도 C / C ++ 또는 어셈블리 코드를 작성하여 원하는 경우 그렇게하고 앱을 그렇게 배포합니다.

다음은 Android 배터리 구동 장치 또는 모든 장치에 배터리 수명에 문제가있을 수있는 몇 가지 실제 이유입니다 .

  • CPU, 화면 또는 데이터 연결을 깨우는 응용 프로그램. 특히 LTE와 같은 4G 칩셋은 전원을 켤 때 많은 양의 에너지를 사용하므로, LTE 칩을 계속 깨워 몇 킬로바이트의 데이터를 전송하는 백그라운드 프로그램이있는 경우 배터리가 매우 빨리 소모됩니다. 최신 스마트 폰과 태블릿의 화면은 밝기를 최소로 낮추지 않는 한 에너지 집약적입니다.

  • "Bloatware"는 장치에 있어야하며 제거 할 수 없습니다. 일부 파렴치한 통신 사업자는 CPU 사이클을 차지하고 데이터 연결을 깨우는 블로 트웨어를 실행해야합니다. 이것은 bloatware의 소프트웨어 개발자가 무능력하거나 스마트 폰에서 활동을 모니터링하고 원격으로 서버를 전송하여 데이터 마이닝을 위해 배터리에 에너지를 많이 소비하기 때문일 수 있습니다.

마지막으로, Android가 다른 모바일 플랫폼보다 배터리 수명 문제가 더 심하다는 평가에 동의하지 않습니다. 특정 전화 및 장치는 실제로 하드웨어의 에너지 소비와 관련된 배터리 용량으로 인해 배터리 수명 문제가있을 수 있습니다. 잘못 최적화 된 전원 설정 (사용자, 이동 통신사 또는 제조업체에서 선출) 또는 전화의 칩을 항상 깨우는 블로 트웨어 앱. 그러나 배터리 문제가있는 장치의 모든 예에 대해 배터리 수명이 뛰어난 장치의 반례를들 수 있습니다. "Dalvik"또는 "It 's Linux"또는 "It 's Java"를 일반화하는 간단한 방법은 없습니다. 전력 최적화는 성능, 응답 성, 배터리 수명에 대한 사용자의 기대, 각 선택에 대한 장단점. 장치의 전원 프로파일을 완전히 이해하려면 배터리 자체, 모든 하드웨어 및 장치에서 실행중인 모든 소프트웨어를 면밀히 검토해야합니다.


1
+1 약간 tl; dr이지만 기술적으로도 훌륭한 답변이 있습니다.
Doktoro Reichard

고마워요, 모든 공정한 포인트. 내가 모르는 것을 묻고 있었기 때문에 일부 용어를 서로 바꿔서 잘못 사용했습니다. 여전히 관심이 있다면 질문 자체를 약간 수정했습니다.
PKM

이 답변은 매우 유익하지만 질문과는 거리가 멀었습니다. 문제의 핵심은 VM 오버 헤드가 더 많은 CPU 시간을 사용하고 사용하는 최적화에 의해 절약되는 것입니다. 그것은 질문이 orher 쪽에도 힌트가 있었지만 안드로이드가 iO보다 나은 이유가 더 많습니다.
Igor Čordaš 2016 년

여기에도 잘못된 가정이 있습니다. iOS에는 Mac OS의 자동 메모리 관리 기능이 없습니다. 그리고 실제로 Dalvik을 모든 전형적인 문제와 함께 "자바"로 만드는 것은 관리입니다. : 몇 달 전이 가비지 컬렉션 (GC) 달빅는 데 문제에 꽤 좋은 개요이었다 anandtech.com/show/8231/...는 그들도 배터리 수명에 영향을 미치는 경우 아니면 그냥 성능 나는 말할 수 없다 -.
pvblivs

@pvblivs iOS 용 "고급"애플리케이션 코드를 작성하는 것은 GC 대신 자동 참조 카운팅을 사용하는 반면 Dalvik은 GC를 사용하고 "그러므로" 즉, 그것은 아이폰 OS가 안드로이드보다 ... 당신은 안드로이드 애플 리케이션을하지 않는 종류의 내 포인트를 누락 아직도 "효율적"인) 적어도 그럴듯에서의 자바로 작성하고, 실제로 어셈블러로 작성하거나 할 수 있습니다 원한다면 기본 ARM 코드까지! 성능에 매우 민감한 앱과 내장 제품 GC없이 기본 코드를 사용해야 합니다.
allquixotic

5

이 답변에서는 두 사람이 시장 점유율의 80 % 이상을 차지하므로 성능을 Android 및 IOS와 비교할 것입니다.

Java 앱은 더 많은 전력을 사용하지 않습니다. ( http://www.javarants.com/2004/05/04/looks-like-apple-should-switch/ ) 오라클의 자바 VM 또는이 실제로 구글의 달빅 VM 훨씬 더 effient IOS의 오브젝티브 C에 비해 간주됩니다. Java는 휴대 전화에서 코드를 실행하기 전에 코드를 최적화 할 수있어 성능이 훨씬 향상 될 수 있습니다. Java 라이브러리는 오픈 소스이므로 수백 명의 개발자가 최적화했습니다. 반면에 IOS에서는 Apple 개발자 만 코드를 변경할 수 있습니다. 검토가 적을수록 성능이 저하 될 수 있습니다.

안드로이드 프로그램은 Object-C (IOS에서 유일하게 지원되는 언어)보다 더 빠르게 논쟁의 여지가있는 네이티브 C 코드를 실행할 수 있습니다.

Google이 Dalvik VM을 사용하기로 결정한 이유는 이식성 때문입니다. Android가 공식적으로 실행할 수있는 4 가지 CPU 아키텍처 (ARM, MIPS, x86, I.MX)를 알고 있습니다. 다른 모든 전화 OS는 하나만 사용할 수 있지만 (ARM). ( http://en.wikipedia.org/wiki/Comparison_of_mobile_operating_systems ) 따라서 다른 CPU 유형을 예를 들어 IPhone과 비교하는 것은 불공평합니다. 안드로이드가 아이폰에서 실행 되었다면, 안드로이드는 뛰어난 성능과 배터리 수명에 필적 할 것입니다.

"자바 애플리케이션은 더 많은 전력을 사용합니까?" 간단하게
Android 휴대 전화가 다른 플랫폼 / 휴대 전화와 비교했을 때 배터리 수명이 긴 이유는 무엇입니까? 많은 안드로이드 폰은 애플의 아이폰보다 저렴하게 제작되었지만 가격 차이를 살펴보십시오. 아이폰은 훨씬 큰 배터리로 인해 더 비싸다 (그리고 평균적으로 CPU가 더 느리다). 내 안드로이드 폰 (Google Galaxy Nexus)은 IPhone 4G와 비슷한 배터리 수명을 가지고 있지만 하드웨어 사양이 훨씬 빠릅니다 (1GHz vs. 1.2GHZ).

편집 : Java는 프로그래머의 지식 없이도 코드를 최적화 할 수 있습니다. 완벽한 C 코드는 항상 Java / Objective-C / C #보다 빠르게 실행됩니다. 즉, 얼마나 많은 프로그래머가 완벽합니까? JVM 수준에서 Java와 라이브러리는 오픈 소스 개발 원칙으로 인해 항상 "더 완벽합니다". ( http://www.infoq.com/news/2012/03/Defects-Open-Source-Commercial )

편집 2 : 약간의 정보 : Lenovo의 새로운 P780 Android 전화-42 시간 통화 대 IPhone에서 12 시간.


1
나는 그 질문 자체 가 "... Android 휴대 전화는 다른 플랫폼 / 휴대폰에 비해 배터리 수명이 엄청나 다"와 같은 근거없는 주장을한다고 주장한다. 사실이 아닙니다.
allquixotic

첫 번째 링크가 모호한 품질의 IMHO임을 추가하고 싶습니다. 벤치 마크 파일이 사라졌으며 주석 작성자가 링크의 포스터 의견을 반박했습니다. 이 소식은 믿을 수없는 출처와 주관적인 진술이 없기 때문에 편견이없는 것 같습니다.
Doktoro Reichard

첫 번째 논평자는 옳습니다. 자세한 테스트가 없으면 모든 답변이 편향됩니다. 나는 안드로이드 폰의 배터리 수명이 상당히 끔찍하지만 많은 사람들이 언급 한 것처럼 VM 때문이 아니라는 데 동의합니다.
Igor Čordaš 2016 년

곧이 모든 정보는 안드로이드에서 ART 런타임이 나오면 구식입니다.
Mark Lopez

3

그렇습니다. 이는 전력 소비 증가와 관련이 있습니다. 추상화 계층이이를 수행합니다. 또한 속도가 감소합니다 (동일한 동전의 반대쪽-오버 헤드가 큰 경우 수행하는 데 시간이 오래 걸리므로 더 많은 CPU를 사용합니다). 올바르게 이해한다면 NDK 의 장점 중 하나입니다 . 특정 코드를 작성하여 특정 프로세서의 속도를 높일 수 있습니다.

즉, 대부분의 작업에서 VM 실행의 "전력 관련"오버 헤드가 다른 고려 사항으로 인해 뒤떨어 졌다고 생각합니다. 대부분의 프로그램에서 화면과 라디오를 사용하면 대부분의 전력이 소비됩니다.


네 말이 맞아 Oled 화면에서 검은 색 인터페이스 요소를 사용하더라도 대부분의 경우 NDK 대 SDK를 사용하는 것보다 절전 기능이 더 커집니다.
Igor Čordaš 2016 년

3

다른 모든 포스터와 관련하여 여기서 가장 중요한 것은 C / C ++ / Java가 존재하는지 여부가 아니라 응용 프로그램이 수행하는 작업입니다.

전력 소비는 처리와 직접 매핑되므로 프로그램이 어떤 처리를 수행 할 것인지 스스로에게 물어볼 것입니다.

숫자를 추가한다고 가정하십시오. 2.000.000에 도달 할 때까지 무한 루프에 2를 2로 더한다고 가정하십시오. 두 가지 질문이 발생합니다.

  1. 구현 방법 : for 루프입니까? while 루프입니까? (고토 / 라벨 핵인가요?)
  2. 코드는 어떻게 최적화되고 있습니까?

이 두 가지 질문은 궁극적으로 프로세서가 수행해야하는 작업 수와 장치가 사용하는 전력량을 정의합니다. 이 말에 따르면 가상화 된 환경을 실행하는 "오버 헤드"는 프로그램 전체에 대해 Java가 이전에 최적화 한 것으로 인해 무시할 수 있지만 다시 한 번 응용 프로그램의 작업에 따라 다릅니다.


0

예.

가상 머신은 '모든 것을 두 번 수행'하며 반드시 효율적일 필요는 없습니다. 따라서 그들은 '실제 기계'와 동일한 명령을 처리하기 위해 적어도 두 배의 전력을 사용합니다. 가상 머신이 있으면 작업 속도가 느려지고 더 많은 전력을 사용합니다. 기본적으로 iOS 및 Windows와 같은 OS는 전력 소비를 줄이면서 모든 작업을 더 빠르게 수행합니다.

이것은 화면 전환, 페이지 로딩, 탐색 등의 실제 차이점으로 해석됩니다. 현재 Android (VM)와 Windows Phone을 비교하고 느린 프로세서 (1GHz vs 1.6GHz)를 사용하더라도 Windows는 동일한 종류의 작업을 수행하는 Android보다 성능이 훨씬 뛰어납니다.

그러나 대부분의 사람들이 관심을 끄는 것은 앱을 설치하고 갑자기 배터리가 더 빨리 소모되는 시점입니다. 그것은 실제로 가상 머신 때문이 아니라 배고픈 리소스를 사용하는 앱입니다.

가상 머신 OS, 이식성에 대한 전체적인 이유는 OS를 기반으로하는 좋은 이유가 아닙니다. 사람들이 좋아하는 아키텍처로 휴대 전화를 구매하고 휴대 성이 있기 때문에 Android를 사용하는 것을 보십니까? 사람들이 더 높은 성능과 안정성을 포기하고 Android 이외의 휴대 전화에 Android를 설치하는 것을 보십니까? 사람들은 Android Phone, Windows Phone 또는 IPhone 등을 구입합니다. 저렴한 장치에서 휴대 성을 위해 성능을 희생하는 것은 비현실적입니다. 실패한 것이 좋은 생각이었습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.