Опыт разработки LogicPad: путь до релиза личного Windows-приложения

Sun, 13 Sep 2026 04:00:00 +0900

1. Введение: почему именно сейчас стоит создавать нативные приложения для Windows

В современной разработке приложений кроссплатформенные технологии, такие как Electron, Tauri и React Native, несомненно стали мейнстримом. Подход «написал один раз, работает везде» (Write Once, Run Anywhere) с использованием веб-технологий весьма рационален с точки зрения скорости разработки и простоты поддержки. Однако я намеренно выбрал путь создания «LogicPad» как нативного приложения, полностью оптимизированного под Windows.

LogicPad — это симулятор цифровых логических схем и текстовый редактор, целевой аудиторией которого являются инженеры по аппаратному обеспечению и те, кто изучает логические схемы. Приложению необходимо моделировать десятки тысяч логических вентилей в реальном времени, одновременно отображая сложные волновые данные без задержек. В области, где требуется такая экстремальная производительность, паузы на сборку мусора длительностью в несколько миллисекунд (микрофризы) или накладные расходы на рендеринг веб-представления (WebView) приводят к фатальному ухудшению пользовательского опыта.

В этой статье я подробно рассмотрю весь путь: от концепции разработки LogicPad, реализации на C++ и WinUI 3 (Windows App SDK), преодоления специфических технических барьеров, упаковки в формат MSIX, и до публикации для всего мира через Microsoft Store, сопровождая это глубокими техническими объяснениями. Я надеюсь, что мой опыт того, как независимый разработчик может создать нативное Windows-приложение корпоративного качества, станет ориентиром для тех, кто также решил бросить вызов нативной разработке.

2. График проекта

Разработка LogicPad велась как личный проект в выходные дни и по вечерам. Весь проект занял около полугода (6 месяцев). Ниже представлена диаграмма Ганта, показывающая ход выполнения проекта.

gantt
title График разработки LogicPad
dateFormat YYYY-MM-DD
section "Планирование и дизайн"
"Анализ требований и прототипирование" :a1, 2025-10-01, 30d
"Проектирование архитектуры (Ядро C++)" :a2, after a1, 20d
section "Разработка ядра"
"Движок симуляции (C++)" :a3, after a2, 45d
"Интеграция WinUI 3 XAML" :a4, after a3, 40d
section "Улучшение UI/UX"
"Кастомная строка заголовка и окна" :a5, after a4, 15d
"Асинхронный диспетчер и многопоточность" :a6, after a5, 15d
section "Релиз и магазин"
"Упаковка MSIX и разрешения" :a7, after a6, 10d
"Сертификация Microsoft Store" :a8, after a7, 14d

Как видно, большая часть времени разработки была потрачена на оптимизацию базового движка и интеграцию асинхронной обработки между WinUI 3 и C++. Несмотря на то, что нативная разработка имеет более высокие затраты на начальную настройку и обучение по сравнению с кроссплатформенной разработкой, эти инвестиции определенно окупаются в виде конечной производительности.

3. Выбор технологий: Глубины C++ / WinUI 3 / Windows App SDK

При разработке LogicPad выбор технологического стека был одним из самых важных решений. Исторически на платформе Windows существовали различные варианты нативных UI-фреймворков, такие как Win32 API (User32/GDI), MFC, Windows Forms, WPF, UWP и др. В настоящее время Microsoft рекомендует для разработки современных настольных приложений Windows использовать WinUI 3, который входит в состав Windows App SDK.

3.1. Архитектура Windows App SDK и WinUI 3

Windows App SDK — это набор библиотек для предоставления новейших Windows API независимо от версии ОС. В то время как традиционная UWP (Universal Windows Platform) была тесно связана с обновлениями ОС, Windows App SDK распространяется вместе с приложением, что гарантирует стабильную работу от Windows 10 (начиная с версии 1809) до Windows 11.

WinUI 3 — это нативный UI-фреймворк, работающий поверх Windows App SDK, полностью поддерживающий Fluent Design System. Внутреннее устройство WinUI 3 реализовано на C++ и DirectX, что обеспечивает очень высокую скорость работы.

3.2. Почему был выбран C++ (C++/WinRT), а не C#

Для разработки на WinUI 3 поддерживаются языки C# и C++. Использование C# и .NET значительно повысило бы скорость разработки, но в LogicPad я выбрал C++/WinRT по следующим причинам:

Детерминированное управление памятью: Отсутствие сборщика мусора (GC) позволяет полностью контролировать время выделения и освобождения памяти. Это предотвращает паузы GC во время цикла симуляции.
Оптимизация SIMD и кэша: В C++ можно строго определить физическую структуру данных в памяти (например, Struct of Arrays), чтобы максимизировать процент попадания в кэш процессора.
Нативные ABI-границы: C++/WinRT — это современная проекция C++ для COM (Component Object Model). Это позволяет вызывать нативные API ОС напрямую, без накладных расходов P/Invoke, как в C#.

В основе C++/WinRT лежит COM. Все объекты WinRT по сути являются COM-объектами, реализующими интерфейс IUnknown, а умные указатели C++/WinRT, такие как winrt::com_ptr, автоматически управляют подсчетом ссылок (AddRef / Release).

4. Главные препятствия и прорывы в разработке на WinUI 3

Разработка WinUI 3 с использованием C++/WinRT очень мощная, но при этом сопряжена со специфической сложностью. Здесь я подробно объясню две основные технические проблемы, с которыми я столкнулся при разработке LogicPad, и пути их решения.

4.1. Ужас асинхронного обновления UI в C++ и корутины

Золотое правило современных UI-приложений — «не блокировать поток пользовательского интерфейса (UI-поток)». В LogicPad необходимо выполнять симуляцию огромных схем в фоновом потоке, а затем отображать результаты в UI-потоке.

В C# это можно довольно просто описать с помощью async/await и DispatcherQueue, но в C++ это реализуется путем комбинирования корутин C++20 (Coroutines) и winrt::apartment_context. Здесь необходимо понимание квартирной модели COM (STA: Single-Threaded Apartment и MTA: Multi-Threaded Apartment).

Следующий код из реальной кодовой базы LogicPad демонстрирует паттерн бесшовного перехода между фоновыми вычислениями и возвратом в UI-поток.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48


#include <winrt/Windows.Foundation.h>
#include <winrt/Microsoft.UI.Dispatching.h>
#include <winrt/Microsoft.UI.Xaml.h>

using namespace winrt;
using namespace Microsoft::UI::Xaml;
using namespace Microsoft::UI::Dispatching;

// Обработчик события нажатия кнопки
winrt::fire_and_forget MainWindow::OnRunSimulationClicked(
 IInspectable const& /* sender */,
 RoutedEventArgs const& /* args */)
{
 // Захват контекста квартиры (STA) текущего UI-потока
 winrt::apartment_context ui_thread;

 try
 {
 // Обновление статуса UI (выполняется в UI-потоке)
 StatusTextBlock().Text(L"Идет симуляция...");
 ProgressBar().IsIndeterminate(true);

 // Переход контекста в пул потоков (MTA)
 co_await winrt::resume_background();

 // Очень тяжелый процесс симуляции (выполняется в фоновом потоке)
 // В это время UI-поток освобождается, предотвращая зависание приложения
 std::vector<LogicResult> results = CoreEngine::RunMassiveSimulation();

 // Форматирование результатов симуляции в строку (продолжается в фоне)
 winrt::hstring outputText = FormatResults(results);

 // Возврат контекста в UI-поток
 co_await ui_thread;

 // Дальнейший код выполняется в UI-потоке, поэтому можно безопасно обращаться к элементам управления XAML
 ResultTextBlock().Text(outputText);
 ProgressBar().IsIndeterminate(false);
 StatusTextBlock().Text(L"Завершено");
 }
 catch (winrt::hresult_error const& ex)
 {
 // При возникновении исключения также возвращаемся в UI-поток для отображения сообщения об ошибке
 co_await ui_thread;
 StatusTextBlock().Text(L"Ошибка: " + ex.message());
 ProgressBar().IsIndeterminate(false);
 }
}

Поведение winrt::apartment_context выглядит как магия, но внутренне он использует интерфейс IContextCallback для запоминания исходного контекста потока, и во время co_await ставит в очередь (отправляет) выполнение обратно в этот контекст — это продвинутый механизм C++. Это позволяет писать асинхронный код в процедурном стиле, избегая ада коллбеков.

4.2. Идеальная реализация кастомной строки заголовка

В приложениях эпохи Windows 11 «кастомная строка заголовка» (область caption), где размещаются вкладки или строка поиска, является обязательным требованием современного UX. В WinUI 3 просто изменить цвет строки заголовка легко, но попытка удовлетворить требование «расширить клиентскую область на строку заголовка, сохранив при этом возможность перемещения окна и функции Snap Layouts (автоматическое изменение размера при перетаскивании к краю экрана)», резко повышает уровень сложности.

В LogicPad я использовал API ExtendsContentIntoTitleBar, чтобы создать строку заголовка из собственных XAML-элементов. Ниже приведен код настройки строки заголовка с использованием класса AppWindow из Windows App SDK.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


#include <winrt/Microsoft.UI.Windowing.h>
#include <winrt/Microsoft.UI.Interop.h>
#include <microsoft.ui.interop.h> // for GetWindowIdFromWindow

void MainWindow::InitializeCustomTitleBar()
{
 // Получение HWND (дескриптор окна) текущего окна
 auto windowNative = this->try_as<::IWindowNative>();
 HWND hwnd{ nullptr };
 windowNative->get_WindowHandle(&hwnd);

 // Преобразование HWND в WindowId и получение экземпляра AppWindow
 winrt::Microsoft::UI::WindowId windowId =
 winrt::Microsoft::UI::GetWindowIdFromWindow(hwnd);
 auto appWindow = winrt::Microsoft::UI::Windowing::AppWindow::GetFromWindowId(windowId);

 // Проверка, поддерживает ли версия ОС кастомизацию
 if (winrt::Microsoft::UI::Windowing::AppWindowTitleBar::IsCustomizationSupported())
 {
 auto titleBar = appWindow.TitleBar();

 // Расширение клиентской области (контента) на строку заголовка
 titleBar.ExtendsContentIntoTitleBar(true);

 // Делаем фон стандартных кнопок заголовка (свернуть/развернуть/закрыть) прозрачным
 titleBar.ButtonBackgroundColor(winrt::Microsoft::UI::Colors::Transparent());
 titleBar.ButtonInactiveBackgroundColor(winrt::Microsoft::UI::Colors::Transparent());

 // Установка UI-элемента (AppTitleBar), определенного в XAML, как области перетаскивания
 // *Для этого необходимо отслеживать UIElement на стороне XAML с помощью Dispatcher в UI-потоке,
 // и вызывать SetDragRectangles(), чтобы сообщить ОС об областях, доступных для перетаскивания.
 }
}

Самая большая ловушка в этой реализации заключается в том, что каждый раз, когда размер элемента пользовательского интерфейса со стороны XAML меняется (например, при изменении размера окна), необходимо пересчитывать и уведомлять ОС об области hit-test со словами «здесь можно перетаскивать», используя InputNonClientPointerSource или SetDragRectangles. Если этого не сделать, возникнут ошибки: окно не будет двигаться при перетаскивании за заголовок, или нажатие на кнопку будет распознаваться как перетаскивание окна.

5. Глубины упаковки MSIX и AppXManifest

Для распространения завершенного LogicPad необходимо создать установщик. Вместо традиционных установщиков MSI или EXE я выбрал современный формат MSIX. MSIX обеспечивает абсолютно чистую установку и удаление (не засоряет реестр) и включает функцию автоматического обновления, что очень безопасно и удобно для пользователей.

Однако при упаковке нативного приложения, написанного на C++, в формат MSIX самое важное, на что следует обратить внимание — это настройки Package.appxmanifest (файла манифеста).

LogicPad должен читать и писать огромные файлы проектов, сохраненные в локальной файловой системе (например, в папке «Документы» пользователя). В стандартной изолированной среде (AppContainer) UWP приложение имеет доступ только к собственной изолированной папке данных. Чтобы получить права полного доступа как у нативного десктопного приложения, необходимо объявить возможность runFullTrust в манифесте.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


<?xml version="1.0" encoding="utf-8"?>
<Package
 xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10"
 xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10"
 xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
 IgnorableNamespaces="uap rescap">

 <Identity
 Name="LogicPad.Studio"
 Publisher="CN=Kenji"
 Version="1.0.0.0" />

 <Properties>
 <DisplayName>LogicPad</DisplayName>
 <PublisherDisplayName>Kenji</PublisherDisplayName>
 <Logo>Assets\StoreLogo.png</Logo>
 </Properties>

 <Dependencies>
 <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.17763.0" MaxVersionTested="10.0.22621.0" />
 </Dependencies>

 <Capabilities>
 <!-- Обычные ограничения возможностей -->
 <Capability Name="internetClient" />
 <!-- Ограниченная возможность для работы в качестве нативного десктопного приложения -->
 <rescap:Capability Name="runFullTrust" />
 </Capabilities>
</Package>

Это <rescap:Capability Name="runFullTrust" /> называется «ограниченной возможностью» (Restricted Capability). При отправке в Microsoft Store вам нужно будет предоставить письменное обоснование рецензентам, почему требуется это разрешение. Я объяснил, что «это приложение является инструментом для профессионалов, которое читает, записывает и экспортирует любые файлы проектов логических схем на локальном диске пользователя», и успешно прошел проверку.

6. Путь к Microsoft Store и процесс проверки

После завершения работы над приложением и сборки пакета MSIX наступает время для отправки в Microsoft Store. Для независимого разработчика распространение через магазин дает неоценимые преимущества: автоматическая доставка обновлений, гарантия надежности и использование платежной системы.

Процесс отправки в Microsoft Store осуществляется через Partner Center (Центр партнеров). Блок-схема ниже показывает весь путь от сборки до публикации.

flowchart TD
A["Разработчик (Visual Studio)"] -->|Сборка и подпись| B["Генерация пакета MSIX Bundle"]
B --> C["Windows App Certification Kit (WACK)"]
C -->|Пройдено| D["Панель управления Partner Center"]
C -->|Провалено| E["Исправление кода / манифеста"]
E --> A
D -->|Загрузка пакета| F["Процесс сертификации в Store"]
F --> G["Автоматическое сканирование на вредоносное ПО"]
G --> H["Ручная проверка контента"]
H -->|Одобрено| I["Публикация в Microsoft Store"]
H -->|Отклонено| J["Исправление замечаний и повторная отправка"]
J --> D
I --> K["Приложение опубликовано!"]

6.1. Барьер WACK (Windows App Certification Kit)

Перед загрузкой в Partner Center вы должны локально запустить WACK (Windows App Certification Kit) и пройти предварительное тестирование. WACK — это инструмент, который автоматически проверяет приложение на наличие сбоев, вызовы недопустимых API и соответствие требованиям производительности.

Для нативных приложений на C++ особую осторожность следует проявлять с ошибками «использование неподдерживаемого API». Если вы статически компонуете старую стороннюю C++ библиотеку, то внутри нее могут использоваться устаревшие Win32 API, из-за чего проверка WACK не будет пройдена. Чтобы обойти эту проблему, я обновил зависимости до последних версий и переписал некоторые функции на альтернативные API, предоставляемые Windows App SDK.

6.2. Проверка и публикация

Настройки в Partner Center включают ценообразование приложения, возрастные ограничения (рейтинг IARC), а также ввод скриншотов и описаний для магазина. Поскольку LogicPad — это технический инструмент, я моментально получил рейтинг для всех возрастов.

С момента отправки пакета до завершения проверки прошло около 3 рабочих дней. После автоматического сканирования на вирусы и проверки функциональности, команда рецензентов Microsoft проводит ручную проверку. Запрос на разрешение runFullTrust прошел без проблем, и чувство достижения, когда статус наконец изменился на «Опубликовано» (In the Store), было ни с чем не сравнимым.

7. Личная разработка как бизнес: Математическая модель производительности и дохода

Чтобы не просто создать приложение и быть довольным, а постоянно обновлять LogicPad и превратить его в успешный бизнес, необходимо количественно оценивать как технические, так и бизнес-показатели.

7.1. Модель оптимизации потребления памяти благодаря C++

Главное преимущество LogicPad заключается в его невероятной легковесности по сравнению с редакторами на базе Electron (например, VSCode). След памяти (memory footprint) приложения $M_{total}$ можно смоделировать следующим образом:

$$ M_{total} = M_{UI} + M_{engine} + M_{cache} $$

Здесь затраты памяти на нативный рендеринг WinUI 3 $M_{UI}$ кардинально меньше по сравнению с Electron, который загружает браузерный движок (около 50 МБ). Кроме того, память C++ движка $M_{engine}$ линейно масштабируется относительно количества логических вентилей $N$, благодаря оптимизированным структурам и устранению указателей.

$$ M_{engine} = N \times \text{sizeof(LogicNode)} $$

Используя #pragma pack в C++ для оптимизации выравнивания структуры, я минимизировал потребление памяти на каждый узел до предела.

1
2
3
4
5
6
7
8
9


#pragma pack(push, 1)
// Отказ от таблицы виртуальных функций (vtable) и упаковка для минимизации памяти
struct LogicNode {
 uint32_t id; // 4 байта
 uint16_t type; // 2 байта
 bool isActive; // 1 байт
 // Размер структуры — 7 байт (без выравнивающего паддинга)
};
#pragma pack(pop)

Память кэш-слоя $M_{cache}$ для хранения истории симуляции увеличивается пропорционально $\mathcal{O}(N \log N)$, но поскольку базовый след памяти небольшой, даже для схем из десятков тысяч узлов потребление ОЗУ всей системы остается в пределах 200 МБ.

7.2. LTV и CAC: Расчеты маркетинга

В стратегии монетизации личных проектов баланс между пожизненной ценностью клиента (LTV: Lifetime Value) и стоимостью привлечения клиента (CAC: Customer Acquisition Cost) решает все. LogicPad использует не подписку, а модель лицензии с разовой покупкой (freemium).

LTV рассчитывается как сумма текущей стоимости вероятности будущих покупок обновлений, дисконтированная по ставке $d$. За период $T$ это выражается следующей формулой:

$$ LTV = \sum_{t=1}^{T} \frac{ARPU_t \times Margin}{(1+d)^t} $$

С другой стороны, CAC — это общая сумма маркетинговых затрат, таких как реклама в Twitter (ныне X) или привлечение через статьи в блогах, разделенная на количество новых пользователей.

$$ CAC = \frac{Total\ Marketing\ Spend}{Number\ of\ New\ Users} $$

Преимущество индивидуальной разработки в том, что затраты на рабочее время можно считать безвозвратными как «время на хобби», и CAC можно рассчитывать только на основе чистых маркетинговых расходов. В настоящее время благодаря органическому трафику, в основном основанному на рекомендациях в нишевых технических сообществах, мы достигаем здоровой юнит-экономики $LTV > CAC$ в состоянии, когда $CAC \approx 0$.

8. Заключение: суровый, но прекрасный мир нативной разработки

Оглядываясь на путь разработки LogicPad и его выпуск в Microsoft Store, могу сказать, что это был далеко не простой путь: борьба с запутанными ошибками компиляции C++/WinRT, отслеживание утечек памяти из-за ошибок подсчета ссылок COM, а также изучение XML-спецификаций манифеста MSIX.

Именно потому, что с развитием веб-технологий наступила эпоха, когда «в браузере можно сделать всё что угодно», опыт нативной разработки, когда вы напрямую обращаетесь к API ОС и заботитесь о каждом байте памяти и такте процессора, в подавляющей степени повышает базовую квалификацию инженера.

WinUI 3 и Windows App SDK продолжают активно развиваться и являются лучшими инструментами для создания красивых приложений, максимально использующих парадигму пользовательского интерфейса Windows 11. Я искренне надеюсь, что этот пост в блоге поможет разработчикам, которые собираются попробовать свои силы в нативной разработке для Windows, и что в Store появится еще больше отличных приложений.

Разработка еще не закончена. В следующей версии LogicPad планируется интеграция собственного движка рендеринга волновых форм на базе Direct2D. В следующей статье мы планируем углубиться во взаимодействие DirectX и WinUI 3 (использование SwapChainPanel). Оставайтесь с нами.

Personal Project on kenji.blog