कोरलोकेशन का उपयोग करते समय बैटरी नाली महत्वपूर्ण स्थान निगरानी और कोरब्लूथूट

Question

हमने पृष्ठभूमि में चलने वाले एक एप्लिकेशन को जारी किया है और CoreBluetooth & CoreLocation का उपयोग अपने पार्किंग स्थान को स्वचालित रूप से सहेजने के लिए करता है।

एक उच्च स्तरीय हमारे एप्लिकेशन सिर्फ एक CoreBluetooth डिस्कनेक्ट घटना के लिए लग रहा है और जब तक हम एक स्थान फिक्स (सटीकता < = 10 मी) या 3 मिनट अधिकतम समय मिलता GPS चालू करता है पर (यह हो सकता है जब आप एक भूमिगत पार्किंग में पार्क कोई जीपीएस कवरेज के साथ)। इसके बाद हम अपने ऐप को समाप्त करने वाली प्रणाली की स्थिति में स्वचालित रूप से हमारे एप्लिकेशन को फिर से लॉन्च करने के लिए महत्वपूर्ण स्थान निगरानी का उपयोग करते हैं।

हमारे विकास के दौरान हमने कभी भी बैटरी नाली समस्या को नहीं देखा, हालांकि हमारे 75% उपयोगकर्ता कहते हैं कि वे एक महत्वपूर्ण बैटरी नाली देखते हैं। हमारे बैकर्स के 10% ने मतदान का जवाब दिया, इसलिए यह निर्धारित करना मुश्किल है कि टूटने का प्रतिनिधि कैसा है, लेकिन यह हमारे उपयोगकर्ताओं का एक बड़ा प्रतिशत है। http://www.findmycarsmarter.com/forum/viewtopic.php?f=4&t=30

हमने फिर एक अद्यतन जारी किया जिसने उपयोगकर्ताओं को महत्वपूर्ण स्थान निगरानी अक्षम करने की अनुमति दी और 60% कहते हैं कि महत्वपूर्ण स्थान निगरानी अक्षम करने से नाली दूर हो जाती है। http://www.findmycarsmarter.com/forum/viewtopic.php?f=4&t=42

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

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

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

एक पोंछे 5.0.1 आईफोन 4 एस पर केवल इन दो ऐप्स के साथ सीटीएम 1 & एफएमसी स्थापित हम अंततः नाली राज्य में प्रवेश करने में सक्षम थे। दिलचस्प बात यह है कि नाली की समस्या एक पोंछे डिवाइस पर हमारे सामान्य डिवाइस पर बहुत कम होती है। दुर्भाग्य से हमने केवल कुछ बार नाली राज्य देखा और नाली को विश्वसनीय रूप से पुन: पेश करने में सक्षम होने के बिना हमारे पास काम करने के लिए एक अच्छा नियंत्रण राज्य नहीं है।

हमने ऐप्पल के साथ एक बग रिपोर्ट दायर की है और एक तकनीकी सहायता घटना खोला है, लेकिन शायद स्टैकओवर समुदाय कुछ अंतर्दृष्टि भी प्रदान कर सकता है। हम एफएमसी http://www.findmycarsmarter.com/files/FMC.zip

On Going into the Background 
    [btleManager stopScan]; 
    [locationManager stopUpdatingLocation]; 
    [locationManager stopUpdatingHeading]; 
    [locationManager startMonitoringSignificantLocationChanges]; 

On Re-entering Foreground 
    [locationManager stopMonitoringSignificantLocationChanges]; 
    [locationManager startUpdatingLocation]; 
    [locationManager startUpdatingHeading];   
    [btleManager scanForPeripheralsWithServices:nil options:nil]; 
On didUpdateToLocation 
    //do nothing 
On didUpdateHeading 
    //do nothing 
On centralManagerDidUpdateState 
    [btleManager scanForPeripheralsWithServices:nil options:nil]; 
On didDiscoverPeripheral 
    [btleManager connectPeripheral:device options:nil]; 
On didConnectPeripheral 
    //update log 
On didDisconnectPeripheral 
    //initiate reconnect 
    [btleManager connectPeripheral:device options:nil]; 

5,1 बीटा में 5.0.1 & में इस समस्या को दोनों को देखा है 3.

CTM1 http://www.findmycarsmarter.com/files/CTM1.zip

On Going into the Background 
    [locationManager stopUpdatingLocation]; 
    [locationManager stopUpdatingHeading]; 
    [locationManager startMonitoringSignificantLocationChanges]; 

On Re-entering Foreground 
    [locationManager stopMonitoringSignificantLocationChanges]; 
    [locationManager startUpdatingLocation]; 
    [locationManager startUpdatingHeading]; 
On didUpdateToLocation 
    //do nothing 
On didUpdateHeading 
    //do nothing 

आप किसी भी कोडिंग गलतियों को देखते हैं खाते हो सकती है कि नाली के लिए कृपया हमें बताएं।

एक अन्य प्रश्न हमारे पास है, अगर हम दोनों जीपीएस & महत्वपूर्ण स्थान निगरानी का उपयोग कर रहे हैं, तो stopMonitoringSignificantLocationChanges पर कॉल करने का कोई कारण है? क्षेत्र नमूना कोड को देखते हुए वे stopMonitoringSignificantLocationChanges & startLocationUpdate अग्रभूमि में प्रवेश करने और stopLocationUpdate & startMonitoringSignificantLocationChanges पृष्ठभूमि में प्रवेश करने पर कॉल करते हैं, लेकिन मुझे आश्चर्य है कि यह आवश्यक/अनुशंसित/आवश्यक है या नहीं?

अद्यतन:

हम साथ Apple डेवलपर तकनीकी सहायता की पुष्टि की है दोनों जीपीएस & महत्वपूर्ण स्थान की निगरानी है कि जीपीएस अद्यतन सक्षम करने से पहले महत्वपूर्ण स्थान की निगरानी को बंद करने के बारे में हमारी अनुक्रम सही है का उपयोग कर अनुप्रयोगों के लिए कि।

हमने यह भी पुष्टि की है कि 5.1 फ्रेमवर्क के खिलाफ एक पुनः संकलित खोज माई कार स्मार्टर एप्लिकेशन के साथ जीएम 5.1 & में नाली की समस्या अभी भी देखी जा सकती है।

अद्यतन:

ऐसा लगता है कि इस मुद्दे की तरह जब हमारे एप्लिकेशन एक महत्वपूर्ण स्थान की निगरानी घटना के जवाब में पृष्ठभूमि से शुरू की है शुरू हो रहा है। हम वास्तव में हमारे नमूना कोड में इस परिदृश्य को सही तरीके से संभाल नहीं पाते हैं, लेकिन हम अपने वास्तविक ऐप में करते हैं।

नमूना कोड में, पृष्ठभूमि पुन: लॉन्च पर हम स्थान अपडेट चालू कर देंगे और चूंकि कोई एप्लिकेशन नहीं है DidEnterBackground कॉल, जीपीएस छोड़ा जाएगा।

हमारे ऐप में हम यह देखने के लिए जांच करते हैं कि क्या हमें UIAplplicationLaunchOptionsLocationKey ध्वज की तलाश करके पृष्ठभूमि से लॉन्च किया गया था, यदि हम महत्वपूर्ण स्थान निगरानी शुरू करते हैं, अन्यथा हम अग्रभूमि में लॉन्च किए गए थे और हम स्थान अपडेट करना शुरू कर देते हैं।

ऐप्पल हमारे पास वापस आ गया और कहा कि महत्वपूर्ण स्थान निगरानी के उपयोग को Info.plist में UIBackgroundModes सरणी में स्थान सेट की आवश्यकता नहीं है। हमने इस प्रविष्टि को हटा दिया और ऐसा प्रतीत होता है कि बैटरी नाली की स्थिति अब हिट नहीं हुई है। UIBackgroundModes सूची में हमारे पास अभी भी ब्लूटूथ-केंद्र है। फिलहाल हम अस्पष्ट हैं कि यह क्यों मदद करता है। हम इसे बेहतर समझने में हमारी सहायता के लिए कुछ और प्रयोग चलने जा रहे हैं। अगर किसी के पास कोई सुझाव है तो कृपया हमें बताएं।

Answer 1

दिन के अंत में, एप्पल के UIBackgroundModes से स्थान निकालने का सुझाव हमारे बैटरी समाप्ति के समस्या का समाधान हो।

क्रम अभी भी पृष्ठभूमि में स्थानों आने के लिए हमें साथ [locationManager startLocationUpdates] & [locationManager stopLocationUpdates] कॉल रैप करने के लिए किया था:

[[UIApplication sharedApplication] beginBackgroundTaskWithExpirationHandler]; 
[[UIApplication sharedApplication] endBackgroundTask:]; 

Answer 2

आप किसी भी दोहराव सिग्नल ध्वनि का उपयोग कर ऐप की स्थिति डीबग कर सकते हैं। बस यह सुनिश्चित करें कि आपने इस परीक्षण के लिए पृष्ठभूमि मोड आवश्यकताओं में 'नाटकों ऑडियो' नहीं रखा है। यदि आपका ऐप चल रहा है - तो आप यह आवाज सुनेंगे, यहां तक ​​कि पृष्ठभूमि पृष्ठभूमि में भी है। यदि ऐप निलंबित कर दिया गया है - तो आप कुछ भी नहीं सुनेंगे। यह पता लगाने के लिए शायद सबसे आसान तरीका है कि ऐप ठीक तरह से निलंबित नहीं है।

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

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

इसके अलावा, अपने सभी तृतीय पक्ष कोड और libs की जांच करें - शायद उनमें से कुछ जीपीएस बदलते हैं और इसे किसी चीज़ के लिए उपयोग करते हैं। अधिकतर भयावह, लेकिन विश्लेषणात्मक और विज्ञापन लक्ष्यीकरण उद्देश्यों के लिए हो सकता है।

Answer 3

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

[locationManager stopUpdatingLocation];

फिर अपने आवश्यकता के अनुसार के बाद तो, तदनुसार शुरू

धन्यवाद