2015-09-28 4 views
6

मैं आईओएस 9.0 एसडीके & एआरसी के साथ एक्सकोड 7.0 का उपयोग कर रहा हूं, आईओएस 9 के साथ आईफोन 5 एस पर किए गए सभी प्रोफाइलिंग/परीक्षण। EDIT: सभी स्क्रीनशॉट के लिए, यह एक ही रन था: मैंने सीधे डीकोड से डीबग निर्माण किया , और उसके बाद मैन्युअल रूप से संलग्न उपकरण। तो स्क्रीनशॉट सभी एक ही परीक्षण रन से हैं। यह स्मृति वृद्धि (प्रति एक्सकोड व्यू) 100% पुनरुत्पादित है।एक्सकोड और उपकरणों मेमोरी उपयोग के बीच बड़ा अंतर क्यों है, और यह ठीक है?

मेरा ऐप ज़िप फ़ाइलों को डाउनलोड करता है, उन्हें अनपैक करता है, और उन्हें कैमरा रोल में जोड़ता है। मैंने मेमोरी लीक (यानी गायब CGContextRelease) को प्रोफाइल और पकड़ने के साथ-साथ @autoreleasepool आदि

अनजिपिंग के दौरान, एक्सकोड में मुझे स्मृति उपयोग तेजी से शूटिंग दिखाई देता है, अनजिपिंग खत्म होने तक कभी खत्म नहीं होता है, और मैं इसे समझा नहीं सकता क्योंकि ऐसे उपकरणों में कोई वस्तु नहीं है जिन्हें मैं देख सकता हूं। स्मृति कभी जारी नहीं होती है (प्रति एक्सकोड की मेमोरी व्यू)। मेरे परीक्षण चलाने के अंत में मैं 236 एमबी का उपयोग करता हूं, बिना अनजिपिंग के दौरान कोई स्मृति चेतावनी नहीं। अगर मैं इंस्ट्रूमेंट्स आवंटन उपकरण का उपयोग करता हूं, तो मुझे 50.2 एमबी ढेर और अज्ञात वीएम का उपयोग किया जाता है। यह एक बड़ा अंतर है!

मैंने सोचा मान लेते हैं कि [UIImage imageNamed: इसके लिए जिम्मेदार था (कैशिंग आदि), क्योंकि मैं काफी कुछ एनिमेटेड UIImageViews है, तो मैं समय बिताया मेरे सभी कोड से imageNamed को दूर करने, और बदले imageWithContentsOfFile का उपयोग कर। इससे बिल्कुल मदद नहीं मिली। मैं आईओएस 8 के साथ कैमरे रोल में अनजिप छवियों को जोड़ता हूं: इस तरह के फोटो फ्रेमवर्क: [PHAssetChangeRequest creationRequestForAssetFromImageAtFileURL:[NSURL fileURLWithPath:filePath]]

मैंने उपकरण और वेब लेखों के माध्यम से काफी समय बिताया है लेकिन इसका कोई फायदा नहीं हुआ है। क्या कोई इन सवालों का जवाब दे सकता है?

  1. क्यों एक्सकोड मेमोरी उपयोग & उपकरण के बीच विसंगति - यह सामान्य है?
  2. मुझे लगता है कि इस तरह के ऐप को जारी करने के लिए ये संख्याएं बहुत अधिक हैं, और ऐप स्टोर पर अपलोड करने से पहले मुझे इसे बेहतर बनाना होगा, है ना?
  3. नीचे दिए गए स्क्रीनशॉट को देखकर आप कोई सुझाव दे सकते हैं जहां मैं समस्या की तलाश करना शुरू कर सकता हूं?

आपकी मदद के लिए अग्रिम धन्यवाद। बेशक मैं किसी भी स्रोत-कोड है कि मदद मिलेगी पोस्ट करेंगे, मैं सिर्फ यकीन है कि जहां शुरू करने के लिए नहीं कर रहा हूँ ...

Xcode स्मृति उपयोग 236 एमबी xcode mem usage

उपकरण instruments vm summary

instruments allocation summary

+0

केवल उपकरण आपको काम करने के लिए संख्या देता है। और उपकरण ही एकमात्र उपकरण है जिसका उपयोग आपको लीक और समग्र स्मृति उपयोग की तलाश में करना चाहिए। 50 एमबी एक समस्या की तरह नहीं लगता है ... – Volker

+2

वास्तव में? इसलिए बड़े पैमाने पर 236 एमबी संख्या को अनदेखा करना और नाटक करना ठीक है? मैं थोड़े से ऐसा करने से डरता हूं, इसे गलीचा के नीचे साफ करने जैसा लगता है;) – xaphod

+0

"मैंने सीधे एक्सकोड से डीबग निर्माण किया, और उसके बाद मैन्युअल रूप से जुड़ा हुआ उपकरण" और यह समस्या है। – matt

उत्तर

4

इसका सबसे आम कारण आपकी कॉन्फ़िगरेशन है। डिफ़ॉल्ट रूप से जब आप एक्सकोड में चलाते हैं, तो आप डीबग मोड में बनाते हैं। जब आप इंस्ट्रूमेंट्स में प्रोफाइल करते हैं, डिफ़ॉल्ट रूप से, यह रिलीज बनाता है। आप इसे बदलने के लिए अपनी योजना में अपने रन और प्रोफाइल कॉन्फ़िगरेशन को संशोधित कर सकते हैं।

+0

हाय रॉब, मैं ऊपर अपना प्रश्न अपडेट करूँगा: इस मामले में मैं डीबग कॉन्फ़िगरेशन और संलग्न उपकरणों के साथ मैन्युअल रूप से – xaphod

+0

... और खेद है कि मुझे अपनी आखिरी टिप्पणी में पूछा जाना चाहिए था: क्या आपका मतलब है कि रिलीज बिल्ड पर उपकरण चलाना चाहिए? मैंने सोचा कि मुझे डिबग बिल्ड पर इंस्ट्रूमेंट्स चलाने होंगे। – xaphod

+2

आम तौर पर आप रिलीज बिल्ड पर इंस्ट्रूमेंट चलाते हैं, क्योंकि यही वह शिपिंग है जिसे आप शिपिंग कर रहे हैं। ऑप्टिमाइज़ेशन नाटकीय रूप से प्रदर्शन को प्रभावित कर सकते हैं, इसलिए सीपीयू प्रोफाइलिंग (जो इंस्ट्रूमेंट्स का एक बहुत ही आम उपयोग है) रिलीज में काफी बेकार है। मेमोरी उपयोग * आमतौर पर * नाटकीय रूप से बदलता नहीं है। –

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