Как стать автором
Обновить

Комментарии 67

Здорово. Буду пользоваться. Спасибо!
«Как это решалось раньше»

да точно также, без бубенов и плясок — показом модальной либо немодальной формы (по вкусу) при старте до создания главной формы и остальной загрузкой в бэкграунде.
В данном случае все равно придется ждать пока загрузятся библиотеки, необходимые для создания формы. Это относится к .net в целом. Показ SplashScreen занимает меньше секунды.
ну, главную форму можно не создавать, и ничего что только на ней используется загружаться пока не будет.
а вообще — не уловил вашей мысли. где именно не придется ждать библиотек для показа формы? или SplashScreen прямо на desktop-е рисуется?
Проблема в том, что для того, чтобы нарисовать сплэшскрин, нужно создать окно, в котором будет нарисована картинка. Чтобы создать окно нужно подгрузить System.Windows.Forms.dll, а она доволно тяжелая. Я так понимаю, что SplashScreen — это какая-то легковесная реализация окна, вызывающая напрямую WinApi-шные функции типа CreateWindowEx и т.п.
Спасибо! Оказалось, что это относится только к WPF приложениям.

Моя мысль заключается в том, что WPF приложение перед своим запуском тратит загружает .net библиотеки. Если запуск «холодный», то на это может уйти до 20(!) секунд.

SplashScreen показывается до начала загрузки WPF приложения.
а вы не можете подсказать, как решить собственно проблему долгой загрузки?
может быть загружать на стартапе системы какого-нибудь агента, который будет держать длл-ки в памяти?
Решения «в лоб» я не находил, но основные направления, в которых стоит копать есть в WPF Performance blog.
Будь уверен, я, как пользователь, вырублю твоего агента, если смогу.
если скорость запуска приложения критична, смотреть надо в сторону ngen.exe. Это тулса в составе .NET
Думаю, проблему с черным фоном при затухании можно решить изначально установив прозрачность сплеша близкой но не равной непрозрачности.
Черный фон возникает вообще, а не только при затухании. Иногда хочется чего-нибудь круглого. :) Но это практически не мешает: один раз из ста, если не реже.
можно перенести в блог .net :) иногда пользуюсь сплешскрином :)
Был бы рад ;)
ну думаю за Tipz вам повысят карму :)
это все конечно хорошо, кроме основного посыла: длительности загрузки. WPF приложение стартует долго не из-за загрузки большого количества DLL — это как раз быстро, — а из-за того, что долго поднимается DirectX.
В WPF Performance blog об этом ни слова. Да и в Висте, например, DirectX-у подниматься не надо. А скорость загрузки в Висте и ХР сравнимая.
Google по ключевым словам «WPF DirectX startup» расскажет вам много нового.
WPF приложение стартует долго, именно потому, что при открытии первой формы необходимо открывать DirectX контекст для приложения.

Более того, сама идея с библиотеками несостоятельна, хотя бы потому, что связывание в CRL статическое. Поэтому splash никак не может появиться раньше загрузки всех статически слинкованных библиотек.

Попробуйте попрофилировать открытие первого окна в WPF приложении — сомнений не останется.
Библиотеки может быть и связываются статически, но всё-таки, классы подгружаются по мере необходимости.
молодой человек, вы несете откровенную пургу.
.net сборки всегда грузятся целиком.
Навреное имел вввиду библиотеки.
это одно и то же в данном контексте.
Наткнулся случайно на старый пост и не смог оставить без ответа =)

Все статические поля класса инициализируются в статическом конструкторе, который вызывается только когда идёт первое обращение к классу.

То же относится и к P/Invoke библиотекам. Если окажется, что файла библиотеки не существует, то эксепшен будет выкинут только в момент JIT-компиляции вызывающего метода, а не при загрузке приложения.
Этот способ подходит для обычных дотнет приложений (не WPF)?
Я попробовал реализовать первый способ, однако сплешскрин не появился.
Может быть это потому что приложение само по себе запускается менее чем за секунду, и система считает что сплеш не нужен?
Нет, не подходит. Я написал в апдейте.
Они действительно загружаются гораздо быстрее WPF приложений.
>Этот способ подходит для обычных дотнет приложений (не WPF)?

А что такое обычное дотнет приложение? Если программировать для .NET 2.0 в VS 8.0, то там нужно просто нажать «Add New Item...», выбрать «Splash Screen» и далее зайти в свойства проекта и выбрать этот сплэш скрин.
Олдскульный метод — загрузку вашей сплеш формы (или объекта с ней) в аппликешн эвентс. Намного больше возможностей для создания информативного сплеша.
Милейший!
Вы предлагаете скрывать от конечного пользователя тормоза платформы, показывая картинку, у которой, кстати, может черти куда исчезнуть прозрачность, методом, ни за так череватым нативным эксепшеном?
Чесное слово, постеснялись бы )

з.ы.
Веду проэкт на дотнете третий год. Тоесть вроде-бы коллега. Такой вот колегеальный совет.
НЛО прилетело и опубликовало эту надпись здесь
Конечному пользователю необязательно знать про тормоза платформы. Из-за них он вряд ли сменит платформу. А вот имеющимися средствами обеспечить пользователю максимальный комфорт — это основная задача. И ему (пользователю) абсолютно все равно есть там ошибка или нет: главное чтобы работало.
>> главное чтобы работало
Вот это плохая тактика: о)
Тормоза платформы? о_О У меня .NET приложения нормально работают. «Что я делаю не так?» (с) habrahabr
Вы не так читаете. Давайте читать вместе!
Ниже приведены цитаты из поста, к которому я оставил этот комментарий. Прошу вас не побрезговать и прочитать их хотя бы однажды.
«Если вы сталкивались с программированием в .net, то наверняка замечали, что при запуске программы, написанной с использованием WPF, долгое время ничего не происходит.»

«Решить эту проблему можно показав заставку сразу после запуска. Это даст физический отклик сразу после запуска приложения и создаст иллюзию более быстрой загрузки.

О том, как это сделать написано под катом.»
Вы тоже не так читаете :) Давайте читать вместе!

«Тормоза платформы? о_О У меня .NET приложения нормально работают»

Работают без тормозов, а не загружаются… :)
Если вы согласны, что низкую скорость загрузки приложений можно отнести к «тормозам» платформы (jit, dx9, etc), то данный тред исчерпан )
Опять костыли придумывают, ох-е.
Вот еще один убедительный повод не пользоваться .NET программами, мне эта технология изначально не нравилась((

Надо не придумывать как отобразить сплеш, а правильно разрабатывать соответствующие библиотеки, чтобы не надо было ждать. Жаль что майкрософт пошла путем Gnome и KDE((
НЛО прилетело и опубликовало эту надпись здесь
> Стандартная 2.0 формочка отображается быстро, «не отличишь от настоящей», т.е. нативной.
Не надо. Если у вас много памяти и это горячий старт, то да, довольно быстро (современные 3-х гигагерцовые камни позволяют нам не отличать от настоящей). Но я видел как запускается пустая формочка на win98 с 64 Мб памяти и 500 Мгц процессором. Бедняга мучался в огонии ровно минуту. Естественно приложение с формой на winApi на нем запускается за миллисекунды. Так что разница есть, и она существенна.
НЛО прилетело и опубликовало эту надпись здесь
Ну вот и используйте всю мощность копеешного железа. Удивите меня. Но не заставкой, которая скрывает 10-и секундную загрузку фреймворка.
Вы, кстати, посмотрите как Apple решает проблему загрузки «тяжёлых» приложений под iPhone.
Они после старта пару секунд показывают скриншот этой программы, сделанный перед ее прошлым закрытием. А ведь типа тру-компания, не в пример страшным монстрам майкрософта…

Иногда проще заставкой откупиться и сэкономить компании пару дней своей работы, чем потратить их на оптимизацию какого-нибудь бизнес-приложения, которое запускают один раз в день.
Не дай бог MS пойдет тем путем что вы предлагаете. Отказываться от «удобнейших» технологий, чтобы удивлять людей которые до сих пор сидят на «win98 с 64 Мб памяти и 500 Мгц процессором» о_О

PS: Я готов ждать и 10 минут если дальше меня ждет красивая и удобная программа.
А как вы умудрились запустит .net (wpf а частности) под win98 ????
.net 2.0 вполне себе ставится на 98.
Правда про минуту при старте… Или там совсем не «пустая формочка» или что-то с машиной. Пустая форма загрузится за секунды.
Я и на ассамблере могу написать программу которая в win98 будет грузиться 2 часа :)))

PS: Прямые руки еще никто не отменял. А врать по прежнему не хорошо…
> программы, написанной с использованием WPF, долгое время ничего не происходит. Так продолжается секунд 10

Это ппц какой-то.

Будущее конечно за уравляемым кодом, но Microsoft .Net — очередной маркетинговый продукт.
НЛО прилетело и опубликовало эту надпись здесь
А что вы предлагаете? Java\ Swing? Python\ Qt? о_О

Так вот. Когда на эти языки научаться работать с анимацией так чтоб это все не тормозило, и мне не приходилось учить openGL или DiretX – тогда позовете. А пока лучше на заикайтесь что .Net 3.x – это плохо.
НЛО прилетело и опубликовало эту надпись здесь
Я не отрицаю очевидного, но время написания одинаковых приложений на Си и на WPF сильно отличается.
Да и к тому же это очень молодая технология. Трудно требовать от нее чего-то сверхъестественного.
НЛО прилетело и опубликовало эту надпись здесь
Разрабатывать начали давно, но реальное использование продукта обычно выходит за рамки, планируемые разработчиками :-)
Молодая не молодая… WPF – это мега ОХ… какая технология :)

Сколько бессонных ночей я провел в мечтах о «нестандартном» интерфейсе для своих программ. О «прозрачных» кнопках, и анимации. С прежними языками и технологиями:
1) Swing (Java)
2) Wx, Qt (Python, C++)
3) WinApi + DirectX (C++)
4) Windows Forms (.Net 2.0)
Мне оставалось только плакать в платочек :(

А теперь у меня есть .NET 3.x – и у меня – полные штаны счастья…
Теперь кнопки могут летать по форме и мне для этого ненужно замарачиватся с потоками и таймерами. Теперь элементы управления могут исчезать, а оставшиеся сами подстроятся под нужный мне размер — и для этого нужно всего пару строк кода. ПРИ ЭТОМ ВСЕ ЭТО НЕ ТОРМОЗИТ!!!

И самое главное – мне больше не нужно сдерживать свою больную фантазию… :)

PS: Так-что не стоит наезжать на WPF. Возможно вам эта технология ничего не дала (как мне WF и WCF). Но лично для меня WPF — это жизнь :)
Согласен. До того, как перевели проект на WPF мы замучались с отображением инфы. Около тысячи кораблей, разного типа, с оповещениями и без, обновляющиеся каждый в свое собственное время и при этом еще приходит видео с тех же радаров, которое нужно положить поверх полупрозрачным, но чтобы при наведении мыши оно становилось непрозрачным.

В GDI+ это было на грани. А в WPF только шаблончик написал и все появилось: тултипы, кнопочки на кораблях, анимированная прозрачность и т.д. И обновляется все само, без таймеров.

И при этом ничего не тормозит. Я не думаю, что это можно сделать лучше, быстрее и легче на чем-то другом.
Еще одно подтверждение моим словам :)

Вспомнить хотябы что было при появлении .Net Framework. Все только и говорили что он скоро загнется и мир захватят «web-приложения». Сейчас ругают WPF :)

И вообще кто-то из MVP сказал: «Некоторые против WPF и в качестве аргументов приводят, то что им просто хочется писать код. WPF же для этого и создано. Чтобы облегчить жизнь разработчика. Отделить представление от модели...»

PS: Недавно пробовал сделать что-то на Windows Forms. Ужас! Как я с этой технологией работал? :)))
«Как это решалось раньше»
А раньше это решалось оптимизацией кода, чтобы пользователю не приходилось ждать полминуты появления интерфейса простой программы.
НЛО прилетело и опубликовало эту надпись здесь
Нее. Сплэши появились одновременно с идеологией «тормозит — просто купите процессор мощнее». :)
Спасибо за дельный совет и доступный язык!
Добавлю в свои заметки. Хороший старт взяли на Хабре!
Как я понимаю, это первая полноценная, самостоятельная статья здесь?
Не снижайте уровень, ждём новых, полезных статей!
Да, первая. Спасибо.
В корне не согласен, с объяснением почему так долго загружается WPF приложение, особенно вот эта часть:

'SplashDemo.vshost.exe' (Managed): Loaded 'C:\Windows\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
'SplashDemo.vshost.exe' (Managed): Loaded 'C:\Windows\assembly\GAC_MSIL\Microsoft.VisualStudio.HostingProcess.Utilities\9.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.HostingProcess.Utilities.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.

Это показывает, что вы запускаете его в среде VS, а в это время загружается еще 3 не нужные сборки… у меня под VS любое приложение .NET запускается дольше.

WPF приложение, как было сказано в комментариях грузится ИНОГДА (подчеркиваю, потому что обычно проблем с долготой запуска не стоит) долго из-за инициализации DX (а если еще и аппаратной поддержки нету...)- у вас же игры тоже не по 1ms запускаются, а по несколько секунд, порой и минут.

Тем более вы описываете работу WPF уже в версии 3.5SP1, а в этом сервис паке было существенное увеличение производительности WPF приложений. Лично я разницу замечаю по загрузке и работе приложение с 1 SP и без него.

SplashWindow на самом деле грузится как нативное окно, почти сразу после старта приложения, НО загрузку библиотек mscorlib.dll, System.dll, WindowsBase.dll, System.XML.dll, System.Security.dll никто не отменял… так что тут скорость понятие относительное.

Из своего опыта могу сказать, что если делать SplashWindow на том же WPF (не нагружая это окно фигней всякой), различий в скорости «загрузки» почти не видно.
Хотя вот такая вещь очень даже интересна для ьыстроты разработки.
под VS приложение загружается дольше (и работает) не потому, что что-то лишнее грузится (а mscorlib, кстати, грузится всегда), а потому, что ваше приложение выполняется под отладчиком, а значит помимо производителньости, которую отжирает сам процесс отладки, у вас запрещены все JIT-оптимизации.
Ну вообще-то я имел ввиду сборки vshost, и Microsoft.VisualStudio.HostingProcess.Utilities.dll в первую очередь, что и говорит о том, что вы сказали :)
Благодаря конструктивной критике мне удалось уменьшить время полной загрузки приложения до 7 секунд, а время появления основного окна стало практически мгновенным. Чуть позже напишу напишу о том, что и как было сделано.
спасибо, познавательно для нубов)
Блин! Черт! Для меня было познавательно…

PS: Я реально не знал, про данную фишку :)))))
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.