Jetpack Compose y mejores prácticas que siempre debe recordar: parte 2 | de Kaaveh Mohamedi | diciembre 2022

La optimización del rendimiento no es una solución única para todos.

Hay tantas variables que pueden afectar el rendimiento. Es mejor escribir puntos de referencia para la aplicación y encontrar y corregir cuellos de botella en el rendimiento. Esta es una regla general, no solo específica de Jetpack Compose. Escriba un punto de referencia para las pantallas activas en su aplicación. Es como escribir una prueba de IU: benchmarkRule.measureRepeated(packageName = PACKAGE_NAME,metrics = list0f(FrameTimingMetric()),compilationMode = compileMode,iterations = ITERATIONS,setupBlock = {…}) {val lazyColumn = device.findObject (By. res(«list»))repeat(3) {lazyColumn.drag(Point(0, lazyColumn.visibleCenter.y / 3))}} Como suele escuchar, el compilador de composición no se recompone en algunos escenarios, cuando está seguro algunas funciones componibles. Para lograr esto, el compilador de Compose marca todos los parámetros de las funciones componibles como Stable o Unstable . Entonces hay dos condiciones:

1. Inestable

Si al menos un parámetro de función componible está marcado como inestable, esa función nunca se puede omitir y recomponer cada vez.

2. Estable

Si todos los parámetros están marcados como estables, el compilador de composición busca cambios en el valor del parámetro. Si se cambia un parámetro, se produce el reensamblaje; de ​​lo contrario, omita el reensamblaje. Entonces, ¿qué tipos se consideran estables? Según documentos:

• Todos los objetos inmutables como todos primitivo tipos y instrumentos de cuerda. También clase de datos con Todo el mundo propiedad val (tipos que nunca cambian después de la construcción)
• Todos los objetos mutables que compila Compose son notificados de alguna manera cuando se cambia el valor. Como los objetos MutableState devueltos por mutableStateOf()

Hay una situación interesante. Las clases de colección como List, Set y Map siempre se determinan de manera inestable. ¿Pero por qué? Veamos un ejemplo: val contactList = mutableListOf(Contact(…)…)@Composablefun ContactList(contactList: List){…}Como habrás notado, una de las implementaciones de la interfaz de List es MutableList. La lista de contactos puede actualizarse fuera de la función componible (cada elemento se elimina o se agrega uno nuevo), y no hay forma de decirle al compilador que el parámetro ha cambiado (por eso lo envolvemos con Estado). Para hacer cumplir la inmutabilidad de las colecciones de Kotlin, se pueden usar las colecciones de Kotlinx inmutables. Por el contrario, todos los tipos no mencionados anteriormente se consideran inestables. Por ejemplo, todas las clases provienen de bibliotecas de terceros, incluso las clases de su modelo provienen de módulos no compuestos (como módulos de capa de dominio y datos).Estable vs. InestableDespués de todas las explicaciones, hay una pregunta importante: ¿es necesario atravesar el código base y comentar todas las clases para hacerlas estables? En primer lugar, esforzarse por lograr la omisión total es una optimización prematura. Debe tener en cuenta la estabilidad cuando se enfrenta a problemas de rendimiento. En segundo lugar, como dijo Leland Richardson, uno de los ingenieros de software que trabajan en el compilador Compose:

Mi trabajo es evitar que los desarrolladores tengan que luchar con la estabilidad de los parámetros.

Creo que en las próximas versiones del compilador necesitará saber menos sobre la estabilidad de los parámetros. Pero si desea obtener más información sobre la estabilidad, consulte este video de Leland: