在开发过程中，我遇到了一个问题：每个布局需要多少资源？（线性、相对、制表符、约束、协调器）
在复杂的应用程序视图中，使用极其轻量级的布局是否合理？
RError.com
在开发过程中，我遇到了一个问题：每个布局需要多少资源？（线性、相对、制表符、约束、协调器）
在复杂的应用程序视图中，使用极其轻量级的布局是否合理？
一般情况下，单层布局，资源消耗升序排列：
FrameLayout - 线性布局 - 相对布局 - 约束布局
但是，当将一个容器嵌套到另一个容器中时，资源消耗会显着增加。由于在实践中很少有这样的布局，其中一个简单的容器（如 Frame 或 Linear）就足够了，在大多数情况下，ConstraintLayout 将是最好的解决方案，作为一个容器，最初被认为是一个单层的并且有大量的用于舒适实现几乎任何布局的属性，无需将一个容器嵌套到另一个容器中。这是它相对于简单容器的优势，但如果你把其他容器放在里面，它就会丢失。
另一方面，如果布局可以在单级FrameLayout（例如，Fragment的容器）或LinearLayout（例如，列表项）中进行布局，那么这将是一个更优化的解决方案资源消耗方面。
TableLayout是一个两级LinearLayout（垂直嵌套水平）
一方面，RelativeLayout 比 ConstraintLayout 轻一些，另一方面，它在小部件定位方面显着输给了它，并且可能目前需求量不大。
CoordinatorLayout、AppBarLayout 之类的东西没有实现替代方案，它们的资源消耗仅从是否使用它的位置来评估，尽管它们背后似乎对资源没有特别的胃口。
不同布局的多重测试：不同容器的性能比较，嵌套容器与ConstraintLayout
您还可以使用Hierarchy Viewer 工具来评估标记性能。从工作室版本 3 开始，它已被弃用，并且提供了 Layout Inspector 作为替代品，但它没有显示渲染布局的时间。
现在您可以从 Android 设备监视器启动 Hierarchy Viewver，而后者又可以从文件夹启动
PS：现在google推荐通过Systrace来评估UI性能，但是它的结果不如Hierarchy Viewr那么简单直观