ConstraintLayout ve RelativeLayout arasındaki farklar

Ben arasındaki fark hakkında karıştı ConstraintLayoutve RelativeLayout. Birisi bana aralarındaki kesin farklılıkları söyleyebilir mi?

Amacı, ConstraintLayoutiç içe yerleştirmekten kaçınmak için her görünüme bazı kurallar uygulayarak mizanpajlarınızın görünüm hiyerarşisini optimize etmek ve düzleştirmektir.

Kurallar size hatırlatır RelativeLayout, örneğin başka bir görünümün solunu soluna ayarlamak.

app:layout_constraintBottom_toBottomOf="@+id/view1"

Bunun aksine RelativeLayout, bir görünümü tutamaçlara göre (daire ile işaretli)% 0 ve% 100 yatay ve dikey ofset açısından konumlandırmak için kullanılan değer ConstraintLayoutsunar bias. Bu yüzdeler (ve kesirler), görünümün farklı ekran yoğunlukları ve boyutları arasında kesintisiz konumlandırılmasını sağlar.

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

Taban çizgisi tutamacı (köşeleri yuvarlatılmış uzun boru, daire tutamacının altında) görünümün içeriğini başka bir görünüm referansıyla hizalamak için kullanılır.

Kare tutamaçlar (görünümün her köşesinde) görünümü dps olarak yeniden boyutlandırmak için kullanılır.

Bu tamamen fikir temelli ve benim izlenimim ConstraintLayout

Göreceli Düzen ve Kısıt Düzeni eşdeğeri özellikleri

(1) Göreceli Düzen:

android:layout_centerInParent="true"    

(1) Kısıt Düzeni eşdeğeri:

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"

(2) Göreceli Düzen:

android:layout_centerHorizontal="true"

(2) Kısıt Düzeni eşdeğeri:

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

(3) Göreceli Düzen:

android:layout_centerVertical="true"    

(3) Kısıt Düzeni eşdeğeri:

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

(4) Göreceli Düzen:

android:layout_alignParentLeft="true"   

(4) Kısıt Düzeni eşdeğeri:

app:layout_constraintLeft_toLeftOf="parent"

(5) Göreceli Düzen:

android:layout_alignParentStart="true"

(5) Kısıt Düzeni eşdeğeri:

app:layout_constraintStart_toStartOf="parent"

(6) Göreceli Düzen:

android:layout_alignParentRight="true"

(6) Kısıt Düzeni eşdeğeri:

app:layout_constraintRight_toRightOf="parent"

(7) Göreceli Düzen:

android:layout_alignParentEnd="true"    

(7) Kısıt Düzeni eşdeğeri:

app:layout_constraintEnd_toEndOf="parent"

(8) Göreceli Düzen:

android:layout_alignParentTop="true"

(8) Kısıt Düzeni eşdeğeri:

app:layout_constraintTop_toTopOf="parent"

(9) Göreceli Düzen:

android:layout_alignParentBottom="true" 

(9) Kısıt Düzeni eşdeğeri:

app:layout_constraintBottom_toBottomOf="parent"

(10) Göreceli Düzen:

android:layout_alignStart="@id/view"

(10) Kısıt Düzeni eşdeğeri:

app:layout_constraintStart_toStartOf="@id/view"

(11) Göreceli Düzen:

android:layout_alignLeft="@id/view" 

(11) Kısıt Düzeni eşdeğeri:

app:layout_constraintLeft_toLeftOf="@id/view"

(12) Göreceli Düzen:

android:layout_alignEnd="@id/view"  

(12) Kısıt Düzeni eşdeğeri:

app:layout_constraintEnd_toEndOf="@id/view"

(13) Göreceli Düzen:

android:layout_alignRight="@id/view"

(13) Kısıt Düzeni eşdeğeri:

app:layout_constraintRight_toRightOf="@id/view"

(14) Göreceli Düzen:

android:layout_alignTop="@id/view"  

(14) Kısıt Düzeni eşdeğeri:

app:layout_constraintTop_toTopOf="@id/view"

(15) Göreceli Düzen:

android:layout_alignBaseline="@id/view" 

(15) Kısıt Düzeni eşdeğeri:

app:layout_constraintBaseline_toBaselineOf="@id/view"

(16) Göreceli Düzen:

android:layout_alignBottom="@id/view"

(16) Kısıt Düzeni eşdeğeri:

app:layout_constraintBottom_toBottomOf="@id/view"

(17) Göreceli Düzen:

android:layout_toStartOf="@id/view"

(17) Kısıt Düzeni eşdeğeri:

app:layout_constraintEnd_toStartOf="@id/view"

(18) Göreceli Düzen:

android:layout_toLeftOf="@id/view"  

(18) Kısıt Düzeni eşdeğeri:

app:layout_constraintRight_toLeftOf="@id/view"

(19) Göreceli Düzen:

android:layout_toEndOf="@id/view"

(19) Kısıt Düzeni eşdeğeri:

app:layout_constraintStart_toEndOf="@id/view"

(20) Göreceli Düzen:

android:layout_toRightOf="@id/view"

(20) Kısıt Düzeni eşdeğeri:

app:layout_constraintLeft_toRightOf="@id/view"

(21) Göreceli Düzen:

android:layout_above="@id/view" 

(21) Kısıt Düzeni eşdeğeri:

app:layout_constraintBottom_toTopOf="@id/view"

(22) Göreceli Düzen:

android:layout_below="@id/view" 

(22) Kısıt Düzeni eşdeğeri:

app:layout_constraintTop_toBottomOf="@id/view"

@Davidpbr ConstraintLayout performansı tarafından rapor edildi

Her biri bir ebeveyn ConstraintLayoutve bir olmak üzere iki benzer 7 çocuk düzenini yaptım RelativeLayout. Android Studio yöntem izleme aracına dayanarak, ConstraintLayoutonMeasure'da daha fazla zaman harcıyor ve ek çalışmalar gerçekleştiriyor onFinishInflate.

Kullanılan kitaplık ( support-v4, appcompat-v7…):

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

Üretilen cihazlar / Android versiyonları: Samsung Galaxy S6 (SM-G920A. Üzgünüm, Nexus atm yok). Android 5.0.2

Hızlı yöntem izleme karşılaştırması:

Örnek Github repo: https://github.com/OnlyInAmerica/ConstraintLayoutPerf

Farklılıklar / avantajlar şunlardır:

1. Kısıt Düzeni, hem Göreli Yerleşimin hem de Doğrusal mizanpajın ikili gücüne sahiptir: Göreli görünüm konumlarını (Göreceli mizanpaj gibi) ayarlayın ve ayrıca dinamik UI (yalnızca Doğrusal Mizanpaj'da mümkün olan) için ağırlıklar ayarlayın.

2. Çok güçlü bir kullanım, bir zincir oluşturarak elementlerin gruplandırılmasıdır. Bu şekilde, bir bütün olarak sadece başka bir görüş grubu oluşturmak için başka bir hiyerarşi katmanı eklemeden istenen şekilde yerleştirilebilen bir grup görünüm oluşturabiliriz.

3. Ağırlıklara ek olarak, merkezden yer değiştirme yüzdesinden başka bir şey olmayan yatay ve dikey önyargı uygulayabiliriz. (0.5 sapması, merkezi olarak hizalanır. Daha az veya daha fazla değer, ilgili yönde karşılık gelen hareket anlamına gelir).

4. Bir başka çok önemli özellik de, GONE görünümlerini işlemek için işlevsellik sağlaması ve böylece bazı görünümler java kodu aracılığıyla GONE olarak ayarlandığında düzenlerin bozulmamasıdır. Daha fazlasını burada bulabilirsiniz: https://developer.android.com/reference/android/support/constraint/ConstraintLayout.html#VisibilityBehavior

5. Bir sayfa tasarlamayı kolaylaştıran Mavi baskı ve Görsel Editör aracı kullanılarak otomatik kısıtlamanın uygulanmasını sağlar.

Tüm bu özellikler, performansı artıran ve aynı zamanda farklı ekran boyutlarına ve yoğunluğuna daha kolay adapte olabilen duyarlı ve dinamik kullanıcı arayüzü oluşturmaya yardımcı olan görünüm hiyerarşisinin düzleşmesine yol açar.

Hızlı bir şekilde öğrenmek için en iyi yer: https://codelabs.developers.google.com/codelabs/constraint-layout/#0

Büyük bir fark, ConstraintLayout'ın görünüm gitmiş olsa bile kısıtlamalara saygı göstermesidir. Eğer bir zinciriniz varsa ve bir görünümün ortadan kaybolmasını istiyorsanız, düzeni bozmaz.

@ Dhaval-jivani yanıtı yanı sıra.

Proje github projesini kısıtlama düzeni v.1.1.0-beta3'ün en son sürümüne güncelledim

OnCreate yönteminin süresini ve onCreate başlangıcı ile CPU monitöründe görünen son preformDraw yönteminin yürütülmesi arasında geçen süreyi ölçtüm ve karşılaştırdım. Tüm testler Android 6.0.1 ile Samsung S5 mini'de yapıldı. İşte sonuçlar:

Yeni başlangıç ​​(uygulama başlatıldıktan sonra ilk ekran açılması)

Göreceli Düzen

OnCreate: 123 ms

Son preformDraw time - OnCreate süresi: 311.3 ms

Kısıt Düzeni

OnCreate: 120.3 ms

Son preformDraw time - OnCreate süresi: 310ms

Bunun yanı sıra, bu makaleden performans testini kontrol ettim , burada kod ve 100'den az kısıtlama düzeni varyantının sayım, şişirme, ölçü ve mizanpaj ile ilgili değişkenlerin yürütülmesi sırasında göreceli mizanpaj ile daha hızlı olduğunu gördüm . Ve Android 4.3 yüklü Samsung S3 gibi eski Android cihazlarda fark daha büyük.

Sonuç olarak, makalenin yorumlarına katılıyorum :

Eski görünümleri yeniden düzenlemeye değer mi, RelativeLayout veya LinearLayout'tan geçiş yapar mı?

Her zaman olduğu gibi: 🙂

Geçerli düzen hiyerarşinizle ilgili bir performans sorununuz yoksa veya düzende yine de önemli değişiklikler yapmak istemiyorsanız hiçbir şeyi yeniden düzenlemezdim. Son zamanlarda ölçmemiş olmama rağmen, son sürümlerde herhangi bir performans sorunu bulamadım. Bu yüzden kullanmak için güvenli olmanız gerektiğini düşünüyorum. ama - dediğim gibi - sadece göç uğruna göç etmeyin. Sadece bunu yapmak için bir ihtiyaç ve fayda varsa yapın. Yeni düzenler için neredeyse ConstraintLayout kullanıyorum. Daha öncekilere kıyasla çok daha iyi.

Resmi olarak ConstraintLayoutise çok daha hızlı

Android'in N sürümünde, ConstraintLayoutsınıf benzer işlevsellik sağlar RelativeLayout, ancak önemli ölçüde daha düşük bir maliyetle.

Sorulması gereken asıl soru, bir kısıt düzeni dışında herhangi bir düzen kullanmak için herhangi bir neden var mı? Cevabın hayır olabileceğine inanıyorum.

Acemi programcılara veya benzerlerine yönelik olduklarında ısrar edenlere, diğer düzenlerden daha düşük olmaları için bir neden sunmalıdırlar.

Kısıtlama düzenleri her şekilde daha iyidir (APK boyutunda 150k gibi maliyeti vardır.). Daha hızlılar, daha kolaylar, daha esnekler, değişikliklere daha iyi tepki veriyorlar, öğeler kaybolduğunda sorunları çözüyorlar, radikal olarak farklı ekran türlerine daha iyi uyuyorlar ve bu kadar uzun süre iç içe bir döngü kullanmıyorlar her şey için ağaç yapısı çıkardı. İstediğiniz yere, istediğiniz yere, istediğiniz yere koyabilirsiniz.

Görsel düzen editörünün yeterince iyi olmadığı 2016'nın ortalarında biraz vidalıydılar, ancak bir düzeniniz varsa, bir kısıtlama düzeni kullanmayı ciddi olarak düşünmek isteyebileceğiniz noktaya kadar. bir şeyle aynı şeyi RelativeLayout, hatta basit bir şeyi yaptığında LinearLayout. FrameLayoutsaçıkça hala amaçları var. Ancak, bu noktada başka bir şey inşa etmeyi göremiyorum. Bununla başlasalardı, başka bir şey eklemezlerdi.

Yapabileceğim Sonuç

1) Kodun xml kısmına dokunmadan UI tasarımı yapabiliriz , dürüst olmak gerekirse, google'ın UI'nin iOS uygulamalarında nasıl tasarlandığını kopyaladığını hissediyorum , iOS'ta UI geliştirmeye aşina olmanız mantıklı olacaktır, ancak göreceli düzende xml tasarımına dokunmadan kısıtlamaları ayarlamak zor .

2) İkincisi, diğer düzenlerden farklı olarak düz görünüm hiyerarşisine sahiptir , bu nedenle diğer cevaplardan görmüş olabileceğiniz göreceli düzenden daha iyi performans gösterir

3) Ayrıca , göreceli düzende yapamayan belirli bir açıyla belirli bir yarıçapta buna göre başka bir görünüm yerleştirebileceğimiz dairesel göreli konumlandırma gibi göreceli düzenin dışında ekstra şeyler de vardır.

Tekrar söylüyorum, kısıtlama düzenini kullanarak UI tasarlamak iOS'ta UI tasarlamakla aynıdır, bu nedenle gelecekte iOS'ta çalışıyorsanız kısıtlama düzenini kullandıysanız daha kolay bulacaksınız

Belirttiğim tek fark, sürükle ve bırak yoluyla göreceli bir düzende ayarlanan şeylerin otomatik olarak boyutlarını çıkartılan diğer öğelere göre olmasıdır, bu yüzden uygulamayı çalıştırdığınızda gördüğünüz şey elde ettiğiniz şeydir. Ancak kısıtlama düzeninde, tasarım görünümünde bir öğeyi sürükleyip bıraksanız bile, uygulamayı çalıştırdığınızda bazı şeyler değişebilir. Bu, kısıtlamaları manuel olarak ayarlayarak veya bileşen ağacındaki öğeyi sağ tıklayıp kısıtlama düzeni alt menüsünü seçip 'kısıtlamaları çıkar' seçeneğini tıklatarak daha riskli bir hareketle düzeltilebilir. Bu yardımcı olur umarım