Construír aplicacións de lona grandes e complexas

A maioría dos artigos desta sección da documentación cobren o rendemento en tempo de execución das aplicacións tal e como experimentan as persoas que as usan. Este artigo cobre o rendemento da aplicación tal e como experimentan as persoas que as fan.

A medida que as aplicacións se fan máis grandes e complexas, necesita cargar e xestionar un maior número de controis, fórmulas e fontes de datos, Power Apps Studio todo iso con interdependencias que crecen exponencialmente. Power Apps Studio Pode levar máis tempo para cargar, e características como IntelliSense e codificación de cores poden atrasarse. Utilice as recomendacións seguintes para traballar mellor con aplicacións grandes e complexas Power Apps Studio. Tamén poden axudar a mellorar o rendemento de tempo de execución das aplicacións.

Os exemplos deste artigo usan a solución da mostra de resposta a urxencias hospitalarias.

Use App.Formulas no canto de App.OnStart

A mellor forma de reducir o tempo de carga para ambos Power Apps Studio e a súa aplicación é substituír a inicialización variable e de recollida en App.OnStart por fórmulas nomeadas en App.Formulas.

Vexamos o seguinte exemplo, que usa App.OnStart.

// Get the color of text on a dark background.
Set(varColorOnDark,RGBA(0, 0, 0, 1));

// Get the color of the menu icons.
Set(varColorMenuIcon,"#0070a9");

// Get the styles for a form.
Set(varFormStyle,
    {
        DataCard: { Height: 50 },
        Title: { Height: 50, Size: 21, Color: varColorOnDark },
        Control: { Height: 50, Size: 18 },
        Label: { Size: 18, Color: varColorOnDark }
    }
);

ClearCollect(
    FacilitiesList,
    ForAll(
        Facilities,
        { Name: 'Facility Name', Id: Facility }
    )
);
If(
    Not IsBlank(Param("FacilityID")),
    Set(ParamFacility,
        LookUp(
            FacilitiesList,
            Id = GUID(Param("FacilityID"))
        ).Name
    );
);

Debido a que son unha secuencia de declaracións, a súa aplicación debe avaliar estas chamadas Set e Recoller en orde antes de que poida mostrar a primeira pantalla, o que fai que a carga da aplicación sexa máis lentamente. E debido a que toda a App.OnStart debe ser considerada como un todo, orde conservada e erros agregados antes de devolver o resultado final, a fórmula é complexa para Power Apps Studio analizar.

Hai un camiño mellor. Use App.Formulas no seu lugar e define estas variables e coleccións como fórmulas nomeadas, como no seguinte exemplo.

// Get the color of text on a dark background.
varColorOnDark = RGBA(0, 0, 0, 1);

// Get the color of the menu icons.
varColorMenuIcon = "#0070a9";

// Get the styles for a form.
varFormStyle = 
    {
        DataCard: { Height: 50 },
        Title: { Height: 50, Size: 21, Color: varColorOnDark },
        Control: { Height: 50, Size: 18 },
        Label: { Size: 18, Color: varColorOnDark }
    };

FacilitiesList =
    ForAll(
        Facilities,
        { Name: 'Facility Name', Id: Facility }
    );

ParamFacility = 
    If( Not IsBlank(Param("FacilityID")),
        LookUp(
            FacilitiesList,
            Id = GUID(Param("FacilityID"))
        ).Name,
        Blank()
    );

Este cambio pode parecer pequeno, pero pode ter un gran impacto. Debido a que cada fórmula nomeada é independente das outras, pode analizalas de forma independente, Power Apps Studio dividindo efectivamente unha gran App.OnStart en anacos máis pequenos. Vimos Power Apps Studio caer o tempo de carga ata un 80% con este cambio só.

A túa aplicación tamén carga máis rápido porque non ten que avaliar estas fórmulas ata que necesite o resultado. A primeira pantalla da aplicación móstrase inmediatamente.

As fórmulas nomeadas non se poden usar en todas as situacións porque non podes modificalas nin usalas con Set. Algunhas situacións requiren o uso dunha variable estatal que poida ser modificada. O conxunto é perfecto para estas situacións e debes seguir usándoo. Pero, con máis frecuencia que non, está a usar variables globais en OnStart para configurar valores estáticos que non cambian. Neses casos, unha fórmula nomeada é a mellor opción.

Dado que as fórmulas nomeadas son inmutables, o prefixo var (curto para "variable") como convención de nomes xa non é apropiado. Non cambiamos os nomes neste exemplo porque requiriría cambios no resto da aplicación para igualar.

É tentador colocar unha fórmula nomeada en App.OnStart, pero non. Non pertencen alí. Como propiedade sobre o comportamento, App.OnStart avalía cada unha das súas declaracións en orde, creando variables globais e falando con bases de datos só unha vez, cando se carga a aplicación. As fórmulas nomeadas son fórmulas que definen como calcular algo sempre que sexa necesario e sempre son certas. É esta fórmula natureza a que lles permite ser independentes e permite que a aplicación termine de carga antes de ser avaliada.

Dividir fórmulas longas

App.OnStart é un dos peores infractores para fórmulas longas e definitivamente onde debes comezar, pero non é o único caso.

Os nosos estudos demostraron que case todas as aplicacións cun longo tempo de carga teñen Power Apps Studio polo menos unha fórmula de máis de 256.000 caracteres. Algunhas aplicacións cos tempos de carga máis longos teñen fórmulas de máis de 1 millón de caracteres. Fórmulas que durante moito tempo poñen unha tensión Power Apps Studio significativa.

Para empeorar as cousas, copiar e pegar un control cunha fórmula longa duplica a fórmula nas propiedades do control sen que se realice. Power Apps Está modelado despois de Excel, onde son comúns múltiples copias dunha fórmula. Porén, nas fórmulas de Excel limítanse a unha expresión e están coroadas en 8.000 caracteres. Power Apps As fórmulas poden crecer moito máis tempo coa introdución da lóxica imperativa e o operador de encadernación (; ou ;;, dependendo da localización).

A solución xeral é dividir fórmulas longas en partes máis pequenas e reutilizar as partes, como fixemos na sección anterior cando cambiamos as declaracións de Set/Collect en App.OnStart para nomear fórmulas en App.Formulas. Noutras linguaxes de programación, as partes reutilizables denomínanse a miúdo subrutinas ou funcións definidas polo usuario. Pode pensar en fórmulas nomeadas como unha forma simple de función definida polo usuario sen parámetros nin efectos secundarios.

Usar fórmulas nomeadas en todas partes

No exemplo anterior, usamos fórmulas nomeadas como substituto de App.OnStart. Non obstante, podes usalos para substituír un cálculo en calquera lugar dunha aplicación.

Por exemplo, unha das pantallas da solución da mostra de resposta a urxencias hospitalarias inclúe esta lóxica en Screen.OnVisible:

ClearCollect(
    MySplashSelectionsCollection,
    {
        MySystemCol: First(
            Filter(
                Regions,
                Region = MyParamRegion
            )
        ).System.'System Name',
        MyRegionCol: First(
            Filter(
                Regions,
                Region = MyParamRegion
            )
        ).'Region Name',
        MyFacilityCol: ParamFacility,
          MyFacilityColID:  LookUp(
            FacilitiesList,
            Id = GUID(Param("FacilityID"))
        ).Id
    }
); 

Esta fórmula pode dividirse nun conxunto de fórmulas nomeadas. Tamén facilita a lectura da fórmula.

MyRegion = LookUp(
                    Regions,
                    Region = MyParamRegion
           );

MyFacility = LookUp(
                    FacilitiesList,
                    Id = GUID(Param("FacilityID")
            );

MySplashSelectionsCollection = 
    {
        MySystemCol: MyRegion.System.'System Name',
        MyRegionCol: MyRegion.'Region Name',
        MyFacilityCol: ParamFacility,
        MyFacilityColID:  MyFacility.Id
    };

Extraemos ParamFacility como fórmula nomeada anteriormente cando trasladamos a maioría das chamadas Set de App.OnStart para nomear fórmulas en App.Formulas.

As fórmulas nomeadas avalíanse só cando os seus valores son necesarios. Se a intención orixinal de usar Screen.OnVisible era aprazar o traballo ata que se mostra a pantalla, entón o traballo aínda se deduce como fórmulas nomeadas globais en App.Formulas.

Usar a función

Tamén podes usar a función Con nunha fórmula para dividir a lóxica. Crea un rexistro no primeiro parámetro cos valores que queres usar como campos e, a seguir, usa eses campos no segundo parámetro para calcular o valor de retorno de Con. Por exemplo, o exemplo anterior pode escribirse como unha fórmula nomeada:

MySplashSelectionsCollection = 
    With( { MyRegion: LookUp(
                            Regions,
                            Region = MyParamRegion
                      ),
            MyFacility: LookUp(
                            FacilitiesList,
                            Id = GUID(Param("FacilityID")
                      ) 
           },
           {
                MySystemCol: MyRegion.System.'System Name',
                MyRegionCol: MyRegion.'Region Name',
                MyFacilityCol: ParamFacility,
                MyFacilityColID:  MyFacility.Id
           }
    )

Un inconveniente de usar Con esta forma é que non pode usar porque están definidos na mesma MyFacility Con MyRegion función, un problema que non está presente con fórmulas nomeadas. Unha solución é aniñar Con funcións e usar a palabra clave para nomear o rexistro de cada un para dar fácil acceso a todas as variables Con variables.

Usar compoñentes do lenzo

Os compoñentes de lona son máis frecuentemente usados para crear un control de UI que se pode colocar no lenzo como un control. Tamén podes usalos sen colocalos na interface de usuario para realizar cálculos con propiedades de saída personalizadas como alternativa ás fórmulas nomeadas. Os compoñentes de lona son fáciles de compartir en aplicacións con bibliotecas de compoñentes e, a diferenza das fórmulas nomeadas, están totalmente soportados. Non obstante, son máis difíciles de configurar e usar que as fórmulas nomeadas.

Para dividir a lóxica:

1. En Power Apps Studio, cambie á pestana Compoñentes na vista Árbore.
2. Crear un compoñente novo.
3. No panel Propiedades, activa o alcance da aplicación de Access.
4. Engadir unha propiedade personalizada.
5. Establece o tipo de Propiedade á Saída e o Tipo de Datos segundo corresponda.
6. Seleccione Crear.
7. No piquete da propiedade xunto á barra de fórmulas da parte superior da pantalla, selecciona a nova propiedade.
8. Escribe a fórmula para que a lóxica se divida e reutilice.

Para utilizar a lóxica:

1. Mudar ao separador Pantallas na vista Árbore.
2. No panel Inserir , expanda personalizada e insira o seu compoñente.
3. Para calcular un valor coa propiedade, use ComponentName.PropertyName.

Seleccione con control oculto para lóxica imperativa

A lóxica imperativa úsase para modificar o estado con Set and Collect, notificar ao usuario con Notificar , navegar a outra pantalla ou aplicación con Navigate and Launch , e escribir valores a unha base de datos con · Patch, SubmitForm ou RemoveIf. ·

As fórmulas nomeadas e as propiedades de saída personalizadas do lenzo non soportan unha lóxica imperativa. Unha forma común de dividir a lóxica imperativa é usar a propiedade OnSelect dun control oculto.

1. Engade un control de Button á pantalla.
2. Configure a propiedade OnSelect á lóxica imperativa que desexa executar.
3. Establece a propiedade visible en falso, xa que non hai necesidade de que o usuario vexa ou interactúe con ela.
4. Chame Select( Button ) cando queira executar a lóxica imperativa.

Por exemplo, unha das pantallas da nosa mostra ten a seguinte propiedade OnSelect nun control de botón . (Este exemplo sinxelo é só para fins de ilustración. Normalmente, só usarías esta técnica para fórmulas máis longas.)

btnAction_17.OnSelect = 
    Trace("Feedback Screen: Submit Button",TraceSeverity.Information);
    If(
        // Proceed if all forms are validated.
        And(
            FormFeedback.Valid
        ),
    
        // Set the updates to static variables.
        Set(updatesFeedback,Patch(Defaults('App Feedbacks'), FormFeedback.Updates));
        // Submit the first form. Subsequent actions can be found in the OnSuccess.
        SubmitForm(FormFeedback);
        ,
    
        Notify("Please complete all fields before proceeding",
               NotificationType.Warning,2000)
    );

Para dividir esta lóxica en partes, podemos poñer porcións en controis separados de Button e seleccionalos do orixinal:

btnTrace.OnSelect = 
    Trace("Feedback Screen: Submit Button",TraceSeverity.Information);

btnSubmit.OnSelect = 
    If(
        // Proceed if all forms are validated.
        And(
            FormFeedback.Valid
        ),
    
        // Set the updates to static variables.
        Set(updatesFeedback,Patch(Defaults('App Feedbacks'), FormFeedback.Updates));
        // Submit the first form. Subsequent actions can be found in OnSuccess.
        SubmitForm(FormFeedback);
        ,
    
        Notify("Please complete all fields before proceeding",
               NotificationType.Warning,2000)
    );

btnAction_17.OnSelect = 
    Select( btnTrace );
    Select( btnSubmit );

Esta técnica só funciona na mesma pantalla. Outras técnicas que son un traballo lixeiramente máis complicado nas pantallas, como usar o control Toggle, configurar OnCheck á lóxica que quere executar e configurar Default a unha variable global e logo atrasar a variable global co Set( global, true ); Set( global, false ) punto que quere executar a lóxica.

Neste exemplo, xa se fixera algunha división lóxica. O comentario menciona que "as accións posteriores pódense atopar en OnSuccess". Este evento ten unha lóxica imperativa despois de que o rexistro fose presentado con éxito, unha solución específica para a función SubmitForm .

Partición da aplicación

Algunhas aplicacións crecen ata miles de controis e centos de fontes de datos, o que se retarda Power Apps Studio. Do mesmo xeito que coas fórmulas longas, as aplicacións grandes pódense dividir en seccións máis pequenas que traballan xuntas para crear unha experiencia de usuario.

Aplicacións de lona separadas

Un enfoque é implementar seccións en aplicacións de lona separadas e usar a función Lanzamento para navegar entre as aplicacións separadas e pasar o contexto necesario.

Este enfoque utilizouse na solución da mostra de resposta de urxencias hospitalarias. As aplicacións separadas xestionan cada unha das principais áreas da aplicación global. As aplicacións comparten un compoñente común de conmutación a través dunha biblioteca de compoñentes que cada aplicación mostra na súa pantalla de inicio:

Cando o usuario selecciona unha área, o compoñente usa metadatos sobre as aplicacións dispoñibles e que aplicación está aloxando o compoñente. Se a pantalla desexada está nesta aplicación (é dicir, ThisItem.Screen non está en branco), entón faise unha chamada Navigate . Pero se a pantalla desexada está nunha aplicación diferente (é dicir, ThisItem.PowerAppID non está en branco), entón úsase unha función de lanzamento co ID da aplicación do obxectivo e o contexto FacilityID :

If(
    IsBlank(ThisItem.Screen),
    If(IsBlank(ThisItem.PowerAppID), 
        Launch(ThisItem.URL),           
        Launch("/providers/Microsoft.PowerApps/apps/" & ThisItem.PowerAppID, 
               "FacilityID", Home_Facility_DD.Selected.Id)
    ),
    Navigate(
        ThisItem.Screen,
        Fade
    )
);

Estado na aplicación orixinal pérdese cando se lanza outra aplicación. Asegúrese de gardar calquera estado antes de chamar á función Lanzamento . Escríbeo a unha base de datos, chame a SaveData ou pase estado á aplicación de destino con parámetros que se len coa función Param .

Aplicación impulsada por modelos con páxinas personalizadas

As seccións tamén se poden implementar como páxinas personalizadas. As páxinas personalizadas actúan como unha aplicación mini canvas cun contedor de aplicacións impulsado por modelos para a navegación.