android - ConstraintLayout 与 "Traditional"布局

Question

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

问题ConstraintLayout vs CoordinatorLayout已经向我展示了 CoordinatorLayout 仍然拥有它的存在权。 我想当只有一个子 View 时，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 artifact in your 模块的 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 构建，使其更容易 根据开发人员碰巧放置小部件的位置推断出正确的规则。

重新计算大小和位置

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

Does the ConstraintLayout have better performance then a nested Layout?

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

嗯，

有关更多信息，您可以查看 CommonsWare 的有关 android 开发的书籍。 使用 ConstraintLayout 更详细地解释了与其他容器(如 LinearLayout、RelativeLayout 等)的比较示例。真正剖析了 android 开发。