Novembre 2015
Volume 30 Numero 12
Il presente articolo è stato tradotto automaticamente.
Windows 10 - Accelera le operazioni su file con l'Indicizzatore ricerca
Da Wilson Adam | Novembre 2015
L'indicizzatore di ricerca è stata che una parte di Windows per molti rilascia a questo punto, potenziamento di tutti gli elementi con le viste di libreria in Esplora File per la barra degli indirizzi di Internet Explorer, nonché di fornire funzionalità di ricerca per il menu Start e Outlook. Con Windows 10, la potenza dell'indicizzatore è passato da vengano limitate ai computer desktop, è sempre disponibile per tutte le app universale Windows Platform (UWP). Sebbene in tal modo Cortana eseguire ricerche migliore, la parte più interessante di questo miglioramento è che migliora notevolmente interagiscono delle applicazioni con il file system.
L'indicizzatore consente applicazioni più interessanti operazioni quali l'ordinamento e raggruppamento dei file e rilevamento cambiamenti nel file system. La maggior parte delle API l'indicizzatore sono disponibile per applicazioni UWP tramite gli spazi dei nomi storage e Windows.Storage.Search. Applicazioni utilizza già l'indicizzatore per consentire esperienze all'avanguardia per gli utenti. In questo articolo verranno esaminate come è possibile utilizzare l'indicizzatore per tenere traccia delle modifiche nel file system, il rendering di visualizzazioni rapidamente e offrono alcuni suggerimenti su come migliorare le query di un'applicazione base.
Accedere rapidamente a file e metadati
La maggior parte dei dispositivi utente contengono centinaia o migliaia di file multimediali che includono più immagini mai piacevole e brani preferiti dell'utente. Le applicazioni che possono scorrere rapidamente i file nel dispositivo e offerta stimolare le interazioni con i file sono tra le applicazioni più amato su qualsiasi piattaforma. Il UWP fornisce una serie di classi che può essere utilizzato per accedere ai file su qualsiasi dispositivo, indipendentemente dal fattore di forma.
Lo spazio dei nomi storage include le classi di base per l'accesso ai file e cartelle, nonché le operazioni di base che la maggior parte delle applicazioni non li. Ma se l'applicazione deve accedere una notevole quantità di file o i metadati quindi queste classi non forniscono le caratteristiche delle prestazioni che richiedono agli utenti.
Ad esempio, chiamata StorageFolder.GetFilesAsync è disponibile una soluzione per emergenza se non si controllano la cartella che è stata l'enumerazione. Gli utenti possono inserire miliardi di file in una singola directory, ma il tentativo di creare oggetti StorageFile per ognuno di essi causerà un'app in modo estremamente rapido esaurimento della memoria. Anche nei casi più estremi la chiamata restituirà ancora molto lentamente in quanto il sistema deve creare migliaia di handle di file e li il marshalling nel contenitore delle app. Per consentire applicazioni di evitare questo problema, il sistema fornisce le classi StorageFileQueryResults e StorageFolderQueryResults.
StorageFileQueryResults è il passaggio a classe ogni volta che la scrittura di un'applicazione di handle di più di un numero di file semplice. Non solo fornisce un metodo chiaro per enumerare e modificare i risultati di una query di ricerca complessa, tuttavia, poiché l'API tratta di una richiesta di enumerazione come una query per "*," funziona anche per i casi più comuni.
Utilizzando l'indicizzatore laddove disponibili è il primo passaggio per velocizzare l'applicazione. A questo punto, provenienti da program manager, un indicizzatore che sembra essere chiedono self-gestisce per Mantieni impiegate, ma esiste un motivo logico detto. Gli oggetti StorageFile e StorageFolder erano stati progettati con l'indicizzatore in mente. La proprietà memorizzati nella cache l'oggetto possono essere recuperate rapidamente dall'indicizzatore. Se non si utilizza l'indicizzatore, il sistema deve cercare valori dal disco e del Registro di sistema, che contiene I/O e causi problemi di prestazioni per l'applicazione e il sistema.
Per assicurarsi che l'indicizzatore sta per essere utilizzato, creare un oggetto QueryOptions e impostare la proprietà QueryOptions.IndexerOption di utilizzare solo l'indicizzatore:
QueryOptions options = new QueryOptions();
options.IndexerOption = IndexerOption.OnlyUseIndexer;
In alternativa, utilizzare l'indicizzatore quando è disponibile:
options.IndexerOption = IndexerOption.UseIndexerWhenAvailable;
Utilizzo consigliato è per i casi in cui un'operazione lenta file non verrà bloccata l'applicazione o manipolare l'esperienza utente per l'utilizzo di IndexerOption.UseIndexerWhenAvailable. Si tenterà di utilizzare l'indicizzatore per enumerare i file, ma tentare di molto più lente operazioni su disco, se necessario. Quando viene restituito alcun risultato è migliore in attesa di un'operazione lenta dei file, è consigliabile utilizzare IndexerOption.OnlyUseIndexer. Il sistema restituirà zero se l'indicizzatore è disabilitata, ma verrà restituita rapidamente, lasciando App essere reattiva all'utente.
Esistono situazioni che sembra un po' eccessiva per un'enumerazione di rapida creazione di un oggetto QueryOptions e, in questi casi, potrebbe essere utile se è presente l'indicizzatore. Per i casi in cui è controllare il contenuto della cartella, la chiamata a StorageFolder.GetItemsAsync ha senso. È una semplice riga di codice da scrivere e verranno nascoste eventuali problemi di prestazioni nei casi in cui sono presenti solo alcuni file nella directory.
Un altro modo per velocizzare l'enumerazione dei file è di non creare oggetti StorageFile o StorageFolder non necessari. Anche quando si utilizza l'indicizzatore, l'apertura di un StorageFile richiede al sistema di creare un handle di file, raccogliere alcuni dati di proprietà ed eseguirne il marshalling nel processo dell'applicazione. Questo IPC è dotato di ritardi inerenti, che possono essere evitati in molti casi evitando di creare gli oggetti in primo luogo.
È importante sottolineare, un oggetto StorageFileQueryResult supportato dall'indicizzatore non è possibile creare qualsiasi StorageFiles internamente. Vengono creati su richiesta quando richiesto tramite GetFilesAsync. Fino a quel momento, il sistema mantiene un elenco dei file solo in memoria, è relativamente semplice.
Il metodo consigliato per enumerare un numero elevato di file consiste nell'utilizzare la funzionalità batch su GetFilesAsync alla pagina in gruppi di file come sono necessari. In questo modo, è possibile eseguire l'applicazione in background sui file di elaborazione durante l'attesa per il successivo impostato da creare. Il codice in Figura 1 viene illustrato come farlo in un semplice esempio.
Figura 1 GetFilesAsync
uint index = 0, stepSize = 10;
IReadOnlyList<StorageFile> files = await queryResult.GetFilesAsync(index, stepSize);
index += 10;
while (files.Count != 0)
{
var fileTask = queryResult.GetFilesAsync(index, stepSize).AsTask();
foreach (StorageFile file in files)
{
// Do the background processing here
}
files = await fileTask;
index += 10;
}
Questo è lo stesso schema di codifica utilizzato da un numero di applicazioni già in Windows. Variando le dimensioni di passaggio sono in grado di estrarre il numero di elementi da disporre di una visualizzazione prima reattiva nell'app durante il dispositivo rapidamente il resto del file in background.
Proprietà prelettura è un altro modo semplice per velocizzare l'applicazione. Proprietà prelettura consente comunicare al sistema che è interessato in un determinato set di proprietà del file app. Il sistema ottenere le proprietà dall'indicizzatore mentre esegue l'enumerazione un set di file e memorizzarle nella cache nell'oggetto StorageFile. Ciò offre un incremento delle prestazioni semplice e la semplice raccolta di proprietà a fasi quando vengono restituiti i file.
Impostare i valori di prelettura di proprietà nell'oggetto QueryOptions. Sono supportati alcuni scenari comuni utilizzando il PropertyPrefetchOptions, ma anche le applicazioni sono in grado di personalizzare le proprietà richieste per tutti i valori supportati da Windows. Il codice per eseguire questa operazione è semplice:
QueryOptions options = new QueryOptions();
options.SetPropertyPrefetch(PropertyPrefetchOptions.ImageProperties,
new String[] { });
In questo caso, l'applicazione utilizza le proprietà dell'immagine e non necessita di tutte le altre proprietà. Quando il sistema sta enumerando i risultati della query, memorizza nella cache le proprietà dell'immagine in memoria in modo che siano disponibili rapidamente in un secondo momento.
Un'ultima osservazione è che la proprietà deve essere archiviato nell'indice per la prelettura per offrire un miglioramento delle prestazioni; in caso contrario, il sistema sarà ancora necessario accedere al file per trovare il valore, che è relativamente molto lento. La pagina di Microsoft Windows Developer Center per il sistema di proprietà (bit.ly/1LuovhT) contiene tutte le informazioni sulle proprietà disponibili in indicizzatore di Windows. Cercare solo isColumn = true nella descrizione della proprietà, che indica la proprietà è disponibile per essere eseguita la prelettura.
Unione di tutti questi miglioramenti consente al codice molto più velocemente. Per un esempio semplice, ho scritto un'applicazione che recupera tutte le immagini nel computer e l'altezza verticale. Questo è il primo passaggio che un'applicazione di visualizzazione delle foto dovrebbero adottare per visualizzare la raccolta di foto dell'utente.
Ho eseguito tre esecuzioni per provare i diversi stili di enumerazione di file e visualizzare le differenze tra di essi. Il primo test utilizzato codice Naive con l'indicizzatore abilitata come illustrato nella Figura 2. Il secondo test utilizzato il codice illustrato nella Figura 3, che esegue la prelettura di proprietà e pagine in file. E utilizza la terza proprietà prelettura e i file di paging in, ma con l'indicizzatore disabilitato. Questo codice è analogo a quello di Figura 3, ma con una riga modificata come indicato nei commenti.
Figura 2 Naive codice l'enumerazione di una libreria
StorageFolder folder = KnownFolders.PicturesLibrary;
QueryOptions options = new QueryOptions(
CommonFileQuery.OrderByDate, new String[] { ".jpg", ".jpeg", ".png" });
options.IndexerOption = IndexerOption.OnlyUseIndexer;
StorageFileQueryResult queryResult = folder.CreateFileQueryWithOptions(options);
Stopwatch watch = Stopwatch.StartNew();
IReadOnlyList<StorageFile> files = await queryResult.GetFilesAsync();
foreach (StorageFile file in files)
{
IDictionary<string, object> size =
await file.Properties.RetrievePropertiesAsync(
new String[] { "System.Image.VerticalSize" });
var sizeVal = size["System.Image.VerticalSize"];
}
watch.Stop();
Debug.WriteLine("Time to run the slow way: " + watch.ElapsedMilliseconds + " ms");
Figura 3 per l'enumerazione di una libreria di codice ottimizzato
StorageFolder folder = KnownFolders.PicturesLibrary;
QueryOptions options = new QueryOptions(
CommonFileQuery.OrderByDate, new String[] { ".jpg", ".jpeg", ".png" });
// Change to DoNotUseIndexer for trial 3
options.IndexerOption = IndexerOption.OnlyUseIndexer;
options.SetPropertyPrefetch(PropertyPrefetchOptions.None, new String[] { "System.Image.VerticalSize" });
StorageFileQueryResult queryResult = folder.CreateFileQueryWithOptions(options);
Stopwatch watch = Stopwatch.StartNew();
uint index = 0, stepSize = 10;
IReadOnlyList<StorageFile> files = await queryResult.GetFilesAsync(index, stepSize);
index += 10;
// Note that I'm paging in the files as described
while (files.Count != 0)
{
var fileTask = queryResult.GetFilesAsync(index, stepSize).AsTask();
foreach (StorageFile file in files)
{
// Put the value into memory to make sure that the system really fetches the property
IDictionary<string,object> size =
await file.Properties.RetrievePropertiesAsync(
new String[] { "System.Image.VerticalSize" });
var sizeVal = size["System.Image.VerticalSize"];
}
files = await fileTask;
index += 10;
}
watch.Stop();
Debug.WriteLine("Time to run: " + watch.ElapsedMilliseconds + " ms");
Uno sguardo ai risultati con e senza la prelettura, la differenza nelle prestazioni è molto chiara, come illustrato nella Figura 4.
Figura 4 risultati con e senza prelettura
| Test Case (2.600 immagini su un computer Desktop) | Media di più di 10 campioni fase di esecuzione |
| Codice Naive + indicizzatore | 9,318ms |
| Tutte le ottimizzazioni + indicizzatore | 5,796ms |
| Le ottimizzazioni + Nessun indicizzatore | 20,248ms (48,420ms a freddo) |
Esiste la possibilità di quasi raddoppiare le prestazioni del codice Naive applicando le ottimizzazioni di semplice descritte in questo argomento. I modelli sono sperimentati, nonché. Prima di rilasciare qualsiasi versione di Windows si lavora con i team di app che alle foto, musica Groove e altri sono funzionante nonché possibili. Ovvero provenienza questi modelli; essi sono stati cribbed direttamente dal codice le applicazioni attive UWP prima sul UWP e possono essere applicati direttamente alle applicazioni.
Rilevamento delle modifiche nel File System
Come illustrato di seguito, l'enumerazione di tutti i file in un percorso è un processo di risorse. La maggior parte dei casi, gli utenti non ancora verranno interessati a file meno recenti. Desiderano l'immagine ha appena eseguiti, il brano è stato appena scaricato o il documento modificato di recente. Per portare i file più recenti all'inizio, l'applicazione può tenere traccia delle modifiche nel file System e trovare più di recente file creati o modificati facilmente.
Esistono due metodi di rilevamento delle modifiche a seconda se l'applicazione è in background o in primo piano. Quando un'applicazione è in primo piano, è possibile utilizzare l'evento ContentsChanged da un oggetto StorageFileQueryResult per ricevere notifica delle modifiche in una determinata query. Quando un'applicazione è in background, può registrarsi per il StorageLibraryContentChangedTrigger per ricevere una notifica quando un elemento modificato. Entrambi gli elementi sono guardarsi notifiche per informare un'applicazione che un elemento modificato, ma non includono informazioni sui file che sono stati modificati.
Per trovare i file che sono stati modificati o creati di recente, il sistema fornisce la proprietà System.Search.GatherTime. La proprietà è impostata per tutti i file in un percorso indicizzato e rileva l'ultima volta che l'indicizzatore notato una modifica al file. Questa proprietà verrà costantemente aggiornata in base all'orologio di sistema, tuttavia, in modo che l'esclusione di solito che includono utenti, legale e fuso orario commutatori manualmente la modifica dell'ora di sistema vengono mantenuti per considerare attendibile questo valore nell'applicazione.
Registrazione per un evento in primo piano di rilevamento delle modifiche è facile. Dopo aver creato un oggetto StorageFileQueryResult che analizza l'ambito che interessata l'applicazione, è sufficiente registrare per l'evento ContentsChanged, come illustrato di seguito:
StorageFileQueryResult resultSet = photos.CreateFileQueryWithOptions(option);
resultSet.ContentsChanged += resultSet_ContentsChanged;
L'evento verrà generato ogni volta che un elemento nel risultato viene impostato. L'applicazione può quindi trovare i file modificati di recente.
Rilevamento delle modifiche dallo sfondo è leggermente più complessa. Le applicazioni sono in grado di registrarsi per ricevere una notifica quando un file viene modificato in una libreria sul dispositivo. Non esiste alcun supporto per più complesse le query o gli ambiti, il che significa che le applicazioni sono responsabili per l'esecuzione di un po' di lavoro per assicurarsi che la modifica è un elemento in cui sono effettivamente interessati.
Come un testo interessante, il motivo per le applicazioni possono effettuare la registrazione sola per la libreria notifiche di modifica e non in base al tipo di file è dovuto a come è stato progettato l'indicizzatore. Il filtro query in base alla posizione di un file su disco è molto più veloce rispetto a una query per trovare una corrispondenza in base al tipo di file; e trascinata verso il basso le prestazioni dei dispositivi nei nostri test iniziale. Ulteriori suggerimenti sulle prestazioni verranno trattati più avanti, ma questo è dei più importanti da ricordare: Filtro dei risultati di query dal percorso del file è estremamente veloce rispetto ad altri tipi di operazioni di filtro.
Ho delineato i passaggi per la registrazione per un'attività in background con esempi di codice in un post di blog (bit.ly/1iPUVIo), ma passiamo a esaminare un paio di passaggi più interessanti. La prima cosa che un'applicazione deve fare è creare il trigger in background:
StorageLibrary library =
await StorageLibrary.GetLibraryAsync(KnownLibraryId.Pictures);
StorageLibraryContentChangedTrigger trigger =
StorageLibraryContentChangedTrigger.Create(library);
Essere creato il trigger da un insieme di librerie anche se l'applicazione dovrà essere interessati a più percorsi di rilevamento. In questo caso, l'applicazione dovrà essere esaminando la libreria di immagini, che è uno degli scenari più comuni per le applicazioni. È necessario verificare che l'applicazione dispone di funzioni corrette per poter accedere alla libreria che sta tentando di modificare una traccia; in caso contrario, verrà restituito un accesso negato eccezione quando l'applicazione tenta di creare l'oggetto StorageLibrary.
Nei dispositivi mobili Windows, questo è particolarmente potente come sistema di garanzie di nuove immagini dal dispositivo sta per essere scritto nel percorso della libreria di immagini. Questa operazione viene eseguita indipendentemente da ciò che l'utente sceglie nella pagina Impostazioni modificando le cartelle sono incluse come parte della libreria.
L'applicazione deve registrare l'attività in background utilizzando il BackgroundExecutionManager e dispone di un'attività in background incorporata in app. Impossibile attivare l'attività in background mentre l'applicazione è in primo piano, pertanto qualsiasi codice deve essere consapevole di potenziali race condition durante l'accesso a file o del Registro di sistema.
Al termine della registrazione, l'applicazione verrà chiamato ogni volta che viene apportata una modifica nella raccolta per cui è registrati. Questo potrebbe includere file che non interessata l'applicazione o in grado di elaborare. In tal caso, applicare un filtro restrittivo non appena viene attivato l'attività in background è il modo migliore per assicurarsi che non esiste alcun sfondo inutilizzato l'elaborazione.
Trovare i file più recente aggiunti o modificati è semplice come una singola query con l'indicizzatore. Semplicemente richiedere tutti i file con un tempo di raccolta di dati che rientrano nell'intervallo in cui l'applicazione è interessata. Stesso ordinamento e raggruppamento di funzionalità disponibili per altre query può essere usati qui, anche se lo si desidera. Tenere presente che l'indicizzatore utilizza ora Zulu internamente, assicurarsi quindi di convertire tutte le stringhe di ora Zulu prima di utilizzarli. Ecco come è possibile compilare una query:
QueryOptions options = new QueryOptions();
DateTimeOffset lastSearchTime = DateTimeOffset.UtcNow.AddHours(-1);
// This is the conversion to Zulu time, which is used by the indexer
string timeFilter = "System.Search.GatherTime:>=" +
lastSearchTime.ToString("yyyy\\-MM\\-dd\\THH\\:mm\\:ss\\Z")
options.ApplicationSearchFilter += timeFilter;
In questo caso l'applicazione sta per ottenere tutti i risultati dall'ultima ora. In alcune applicazioni risulta più utile salvare l'ora dell'ultima query e utilizzarlo nella query, ma funzionerà qualsiasi DateTimeOffset. Una volta che l'applicazione contiene l'elenco di back file è possibile enumerare come indicato in precedenza o utilizzare l'elenco per rilevare quali file sono stati introdotti a esso.
La combinazione di due metodi di rilevamento delle modifiche con il tempo di raccolta consente UWP applicazioni la possibilità di modificare il file system di tenere traccia e reagire alle modifiche sul disco con facilità. Queste possono essere relativamente nuove API nella storia di Windows, ma vengono utilizzati nelle applicazioni di foto, musica Groove, OneDrive, Cortana e film e TV incorporate in Windows 10. Assicurando vengono inclusi nell'applicazione sapere che si sono potenziamento di queste esperienze uniche.
Procedure consigliate generali
Esistono alcune cose che qualsiasi applicazione utilizzando l'indicizzatore deve essere presente per evitare eventuali bug e assicurarsi che l'applicazione sia più rapidamente possibile. Includono evitando qualsiasi query inutilmente complesse in parti critiche per le prestazioni dell'applicazione, utilizzando le enumerazioni di proprietà correttamente e sia consapevole dell'indicizzazione ritardi.
Come è stata progettata una query può avere un impatto significativo sulle prestazioni. Quando l'indicizzatore è in esecuzione di query nel relativo database di backup, alcune query sono più veloci per il layout le informazioni sul disco. Filtro in base a percorso del file è sempre veloce come l'indicizzatore è in grado di eliminare rapidamente enormi parti dell'indice dalla query. Ciò consente di risparmiare processore e il tempo dei / o perché vi sono meno stringhe che devono essere recuperati e confrontati durante la ricerca di corrispondenze con i termini della query.
L'indicizzatore è sufficientemente potente per gestire le espressioni regolari, ma alcuni moduli di essi sono noti per causano rallentamenti. La cosa peggiore che può essere incluso in una query di indicizzatore è una ricerca del suffisso. Si tratta di una query per tutti i termini che terminano con un determinato valore. Un esempio potrebbe essere la query "* zione," che cerca tutti i documenti contenenti parole che terminano con "descrizione". Poiché l'indice viene ordinato per la prima lettera di ogni token, esiste un modo rapido per individuare i termini corrispondenti questa query. È necessario decodificare ogni token in tutto l'indice e confrontarlo con il termine di ricerca, è molto lento.
Le enumerazioni possono accelerare le query ma hanno un comportamento imprevisto nelle compilazioni internazionale. Chiunque abbia creato un sistema di ricerca sa quanto più veloce eseguire confronti in base a un'enumerazione è di eseguire confronti tra stringhe. E questo si applica l'indicizzatore. Per semplificare l'applicazione, il sistema di proprietà fornisce un numero di enumerazioni per filtrare i risultati a un minor numero di elementi prima di avviare i confronti di stringa costosi. Un esempio comune consiste nell'utilizzare il filtro System.Kind per limitare i risultati solo i tipi di file in grado di gestire un'applicazione, ad esempio musica o documenti.
Si verifica un errore comune di cui chiunque tramite enumerazioni deve tenere conto. Se l'utente dovrà cercare per solo i file musicali, quindi un en-us versione di Windows aggiungendo System.Kind:=music alla query deve essere eseguito perfettamente per limitare i risultati della ricerca e velocizzare una query. Questo funzionerà anche in altri linguaggi, probabilmente è sufficiente passare il test di internazionalizzazione, ma non verrà completata nel sistema non è in grado di riconoscere "Musica" come un termine inglese e analizza invece nella lingua locale.
Il modo corretto per utilizzare un'enumerazione, ad esempio System.Kind deve indicare chiaramente che l'applicazione non sia progettata per utilizzare il valore come un'enumerazione, non come un termine di ricerca. Questa operazione viene eseguita utilizzando la sintassi di enumerazione #value. Ad esempio, scrivere System.Kind:=System.Kind#Music sarebbe il modo corretto per filtrare solo i risultati di musica. Questo funzionerà in tutte le lingue di Windows fornito e consentiranno di filtrare i risultati per il sistema riconosce come file musicali solo ai file.
Escape correttamente la sintassi di Query avanzate (AQS) consente di verificare che gli utenti non accedono sodo per problemi relativi alle query riproducibili. AQS dispone di numerose funzionalità che consentono agli utenti di includere le virgolette o parentesi per determinare la modalità di elaborazione della query. Ciò significa che le applicazioni sono necessario prestare attenzione a eventuali condizioni di query che potrebbero includere questi caratteri di escape. Ad esempio, la ricerca di documento (8). docx verrà comportare un errore di analisi e la restituzione di risultati non corretti. L'applicazione deve invece escape il termine come Document%288%29.docx. Restituirà gli elementi in corrispondenza dell'indice che corrispondono al termine di ricerca, anziché il sistema tenta di analizzare la parentesi come parte della query.
Per una descrizione più dettagliata di tutte le funzionalità di AQS e come verificare che le query siano corrette, è possibile consultare la documentazione all'indirizzo bit.ly/1Fhacfl. Include numerose informazioni eccezionali, inclusi ulteriori dettagli sui suggerimenti indicati.
Nota sull'indicizzazione ritardi: L'indicizzazione non è immediata, il che significa che gli elementi vengano visualizzati nell'indice o notifiche basate sull'indicizzatore sta per essere ritardato leggermente da quando viene scritto il file. Sotto carico normale del sistema, il ritardo sarà nell'ordine di 100 ms, ovvero più velocemente di quanto la maggior parte delle applicazioni possono eseguire query nel file system, in modo non evidente. Vi sono casi in cui un utente potrebbe essere migrazione migliaia di computer dei file e l'indicizzatore è notevolmente in ritardo.
In questi casi, esistono applicazioni si consiglia di eseguire due operazioni: In primo luogo, dovrebbe contengono una query aperta tramite i percorsi del file system in cui l'applicazione è più interessante. In genere, questa operazione viene eseguita creando un oggetto StorageFileQueryResult sul file percorsi di sistema che dell'applicazione verrà eseguita la ricerca. Quando l'indicizzatore rileva che un'applicazione disponga di una query aperta, sarà la priorità l'indicizzazione in tali ambiti su tutti gli altri ambiti. Tuttavia, assicurarsi di non eseguire questa operazione per un ambito maggiore del necessario. L'indicizzatore verrà arrestare rispettando backoff di sistema e le notifiche utente attivo per elaborare le modifiche appena possibile, pertanto è possibile notare un impatto sulle prestazioni del sistema mentre si verifica questa situazione.
Altri si consiglia di avvisare gli utenti che il sistema viene aggiornato con le operazioni di file. Alcune applicazioni, ad esempio Cortana mostrano un messaggio nella parte superiore dell'interfaccia utente, mentre altri interrompe l'esecuzione di query complesse e Mostra una versione semplice dell'esperienza. Spetta all'utente per determinare il migliore per l'esperienza di app.
Avvolgendo
Questo è stato una breve panoramica delle funzionalità disponibili per gli utenti le API di archiviazione di Windows in Windows 10 e indicizzatore. Per ulteriori informazioni su come utilizzare le query per passare contesto di attivazione dell'applicazione o esempi di codice per il trigger in background, consultare il blog del team all'indirizzo bit.ly/1iPUVIo. Lavoriamo costantemente con gli sviluppatori per assicurarsi che le API di ricerca siano adatti all'utilizzo. Gradiremmo ricevere i vostri commenti su ciò che funziona e ciò che si desidera vedere aggiunto alla superficie.
Wilson Adamè un program manager del team piattaforma e l'ecosistema di sviluppatori Windows. Lavora sull'affidabilità di notifica indicizzatore e push Windows. In precedenza ha lavorato in un'archiviazione API per Windows Phone 8.1. Contattarlo all'indirizzo adwilso@microsoft.com.
Grazie all'esperto tecnica seguente per la revisione di questo articolo: Sami Khoury
Sami Khoury è un tecnico del team piattaforma e l'ecosistema di sviluppatori Windows. Dirige lo sviluppo dell'indicizzatore di Windows