MediaPlayer प्रारंभ थ्रेड में प्रारंभिक थ्रेड बनाम सेवा के माध्यम से चल रहा है()

Question

तो, मैं एक अलग थ्रेड में संगीत स्ट्रीम कर रहा हूं। अगर मैं ऐप छोड़ देता हूं (onPause(), onStop() बुलाया जा रहा है, आदि), संगीत चल रहा है, लेकिन आखिरकार - अन्य ऐप्स खोलने और उनके बीच स्विच करने और होम स्क्रीन पर वापस जाने के बाद - मेरा ऐप मारे गए। कोई दुर्घटना नहीं, केवल WIN DEATH और process com.myapp.android has died लॉगकैट में। जाहिर है, संसाधनों को पुनः प्राप्त करने के लिए सिस्टम द्वारा ऐप्स को नष्ट करने के लिए यह वैध है।

मेरा प्रश्न है: क्या मुख्य (यूआई) थ्रेड के थ्रेड ऑफ में सामान चलाना मतलब है कि अब तक सिस्टम की चिंता होने पर अब इसकी प्राथमिकता कम है? मतलब, क्या मैं मीडिया प्लेयर को Service में चलाता हूं और यहां तक ​​कि startForeground() का उपयोग अग्रभूमि में सेवा चलाने के लिए भी किया जा सकता है?

किसी भी विचार या स्पष्टीकरण की सराहना की जाएगी!

संपादित

इसके अलावा, पर सेवाएं प्रलेखन का हिस्सा मुझे confuses। प्रासंगिक भाग में, यह कहा गया है:

सावधानी: एक सेवा अपने होस्टिंग प्रक्रिया- सेवा के मुख्य थ्रेड में चलता है अपने स्वयं के धागे का निर्माण नहीं करता है और एक अलग प्रक्रिया में नहीं चलता है (निर्दिष्ट न किए)। इसका मतलब यह है कि, यदि आपकी सेवा किसी भी CPU गहन कार्य या संचालन (जैसे एमपी 3 प्लेबैक या नेटवर्किंग) को अवरुद्ध करने जा रही है, तो आपको उस कार्य को करने के लिए सेवा के भीतर नया धागा बनाना चाहिए।

मैंने हमेशा मुख्य धागे पर एक सेवा में एमपी 3 प्लेबैक चलाया है और यूआई उत्तरदायी बना हुआ है। अगर मुझे उपरोक्त उद्धरण में अनुशंसित एक अलग थ्रेड में रखा जाना है, तो मैं उस स्थान पर वापस नहीं आऊंगा जहां मैंने शुरू किया था, अर्थात् मीडिया थ्रेडबैक मुख्य धागे से निकलने के साथ, जिससे प्लेबैक की संभावना बढ़ रही है अन्य ऐप्स खोले जाने पर मारे गए हैं, इत्यादि?

Answer 1

मुझे लगता है कि आपके अधिकांश प्रश्न Android documentation on Services में उत्तर दिए गए हैं।

लिंक से:

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

आपके प्रश्न का उत्तर करने के लिए, हाँ, चल एक अलग Thread एक Activity के बंद अग्रभूमि में चल रहे एक Service की तुलना में कम प्राथमिकता दी जाती है जा रहा है, अगर Activity कि Thread रोक दिया गया है शुरू कर दिया/रोक दिया है।

व्यक्तिगत रूप से, मैं इसे Service में करने की अनुशंसा करता हूं, क्योंकि यह Service वर्ग के लिए बिल्कुल बनाया गया है।

संपादित करें:

दिलचस्प, तुम क्या सुझाव है कि मैं क्या पढ़ा है के विपरीत लगता है (सब कुछ संवेदनशील जब Service में धागा का उपयोग नहीं है)। भले ही, यह शायद पृष्ठभूमि धागे में शुरू किया जाना चाहिए।

धागा (एक धागा जिसे आप बनाते हैं) तब तक मर नहीं जाएगा जब तक प्रक्रिया मर जाती है, और ऐसा तब होगा जब रनटाइम निर्णय लेता है कि संसाधनों की आवश्यकता है। Activity की मृत्यु हो सकती है जब वे अग्रभूमि में नहीं हैं, इसलिए उनके Thread को भी नष्ट किया जा सकता है। यदि आपके पास Service अग्रभूमि के रूप में चिह्नित है, तो इसे नष्ट होने की संभावना कम है, और इसलिए, आपको एक ही समस्या नहीं होनी चाहिए।

Answer 2

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

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

Answer 3

मैंने अभी इस उत्तर का हिस्सा कहीं और पोस्ट किया है, लेकिन यह अभी भी प्रासंगिक है।

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

आदर्श रूप से, आपको एक थ्रेड उत्पन्न करना चाहिए जो आपके मीडियाप्लेयर को किसी सेवा से नियंत्रित करता है। इस तरह आप सुनिश्चित करते हैं कि आपका ऐप पृष्ठभूमि में है और कोई अवरुद्ध कॉल (तैयार()/readyAsync() से अलग) आपके ऐप को लटका नहीं है।