आईओएस ऑटोलायआउट प्रदर्शन समस्या। [NSISEngine ऑप्टिमाइज़]

Question

मुझे एक बहुत ही अजीब समस्या का सामना करना पड़ा है और मैं सोच रहा था, अगर कोई मेरी मदद कर सकता है क्योंकि मैं पूरी तरह से खो गया हूं।

संदर्भ: मैं अपेक्षाकृत सरल पदानुक्रम के साथ एक ऐप विकसित कर रहा हूं। बस कुछ दृश्य नियंत्रक लेकिन बहुत अधिक उच्च-रेज छवियां। उन्हें में कुछ पाठ आदि के साथ प्रस्तुत किया जाता है। पोर्ट्रेट मोड में इसका परीक्षण करते समय स्क्रॉलव्यू आसानी से स्क्रॉल नहीं करता था। ऐसा लगता है कि फ्रेमरेट लगभग 4-5 एफपीएस तक गिर गया। सबसे पहले मैंने सोचा कि यह उच्च-रेज छवियों के कारण था।

लेकिन फिर मैंने आईपैड को लैंडस्केप मोड में बदल दिया और सब कुछ सुचारू रूप से चला गया। चूंकि मेरे पास चित्र और परिदृश्य के लिए एक अलग xib-file है, इसलिए मैंने सोचा कि पोर्ट्रेट-xib में कोई समस्या होनी चाहिए। यह निकला, वहाँ नहीं था। दोनों में एक ही वीसी-क्लास था और इसलिए एक ही कोड का उपयोग करना और दोनों xibs विचारों के आकार और पदों को छोड़कर लगभग समान हैं।

समस्या को कम करने के लिए, मैंने समस्या का कारण बनने के लिए इंस्ट्रूमेंट के टाइमप्रोफाइलर का उपयोग किया। जैसा कि यह निकला, टाइमप्रोफाइलर ने [NSISEngine optimize] पर कुछ कॉल दिखाए (NSLayoutConstraint द्वारा ट्रिगर किया गया)। पोर्ट्रेट मोड में अधिक कॉल थे और उन कॉलों में काफी समय लगा। पेड़ के नीचे मैंने देखा कि पोर्ट्रेट मोड [NSISEngine optimize] में [NSISEngine fixupIntegralizationViolations] कहा जाता है और परिदृश्य में यह नहीं था।

मैंने रूटव्यूवी और एक अन्य जो रूटवीसी द्वारा प्रस्तुत किया गया है, को छोड़कर ऐप से सभी व्यू कंट्रोलर को हटा दिया। प्रस्तुत वीसी में बस कुछ छवियों, बटन और कुछ एनिमेशन शामिल हैं। यह दोनों ओरिएंटेशन के लिए केवल एक xib है और (जैसा कि अन्य सभी भी) ऑटोलायआउट के साथ बाहर रखा गया है।

लेआउट काम करता है क्योंकि यह दोनों ओरिएंटेशन में होना चाहिए और वहां कोई अस्पष्टता नहीं है (जहां तक ​​मैं कह सकता हूं। कम से कम po [[UIWindow keyWindow] _autolayoutTrace] कोई भी नहीं दिखाता है)।

मैंने वीसी की प्रस्तुति प्रक्रिया के टाइमप्रोफाइल का एक स्क्रीनशॉट संलग्न किया है। एक चित्र के लिए और एक परिदृश्य के लिए। जैसा कि आप देख सकते हैं, परिदृश्य में [NSISEngine optimize] पर कॉल केवल एक मिलीसेकंड लेते हैं जबकि चित्र में वे 3000 मिमी से अधिक लेते हैं।

क्या कोई ऐसा है जो मुझे बता सकता है कि ऐसा क्यों है? या शायद यह पता है कि समस्या क्या है यह जानने के लिए मैं क्या कर सकता हूं?

किसी भी मदद की सराहना की जाएगी!

Thx

छवि का एक बड़ा संस्करण के लिए लिंक: link

Answer 1

मैंने इस समस्या पर एक तकनीकी सहायता का अनुरोध दर्ज और अंत में इस सवाल का जवाब मिल गया है, कि यह संभवत: एक बग है। बग रिपोर्ट दायर की गई है। उम्मीद है कि वे जल्द ही इसे ठीक कर देंगे। अगर कोई खबर है तो मैं इस जवाब को अपडेट करूंगा।

Answer 2

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

मैंने इस समस्या पर एक समर्थन टिकट भी खोला है।

अद्यतन:

मुझे मेरी स्थिति में कारण मिला। यह कमी के सेट पीछा कर रहा था:

NSArray *constraints = [NSLayoutConstraint 
         constraintsWithVisualFormat : @"|[sunLabel][monLabel(==sunLabel)][tueLabel(==sunLabel)][wedLabel(==sunLabel)][thuLabel(==sunLabel)][friLabel(==sunLabel)][satLabel(==sunLabel)]|" 
         options : 0 
         metrics : nil 
         views : labelViewsDictionary]; 

यह निर्दिष्ट करता है कि 7 लेबल एक माता पिता को देखने के भीतर सभी शेयर एक ही आकार और सभी माता पिता को देखने की चौड़ाई का विस्तार। मेरा मानना ​​है कि लेआउट की अत्यधिक रिलेशनल प्रकृति ऑटो लेआउट फिट कर रही थी, विशेष रूप से क्योंकि माता-पिता की चौड़ाई चौड़ाई 7 से विभाजित नहीं थी।

इसे हल करने के लिए, मैंने बाधाओं की एक सरणी बनाई जो प्रत्येक लेबल की चौड़ाई निर्दिष्ट करती है और उन बाधाओं को लागू किया। जब डिवाइस अभिभावक परिवर्तन की चौड़ाई को घुमाता है तो मैं वापस जाता हूं और बाधाओं पर लगातार समायोजित करता हूं ताकि मूल दृश्य चौड़ाई के 1/7 वें हो। यह अब अच्छा प्रदर्शन करता है, पॉपओवर लोड करने की प्रक्रिया अब 2000ms के बजाय 300ms से कम लेती है।

Answer 3

मुझे कल आईपैड आईओएस 6.1 डिवाइस में एक ही समस्या थी। ऐप के इंस्ट्रूमेंटिंग ने पाया कि विधि फिक्सअप इंटेग्रलाइजेशन उल्लंघन हर बार लगभग 300 एमएस ले रहा था (लगभग 20 गुना, जो बहुत कुछ है) ऐप को बिल्कुल बेकार बना देता है।

मेरी समस्या जैक कॉक्स टिप्पणियों के समान ही थी, लेकिन मैंने इसे अलग हल किया। मेरी बाधा थी:

@ "एच: | [ऑलबटन] [इनस्टोरबटन (== ऑलबटन)] [ऑनलाइन बटन (== ऑलबटन)] [सॉर्टबटन (50)] |"

मुद्दा यह है कि पेरेंट व्यू यहां पूर्ण आईपैड परिदृश्य चौड़ाई है, इसलिए इस प्रदूषण का गणित प्रत्येक चौड़ाई को इस चौड़ाई को दे रहा था: (1024-50)/3 = 324.6666667।

यह आमतौर पर ऑटोलायआउट में कोई समस्या नहीं है क्योंकि यह बड़ी फ्लोट संख्याओं का ख्याल रखता है और उन्हें सही ढंग से गोल करता है, लेकिन ऐसा लगता है कि आईपैड आईओएस 6 लैंडस्केप में इस संख्या को गोल करने से यूआई को अवरुद्ध करने वाली एक बग ट्रिगर होती है। इसके चारों ओर जाने के लिए मुझे बस इतना करना था कि सॉर्ट बटन को 52 के साथ बदलना है, इसलिए प्रत्येक बटन चौड़ाई अब है: (1024-52)/3 = 324. यह सब कुछ है। अब विधि fixupIntegralization उल्लंघन हर बार लगभग 1ms लेता है।

दिलचस्प बात यह है कि 52 का उपयोग करके यह लैंडस्केप में दशमलव चौड़ाई नहीं देता है, लेकिन यह चित्र में दशमलव संख्या देता है: (768-52)/3 = 238.666667। हालांकि, चित्र में कोई बग नहीं है और ऑटोलायआउट संख्याओं को सही ढंग से गोल करता है।