कांस्ट्रेलेन्टलेयआउट और रिलेटिवलैटआउट के बीच अंतर

Question

मैं ConstraintLayoutऔर के बीच के अंतर को लेकर उलझन में हूं RelativeLayout। क्या कोई मुझे उनके बीच सटीक अंतर बता सकता है?

Comments

कांस्ट्रेनल लयआउट मुख्य रूप से नए प्रोग्रामर के लिए डिज़ाइन किया गया है ताकि वे XML के माध्यम से हाथ से लेआउट बनाने के बजाय विज़ुअल एडिटर का उपयोग करके लेआउट को आसानी से डिज़ाइन कर सकें।

— कोप्सऑनराड

@ जेक निश्चित रूप से अनुभवी विशेषज्ञ

— देवों के

@MosesAprico आप सही हैं कि यह है। लेकिन मुझे लगता है अनुभवी विशेषज्ञ devs पहले से ही अन्य तरीके से बहुत कुछ (वे पहले से ही की तरह पता है RealtiveLayout, LinearLayout, GridLayoutआदि) दृश्य पदानुक्रम वे चाहते हैं।

— कोप्सऑनरॉड

@CopsOnRoad वास्तव में आप गलत हैं। Apple 5+ वर्षों से अड़चन का काम कर रहा है। आप किसी भी आकार के लिए उत्तरदायी डिजाइन प्राप्त करते हैं और जटिल लेआउट के एक टन लिखने के लिए नहीं है। जब आप कई विचारों को बांधना शुरू करते हैं तो आपको पूरी तरह उत्तरदायी डिजाइन बनाने के लिए केवल 3 बुनियादी नियंत्रणों की आवश्यकता होती है।

— निक टर्नर

Answer 1

के इरादे ConstraintLayoutका अनुकूलन और से बचने के घोंसले के लिए प्रत्येक दृश्य के लिए कुछ नियमों को लागू करके अपने लेआउट को देखते पदानुक्रम समतल है।

नियम आपको याद दिलाते हैं RelativeLayout, उदाहरण के लिए बाईं ओर कुछ अन्य दृश्य के बाईं ओर स्थापित करना।

app:layout_constraintBottom_toBottomOf="@+id/view1"

इसके विपरीत RelativeLayout, मूल्य ConstraintLayoutप्रदान करता है biasजो कि हैंडल (सर्कल के साथ चिह्नित) के सापेक्ष 0% और 100% क्षैतिज और ऊर्ध्वाधर ऑफसेट के संदर्भ में देखने के लिए उपयोग किया जाता है। ये प्रतिशत (और अंश) विभिन्न स्क्रीन घनत्वों और आकारों में दृश्य की सहज स्थिति प्रदान करते हैं।

app:layout_constraintHorizontal_bias="0.33" <!-- from 0.0 to 1.0 -->
app:layout_constraintVertical_bias="0.53" <!-- from 0.0 to 1.0 -->

बेसलाइन हैंडल (सर्कल हैंडल के नीचे गोल कोनों के साथ लंबा पाइप) का उपयोग दूसरे दृश्य संदर्भ के साथ दृश्य की सामग्री को संरेखित करने के लिए किया जाता है।

वर्ग हैंडल (दृश्य के प्रत्येक कोने पर) का उपयोग dps में दृश्य का आकार बदलने के लिए किया जाता है।

यह पूरी तरह से आधारित है और मेरी धारणा है ConstraintLayout

Comments

हम अभी भी RelativeLayout का उपयोग करके समतल लेआउट बना सकते हैं, इसीलिए मैं उलझन में हूँ कि ConstraintLayout कहाँ ध्यान रखे जहाँ RelativeLayout नहीं कर सकता है?

RelativeLayout एक दो-पास लेआउट है, जो दोहरे कराधान से पीड़ित है। इसे कम से कम दो बार मापना / लेआउट करना होगा। ConstraintLayout को इस प्रदर्शन का दंड नहीं भुगतना पड़ता है।

— क्रिस्टोफर पेरी

@ सुखद हां, हम अभी भी RelativeLayout का उपयोग करके समतल लेआउट बना सकते हैं। लेकिन यहां उल्लेखित सभी के अलावा, कांस्ट्रेन्डलैट आपको पूर्वनिर्धारित अनुपात में नकारात्मक मार्जिन और आकार के साक्षात्कार का उपयोग करने देता है । अंतिम एक सबसे मज़बूत तरीका है 16: 9 अनुपात में अपने ImageView के लिए कार्ड व्यू में सामग्री डिज़ाइन के

— यूजीन ब्रुसोव

कुछ ऐसे लेआउट हैं जो RelativeLayout में असंभव हैं जब तक कि आप एक LinearLayout या किसी अन्य RelativeLayout को नस्ट न करें। उदाहरण के लिए: 3 के एक "स्टैक" को दूसरे दृश्य के सापेक्ष लंबवत देखें

— Gak2

@ Gak2 मुझे आपके उदाहरण में नेस्टेड लेआउट के बिना कुछ भी असंभव नहीं दिख रहा है। हो सकता है कि आपको "स्टैक" से कुछ और मतलब हो। मैं सिर्फ "layout_alignEnd", "layout_below", "layout _..." का उपयोग करता हूं और इसके साथ किसी भी प्रकार का ढेर लगा सकता हूं ...

— अविश्वसनीय Jan

Answer 2

सापेक्ष लेआउट और बाधा लेआउट समकक्ष गुण

(1) सापेक्ष लेआउट:

android:layout_centerInParent="true"    

(1) बाधा लेआउट समकक्ष:

app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintLeft_toLeftOf="parent"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintRight_toRightOf="parent"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintTop_toTopOf="parent"

---

(२) सापेक्ष लेआउट:

android:layout_centerHorizontal="true"

(2) बाधा लेआउट समकक्ष:

app:layout_constraintLeft_toLeftOf="parent"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintRight_toRightOf="parent"
app:layout_constraintEnd_toEndOf="parent"

---

(3) सापेक्ष लेआउट:

android:layout_centerVertical="true"    

(3) बाधा लेआउट समतुल्य:

app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintTop_toTopOf="parent"

---

(4) सापेक्ष लेआउट:

android:layout_alignParentLeft="true"   

(4) बाधा लेआउट समकक्ष:

app:layout_constraintLeft_toLeftOf="parent"

---

(5) सापेक्ष लेआउट:

android:layout_alignParentStart="true"

(5) बाधा लेआउट समकक्ष:

app:layout_constraintStart_toStartOf="parent"

---

(6) सापेक्ष लेआउट:

android:layout_alignParentRight="true"

(6) बाधा लेआउट समतुल्य:

app:layout_constraintRight_toRightOf="parent"

---

(7) सापेक्ष लेआउट:

android:layout_alignParentEnd="true"    

(7) बाधा लेआउट समतुल्य:

app:layout_constraintEnd_toEndOf="parent"

---

(8) सापेक्ष लेआउट:

android:layout_alignParentTop="true"

(8) बाधा लेआउट समतुल्य:

app:layout_constraintTop_toTopOf="parent"

---

(9) सापेक्ष लेआउट:

android:layout_alignParentBottom="true" 

(9) बाधा लेआउट समतुल्य:

app:layout_constraintBottom_toBottomOf="parent"

---

(10) सापेक्ष लेआउट:

android:layout_alignStart="@id/view"

(10) बाधा लेआउट समतुल्य:

app:layout_constraintStart_toStartOf="@id/view"

---

(११) सापेक्ष लेआउट:

android:layout_alignLeft="@id/view" 

(11) बाधा लेआउट समतुल्य:

app:layout_constraintLeft_toLeftOf="@id/view"

---

(12) सापेक्ष लेआउट:

android:layout_alignEnd="@id/view"  

(12) बाधा लेआउट समतुल्य:

app:layout_constraintEnd_toEndOf="@id/view"

---

(13) सापेक्ष लेआउट:

android:layout_alignRight="@id/view"

(13) बाधा लेआउट समतुल्य:

app:layout_constraintRight_toRightOf="@id/view"

---

(14) सापेक्ष लेआउट:

android:layout_alignTop="@id/view"  

(14) बाधा लेआउट समकक्ष:

app:layout_constraintTop_toTopOf="@id/view"

---

(15) सापेक्ष लेआउट:

android:layout_alignBaseline="@id/view" 

(15) बाधा लेआउट समतुल्य:

app:layout_constraintBaseline_toBaselineOf="@id/view"

---

(16) सापेक्ष लेआउट:

android:layout_alignBottom="@id/view"

(16) बाधा लेआउट समतुल्य:

app:layout_constraintBottom_toBottomOf="@id/view"

---

(१ Layout) सापेक्ष लेआउट:

android:layout_toStartOf="@id/view"

(17) बाधा लेआउट समतुल्य:

app:layout_constraintEnd_toStartOf="@id/view"

---

(18) सापेक्ष लेआउट:

android:layout_toLeftOf="@id/view"  

(18) बाधा लेआउट समतुल्य:

app:layout_constraintRight_toLeftOf="@id/view"

---

(19) सापेक्ष लेआउट:

android:layout_toEndOf="@id/view"

(19) बाधा लेआउट समतुल्य:

app:layout_constraintStart_toEndOf="@id/view"

---

(२०) सापेक्ष लेआउट:

android:layout_toRightOf="@id/view"

(20) बाधा लेआउट समतुल्य:

app:layout_constraintLeft_toRightOf="@id/view"

---

(२१) सापेक्ष लेआउट:

android:layout_above="@id/view" 

(२१) बाधा लेआउट समतुल्य:

app:layout_constraintBottom_toTopOf="@id/view"

---

(२२) सापेक्ष लेआउट:

android:layout_below="@id/view" 

(22) बाधा लेआउट समतुल्य:

app:layout_constraintTop_toBottomOf="@id/view"

---

Comments

क्या आप छवि के बजाय पाठ के रूप में पोस्ट कर सकते हैं? ताकि भविष्य में यह मेरे लिए और दूसरों के लिए भी बहुत उपयोगी हो।

— नया डेवलपर

हर किसी को सीखने की शुरुआत करने वाले को यह देखने की जरूरत है। धन्यवाद।

— अनुदान

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

— यतिऑनरेन्जरेमउंडर

नहीं, मेरे पास डॉक्स में देखने का समय नहीं है, यह निश्चित रूप से उपयोगी है। और सरल भाषा में लिखा गया है। Upvoting।

— कोडटॉइल

Answer 3

@Davidpbr ConstraintLayout प्रदर्शन द्वारा रिपोर्ट किया गया

मैंने दो समान 7-बाल लेआउट बनाए, एक-एक माता ConstraintLayout- पिता के साथ और RelativeLayout। एंड्रॉइड स्टूडियो विधि ट्रेसिंग टूल के आधार पर, यह ConstraintLayoutअधिक समय तक खर्च करता है और इसमें अतिरिक्त काम करता है onFinishInflate।

लाइब्रेरी का इस्तेमाल किया ( support-v4, appcompat-v7...):

com.android.support.constraint:constraint-layout:1.0.0-alpha1

डिवाइस / एंड्रॉइड वर्जन पर पुन: पेश किया गया: सैमसंग गैलेक्सी एस 6 (एसएम-जी 9 20 ए। क्षमा करें, कोई नेक्सस एटीएम)। Android 5.0.2

त्वरित विधि अनुरेखण तुलना:

नमूना गितुब रेपो: https://github.com/OnlyInAmerica/ConstraintLayoutPerf

Comments

उसी मुद्दे से: मैं इसे अभी के लिए बंद करने जा रहा हूं - अल्फा 4/5 प्रदर्शन में काफी सुधार लाया। हम शायद इसे और अधिक सुधारने में सक्षम होंगे, लेकिन हो सकता है कि यह पद 1.0 प्रतीक्षा करे।

— ऑलेक्ज़ेंडर

क्या आप इस महान तुलना को बनाने के लिए किस टूल का उपयोग कर सकते हैं?

— नटिव

@ नेटिव मोनोटिर्स-> सीपीयू-> टाइम ट्रैकर आइकन

— एंड्री टी

बाधा रहित लेआउट पर एक ही कोड को रन और प्रोफाइल करें: 1.0.1 नेक्सस 5 पर एंड्रॉइड 6.0.1 के साथ, यहां परिणाम: सापेक्ष लेआउट - माप पर 2ms 30ms + 16ms = 62 लीटर Layouyt 7ms = 9ms पर कुल 54 एमएस के बारे में लेआउट - init 7ms बाधा लेआउट लेआउट पैरामेट्स उत्पन्न + दृश्य जोड़ें ~ 7 * 2ms = 14ms माप पर 60ms + 52ms ~ 112ms लेआउट 8ms पर कुल ~ 141ms सापेक्ष लेआउट की तुलना में पहली बार बाधा से लगभग तीन गुना तेज है।

— एंड्री टी

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

— कोडपीकर

Answer 4

निम्नलिखित अंतर / लाभ हैं:

1. बाधा लेआउट में सापेक्ष लेआउट के साथ-साथ रैखिक लेआउट दोनों की दोहरी शक्ति है: विचारों के सापेक्ष स्थान निर्धारित करें (जैसे सापेक्ष लेआउट) और गतिशील यूआई के लिए वजन भी निर्धारित करें (जो केवल रैखिक लेआउट में संभव था)।

2. एक बहुत शक्तिशाली उपयोग श्रृंखला बनाकर तत्वों का समूह है। इस तरह हम विचारों के एक समूह का निर्माण कर सकते हैं, जो कि एक पूरे समूह को बनाने के लिए सिर्फ पदानुक्रम की एक और परत को जोड़े बिना एक वांछित तरीके से रखा जा सकता है।

3. भार के अतिरिक्त, हम क्षैतिज और ऊर्ध्वाधर पूर्वाग्रह लागू कर सकते हैं जो केंद्र से विस्थापन के प्रतिशत के अलावा कुछ भी नहीं है। (०.५ के पूर्वाग्रह का अर्थ केन्द्रित रूप से संरेखित करना है। संबंधित दिशा में किसी भी मूल्य के कम या अधिक होने का मतलब है कि संबंधित गति)।

4. एक और बहुत महत्वपूर्ण विशेषता यह है कि यह GONE विचारों को संभालने के लिए कार्यक्षमता का सम्मान करता है और प्रदान करता है, ताकि लेआउट को जावा कोड के माध्यम से कुछ दृश्य सेट किए जाने पर टूट न जाए। और अधिक यहाँ पाया जा सकता है: https://developer.android.com/reference/android/support/constraint/ConstraintLayout.html#VisibilityBehavior

5. ब्लू प्रिंट और विजुअल एडिटर टूल के उपयोग से स्वचालित अवरोधन की शक्ति प्रदान करता है जिससे पेज डिजाइन करना आसान हो जाता है।

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

यहाँ पर जल्दी से सीखने के लिए सबसे अच्छी जगह है: https://codelabs.developers.google.com/codelabs/constraint-layout/#0

Comments

6) कांस्ट्रेन्डलैटआउट, पूर्व-परिभाषित अनुपातों के माध्यमों में साक्षात्कारों को आकार देना संभव बनाता है । यह उदाहरण के लिए उपयोगी होगा जब आप 16: 9 में अपना ImageView रखने जा रहे हों।

— यूजीन ब्रूसोव

Answer 5

एक बड़ा अंतर यह है कि अगर दृश्य चला जाता है, तो भी कॉन्स्ट्रेनल लयआउट बाधाओं का सम्मान करता है। यदि आपके पास एक श्रृंखला है और आप बीच में एक दृश्य गायब करना चाहते हैं तो यह लेआउट को नहीं तोड़ेगा।

Comments

क्या आप मुझे कोई उदाहरण दे सकते हैं? मान लीजिए कि 3 बटन हैं। मैं 2nd बटन छिपाऊंगा और 3rd बटन btn2 के रूप में आईडी के साथ 2 बटन से जुड़ा हुआ है। मान लीजिए कि मैं 2nd बटन छिपाता हूं तो 3rd बटन 2 बटन का आईडी कैसे खोज सकता है?

यह सच नहीं है। यदि आप "GONE" के बजाय एक बटन की दृश्यता को "INVISIBLE" के रूप में सेट करते हैं, तो आप बाधाओं को नहीं तोड़ेंगे। मेरे लिए, जैसा कि @Nikola ने कहा कि सबसे बड़ा अलग पूर्वाग्रह है जो आपको अधिक "उत्तरदायी" विचार बनाने में मदद करता है।

— zapotec

@ नोइंग लेट्स मान लेते हैं कि बटन एक दूसरे के नीचे हैं। यहां तक ​​कि अगर आप tButton 2 छिपाते हैं, तो यह अभी भी "दृश्य अनुबंध" में है, या तो आपके xml या कोड में। ConstraintLayout इसका सम्मान करेगा और बटन 3 बटन 1 के नीचे होगा। एक RelativeLayout बटन 2 में चला गया है, इसके साथ गर्भनिरोधक चला गया है, इसलिए बटन 3 डिफ़ॉल्ट स्थिति में होगा, इसलिए स्क्रीन के ऊपरी बाएँ।

— हरबर्ट74

@ ज़ापोटेक मेरा सम्मान है कि अन्य सामान आपके लिए अधिक महत्वपूर्ण है, लेकिन मेरे लिए यह वास्तव में एक अच्छा अंतर है। केवल उसी चीज़ को ठीक करता है जिससे मैं RelativeLayout में नफरत करता था। अदृश्य का उपयोग करना एक विकल्प नहीं है, क्योंकि यह अंतरिक्ष का दावा करेगा।

— हरबर्ट74

Answer 6

@ धवल-जीवनी उत्तर के अलावा।

मैंने प्रोजेक्ट github प्रोजेक्ट को नवीनतम लेआउट v.1.1.0-beta3 के नवीनतम संस्करण में अद्यतन किया है

मैंने मापा है और ऑनक्रिएट विधि के समय की तुलना की है और ऑनक्रिएट की शुरुआत और सीपीयू मॉनिटर में दिखाई देने वाली अंतिम प्रीफॉर्मड्रॉ विधि के निष्पादन के अंत के बीच का समय। सभी परीक्षण एंड्रॉइड 6.0.1 के साथ सैमसंग एस 5 मिनी पर किए गए थे। यहां परिणाम:

नई शुरुआत (एप्लिकेशन लॉन्च के बाद पहली बार स्क्रीन खोलना)

अंतरंग परिस्थिति

ऑनक्रिएट: 123 मी

अंतिम प्रीफॉर्मड्रॉ टाइम - ऑनक्रीट समय: 311.3ms

बाधा लेआउट

ऑनक्रिएट: 120.3ms

अंतिम प्रीफॉर्मड्रॉ टाइम - ऑनक्रीट समय: 310 मी

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

निष्कर्ष के रूप में मैं लेख की टिप्पणियों से सहमत हूं :

क्या यह पुराने विचारों को रिलेटिव लियूट या लिनियर लयआउट से स्विच करने लायक है?

हमेशा की तरह: यह निर्भर करता है 🙂

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

Answer 7

आधिकारिक तौर पर, ConstraintLayoutहै बहुत तेजी से

एंड्रॉइड के एन रिलीज़ में, ConstraintLayoutक्लास समान कार्यक्षमता प्रदान करता है RelativeLayout, लेकिन कम लागत पर।

Answer 8

पूछने के लिए असली सवाल यह है कि क्या किसी भी तरह की बाधा के अलावा किसी अन्य लेआउट का उपयोग करने का कोई कारण है? मेरा मानना ​​है कि उत्तर नहीं हो सकता है।

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

बाधाएं हर तरह से बेहतर हैं (वे एपीके आकार में 150k की तरह खर्च करते हैं।) वे तेज होते हैं, वे आसान होते हैं, वे अधिक लचीले होते हैं, वे परिवर्तनों के लिए बेहतर प्रतिक्रिया करते हैं, वे समस्याओं को ठीक करते हैं जब आइटम चले जाते हैं, तो वे मौलिक रूप से अलग-अलग स्क्रीन प्रकारों के अनुरूप बेहतर होते हैं और वे लंबे समय तक नेस्टेड लूप के एक गुच्छा का उपयोग नहीं करते हैं सब कुछ के लिए पेड़ संरचना तैयार की। आप कहीं भी, किसी भी चीज के संबंध में, कहीं भी कुछ भी रख सकते हैं।

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

Comments

क्या इसका कोई प्रमाण है?

— राजेश नसीत

हाँ। यह तेज है। लेआउट एक पेड़ के माध्यम से पुनरावृत्ति करने के बजाय एक एकल में नीचे है। ज्यादातर चीजों के लिए यह मायने नहीं रखेगा क्योंकि यह लेआउट में कॉल पर किया गया है। लेकिन, देखने में आसान होने वाली ट्री चीज़, विचारों के अंदर विचारों का एक गुच्छा बनाती है जिसमें कॉल की आवश्यकता होती है। हालांकि यह सैद्धांतिक रूप से अच्छा है, लेकिन व्यवहार में कोड के एक बिट में लेआउट प्रदर्शन पूरे दृश्य पेड़ के माध्यम से पुनरावृति की तुलना में कहीं अधिक आसान है। यह अधिक विचारों के साथ और अधिक प्रभावशाली होगा, लेकिन यहां मई से एक बेंचमार्क है: medium.com/@krpiotrek/constraintlayout-performance-c1455c7984d7

— तात्कालिक करें।

मुझे एक और सवाल का सामना करना पड़ रहा है, क्या मुझे जिस ऐप पर काम कर रहा हूं, उसमें सभी मौजूदा रिलेटिवेलआउट्स को बदल देना चाहिए? क्या यह प्रदर्शन में काफी सुधार करेगा?

— श्रीकांत करुमनघाट

@SricanthKarumanaghat ऐसा लगता है कि आप कभी भी वापस समय नहीं लेंगे जो उन समय को वापस ले जाता है जब स्विचिंग आपको बचा लेगी। हम ज्यादातर मामलों में 3.25ms के लिए 3.5ms चक्र छोड़ने की बात कर रहे हैं। यदि यह आपको एक अतिरिक्त सुविधा या कुछ ऐसी चीज़ देता है जिसकी आपको ज़रूरत है, लेकिन विशुद्ध रूप से स्पीड ग्राउंड नाह पर। हालांकि हम कन्वर्ट बटन को हिट करने की बात कर रहे हैं।

— ताताराइज करें

Answer 9

निष्कर्ष मैं बना सकता हूं

1) हम कोड के xml हिस्से को छूने के बिना यूआई डिज़ाइन कर सकते हैं , ईमानदार होने के लिए मुझे लगता है कि Google ने कॉपी किया है कि आईओएस ऐप में यूआई कैसे डिज़ाइन किया गया है , यह समझ में आएगा कि क्या आप आईओएस में यूआई के विकास से परिचित हैं, लेकिन सापेक्ष लेआउट में एक्सएमएल डिजाइन को छूने के बिना बाधाओं को सेट करना मुश्किल है ।

2) दूसरे में अन्य लेआउट के विपरीत फ्लैट दृश्य पदानुक्रम है , इसलिए सापेक्ष लेआउट की तुलना में बेहतर प्रदर्शन होता है जिसे आपने अन्य उत्तरों से देखा होगा।

3) इसमें अतिरिक्त चीजें भी होती हैं, जो सापेक्ष लेआउट के अलावा होती हैं, जैसे कि गोलाकार सापेक्ष स्थिति, जहां हम एक दूसरे के सापेक्ष इस दृश्य को किसी निश्चित कोण पर रख सकते हैं, जो सापेक्ष लेआउट में नहीं कर सकता है

मैं इसे फिर से कह रहा हूं, कसना लेआउट का उपयोग करके यूआई डिजाइन करना iOS में यूआई डिजाइन करने के समान है, इसलिए भविष्य में यदि आप आईओएस पर काम करते हैं तो आपको आसान होगा यदि आपने बाधा लेआउट का उपयोग किया है

Answer 10

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