android - promedio - peso atomico
¿Por qué los pesos anidados son malos para el rendimiento? ¿Alternativas? (5)
He escrito un par de archivos de diseño donde utilicé el atributo layout_weight para crear una relación entre diferentes vistas.
En algún momento, comienzo a recibir advertencias sobre pelusas sobre los pesos anidados.
Entonces, me pregunto por qué los pesos anidados son malos para el rendimiento, y si hay una manera más eficiente de crear una relación constante entre dimensiones de vista que podrían usarse para diferentes tamaños de pantalla y que no necesita especificar muchos valores de ppp de dimensión. a través de varios archivos de diseño (para diferentes tamaños de pantalla, quiero decir).
¡Gracias!
Creo (y probablemente me llame la atención por esto), pero una vez más creo que mi teléfono tiene un procesador de cuatro núcleos para competir (si no destruir por completo) con la mayoría de las computadoras personales de las personas.
También creo que este tipo de capacidad de hardware es el futuro de los teléfonos.
Así que llegué a la conclusión de que, mientras no te dejes llevar por la anidación (en MHO, el diseño nunca debería tener más de 4 niveles de profundidad, y si es probable que lo estés haciendo mal), a tu teléfono no le importaría nada acerca de tener pesas.
Hay muchas cosas que puede hacer que tendrán un efecto mucho más extenso en el rendimiento y luego preocuparse de que su procesador haga algunos cálculos adicionales.
(Por favor, tenga en cuenta que estoy siendo un poco cómico, por lo que no tomo nada demasiado en serio de esta publicación, aparte de la idea de que hay otras cosas que debe optimizar primero, y que preocuparse por un nivel profundo de 2-3 niveles no ayuda tu salud)
Creo que la única alternativa es hacer una función que se llame onResume y establecerá todos los tamaños y posiciones. De todos modos, en peso puede establecer solo tamaños pero sin relleno (por lo que los diseños se vuelven aún más complicados), sin textSize (imposible de compensar de alguna manera), y mucho menos cosas como el número de líneas.
La razón principal por la cual los pesos anidados son malos es que cuando un diseño tiene niños con un peso, debe medirse dos veces (creo que esto se menciona en la advertencia de pelusas). Esto significa que un diseño ponderado que también contiene un diseño ponderado tiene que medirse cuatro veces, y cada ''capa'' de pesos que agregue aumentará las medidas con una potencia de dos.
En ICS (API nivel 14) se agregó GridLayout , que permite soluciones simples y ''planas'' para muchos diseños que anteriormente requerían ponderaciones. Si está desarrollando versiones anteriores de Android, tendrá un tiempo un poco más difícil para eliminar pesas, pero el uso de un RelativeLayout y el aplanamiento tanto como sea posible de su diseño en esa cabina suelen eliminar una gran cantidad de los pesos anidados.
Los pesos anidados son malos para el rendimiento porque:
Los pesos de diseño requieren que un artilugio se mida dos veces. Cuando un LinearLayout con pesos distintos de cero se anida dentro de otro LinearLayout con pesos distintos de cero, entonces el número de mediciones aumenta exponencialmente.
Siempre es mejor usar RelativeLayout y ajustar su vista de acuerdo con los lugares de otras vistas sin usar valores específicos de dpi.
Actualización: como sabemos, la biblioteca de soporte porcentual está obsoleta desde el nivel 26 de la API. ConstraintLayout es la nueva forma de lograr la misma estructura plana xml.
Muestras actualizadas:
<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>
Actualización: la gran biblioteca de soporte de porcentaje de android resuelve nuestro problema de rendimiento y LinearLayout ponderado desordenado ponderado
compile ''com.android.support:percent:23.0.0''
Considere este diseño simple para demostrar lo mismo.
<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>
El degradado de rendimiento LinearLayout ancló LinearLayout con pesos. ¡Realmente increíble!