नमस्ते! मेरा नाम साशा है, मैं टीम में एक iOS डेवलपर हूं जो VKontakte फीड बनाता है। अब मैं आपको बताता हूँ कि हम किस तरह से इंटरफ़ेस के प्रदर्शन को अनुकूलित करते हैं और इससे जुड़ी समस्याओं के बारे में सोचते हैं।
मुझे लगता है कि आप कल्पना कर सकते हैं कि वीके टेप क्या है। यह एक स्क्रीन है जहां आप विभिन्न प्रकार की सामग्री देख सकते हैं: ग्रंथ, स्थिर चित्र, एनिमेटेड GIF, एम्बेडेड तत्व (वीडियो और संगीत)। यह सब आसानी से प्रदर्शित किया जाना चाहिए, इसलिए समाधानों के प्रदर्शन पर उच्च मांग।

अब देखते हैं कि मैपिंग के साथ काम करने के मानक मानक क्या हैं और किन सीमाओं या लाभों को ध्यान में रखा जाना चाहिए।

यदि आप पढ़ने से अधिक सुनना पसंद करते हैं, तो रिपोर्ट की वीडियो रिकॉर्डिंग यहां है ।

सामग्री

1. विवरण और लेआउट की गणना
   1.1। ऑटो लेआउट
   1.2। मैनुअल frame गणना
2. पाठ का आकार गणना
   2.1। UILabel / UITextView / UITextField के आकार की गणना के लिए मानक तरीके
   2.2। NSAttributedString / NSString तरीके
   2.3। TextKit
   2.4। CoreText
3. VKontakte फीड कैसे काम करता है?
4. बेहतर प्रदर्शन कैसे प्राप्त करें
   4.1 प्रदर्शन की समस्याएं क्यों
   4.2। CATransaction.commit
   4.3। रेंडरिंग पाइपलाइन
   4.4। प्रदर्शन के लिए सबसे कमजोर स्थान
5. माप उपकरण
   5.1। धातु प्रणाली ट्रेस
   5.2। हम कोड में प्रदर्शन की कमी को ठीक करते हैं, जबकि एप्लिकेशन चल रहा है

• समस्याओं का अनुसंधान कैसे करें। सिफारिशें
• निष्कर्ष
• जानकारी के स्रोत

1. लेआउट का विवरण और गणना

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

1.1। ऑटो लेआउट

शायद iOS में इंटरफ़ेस बनाने का सबसे लोकप्रिय तरीका Apple के ऑटो लेआउट लेआउट सिस्टम का उपयोग करना है। यह कैसोवेरी एल्गोरिथ्म पर आधारित है, जो बाधाओं की अवधारणा के साथ संयुक्त रूप से जुड़ा हुआ है ।

अभी के लिए, याद रखें कि ऑटो लेआउट का उपयोग करके लागू किया गया इंटरफ़ेस प्रतिबंधों पर बनाया गया है।

दृष्टिकोण की विशेषताएं:

• बाधा प्रणाली एक रैखिक प्रोग्रामिंग समस्या में बदल जाती है ।
• कैसोवेरी सिम्प्लेक्स विधि का उपयोग करके परिणामी अनुकूलन समस्या को हल करता है । इस विधि में घातीय स्पर्शोन्मुख जटिलता है। इसका क्या मतलब है? जैसा कि लेआउट में बाधाओं की संख्या बढ़ जाती है, सबसे खराब स्थिति में, गणना तेजी से धीमा हो सकती है।
• UIView लिए परिणामी frame मान संगत अनुकूलन समस्या का समाधान हैं।

ऑटो लेआउट का उपयोग करने के लाभ:

• सरल मैपिंग पर, रैखिक कम्प्यूटेशनल जटिलता संभव है ।
• यह सभी मानक तत्वों के साथ-साथ हो जाता है, क्योंकि यह Apple की "देशी" तकनीक है।
• बॉक्स के बाहर UIView साथ काम करता है।
• इंटरफ़ेस बिल्डर में उपलब्ध है, जो आपको स्टोरीबोर्ड या XIB में लेआउट का वर्णन करने की अनुमति देता है।
• यह संक्रमण के दौरान भी अद्यतित समाधान की गारंटी देता है। इसका मतलब यह है कि प्रत्येक UIView frame मूल्य हमेशा (!) वास्तविक लेआउट कार्य का एक समाधान है।

अधिकांश प्रदर्शनों के लिए सिस्टम क्षमताएं पर्याप्त हैं। लेकिन भारी मात्रा में सामग्री के साथ टेप बनाने के लिए यह उपयुक्त नहीं है। क्यों?

यह याद रखना महत्वपूर्ण है कि ऑटो लेआउट:

• केवल मुख्य सूत्र में काम करता है । मान लीजिए कि Apple इंजीनियरों ने मेनस्ट्रीम को ऑटो लेआउट समाधान के सिंक्रनाइज़ेशन बिंदु और सभी UIView के फ्रेम वैल्यू के रूप में चुना UIView । इसके बिना, आपको ऑटो लेआउट को एक अलग धागे में गणना करना होगा और मुख्य धागे के साथ मूल्यों को लगातार सिंक्रनाइज़ करना होगा।
• यह धीरे-धीरे जटिल अभ्यावेदन पर काम कर सकता है , क्योंकि यह एक क्रूर बल एल्गोरिथ्म पर आधारित है जिसकी सबसे खराब स्थिति में जटिलता घातीय है।
• IOS 6.0 के साथ उपलब्ध है । अब यह शायद ही कोई समस्या है, लेकिन यह विचार करने लायक है।

निष्कर्ष: ऑटो लेआउट का उपयोग करना संग्रह के बिना या उसके साथ प्रदर्शित करना सुविधाजनक है, लेकिन तत्वों के बीच जटिल संबंधों के बिना।

1.2। मैनुअल frame गणना

दृष्टिकोण का सार: हम सभी frame मूल्यों की गणना खुद करते हैं। उदाहरण के लिए, हम तरीके sizeThatFits लागू करते हैं, sizeThatFits , sizeThatFits । यही है, sizeThatFits में layoutSubviews स्वयं सभी बाल तत्वों की व्यवस्था करते हैं, आकार में हम बच्चे तत्वों और सामग्री के वांछित स्थान के अनुरूप आकार की गणना करते हैं।

यह क्या देता है? हम जटिल गणना को पृष्ठभूमि धारा में स्थानांतरित कर सकते हैं, और अपेक्षाकृत सरल गणना मुख्य धारा में की जा सकती है।

क्या समस्या है? आपको स्वयं गणनाओं को लागू करना होगा, गलती करना आसान है। आपको यह भी सुनिश्चित करने की आवश्यकता है कि बच्चों की स्थिति और आकार आकार में वापस आए परिणाम sizeThatFits ।

स्व-मूल्यांकन उचित है यदि:

• हमने सामना किया है या अनुमान लगाया है कि हम ऑटो लेआउट प्रदर्शन सीमाओं का सामना करेंगे।
• आवेदन में एक जटिल संग्रह है, और एक अच्छा मौका है कि विकसित तत्व इसकी कोशिकाओं में से एक में गिर जाएगा;
• हम पृष्ठभूमि थ्रेड में तत्व के आकार की गणना करना चाहते हैं;
• हम स्क्रीन पर गैर-मानक तत्व प्रदर्शित करते हैं, जिसके आकार को सामग्री या पर्यावरण के आधार पर लगातार पुनर्गठित किया जाना चाहिए।
  

एक उदाहरण है। टूलटिप्स ड्रा करें जो स्वचालित रूप से सामग्री को फिट करने के लिए स्केल करते हैं। इस कार्य में सबसे दिलचस्प हिस्सा यह है कि प्रत्येक टूलटिप में पाठ के दृश्य आकार की गणना कैसे की जाए।

2. पाठ आकार की गणना

इस समस्या को कम से कम चार तरीकों से हल किया जा सकता है, जिनमें से प्रत्येक अपने स्वयं के तरीकों पर निर्भर करता है। और प्रत्येक की अपनी विशेषताओं और सीमाएं हैं।

2.1। UILabel / UITextView / UITextField के आकार की गणना के लिए मानक तरीके

sizeThatFits ( sizeThatFits में डिफ़ॉल्ट रूप से उपयोग किया जाता है) और intrinsicContentSize (ऑटो लेआउट में प्रयुक्त) intrinsicContentSize सामग्री दृश्य सामग्री का पसंदीदा आकार लौटाते हैं। उदाहरण के लिए, उनकी मदद से हम यह पता लगा सकते हैं कि UILabel में लिखे गए पाठ में कितना स्थान UILabel ।

नकारात्मक पक्ष यह है कि दोनों विधियां केवल मुख्य धागे में काम करती हैं - उन्हें पृष्ठभूमि से नहीं बुलाया जा सकता है।

मानक तरीके कब उपयोगी हैं?

• यदि हम पहले से ही sizeToFit या Auto Layout का उपयोग करते हैं।
• जब प्रदर्शन में मानक तत्व होते हैं, और हम कोड में उनका आकार प्राप्त करना चाहते हैं।
• जटिल संग्रह के बिना किसी भी प्रदर्शन के लिए।

2.2। NSAttributedString / NSString तरीके

boundingRect और sizeWithAttributes ध्यान दें। मैं UILabel / UITextView / UITextField की सामग्री का आकार पढ़ने के लिए उनका उपयोग करने की सलाह नहीं देता। मुझे दस्तावेज़ीकरण की जानकारी में कहीं भी यह नहीं मिला कि NSString तरीके और UIView तत्वों के लेआउट तरीके एक ही कोड (समान कक्षाएं) पर आधारित हैं। वर्गों के ये दो समूह क्रमशः अलग-अलग रूपरेखाओं के हैं: फाउंडेशन और यूआईकिट। हो सकता है कि आपको पहले से ही UILabel आकार के लिए बाउंडिंगआरक्ट परिणाम फिट करना था? या क्या आप इस तथ्य से NSString कि NSString इमोजी के आकार को ध्यान में नहीं रखते हैं ? ये समस्याएं हैं जो आपको मिल सकती हैं।

मैं आपको यह भी बताऊंगा कि UILabel / UITextView / UITextField में पाठ खींचने के लिए कौन सी कक्षाएं ज़िम्मेदार हैं, लेकिन अभी के तरीकों पर लौटने UITextField ।

यदि हम हैं तो इसका इस्तेमाल करना।

• हम drawInRect , drawAtPoint या NSString / NSAttributedString अन्य तरीकों का उपयोग करके गैर-मानक इंटरफ़ेस तत्वों को आकर्षित करते हैं।
• हम पृष्ठभूमि स्ट्रीम में तत्वों के आकार पर विचार करना चाहते हैं। फिर, यह केवल उचित रेंडरिंग विधियों का उपयोग करते समय है।
• उदाहरण के लिए, एक मनमाना संदर्भ बनाएं, छवि के शीर्ष पर एक रेखा प्रदर्शित करें।

2.3। TextKit

इस उपकरण में मानक क्लासेस NLayoutManager , NSTextStorage और NSTextContainer । लेआउट UILabel / UITextView / UITextField भी UITextField पर आधारित है।

TextKit बहुत सुविधाजनक है जब आपको पाठ के स्थान का विस्तार से वर्णन करने की आवश्यकता होती है और संकेत मिलता है कि यह किस आकार में घूमेगा:

TextKit का उपयोग करके, आप पृष्ठभूमि कतार में इंटरफ़ेस तत्वों के आकार, साथ ही लाइनों / वर्णों की frame गणना कर सकते हैं। इसके अलावा, रूपरेखा आपको ग्लिफ़ खींचने और मौजूदा लेआउट के भीतर पाठ की उपस्थिति को पूरी तरह से बदलने की अनुमति देती है। यह सब iOS 7.0 और उच्चतर में काम करता है।

TextKit उपयोगी है जब आप की जरूरत है:

• जटिल लेआउट के साथ प्रदर्शन पाठ;
• छवियों पर पाठ आकर्षित करें;
• व्यक्तिगत सबस्ट्रिंग के आकार की गणना करें;
• लाइनों की संख्या गिनें;
• एक UITextView में गणना के परिणामों का उपयोग करें।

मैं फिर जोर देता हूं। यदि आपको UITextView के आकार की गणना करने की आवश्यकता है, तो हम पहले NSLayoutManager , NSTextStorage और NSTextContainer के उदाहरणों को कॉन्फ़िगर करते NSTextContainer , और फिर इन उदाहरणों को संबंधित NSTextContainer पास देते हैं , जहाँ वे लेआउट के लिए ज़िम्मेदार होंगे। केवल इस तरह से हम सभी मूल्यों के पूर्ण संयोग की गारंटी देते हैं।

UILabel और UITextField साथ TextKit का उपयोग न करें! उनके लिए ( UITextView विपरीत) आप NSLayoutManager , NSTextStorage और NSTextContainer कॉन्फ़िगर नहीं कर सकते।

2.4। CoreText

यह iOS में सबसे निचला स्तर का टेक्स्ट टूल है। यह फोंट, पात्रों, लाइनों, इंडेंट के प्रतिपादन पर अधिकतम नियंत्रण देता है। और वह, TextKit की तरह, आपको पाठ के टाइपोग्राफिक मापदंडों की गणना करने की अनुमति देता है, जैसे कि आधारभूत और व्यक्तिगत लाइनों के फ्रेम आकार।

जैसा कि आप जानते हैं, जितनी अधिक स्वतंत्रता, उतनी ही अधिक जिम्मेदारी। और CoreText का उपयोग करके अच्छे परिणाम प्राप्त करने के लिए, आपको इसके तरीकों का उपयोग करने में सक्षम होने की आवश्यकता है।

CoreText अधिकांश वस्तुओं पर संचालन के लिए थ्रेड सुरक्षा प्रदान करता है। इसका मतलब है कि हम विभिन्न थ्रेड्स से इसके तरीकों को कॉल कर सकते हैं। तुलना के लिए, TextKit का उपयोग करते समय, आपको स्वयं विधि कॉल के अनुक्रम के बारे में सोचना होगा।

CoreText का उपयोग किया जाना चाहिए यदि:

• पाठ मापदंडों तक सीधी पहुंच के लिए एक अत्यंत सरल निम्न-स्तरीय एपीआई की आवश्यकता होती है। मुझे तुरंत कहना होगा कि अधिकांश कार्यों के लिए, TextKit की क्षमताएं पर्याप्त हैं।
• व्यक्तिगत लाइनों ( CTLine ) और पात्रों / तत्वों के साथ बहुत काम करना है।
• IOS 6.0 में समर्थन महत्वपूर्ण है।

VKontakte फ़ीड के लिए, हमने CoreText का उपयोग किया। क्यों? बस उस समय जब हमने पाठ के साथ काम करने के बुनियादी कार्यों को लागू किया, TextKit अभी तक नहीं था।

3. VKontakte फीड कैसे काम करता है?

संक्षेप में हम सर्वर से डेटा कैसे प्राप्त करते हैं, लेआउट और डिस्प्ले बनाते हैं।

सबसे पहले, पृष्ठभूमि कतार में किए गए कार्यों पर विचार करें। हम सर्वर से डेटा प्राप्त करते हैं, इसे प्रोसेस करते हैं और बाद में डिस्प्ले का वर्णन करते हैं। इस स्तर पर, हमारे पास अभी तक UIView उदाहरण नहीं हैं, हम केवल अपने घोषणात्मक उपकरण के साथ भविष्य के इंटरफ़ेस के नियमों और संरचना को सेट करते हैं, कुछ हद तक स्विफ्टयूआई के समान है। लेआउट की गणना करने के लिए, हम वर्तमान प्रतिबंधों को ध्यान में रखते हुए पूरे frame गणना करते हैं, उदाहरण के लिए, स्क्रीन की चौड़ाई। हम वर्तमान dataSource ( dataSourceUpdate ) का अद्यतन करते हैं। यहां, पृष्ठभूमि-कतार में, हम चित्र तैयार करते हैं: विघटन करते हैं (अधिक विवरण के लिए प्रदर्शन अनुभाग देखें), छाया, गोल और अन्य प्रभाव आकर्षित करें।

अब मेन कतार में जाएं। dataSourceUpdate प्राप्त dataSourceUpdate को dataSourceUpdate , UITableView में पुनः उपयोग करें, पुन: उपयोग करें और इंटरफ़ेस घटनाओं को संसाधित करें, कोशिकाओं को भरें।

हमारे लेआउट सिस्टम का वर्णन करने के लिए, एक अलग लेख की आवश्यकता होगी, लेकिन यहां मैं इसकी मुख्य विशेषताओं को सूचीबद्ध करूंगा:

• एक घोषणात्मक एपीआई नियमों का एक समूह है जिस पर एक इंटरफ़ेस बनाया गया है।
• बुनियादी घटक एक पेड़ ( nodes ) बनाते हैं।
• बुनियादी घटकों में सरल गणना। उदाहरण के लिए, सूचियों में, हम केवल origin ऑफसेट की गणना करते origin , सभी बच्चों की चौड़ाई / ऊंचाई को ध्यान में रखते हुए।
• मूल तत्व पदानुक्रम में UIView अनावश्यक "कंटेनरों" का निर्माण नहीं करते हैं। उदाहरण के लिए, सूची घटक अतिरिक्त UIView नहीं बनाता है और इसमें बच्चों को नहीं जोड़ता है। इसके बजाय, हम मूल (सूची के लिए) तत्व के सापेक्ष बच्चों की origin ऑफसेट की गणना करते origin ।
• CoreText के साथ निम्न स्तर का पाठ प्रबंधन।

लेकिन इस दृष्टिकोण के साथ भी, प्रदर्शन के मुद्दों के कारण टेप देखने में आसानी नहीं हो सकती है। क्यों?

प्रत्येक कोशिका में nodes का एक जटिल पदानुक्रम होता है। और यद्यपि मूल तत्व अनावश्यक कंटेनरों का निर्माण नहीं करते UIView भी बहुत सारे UIView रिबन में प्रदर्शित UIView । और मेन-कतार में "नोड्स" (बाइंडिंग देखें) के साथ पदानुक्रम को भरने पर अतिरिक्त काम होता है जिससे दूर होना मुश्किल है।

हमने पृष्ठभूमि कतार में अधिक से अधिक कार्यों को स्थानांतरित करने की कोशिश की और अब भी ऐसा करना जारी है। इसके अलावा, सीपीयू-सघन और जीपीयू-गहन संचालन हैं जिन्हें ध्यान में रखा जाना चाहिए और इसे दरकिनार किया जाना चाहिए।

4. बेहतर प्रदर्शन कैसे प्राप्त करें

सबसे सरल उत्तर मुख्य धागे, सीपीयू और जीपीयू को बंद करना है। ऐसा करने के लिए, आपको आईओएस-एप्लिकेशन के काम को गहराई से समझने की आवश्यकता है। और सबसे ऊपर, समस्याओं के स्रोतों की पहचान करें।

4.1 प्रदर्शन की समस्याएं क्यों

कोर एनिमेशन, RunLoop और स्क्रॉल
आइए याद रखें कि इंटरफ़ेस iOS में कैसे बनाया गया है। शीर्ष स्तर पर, UIKit है , जो उपयोगकर्ता के साथ बातचीत करने के लिए ज़िम्मेदार है: इशारा प्रसंस्करण, नींद से आवेदन जागना, और इसी तरह की चीजें। इंटरफ़ेस को प्रस्तुत करने के लिए, एक निम्न-स्तरीय उपकरण जिम्मेदार है - कोर एनिमेशन (जैसा कि macOS में)। यह अपने स्वयं के इंटरफ़ेस विवरण प्रणाली के साथ एक रूपरेखा है । एक इंटरफ़ेस के निर्माण की मूल अवधारणाओं पर विचार करें।

कोर एनिमेशन के लिए, संपूर्ण इंटरफ़ेस CALayer लेयर्स है। वे एक रेंडर ट्री बनाते हैं, जिसे CATransaction लेनदेन के माध्यम से प्रबंधित किया जाता है।

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

कई लेनदेन एक स्टैक बनाते हैं। ताजा अपडेट स्टैक के शीर्ष लेनदेन में आते हैं।

अब हम जानते हैं कि स्क्रीन को अपडेट करने के लिए हमें लेयर ट्री के लिए नए मापदंडों के साथ लेनदेन करना होगा।

लेन-देन कब और कैसे करें? हमारे आवेदन में, थ्रेड्स में RunLoop नामक एक इकाई है । सरल शब्दों में, यह एक अनंत लूप है, जिसके प्रत्येक पुनरावृत्ति पर घटनाओं की वर्तमान कतार संसाधित होती है।

मुख्य सूत्र में, RunLoop विभिन्न स्रोतों से घटनाओं को संसाधित करने RunLoop आवश्यकता होती है, जैसे कि एक इंटरफ़ेस (इशारे), टाइमर, या, उदाहरण के लिए, NSStream और NSPort से डेटा प्राप्त करने के लिए हैंडलर।

कोर एनिमेशन और RunLoop कैसे RunLoop ? हमने ऊपर पाया कि रेंडर ट्री में एक परत के गुणों को बदलते समय, सिस्टम यदि आवश्यक हो तो निहित लेनदेन बनाता है (इसलिए, हमें कुछ को फिर से CATransaction.begin लिए CATransaction.begin को कॉल करने की आवश्यकता नहीं है)। इसके अलावा, प्रत्येक RunLoop चलना पर RunLoop सिस्टम स्वचालित रूप से खुले लेनदेन को बंद कर देता है और किए गए परिवर्तनों ( CATransaction.commit ) को लागू करता है।

ध्यान दो! पुनरावृत्तियों की संख्या RunLoop स्क्रीन की ताज़ा दर पर निर्भर नहीं करती है। चक्र स्क्रीन के साथ समकालिक नहीं है और "अंतहीन while() " की तरह काम करता है।

अब देखते हैं कि स्क्रॉल के दौरान मुख्य थ्रेड पर RunLoop पुनरावृत्तियों में क्या होता है:

  ... if (dispatchBlocks.count > 0) { //   MainQueue doBlocks() } ... if (hasPanEvent) { handlePan() // UIScrollView change content offset -> change bounds } ... if (hasCATransaction) { CATransaction.commit() } ... 

सबसे पहले, प्रेषण_ dispatch_async / dispatch_sync माध्यम से मुख्य कतार में जोड़े गए ब्लॉक निष्पादित किए जाते हैं। और जब तक वे पूरा नहीं हो जाते, तब तक कार्यक्रम निम्नलिखित कार्यों के लिए आगे नहीं बढ़ता है।

इसके बाद, UIKit उपयोगकर्ता के पैन-जेस्चर की प्रक्रिया शुरू करता है । इस इशारे को संसाधित करने के भाग के रूप में, UIScrollView.contentOffset बदलता है, और परिणामस्वरूप, UIScrollView.bounds । UIScrollView की bounds बदलना (क्रमशः, और इसके वंशज UITableView , UICollectionView ) सामग्री के दृश्य भाग ( viewport ) को अद्यतन करता है।

RunLoop पुनरावृत्ति के अंत में, यदि हमारे पास खुला लेनदेन है, तो commit या flush स्वचालित रूप से होता है।

यह कैसे काम करता है, यह जांचने के लिए, उचित स्थानों पर ब्रेकपॉइंट लगाएं।
यहां बताया गया है कि जेस्चर प्रोसेसिंग कैसा दिखेगा:

और यहाँ handlePan बाद handlePan :

स्क्रॉल CADisplayLink दौरान, UIScrollView स्क्रीन रिफ्रेश दर के साथ प्रति सेकंड CADisplayLink बदलाव की संख्या को सिंक्रनाइज़ करने के लिए एक CADisplayLink टाइमर बनाता है।

हम CATransaction.commit कि RunLoop पुनरावृत्ति के अंत में नहीं होता है, लेकिन सीधे CADisplayLink टाइमर के प्रसंस्करण में होता है। लेकिन इससे कोई फर्क नहीं पड़ता:

4.2। CATransaction.commit

वास्तव में, CATransaction.commit अंदर के सभी ऑपरेशन को CALayer लेयर्स पर किया जाता है। लेआउट ( drawLayer ) और छवि ( drawLayer ) को अपडेट करने के लिए layoutSublayers की अपनी विधियाँ हैं। इन विधियों के डिफ़ॉल्ट कार्यान्वयन के परिणामस्वरूप प्रतिनिधि पद्धति कॉल होती है। UIView की नई आवृत्ति को UIView पदानुक्रम में जोड़कर, हम स्पष्ट रूप से कोर एनिमेशन परत पदानुक्रम में संबंधित परत जोड़ते हैं। इस मामले में, UIView डिफ़ॉल्ट रूप से अपनी परत का एक प्रतिनिधि है। जैसा कि आप कॉल स्टैक से देख सकते हैं, UIView CALayer प्रतिनिधि विधियों के कार्यान्वयन के भाग के रूप में, अपने तरीकों को निष्पादित करता है, जिस पर चर्चा की जाएगी:

चूँकि हम आमतौर पर UIView पदानुक्रम के साथ काम करते हैं, इसलिए विवरण UIView उदाहरणों के साथ आगे बढ़ेगा।

setNeedsLayout दौरान, setNeedsLayout के साथ चिह्नित सभी UIView के लेआउट setNeedsLayout । ध्यान दें कि एक बार फिर हम खुद layoutIfNeeded अंदर सिस्टम में उनके गारंटीकृत आस्थगित निष्पादन के कारण layoutIfNeeded या layoutIfNeeded नहीं कहते हैं। यहां तक ​​कि अगर एक लेन-देन में ( setNeedsLayout और setNeedsLayout लिए कॉल के बीच) आप कई बार frame बदलते हैं और setNeedsLayout कॉल setNeedsLayout , तो प्रत्येक परिवर्तन तुरंत लागू नहीं होगा। अंतिम परिवर्तन केवल CATransaction.commit को कॉल करने के बाद प्रभावी होंगे। प्रासंगिक CALayer विधियाँ: setNeedsLayout , layoutIfNeeded और layoutIfNeeded ।

ड्रॉइंग के लिए एक समान गुच्छा setNeedsDisplay और setNeedsDisplay विधियों द्वारा बनाया गया है। CALayer यह setNeedsDisplay , displayIfNeeded और drawLayer । CATransaction.commit किए गए सभी तरीकों को कॉल करता है जो setNeedsDisplay के साथ चिह्नित हैं। इस कदम को कभी-कभी ऑफस्क्रीन-ड्राइंग कहा जाता है।

एक उदाहरण है । विशिष्टता और सुविधा के लिए, UITableView :

  ... // Layout UITableView.layoutSubviews() //  ,   .. ... // Offscreen drawing UITableView.drawRect() //    ... 

UIKit UICollectionView UITableView / UICollectionView का UICollectionView : उपयोग करता है। willDisplayCell : willDisplayCell प्रतिनिधि willDisplayCell और इतने पर। drawInContext दौरान, drawInContext -ड्रॉइंग होती है: सभी लेयर्स के drawInContext मेथड्स या setNeedsDisplay के रूप में चिह्नित सभी UIView setNeedsDisplay को setNeedsDisplay । मुझे लगता है कि जब हम कुछ आकर्षित करते हैं, तो यह मुख्य धागे पर होता है, और हमें तत्काल एक नए फ्रेम के लिए परतों के प्रदर्शन को बदलने की आवश्यकता है। यह स्पष्ट है कि इस तरह का समाधान बहुत अक्षम हो सकता है।

CATransaction.commit में आगे क्या होता है? रेंडर ट्री रेंडर सर्वर को भेजा जाता है।

4.3। रेंडरिंग पाइपलाइन

IOS में एक इंटरफ़ेस फ्रेम बनाने की पूरी प्रक्रिया को याद करें (पाइपलाइन की व्याख्या करें [WWDC 2014 सत्र 419। iOS ऐप के लिए उन्नत ग्राफिक्स और एनिमेशन):

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

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

दिलचस्प है, फ्रेम बनाते समय, एक निश्चित "मल्टीथ्रेडिंग" का उपयोग किया जाता है। यदि स्क्रीन रिफ्रेश दर 60 फ्रेम प्रति सेकंड है, तो एक नया फ्रेम कुल मिलाकर 1/60 में नहीं, बल्कि एक सेकंड के 1/30 में बनता है। ऐसा इसलिए है क्योंकि एप्लिकेशन नया फ़्रेम तैयार कर रहा है, रेंडर सर्वर अभी भी पिछले एक को प्रोसेस कर रहा है:

मोटे तौर पर, स्क्रीन पर प्रदर्शित होने से पहले फ्रेम के निर्माण का कुल समय लेनदेन के गठन के लिए हमारी प्रक्रिया में 1/60 सेकंड और लेनदेन प्रसंस्करण के दौरान रेंडर सर्वर प्रक्रिया में 1/60 सेकंड का होता है।

मैं निम्नलिखित टिप्पणी करना चाहूंगा। हम खुद परतों की ड्राइंग को समानांतर कर सकते हैं और पृष्ठभूमि स्ट्रीम में UIImage / CGImage की सामग्री को प्रस्तुत कर सकते हैं। उसके बाद, मुख्य धागे में, आपको बनाई गई छवि को CALayer.contents संपत्ति में असाइन करना होगा। प्रदर्शन के मामले में, यह एक बहुत अच्छा दृष्टिकोण है। यह डेवलपर्स है जो इसे बनावट का उपयोग करते हैं। लेकिन चूँकि हम अपने आवेदन की प्रक्रिया में लेन-देन उत्पन्न करने की प्रक्रिया में केवल CALayer.contents को बदल सकते हैं, हमारे पास 1/30 सेकंड (रेंडर सर्वर के साथ रेंडरिंग पाइपलाइन के समानांतर और खाते के अनुकूलन को ध्यान में रखते हुए) एक नई छवि बनाने और स्थानापन्न करने के लिए केवल 60 फ्रेम पर 1/60 सेकंड हैं। )।

इसके अलावा, रेंडर सर्वर अभी भी सम्मिश्रण (नीचे देखें) और शॉर्ट-टर्म लेयर कैशिंग [iOS कोर एनिमेशन: एडवांस्ड टेक्नीक्स को संभाल सकता है। Nick Lockwood]. 1/60 CALayer.contents , . .

: , .

4.4.

Main-thread

1. ( CATransaction.commit ) - UIView.layoutSubviews UIView (, CALayer ). , layoutSubviews / cellForRow / willDisplayCell .

2. drawInContext / drawRect . - Main- ( CATransaction.commit ) — . , .

3. . . CATransaction.commit , , .

4. . UIImage / CGImage .

5. . Main-thread , scroll. - , UI.

6. Main-. , RunLoop Main- , , Main-. .

GPU

Blending . GPU ( Render Server GPU, ). , , Background-.

. , UIBlurEffect , UIVibrancyEffect , , (Render Pass). , , .

Offscreen rendering (Render Server)

Render Server . , , :

• cornerRadius — Render Server , ;
• shadowRadius — Render Server , ;
• mask — .

CALayer , , Offscreen rendering. , UIVisualEffect ( , Render Server CPU, GPU).

, .

5.

, , Time Profiler. Metal System Trace — Time Profiler .

5.1. Metal System Trace

, ( ). , : , .

, Metal System Trace , . , Render Server. , Main-, — , .

- , :

Metal System Trace . 64- , iPhone 5s. , . , - , , UI.

5.2.

. , - - . , CADisplayLink .

CADisplayLink timestamp — ( Render Server). CADisplayLink.timestamp timestamp . , (, 1/60 ) :

  //  CADisplayLink. link = [CADisplayLink displayLinkWithTarget:target selector:selector] [link addToRunLoop:[NSRunLoop mainRunLoop] forMode:UITrackingRunLoopMode] //    CADisplayLink : diff = prevTimestamp - link.timestamp if (diff > 1/fps) { //  freeze } prevTimestamp = link.timestamp 

CADisplayLink UITrackingRunLoopMode , .

Rendering Pipeline:

UI-, . «» freezeFrameTimeRate :

 scrollTime //    Scroll freezeFrameTime //    ,  "",       freezeFrameTimeRate = freezeFrameTime / scrollTime 

, - UIView . , «»:

, , « UIView » . क्यों? , . , , , : CADisplayLink , Render Server link.timetamp , Render Server , . 60 UI-, Render Server. Render Server , .

, , , Render Server . Metal , Render Server. , , iOS, Render Server .

.

, , . , .

: — ! — .

निष्कर्ष

— . , , .

, — . , .

, :

1. Apple .
2. Auto Layout .
3. The Cassowary Linear Arithmetic Constraint Solving Algorithm .
4. iOS Core Animation: Advanced Techniques. Nick Lockwood.
5. WWDC 2014 Session 419. Advanced Graphics and Animations for iOS Apps.