Partilhar via


Ferramentas de teste e depuração para Gestão do Ciclo de Vida de Processos (PLM)

Uma das principais diferenças entre aplicativos UWP e aplicativos de desktop tradicionais é que os títulos UWP residem em um contêiner de aplicativo sujeito ao Gerenciamento do Ciclo de Vida do Processo (PLM). Os aplicativos UWP podem ser suspensos, retomados ou encerrados em todas as plataformas pelo serviço Runtime Broker, e há ferramentas dedicadas para você usar para forçar essas transições quando estiver testando ou depurando o código que as manipula.

Funcionalidades no Visual Studio 2015

O depurador interno no Visual Studio 2015 pode ajudá-lo a investigar possíveis problemas ao usar recursos exclusivos da UWP. Você pode forçar a sua aplicação em diferentes estados de PLM usando a barra de ferramentas Lifecycle Events, que se torna visível quando executa e depura o seu título.

Barra de Ferramentas de Eventos do Ciclo de Vida

A ferramenta PLMDebug

PLMDebug.exe é uma ferramenta de linha de comando que permite controlar o estado do PLM de um pacote de aplicativo e é fornecida como parte do SDK do Windows. Depois de instalada, a ferramenta reside em C:\Program Files (x86)\Windows Kits\10\Debuggers\x64 por padrão.

O PLMDebug também permite desativar o PLM para qualquer pacote de aplicação instalado, o que é necessário para alguns depuradores. A desativação do PLM impede que o serviço Runtime Broker encerre seu aplicativo antes que você tenha a chance de depurar. Para desativar o PLM, use a opção /enableDebug, seguida pelo nome completo do pacote do seu aplicativo UWP (nome curto, nome da família do pacote ou AUMID de um pacote não funcionarão):

plmdebug /enableDebug [PackageFullName]

Depois de implantar seu aplicativo UWP do Visual Studio, o nome completo do pacote é exibido na janela de saída. Como alternativa, você também pode recuperar o nome completo do pacote executando Get-AppxPackage em um console do PowerShell.

executando Get-AppxPackage

Opcionalmente, pode especificar um caminho absoluto para um depurador que será iniciado automaticamente quando o pacote da aplicação for ativado. Se você deseja fazer isso usando o Visual Studio, você precisará especificar VSJITDebugger.exe como o depurador. No entanto, VSJITDebugger.exe requer que especifiques a opção "-p", juntamente com a ID do processo (PID) da aplicação UWP. Como não é possível conhecer o PID da sua aplicação UWP de antemão, esse cenário não é possível de imediato.

Você pode contornar essa limitação escrevendo um script ou ferramenta que identifique o processo do seu jogo e, em seguida, o shell executa VSJITDebugger.exe, e passa o PID do seu aplicativo UWP. O exemplo de código C# a seguir ilustra uma abordagem direta para fazer isso.

using System.Diagnostics;

namespace VSJITLauncher
{
    class Program
    {
        static void Main(string[] args)
        {
            // Name of UWP process, which can be retrieved via Task Manager.
            Process[] processes = Process.GetProcessesByName(args[0]);

            // Get PID of most recent instance
            // Note the highest PID is arbitrary. Windows may recycle or wrap the PID at any time.
            int highestId = 0;
            foreach (Process detectedProcess in processes)
            {
                if (detectedProcess.Id > highestId)
                    highestId = detectedProcess.Id;
            }

            // Launch VSJITDebugger.exe, which resides in C:\Windows\System32
            ProcessStartInfo startInfo = new ProcessStartInfo("vsjitdebugger.exe", "-p " + highestId);
            startInfo.UseShellExecute = true;

            Process process = new Process();
            process.StartInfo = startInfo;
            process.Start();
        }
    }
}

Exemplo de uso disso em conjunto com PLMDebug:

plmdebug /enableDebug 279f7062-ce35-40e8-a69f-cc22c08e0bb8_1.0.0.0_x86__c6sq6kwgxxfcg "\"C:\VSJITLauncher.exe\" Game"

onde Game é o nome do processo e 279f7062-ce35-40e8-a69f-cc22c08e0bb8_1.0.0.0_x86__c6sq6kwgxxfcg é o nome completo do pacote de aplicativo UWP de exemplo.

Note que cada chamada para /enableDebug deve ser posteriormente acoplada a outra chamada PLMDebug com a opção /disableDebug. Além disso, o caminho para um depurador deve ser absoluto (caminhos relativos não são aceites).