Жизненный цикл приложений WinForms

1. Создание экземпляра формы — за это отвечает конструктор.

2. Форма уже создана, но еще остается не видимой — за это отвечает событие Load.

3. Форма становится видимой, становится текущей и ей передается фокус — за это отвечает событие Activated. Если пользователь переключается на другую форму этого приложения, то возникает событие Deactivate для этой формы, т.е. она теряет фокус. Соответственно, у другой формы возникает событие Activated и фокус передается ей.

4. Форма закрывается — за это отвечает событие FormClosing. Событие Closing прерывает процесс, но форма еще не закрыта, она еще отображается на экране. Его еще возможно отменить. Например, пользователь кликает на правой верхней кнопке "крестик", появляется диалоговое окно "Вы действительно хотите закрыть программу?".

5. Закрытие формы — за это отвечает событие FormClosed.

6. Форма теряет фокус и исчезает — за это отвечает событие Deactivate.

7. Освобождаются ресурсы, происходит очистка мусора — за это отвечает метод Dispose().

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

Разумеется есть некоторые стереотипы поведения приложений определенных типов. Но ни кто не мешает их нарушать если это необходимо и оправданно или просто захотелось. Например WCF-сервис, вовсе не обязательно публиковать как веб приложение или устанавливать в качестве системной службы, вполне можно запустить в виде консольного приложения или фоновым потоком оконного приложения, хуже выполнять свои задачи от такого обращения он не станет, при наличии достаточно количества ресурсов разумеется. Ваше приложение может быть монолитным или собираться как конструктор из плагинов, ваше право.

Это не реклама платформы, просто некоторые факты. Своих проблем и тараканов тут столько же, если не больше.

Единственное исключение, это приложения UWP, их жизненный цикл похож на жизненный цикл приложений андроид. Подробности тут.

При компиляции приложение компилируется в байт-код.

Затем, при запуске приложения выполняется JIT-компиляция, которая преобразует байт-код в машинный код. Так как JIT-компиляция на машине конечного пользователя, то может быть проделана дополнительная оптимизация. Например, если было указано ANY CPU, то программа может быть скомпилирована под х64, если целевая машина работает под ним.

Далее, идет запуск самого приложения.

Запускается главная форма.

Так же стоит отметить, что формы привязаны к потоку в котором они были созданы.

Т.е ты не можешь обратиться к контролам из другого потоко=> нужно использовать трюк с INVOKE.

Приложение живет, пока живет главная форма.

Иными словами, если главную форму закрыть или произойдет какое-либо не обрабатываемое исключение, то приложение умрет.

Не знаю, что еще можно добавить.