IOS में प्रदर्शन या मुख्य थ्रेड को ऑफ़लोड कैसे करें। भाग 1

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

“दोस्तों, आइए कल्पना करें कि आप स्टार्टअप के समय को 10 सेकंड तक कम कर सकते हैं। इसे 5 मिलियन उपयोगकर्ताओं द्वारा गुणा करते हुए, हमारे पास प्रतिदिन 50 मिलियन सेकंड होंगे। एक वर्ष में यह लगभग दस मानव जीवन की राशि होगी। इसलिए, यदि आप प्रारंभिक डाउनलोड 10 सेकंड तेज करते हैं, तो आप कई दसियों जीवन बचाएंगे। यह वास्तव में इसके लायक है, है ना? ”

प्रदर्शन पर स्टीव जॉब्स (Apple II कंप्यूटर स्टार्टअप समय)।

यह लेख फ्यूजन आईओएस डेवलपर ल्यूक परम की रिपोर्ट पर आधारित है, जिन्होंने पिछले साल एमबीएलटी डीईवी इंटरनेशनल मोबाइल डेवलपर्स कॉन्फ्रेंस में बात की थी।

MBLT DEV 2018 28 सितंबर को मास्को में आयोजित किया जाएगा। टिकट अभी सबसे सस्ता है। परंपरा के अनुसार, जबकि कार्यक्रम समिति रिपोर्टों का चयन करती है, आप कोनफ के लिए शुरुआती पक्षी टिकट खरीद सकते हैं। अब इस अवसर को लें। 29 जून से टिकट और महंगे हो जाएंगे।

फ्रेम का नुकसान

मुख्य थ्रेड कोड को निष्पादित करता है जो स्पर्श प्रकार की घटनाओं और UI के साथ काम करने के लिए जिम्मेदार है। वह स्क्रीन का प्रतिपादन करता है। अधिकांश आधुनिक स्मार्टफोन 60 फ्रेम प्रति सेकंड पर रेंडर करते हैं। इसका मतलब है कि कार्य 16.67 मिलीसेकंड (1000 मिलीसेकंड / 60 फ्रेम) में पूरा होना चाहिए। इसलिए, मेन थ्रेड में त्वरण महत्वपूर्ण है।

यदि कुछ ऑपरेशन में 16.67 मिलीसेकंड से अधिक का समय लगता है, तो फ़्रेम लॉस अपने आप हो जाता है, और एप्लिकेशन उपयोगकर्ता एनिमेशन खेलते समय इसे नोटिस करेंगे। कुछ उपकरणों पर, प्रतिपादन और भी तेज है, उदाहरण के लिए, iPad Pro 2017 पर, स्क्रीन रिफ्रेश दर 120 हर्ट्ज है, इसलिए एक फ्रेम में संचालन पूरा करने के लिए केवल 8 मिलीसेकंड हैं।

नियम # 1

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

।

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

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

।

उपयोगकर्ता इससे खुश नहीं होंगे, खासकर यदि एप्लिकेशन पुराने उपकरणों पर चलता है, जैसे कि iPhone 5 या पुराने iPod मॉडल, आदि।

समय प्रोफाइलर

इस तरह के मुद्दों पर नज़र रखने के लिए एक उपयोगी उपकरण टाइम प्रोफाइलर है। अन्य उपकरण भी उपयोगी होते हैं, लेकिन अंततः 90% फ़्यूज़न में हम टाइम प्रोइलर का उपयोग करते हैं। आमतौर पर, एप्लिकेशन में समस्याएं स्क्रॉलव्यू से संबंधित होती हैं, पाठ और छवियों वाले क्षेत्र।

छवियाँ महत्वपूर्ण हैं। हम UIImage का उपयोग करके JPEG प्रारूप को डिकोड करते हैं। वे इसे धीरे-धीरे करते हैं, और हम सीधे उनके प्रदर्शन को ट्रैक नहीं कर सकते हैं। UIImageView में छवि को सेट करने के तुरंत बाद ऐसा नहीं होता है, लेकिन आप इस पल को टाइम प्रोफाइलर में ट्रेसिंग के माध्यम से देख सकते हैं।

पाठ स्वरूपण एक और महत्वपूर्ण बिंदु है। यह तब मायने रखता है जब एप्लिकेशन में बड़ी मात्रा में "जटिल" पाठ होता है, उदाहरण के लिए, जापानी या चीनी में। पाठ के साथ लाइनों के लिए सही आकार की गणना करने में लंबा समय लग सकता है।

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

ट्रेस पैटर्न

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

प्रारंभिक ट्रेस विश्लेषण जटिल लग सकता है। हमेशा यह पता लगाना संभव नहीं है कि FRunLoopDoSource0 का क्या अर्थ है।

ट्रेस के माध्यम से अफवाह करते हुए, आप समझ सकते हैं कि सिस्टम कैसे काम करता है, और फिर सब कुछ समझ में आता है। आप स्टैक ट्रेस को ट्रैक कर सकते हैं और उन सभी सिस्टम तत्वों को देख सकते हैं जिन्हें आपने नहीं लिखा था। लेकिन सबसे नीचे आपका सोर्स कोड है।

पेड़ को बुलाओ

मान लीजिए कि हमारे पास एक बहुत ही सरल आवेदन है। इसमें मुख्य फ़ंक्शन होता है जो कई अन्य कार्यों को कॉल करता है। टाइम प्रोइलर के काम का सार यह है कि यह एक मिलीसेकंड (डिफ़ॉल्ट रूप से) की आवृत्ति के साथ स्टैक ट्रेस की वर्तमान स्थिति का स्नैपशॉट लेता है। एक और मिलीसेकंड के बाद, वह ट्रेस का स्नैपशॉट लेता है। यह मुख्य फ़ंक्शन को कॉल करता है, जो फ़ंक्शन को " foo " कहता है, जिसे फ़ंक्शन " bar " कहा जाता है। प्रारंभिक स्टैक ट्रेस नीचे स्क्रीनशॉट में दिखाया गया है। इन आंकड़ों को एक साथ एकत्र किया जाता है। प्रत्येक फ़ंक्शन के विपरीत, एक संख्या इंगित की गई है: 1, 1, 1।

इसका मतलब है कि इनमें से प्रत्येक फ़ंक्शन को एक बार बुलाया गया था। फिर, एक मिलीसेकंड के बाद, हमें स्टैक का एक और शॉट मिलता है। इस बार यह बिल्कुल समान दिखता है, इसलिए सभी संख्या 1 से बढ़ जाती है, और हमें 2, 2, 2 मिलते हैं।

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

अगला, एक फ़ंक्शन दूसरे को कॉल करता है, जिसे तीसरा फ़ंक्शन कहा जाता है। हम देखते हैं कि " baz " फ़ंक्शन को दो बार बुलाया गया था। लेकिन यह फ़ंक्शन इतना महत्वहीन है कि इसे एक मिलीसेकंड से अधिक तेज कहा जाता है।

Time Profiler का उपयोग करते समय, यह याद रखना महत्वपूर्ण है कि यह विशिष्ट समय अंतराल नहीं दिखाता है। यह किसी फ़ंक्शन के सटीक निष्पादन समय को प्रदर्शित नहीं करता है। वह केवल रिपोर्ट करता है कि चित्रों में यह कितनी बार दिखाई देता है, जो प्रत्येक फ़ंक्शन की अवधि का केवल एक अनुमानित मूल्य देता है। चूंकि कुछ प्रक्रियाएं काफी तेज होती हैं, वे चित्रों पर कभी प्रदर्शित नहीं होती हैं।

कंसोल मोड में कॉल स्विच करते समय, आप फ्रेम दर में कमी के सभी क्षणों को देख और तुलना कर सकते हैं। उदाहरण में, फ्रेम की हानि कई बार हुई और विभिन्न प्रक्रियाओं का प्रदर्शन किया गया।

MacOS पर पूरी तरह से क्लिक करने से अनुभाग और उप-वर्गों का विस्तार होगा, न कि केवल एक चयनित। वे प्रदर्शन किए गए कार्य की मात्रा द्वारा हल किए जाएंगे। 90% मामलों में, CFRunLoopRun आता है, उसके बाद कॉलबैक आता है।

यह एप्लिकेशन पूरी तरह से सिंगल रन लूप कार्य निष्पादन चक्र पर आधारित है। एक अंतहीन दोहराव चक्र है, और प्रत्येक पुनरावृत्ति पर, कॉलबैक लॉन्च किए जाते हैं। यदि आप इन कॉलबैक को देखते हैं, तो आप शीर्ष बाधाओं को उजागर कर सकते हैं।

इन चुनौतियों को अधिक विस्तार से देखने के बाद, आप सबसे अधिक संभावना नहीं समझ पाएंगे कि वे क्या कर रहे हैं। ये रेंडर, इमेज प्रोवाइडर, आईओ हो सकते हैं।

एक विकल्प है जो आपको सिस्टम लाइब्रेरी को छिपाने की अनुमति देता है। वे वास्तव में आवेदन के समस्या क्षेत्र हैं।

ऐसे मीटर हैं जो प्रतिशत के संदर्भ में बताते हैं कि कोई विशेष कार्य या ऑपरेशन कितना कार्य करता है। यदि हम इस उदाहरण को देखते हैं, तो हम यहां मूल्य - 34% देखेंगे। यह Apple jpeg_decode_image_all प्रक्रिया है। अध्ययन करने के बाद यह स्पष्ट हो जाता है कि जेपीईजी छवियों का डिकोडिंग मुख्य धागे में होता है, और ज्यादातर मामलों में यह फ्रेम लॉस का कारण होता है।

नियम # २

सामान्य रूप से, डिकोडिंग जेपीआर छवियों को पृष्ठभूमि में किया जाना चाहिए। अधिकांश तृतीय-पक्ष लाइब्रेरी (AsyncDisplayKit, SDWebImage, आदि) डिफ़ॉल्ट रूप से ऐसा कर सकते हैं। यदि आप फ्रेमवर्क का उपयोग नहीं करना चाहते हैं, तो आप डिकोडिंग मैन्युअल रूप से कर सकते हैं। ऐसा करने के लिए, आप UIImage पर एक एक्सटेंशन लिख सकते हैं जिसमें आप एक संदर्भ बनाते हैं और मैन्युअल रूप से एक छवि बनाते हैं।

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

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

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

मेमोरी अलर्ट से बाहर

कम मेमोरी के किसी भी संकेत के साथ, मैं सभी अप्रयुक्त डेटा को हटाना चाहता हूं जो संभव है। लेकिन अगर विभिन्न प्रक्रियाओं को थर्ड-पार्टी स्ट्रीम पर किया जाता है, तो वॉल्यूमेट्रिक डिकोड किए गए JPEG- चित्र उन पर अधिकांश खाली स्थान ले लेंगे।

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

विफलताओं के बिना काम करें

अनिवार्य रूप से, मुख्य धागा प्रक्रियाओं से मिलकर एक कतार है। थर्ड-पार्टी थ्रेड्स के साथ काम करते समय, आप कमांड performSelectorOnMainThread:withObject:waitUntilDone: ऑब्जेक्टिव-सी में लिख सकते हैं। उसके लिए धन्यवाद, कार्यों को मुख्य धागे पर कतार के अंत में रखा जाएगा। इसलिए, यदि मुख्य थ्रेड स्मृति सूचनाओं को संसाधित करने में व्यस्त है, तो इस कमांड को कॉल करने से आप सभी सूचनाओं को संसाधित होने तक प्रतीक्षा करने की अनुमति देंगे, और उसके बाद ही डेटा लोड करने और रखने की जटिल प्रक्रिया शुरू करेंगे। स्विफ्ट में, यह थोड़ा सरल दिखता है। DispatchQueue.main.sync मुख्य थ्रेड पर स्थान खाली करता है।

यहाँ एक और उदाहरण है। हमने तृतीय-पक्ष धाराओं पर मेमोरी और डिकोड छवियों को मुक्त कर दिया है। नेत्रहीन रूप से टेप को स्क्रॉल करना बेहतर हो गया है। हम अभी भी इस तथ्य के कारण फ्रेम खो रहे हैं कि हम आइपॉड 5 जी का परीक्षण कर रहे हैं। यह उन लोगों के सबसे खराब परीक्षण मॉडल में से एक है जो अभी भी iOS 10 और 11 संस्करणों का समर्थन करते हैं।

यदि आप इस तरह के फ्रेम लॉस का अनुभव करते हैं, तो आप अभी भी टेप देख सकते हैं। हालांकि, ऐसी प्रक्रियाएं बनी हुई हैं जो कर्मियों के नुकसान का कारण बनी हुई हैं। एप्लिकेशन को तेज़ी से चलाने के लिए अन्य तरीके हैं।

बेशक, एप्लिकेशन को अनुकूलित करना हमेशा आसान नहीं होता है। लेकिन अगर आपके पास ऐसे कार्य हैं जिन्हें पूरा करने में अपेक्षाकृत लंबा समय लगता है, तो आपको उन्हें पृष्ठभूमि के धागे में रखना चाहिए। सुनिश्चित करें कि ये कार्य UI से संबंधित नहीं हैं, क्योंकि कई UIKit कक्षाएं सुरक्षित नहीं हैं, अर्थात, आप उन्हें बैकएंड में नहीं बना सकते हैं।

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

MBLT DEV 2018 में आपका स्वागत है

मास्को में 28 सितंबर को 5 वें अंतर्राष्ट्रीय एमबीएलटी डीईवी 2018 मोबाइल डेवलपर्स सम्मेलन में आएं । पहले स्पीकर पहले से ही साइट पर हैं, और नवीनतम शुरुआती पक्षी अभी भी बिक्री पर है। टिकट की कीमतें 29 जून को बढ़ेंगी। अब सबसे कम कीमत में टिकट खरीदें ।

आईओएस में उपयोगकर्ता इंटरफ़ेस के कार्यान्वयन के बारे में पढ़ें, बेज़ियर घटता और लेख के दूसरे भाग में अन्य उपयोगी उपकरण का उपयोग, जिसे हम 28 जून को प्रकाशित करेंगे।