ऑटो लेआउट का गणितीय आधार

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

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




ऑटो लेआउट एक लेआउट सिस्टम है । इसमें देरी करने से पहले, आइए सामान्य रूप से आधुनिक टाइपसेटिंग के बारे में बात करें। तो चलो ऑटो लेआउट से निपटते हैं - हम यह पता लगाएंगे कि यह किस कार्य को हल करता है और यह कैसे करता है। आइए iOS में ऑटो लेआउट को लागू करने में सुविधाओं पर विचार करें, और व्यावहारिक युक्तियां विकसित करने का प्रयास करें जो इसके साथ काम करने में मदद कर सकें।

यह कहानी एक गणितीय लेख के बहुत करीब होगी, इसलिए हम पहले उसी भाषा को बोलने के लिए अंकन पर सहमत होते हैं।


स्पीकर के बारे में: एंटोन सर्गेव ( antonsergeev88 ) Yandex.Mart टीम में काम करता है, आईओएस पर मैप्स के लिए मोबाइल क्लाइंट के साथ काम करता है। मोबाइल विकास से पहले, वह पावर प्लांट कंट्रोल सिस्टम से निपटता है, जहां कोड में त्रुटियों की लागत बहुत अधिक है।

पदनाम

स्कूल के बाद से रैखिक समीकरणों की प्रणालियाँ हमसे परिचित हैं - वे एक घुंघराले ब्रैकेट द्वारा इंगित किए जाते हैं, और उनका समाधान पहले से ही बिना है। इसके अलावा, रैखिक समीकरणों की प्रणालियों में ऐसी इकाइयाँ हैं जो ऑटो लेआउट के साथ काम करती हैं - प्रतिबंध। उन्हें एक सीधी रेखा द्वारा इंगित किया जाता है।



अजीब और, जैसा कि हम पहले से ही जानते हैं, खतरनाक पक्षी स्लाइड के ऊपरी कोने में गलती से चित्रित नहीं होता है। कैसोवरी (लेट। कैसोवरी) के सम्मान में, जो निश्चित रूप से ऑस्ट्रेलिया में रहती है, हमारे सभी आईफ़ोन में एक एल्गोरिथ्म का नाम दिया गया है।

ऑटो लेआउट की अपनी सीमाएं हैं, हम प्राथमिकता के क्रम में रंगों के साथ उन्हें निरूपित करेंगे: लाल - आवश्यक; पीला - उच्च; नीला - कम।

मेकअप

जब मैं प्रेजेंटेशन बना रहा था, मैंने विभिन्न तत्वों को स्क्रीन पर रखा, उदाहरण के लिए, एक कैसोवरी। ऐसा करने के लिए, मैंने निर्धारित किया कि पुलाव एक आयताकार चित्र है। आपको इसे एक ऐसी शीट पर व्यवस्थित करने की आवश्यकता है जिसमें कुल्हाड़ी और स्वयं का समन्वय प्रणाली है, और इसके लिए मैंने ऊपरी बाएं कोने, चौड़ाई और ऊंचाई के निर्देशांक निर्धारित किए।



इन चार मूल्यों को जानना किसी भी दृश्य का प्रतिनिधित्व करने के लिए पर्याप्त है।

एल्गोरिथम नंबर 1

शीट पर कैसोवेरी रखते समय, हमने पहले लेआउट एल्गोरिथ्म का अनौपचारिक रूप से वर्णन किया है:

• निर्देशांक और आकार निर्धारित करें;
• उन्हें UIView पर लागू करें।

एल्गोरिथ्म काम करता है, लेकिन उपयोग करने में काफी मुश्किल है, इसलिए हम इसे और सरल करेंगे।

मान लीजिए कि नीचे रैखिक समीकरणों की कुछ प्रणाली का समाधान है।



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

रैखिक परिवर्तनों की सुंदरता यह है कि वे प्रतिवर्ती हैं। यह हमें एक दिलचस्प और सूक्ष्म विचार के साथ लाता है जिसके साथ संपूर्ण आधुनिक लेआउट शुरू होता है।

आज्ञाकारी और आकार के साथ एक दृश्य - एक आयत होने दें। हम इसे व्यवस्थित करना चाहते हैं ताकि केंद्र दिए गए बिंदु के साथ मेल खाता हो। हम रैखिक परिवर्तनों का उपयोग करके केंद्र को मॉडल करते हैं - ऊपरी बाएं कोने + आधा चौड़ाई का समन्वय ।



हमने रैखिक परिवर्तन द्वारा केंद्र को मॉडल किया, यह नहीं था: केवल ऊपरी बाएं बिंदु, चौड़ाई और ऊंचाई के निर्देशांक थे।

इसी तरह, आप किसी अन्य इंडेंटेशन का अनुकरण कर सकते हैं, उदाहरण के लिए, दाएं कोने से 20 अंक।

यह रैखिक परिवर्तनों का विचार है जो हमें विभिन्न टाइपिंग सिस्टम बनाने की अनुमति देता है।

एक प्राथमिक उदाहरण पर विचार करें। हम एक प्रणाली लिखते हैं जिसके साथ हम मध्य और दाईं ओर, चौड़ाई और चौड़ाई और ऊंचाई के बीच संबंध के समन्वय स्थापित करते हैं। हम सिस्टम को हल करते हैं और उत्तर प्राप्त करते हैं।



तो हम दूसरे एल्गोरिथ्म में आते हैं।

एल्गोरिथम नंबर 2

एल्गोरिथ्म के दूसरे पुनरावृत्ति में निम्नलिखित आइटम होते हैं:

• रैखिक समीकरणों की एक प्रणाली बनाना;
• हम इसे हल करते हैं;
• UIView के समाधान को लागू करें।

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



एक समस्या है - इस प्रणाली का एक भी समाधान नहीं है। समस्या असाधारण नहीं है, बिल्कुल सभी लेआउट सिस्टम इसमें चलते हैं, और इसे समाधान की कमी कहा जाता है।

इस स्थिति से बाहर इतने सारे तरीके नहीं हैं:

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

ऑटो लेआउट समस्या का विवरण और समाधान

हमारे पास एक आयताकार चित्र है और इसे विशिष्ट रूप से पहचानने के लिए, हमें 4 मापदंडों की आवश्यकता है:

• ऊपरी बाएं कोने के निर्देशांक;
• चौड़ाई और ऊंचाई।

ऑटो लेआउट बहुत क्रिया है। रैखिक समीकरणों की एक प्रणाली की तुलना में, स्क्रीन पर सब कुछ डालना बहुत कठिन है। इसलिए, हम सामान्यता के नुकसान के बिना विचार करेंगे, एक आयामी मामला।



सब कुछ बहुत सरल है: अंतरिक्ष एक सीधी रेखा है, और इसमें रखी जाने वाली सभी वस्तुएं एक सीधी रेखा पर बिंदु हैं। एक मान: X = X _P बिंदु की स्थिति निर्धारित करने के लिए पर्याप्त है।

ऑटो लेआउट दृष्टिकोण पर विचार करें। एक जगह है जिसमें प्रतिबंध लगाए गए हैं। समाधान हम प्राप्त करना चाहते हैं एक्स = एक्स ₀ , और कोई अन्य नहीं।

एक समस्या है - हमने प्रतिबंधों के साथ संचालन को परिभाषित नहीं किया है। हम सीधे X = X ₀ के रिकॉर्ड से निष्कर्ष नहीं निकाल सकते हैं, हम कुछ भी गुणा नहीं कर सकते हैं या कुछ भी जोड़ सकते हैं। ऐसा करने के लिए, हमें बाधा को बदलने की जरूरत है कि हम किसके साथ काम कर सकते हैं - समीकरणों और असमानताओं की प्रणाली में।



ऑटो लेआउट समीकरणों और असमानताओं की प्रणाली को निम्नानुसार बदल देता है।

• पहले 2 अतिरिक्त चर पेश करता है जो नकारात्मक नहीं हैं और एक दूसरे पर निर्भर हैं । उनमें से कम से कम एक शून्य के बराबर है।
• बाधा स्वयं संकेतन X = X ₀ + a ⁺ - a ^- में परिवर्तित हो जाती है।

बिंदु X ₀   - प्रणाली का समाधान: यदि a ⁺ और a ^- शून्य के बराबर हैं, तो यह सच होगा। लेकिन इस लाइन पर कोई अन्य बिंदु एक समाधान होगा।

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

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

असमानता बाधाओं

असमानता प्रतिबंधों के मामले में, परिवर्तन उसी तरह से होता है जैसे समानताएं: दो अतिरिक्त चर पेश किए जाते हैं और यह सब सिस्टम में एकत्र किया जाता है। केवल कार्यात्मक अलग है, और यह एक के बराबर है ^- ।



ऊपर दिए गए ग्राफ़ से पता चलता है कि ऐसा क्यों है - a का कोई मान ^- a = = 0 ( X ₀ से + ∞ तक ) समस्या का इष्टतम समाधान होगा।

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



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

हम फ़ंक्शन को इकट्ठा करते हैं और देखते हैं कि समाधान एक्स _{1 है} । जैसा कि हमें उम्मीद थी, प्रतिबंध लगा रहा है। तो हम तीसरे एल्गोरिथम पर आते हैं।

एल्गोरिथम नंबर 3

कुछ करने के लिए, आपको चाहिए:

• रैखिक बाधाओं की एक प्रणाली बनाएँ;
• इसे एक रैखिक प्रोग्रामिंग समस्या में बदलना;
• किसी भी ज्ञात तरीके से समस्या को हल करें, उदाहरण के लिए, सरल लेआउट विधि जो ऑटो लेआउट में उपयोग की जाती है;
• UIView के समाधान को लागू करें।

यह एल्गोरिथ्म पर्याप्त लगता है, लेकिन निम्नलिखित मामले पर विचार करें: हम बाधाओं के प्रारंभिक सेट को बदलते हैं ताकि दूसरा बाधा अब एक्स now एक्स _{2 हो} ।



हम क्या समाधान देखने की उम्मीद करते हैं?

• एक्स ₁ ? दरअसल, पहले प्रतिबंध में ऐसा लिखा गया है: एक्स = एक्स ₁ , और यह समाधान दूसरे प्रतिबंध के साथ संघर्ष करता है।
• एक्स ₂ ? पहले प्रतिबंध के साथ पहले से ही एक संघर्ष होगा।

स्थिति से बाहर निकलने के लिए, हम उन परिवर्तनों का प्रदर्शन करेंगे जो हम पहले से ही जानते हैं कि कैसे करना है।

नई कार्यक्षमता का ग्राफ अलग दिखता है: X ₁ से X ₂ के अंतराल का कोई भी बिंदु सिस्टम का सही वैध समाधान होगा। इसे अनिश्चितता कहा जाता है ।

अनिश्चितता

ऑटो लेआउट में ऐसी समस्याओं को हल करने के लिए एक तंत्र है - प्राथमिकताएं । मैं आपको याद दिलाता हूं कि पीला उच्च प्राथमिकता का संकेत देगा, और नीला - कम।



प्रतिबंध बदलें। कृपया ध्यान दें कि परिणामी प्रणाली सिर्फ काली है। हम जानते हैं कि इसके साथ कैसे काम करना है, और इसमें प्रतिबंधों के बारे में कोई जानकारी नहीं है। यह कार्यात्मकताओं में है, जिनमें से दो होंगे। ऑटो लेआउट पहले और फिर दूसरे को छोटा करेगा।

रैखिक प्रोग्रामिंग समस्याओं में, हम स्वयं समाधान के लिए नहीं, बल्कि संभव समाधानों की श्रेणी के लिए देख रहे हैं। बेशक, हम चाहते हैं कि यह क्षेत्र केवल एक बिंदु हो, और ऑटो लेआउट उसी तरह से कार्य करता है। सबसे पहले, यह ( - + , + , ) पर सर्वोच्च-प्राथमिकता वाले कार्यात्मक को कम करता है और, आउटपुट पर, संभव समाधान का एक डोमेन प्राप्त करता है। ऑटो लेआउट अनुमेय मूल्यों की प्राप्त सीमा पर पहले से ही दूसरी रैखिक प्रोग्रामिंग समस्या को हल करता है। इस तरह के तंत्र को बाधाओं का एक पदानुक्रम कहा जाता है, और इस समस्या में बिंदु X ₂ देता है।

एलगोरिदम नंबर 4

• रैखिक बाधाओं का एक पदानुक्रम बनाएं;
• इसे एक रेखीय प्रोग्रामिंग कार्य में बदलना;
• क्रमिक रूप से रैखिक प्रोग्रामिंग समस्या को हल करें - उच्चतम प्राथमिकता से निम्नतम प्राथमिकता तक।
• ULView के लिए समाधान लागू करें।

आइए पिछले कार्य को फिर से देखें। हम गणितज्ञ नहीं हैं, लेकिन इंजीनियरों, और किसी भी इंजीनियर को यहां भ्रमित होना चाहिए।

यहां एक गंभीर समस्या है - अनंत , और मुझे नहीं पता कि यह क्या है।

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

• पैरामीटर वे बाधाएं हैं जिनके साथ हम काम कर रहे हैं। उन्हें मूल में कहा जाता है , कभी-कभी Apple प्रलेखन में - वैकल्पिक बाधाएं ।
• आवश्यकताएं या आवश्यकताएं - प्राथमिकता के साथ प्रतिबंध आवश्यक ।

आइए देखते हैं कि इस तरह की प्राथमिकताओं के साथ आवश्यकताओं को गणित के दृष्टिकोण से कैसे बदला जाता है।



हमारे पास फिर से दो बिंदुओं के साथ एक सीधी रेखा है, और पहला प्रतिबंध X = X _{1 है} । स्लाइड पर, यह लाल है, अर्थात, प्राथमिकता के साथ यह प्रतिबंध आवश्यक है - हम इसे आवश्यकता कहेंगे।

ऑटो लेआउट इसे एक समीकरण X = X ₁ वाले रैखिक समीकरणों की प्रणाली में परिवर्तित करता है। अधिक कुछ नहीं - कोई रेखीय प्रोग्रामिंग कार्य नहीं, कोई अनुकूलन नहीं।

स्थिति असमानताओं के साथ समान है, लेकिन थोड़ा अधिक जटिल - एक अतिरिक्त चर दिखाई देगा जो किसी भी मान को 0 से अधिक ले सकता है। 0 से अधिक किसी भी मूल्य के लिए, यह प्रतिबंध संतुष्ट होगा। कृपया ध्यान दें कि यहाँ कोई रेखीय प्रोग्रामिंग कार्य और अनुकूलन नहीं हैं।

आइए इन सभी को एक साथ मिलाने की कोशिश करें, दो आवश्यकताओं को एक साथ रखें और उन्हें एक प्रणाली में परिवर्तित करें एक चौकस पाठक, ने कहा कि हम उसी मुद्दे पर आए थे जिसके साथ हमने शुरू किया था - आवश्यकताओं को सुसंगत होना चाहिए ।



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

आइए सभी प्रकार के प्रतिबंधों को संयोजित करने का प्रयास करें जो हमें एक प्रणाली में मिले थे। मान लीजिए कि हम समस्या को पूरी रेखा पर नहीं, बल्कि केवल X ₀ और X _{3 के} बीच हल करना चाहते हैं । यह सब रैखिक समीकरणों और असमानताओं की एक प्रणाली में बदलना, हम निम्नलिखित प्राप्त करते हैं।



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

ऐसा लगता है कि कार्य बहुत अधिक नहीं बदला है - हम पहले की तरह ही कम से कम करते हैं, लेकिन स्वीकार्य मूल्यों की प्रारंभिक सीमा बदल रही है, अब यह एक्स ₀ से एक्स _{3 तक है} ।

गणितीय दृष्टिकोण से, आवश्यकताएं - आवश्यक प्रकार के प्रतिबंध - सिस्टम में अपने समीकरणों को संशोधित किए बिना अतिरिक्त समीकरणों को पेश करने की क्षमता है।

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

हम अंतिम पांचवें एल्गोरिथ्म में पहुंचे।

एल्गोरिथम नंबर 5

• आवश्यक प्रतिबंधों को परिभाषित करें - लेआउट आवश्यकताओं;
• रैखिक बाधाओं का एक पदानुक्रम बनाएँ;
• सभी बाधाओं को एक रैखिक प्रोग्रामिंग समस्या में परिवर्तित करें;
• रैखिक प्रोग्रामिंग की समस्या को हल करना;
• ULView के लिए समाधान लागू करें।

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

IOS सुविधाएँ

लेआउटसुब्यू () में कोई गणना नहीं है ।

इनका उत्पादन कब किया जाता है? उत्तर: हमेशा, किसी भी समय ऑटो लेआउट को गिना जाता है। गणना ठीक तब होती है जब हम अपने दृष्टिकोण में बाधाओं को जोड़ते हैं, या बाधाओं के साथ काम करने के लिए आधुनिक एपीआई विधियों का उपयोग करके उन्हें सक्रिय करते हैं।



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

दूसरी विशेषता आंतरिक आंतरिक संपर्क है - आंतरिक आकार जिसे प्रत्येक दृश्य के लिए सेट किया जा सकता है।



यह 4 अतिरिक्त असमानता बाधाओं को बनाने के लिए एक सरल इंटरफ़ेस है जिसे सिस्टम में रखा जाएगा। यह तंत्र बहुत सुविधाजनक है, यह आपको स्पष्ट प्रतिबंधों की संख्या को कम करने की अनुमति देता है, जो ऑटो लेआउट के उपयोग को सरल करता है। अंतिम और सबसे पतला बिंदु जो अक्सर भुला दिया जाता है, TranslAutoresizingMaskIntoConstraints है ।



यह एक बैसाखी है जिसे iOS 5 के दिनों में वापस पेश किया गया था, ताकि ऑटो लेआउट के दिखने के बाद पुराना कोड न टूटे।

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

मैं आपको याद दिलाता हूं कि कैसोवेरी के ऑटो लेआउट कार्य में कोई सीमा नहीं है, केवल सीमाएं हैं।

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

इस स्थिति से बचने के लिए, यदि TranslateAutoresizingMaskIntoConstraints वैरिएबल का मान सत्य है, तो फ़्रेम पर निर्धारित प्रत्येक दृश्य पर एक अतिरिक्त प्रतिबंध लागू होता है। प्रतिबंधों का यह सेट रन-रन से भिन्न हो सकता है। इस सेट के बारे में केवल एक चीज ज्ञात है - इसका फ्रेम वह होगा जो प्रसारित किया गया था।

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

यह जानना महत्वपूर्ण है:

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

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

व्यावहारिक सुझाव

सभी में तीन परिषदें होंगी और सबसे महत्वपूर्ण के साथ शुरू होगी।

अनुकूलन

समस्या का स्थानीयकरण करना महत्वपूर्ण है।

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

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


कार्य यह है: हम एक-एक करके एक श्रृंखला बनाते हैं, और हम प्रत्येक बाद वाले को पिछले एक के साथ जोड़ते हैं। इस प्रकार, 1000 तत्वों का एक अनुक्रम बनाया गया था। विभिन्न ऑपरेशनों को मापने के बाद, समय को मिलीसेकंड में इंगित किया गया है। मान काफी बड़े हैं, क्योंकि ऑटो लेआउट का आविष्कार 80 और 90 के दशक के जंक्शन पर किया गया था।

इस तरह की श्रृंखला को इकट्ठा करके, आप निम्नानुसार कार्य कर सकते हैं:

• एक समय में एक बाधा जोड़ें और हर बार तय करें। इसमें 38 सेकंड का समय लगेगा।
• आप एक ही बार में सभी प्रतिबंध जोड़ सकते हैं , और उसके बाद ही सिस्टम को हल कर सकते हैं। यह समाधान अधिक कुशल है। पुराने आंकड़ों के अनुसार, दक्षता 70% बढ़ जाती है, लेकिन आधुनिक उपकरणों पर वर्तमान कार्यान्वयन में केवल 20% होगी। लेकिन प्रतिबंधों के गुणात्मक रूप से एक बार का जोड़ हमेशा अधिक प्रभावी होगा।
• जब पूरी श्रृंखला इकट्ठी हो जाती है, तो आप एक और प्रतिबंध जोड़ सकते हैं । जैसा कि तालिका से देखा जा सकता है, यह ऑपरेशन काफी सस्ता है।
• सबसे दिलचस्प बात: यदि हम कोई नया प्रतिबंध नहीं जोड़ते हैं, लेकिन किसी एक मौजूदा में कुछ निरंतरता को बदलते हैं , तो यह एक नए प्रतिबंध को हटाने या बनाने की तुलना में अधिक प्रभावी परिमाण का एक आदेश है।

पहले दो बिंदुओं को इंटरफेस की प्राथमिक गणना के रूप में वर्णित किया जा सकता है, पिछले दो - अगले के रूप में।

प्राथमिक इंटरफ़ेस गणना

यहाँ आप अनुकूलन के लिए भारी मात्रा में बाधाओं को जोड़ने के तरीकों का उपयोग कर सकते हैं:

• NSLayoutConstraints.activate (_ :) - एक दृश्य बनाते समय, सभी बाधाओं को क्रमिक रूप से एक सरणी, कैश में इकट्ठा करें और उसके बाद ही इसे एक बार में जोड़ें।
• या इंटरफ़ेस बिल्डर में सेल बनाएँ । वह हमारे लिए सब कुछ करेगा, और अतिरिक्त अनुकूलन करेगा, जो अक्सर सुविधाजनक होता है।

इसके बाद इंटरफ़ेस गणना

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

• UIView — . view , Auto Layout. , , view, .
• — IntrinsicContentSize. , , .
• . , , .

, WWDC 2018S220 High Performance Auto Layout . — Apple , .

, constraints.

required , — , , . .

, .

:

• , . ( loader) — .
• , . , .

, , .

constraint required, . , , , . , .

— , . , — . - , , . Auto Layout , .

, . . , , , . layout, , , . .

— , Auto Layout, , .

, required, , . :

• , .
• , , .

, , , .

, . , , , . , — . .

— . , , , — , — required -.

:

Solving Linear Arithmetic Constraints for User Interface Applications
The Cassowary Linear Constraint Solving Algorithm
Constraints as s Design Pattern
Auto Layout Guide by Apple
WWDC 2018 Session 220 High Performance Auto Layout
UILabel API Auto Layout —
. Medium

, AppsConf 2019 . , AppsConf , 22 23 . - , .