एंड्रॉइड में ओएस / उपयोगकर्ता द्वारा गेम क्रैश / मार पर फ़ाइल ऑपरेशन (ओं) की विफलता


13

गेम / ऐप इंटरनल स्टोरेज में एक फाइल पर निश्चित अंतराल के बाद मेरा गेम अपनी स्थिति बचाता है। जब मेरा गेम उपयोगकर्ता या ओएस द्वारा क्रमशः मारा जाता है या दुर्घटनाग्रस्त हो जाता है, तो हम उस फ़ाइल पर वर्तमान गेम स्थिति लिखते हैं। फिक्स अंतराल के बाद फ़ाइल लेखन ठीक काम कर रहा है, लेकिन जब ओएस या उपयोगकर्ता द्वारा गेम को क्रैश / मार दिया जाता है, तो फ़ाइल लेखन ऑपरेशन विफल हो जाता है। ऑपरेशन की विफलता के परिणामस्वरूप अपूर्ण गेम स्थिति या खाली गेम स्थिति होती है अर्थात फ़ाइल पर कोई डेटा नहीं लिखा जाता है। मैंने एंड्रॉइड सेवा का उपयोग करते हुए कई समाधानों की कोशिश की है, यदि यह सेवा है तो ऐप के साथ नॉन स्टिकी सेवा को मार दिया जाता है। दूसरी ओर यदि सेवा STICKY है तो इसे फिर से शुरू किया जाता है लेकिन इरादा जो सेवा के साथ शुरू में जुड़ा हुआ था वह शून्य या नया है।

सवाल यह है कि जब मैं अपना गेम / ऐप उपयोगकर्ता / ओएस द्वारा मार दिया जाता है, तो मैं अपने डेटा को पूरी तरह से आंतरिक भंडारण में कैसे बचा सकता हूं?


आप अपने SIGTERMs और अपने SIGKILLs को संभाल लेंगे (खैर शायद SIGKILLs नहीं है, Android शायद SIGTERM का उपयोग कर रहा है)। (पूर्ण उत्तर के लिए शोध / लिखने का समय नहीं है लेकिन यह मूल विचार है।)
जॉन हैमिल्टन

2
@ जोहान हैमिल्टन SIGKILL को परिभाषा के द्वारा नियंत्रित नहीं किया जा सकता है।
डार्कहोग

@Darkhogg, एकता में नहीं, यह सुनिश्चित है। (मैंने इस विशिष्ट उद्देश्य के लिए एक परियोजना के लिए एक बिंदु पर लिनक्स कर्नेल को बदल दिया और यह निश्चित रूप से कार्यक्रमों को SIGKILL को संभालने के लिए संभव है)
जॉन हैमिल्टन

जवाबों:


20

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

सहेजें:

  • यदि कोई फ़ाइल मौजूद नहीं है, तो फ़ाइल A पर स्थिति लिखें
  • यदि A मौजूद है, तो B को लिखें
  • यदि A और B दोनों मौजूद हैं, तो खोजें कि कौन सा पुराना है, इसे हटा दें, और फिर उस एक को लिखें

भार:

  • यदि A और B दोनों मौजूद हैं, तो दोनों का नया लोड करने का प्रयास करें। यदि वह विफल हो जाता है (क्योंकि फ़ाइल अपूर्ण या भ्रष्ट है), तो उसे हटा दें और दूसरे को लोड करें
  • यदि केवल एक ही मौजूद है, तो इसे लोड करें
  • यदि दोनों भ्रष्ट हैं, तो उपयोगकर्ता को सूचित करें कि उनकी बचत स्थिति अपरिवर्तनीय थी (जैसे कि आपके पास संभवतः पहले से ही है)

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

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


धन्यवाद MrCranky यह मेरी समस्या का आंशिक समाधान है कि मैं ऐप / गेम को मारने से ठीक पहले पिछले सत्र का डेटा कैसे बचा सकता हूं? उदाहरण के लिए, उसने ऐप खरीद और ऐप को मार डाला।
फैसल इमरान

12
आपको दो फ़ाइलों की भी आवश्यकता नहीं है। बी को लिखें, यदि और केवल अगर लेखन सफल रहा, तो ए हटाएं और बी का java.nio.file.Files.move(Path source, Path target, CopyOption... options)नाम बदलकर ए करें। नामकरण और ओवरराइटिंग परमाणु ऑपरेशन के रूप में कर सकते हैं।
पॉलीग्नोम

6
@ पॉलीग्नोम: ध्यान दें कि बिजली की विफलता के मामले में यह हमेशा आपको अपेक्षित गारंटी प्रदान नहीं करेगा, जब तक कि आप sync()फ़ाइल ए पर ले जाने से पहले फ़ाइल बी पर कॉल नहीं करते हैं (तब भी पूरी गारंटी नहीं है, लेकिन sync()यह काफी अच्छा है)।
डायट्रीच एप

1
@FaisalImran महत्वपूर्ण ऑपरेशन के बाद डेटा को सहेजें, उदाहरण के लिए, IAP के बाद। अगर फोन बंद होने से ऑपरेशन बाधित होता है, तो मुझे लगता है कि यह किसी भी व्यक्ति से कभी भी पैसे नहीं लेगा। लेकिन सिर्फ मामले में, आप कुछ खरीदने के प्रयास के रूप में किसी प्लेटफ़ॉर्म पर खरीदारी में उसके खाते के डेटा को सहेजना चाह सकते हैं। फिर बाद में आप अपनी कमाई की तुलना उस डेटा से कर सकते हैं और देख सकते हैं कि क्या इस व्यक्ति ने वास्तव में कुछ खरीदा है। और फिर उसके लिए इस सुविधा को ऑनलाइन सेवा के माध्यम से खोलें जो आप सभी डेटा को बचाने के लिए उपयोग कर रहे हैं। यदि आप IAP के लिए स्थानीय बचत का उपयोग कर रहे हैं, तो यह इस समस्या से भी बदतर है।
उम्मीदवार चंद्रमा _Max_

1
अंत में, हालांकि यह आपकी सभी समस्याओं को हल नहीं कर सकता है, मैं कहूंगा कि आपकी समस्या पूरी तरह से हल नहीं है। आप दोनों का समर्थन नहीं कर सकते हैं "उपयोगकर्ता किसी भी समय मेरे ऐप को मार सकता है" और "कोई भी डेटा कभी भी नहीं खोना चाहिए" क्योंकि किसी घटना के बाद हमेशा एक खिड़की होगी लेकिन इससे पहले कि यह स्टोर करने के लिए जारी रखा गया है जहां उपयोगकर्ता एप्लिकेशन को मार सकते हैं और डेटा खो सकते हैं।
श्री क्रानिक

3

जब वे पृष्ठभूमि में होते हैं, तो Android केवल ऐप्स को मारता है। क्या ऐप के बैकग्राउंड में होने पर आपके गेम डेटा को वास्तव में अपडेट करने की आवश्यकता है, या ऐप के अग्रभूमि में लौटने तक क्या आप डेटा अपडेट करना बंद कर सकते हैं? आप मल्टीप्लेयर गेम में भी अपडेट्स को स्थगित करने में सक्षम हो सकते हैं, यदि आप घटनाओं के इतिहास या यहां तक ​​कि वर्तमान स्थिति को भी पकड़ सकते हैं जब ऐप अग्रभूमि में वापस आ जाता है। यह कुछ ऐसा है जिसे आपको सीपीयू, नेटवर्क और बैटरी दक्षता के लिए वैसे भी करने पर ध्यान देना चाहिए।

यदि उपयोगकर्ता आपके ऐप को मारता है, तो चल रही सेवाओं को कॉल प्राप्त करना चाहिए onTaskRemoved। मुझे नहीं पता कि अगर आप इस विधि में बहुत प्रसंस्करण करने की कोशिश करते हैं तो क्या होगा। मुझे उम्मीद है कि अगर यह एक निश्चित समय के भीतर वापस नहीं आता है, तो एंड्रॉइड kill -9आपका ऐप होगा ।


ऐप को बैकग्राउंड में अपडेट करने की ज़रूरत नहीं है, लेकिन ऐप को बैकग्राउंड में जाने या नष्ट होने से पहले अपने डेटा यानी जोंस फाइल को सेव करना होगा।
फैसल इमरान

आप सही हैं ऑनस्क्रीमेड विधि कॉल करेगी लेकिन फ़ाइल को सहेजने के लिए आवश्यक समय अधिक है या हम कह सकते हैं कि गणना का समय बड़ा है। जब उपयोगकर्ता ऐप को मार देगा तो यह विधि बंद हो जाएगी।
फैसल इमरान
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.