android - ConstraintLayout 与 "Traditional"布局

Question

我只是想知道什么时候选择 CoordinatorLayout 而不是“传统”布局，还是它们(或至少其中一些)会被弃用？

问题ConstraintLayout vs CoordinatorLayout已经向我展示了 CoordinatorLayout 仍然有其存在的权利。
我认为当只有一个 subview 时，FrameLayout 仍然是比 ConstraintLayout 更好的选择。

但是其他布局呢？

我个人非常习惯在 xml 中手动编写布局，因此转换到 ConstraintLayout 对我来说非常困难。此外，这个问题的答案会让我真正感兴趣:

ConstraintLayout 是否比嵌套布局具有更好的性能？如果是这种情况，会在什么时候发生(嵌套的级别)？

Answer 1

I am just wondering when to choose the CoordinatorLayout over "Traditional" Layouts or are they (or at least some of them) going to be deprecated?

所以ConstraintLayout很有用，但(目前)它不是 Android 应用程序开发所必需的，任何
超过LinearLayout和 RelativeLayout是。而且，因为 ConstraintLayout是一个
库，您需要采取一些额外的步骤将其添加到您的项目中( com.android.support.constraint:constraint-layout 工件在您的
模块的 build.gradle 文件的依赖项关闭)，并且它
为您的 Android 应用程序的大小增加了约 100KB。

I am personally so accustomed to writing layouts by hand in xml so transitioning to the ConstraintLayout is very hard for me.

拖放 GUI 生成器

Google 正努力让开发人员的生活更轻松，让他们的工作更快、更有效率，因此他们继续改进拖放式 GUI 构建器。然而拖放手势，开发者只是
根据开发者所在的位置为您提供小部件的 X/Y 坐标
释放鼠标按钮并完成放置。
与 LinearLayout添加小部件很容易。与 RelativeLayout GUI bulder 很难处理拖放操作，可能您必须深入研究 XML 代码才能完成任务。ConstraintLayout创建时考虑了 GUI 构建，以使其更容易
根据开发人员碰巧放置小部件的位置推断正确的规则。

重新计算大小和位置

更改小部件的详细信息通常会导致
必须重新计算的大小。例如 nne 更改 TextView可能
导致整个层次结构经历重新调整大小/重新定位的工作。如果您在另一个容器内的容器内有容器等，则意味着 parent 重新调整大小/重新定位他们的 child ，这可能非常
对于深层次结构来说代价高昂。
所以

Does the ConstraintLayout have better performance then a nested Layout?

是的，ConstraintLayout设计时考虑了性能，试图消除
尽可能多的通过场景，并试图消除对
深层嵌套的 View 层次结构。

呵呵，

有关更多信息，您可以查看来自 的一本关于 android 开发的书。 CommonsWare .
在那里使用 ConstraintLayout将通过与其他容器(如 LinearLayout)的比较示例进行更详细的说明。 , RelativeLayout等。真正解剖android 开发。