क्या वर्चुअल मशीन पर चलने के बाद एंड्रॉइड या जावा अधिक शक्ति का उपयोग करता है?

Question

चूंकि एंड्रॉइड एप्लिकेशन एक जेवीएम (डाल्विक वीएम) पर चलते हैं जो मूल रूप से एक वर्चुअल प्रोसेसर है, और प्रत्येक आभासी निर्देश को अंतर्निहित चिपसेट के मूल निर्देश के साथ मैप करना पड़ता है, क्या इस मैपिंग के परिणामस्वरूप इस मैपिंग के ओवरहेड के कारण अधिक बिजली की खपत होती है?

इस प्रश्न को जावा में बढ़ाया जा सकता है और इसे "जहाँ अनुप्रयोग अधिक शक्ति का उपयोग करते हैं?" क्या अन्य प्लेटफार्मों / फोन की तुलना में एंड्रॉइड फोन में ऐसी भयावह बैटरी रहती है?

संपादित करें : उत्तर के आधार पर मैंने कुछ बिंदुओं को स्पष्ट किया है क्योंकि मैंने गलत तरीके से JVM और Dalvik के बारे में बात की थी। इस बिट में मैं जावा के बारे में केवल यह पूछने के लिए बात कर रहा हूं कि क्या यह अधिक शक्ति का उपयोग करता है और यदि हां, तो क्या यह वैचारिक रूप से एंड्रॉइड पर भी लागू होता है और क्या इसका परिणाम बैटरी जीवन में कमी है।

संदर्भ : विकिपीडिया से उद्धृत:

1. जावा बाइटकोड सी कोड के लिए विधानसभा भाषा के अनुरूप है।
2. एक कंपाइलर के दृष्टिकोण से, जावा वर्चुअल मशीन एक निर्देश सेट, जावा बाइटकोड के साथ सिर्फ एक और प्रोसेसर है, जिसके लिए कोड उत्पन्न किया जा सकता है।
3. जेवीएम में एक स्टैक आर्किटेक्चर है। Dalvik एक प्रक्रिया वर्चुअल मशीन है जो JVM के समान वर्चुअलाइजेशन नहीं है और इसमें एक रजिस्टर आर्किटेक्चर है।

चूँकि जावा प्रोग्रामिंग लैंग्वेज को बायटेकोड (असेंबली-लाइक) से संकलित किया जाता है और यह वर्चुअल प्रोसेसर पर चलता है, यह सही सॉफ्टवेयर कोड पोर्टेबिलिटी प्रदान करता है। इसके अलावा, चूंकि लिनक्स के लिए एक जेवीएम है और लिनक्स को खुले हार्डवेयर पर पोर्ट किया गया है, इसलिए संयोजन पूरे स्टैक पर सही एप्लिकेशन पोर्टेबिलिटी प्रदान कर सकता है।

पावर : यह प्रश्न अनिवार्य रूप से इस पर उबलता है - आपके सॉफ़्टवेयर कोड या एप्लिकेशन की कार्यक्षमता के समान सेट के लिए, आपके CPU घड़ी चक्रों के कितने प्रतिशत को रन टाइम वातावरण के लिए जिम्मेदार ठहराया जाता है। यह आधुनिक जेवीएम के जस्ट-इन-टाइम संकलन वातावरण के साथ है जहां अगर बायोटकोड को अंतर्निहित चिपसेट के मूल निर्देश के लिए संकलित किया जाता है, तो रन-टाइम केवल जेट संकलन के दौरान सक्रिय होना चाहिए। तो सीपीयू घड़ी चक्रों का उपयोग रन-टाइम वातावरण में करने के लिए कितना किया जाता है जिसके परिणामस्वरूप बिजली की खपत ओवरहेड होने की उम्मीद है। मैं केवल बिजली की खपत के पहलू में दिलचस्पी रखता हूं, न कि सांख्यिकीय रूप से टाइप की गई और निर्मित भाषाओं की तुलना में सापेक्ष प्रदर्शन और जावा के फायदों को समझता हूं। उप-प्रश्न जो संबंधित हो सकते हैं:

• जावा रन टाइम कार्यक्षमता के लिए libc का उपयोग करता है?
• क्या इनमें से कोई भी बिजली की खपत से संबंधित बिंदु Dalvik VM और Android में अनुवाद करते हैं?
• स्क्रीन और वायरलेस चिपसेट के बारे में बात किए बिना एंड्रॉइड की खराब बैटरी खपत को सामान्य करने के बजाय - आइए बात करते हैं कि कैसे iPhone 5 में 1440 एमएएच की बैटरी है जो आधुनिक नेक्सस फोन की तुलना में छोटी है। विचार की यह पूरी ट्रेन (जावा, वर्चुअल प्रोसेसर, इंस्ट्रक्शन मैपिंग, एंड्रॉइड) उत्पन्न हुई क्योंकि एक iphone-वफादार मित्र ने दावा किया कि यह उसके iphone के लिए मेरे (भयानक) सांठगांठ से बेहतर बैटरी जीवन का संभावित कारण हो सकता है।

किसी भी मामले में, नीचे दिए गए उत्तर के लिए धन्यवाद।

Comments

बैटरी की तुलना उनके mAh से न करें। वह चालू है; सिद्धांत रूप में आपके पास 10000 mAh की बैटरी की तुलना में अधिक पावर (वाट-घंटे) के साथ 2 mAh की बैटरी हो सकती है। वोल्टेज पर निर्भर करता है। Nexus 4 में 8 Wh बैटरी है जबकि iPhone 5 में 5.45 Wh बैटरी है। अंतर काफी हद तक स्क्रीन के आकार के कारण होता है: नेक्सस 4 में 4.7 "विकर्ण डिस्प्ले होता है जबकि आईफोन 5 में 4 इंच, उच्च रिज़ॉल्यूशन और उच्च चमक (608 सीडी / मी ^ 2 बनाम 500) होता है। प्रोसेसर। यह भी स्पष्ट रूप से अलग है: नेक्सस 4 में क्वाड-कोर @ 1.5 गीगाहर्ट्ज़ है; आईफोन 5 में डुअल कोर @ 1.3 गीगाहर्ट्ज़ है। तेज़ = अधिक बैटरी का उपयोग।

— allquixotic

मूल रूप से आईफ़ोन एक छोटी बैटरी के साथ अधिक समय तक चलता है क्योंकि पूरा प्लेटफ़ॉर्म छोटा होने के लिए इंजीनियर होता है: कम भौतिक स्थान, छोटी स्क्रीन, छोटे सीपीयू, कम कोर, कम क्षमता, कम प्रदर्शन, कम, कम, कम। एंड्रॉइड फोन विपरीत दिशा में चल रहे हैं: बड़ा, और अधिक कोर, और अधिक शक्ति, और तेज। बेशक वे समान बैटरी जीवन प्राप्त करने के लिए बहुत बड़ी बैटरी की आवश्यकता कर रहे हैं। कभी-कभी बड़ी बैटरी भी खपत की ठीक से भरपाई नहीं करती है, और उस स्थिति में आपके पास खराब बैटरी लाइफ वाला फोन होता है।

— Allquixotic

Answer 1

आपका प्रश्न कई त्रुटिपूर्ण मान्यताओं पर आधारित है । मुझे उन्हें साफ़ करने का प्रयास करें:

• आपने कहा "JVM (Dalvik VM)"। यह "हवाई जहाज (साइकिल)" कहने जैसा है। इन दोनों चीजों का एक-दूसरे से कोई लेना-देना नहीं है।

• आपने कहा "... जो मूल रूप से एक आभासी प्रोसेसर है"। बस झूठ है। यह ऐसा नहीं है कि, हर बार "वर्चुअल मशीन" या "वीएम" शब्द का उपयोग तकनीकी संदर्भ में किया जाता है, यह अनिवार्य रूप से वीएमवेयर वर्कस्टेशन के बराबर है । ऐसा इसलिए है क्योंकि VMware जैसे उत्पाद वास्तव में सीपीयू ही नहीं, बल्कि पूरे कंप्यूटर का अनुकरण करते हैं, और एक अन्य ऑपरेटिंग सिस्टम के शीर्ष पर एक ऑपरेटिंग सिस्टम चला रहे हैं। Dalvik VM ऐसा काम नहीं करता है। आस - पास भी नहीं।

• जावा सिर्फ एक प्रोग्रामिंग भाषा है। यह वाक्यविन्यास है। Android / Dalvik प्रोग्राम जावा नामक पूरी तरह से असंबंधित डेस्कटॉप / सर्वर प्रोग्रामिंग भाषा के समान या बहुत समान सिंटैक्स का उपयोग करने के लिए होता है, जो जावा वर्चुअल मशीन पर चलता है। सिद्धांत रूप में, आप जावा कोड लिख सकते हैं जो सी कोड के समान ही गति है, क्योंकि वे दोनों उच्च स्तरीय प्रोग्रामिंग भाषा हैं। पुस्तकालय कॉल के कार्यान्वयन के विवरण और रनटाइम को डिज़ाइन करने के तरीके के बारे में शैतान का, जिसका भाषा के वाक्य विन्यास के साथ बहुत कम है।

• यह कहना एक सामान्यीकरण है कि हाई पावर की खपत के लिए Dalvik VM, Sun Java Hotspot JVM या Java प्रोग्रामिंग लैंग्वेज सिंटैक्स जिम्मेदार है। कारण यह है कि आपको किसी और चीज़ के प्रदर्शन के बारे में जो भी बात करनी है, उसकी तुलना करनी होगी । सबसे सामान्य मामले में, जब आप दोनों प्लेटफार्मों की "सर्वश्रेष्ठ-केस" क्षमताओं की तुलना कर रहे होते हैं, तो यह सिद्धांत रूप में होता है कि किसी भी अन्य प्लेटफॉर्म पर कार्यक्रमों की तुलना में बस या तो तेज या तेज गति से चलने वाले Dalvik एप्स बनाएं। स्वचालित मेमोरी प्रबंधन और JIT संकलन के अलावा - ऐसी सुविधाएँ जो इन दिनों लगभग सभी प्रोग्रामिंग वातावरणों में मानक हैं, जिनमें iOS और जावास्क्रिप्ट / HTML5 शामिल हैं - बहुत कम है जो Dalvik को Objective-C, .NET, Ruby, से अलग करता है ओरेकल हॉटस्पॉट जेवीएम, पायथन, और इसी तरह।

• यह धारणा कि "जावा धीमा है" जावा के पुराने संस्करणों के साथ एक समस्या के कारण है, इसमें या तो उनके पास जस्ट-इन-टाइम कंपाइलर (जेआईटी) नहीं था, या जेआईटी के पास कार्यक्षमता में बहुत सीमित था। JVM में जस्ट-इन टाइम कंपाइलर थाअब बहुत लंबे समय के लिए। एक JIT संकलक रनटाइम (उदाहरण के लिए, JVM) का एक हिस्सा है जो प्रोसेसर-स्वतंत्र बायोटेक - उदाहरण के लिए Java bytecode - को लेता है और इसे CPU के लिए मूल निर्देशों में संकलित करता है। यह प्रक्रिया तब की जाती है जब जावा प्रोग्राम लॉन्च होता है, और उन्नत जेआईटी कंपाइलर अवलोकन परिणामों के आधार पर अपने प्रदर्शन को बेहतर बनाने के लिए रनटाइम पर व्यक्तिगत कार्यों या निर्देशों का अनुकूलन कर सकते हैं। उदाहरण के लिए, यदि कोई विधि यह कहे जाने पर हर बार सही होती है, लेकिन यह मूल बायोटेक से स्पष्ट नहीं है कि वह ऐसा करेगा, तो JIT कंपाइलर यह मान सकता है कि यह सही है, और फ़ंक्शन कॉल को हार्ड से बदल देता है- "सत्य" का कोडित मूल्य। यह तो केवल एक उदाहरण है।

• जेआईटी संकलन और रनटाइम डायनामिक कोड विश्लेषण तकनीक हाल के वर्षों में भारी प्रगति कर रही है। कंप्यूटर विज्ञान समुदाय के कई लोगों का मानना ​​है कि, एक या दो दशक में, जावा, सी # और रूबी जैसी गतिशील रूप से व्याख्या / संकलित भाषाओं में उपलब्ध परिष्कृत विश्लेषण इतने उन्नत होंगे कि, ज्यादातर मामलों में, ये भाषाएं तेजी से निष्पादित होंगी C और C ++ जैसी सांख्यिकीय रूप से संकलित भाषाओं की तुलना में रनटाइम। ऐसा इसलिए है क्योंकि स्थिर संकलक आमतौर पर बिल्ड-टाइम में कोड संकलन तक सीमित होते हैं, और कोड रनटाइम पर संशोधित नहीं होता है। लेकिन एक रनटाइम माहौल में जहां प्रोग्राम का कोड खुद को फिर से लिख सकता हैनिष्पादन को और अधिक कुशलता से करने के लिए, कोड के प्रदर्शन का विश्लेषण करके और सीपीयू पर चलने वाले निर्देशों की संख्या को कम करने के लिए कोड के प्रदर्शन का विश्लेषण करके और समायोजन करके प्राप्त किया जा सकता है। बार-बार कोड के लिए, विश्लेषण करने के लिए आवश्यक समय निवेश बार-बार तेज कोड को कॉल करने के प्रदर्शन लाभ से बहुत आगे निकल जाता है।

• यह ध्यान दिया जाना चाहिए कि एंड्रॉइड डाल्विक वीएम में एक जेआईटी भी शामिल है, और यह सूर्य / ओरेकल जेवीएम के रूप में एक ही बाईटकोड प्रारूप का उपयोग नहीं करता है। Dalvik का JIT कम मेमोरी वातावरण के लिए अनुकूलित है, और यह रनटाइम प्रदर्शन बढ़ाने के रूप में बहुत उन्नत है। तो यह कुछ हद तक एक संयोग है कि JVM और Dalvik अपने संबंधित जावा-आधारित रनटाइम वातावरण के लिए समान अनुकूलन लागू करते हैं, लेकिन हुड के तहत वे काफी अलग हैं।

• उस डाल्विक को न भूलें; लिनक्स कर्नेल; निम्न-स्तरीय प्रणाली प्रक्रियाएं; और एंड्रॉइड वेब ब्राउज़र (फ़ायरफ़ॉक्स और क्रोम दोनों) के मूल देशी सी / सी ++ में लिखे गए हैं, और इसलिए उनके पास कोई ओवरहेड चिंताएं नहीं हैं जो एक Dalvik प्रोग्राम होगा। यह iOS जैसा ही है। यदि आप शुद्ध एंड्रॉइड के बारे में बात कर रहे हैं, न कि कैरियर / थर्ड-पार्टी ब्लोट जो इसके ऊपर बैठता है, तो कोरविक में जो बहुत बड़ा अनुपात सम्‍मिलित है वह Dalvik का उपयोग करके नहीं लिखा गया है।

• एंड्रॉइड पर एप्लिकेशन डेवलपर्स अपने विकल्प पर भी, मूल कोड लिख सकते हैं, डाल्विक को दरकिनार कर सकते हैं। यदि किसी एप्लिकेशन डेवलपर को लगा कि Dalvik उनके कोड के प्रदर्शन में अड़चन के रूप में काम कर रहा है, या इससे बहुत अधिक बैटरी निकलती है, तो वे Google की स्वीकृति प्राप्त किए बिना ही C / C ++ या असेंबली कोड लिख सकते हैं। ऐसा करने के लिए, और उनके ऐप को इस तरह वितरित करें।

यहां कुछ वास्तविक कारण बताए गए हैं कि एंड्रॉइड बैटरी चालित डिवाइस, या किसी भी डिवाइस के कारण बैटरी जीवन में समस्याएं हो सकती हैं:

• सीपीयू, स्क्रीन, या डेटा कनेक्शन को जागृत रखने वाले अनुप्रयोग। विशेष रूप से, एलटीई जैसे 4 जी चिपसेट जब वे संचालित होते हैं तो बहुत अधिक ऊर्जा का उपयोग करते हैं, इसलिए यदि आपके पास पृष्ठभूमि कार्यक्रम हैं जो एलटीई चिप को लगातार कुछ किलोबाइट डेटा स्थानांतरित करने के लिए जगाते हैं, तो यह आपकी बैटरी को बहुत तेजी से खत्म कर देगा। आधुनिक स्मार्टफोन और टैबलेट पर स्क्रीन भी बहुत ऊर्जा-गहन है, जब तक कि आप चमक को कम से कम नहीं करते।

• "ब्लोटवेयर" जो डिवाइस पर होना आवश्यक है, और इसे अनइंस्टॉल नहीं किया जा सकता है। कुछ बेईमान वाहक आपको ब्लोटवेयर चलाने के लिए आवश्यक होते हैं जो सीपीयू चक्र लेते हैं और डेटा कनेक्शन को जागृत रखते हैं। यह या तो ब्लोटवेयर के सॉफ़्टवेयर डेवलपर्स की ओर से अक्षमता के कारण हो सकता है, या आपके स्मार्टफोन पर आपकी गतिविधियों की निगरानी करने और उन्हें डेटा खनन के लिए एक दूरस्थ सर्वर पर भेजने का एक जानबूझकर लक्ष्य है, जो आपकी बैटरी के लिए बहुत ऊर्जा-गहन है।

अंत में, मैं आपके आकलन से असहमत हूं कि एंड्रॉइड में अन्य मोबाइल प्लेटफार्मों की तुलना में बैटरी जीवन की समस्याएं बदतर हैं। कुछ फोन और उपकरणों में वास्तव में बैटरी जीवन की समस्याएं हो सकती हैं, या तो हार्डवेयर की ऊर्जा खपत के सापेक्ष बैटरी की क्षमता के कारण; खराब अनुकूलित बिजली सेटिंग्स (उपयोगकर्ता, वाहक या निर्माता द्वारा निर्वाचित); या ब्लोटवेयर ऐप्स जो फोन में चिप्स रखते हैं, हर समय जागते हैं। लेकिन हर उस डिवाइस के उदाहरण के लिए जिसमें बैटरी की समस्या है, मैं आपको उत्कृष्ट बैटरी जीवन के साथ डिवाइस का एक प्रतिरूप दे सकता हूं। यह सामान्य करने का कोई सरल तरीका नहीं है कि "यह दलविक है" या "यह लिनक्स है" या "यह जावा है"। शक्ति अनुकूलन प्रदर्शन, जवाबदेही सहित प्रतिस्पर्धात्मक चिंताओं का एक जटिल हार्डवेयर / सॉफ्टवेयर मिश-घोष है, और बैटरी जीवन के लिए उपयोगकर्ता की अपेक्षाएँ, प्रत्येक विकल्प के लिए पेशेवरों और विपक्षों के साथ। किसी डिवाइस की पावर प्रोफाइल को पूरी तरह से समझने के लिए, आपको बैटरी पर ही, हार्डवेयर के सभी और डिवाइस पर चल रहे सभी सॉफ्टवेयर पर बारीकी से विचार करना होगा।

Comments

+1 यह एक छोटी सी tl है; डॉ। लेकिन इसमें सभी, यहां तक ​​कि एक अच्छा तकनीकी उत्तर भी है।

— डॉकटोरो रीचर्ड

धन्यवाद, सभी उचित बिंदु। मैंने गलत तरीके से कुछ शब्दों का इस्तेमाल किया था, क्योंकि मैं कुछ पूछ रहा था जो मुझे नहीं पता था। यदि आप अभी भी रुचि रखते हैं तो प्रश्न में ही कुछ संपादन किए हैं।

— पीकेएम

यह उत्तर काफी जानकारीपूर्ण है लेकिन सवाल से बहुत आगे निकल गया। सवाल का मुख्य यह था कि वीएम ओवरहेड अधिक सीपीयू समय का उपयोग करता है फिर यह अनुकूलन के द्वारा बचाता है जो इसे नियुक्त करता है। यह एंड्रॉइड के आईओएस से बेहतर क्यों है, हालांकि यह सवाल इशारा पक्ष के लिए भी था।

— इगोर :57ordaš

यहाँ एक त्रुटिपूर्ण धारणा है। IOS में Mac OS के स्वचालित मेमोरी प्रबंधन का अभाव है। और यह वास्तव में प्रबंधन है जो अपनी सभी विशिष्ट समस्याओं के साथ डाल्विक को "जावा" बनाता है। कुछ महीने पहले गारबेज कलेक्शन (GC) के मुद्दों पर एक बहुत अच्छा अवलोकन था, Dalvik चल रहा है: anandtech.com/show/8231/… - अगर वे बैटरी जीवन को प्रभावित करते हैं या सिर्फ प्रदर्शन जो मैं नहीं बता सकता।

— pvblivs

@pvblivs जबकि यह सच है कि iOS के लिए "उच्च-स्तरीय" एप्लिकेशन कोड लिखना GC के बजाय स्वचालित संदर्भ गणना का उपयोग करता है जबकि Dalvik GC का उपयोग करता है, और "इसलिए" (मैं यह नहीं कह रहा हूं यह जरूरी सच है, बस आप बहस करने लगते हैं कि, और यह कम प्रशंसनीय पर) आईओएस "और अधिक कुशल" है एंड्रॉयड से ... तुम अब भी मेरी बात याद आ रही की तरह कर रहे हैं Android एप्लिकेशन को नहीं है कि है जावा में लिखा जा रहा है, और वास्तव में या कोडांतरक में लिखा जा सकता है यहां तक ​​कि अगर आप चाहते हैं देशी एआरएम कोड! अत्यधिक प्रदर्शन के प्रति संवेदनशील ऐप और बिलिन स्टफ को जीसी के बिना देशी कोड का उपयोग करना चाहिए ।

— एलाक्विक्सोटिक

Answer 2

इस उत्तर में, मैं Android और IOS के साथ प्रदर्शन की तुलना करूंगा क्योंकि दोनों का 80% बाजार में हिस्सा है।

जावा ऐप्स अधिक शक्ति का उपयोग नहीं करते हैं। ( http://www.javarants.com/2004/05/04/looks-like-apple-should-switch/ ) ओरेकल के जावा वीएम या वास्तव में Google के Dalvik VM को IOS के ऑब्जेक्टिव-सी की तुलना में अधिक पवित्र माना जाता है। जावा फोन पर निष्पादित होने से पहले कोड को अनुकूलित करने में सक्षम है, जिसके परिणामस्वरूप बेहतर प्रदर्शन हो सकता है। जावा लाइब्रेरी ओपन सोर्स हैं और इसलिए सैकड़ों विभिन्न डेवलपर्स द्वारा अनुकूलित किया गया है। दूसरी ओर IOS के साथ केवल Apple डेवलपर कोड बदलने में सक्षम हैं। कम समीक्षा = कम संभावित प्रदर्शन।

एंड्रॉइड प्रोग्राम भी मूल सी कोड को चलाने में सक्षम हैं जो ऑब्जेक्ट-सी (IOS पर समर्थित एकमात्र भाषा) की तुलना में अधिक तेजी से विवादित हो सकते हैं।

Google ने Dalvik VM का उपयोग करने का कारण पोर्टेबिलिटी के लिए तय किया है। मैं चार अलग-अलग सीपीयू आर्किटेक्चर के बारे में जानता हूं जो एंड्रॉइड (एआरएम, एमआइपी, x86, I.MX) पर आधिकारिक रूप से चल सकते हैं। जबकि हर दूसरा फोन OS केवल एक (ARM) का उपयोग कर सकता है। ( http://en.wikipedia.org/wiki/Comparison_of_mobile_operating_systems ) इसलिए उदाहरण के लिए IPhone के साथ विभिन्न CPU प्रकारों की तुलना करना अनुचित है। अगर एंड्रॉइड IPhone पर चलाया गया था, तो एंड्रॉइड बेहतर प्रदर्शन और बैटरी जीवन के लिए तुलनीय होगा।

"क्या जावा एप्लिकेशन अधिक शक्ति का उपयोग करते हैं?" बस नहीं।
एंड्रॉइड फोन में अन्य प्लेटफार्मों / फोन की तुलना में ऐसी भयावह बैटरी क्यों होती है? कई एंड्रॉइड फोन ऐप्पल के आईफोन की तुलना में सस्ते बनाए जाते हैं, लेकिन कीमत के अंतर को देखें। इसमें बड़ी बैटरी होने के कारण IPhone की कीमत अधिक है (और यह औसत धीमी सीपीयू पर है)। मेरे एंड्रॉइड फोन (Google गैलेक्सी नेक्सस) में आईफोन 4 जी की तुलना करने योग्य बैटरी जीवन है लेकिन इसमें बहुत तेज हार्डवेयर चश्मा (1GHz बनाम 1.2GHZ) है।

EDIT: जावा प्रोग्रामर के ज्ञान की आवश्यकता के बिना कोड को अनुकूलित कर सकता है। बिल्कुल सही, सी कोड हमेशा जावा / ऑब्जेक्टिव-सी / सी # से तेज चलेगा; उस ने कहा, कितने प्रोग्रामर परफेक्ट हैं? जेवीएम स्तर पर जावा और पुस्तकालय हमेशा अपने खुले स्रोत विकास सिद्धांतों के कारण "अधिक परिपूर्ण" होंगे। ( http://www.infoq.com/news/2012/03/Defects-Open-Source-Com वाणिज्यिक )

EDIT 2: जानकारी का छोटा सा हिस्सा: लेनोवो का नया P780 एंड्रॉइड फोन - 42 घंटे IPhone पर 12 घंटे की बात करते हैं।

Comments

मैं तर्क देता हूं कि यह प्रश्न "... जैसे एंड्रॉइड फोन में अन्य प्लेटफार्मों / फोन की तुलना में बैटरी जीवन को इतना भयावह है" जैसे पूरी तरह से निराधार दावे करता है। बस सच नहीं है।

— allquixotic

जोड़ना चाहेंगे कि आपका पहला लिंक संदिग्ध गुणवत्ता का IMHO है: बेंचमार्क फाइलें चली गई हैं, और एक टिप्पणीकार ने लिंक के पोस्टर की राय को अस्वीकार कर दिया है। असंगत स्रोतों और व्यक्तिपरक बयानों की कमी के कारण यह पद पक्षपाती लगता है।

— डॉकटोरो रीचर्ड

वैसे पहला टिप्पणीकार एक तरह का अधिकार है। विस्तृत परीक्षण के बिना सभी उत्तर पक्षपाती होंगे। मैं इस बात से सहमत हूं कि एंड्रॉइड फोन की बैटरी लाइफ काफी भयानक होती है, लेकिन यह निश्चित रूप से वीएम के कारण नहीं है जैसा कि कई लोगों ने उल्लेख किया है।

— इगोर :ordaš

जल्द ही यह सारी जानकारी किसी भी तरह से एंड्रॉइड में एआरटी रनटाइम के आने से बाहर हो जाएगी।

— मार्क लोपेज

Answer 3

हां, यह बिजली की बढ़ी हुई खपत से संबंधित है - अमूर्त की परतें ऐसा करेंगी। यह गति में भी कमी लाता है (उसी सिक्के के विपरीत - यदि किसी चीज में अधिक ओवरहेड है तो उसे प्रदर्शन करने में अधिक समय लगेगा और इस प्रकार अधिक सीपीयू का उपयोग करना होगा)। अगर मैं सही ढंग से समझता हूं कि एनडीके क्या करता है इसके फायदे में से एक है - विशिष्ट कोड लिखकर विशिष्ट प्रोसेसर के लिए स्पीडअप की अनुमति दें।

कहा कि ज्यादातर नौकरियों के लिए, मुझे लगता है कि वीएम को चलाने के "शक्ति संबंधी" ओवरहेड्स अन्य विचारों से बौने होंगे - अधिकांश कार्यक्रमों के लिए स्क्रीन और रेडियो का उपयोग अधिकांश बिजली की खपत करेगा।

Comments

तुम सही हो। Oled स्क्रीन पर काले इंटरफ़ेस तत्वों का उपयोग करते हुए AEven ज्यादातर मामलों में NDK बनाम SDK के साथ बड़ा पावर सेवर होगा।

— इगोर :ordaš

Answer 4

अन्य सभी पोस्टरों के संबंध में, मेरा मानना ​​है कि यहाँ जो मायने रखता है वह यह नहीं है कि C / C ++ / Java मौजूद है बल्कि क्या अनुप्रयोग कर रहे हैं।

चूंकि बिजली की खपत सीधे प्रसंस्करण के साथ होती है, इसलिए मैं खुद से पूछूंगा कि प्रसंस्करण एक कार्यक्रम क्या करेगा।

कहते हैं कि आप संख्याएँ जोड़ रहे हैं। कहते हैं कि आप 2.000.000 तक पहुँचने तक एक अनंत लूप पर 2 जोड़ रहे हैं। दो सवाल उठते हैं:

1. इसे कैसे लागू किया जाता है: क्या यह फॉर-लूप है? क्या यह थोड़ी देर का लूप है? (क्या यह गोटो / लेबल हैक है?)
2. कोड को कैसे ऑप्टिमाइज़ किया जा रहा है।

ये दो प्रश्न अंततः परिभाषित करते हैं कि प्रोसेसर को कितने ऑपरेशन करने की आवश्यकता है और आखिरकार, एक उपकरण कितना बिजली का उपयोग करता है। यह कहा जा रहा है, वर्चुअलाइज्ड वातावरण चलाने का "ओवरहेड" जावा के द्वारा पूरे कार्यक्रम में किए गए पिछले अनुकूलन के कारण नगण्य हो सकता है, लेकिन फिर, यह सब इस बात पर निर्भर करता है कि आवेदन क्या कर रहा है।

Answer 5

हाँ।

आभासी मशीनें 'सब कुछ दो बार करती हैं', और जरूरी नहीं कि कुशलता से हो। इसलिए, वे 'वास्तविक मशीन' के समान निर्देशों को संसाधित करने के लिए कम से कम दो बार अधिक शक्ति का उपयोग करेंगे। एक वर्चुअल मशीन की उपस्थिति चीजों को धीमा कर देती है और अधिक शक्ति का उपयोग करती है। मूल रूप से, iOS और WIndows जैसे OS सब कुछ तेज़ी से और कम बिजली की खपत के साथ करेंगे।

यह स्क्रीन संक्रमण, पेज लोडिंग, नेविगेशन, जैसी चीजों में वास्तविक अंतर का अनुवाद करता है। वर्तमान में Im एंड्रॉइड (VM) और विंडोज फोन की तुलना कर रहा है, और यहां तक ​​कि एक धीमी प्रोसेसर (1GHz बनाम 1.6GHz) के साथ, विंडोज एंड्रॉइड को एक ही तरह के कार्यों को करने से काफी बेहतर है।

हालांकि, ज्यादातर लोगों का ध्यान आकर्षित करता है जब वे एक ऐप इंस्टॉल करते हैं और अचानक उनकी बैटरी अधिक तेजी से उपयोग हो जाती है। वर्चुअल मशीन के कारण थॉट्स वास्तव में नहीं है, लेकिन एक ऐसा ऐप जो संसाधनों का उपयोग करता है।

एक वर्चुअल मशीन OS, पोर्टेबिलिटी के पूरे कारण, एक OS को आधार बनाने के लिए एक अच्छा कारण नहीं है। क्या आप लोगों को अपनी पसंदीदा वास्तुकला के साथ फोन खरीदते और एंड्रॉइड का उपयोग करते हुए देखते हैं क्योंकि यह पोर्टेबल है? क्या आप लोगों को उच्च प्रदर्शन और विश्वसनीयता देने और अपने गैर-एंड्रॉइड फोन पर एंड्रॉइड डालते हुए देखते हैं? लोग कम लागत वाले उपकरणों में पोर्टेबिलिटी के लिए प्रदर्शन को अव्यवहारिक बनाने के लिए एंड्रॉइड फोन, या विंडोज फोन, या आईफोन आदि खरीदते हैं। यह एक अच्छा विचार था जो विफल हो गया।