एंड्रॉइड टाइमर जो डिवाइस सो रहा है

Question

मैं एक स्पोर्ट्स ऐप लिख रहा हूं जिसे तिमाही/आधा/अवधि के विलुप्त समय को ट्रैक करने की आवश्यकता है। बीतने वाले समय को दूसरे के लिए सटीक होना चाहिए। गेम घड़ी को चलाने के लिए जारी रखना आवश्यक है भले ही उपयोगकर्ता बिजली बटन दबाकर डिवाइस को नींद मोड में स्पष्ट रूप से रखे।

इस पर मेरा पहला प्रयास Handler.postDelayed() का उपयोग कर घड़ी सुनिश्चित करना है कि "घड़ी" एक स्क्रीन टाइमआउट द्वारा नहीं रोका गया था कि हर 200 मि.से और WindowManager.LayoutParms.FLAG_KEEP_SCREEN_ON टिक्स को गति प्रदान करने शामिल किया गया। लेकिन मुझे जल्द ही पता चला कि डिवाइस को मैन्युअल रूप से सोने के लिए पावर बटन दबाकर इस दृष्टिकोण को बाधित करना संभव था। इसके अलावा, PostDelayed() दृष्टिकोण कुछ घड़ी बहाव का अनुभव कर रहा है, जाहिर है कि रन() विधि में बिताए गए समय का परिणाम। वास्तविक संख्याएं अभी भी सटीक हैं, लेकिन गठबंधन होने की बजाय, उदाहरण के लिए, 5 सेकंड सीमाओं पर जिन्हें उपयोगकर्ताओं द्वारा आसानी से समझा जाता है - शामिल टाइमर बहाव करना शुरू करते हैं, जिसके परिणामस्वरूप कुछ समझने योग्य उपयोगकर्ता भ्रम होता है।

अनुसंधान के एक बिट के बाद मैंने सेवाओं, java timers, AlarmManager प्रयोग करने के लिए techiques पाया, और PartialWakeLock टाइमर लागू करने के लिए। स्वयं द्वारा सेवाएं सोने के लिए जाने वाली डिवाइस से जुड़ी समस्या का समाधान नहीं करेंगे। जावा टाइमर, सेवाओं की तरह, सोने के लिए डिवाइस के साथ समस्या का समाधान नहीं करते हैं। अलार्ममेनगर एक अच्छा दृष्टिकोण की तरह प्रतीत होता है, लेकिन मुझे चिंता है कि यह अलार्ममेनगर का उचित उपयोग नहीं है (यानी, अलार्म के बीच बहुत कम अंतराल)। पार्टियलवेक लॉक का उपयोग करना भी आशाजनक दिखता है, लेकिन स्वयं ही यह घड़ी-बहाव की समस्या का समाधान नहीं करता है।

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

धन्यवाद,

रिच

Answer 1

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

यह पता चला मैं SystemClock.uptimeMillis() उपयोग कर रहा था जब मैं SystemClock.elapsedRealtime() उपयोग किया गया है। 2 के बीच का अंतर सूक्ष्म है, लेकिन महत्वपूर्ण है।

आप उम्मीद कर सकते हैं, मेरे समाधान postDelayed के लिए कॉल के बीच अवधि अर्जित होने के कारण बीता हुआ समय का ट्रैक रखता है() - अर्थात, बीता हुआ समय = elapsedTime + lastClockInterval। जैसा ऊपर बताया गया है, मूल कार्यान्वयन अपटाइममिलिस() का उपयोग किया गया। javadoc reveals that uptimeMillis() की सावधानीपूर्वक पढ़ने में "गहरी नींद" में व्यतीत समय शामिल नहीं है, उदाहरण के लिए, जब उपयोगकर्ता पावर बटन दबाता है। लेकिन elapsedRealtime() विधि में "गहरी नींद" मोड में बिताए गए समय शामिल हैं। गहरी नींद चक्रों में समय ट्रैक करने के लिए आवश्यक सभी को अपटाइम मिलिस()elapsedRealtime() के उपयोग को प्रतिस्थापित करना था। सफलता! अलार्ममेनगर, आंशिक WakeLock, या कुछ भी काफी जटिल बनाने के लिए कोई ज़रूरत नहीं है। अनुमोदित, इन तरीकों का अभी भी उपयोग किया गया है, लेकिन जब वे एक सरल समय-समय पर घड़ी या टाइमर लागू करते हैं तो वे अधिक हो जाते हैं।

पोस्टडेलेड() प्रोसेसिंग से जुड़े गैर-शून्य निष्पादन समय के कारण घड़ी-बहाव के साथ आने वाली अगली समस्या है। मुझे आशा है कि प्रसंस्करण करने के लिए धागे को फैलाने से इस समस्या को हल किया जाएगा, जिससे पोस्टडेलेड() को अतुल्यकालिक कॉल की नकल करने के लिए कम या कम अनुमति मिल जाएगी। पोस्टडेलेड() देरी समय को ध्यान में रखना होगा पोस्टडेलेड() में बिताए गए समय को ध्यान में रखना। मैं अपने परिणाम पोस्ट करूंगा।

मेरी एक जांच के दौरान, मैंने खुद को CommonsWare Warescription पर इलाज किया। हालांकि मैंने इस समस्या के लिए इस स्रोत से सीधे किसी भी विचार का उपयोग नहीं किया है, मुझे लगता है कि यह भविष्य के लिए मेरे एंड्रॉइड जाने-माने सूचना स्रोत होने जा रहा है। मुझे अपने दिन की नौकरी के माध्यम से एक O'Reilly सदस्यता मिली है, लेकिन मुझे कम से कम उतना अच्छा होना चाहिए, अगर बेहतर नहीं है, तो एंड्रॉइड विकास के बारे में जानकारी का स्रोत O'Reilly संसाधनों के रूप में। और मैंने ओ'रेली सफारी संसाधनों को बहुत अच्छा पाया है। दिलचस्प ...

चीयर्स, रिच