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
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
|
---
title: Оптимизация запуска
slug: Web/Performance/Optimizing_startup_performance
translation_of: Web/Performance/Optimizing_startup_performance
---
<div class="summary">
<p>Часто упускаемый из вида аспект разработки приложений - это скорость запуска приложения. Даже если вы прикладываете много усилий к оптимизации работы приложений, именно этот этап может быть пропущен. Как долго запускается ваше приложение? Создается ли впечатление, что устройство зависает, пока приложение запускается? Все эти симптомы заставляют пользователя считать, что приложение сломано или что-то идет не так. Всегда будет не лишним убедиться, что ваше приложение запускается плавно. В этой статье мы поделимся некоторыми подсказками, которые помогут вам оптимизировать запуск приложения, вне зависимости от того, пишете ли вы его с нуля или работаете над уже существующим.</p>
</div>
<h2 id="Приятный_запуск">Приятный запуск</h2>
<p>Не имеет значения, какую платформу вы используете, всегда будет правильным обеспечить как можно более быструю загрузку приложения. Так как это наиболее общая проблема, мы не будем заострять на ней внимание здесь. Однако, мы обратим внимание на наибольшую проблему Web-приложений: синхронная загрузка ресурсов. Решением этой проблемы был бы максимальный переход на асинхронную загрузку ресурсов. Это означает, что инициализриующий код не должен запускаться в одно единственном обработчике событий в главном потоке процесса.</p>
<p>Вместо этого, вы можете разбить ваш код так, чтобы часть его обрабатывалась в <a href="/en-US/docs/DOM/Using_web_workers" title="/en-US/docs/DOM/Using_web_workers">Web worker</a>, что выделит его в отдельные фоновые неблокирующие треды (например, запросы данных и их обработка). Затем, все, что должно быть выполнено в основном потоке (например, пользовательские события или рендеринг интерфейса) должно быть разбито на небольшие кусочки так, чтобы обработчик браузера выполнял небольшие куски кода итеративно, а не за один подход. Это позволит ваше приложению выглядеть отзывчивым даже во время первоначальной загрузки.</p>
<p>Почему так важно делать все это асинхронно? Помимо причин, перечисленных выше, подумайте о влиянии, которые оказывают зависшие приложения: пользователь не может отменить запуск, даже если он запустил приложение по ошибке. Если приложение запускается в браузере, пользователь даже не сможет закрыть вкладку. В конечно счете это может привести даже к системным предупреждениям о "медленных скриптах" или "исчерпании памяти". А ведь было время, когда каждая вкладка не работала в отдельном процессе, как сейчас, а потому повисшая вкладка приводила к зависанию всего браузера! Вы должны не просто делать загрузку приложения "мягкой", но и давать пользователю знать о процессе загрузки: показывайте ему прогресс-бары или этапы, которые проходит приложение. Это позволит пользователю убедиться, что приложение не зависло.</p>
<h3 id="Было_бы_желание...">Было бы желание...</h3>
<p>Если вы начинаете ваш проект с нуля, обычно очень легко начать писать код "правильно", делая все изначально асинхронным. Все вычисления при запуски должны выполняться в фоновых потоках, в то время как основной поток должен держаться максимально очищенным от лишних функций. Включайте индикатор прогресса для того, чтобы пользователь знал, что сейчас происходит и не думал, что приложение сломано. В теории, если вы только начинаете разработку приложения - это все должно быть очень просто.</p>
<p>С другой стороны, потребуются некоторые ухищрения, если вы пытаетесь портировать существующее десктопное приложение в Web или привыкли писать такие. Десктопные приложения обычно не нуждаются в написании кода в асинхронной манере, потому что операционная система берет заботу об этом на себя. В исходниках такого приложения может быть лишь один поток обработки кода, но даже он может быть легко разбит на асинхронные этапы (запуском каждой новой итерации потока по отдельности). В таких приложениях запуск часто представляет собой последовательную монолитную процедуру, которая время от времени обращается к метрикам прогресса и обновляет их.</p>
<p>И хотя вы можете использовать <a href="/en-US/docs/DOM/Using_web_workers" title="/en-US/docs/DOM/Using_web_workers">Web workers</a>, чтобы обработать очень большие и "тяжелые" скрипты асинхронно, вы должны учитывать некоторые ограничения. Web Worker-ы не имеют доступа к некоторым API браузера: DOM, <a href="/en-US/docs/WebGL" title="/en-US/docs/WebGL">WebGL</a> или audio, они не могут посылать синхронные сообщения в основной поток, вы даже не можете проксировать некоторые из этих API в основной поток. Это всё означает, что вы можете поместить в Web Worker-ы только "чистые функции", но вам все равно придется вычислять огромную часть данных в основном потоке. Поэтому очень полезно разрабатывать систему так, чтобы в ней было как можно больше чистых функций - так их будет проще делегировать последствии.</p>
<p>Тем не менее, даже код в основном потоке можно сделать асинхронным, приложив лишь небольшие усилия.</p>
<h2 id="Переход_к_асинхронности">Переход к асинхронности</h2>
<p>Есть несколько предложений, как сделать процесс загрузки асинхронным:</p>
<ul>
<li>Используйте атрибуты {{ htmlattrxref("defer") }} или {{ htmlattrxref("async") }} на тегах script. Это позволит HTML парсерам продолжать парсинг документа, вместо того, чтобы переключаться на скачивание / парсинг / выполнение скриптов.</li>
<li>Если вам нужно декодировать какой-то ресурс (например, JPEG для превращения его в текстуру в WebGL), делайте это в Worker-ах.</li>
<li>Когда вы имеете дело с данными, поддерживаемыми браузером, используйте встроенные декодеры, а не пишите свои. Это касается, например, декодинга изображений / видео. Производители браузеров стараются применять лучшие техники, наиболее совместимые с их кодовой базой. Кроме того, многие браузеры поддерживают параллельное выполнение таких обработчиков.</li>
<li>Любая обработка данных, которая может быть сделана параллельно <strong>должна </strong>быть сделана параллельно.</li>
<li>Не подключайте скрипты и стили, которые не критичны для запуска приложения, в инициализирующий HTML. Загружайте их только тогда, когда это необходимо.</li>
<li>Сокращайте размеры ваших JavaScript-файлов. Попробуйте отправлять минифицированный код и используйте сжатие, например Gzip или Brotli.</li>
<li>Используйте дополнительные атрибуты (например preconnect или preload) всегда, когда есть возможность сказать браузеру, что является критическим для вашей системы.</li>
</ul>
<p>Чем больше вещей вы можете сделать асинхронно, тем большие преимущества многоядерных процессоров вы сможете задействовать.</p>
<h3 id="Проблемы_портирования">Проблемы портирования</h3>
<p>Когда первоначальная загрузка завершена и начинается обработка приложения в основном потоке, вполне возможно, что ваше приложение обязано быть однопоточным, особенно если это портированная версия. Очень важно попытаться помочь процессу запуска приложения, порефакторив код, сделав его композитным, состоящим из маленьких кусочков, каждый из которых может быть обработан последовательно основным потоком. В этом случае, в промежутке между выполнением этих кусочков кода браузер сможет выделить время на обработку ввода (например, клик) или на обработку микро-задач.</p>
<p>В случае, если вы портируете ваше приложение, вы наверняка знаете о <a href="/en-US/docs/Mozilla/Projects/Emscripten">Emscripten. </a>Это решение предоставляет API, которое поможет с подобным рефакторингом. Например, вы можете использовать <code>emscripten_push_main_loop_blocker()</code>, чтобы определить фнукцию, как выполняемую после того, как основной поток разрешит продолжить работу. Создавая такие функции, создавая очередь, которая должна выполниться в определенном порядке, вы можете с легкостью разгрузить основной поток.</p>
<p>Конечно, все это не отменяет необходимости рефакторинга кода так, чтобы он работал лучше и это займет время. Но для старта этого может оказаться достаточно.</p>
<h3 id="Насколько_далеко_я_должен_зайти">Насколько далеко я должен зайти?</h3>
<p>Стоит держать в голове, что браузер начинает беспокоиться о вашем скрипте в том случае, если он блокирует основной поток больше, чем на 10 секунд. В идеале, вы не должны блокировать работу страницы так долго. И пока вы держите показатели загрузки приложения ниже этих значение - все должно быть ок. Но не забывайте, что если кто-то имеет не такой мощный компьютер или мобильное устройство, как у вас, то код, выполняющийся у вас за 2 секунды, у этого пользователя может занять 10 секунд. Для этого полезно использовать CPU Throttling, который предоставляется средствами разработчиков в некоорых браузерах.</p>
<h2 id="Другие_предложения">Другие предложения</h2>
<p>Существуют другие вещи, которые могут влиять на скорость запуска приложения, и одна лишь асинхонность не спасёт от всего. Вот несколько из них:</p>
<dl>
<dt>Время загрузки</dt>
<dd>Держите в голове, как много времени занимает загрузка данных вашего приложения. Если приложение действительно большое, популярное и должно обновлять данные часто, вы должны использовать как можно более быстрый хостинг (или даже несколько хостингов для разных регионов). Так же не забывайте сжимать данные.</dd>
<dt>Влияние GPU</dt>
<dd>Компиляция шейдеров или загрузка текстур в GPU может занять время, особенно для по-настоящему сложных WebGL приложений. Давайте пользователю знать о том, что загрузка или обработка данных продолжается фоном, чтобы он знал, когда лучше переходить в загруженные части приложения.</dd>
<dt>Размер данных</dt>
<dd>Делайте всё, чтобы избежать лишних данных. Чем меньше лишних данных запрашивается каждый раз, тем работает приложение. Используйте нормализацию данных и кеширование.</dd>
<dt>Субъективные факторы</dt>
<dd>Любая вещь, которую вы предлагаете пользователю во время запуска приложения и с которой он может взаимодействовать, заставляет время течь быстрее. Это забавно, но прогресс-бар, который показывается 3 секунды ощущается более быстрым, чем пустая страница в течение 1 секунды. Добавляйте подсказки к вашему приложению, рассказывайте интересные факты или просто показывайте что-то красивое - это уже улучшит восприятие.</dd>
</dl>
<h2 id="См._также">См. также</h2>
<ul>
<li><a href="/en-US/docs/Apps" title="/en-US/docs/Apps">Apps</a></li>
<li><a href="/en-US/docs/Games" title="/en-US/docs/Games">Games</a></li>
</ul>
<div class="originaldocinfo">
<h2 id="Original_Document_Information" name="Original_Document_Information">Информация об оригинальном документе:</h2>
<ul>
<li>Автор: Alon Zakai</li>
<li>Исходник: <a href="http://mozakai.blogspot.com/2012/07/bananabread-or-any-compiled-codebase.html" title="http://mozakai.blogspot.com/2012/07/bananabread-or-any-compiled-codebase.html">BananaBread (or any compiled codebase) Startup Experience</a></li>
</ul>
</div>
|
