Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Importante
A partire da Windows 10, versione 1703 (Creators Update), x:DeferLoadStrategy viene sostituito dall'attributo x:Load. L'uso x:Load="False" è equivalente a x:DeferLoadStrategy="Lazy", ma offre la possibilità di scaricare l'interfaccia utente, se necessario. Per altre informazioni, vedi l'attributo x:Load .
Puoi usare x:DeferLoadStrategy="Lazy" per ottimizzare le prestazioni di creazione dell'albero o dell'avvio dell'app XAML. Quando si usa x:DeferLoadStrategy="Lazy", la creazione di un elemento e dei relativi elementi figlio viene ritardata, riducendo i costi di tempo di avvio e memoria. Ciò è utile per ridurre i costi degli elementi visualizzati raramente o in modo condizionale. L'elemento verrà realizzato quando viene fatto riferimento al codice o a VisualStateManager.
Tuttavia, il rilevamento degli elementi posticipati dal framework XAML aggiunge circa 600 byte all'utilizzo della memoria per ogni elemento interessato. Più grande è l'albero degli elementi che si posticipa, maggiore sarà il tempo di avvio risparmiato, ma a costo di un'impronta di memoria maggiore. Pertanto, è possibile abusare di questo attributo al punto che le prestazioni peggiorano.
Utilizzo degli attributi XAML
<object x:DeferLoadStrategy="Lazy" .../>
Osservazioni:
Le restrizioni per l'uso di x:DeferLoadStrategy sono:
- È necessario definire un valore x:Name per l'elemento, perché è necessario trovare l'elemento in un secondo momento.
- È possibile rinviare solo i tipi che derivano da UIElement o FlyoutBase.
- Non è possibile rinviare gli elementi radice in una pagina, in un oggetto UserControl o in un oggetto DataTemplate.
- Non è possibile rinviare gli elementi in un ResourceDictionary.
- Non è possibile rimandare XAML non fissi caricati con XamlReader.Load.
- Lo spostamento di un elemento padre cancella tutti gli elementi che non sono stati realizzati.
Esistono diversi modi per realizzare gli elementi posticipati:
- Chiamare FindName con il nome definito nell'elemento .
- Chiamare GetTemplateChild con il nome definito nell'elemento .
- In visualState usa un'animazione Setter o Storyboard destinata all'elemento posticipato.
- Specificare come destinazione l'elemento posticipato in qualsiasi storyboard.
- Usare un'associazione che mira all'elemento differito.
NOTA: Una volta avviata l'istanza di un elemento, questa viene creata nel thread dell'interfaccia utente, il che potrebbe causare l'interfaccia a balbettare se viene generata una quantità eccessiva contemporaneamente.
Dopo la creazione di un elemento posticipato in uno dei modi elencati in precedenza, vengono eseguite diverse operazioni:
- Viene generato l'evento Loaded sull'elemento.
- Tutte le associazioni sull'elemento vengono valutate.
- Se è stata effettuata la registrazione per ricevere notifiche di modifica delle proprietà sulla proprietà contenente gli elementi posticipati, viene generata la notifica.
È possibile annidare gli elementi posticipati, ma devono essere realizzati partendo dall'elemento più esterno verso l'interno. Se si tenta di realizzare un elemento figlio prima che l'elemento padre sia stato realizzato, viene generata un'eccezione.
In genere, è consigliabile rinviare gli elementi che non sono visualizzabili nel primo fotogramma. Una buona linea guida per trovare i candidati da rinviare consiste nel cercare gli elementi creati con visibilità compressa. Inoltre, l'interfaccia utente attivata dall'interazione dell'utente è un buon posto per cercare gli elementi che è possibile rinviare.
Evitare di rinviare gli elementi in un controllo ListView, poiché può ridurre il tempo di avvio, ma potrebbe anche influire negativamente sulle prestazioni di scorrimento a seconda di ciò che si sta creando. Per migliorare le prestazioni di panoramica, vedere la documentazione relativa all'estensione di markup {x:Bind} e all'attributo x:Phase .
Se l'attributo x:Phase viene usato insieme a x:DeferLoadStrategy , quando viene realizzato un elemento o un albero di elementi, le associazioni vengono applicate fino a e includendo la fase corrente. La fase specificata per x:Phase non influisce né controlla il ritardo dell'elemento. Quando un elemento di elenco viene riciclato come parte della panoramica, gli elementi realizzati si comportano nello stesso modo degli altri elementi attivi e le associazioni compilate ({x:Bind} associazioni) vengono elaborate usando le stesse regole, inclusa la suddivisione in fasi.
Una linea guida generale consiste nel misurare le prestazioni dell'app prima e dopo per assicurarsi di ottenere le prestazioni desiderate.
Example
<Grid x:Name="DeferredGrid" x:DeferLoadStrategy="Lazy">
<Grid.RowDefinitions>
<RowDefinition Height="Auto" />
<RowDefinition Height="Auto" />
</Grid.RowDefinitions>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="Auto" />
<ColumnDefinition Width="Auto" />
</Grid.ColumnDefinitions>
<Rectangle Height="100" Width="100" Fill="#F65314" Margin="0,0,4,4" />
<Rectangle Height="100" Width="100" Fill="#7CBB00" Grid.Column="1" Margin="4,0,0,4" />
<Rectangle Height="100" Width="100" Fill="#00A1F1" Grid.Row="1" Margin="0,4,4,0" />
<Rectangle Height="100" Width="100" Fill="#FFBB00" Grid.Row="1" Grid.Column="1" Margin="4,4,0,0" />
</Grid>
<Button x:Name="RealizeElements" Content="Realize Elements" Click="RealizeElements_Click"/>
private void RealizeElements_Click(object sender, RoutedEventArgs e)
{
// This will realize the deferred grid.
this.FindName("DeferredGrid");
}