В современных все более сложных клиентских приложениях, чтобы отслеживать, нормально ли работает внешнее приложение, некоторые данные, такие как ошибки и производительность, обычно собираются на внешнем интерфейсе, и в конечном итоге мы передаем эти данные на сервер.
Способов отчёта много, по идее нам нужно только отправить данные на сервер. Существует множество способов отправки запроса в браузере, включая, помимо прочего:xhr
,fetch
,script
Этикетка,img
Этикетка,link
Ярлыки, фоновые изображения CSS и т. д.
Существуют существенные различия между различными методами отчетности. Текущий основной метод отчетности заключается в использованииimg
помеченsrc
запрос отправки атрибута, например:
(new Image).src = `/haopv.gif?a=xx&b=xxx`
Поскольку отчеты по журналам не требуют обработки ответов, достаточно только отправить данные. И большинство адресов серверов, которые получают журналы и бизнес-сторону, могут не принадлежать к одному и тому же отделу или даже компании, поэтому будут затронуты междоменные проблемы. использоватьimg
помеченsrc
Атрибуты могут не только отправлять данные на сервер без получения ответа, но и решать междоменную проблему, поэтому в настоящее время это более популярная реализация отчетов по журналам.
Но действительно ли это нормально?
Отчетность по логам не является основной функциональной логикой приложения, то есть отчетность по логам является низкоприоритетной и не должна конкурировать с другими высокоприоритетными операциями (например: получением ключевых ресурсов, вводом ответов, запуском анимаций и т.п.) .) конкурировать за сетевые и вычислительные ресурсы (с точки зрения непрофессионала, поведение отчетов журнала не должно влиять на бизнес-логику и не должно занимать вычислительные ресурсы бизнеса). Но этот односторонний запрос также отвечает за передачу данных об ошибках приложения и производительности, поэтому мы должны убедиться, что он будет доставлен на сервер.
Часто, чтобы повысить скорость доставки, мы выбираем немедленную доставку всех собранных данных, а не объединение и отсрочку доставки. Задержка доставки может означать, что запросу не хватило времени для успешного выполнения, что может привести к потере важных данных приложения.
Это означает, что наше поведение доставки может быть вставлено в цикл событий, который занят работой, тем самым вытесняя ресурсы других высокоприоритетных задач, потому что JS является однопоточным. Это может повредить пользовательскому опыту.
Как мы обеспечиваем доставку данных журнала, сводя к минимуму конфликты ресурсов с другими критически важными операциями? Ответ - маяк.
Маяк
Маяки обеспечивают асинхронную и неблокирующую передачу данных, чтобы свести к минимуму конфликт ресурсов с другими критическими операциями, гарантируя при этом, что эти запросы обрабатываются и доставляются на сервер:
- Запросы маяка имеют приоритет, чтобы избежать конкуренции с критическими операциями и сетевыми запросами с более высоким приоритетом.
- Запросы маяков можно эффективно комбинировать для оптимизации энергопотребления на мобильных устройствах.
- Запросы маяка гарантированно запускаются до того, как страница будет выгружена, и могут выполняться до завершения без блокировки запросов или блокирования задач, обрабатывающих события взаимодействия с пользователем.
Использование маяков очень простое:
var data = JSON.stringify({
name: 'Berwin'
});
navigator.sendBeacon('/haopv', data)
параметр
- url: целевой адрес отчета
- данные: отчетные данные
- Возвращаемое значение (возвращаемое значение): метод sendBeacon возвращает логическое значение после его выполнения.
true
От имени пользовательского агента успешно ставит в очередь запрос маяка, в противном случае возвращаетfalse
.
Пользовательские агенты ограничивают объем данных, отправляемых через маяки, чтобы гарантировать успешную доставку запросов на сервер с минимальным влиянием на активность браузера. Если количество данных, которые нужно поставить в очередь, превышает ограничение пользовательского агента, метод sendBeacon вернет
false
,вернутьtrue
Указывает, что браузер поставил данные в очередь для доставки. Однако, поскольку фактическая передача данных является асинхронной, этот метод не предоставляет никакой информации о том, была ли передача данных успешной.
Хотя маяк имеет высокий уровень поддержки, но по-прежнему доступен не во всех браузерах, поэтому, если вы хотите использовать маяки для создания отчетов в журналах внешнего интерфейса, необходимо определить некоторые функции.
Еще одна вещь, которую следует отметить, это то, что для запросов, отправляемых через маяки, оба метода запросаPOST
, и не поддерживает модификацию.
Суммировать
Отчеты по журналам в рабочей среде — это не только отправка запросов. Отчеты по журналам не являются основной логикой, поэтому приоритет очень низкий.Для наилучшего взаимодействия с пользователем, при рассмотрении вопроса о том, чтобы не занимать вычислительные ресурсы бизнеса и избегать конкурирующих запросов бизнес-сети, мы также должны гарантировать, что данные будут доставлены на сервер. лучше всего использовать маяки как можно чаще.