Mejorar el rendimiento con orígenes de datos
En la unidad anterior, vimos que los orígenes de datos suelen ser la razón principal de que el rendimiento de la aplicación sea lento. En esta unidad, veremos algunas de las técnicas más habituales que se pueden usar para mitigar los problemas de rendimiento.
Usar colecciones para almacenar datos en caché
A menudo veremos que, en la aplicación, consultamos los mismos datos varias veces, como cuando extraemos las listas de departamentos de los menús desplegables. En estos casos, los datos se pueden consultar una vez y después volver a utilizarlos en cualquier parte de la aplicación. Esto reduce las llamadas repetitivas al origen de datos a través de la red. A continuación se muestra un ejemplo de este proceso.
En la aplicación tenemos varias pantallas en las que incluimos un menú desplegable para seleccionar el departamento. La lista de departamentos se mantiene en Microsoft Dataverse en una tabla denominada DepartmentList. En cada instancia del menú usaremos la siguiente fórmula.
Filter(DepartmentList, Status = "Active")
Esto funciona y se realiza correctamente.
Cuando terminamos la aplicación, nos damos cuenta de que estamos consultando la tabla DepartmentList varias veces, a pesar de que es información estática. Con la siguiente fórmula, podemos modificar la aplicación para crear una colección con la propiedad OnStart de la aplicación que almacena la información.
Collect(collectDepartmentList, Filter(DepartmentList, Status = "Active"))
Ahora que tenemos almacenada esa información, podríamos cambiar la propiedad Items de los controles desplegables para que sea collectDepartmentList en lugar de Filter(DepartmentList, Status = "Active"). Estos pequeños cambios contribuyen a aumentar el rendimiento de la aplicación. Además, a medida que vayamos familiarizándonos con la técnica, podremos crear la aplicación así desde el principio, lo que reduce el número de fórmulas que es necesario escribir y mantener.
Tener en cuenta la delegación
Algo que debe tenerse en cuenta es que la función Collect no es delegable. Esto significa que, de forma predeterminada, solo se devolverán y almacenarán en la colección los primeros 500 elementos del origen de datos. Tenga presente esta limitación cuando implemente el uso de colecciones en la aplicación.
La delegación también afecta al rendimiento
Cuando vimos la delegación, nos centramos en obtener el número adecuado de filas en relación con el origen de datos. También es importante recordar que la delegación puede afectar al rendimiento, especialmente en las aplicaciones móviles.
Cuando una fórmula delega en el origen de datos, todo el procesamiento se controla mediante el origen de datos, y solo se devuelven las filas coincidentes a través de la red a la aplicación para mostrarlos. Si una función no es delegable, es común cambiar el límite de delegación a 2000 filas. Esto significa que se descargarán las 2000 primeras filas en toda la red y, seguidamente, se procesarán localmente. En escenarios donde la conexión de telefonía móvil sea lenta o se tenga un dispositivo móvil de gama baja, este procesamiento puede tardar una cantidad considerable de tiempo y, en consecuencia, derivar en una mala experiencia para el usuario.
Pruebe a utilizar solo funciones delegables en la medida de lo posible. Si la función no es delegable, tenga previsto el impacto en el usuario final.
Usar la función Concurrent para cargar varios orígenes de datos
Ya hemos aprendido a usar colecciones para almacenar datos en caché en la aplicación. A medida que vamos implementando esa funcionalidad en la aplicación, no es raro que se carguen varias colecciones cuando la aplicación se inicia. La propiedad OnStart podría ser como la siguiente.
Collect(collectDepartmentList, Filter(DepartmentList, Status =
"Active")); Collect(collectCompanyList,
CompanyList);Collect(collectRegions, RegionList)
En este ejemplo, estamos creando tres colecciones, pero se procesan una a una. Por lo tanto, si cada una tarda 3 segundos en procesarse, el usuario tendrá que esperar 9 segundos para que la aplicación se inicie.
La función Concurrent permite procesar todas esas llamadas al mismo tiempo. Puede cambiar el código por el siguiente.
Concurrent(
Collect(collectDepartmentList, Filter(DepartmentList, Status = "Active")),
Collect(collectCompanyList, CompanyList),
Collect(collectRegions, RegionList)
)
Ahora las tres fórmulas se ejecutan al mismo tiempo. Por tanto, el tiempo de carga se reduce a 3 segundos. Concurrent es una excelente manera de evitar demoras de llamadas asincrónicas.
Características experimentales y en vista preliminar
Power Apps cuenta con otras características avanzadas que puede implementar en su aplicación. Para acceder a ellas, seleccione Archivo en la barra de menús y elija Configuración de la aplicación y Configuración avanzada. La lista de opciones que aparece cambia constantemente, pero siempre suele haber una o varias características relacionadas con el rendimiento.
Características en vista previa
Las características en vista previa son características que se han probado y que están a punto de lanzarse. En breve estarán disponibles para todas las aplicaciones. Probar y conocer estas características ayuda a prepararse para cuando se conviertan en estándar, y la mayoría están habilitadas de forma predeterminada en las aplicaciones nuevas.
Un ejemplo de una característica en vista preliminar actual que ayuda a aumentar el rendimiento es la carga retrasada. Esta característica "acelera el tiempo de inicio de la aplicación mediante el establecimiento de llamadas de expresión de pantalla a petición", lo que significa que las pantallas no se procesan hasta que el usuario accede a la pantalla, lo que hace que la aplicación se inicie y ejecute con mayor rapidez.
Características experimentales
Las características experimentales son características que pueden o no cambiar, interrumpirse o desaparecer en cualquier momento. Las características experimentales están desactivadas de forma predeterminada. Aquí también suele haber características de rendimiento, por lo que merece la pena echarles un vistazo. No olvide, sin embargo, que al incorporarlas en aplicaciones de producción estará corriendo un riesgo, ya que pueden evolucionar, cambiar completamente o desaparecer.
En ocasiones, es posible que vea una característica experimental relacionada con el rendimiento de la aplicación. Siempre puede habilitarla y probarla y, luego, volver a Configuración para deshabilitarla.
Comparación entre OnStart y OnVisible
OnStart y OnVisible forman parte del kit de herramientas para crear aplicaciones increíbles, pero desde el punto de vista del rendimiento pueden tener un impacto muy considerable.
OnStart: se trata de una propiedad de nivel de la aplicación. Las fórmulas de esta propiedad se ejecutan una vez (cuando la aplicación se inicia) y nunca más vuelven a hacerlo. Todas las fórmulas deben procesarse antes de que la aplicación se abra. A menudo, esto sirve para inicializar los datos que se necesitarán en cualquier parte de la aplicación.
OnVisible: se trata de una propiedad de pantalla. Las fórmulas de esta propiedad se ejecutan cada vez que un usuario navega a la pantalla en cuestión. La pantalla se presentará antes de que la fórmula termine de procesarse.
Desde el punto de vista del rendimiento, la consideración principal es cuándo se ejecuta el código: es decir, una vez (cuando la aplicación se inicia) o cada vez que una pantalla se abra. La colección de departamentos que vimos anteriormente en este módulo es un buen ejemplo. Ese código se carga en la propiedad OnStart de la aplicación. Esto significa que se cargó una vez y, tras ello, siempre estará disponible. Si moviéramos ese código de OnStart a OnVisible, perderíamos la ventaja que la colección reporta. Si la fórmula estuviera en la propiedad OnVisible, el origen de datos se consultaría cada vez que el usuario navegase a la pantalla. En este caso, el rendimiento sería igual de bueno si dejáramos el código en la lista desplegable.
Pero esto no significa que OnVisible no deba usarse. OnVisible es una opción excelente en fórmulas que pertenecen a la pantalla actual que debe ejecutar. Además, OnVisible no bloquea. Por lo tanto, los usuarios no tendrán que esperar a que la fórmula termine para ver la pantalla, lo que reduce la cantidad que el usuario necesita para ver una pantalla en blanco.
En la mayoría de las aplicaciones, se usa una combinación de OnStart y OnVisible para obtener una experiencia óptima.
Resumen
Como puede observar, existen muchas opciones a la hora de crear una aplicación e interactuar con orígenes de datos. La lista que se incluye en esta unidad está lejos de ser exhaustiva. Las instrucciones aquí proporcionadas están pensadas para guiarle con el fin de lograr un mejor rendimiento, pero los resultados pueden variar. Cuando empiece a poner en práctica estas técnicas en sus aplicaciones, sabrá qué funciona mejor para usted y su entorno.
En la siguiente unidad, conoceremos algunas técnicas de pruebas y solución de problemas.