Offrire un'esperienza di avvio e arresto ottimale

Questa sezione offre una panoramica dell'esperienza di avvio rapido e dei suggerimenti per i partner per offrire la migliore esperienza on/off per i clienti.

I PC possono essere attivati e disattivati molte volte al giorno. A seconda dei modelli di utilizzo e della capacità di durata della batteria del dispositivo, un PC potrebbe arrestare, dormire o ibernare. L'avvio del sistema è la prima esperienza che gli utenti hanno con il dispositivo ed è un'esperienza ricorrente per la durata del dispositivo. I dati di telemetria dei clienti indicano che gli utenti avviano e arrestano il PC almeno una volta al giorno. Anche se la funzionalità standby connessa riduce la frequenza con cui deve essere avviato un dispositivo, l'avvio potrebbe comunque essere necessario per gli aggiornamenti software e firmware, gli stati della batteria insufficiente e le modifiche di configurazione principali al dispositivo.

A partire da Windows 8.x, la velocità della transizione on/off è notevolmente più veloce rispetto alle versioni precedenti di Windows. Il modello di interazione utente usato in precedenza era interrompere un avvio con i tasti per indicare percorsi di avvio alternativi. Con un tempo di avvio molto più veloce, le interruzioni di avvio sono poco pratiche e influiscono negativamente sull'esperienza di avvio. Nelle versioni precedenti era importante arrestare il processo di avvio il prima possibile per i punti decisionali, ad esempio l'avvio in un sistema operativo alternativo, perché lo spostamento indietro era un processo lungo e lento. Era anche molto più semplice con tempi di avvio lenti per creare periodi di tempo in cui è possibile rilevare e attivare i tasti. In Windows 8.x e Windows 10, questo non è più il caso.

Le prestazioni di avvio predefinite sono migliorate notevolmente grazie all'uso della tecnologia di ibernazione. Per informazioni sui miglioramenti apportati alle prestazioni dell'esperienza on/off, vedere Sospensione e ripresa di Iberna (S4). Le considerazioni contenute in questo argomento descrivono il modello utente per le transizioni di avvio/disattivazione rapide, le opzioni correlate a tali transizioni e i componenti richiesti dagli OEM/ODM per offrire l'esperienza.

Considerazioni

L'origine principale dei ritardi di avvio è il precaricamento del software OEM. L'avvio rapido rappresenta circa il 50% del tempo di avvio complessivo ed è direttamente interessato dai processi di prima e di terze parti seguenti avviati all'avvio:

• Servizi che vengono ripresi

• App di avvio, ad esempio collegamenti in esecuzione tray, indicatori di stato OEM e così via

• Attività antivirus

Questi processi utilizzano le risorse di sistema cpu e disco e possono comportare la bottiglia, che può rendere il dispositivo non rispondente, ritardare i tempi di avvio dell'app o fare in modo che le app vengano eseguite lentamente.

Quando si ottimizzano le prestazioni on/off, considerare i suggerimenti seguenti:

• Determinare quali processi di terze parti o non posta in arrivo vengono caricati e eseguiti nei sistemi.

• Determinare cosa viene avviato all'avvio tramite chiavi di esecuzione del Registro di sistema; in genere, si tratta di processi correlati all'hardware IHV.

• Evitare di includere processi di codice gestito nel percorso di avvio.

• Usare tecniche per ritardare i processi di avvio all'avvio.

• È consigliabile convertire le app desktop tradizionali in app di Microsoft Store, che non causano un impatto sull'avvio. Usare IHD per sfruttare le app per dispositivi di Microsoft Store.

• Comprendere in che modo l'utilizzo della memoria influisce sui tempi di transizione/disattivazione e seguire questi suggerimenti:

  • Ottimizzare il consumo di memoria per ridurre le dimensioni dell'iberfile.

  • Usare la nuova modalità di diagnostica hiberfile.

  • Evitare di abilitare la sospensione ibrida su portatili e ultraportabili, perché genera un iberfile nella sospensione standby (S3).

• Eseguire la migrazione dei processi di aggiornamento per usare AM per ridurre il numero di processi caricati.

• Comprendere che la velocità effettiva del disco è fondamentale per le prestazioni on/off. Ad esempio:

  • In media, i tempi di lettura/scrittura dell'iberfile rappresentano il 50% dell'ora dello schermo di avvio.

  • La maggior parte dei sistemi è associata a disco all'avvio.

  • Un HDD/SSD più veloce può ridurre l'effetto di un precaricamento software significativo caricato e inizializzato all'avvio.

  • Prendere in considerazione il bilanciamento della CPU, delle prestazioni del disco e della capacità di memoria.

• Comprendere che le unità ibride sono utili per le prestazioni on/off e prendere in considerazione l'uso della nuova funzionalità di hint per unità ibride.

Avvio rapido

A partire da Windows 8.x, lo scenario di arresto e riavvio predefinito è stato aggiornato e denominato avvio rapido. L'avvio rapido inizia con il processo di arresto e include la scrittura di dati su disco simili al processo di ibernazione. Una differenza fondamentale è che tutte le sessioni utente (sessione 1) vengono disconnesse e le informazioni rimanenti vengono scritte nel file di iberfile. Quando si avvia il PC da questo stato, Windows carica lo stato inizializzato in precedenza leggendo dal file iberfile, invece di eseguire il processo di avvio completo in cui Vengono inizializzati Windows, driver, dispositivi e servizi. Questo metodo accelera il processo di inizializzazione del blocco o della schermata Start.

Inoltre, l'uso della tecnologia di ibernazione è stato ampliato per creare una nuova esperienza di avvio e arresto predefinita molto più veloce di un avvio completo. Per informazioni dettagliate, vedere il diagramma seguente:

La sequenza di avvio e arresto più veloce usa l'infrastruttura di ibernazione per posizionare il PC in ibernazione. A differenza di un arresto completo e di avvio, la sessione utente viene chiusa e viene eseguita un'ibernazione. Di conseguenza, il file di ibernazione è molto più piccolo, assicurando che il processo di ibernazione e ripresa sia più veloce. Questa sequenza sfrutta anche le ottimizzazioni di parallelizzazione.

Gli sviluppatori che creano driver o app con un servizio di sistema e integratori di sistemi devono monitorare i problemi di qualità dei driver, ad esempio perdite di memoria. Anche se la qualità dei driver è sempre stata importante, si noti che il tempo di attività tra i riavvii del kernel potrebbe essere notevolmente più lungo rispetto alle versioni precedenti di Windows perché durante gli arresti avviati dall'utente, il kernel, i driver e i servizi vengono mantenuti e ripristinati, non solo riavviati.

Avvio completo

Per un'esperienza di avvio ottimale, considerare i suggerimenti seguenti:

• Bilanciare le prestazioni della CPU, le prestazioni del disco e la capacità di memoria.

• Ottimizzare le prestazioni di routing in lettura UEFI.

• Assicurarsi che i driver dei dispositivi del nodo foglia seguano le linee guida per il curriculum rapido.

• Assicurarsi che i driver completino i runtime di integrazione di alimentazione S0 il più rapidamente possibile per impedire ad altri dispositivi di avviare i runtime di integrazione di alimentazione S0.

• Convalidare i driver e i servizi in caso di perdite di memoria.

• Evitare di registrare un servizio per ricevere notifiche degli eventi di risparmio energia, a meno che non sia assolutamente necessario.

• Assicurarsi che i driver non attendino di completare il S_IRP fino al completamento del D_IRP. In questo modo si impedisce ad altri dispositivi di ricevere il S_IRPs, causando ritardi di serializzazione e aumentare il tempo di sospensione complessivo.

Comportamento dell'API di arresto

Per garantire la migliore compatibilità con le app, consentendo al tempo stesso la migliore esperienza possibile per le nuove app, sono stati creati nuovi flag per richiedere un arresto per l'avvio rapido. La tabella seguente descrive i nuovi flag e il comportamento delle API di arresto. Informazioni dettagliate su queste API e flag sono disponibili in MSDN.

API	Comportamento di arresto
InitiateSystemShutdownEx	Esegue sempre un arresto completo
InitiateSystemShutdown	Esegue sempre un arresto completo
InitiateShutdown	Esegue un arresto per l'avvio rapido con l'uso del flag di SHUTDOWN_HYBRID
Exitwindowsex	Esegue un arresto per l'avvio rapido con l'uso del flag di EWX_HYBRID_SHUTDOWN

Distinguere quando si verifica un arresto di ibernazione o arresto per l'avvio rapido

I driver di dispositivo riceveranno una notifica per passare a uno stato di alimentazione di destinazione S5 all'arresto anziché a uno stato di ibernazione di S4, ovvero lo stato di alimentazione effettivo. In questo modo i driver possono impostare un comportamento di riattivazione diverso per l'avvio rapido dopo un arresto. Gli stati di destinazione ed effettivi si trovano nella struttura System_Power_State_Context.

Per la maggior parte dei dispositivi, la distinzione tra il comportamento di riattivazione S4 e S5 è controllata a livello di driver del bus. Se si implementa il proprio autista di autobus e si deve distinguere tra questi due comportamenti, contattare il rappresentante Microsoft per ulteriori informazioni. Per offrire un'esperienza di avvio veloce, seguire queste procedure consigliate:

• Bilanciare le prestazioni della CPU, le prestazioni del disco e la capacità di memoria.

• Ottimizzare le prestazioni di routing in lettura UEFI.

• Assicurarsi che i driver dei dispositivi dei nodi foglia debbano riprendere rapidamente le linee guida.

• Assicurarsi che i driver completino i runtime di integrazione di alimentazione set-power S0 il più rapidamente possibile per impedire ad altri dispositivi di ottenere i propri IRP di alimentazione set-power S0.

• Evitare di avviare app all'avvio, ad eccezione delle app antimalware e dei dispositivi.

• Non avviare mai le app all'avvio usando RunOnce.

• Evitare le app con codice gestito nel percorso di avvio.

• Ritardare l'avvio di app non critiche usando Utilità di pianificazione.

• Convalidare i driver e i servizi in caso di perdite di memoria.

• Registrare un servizio per ricevere la notifica degli eventi di risparmio energia solo se assolutamente necessario.

• Assicurarsi che i driver non attendino il completamento del S_IRP fino al completamento del D_IRP. In questo modo, altri dispositivi riceveranno la loro S_IRPs, causando ritardi di serializzazione e aumentare il tempo di sospensione complessivo.

Sospensione e ripresa di ibernazione (S4)

In una transizione di ibernazione, tutto il contenuto della memoria viene scritto in un file nell'unità del sistema primario. Questo processo mantiene lo stato di Windows, app e dispositivi. Se il footprint di memoria combinato usa tutta la memoria fisica, il file di ibernazione deve essere abbastanza grande per garantire che sia disponibile spazio sufficiente per salvare tutto il contenuto della memoria fisica. Poiché i dati vengono scritti in archiviazione non volatili, la DRAM non deve mantenere l'aggiornamento automatico e può essere disattivata. Questo comportamento comporta un risparmio di potenza molto basso, simile al PC in stato disattivato.

Scenari utente per l'ibernazione

Questi sono gli scenari critici che richiedono la tecnologia di ibernazione nei PC che eseguono la versione moderna di Windows:

• Doze to Hibernate: Un sistema viene lasciato inattiva e passa automaticamente all'ibernazione.

• Batteria critica: Windows esegue automaticamente l'ibernazione del PC per evitare la perdita di dati quando l'alimentazione della batteria è esaurita.

• Condizione termica: Un sistema raggiunge una temperatura predefinita che richiede il risparmio automatico del sistema per proteggere i circuiti.

• Avviato dall'utente: Un utente seleziona l'ibernazione per salvare lo stato utente corrente con alimentazione molto minima.

Anche se questo elenco può evolversi man mano che le esigenze e le funzionalità dei PC si evolveranno, è previsto che molti PC continueranno a usare l'ibernazione, soprattutto quando lo standby connesso non è possibile.

Fase di ibernazione

Nella fase di ibernazione, Windows notifica ai vari componenti che si sta verificando una fase di ibernazione e quindi salva lo stato del contesto e del sistema dell'utente. I dati vengono compressi e scritti nel disco; il sistema usa tutti i core del processore nel sistema per comprimere i dati in memoria e usa un processore durante la scrittura dei dati su disco. Dopo che tutti i dati vengono scritti su disco, Windows notifica al firmware che è pronto per il risparmio di energia.

La notifica del firmware viene eseguita scrivendo nei registri del tipo di sospensione con valori forniti nell'oggetto S4, come definito in ACPI 4, Sezione 4.5, Tabella 4-13 e Sezione 7.3.4. Ciò indica al firmware che in fase di alimentazione successiva, verrà eseguito un tentativo di ripresa anziché un'avvio completo.

Fase di ripresa

La ripresa di ibernazione inizia con il firmware POST, simile a un avvio completo. Il gestore di avvio di Windows rileva che una ripresa dall'ibernazione è necessaria rilevando un file di ibernazione valido e indirizza il sistema a riprendere, ripristinando il contenuto della memoria e tutti i registri architettonici. Nel caso di una ripresa di ibernazione, il contenuto della memoria viene letto dal disco, decompresso e ripristinato, inserendo il sistema nello stato esatto in cui si trovava quando è stato ibernato. Dopo aver ripristinato il contenuto della memoria, i dispositivi vengono riavviati e il computer torna a uno stato in esecuzione, pronto per l'accesso.

Si noti che anche se i driver e i servizi di dispositivo vengono notificati, non vengono riavviati; vengono ripristinati allo stato in cui si è verificata la fase di ibernazione.

Il ripristino della memoria di sistema viene suddiviso in due fasi. La prima fase viene eseguita per ripristinare una parte minima del kernel, che viene quindi usata per completare il ripristino della memoria per il resto del sistema. La prima fase deve essere eseguita con un singolo core dell'ambiente del processore. Tuttavia, dopo il ripristino della parte minima della memoria di sistema, tutti i core del processore possono essere usati per parallelizzare la decompressione e il ripristino dei dati per il resto della ripresa, accelerando in modo significativo il processo.

Il processo è ulteriormente migliorato ridimensionando l'algoritmo di crittografia/decrittografia, in base alle funzionalità del processore.

Le ottimizzazioni di parallelizzazione sono disponibili solo nei sistemi in cui il sistema può garantire che abbia tutti i dati necessari dall'ambiente minimo disponibile. Pertanto, non può essere usato se i componenti aggiunti allo stack di dump di arresto anomalo, che viene usato durante l'operazione di ripresa di ibernazione, non sono stati dichiarati anche come parte di tale ambiente minimo. Se si sta creando un componente di questo tipo, ad esempio un driver di filtro dump di arresto anomalo o un dispositivo che usa un percorso di dump di arresto anomalo separato, contattare Microsoft in modo che possano portare tramite questo processo.

Firmware POST

Tempi POST più veloci riducono il tempo complessivo dall'alimentazione allo stato utilizzabile. Poiché l'avvio rapido di Windows è notevolmente più veloce, il tempo POST può diventare una percentuale più significativa del tempo di avvio totale. Altre informazioni sui requisiti di tempo POST sono documentate nei requisiti di certificazione hardware di Windows. L'analisi mostra che i requisiti di tempo POST sono raggiungibili sulle piattaforme che enumerano completamente e consentono un complemento completo dei componenti hardware nell'ambiente del sistema operativo pre-operativo.

Poiché Windows 8, tutti i PC devono inviare il firmware in base alla specifica UEFI (Unified Extensible Firmware Interface) 2.3.1 o successiva. Poiché molti sistemi si basano su progetti precedenti del firmware legacy, è possibile ottimizzare la progettazione del firmware per soddisfare meglio i tempi POST più rapidi.

L'architettura UEFI scorre attraverso diverse fasi di inizializzazione del firmware e della piattaforma. In base a queste fasi ben definite, esistono diverse considerazioni sulla progettazione che potrebbero ridurre il tempo POST.

Sicurezza (SEC)

Nella fase SEC una piattaforma esegue l'estrazione, la decompressione e la convalida del microcodice della piattaforma archiviata in un flash SPI NOR. A questo punto di alimentazione, la piattaforma ha inizializzazione RAM e il relativo bus. L'elenco seguente include alcune domande da considerare per questa fase:

• Il microcodice è specifico dello SKU o generale di più piattaforme? Le dimensioni del microcodice influiscono sul trasferimento della decompressione alla RAM e alla convalida.

  Prendere in considerazione il refactoring del microcode per essere il più piccolo possibile.

• La velocità del bus flash SPI NOR può essere aumentata? Molte piattaforme supportano più velocità di clock per la parte flash SPI NOR. Sono spesso operativi a una frequenza di clock inferiore (ad esempio, 16 MHz) e possono essere aumentati.

  Prendere in considerazione l'aumento della velocità del bus per ridurre la latenza nel trasferimento di microcodice da NOR flash a RAM.

• La piattaforma ha abbastanza flash NOR? Per risparmiare sui costi, molte piattaforme sono progettate con la parte NOR minima bare, causando una compressione più elevata del microcodice e un costo maggiore per la decompressione.

• Si consideri una parte flash NOR più grande per archiviare il codice con una compressione minore.

Il bilanciamento della compressione, della progettazione e del trasferimento di microcodice potrebbe migliorare le prestazioni dei tempi POST. Alla fine della SEC, il microcodice convalidato copia il resto del kernel e dell'ambiente UEFI da NOR flash in RAM.

Inizializzazione pre-EFI (PEI)

Dopo che il kernel è in RAM, la piattaforma inizializza il kernel e inizia a convalidare l'integrità del codice, della tabella di sistema e di altri elementi. È consigliabile progettare un kernel UEFI ottimizzato per la piattaforma anziché un kernel generico non ottimizzato. Le ottimizzazioni possono includere:

• Compilazione di flag durante le compilazioni del kernel che ottimizzano i buffer di memoria

• Collegamento ai moduli non necessari per l'inizializzazione della piattaforma

Consultare i progettisti del firmware per idee su come ottimizzare il kernel UEFI.

Ambiente di esecuzione driver (DXE)

A questo punto di inizializzazione, vengono caricati i driver UEFI principali e i driver DXE di terze parti. Usando gli strumenti forniti dai progettisti del firmware, il proprietario può identificare quali sono i driver DXE meno efficienti e valutare se il codice può essere ottimizzato.

Un'altra considerazione in questa fase si riposa nel numero di driver DXE caricati. La piattaforma deve caricare solo i driver necessari per garantire un avvio e non dipendere dall'hardware facoltativo. La progettazione finale dipende dalla selezione dell'avvio di destinazione.

Selezione del dispositivo di avvio (BDS)

La selezione del dispositivo di avvio è il passaggio finale dell'inizializzazione della piattaforma prima di passare a Windows. Durante questo passaggio, il firmware determina quali dispositivi di avvio sono presenti e quali assegnare all'esecuzione. La progettazione attenta e le ottimizzazioni delle variabili di avvio influiscono sulla transizione al caricatore di avvio di Windows.

Enumerazione USB

La parte di enumerazione USB di POST può richiedere molto tempo. Con le nuove modifiche introdotte in Windows 8, l'enumerazione USB non sarà più necessaria nel caso di avvio predefinito. Per altre ottimizzazioni del tempo POST, contattare il fornitore di siliconi e firmware. È consigliabile enumerare l'interfaccia USB se la sequenza di avvio è impostata su qualsiasi altro percorso, ad esempio negli scenari seguenti:

• Esistono altre opzioni più elevate nell'ordine di avvio, ad esempio quando Le opzioni di avvio di Windows To Go inserisce una voce di avvio della classe USB nella parte superiore dell'ordine di avvio.

• Una variabile successiva di avvio è impostata, causando l'uso di un dispositivo di avvio diverso.

• Gli errori si verificano negli avvio immediatamente precedenti.

App

Le app desktop che si trovano nel percorso di avvio influiscono sulla transizione/off e sull'efficienza energetica. Gestione attività contrassegnerà le app desktop che hanno un impatto elevato e notificano all'utente le app desktop che sono sempre in esecuzione. Per altre informazioni, vedere App di avvio. Anziché avviare automaticamente le app desktop, è consigliabile usare la manutenzione automatica ed eseguirle solo quando necessario.

Obiettivi consigliati

Importante

Tutti gli obiettivi definiti escludino il tempo di inizializzazione BIOS.

Per offrire una grande esperienza on/off, è consigliabile che un PC soddisfi gli obiettivi nelle tabelle seguenti.

Scenario	Tablet (CS)	Decappottabile	Notebook	All-in-One
Avvio rapido (secondi)	< 25	<= 15	<= 15	<= 15
Dimensioni iberfile (MB)	< 300	<= 300	<= 300	<= 300
Ripresa standby (secondi)	Non applicabile	<= 7	<= 7	<= 5

Metrica	Unità	Obiettivo
Numero di processi avviati tramite chiavi di esecuzione del Registro di sistema Definito come numero totale di processi avviati in ogni avvio usando chiavi Esegui. Ha un impatto diretto sull'utilizzo delle risorse post-on/off (CPU e disco). Per trovare alcuni eventi ETW, vedere le tracce di avvio rapido (usando la tabella Eventi generici): Nome provider: Microsoft-Windows-Shell-CoreTask: Explorer_ExecutingFromRunKeyOpcode: win:Start Il campo 1 dell'evento (comando) fornisce la riga di comando usata per avviare i processi.	count	< 10
I/O del disco con priorità normale durante l'avvio rapido Post/Off Questa metrica può essere ottenuta direttamente dai risultati della valutazione in Windows Assessment Console, in: Total Boot > Post On/Off > Total Disk Usage > Normal Priority Reads (Byte)	MB	< 30

Convalida e test

Puoi usare Windows Assessment Toolkit per migliorare le prestazioni del PC oltre i requisiti minimi. Le valutazioni di Windows correlate all'esperienza on/off includono:

• Valutazione di avvio rapido

• Valutazione di avvio completo e arresto

• Valutazione standby

• Valutazione di ibernazione

Le nuove versioni delle valutazioni Fast Startup e Hibernate includono una modalità di diagnostica Hiberfile . Questa modalità consente di rilevare driver e app che contribuiscono a grandi dimensioni di iberfile e rileva i driver di archiviazione che non implementano la ripresa a più fasi.

Esistono due categorie principali di pagine di memoria archiviate nell'iberfile rispetto alla valutazione di sistema: pagine del pool non di paging del driver e pagine di working set privati di app/servizi.

La nuova modalità consente di comprendere quali componenti software devono essere migliorati per l'utilizzo della memoria.

Strumenti e riferimenti tecnici

Per altre informazioni sull'esperienza on/off, è possibile scaricare gli strumenti per analizzare le prestazioni da queste risorse:

Titolo e collegamento della risorsa	Tipo di contenuto	Descrizione
App di avvio	Articolo	Evidenzia alcuni degli effetti che le app di avvio hanno in un dispositivo Windows e fornisce indicazioni agli sviluppatori (ISV/IHV) e agli OEM per rivedere i modelli di utilizzo delle app di avvio per migliorare la durata della batteria e la velocità di risposta.
Risultati per le valutazioni On/Off	Documento	Consente di interpretare i risultati prodotti dalle valutazioni On/Off (Prestazioni di avvio rapido), prestazioni di avvio (avvio completo), prestazioni standby e prestazioni di ibernazione.