Android hay Java có sử dụng nhiều năng lượng hơn do nó chạy trên máy ảo không?

Do các ứng dụng Android chạy trên JVM (Dalvik VM) về cơ bản là bộ xử lý ảo và mọi hướng dẫn ảo phải được ánh xạ tới hướng dẫn gốc của chipset bên dưới, ánh xạ này có dẫn đến tiêu thụ nhiều năng lượng hơn do chi phí của ánh xạ này không?

Câu hỏi này có thể được mở rộng sang Java và cũng được đặt ra là "các ứng dụng Java có sử dụng nhiều năng lượng hơn không?". Đây có phải là lý do tại sao điện thoại Android có tuổi thọ pin khủng như vậy so với các nền tảng / điện thoại khác?

Chỉnh sửa : Dựa trên các câu trả lời tôi đã làm rõ một vài điểm vì tôi đã nói sai về JVM và Dalvik thay thế cho nhau. Trong phần này, tôi chỉ nói về Java để hỏi liệu nó có sử dụng nhiều năng lượng hơn không và nếu có, điều đó có áp dụng về mặt khái niệm cho Android hay không và điều đó có làm giảm tuổi thọ pin.

Bối cảnh : trích dẫn từ Wikipedia:

1. Mã byte Java tương tự như ngôn ngữ lắp ráp cho mã C.
2. Từ quan điểm của một trình biên dịch, máy ảo Java chỉ là một bộ xử lý khác với một tập lệnh, mã byte Java, cho mã nào có thể được tạo.
3. JVM có kiến ​​trúc ngăn xếp. Dalvik là một máy ảo quy trình không phải là loại ảo hóa giống như JVM và có kiến ​​trúc đăng ký.

Do ngôn ngữ lập trình Java được biên dịch thành mã byte (giống như lắp ráp) và nó chạy trên bộ xử lý ảo, nên nó cung cấp tính di động mã phần mềm thực sự. Ngoài ra, vì có một JVM cho Linux và Linux đã được chuyển sang phần cứng mở, sự kết hợp này có thể cung cấp tính di động ứng dụng thực sự trên toàn bộ ngăn xếp.

Sức mạnh : Câu hỏi chủ yếu tập trung vào vấn đề này - với cùng một bộ chức năng của mã phần mềm hoặc ứng dụng của bạn, bao nhiêu phần trăm chu kỳ xung nhịp CPU của bạn được quy cho môi trường thời gian chạy. Điều này là với môi trường biên dịch đúng lúc của các JVM hiện đại trong đó nếu mã byte được biên dịch theo hướng dẫn gốc của chipset bên dưới, thì thời gian chạy chỉ nên hoạt động trong quá trình biên dịch jit. Vì vậy, bao nhiêu chu kỳ xung nhịp CPU được sử dụng hết trong môi trường thời gian chạy dự kiến ​​sẽ dẫn đến chi phí tiêu thụ điện năng. Tôi chỉ quan tâm đến khía cạnh tiêu thụ năng lượng, chứ không phải hiệu suất tương đối so với các ngôn ngữ được gõ và xây dựng tĩnh và hiểu các lợi thế của Java. Câu hỏi phụ có thể liên quan:

• Thời gian chạy Java có sử dụng libc cho chức năng của nó không?
• Có bất kỳ điểm nào trong số các điểm liên quan đến mức tiêu thụ năng lượng này chuyển sang Dalvik VM và Android không?
• Thay vì khái quát mức tiêu thụ pin kém của Android mà không nói về màn hình và chipset không dây - hãy nói về cách iPhone 5 có pin 1440 mAH nhỏ so với điện thoại Nexus hiện đại. Toàn bộ suy nghĩ này (Java, Bộ xử lý ảo, ánh xạ hướng dẫn, Android) nảy sinh do một người bạn trung thành với iphone tuyên bố đây có thể là lý do khiến iphone của anh ta có thời lượng pin tốt hơn so với nexus (tuyệt vời) của tôi.

Trong mọi trường hợp, cảm ơn câu trả lời dưới đây.

Câu hỏi của bạn dựa trên nhiều giả định thiếu sót. Hãy để tôi cố gắng làm rõ chúng:

• Bạn đã nói "JVM (Dalvik VM)". Điều đó giống như nói "Máy bay (Xe đạp)". Hai điều này hoàn toàn không có gì để làm với nhau.

• Bạn đã nói "... về cơ bản là một bộ xử lý ảo". Đơn giản là sai. Không phải là trường hợp, mỗi khi các từ "Máy ảo" hoặc từ viết tắt "VM" được sử dụng trong ngữ cảnh kỹ thuật, về cơ bản nó tương đương với VMware Workstation . Điều này là do các sản phẩm như VMware thực tế mô phỏng toàn bộ máy tính, không chỉ CPU và đang chạy một hệ điều hành trên hệ điều hành khác. Dalvik VM không hoạt động như vậy. Thậm chí không gần gũi.

• Java chỉ là một ngôn ngữ lập trình. Đó là cú pháp. Các chương trình Android / Dalvik tình cờ sử dụng cú pháp tương tự hoặc rất giống với ngôn ngữ lập trình máy chủ / máy tính để bàn hoàn toàn không liên quan được gọi là Java, chạy trên Máy ảo Java. Về lý thuyết, bạn có thể viết mã Java có tốc độ gần bằng tốc độ với mã C, vì cả hai đều là ngôn ngữ lập trình cấp cao. Ma quỷ trong các chi tiết về việc thực hiện các cuộc gọi thư viện và cách thức thiết kế thời gian chạy, điều này rất ít liên quan đến cú pháp của ngôn ngữ.

• Đó là một khái quát quá mức để nói rằng Dalvik VM, Sun Java Hotspot JVM hoặc cú pháp ngôn ngữ lập trình Java chịu trách nhiệm cho mức tiêu thụ điện năng cao. Lý do là bạn phải so sánh bất cứ điều gì bạn đang nói về hiệu suất của một thứ khác . Trong trường hợp chung nhất, khi bạn chỉ so sánh các khả năng "trường hợp tốt nhất" của cả hai nền tảng, về nguyên tắc có thể tạo ra các ứng dụng Dalvik nhanh hoặc nhanh hơn các chương trình trên bất kỳ nền tảng nào khác. Khác với quản lý bộ nhớ tự động và biên dịch JIT - các tính năng tiêu chuẩn trong hầu hết các môi trường lập trình hiện nay, kể cả trên iOS và JavaScript / HTML5 - có rất ít sự tách biệt Dalvik với Objective-C, .NET, Ruby, Oracle Hotspot JVM, Python, v.v.

• Nhận thức rằng "Java chậm" là do sự cố với các phiên bản Java cũ, ở chỗ chúng không có Trình biên dịch đúng lúc (JIT) hoặc JIT mà chúng bị hạn chế về chức năng. JVM đã có một Trình biên dịch đúng lúctrong một thời gian rất dài bây giờ Trình biên dịch JIT là một phần của thời gian chạy (ví dụ, JVM) có mã byte độc ​​lập với bộ xử lý - ví dụ mã byte Java - và biên dịch nó thành các lệnh gốc cho CPU. Quá trình này được thực hiện khi chương trình Java khởi chạy và các trình biên dịch JIT nâng cao có thể tối ưu hóa các chức năng hoặc hướng dẫn riêng lẻ trong thời gian chạy để cải thiện hiệu suất của chúng dựa trên các kết quả quan sát được. Chẳng hạn, nếu một phương thức trả về true mỗi lần nó được gọi, nhưng không rõ ràng từ mã byte gốc mà nó sẽ làm như vậy, trình biên dịch JIT có thể nhận ra rằng nó chỉ trả về true và thay thế lệnh gọi hàm bằng một lệnh cứng giá trị mã hóa của "true". Đây chỉ là một ví dụ.

• Biên dịch JIT và các kỹ thuật phân tích mã động thời gian chạy đã đạt được những tiến bộ lớn trong những năm gần đây. Nhiều người trong cộng đồng khoa học máy tính tin rằng, trong một hoặc hai thập kỷ, việc phân tích tinh vi có sẵn trong tự động giải thích / ngôn ngữ biên dịch, chẳng hạn như Java, C # và Ruby, sẽ được để nâng cao rằng, trong hầu hết các trường hợp, những ngôn ngữ sẽ thực hiện nhanh hơn ở thời gian chạy hơn các ngôn ngữ được biên dịch tĩnh như C và C ++. Đó là bởi vì trình biên dịch tĩnh thường bị giới hạn trong việc biên dịch mã khi xây dựng và mã không được sửa đổi khi chạy. Nhưng trong một môi trường thời gian chạy, nơi mã của chương trình có thể tự viết lạitrong quá trình thực thi để thực hiện hiệu quả hơn, có rất nhiều ưu điểm có thể đạt được bằng cách phân tích hiệu suất của mã và thực hiện các điều chỉnh để giảm độ phức tạp của mã hoặc số lệnh được chạy trên CPU. Đối với mã được gọi thường xuyên, đầu tư thời gian cần thiết để thực hiện phân tích vượt xa các lợi ích hiệu suất của việc liên tục gọi mã nhanh hơn.

• Cần lưu ý rằng máy ảo Dal Dal của Android cũng chứa JIT và nó không sử dụng định dạng mã byte giống như JVM của Sun / Oracle. JIT của Dalvik được tối ưu hóa cho các môi trường bộ nhớ thấp và nó rất tiên tiến khi cải tiến hiệu năng thời gian chạy. Vì vậy, có một sự trùng hợp ngẫu nhiên là JVM và Dalvik thực hiện các tối ưu hóa tương tự cho môi trường thời gian chạy dựa trên Java tương ứng của chúng, nhưng dưới vỏ bọc thì chúng hoàn toàn khác nhau.

• Đừng quên rằng chính Dalvik; nhân Linux; quy trình hệ thống cấp thấp; và cốt lõi của trình duyệt web Android (cả Firefox và Chrome) được viết bằng C / C ++ bản địa, và do đó, họ không có bất kỳ mối lo ngại nào mà chương trình Dalvik sẽ làm. Điều này giống như iOS. Nếu bạn đang nói về Android thuần túy và không phải là nhà cung cấp dịch vụ / bên thứ ba đứng đầu, thì một tỷ lệ rất lớn của Android bao gồm lõi không được viết bằng Dalvik.

• Các nhà phát triển ứng dụng trên Android cũng có thể, tùy chọn của họ, viết mã gốc, bỏ qua Dalvik. Nếu một nhà phát triển ứng dụng cảm thấy rằng Dalvik đang hoạt động như một nút cổ chai trong việc thực thi mã của họ hoặc khiến nó tiêu tốn quá nhiều pin, họ có thể chỉ cần viết C / C ++ hoặc thậm chí mã lắp ráp nếu họ chọn, mà không cần phải có sự chấp thuận của Google để làm như vậy và phân phối ứng dụng của họ như thế.

Dưới đây là một số lý do thực tế tại sao một thiết bị chạy pin Android hoặc bất kỳ thiết bị nào có thể gặp vấn đề với thời lượng pin:

• Các ứng dụng giữ cho CPU, màn hình hoặc kết nối dữ liệu luôn hoạt động. Đặc biệt, các chip 4G như LTE sử dụng rất nhiều năng lượng khi chúng được bật nguồn, vì vậy nếu bạn có các chương trình nền liên tục đánh thức chip LTE để truyền một vài kilobyte dữ liệu, điều đó sẽ làm cạn kiệt pin của bạn rất nhanh. Màn hình trên điện thoại thông minh và máy tính bảng hiện đại cũng rất tốn năng lượng, trừ khi bạn giảm độ sáng xuống mức tối thiểu.

• "Bloatware" được yêu cầu phải có trên thiết bị và không thể gỡ cài đặt. Một số nhà mạng vô đạo đức yêu cầu bạn chạy bloatware chiếm chu kỳ CPU và giữ cho kết nối dữ liệu luôn hoạt động. Điều này có thể là do sự bất tài của các nhà phát triển phần mềm của bloatware hoặc mục đích cố ý giám sát các hoạt động của bạn trên điện thoại thông minh của bạn và gửi chúng đến một máy chủ từ xa để khai thác dữ liệu, rất tốn năng lượng cho pin của bạn.

Cuối cùng, tôi không đồng ý với đánh giá của bạn rằng Android có vấn đề về thời lượng pin tồi tệ hơn so với các nền tảng di động khác. Một số điện thoại và thiết bị thực sự có thể có vấn đề về tuổi thọ pin, do dung lượng của pin so với mức tiêu thụ năng lượng của phần cứng; cài đặt năng lượng được tối ưu hóa kém (do người dùng, nhà mạng hoặc nhà sản xuất bầu chọn); hoặc các ứng dụng bloatware giúp giữ chip trong điện thoại luôn hoạt động. Nhưng đối với mọi ví dụ về một thiết bị có vấn đề về pin, tôi có thể cung cấp cho bạn một ví dụ về một thiết bị có tuổi thọ pin tuyệt vời. Không có cách đơn giản nào để khái quát rằng "đó là Dalvik" hoặc "đó là Linux" hoặc "đó là Java". Tối ưu hóa năng lượng là một mớ phần cứng / phần mềm phức tạp của các mối quan tâm cạnh tranh, bao gồm hiệu năng, khả năng đáp ứng, và mong đợi của người dùng về tuổi thọ pin, với ưu và nhược điểm cho từng lựa chọn. Để hiểu đầy đủ cấu hình nguồn của thiết bị, bạn phải xem kỹ pin, tất cả phần cứng và tất cả phần mềm đang chạy trên thiết bị.

Trong câu trả lời này, tôi sẽ so sánh hiệu năng với Android và IOS khi cả hai chiếm hơn 80% thị phần.

Các ứng dụng Java không sử dụng nhiều năng lượng hơn. ( Http://www.javarants.com/2004/05/04/looks-like-apple-should-switch/ ) Java VM Oracle hoặc trong thực tế Dalvik VM của Google được xem nhiều hơn nữa Effient hơn IOS của Objective-C. Java có thể tối ưu hóa mã trước khi được thực thi trên điện thoại, điều này có thể mang lại hiệu suất tốt hơn nhiều. Các thư viện Java là Nguồn mở và do đó đã được tối ưu hóa bởi hàng trăm nhà phát triển khác nhau. Mặt khác, chỉ có iOS, các nhà phát triển của Apple mới có thể thay đổi mã. Ít xem xét = hiệu suất ít tiềm năng.

Các chương trình Android cũng có thể chạy mã C gốc có thể bị tranh chấp nhanh hơn so với Object-C (ngôn ngữ duy nhất được hỗ trợ trên iOS).

Lý do tại sao Google quyết định sử dụng Dalvik VM là vì tính di động. Tôi biết về bốn kiến ​​trúc CPU khác nhau mà Android có thể chính thức chạy trên (ARM, MIPS, x86, I.MX). Trong khi mọi hệ điều hành điện thoại khác chỉ có thể sử dụng một (ARM). ( http://en.wikipedia.org/wiki/Comparison_of_mobile_operating_systems ) Vì vậy, so sánh các loại CPU khác nhau với ví dụ IPhone là không công bằng. Nếu Android được chạy trên iPhone, Android sẽ có hiệu năng vượt trội và thời lượng pin.

"các ứng dụng Java có sử dụng nhiều năng lượng hơn không?" Đơn giản là không.
Tại sao điện thoại Android có tuổi thọ pin khủng như vậy so với các nền tảng / điện thoại khác? Nhiều điện thoại Android được xây dựng rẻ hơn IPhone của Apple, nhưng hãy nhìn vào sự khác biệt về giá. IPhone có giá cao hơn vì có pin lớn hơn nhiều (và CPU trung bình chậm hơn). Điện thoại Android của tôi (Google Galaxy Nexus) có thời lượng pin tương đương với IPhone 4G nhưng có thông số phần cứng nhanh hơn nhiều (1GHz so với 1.2GHZ).

EDIT: Java có thể tối ưu hóa mã mà không cần kiến ​​thức của lập trình viên. Hoàn hảo, mã C sẽ luôn chạy nhanh hơn Java / Objective-C / C #; Điều đó nói rằng, có bao nhiêu lập trình viên ngoài kia là hoàn hảo? Ở mức JVM, Java và các thư viện sẽ luôn "hoàn hảo hơn" vì các nguyên tắc phát triển nguồn mở của nó. ( http://www.infoq.com/news/2012/03/Defects-Open-Source-CommIAL )

EDIT 2: Thông tin nhỏ: Điện thoại Android P780 mới của Lenovo - trò chuyện 42 giờ so với 12 giờ trên iPhone.

Vâng, nó liên quan đến việc tiêu thụ năng lượng tăng lên - các lớp trừu tượng sẽ làm điều đó. Nó cũng dẫn đến việc giảm tốc độ (phía đối diện của cùng một đồng tiền - nếu một cái gì đó có chi phí lớn hơn thì sẽ mất nhiều thời gian hơn để thực hiện và do đó sử dụng nhiều CPU hơn). Nếu tôi hiểu chính xác đó là một trong những lợi thế của những gì NDK làm - cho phép tăng tốc cho các bộ xử lý cụ thể bằng cách viết mã cụ thể.

Điều đó nói rằng, đối với hầu hết các công việc, tôi tưởng tượng các chi phí "liên quan đến năng lượng" của việc chạy VM bị lấn át bởi các cân nhắc khác - đối với hầu hết các chương trình, việc sử dụng màn hình và radio sẽ tiêu tốn phần lớn năng lượng.

Liên quan đến tất cả các áp phích khác, tôi tin rằng điều quan trọng nhất ở đây không phải là liệu C / C ++ / Java có tồn tại hay không mà là các ứng dụng đang làm gì.

Vì bản đồ tiêu thụ năng lượng trực tiếp với quá trình xử lý, tôi sẽ tự hỏi chương trình xử lý sẽ làm gì.

Giả sử bạn đang thêm số. Giả sử bạn thêm 2 với 2 vào một vòng lặp vô hạn cho đến khi bạn đạt 2.000.000. Hai câu hỏi phát sinh:

1. Nó được thực hiện như thế nào: Đây có phải là một vòng lặp for không? Có phải là một vòng lặp while? (Đây có phải là hack Goto / Nhãn không?)
2. Làm thế nào là mã được tối ưu hóa.

Hai câu hỏi này cuối cùng xác định có bao nhiêu thao tác mà bộ xử lý cần thực hiện và cuối cùng, thiết bị sử dụng bao nhiêu năng lượng. Điều này đang được nói, "chi phí hoạt động" của môi trường ảo hóa có thể không đáng kể do tối ưu hóa trước đó được thực hiện bởi Java trên toàn bộ chương trình, nhưng một lần nữa, tất cả phụ thuộc vào ứng dụng đang làm gì.

Đúng.

Máy ảo 'làm mọi thứ hai lần' và không nhất thiết phải hiệu quả. Vì vậy, họ sẽ sử dụng ít nhất gấp đôi năng lượng để xử lý các hướng dẫn tương tự như 'máy thật'. Sự hiện diện của một máy ảo làm mọi thứ chậm lại và sử dụng nhiều năng lượng hơn. Về cơ bản, các hệ điều hành như iOS và WIndows sẽ làm mọi thứ nhanh hơn và tiêu thụ ít năng lượng hơn.

Điều này chuyển thành sự khác biệt thực sự trong chuyển đổi màn hình, tải trang, điều hướng, những thứ tương tự. Hiện tại tôi đang so sánh Android (VM) và Windows Phone và thậm chí với bộ xử lý chậm hơn (1GHz so với 1.6GHz), Windows vượt trội đáng kể so với Android thực hiện cùng một loại tác vụ.

Tuy nhiên, điều thu hút sự chú ý của hầu hết mọi người là khi họ cài đặt một ứng dụng và đột nhiên pin của họ được sử dụng nhanh hơn. Đó không thực sự là do máy ảo, mà là một ứng dụng sử dụng tài nguyên một cách đói khát.

Toàn bộ lý do cho một hệ điều hành máy ảo, tính di động, không phải là lý do chính đáng để dựa trên hệ điều hành. Bạn có thấy mọi người mua điện thoại với kiến ​​trúc yêu thích của họ và sử dụng Android vì nó di động không? Bạn có thấy mọi người từ bỏ hiệu suất và độ tin cậy cao hơn và đưa Android lên điện thoại không phải Android của họ không? Mọi người mua Điện thoại Android hoặc Windows Phone hoặc IPhone, v.v ... Để hy sinh hiệu năng cho tính di động trong các thiết bị giá rẻ là không thực tế. Đó là một ý tưởng tốt mà trở thành một thất bại.