當我意識到ConstraintLayout有：與其他人相比，約束佈局是否昂貴？
更好的佈局拖放
更好的視野相對設置了更好的命名「頂級toBottomOf」
更好的佈局結構與比例和百分比指南
以及更多不能在這裏說或我只是不知道
我總是想不斷使用它，因爲它很舒服。
就像標題一樣，我很好奇ConstraintLayout在不斷使用它時會不會對性能產生巨大影響？
聲明您的意見和證據將不勝感激。
如果您有良好的版本/語法，並且需要向下投票，請在下方留下您的結論意見，歡迎編輯。感謝丹尼斯的語法改正。
與其他人相比，約束佈局是否昂貴？
它取決於您的使用情況。 A ConstraintLayout與Steroids上的RelativeLayout類似。
如果你想要一個簡單的2-3 ChildViews佈局，那麼使用ConstraintLayout將不會如此高效。去線性佈局。
「的ConstraintLayout的主要目的是爲了解決問題與RelativeLayout的，它也得這麼好，你可以做到這一點是不可能有的RelativeLayout這麼多東西，而且可以簡化你的佈局就像你以前從未有過的那樣，另外，它修復了RelativeLayout長期存在的性能問題，在度量/佈局階段期間的雙重課稅，所以我們在一個很好的包中獲得了更好的性能，更多的功能和更簡單的佈局。 「
由於性能改進是創建此新佈局的主要原因之一，因此我做了一些性能測試以檢查是否達到此目標。
我比較了RecyclerView中使用的佈局。沒什麼特別的，只是一些嵌套的LinearLayout和RelativeLayout容器。我將此佈局手動移至ConstraintLayout，並進行了一些相當粗糙的性能測試。
在仿真器和Nexus 5上比較這兩者在使用新的ConstraintLayout時總體上會降低性能。
表現最差的是測量。這個方法需要的時間大約是我用於比較的LinearLayout的一個長度的十倍。而且它大部分時間花費了大約60倍，只要onLayout()。因此，與所討論的LinearLayout相比，ConstraintLayout的onLayout（）方法的30％命中幾乎是不相關的。最後，與LinearLayout相比，使用ConstraintLayout的佈局通脹還需要更長的。
ConstraintLayout執行大量的計算以找出在哪裏以及如何顯示其每個孩子。內部（至少）三個相當長的類正在一起工作以獲得結果：LinearSystem,ConstraintWidget和ConstraintWidgetContainer。爲了充分理解表現行爲，我必須深入研究這些類的深度（爲此，當Google發佈其源時，我更喜歡評論類）。但僅僅通過粗略看一下反編譯的代碼，它看起來像這些類必須做很多。
一些煩惱
並不是所有在工作的時刻完美，雖然。現在這些事情困擾我最：
編輯updos填充或以意想不到的方式更改內容
此post支持ConstraintLayout。
就我個人而言，我只使用ConstraintLayout，當我想對齊超過3個視圖。使用起來很簡單，但同時也很麻煩。
這一切都取決於您將它與哪些內容進行比較，以及您測量的內容。如果您將其與LinearLayout進行比較，則其價格仍然非常昂貴。如果你比較內存使用情況，它比RelativeLayout更昂貴。我也不會相信隨機的博客文章是準確的。尤其是那篇博客文章，它將所有的文章都與糟糕的實施設計進行比較。 –
@GabeSechan我建議你發佈它（更詳細）作爲支持用戶的答案，這將通過谷歌搜索來到這裏。 –
如果您非常關心內存使用情況，請讓我們知道它會影響多少內存。我沒有閱讀那個隨機的博客。我自己用它，並在此基礎上，我發佈了這個答案。但我一定會編輯這個答案。 – Dennis
約束佈局提高性能，通過Android開發者博客this文章，它明確規定，ConstraintLayout執行的措施/佈局階段比的RelativeLayout
該示例具有4個ViewGroups的嵌套深度，如果您有更簡單的佈局，則不需要使用約束佈局。 –
更好的約40％我真的，真的建議你停止使用拖放。沒有人使用它是有原因的 - 它更慢，更不準確，並且難以維持編寫佈局的方式。我知道每個iOS工程師都希望他們擁有Android佈局，這是他們希望他們不必拖放的原因。嚴重的網絡開發人員不再使用DreamWeaver也是一樣的原因。 –