Il presente articolo è stato tradotto automaticamente.
Windows 8
Introduzione al debug delle applicazioni Windows Store
Negli anni quaranta, quando uno dei programmi di ammiraglio Grace Hopper non ha funzionato correttamente, ha scoperto una falena bloccato tra i relè su Harvard Mark II — ed è nato il termine "bug". Oggi, naturalmente, debug ha nulla a che fare con gli insetti. Esso è tutto il processo di individuazione e rimozione di difetti nel software.
Nonostante il fatto che oggi linguaggi di programmazione e strumenti andare un lungo cammino verso aiutando gli sviluppatori a scrivere codice efficiente, che non non c'è alcuna protezione da errori logici. I moderni compilatori possono solo eseguire controlli rudimentali contro la sintassi del linguaggio di programmazione, uso corretto del sistema di tipo. Il compilatore fa ben poco per aiutare a determinare il comportamento di runtime effettivo dell'applicazione. Questo è dove il debug abilità sono essenziali. Questo articolo si concentrerà sul debug di applicazioni Windows Store ed esplorare alcune delle tecniche utilizzate nel campo.
Useremo anteprima Visual Studio 2013, anche se queste tecniche generalmente funziona con le versioni precedenti del prodotto. Prima di iniziare, però, è necessario preparare l'ambiente per il debug più avanzato che fornisce Visual Studio da solo. Si consiglia di scaricare e installare le seguenti risorse:
- Anteprima Windows 8.1: bit.ly/12nmBEg
- Visual Studio anteprima 2013: bit.ly/1aMpbeM
- Esercitazioni pratiche per Windows 8: bit.ly/QHh0JR
- Esempio di attività in background (Windows 8.1): bit.ly/IZpfqN
- Windows SDK per Windows 8.1 anteprima: bit.ly/1cM9pyQ
- JustDecompile: bit.ly/qXxKJs
- Process Explorer: bit.ly/fzWyfq
Process Lifecycle Management
Con tipiche applicazioni desktop, i lanci di utente un'app e si corre fino a quando egli si termina. L'applicazione continua a funzionare anche quando non è in prima linea. App Store di Windows sono un po' differente. Quando un'app non è all'avanguardia, un servizio di Windows — il Runtime Broker — sospende tutte le discussioni in app e si risveglia li indietro solo quando l'app è in prima linea. Questa caratteristica romanzo aiuta a preservare il complessiva sistema delle prestazioni e durata della batteria. Con Windows 8.1, anche quando un app è chiuso dall'utente, l'azione predefinita è mettere le app in uno stato sospeso e non denunciarlo. Se si preferisce la precedente funzionalità di Windows 8, è possibile impostare Windows.ApplicationModel.ClosePolicy.TerminateOnClose su true.
Sia sospendere e riprendere gli eventi vengono inviati all'app, dandovi la possibilità di archiviare e recuperare lo stato o eseguire altre azioni, come necessario. Inoltre, se un'app si applica troppa pressione memoria o impiega troppo tempo per l'avvio, il Broker di Runtime terminerà l'app, uccidendo tutti i thread. Visual Studio disattiva automaticamente il processo Lifecycle Management (PLM) per le applicazioni che sono in fase di debug, se sei tua app di debug o associare a un'app installata (usando Debug | Eseguire il debug pacchetto installato App). È importante che il PLM è disabilitato perché si impedirebbe di essere in grado di eseguire il debug di un'applicazione correttamente. Il motivo è semplice: il Broker di Runtime può intervenire e interrompere l'applicazione prima di avere la possibilità di eseguire correttamente il debug.
Tuttavia, alcuni dei debugger fuori Visual Studio, ad esempio Windows Debugger (WinDbg) e Microsoft Console Debugger (CDB), richiede di disattivare manualmente la funzionalità PLM. Per disabilitare manualmente PLM, è possibile utilizzare lo strumento di PLMDebug disponibile in Windows SDK 8.1. PLMDebug è uno strumento della riga di comando che consente di disabilitare il PLM per un pacchetto specifico appx utilizzando l'interruttore /enableDebug. È possibile visualizzare tutti i pacchetti app installata tramite il comando Windows PowerShell Get-AppxPackage o Process Explorer (come descritto più avanti in questo articolo) per identificare l'ID di pacchetto specifico appx.
PLMDebug ha diverse utili funzionalità. Ad esempio, ti consente di inviare in modo esplicito una varietà di eventi all'app, tra cui Sospendi, Riprendi, Terminate, terminare con forza e Clean-terminare. Esso permette anche di collegare un debugger dal vivo (che non copriamo in questo articolo).
Visual Studio consente anche grilletto Suspend e Resume eventi, utilizzando la barra di posizione di Debug, che non è visibile per impostazione predefinita. È possibile aggiungere selezionando Visualizza | Barre degli strumenti | Eseguire il debug di posizione. Le opzioni di debug verranno abilitate una volta si sta attivamente debug app. Figura 1 Mostra la barra di posizione di Debug in anteprima Visual Studio 2013.
Figura 1 la posizione di Debug Toolbar
Attività in background
Molti scenari, ad esempio l'aggiornamento di un riquadro animato, possono essere realizzati senza l'utilizzo di un'attività in background, ma a volte attività in background sono necessari e rappresentano un altro modo in cui codice nell'app Store di Windows può essere avviato in modo implicito a causa di condizioni di sistema specifiche definite. Ad esempio, si potrebbe voler aggiungere o creare miniature in background per una delle vostre applicazioni, ma si desidera solo fare quando la periferica utilizza alimentazione AC. Il Trigger di manutenzione consente di avviare alcune attività basate su intervalli di tempo e le condizioni del sistema ed eseguire ripetutamente i compiti. Sebbene il codice per l'attività in background è definito all'interno della vostra applicazione, nella maggior parte dei casi viene eseguita da un processo separato, denominato BackgroundTaskHost.
Un'applicazione Windows Store registra l'attività in background con l'infrastruttura di attività in background OS-livello utilizzando la classe BackgroundTaskBuilder. L'attività in background viene creato come una classe che implementa l'interfaccia IBackgroundTask, e necessario implementare il metodo Run. Un'attività in background deve avere esattamente uno innescare e una o più condizioni impostate che descrivono le circostanze esatte in cui avviare l'attività in background. Il trigger viene specificato con il metodo SetTrigger della classe BackgroundTaskBuilder.
Visual Studio rende trovando e debug di attività in background registrati facile, perché la barra di posizione di Debug mostreranno le attività in background dichiarato dell'applicazione e consentono di avviarli tramite l'interfaccia di visual Visual Studio . Questa tecnica funziona per tutte le attività in background, ad eccezione di quelli che utilizzano ControlChannelTrigger, PushNotificationTrigger o un SystemTrigger con il tipo di trigger SmsReceived di partenza. Per ulteriori informazioni, vedere il white paper di "Introduzione alle attività in Background" a aka.ms/O35jqc. E troverete un esempio di buon codice a bit.ly/IZpfqN.
Attivazioni
Ci sono molti modi, che l'app può essere lanciato a seconda di cosa tu hai implementato, quali File, protocollo, PrintTaskSettings o ShareTarget. Ad esempio, il tipo di attivazione ShareTarget sarebbe attivo quando un utente condivide qualcosa da un'altra app per app.
Ci sono stati alcuni cambiamenti in Windows 8.1 riguardanti attivazioni. Attivazione di ricerca, ad esempio, è obsoleto, ma c'è ancora qualche supporto di compatibilità. C'è anche un approccio innovativo per il lancio di altre applicazioni che condividono lo schermo con l'app. Questo significa che è possibile condividere lo schermo con un browser, mentre l'app è ancora attivo. Troverete ulteriori informazioni su questa funzionalità a bit.ly/11ckVS3.
Per il debug dell'applicazione da questi tipi di attivazioni, il primo passo è andare alla vostra applicazione progetto proprietà avviare azioni. Iniziare facendo clic destro sul ContosoCookbook in Visual Studio Esplora e scegliendo Proprietà. Selezionare la casella di controllo "non si avvia, ma il mio codice di debug quando comincia," come visto Figura 2. Con questa impostazione, sarete in grado di debug dell'applicazione e inserire punti di interruzione nel vostro gestore di OnLaunched che verrà attivato quando viene attivato da uno qualsiasi degli altri tipi di attivazione. Questa impostazione indica all'applicazione per ottenere pronto per il debug, ma in realtà non si avvia quando si avvia una sessione di debugger. L'applicazione sarà semplicemente aspettare.
Figura 2 impostando le proprietà Debugger
Esplorare un'applicazione in esecuzione
Process Explorer fornisce alcune funzionalità utili per quando si desidera ottenere una sbirciatina al funzionamento interno di un'applicazione in esecuzione. Per vedere queste caratteristiche, esploreremo alcune del codice in un'applicazione denominata bambini auto colori, che potete scaricare da bit.ly/YnmAxT. Andare alla schermata Start e avviare l'app bambini auto colori, quindi avviare Process Explorer (supponendo hai precedentemente impostato).
Se si espande svchost.exe, vedrai il Broker di Runtime e qualsiasi App Store Windows in esecuzione, come illustrato Figura 3. Facendo clic destro su KidsCarColors.exe, è possibile visualizzare le proprietà, ad esempio l'installazione della cartella radice.
Figura 3 Process Explorer di SysInternals
Finestra delle proprietà di un'applicazione in Process Explorer fornisce una ricchezza delle informazioni. Ad esempio, come Figura 4 illustrato, la scheda immagine consente di visualizzare la posizione di una determinata app installata. Sia incorporato apps e le applicazioni scaricate da Windows Store sempre installano nella cartella Apps \Programmi\Windows [cartella principale].
Figura 4 proprietà dell'auto bambini colori App
Troverete anche la scheda prestazioni .NET utili; fornisce informazioni di contatore prestazioni base, tra cui cose come le dimensioni dell'heap, il numero di raccolte di Gen 0 e la percentuale di tempo trascorso nella procedura di garbage collection (GC). Guardando questi contatori di prestazioni consente di valutare l'efficacia del CG, quale è il meccanismo che libera la memoria quando gli oggetti non sono non fa più riferimento. Può essere necessario modificare il codice di un'applicazione per più aggressivamente liberare memoria quando non è necessario. Per ulteriori informazioni sui contatori delle prestazioni di .NET a msdn.microsoft.com/library/w8f5kw2e.
Potrebbe essere necessario modificare le proprietà ed i permessi della cartella C:\Program Files\Windows Apps in modo che è possibile visualizzare le applicazioni all'interno di esso.
All'interno di C:\Program Files\Windows Apps, cartelle parallele esistono per ognuna delle applicazioni installate. Ognuna di queste cartelle di applicazione ha una ricchezza di informazioni, come descritto nella sezione successiva.
Esplorare il codice
Come osservato, si può andare nella directory di installazione per le singole applicazioni e trovare una grande quantità di informazioni sull'applicazione, ad esempio tutti i file MP3 (se presente), immagini, file XAML e altre risorse. Tuttavia, non sarà in grado di esaminare i file XAML per applicazioni Windows 8.1, come essi hai stati compilati in un file binario. Ma c'è una varietà di strumenti che permette di decompilare gli eseguibili di Windows Store app scritti in c# e Visual Basic .NET.
Ci potrai decompilare KidsCarColors.exe utilizzando lo strumento JustDecompile da Telerik. Decompilazione è il processo di assunzione di un codice binario e generatrice sorgente leggibile dell'applicazione. Per farlo, basta passare alla cartella di installazione dell'applicazione, come spiegato in precedenza, tasto destro del mouse su KidsCarColors.exe e scegliere Apri con JustDecompile. Come mostrato Figura 5, ora è possibile vedere i dettagli a basso livello del codice rivelato dal decompilatore. Si noti che il modello di dati all'interno dell'applicazione è facile da decifrare e Sfoglia. JustDecompile rende facile recuperare il codice sorgente perduta o peer in assembly per scoprire la causa di un bug di esterni. Questo significa che è possibile visualizzare il codice sorgente di praticamente qualsiasi applicazione installata di Windows Store.
Figura 5 decompilazione KidsCarColors.exe
È notevole la quantità di informazioni è disponibile con questo strumento. Nella creazione di colori auto bambini, ci sono voluti qualche sforzo per ottenere l'audio funziona bene quando un ragazzino cliccato sul colore dell'auto. Ma tutto quel codice è esposto. Se si seleziona l'oggetto ItemDetailPage in Esplora progetti JustDecompile, sarete in grado di scoprire esattamente come i file audio vengono riprodotti: recuperando il MP3 dalla memoria locale, un'istanza di MediaElements vari, registrando gli eventi di callback media, chiamata SetSource e così via. Per chiunque voglia replicare questo approccio, è tutto lì, esposta al mondo.
JustDecompile fornisce alcuni pulsanti sulla relativa barra degli strumenti, tra cui il pulsante elenco di Assembly, che consente di esplorare i riferimenti che ha impostato l'applicazione. Solo sapendo quali riferimenti ha impostato un'applicazione Windows Store dice qualcosa sulla quale funzionalità utilizza l'applicazione. Ad esempio, si può vedere che i ragazzi auto colori sfrutta il SDK di pubblicità. Questo ha senso, perché l'app di mostrare annunci pubblicitari. Teoricamente, tuttavia, si potrebbe impostare un riferimento a un assembly che non si utilizza mai. Immaginate che abbiamo rimosso la pubblicità dentro l'app ma dimenticato di rimuovere il riferimento all'assembly pubblicità SDK. JustDecompile consente di vedere esattamente quale versione si sta esaurendo in natura e che il codice e i riferimenti aspetto.
JustDecompile include anche una funzionalità chiamata trovare utilizzi, che consente di replicare il comando di trovare tutti i riferimenti in Visual Studio. Si può semplicemente ctrl-clic su qualsiasi Namespace, tipo o membro in codice decompilato per ottenere un elenco di tutti i riferimenti al codice corrispondente. Questo può essere di grande aiuto nell'apprendimento sul funzionamento di un'applicazione senza avere alcun codice sorgente.
Conclusioni
Per massimizzare la vostra efficacia come uno sviluppatore di app Store di Windows, è necessario avere una buona comprensione di come eseguire il debug di applicazioni. Questo articolo vi dà una breve panoramica di alcuni strumenti e tecniche che è possibile utilizzare per trovare e risolvere i problemi nel codice. Inoltre, alcune delle tecniche può aiutare a imparare come lavorano altre applicazioni Windows Store, anche se non hai il codice sorgente.
Bruno Terkaly è un developer evangelist per Microsoft. La sua profonda competenza deriva da anni di esperienza nel campo, scrivendo codice utilizzando una moltitudine di piattaforme, linguaggi, framework, SDK, librerie e API. Trascorre il tempo scrivere codice, blogging e dando le presentazioni dal vivo sulla creazione di applicazioni basate su cloud, in particolare utilizzando la piattaforma Windows Azure. Si può leggere il suo blog a blogs.msdn.com/b/brunoterkaly.
Robert Evans è un assistente tecnico di campo premier e il responsabile tecnico per Windows 8: Laboratori di applicazioni Windows Store Egli è un Microsoft certificata sviluppatore professionista e istruttore Master Windows 8 Dev Bootcamp. Ha presentato al TechReady, GeekReady e The Tablet Show e ha ospitato il laboratorio di Hardware Windows 8 alla conferenza Build Microsoft oltre a numerosi eventi di Windows 8 Hackathon. Prima di diventare un assistente tecnico di campo premier, Evans ha trascorso 12 anni come ingegnere di sviluppo software presso Microsoft a lavorare su vari prodotti come Xbox Live, MSN e ingegneria cellulare di Microsoft IT. È possibile leggere il blog progettazione campo Premier, a cui contribuisce, a aka.ms/Utg864.
Grazie all'esperto tecnica seguente per la revisione di questo articolo: Christophe Nasarre-Soulier (Microsoft)
Christophe Nasarre lavora un team di supporto di Microsoft. Dal 1996, ha lavorato come redattore tecnico su numerosi libri e scritto diversi articoli per MSDN Magazine.