2012-02-27 15 views
10

मैं उपकरणों का उपयोग कर कुछ कम स्मृति स्थितियों के माध्यम से काम करने की कोशिश कर रहा हूं। मैं भौतिक मेमोरी फ्री मेमोरी में मेमोरी खपत को कुछ एमबी तक छोड़ सकता हूं, भले ही आवंटन से पता चलता है कि सभी आवंटन लगभग 3 एमबी है और कुल मिलाकर बाइट 34 एमबी है।कम मेमोरी चेतावनी के माध्यम से काम करने के लिए उपकरण का उपयोग

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

वैसे, यह उपकरणों या डीबगर से जुड़े बिना अधिक स्थिर है।

मेरे पास लगभग कोई भी नहीं है (शायद एक सौ बाइट अधिकतम दुर्घटना से पहले)।

जब मैं आवंटन को देखता हूं, तो मुझे केवल बहुत ही प्राचीन वस्तुएं दिखाई देती हैं। और इसकी कुल स्मृति भी बहुत कम है। तो मैं नहीं देख सकता कि मेरा ऐप इन कम स्मृति चेतावनियों को कैसे उत्पन्न कर रहा है।

जब मैं स्टार्ट अप से हीप शॉट्स को देखता हूं, तो मुझे बेसलाइन और सभी ढेर विकास मूल्यों के योग के बीच लगभग 3 एमबी से अधिक दिखाई नहीं देता है।

मुझे यह पता लगाने के लिए क्या देखना चाहिए कि समस्या कहां है? क्या मैं इसे अपने दृश्य नियंत्रक उदाहरणों में से एक के लिए अलग कर सकता हूं, उदाहरण के लिए? या मेरे अन्य उदाहरणों में से एक के लिए?

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

हालांकि, मैं शारीरिक फ्री मेमोरी में एक बहुत ही नियमित (आवधिक) ड्रॉप देख रहा हूं, 43 एमबी से 6 एमबी (एक बार बैक अप 43 एमबी) तक गिर रहा हूं। मैं यह कहने के लिए क्या करना चाहता हूँ। मेरे पास इस ऐप में कोई टाइमर नहीं चल रहा है। (मेरे पास कुछ प्रदर्शन है चयनकर्ता: बाद में:: लेकिन वे इन परीक्षणों के दौरान सक्रिय नहीं हैं।)

मैं एआरसी का उपयोग नहीं कर रहा हूं।

+0

क्या आपको इस के लिए समाधान/स्पष्टीकरण मिला है? मेरे पास एक ही तरह की समस्या है। – mm24

उत्तर

2

जब मैं आपका टेक्स्ट पढ़ रहा हूं, तो मुझे लगता है कि आपके पास कुछ छिपे हुए लीक हो सकते हैं। मैं गलत हो सकता था, लेकिन क्या आप 100% सुनिश्चित हैं कि आपने सभी रिसाव की जांच की है?

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

आशा है कि यह सहायक होगा।

9

"आवंटन" से वीएम ट्रैकर से भौतिक स्मृति और आबंटित स्मृति के बीच अंतर की प्रमुख मतभेद की वजह से है कि कैसे इन उपकरणों काम करते हैं:

  • आवंटननिशान कि आपके ऐप को इंस्टॉल करके करता है मेमोरी आवंटित करने वाले कार्यों में एक टैप (malloc, NSAllocateObject, ...)। यह विधि प्रत्येक आवंटन के बारे में बहुत सटीक जानकारी उत्पन्न करती है, जैसे कोड (ढेर), राशि, समय, प्रकार में स्थिति।नकारात्मकता यह है कि यदि आप प्रत्येक फ़ंक्शन का पता नहीं लगाते हैं (जैसे vm_allocate) कि किसी भी तरह स्मृति को आवंटित करता है, तो आप यह जानकारी खो देते हैं।

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

अदृश्य आवंटन के एक ज्ञात अपराधी CoreGraphics है: जब छवियों decompressing, बिटमैप संदर्भों और की तरह ड्राइंग यह स्मृति का एक बहुत उपयोग करता है। यह स्मृति आमतौर पर आवंटन उपकरण में अदृश्य है। तो यदि आपका ऐप बहुत सारी छवियों को संभालता है तो संभव है कि आप भौतिक स्मृति की मात्रा और कुल आवंटित आकार के बीच एक बड़ा अंतर देखें।

भौतिक स्मृति में स्पाइक्स बड़ी छवियों को डिकंप्रेस्ड, डाउनसाइज किया जा सकता है और फिर केवल कुछ दृश्यों या परत की सामग्री में स्क्रीन रिज़ॉल्यूशन में उपयोग किया जा सकता है। यह सब आपके कोड के बिना UIKit में स्वचालित रूप से हो सकता है।

+0

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

2

आवंटन उपकरण में सुनिश्चित करें कि आपके पास "केवल सक्रिय आवंटन ट्रैक करें" चेक किया गया है। नीचे छवि देखें। मुझे लगता है कि यह वास्तव में क्या हो रहा है यह देखना आसान बनाता है।

enter image description here

2
  1. आप परियोजना पर विश्लेषण चलाने है? यदि कोई विश्लेषण चेतावनी है, तो पहले उन्हें ठीक करें।

  2. क्या आप किसी कोरफॉउंडेशन सामग्री का उपयोग कर रहे हैं? सीएफ विधियों में से कुछ ... अजीब ... ओबीजेसी रनटाइम और मेम प्रबंधन के साथ बातचीत (उन्हें नहीं करना चाहिए, AFAICS, लेकिन मैंने निम्न स्तर की छवि और एवी मैनिप्लेशंस के साथ कुछ अजीब व्यवहार देखा है जहां ऐसा लगता है मेम की तरह कोर एप्लिकेशन प्रक्रिया के बाहर किया जा रहा है - शायद ओएस एप्पल द्वारा इस्तेमाल किया जा रहा है कॉल)

... एनबी: वहाँ भी आईओएस के पिछले संस्करणों में, है, कुछ मेम-लीक के अंदर कर दिया गया? ऐप्पल के सीएफ तरीके। आईआईआरसी उन लोगों में से अंतिम आईओएस 5.0 में तय किया गया था।

  1. (Stackoverflow के पार्सर बेकार: मैं आपके द्वारा लिखा गया "3" नहीं "1") आप कुछ/बड़े आकार CALayer उदाहरणों (या, जैसे में एक कस्टम drawRect विधि तटरक्षक * तरीकों के साथ UIView के की एक बड़ी संख्या के साथ कर रहे हैं एक UIView)

... एनबी: मैं सटीक व्यवहार आप ऊपर 2 और 3 की वजह से वर्णन देखा है, या तो सीएफ पुस्तकालयों में, या एप्पल विंडोइंग प्रणाली में जब यह के साथ काम करने की कोशिश करता है छवि डेटा जिसे मूल रूप से सीएफ पुस्तकालयों के अंदर उत्पन्न किया गया था - या जिसे कैलियर में अपना रास्ता मिला।

ऐसा लगता है कि उपकरण सीए/सीजी सिस्टम के अंदर प्रत्यक्ष रूप से स्मृति उपयोग को ट्रैक नहीं करते हैं; यह क्षेत्र थोड़ा जटिल है क्योंकि ऐप्पल सीपीयू और जीपीयू रैम के बीच आगे और पीछे घूम रहा है, लेकिन यह निराशाजनक है कि यादगार उपयोग अभी भी गायब होने पर "गायब हो जाता है" लगता है!


अंतिम सोचा (4. - लेकिन इतना मुझे टाइप नहीं दूँगी कि) - आप उपकरण के अदृश्य आरएचएस उपयोग कर रहे हैं?

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

19

आवंटन और लीक उपकरणों केवल दिखाती हैं, जो वस्तुओं वास्तव में ले, यह नहीं कि उनके अंतर्निहित गैर वस्तु ढांचे (साथ काम किया है बैकिंग स्टोर्स) ले रहे हैं। उदाहरण के लिए, UIImages के लिए यह दिखाएगा कि आपके पास कुछ आवंटित बाइट हैं। ऐसा इसलिए है क्योंकि UIImage ऑब्जेक्ट केवल उन बाइट्स लेता है, लेकिन CGImageRef जिसमें वास्तव में छवि डेटा होता है वह एक वस्तु नहीं है, और इन उपकरणों में इसे ध्यान में नहीं रखा जाता है।

यदि आप इसे पहले से नहीं कर रहे हैं, तो वीएम ट्रैकर चलाने के साथ ही आवंटन उपकरण चलाने पर प्रयास करें। यह आपको आवंटित की जा रही प्रकार की स्मृति का एक विचार देगा। आईओएस के लिए "गंदा मेमोरी", इस उपकरण द्वारा दिखाया गया है, जो आम तौर पर स्मृति चेतावनियों को ट्रिगर करता है। गंदा स्मृति स्मृति है जिसे VM सिस्टम द्वारा स्वचालित रूप से त्याग दिया नहीं जा सकता है। यदि आप बहुत सारे CGImages देखते हैं, तो छवियां आपकी समस्या हो सकती हैं।

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

अंत में, मैं आपको इस लेख को पढ़ने की सलाह देता हूं, जो बताता है कि यह सब कैसे काम करता है: http://liam.flookes.com/wp/2012/05/03/finding-ios-memory/

4

मैं लगभग कोई (एक दुर्घटना से पहले हो सकता है एक सौ बाइट्स अधिकतम) करने के लिए नीचे लीक की है।

मेरे अनुभव में, बहुत छोटे रिसाव भी "खतरनाक" संकेत हैं। असल में, मैंने कभी 4K से बड़ा रिसाव नहीं देखा है, और आमतौर पर लीक जो मैं देखता हूं वह दो सैकड़ों बाइट हैं। फिर भी, वे आमतौर पर खुद को "छिपाने" के पीछे एक बहुत बड़ी स्मृति खो देते हैं।

तो, मेरा पहला सुझाव है: उन लीक से छुटकारा पाएं, भले ही वे छोटे और महत्वहीन हों - वे नहीं हैं।

मैं के बाद से मैं एक NSOperationQueue साथ एक अलग थ्रेड के लिए कुछ आपरेशनों ले जाया गया दुर्घटनाग्रस्त अनुभव करने के लिए शुरू कर दिया है।

क्या कोई मौका है कि आप थ्रेड में ले जाने वाले ऑपरेशन को पल्सिंग पीक के लिए ज़िम्मेदार है? क्या यह एक समय में एक से अधिक बार पैदा हो सकता है?

चोटियों के रूप में, मैं दो तरीकों से देख आप उनके बारे में जा सकते हैं:

  1. उपकरण में समय प्रोफाइलर का उपयोग करें और समझने के लिए कोड को क्रियान्वित कर रहा है, जबकि आप शिखर बढ़ती देख कोशिश;

  2. को चुन कर अपने कोड के कुछ भागों बाहर टिप्पणी (मेरा मतलब है: आपके ऐप्स के संपूर्ण भागों - जैसे, एक बुनियादी/खाली UIViewController, आदि के साथ एक "वास्तविक" नियंत्रक की जगह) और यदि आप इस तरह से अपराधी की पहचान कर सकते हैं ।

मैं इस तरह के एक pulsating व्यवहार कभी नहीं देखा है, तो मैं उसे अपने ऐप्लिकेशन पर या अपने डिवाइस पर निर्भर करता है मान लेते हैं। क्या आपने एक अलग डिवाइस के साथ प्रयास किया है? सिम्युलेटर में क्या होता है (क्या आप चोटी देखते हैं)?

संबंधित मुद्दे