【问题标题】:Why are nested weights bad for performance? Alternatives?为什么嵌套权重对性能不利?备择方案?
【发布时间】:2012-03-14 21:41:44
【问题描述】:

我编写了几个布局文件,在其中我使用了layout_weight 属性来创建不同视图之间的比率。

在某些时候,我开始收到有关嵌套权重的 lint 警告。

所以,我想知道为什么嵌套权重对性能不利,以及是否有更有效的方法来创建可用于不同屏幕尺寸的视图尺寸之间的恒定比率,并且不需要指定很多通过多个布局文件(我的意思是针对不同的屏幕尺寸)维度 dpi 值。

谢谢!

【问题讨论】:

标签: android android-layout performance


【解决方案1】:

嵌套权重不利于性能,因为:

布局权重需要对小部件进行两次测量。当一个 具有非零权重的 LinearLayout 嵌套在另一个内部 具有非零权重的 LinearLayout,然后是测量次数 成倍增长。

最好使用RelativeLayouts,根据其他视图的位置调整你的视图,不要使用特定的dpi值。

【讨论】:

  • 需要注意的一点是,我想这就是消息的目的。我指出,如果所涉及的指数很小,指数影响仍然很小。对于小深度的嵌套,使用执行此操作所需的 CPU 就像拥有一匹你整周都在宠爱的主力马,只在星期天出去散步。尽管如此,对于大深度的嵌套来说,这是一个很好的观点。
  • RelativeLayout 也需要测量两次以确保其所有子布局正确,因此将具有布局权重的 LinearLayout 更改为 RelativeLayout 可能不会提高性能。
  • 相对布局并不总是有效。在您需要构建比例小部件的情况下
【解决方案2】:

更新:我们知道,API 级别 26 已弃用百分比支持库。ConstraintLayout 是实现相同扁平 xml 结构的新方法。

Updated Github Project

更新示例:

<android.support.constraint.ConstraintLayout 
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <TextView
        android:id="@+id/fifty_thirty"
        android:layout_width="0dp"
        android:layout_height="0dp"
        android:background="#ffff8800"
        android:gravity="center"
        android:text="@string/fifty_fifty_text"
        android:textColor="@android:color/white"
        app:layout_constraintHeight_default="percent"
        app:layout_constraintHeight_percent="0.5"
        android:textSize="25sp"
        app:layout_constraintTop_toTopOf="parent"
        app:layout_constraintWidth_default="percent"
        app:layout_constraintWidth_percent="0.5" />

    <TextView
        android:layout_width="0dp"
        android:layout_height="0dp"
        android:background="#ffff5566"
        android:gravity="center"
        android:text="@string/fifty_fifty_text"
        android:textColor="@android:color/white"
        android:textSize="25sp"
        app:layout_constraintHeight_default="percent"
        app:layout_constraintHeight_percent="0.5"
        app:layout_constraintLeft_toRightOf="@id/fifty_thirty"
        app:layout_constraintTop_toBottomOf="@id/fifty_thirty"
        app:layout_constraintWidth_default="percent"
        app:layout_constraintWidth_percent="0.5" />

</android.support.constraint.ConstraintLayout>

更新:好消息 android 百分比支持库解决了我们的性能问题和嵌套混乱加权 LinearLayout

compile 'com.android.support:percent:23.0.0'

Demo HERE

考虑这个简单的布局来演示。

<android.support.percent.PercentRelativeLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:layout_width="match_parent"
    android:layout_height="match_parent">
    <TextView
        android:id="@+id/fifty_huntv"
        android:layout_width="0dp"
        android:layout_height="0dp"
        android:background="#ff7acfff"
        android:text="20% - 50%"
        android:textColor="@android:color/white"
        app:layout_heightPercent="20%"
        app:layout_widthPercent="50%" />
    <TextView
        android:layout_width="0dp"
        android:layout_height="0dp"
        android:layout_toRightOf="@id/fifty_huntv"
        android:background="#ffff5566"
        android:text="80%-50%"
        app:layout_heightPercent="80%"
        app:layout_widthPercent="50%"
        />

</android.support.percent.PercentRelativeLayout>

避免了使用权重嵌套LinearLayout 的性能下降器。真的很棒!!!。

【讨论】:

  • @dan 是的,考虑到我们有带权重的嵌套线性布局。
  • “此类在 API 级别 26.0.0-beta1 中已弃用。请考虑改用 ConstraintLayout 和相关布局。” developer.android.com/reference/android/support/percent/…
  • 我不喜欢 ConstraintLayout。它对我来说并不直观
  • ConstraintLayout 对我来说太难了
  • 可能苹果在autolayout constraints上的解释比较清楚,因为逻辑一样,可以帮上忙。不幸的是,我发现 droid 的 ConstraintLayout 比 iOS 的 AutoLayout 更重/更冗长
【解决方案3】:

我认为(而且我可能会为此感到愤怒),但我再次认为我的手机有一个四核处理器,可以与大多数人的家用电脑相媲美(如果不是完全摧毁的话)。

我也认为这种硬件能力是手机的未来。

所以我得出一个结论,只要您不被嵌套所迷惑(在 MHO 中,布局的深度不应超过 4 层,如果是您可能做错了),您的手机可能不太关心体重。

您可以做很多事情来对性能产生更深远的影响,然后担心您的处理器会做一些额外的数学运算。

(请注意,我有点幽默,所以不要把这篇文章中的任何事情看得太认真,除了你应该首先优化其他东西的想法,以及担心 2-3 级深度权重对您的健康没有帮助)

【讨论】:

  • 接受并基本同意,但听说 iPhone 的平均使用量(包括支持其使用的网络服务/网站)每年的能源消耗量与美国家用冰箱的平均消耗量大致相同。因此,作为开发商,我们有责任考虑到这种环境影响。显然,它始终是一种平衡行为:时间、成本、性能、稳定性,总的来说,我确实同意你的观点——但只是认为我们也应该考虑这种影响。显然维护/可扩展性也在这里。无论如何 - 指出并感谢。
  • 意识到问题的具体点是关于设备上的处理而不是网络,但意味着我的评论是作为开发人员优先级的一般观点,而不是 OP 的细节。
【解决方案4】:

嵌套权重不好的主要原因是当一个布局有一个权重的孩子时,它必须测量两次(我认为这在 lint-warning 中提到了)。这意味着还包含加权布局的加权布局必须测量四次,并且您添加的每个“层”权重都会以 2 的幂增加度量。

在 ICS(API 级别 14)中添加了 GridLayout,它为许多以前需要权重的布局提供简单和“扁平”的解决方案。如果您正在为较早版本的 Android 进行开发,则移除权重会稍微困难一些,但使用 RelativeLayout 并将您的布局尽可能展平到该驾驶室中通常会移除大量嵌套的权重。

【讨论】:

  • 我不认为您可以使用GridLayout RelativeLayout 获得相同的结果。例如。对于GridLayout:“GridLayout 不提供对权重原则的支持,如权重中定义的那样。通常,因此无法配置 GridLayout 来在多个组件之间分配多余的空间。”
  • 从 API 21 开始,将权重的概念添加到 GridLayout。要支持较旧的 android 设备,您可以使用 v7 支持库中的 GridLayout。 android.support.v7.widget.GridLayout
【解决方案5】:

有一个简单的解决方案可以避免带有权重的嵌套 LinearLayouts - 只需使用带有 weightSum 的 Tablelayout 和带有 weightSum 的嵌套 LinearLayout - Tablelayout 具有与 LinearLayout 相同的属性(方向、weightSum、layout_weight 等)并且不显示消息 - “嵌套权重对性能不利”

例子:

 <TableLayout
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:orientation="vertical"
        android:weightSum="1">

        <ImageView
            android:layout_width="match_parent"
            android:layout_height="0dp"
            android:layout_weight="0.8"/>


        <LinearLayout
            android:layout_width="match_parent"
            android:layout_height="0dp"
            android:layout_weight="0.2"
            android:orientation="horizontal"
            android:weightSum="1">


            <ImageView
                android:layout_height="match_parent"
                android:layout_width="0dp"
                android:layout_weight="0.4"/>

            <TextView
                android:layout_height="match_parent"
                android:layout_width="0dp"
                android:layout_weight="0.6"/>


            </LinearLayout>

    </TableLayout>

【讨论】:

    【解决方案6】:

    我认为,唯一的选择是创建一个调用 onResume 并设置所有大小和位置的函数。无论如何,按重量,您只能设置大小但不能设置填充(因此布局变得更加复杂),没有 textSize(无法以某种方式补偿),更不用说诸如行数之类的事情了。

    【讨论】:

      猜你喜欢
      • 2012-04-22
      • 1970-01-01
      • 1970-01-01
      • 2014-07-11
      • 2013-01-21
      • 1970-01-01
      • 2012-11-26
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多