Поделиться через

Средства тестирования и отладки для управления жизненным циклом процесса (PLM)

Одним из ключевых различий между приложениями UWP и традиционными классическими приложениями является то, что заголовки UWP находятся в контейнере приложений с учетом управления жизненным циклом процессов (PLM). Приложения UWP могут быть приостановлены, возобновлены или завершены на всех платформах с помощью службы Runtime Broker, а также имеются специальные инструменты, которые вы можете использовать для принудительного выполнения этих переходов при тестировании или отладке обрабатывающего их кода.

Функции в Visual Studio 2015

Встроенный отладчик в Visual Studio 2015 может помочь вам изучить потенциальные проблемы при использовании функций UWP с эксклюзивными функциями. Вы можете принудительно перевести ваше приложение в разные состояния PLM с помощью панели инструментов событий жизненного цикла, которая становится видимой при запуске и отладке вашей программы.

Панель инструментов событий жизненного цикла

Средство PLMDebug

PLMDebug.exe — это средство командной строки, которое позволяет управлять состоянием PLM пакета приложения и поставляется в составе пакета Windows SDK. После установки средство находится в C:\Program Files (x86)\Windows Kits\10\Debuggers\x64 по умолчанию.

PLMDebug также позволяет отключить PLM для любого установленного пакета приложения, который необходим для некоторых отладчиков. Отключение PLM предотвращает завершение работы вашего приложения службой Runtime Broker до того, как у вас появится возможность отладки. Чтобы отключить PLM, используйте параметр /enableDebug, а затем полное имя пакета приложения UWP (короткое имя, имя семейства пакетов или AUMID пакета не будет работать):

plmdebug /enableDebug [PackageFullName]

После развертывания приложения UWP из Visual Studio в окне вывода отображается полное имя пакета. Кроме того, можно получить полное имя пакета, выполнив Get-AppxPackage в консоли PowerShell.

выполнение Get-AppxPackage

При необходимости можно указать абсолютный путь к отладчику, который автоматически запускается при активации пакета приложения. Если вы хотите сделать это с помощью Visual Studio, необходимо указать VSJITDebugger.exe в качестве отладчика. Однако VSJITDebugger.exe требует, чтобы вы указали "-p" вместе с идентификатором процесса (PID) приложения UWP. Поскольку невозможно заранее узнать идентификатор PID вашего приложения UWP, этот сценарий не поддерживается по умолчанию.

Вы можете обойти это ограничение, написав скрипт или средство, определяющее процесс вашей игры, после чего оболочка выполняет VSJITDebugger.exe, передавая PID вашего приложения UWP. Следующий пример кода C# иллюстрирует простой подход к этому.

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();
        }
    }
}

Пример использования этого в сочетании с PLMDebug:

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

где Game — это имя процесса, а 279f7062-ce35-40e8-a69f-cc22c08e0bb8_1.0.0.0_x86__c6sq6kwgxxfcg — полное имя пакета приложения UWP.

Обратите внимание, что каждый вызов /enableDebug должен быть позже связан с другим вызовом PLMDebug с параметром /disableDebug. Кроме того, путь к отладчику должен быть абсолютным (относительные пути не поддерживаются).