ConstraintLayout
との違いについて混乱していRelativeLayout
ます。誰かがそれらの正確な違いを教えてもらえますか?
10 に答える
の目的は、ネストConstraintLayout
を回避するためにいくつかのルールを各ビューに適用することにより、レイアウトのビュー階層を最適化およびフラット化することです。
ルールは を思い起こさせます。RelativeLayout
たとえば、左を他のビューの左に設定します。
app:layout_constraintBottom_toBottomOf="@+id/view1"
とは異なりRelativeLayout
、は、ハンドル (円でマーク) に対する 0% および 100% の水平および垂直オフセットに関してビューを配置するために使用される値をConstraintLayout
提供します。bias
これらのパーセンテージ (および分数) により、さまざまな画面密度とサイズにわたってビューをシームレスに配置できます。
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
@davidpbr ConstraintLayout
パフォーマンスによって報告されました
親ConstraintLayout
とRelativeLayout
. Android Studio メソッド トレース ツールに基づいてConstraintLayout
、onMeasure でより多くの時間を費やし、.で追加の作業を実行しているようonFinishInflate
です。
使用したライブラリ ( support-v4
、appcompat-v7
…):
com.android.support.constraint:constraint-layout:1.0.0-alpha1
再現されたデバイス/Android バージョン: Samsung Galaxy S6 (SM-G920A。申し訳ありませんが、Nexus ATM はありません)。アンドロイド 5.0.2
簡単なメソッド トレースの比較:
サンプル Github リポジトリ: https://github.com/OnlyInAmerica/ConstraintLayoutPerf
大きな違いは、ビューがなくなっても ConstraintLayout が制約を尊重することです。したがって、チェーンがあり、ビューを途中で消したい場合でも、レイアウトが崩れることはありません。
私ができる結論は
1)コードの xml 部分に触れることなく UI 設計を行うことができます。正直なところ、Google は iOS アプリでの UI の設計方法をコピーしたと感じています。iOS での UI 開発に精通している場合は理解できますが、相対的なレイアウトではxml の設計に触れずに制約を設定するのは困難です。
2)第二に、他のレイアウトとは異なり、フラットなビュー階層を持っているため、他の回答から見た相対的なレイアウトよりも優れたパフォーマンスを発揮します
3)相対レイアウトではできない、特定の半径で特定の角度でこのビューに対して別のビューを配置できる円形の相対配置など、相対レイアウトとは別の追加機能もあります
繰り返しになりますが、制約レイアウトを使ってUIをデザインするのは、iOSでUIをデザインするのと同じなので、今後iOSで作業する場合は、制約レイアウトを使った方がやりやすいでしょう。
@ dhaval-jivaniの回答に加えて。
プロジェクトgithubプロジェクトを最新バージョンの制約レイアウト v.1.1.0-beta3 に更新しました
CPUモニターに表示されるonCreateメソッドの時間と、onCreateの開始から最後のpreformDrawメソッドの実行終了までの時間を測定して比較しました。すべてのテストは、Android 6.0.1 を搭載した Samsung S5 mini で行われました。結果は次のとおりです。
新たなスタート(アプリ起動後の最初の画面表示)
相対レイアウト
作成時: 123ms
最後の preformDraw 時間 - OnCreate 時間: 311.3ms
制約レイアウト
作成時: 120.3ms
最後の preformDraw 時間 - OnCreate 時間: 310ms
それに加えて、この記事、コードのパフォーマンス テストを確認 したところ、ループ カウントが 100 未満の制約レイアウト バリアントは、インフレート、メジャー、およびレイアウトの実行中に、相対レイアウトを使用したバリアントよりも高速であることがわかりました。また、Android 4.3 を搭載した Samsung S3 などの古い Android デバイスでは、違いはさらに大きくなります。
結論として、記事のコメントに同意します。
古いビュー スイッチを RelativeLayout または LinearLayout からリファクタリングする価値はありますか?
いつものように:場合によります
現在のレイアウト階層にパフォーマンスの問題があるか、とにかくレイアウトに大幅な変更を加えたい場合を除き、私は何もリファクタリングしません。最近は測定していませんが、最後のリリースではパフォーマンスの問題は見つかりませんでした。ですので、安心してご利用いただければと思います。しかし、私が言ったように、単に移行するためだけに移行しないでください。それが必要であり、それから利益が得られる場合にのみ、そうしてください。ただし、新しいレイアウトの場合は、ほぼ常に ConstraintLayout を使用します。私たちが以前持っていたものと比較して、はるかに優れています。
本当の質問は、制約レイアウト以外のレイアウトを使用する理由があるかということです。答えはノーかもしれないと思います。
初心者のプログラマーなどを対象としていると主張する人には、他のレイアウトよりも劣る何らかの理由を提供する必要があります。
Constraints レイアウトはあらゆる点で優れています (APK サイズで 150k ほどかかります)。それらはより速く、より簡単で、より柔軟で、変更によりよく反応し、アイテムがなくなったときに問題を修正し、根本的に異なる画面タイプによりよく適合し、それほど長いネストされたループの束を使用しません。すべてのツリー構造を引き出します。どこにでも、何に関しても、どこにでも置くことができます。
2016 年半ばには、ビジュアル レイアウト エディターが十分ではなかったので、少しおかしなことになりましたが、レイアウトがまったくない場合は、制約レイアウトの使用を真剣に検討する必要があるかもしれません。RelativeLayout
、または単純なと同じことを行う場合LinearLayout
。FrameLayouts
明らかにまだ目的があります。しかし、現時点では他に何かを構築することは考えられません。彼らがこれで始めたなら、彼らは他に何も追加しなかったでしょう.