Поведение WebAssembly на разных браузерных платформах

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

Модуль содержит типизированные инструкции и может объявлять память и импорты, связывающие его со средой. Спецификация определяет поведение поддерживаемых базовых инструкций, а страница и браузер предоставляют окружающие сервисы, например ввод, хранение и показ данных. Модуль, использующий распространённый набор функций и контролируемые входы, проще переносить, чем модуль, зависящий от дополнительных функций или специфичных для среды сервисов. Эта граница помогает понять, что переносится вместе с модулем, а что следует проверять в приложении, которое его подключает.

Доступность функций является частью контракта. Компилятор может выдать инструкции, которые не поддерживаются старой средой выполнения, даже если исходная программа выглядит неизменной. Поддержка браузеров развивается с разной скоростью, поэтому один лишь формат не гарантирует наличие всех нужных инструкций. Зафиксируйте минимальный набор функций в процессе сборки. Если нужны дополнительные возможности, подготовьте сборку для более широкого базового набора или запасной путь приложения и проверьте, как страница выбирает вариант.

Импорты связывают модуль с поведением, которое не определено ядром WebAssembly. Страница может предоставить функции доступа к данным или сервисам приложения, и у этих функций свои контракты. Правила импортов спецификации Core определяют их объявление, но соответствие импортов не гарантирует одинаковые возможности среды во всех браузерах. Ограничьте интерфейс импортов и опишите допустимые входы и выходы.

Различайте этапы: validate() проверяет байты модуля, compile() создаёт WebAssembly.Module, а instantiate() связывает импорты и создаёт экземпляр. Для инстанцирования также нужен корректный модуль (спецификация Core). Обрабатывайте сбой каждого этапа как отдельное состояние приложения и сохраняйте исходные данные. Необязательный модуль загружайте по запросу его задачи; завершение загрузки ничего не доказывает об устройстве пользователя.

Артефакт модуля следует считать версионируемым интерфейсом. Его экспортируемые функции и импортируемые сервисы образуют контракт со страницей, как сетевой запрос или сохранённая запись. Пользовательская секция может содержать отладочные сведения или данные сторонних расширений, но эти необязательные метаданные игнорируются семантикой WebAssembly и не заменяют версионирование приложения или решение о выпуске. Описание интерфейса страницы должно оставаться частью контракта приложения. Компилятор может изменить бинарный файл без изменения контракта, поэтому сравнивайте поведение, а не требуйте идентичных байтов.

Причины допустимых различий

Среда предоставляет ресурсы и импортируемые функции. Доступ к файлам, часам, сети, хранилищу и сервисам приложения подчиняется отдельным контрактам. Также различаются ресурсные лимиты и планирование задач. Скорость не является константой между устройствами, и изменение производительности не следует путать с изменением семантики модуля. Для проверки корректности сравнивайте результат с контрактом модуля и приложения, а не со временем, измеренным в другой системе.

Для одних числовых операций заданы точные правила, для других стандарт оставляет реализациям некоторую свободу. На результат также могут влиять преобразования значений WebAssembly и JavaScript, а также разбор и сериализация данных приложением. Если сценарий зависит от конкретного числового результата, определите операцию и формат представления. Не исходите из того, что все среды всегда возвращают побитно одинаковые значения, и не расширяйте правило сравнения, пока не проверите применимый стандарт и требование задачи.

Модули зависят и от доступных ресурсов. Выделение памяти, рост таблиц, использование стека и размер входных данных могут влиять на завершение задачи. Для стабильности браузер может ограничивать ресурсы, но эти ограничения не описывают физическую память компьютера. Ошибку выделения следует обрабатывать как ресурсное условие, а не как идентификатор устройства. Приложение может ограничить объём работы, сохранить пользовательский ввод и предложить другой путь, если задача не выполняется.

Дополнительные функции могут зависеть от среды развёртывания. Например, политика безопасности страницы или настройка worker может не предоставлять условия, необходимые модулю. Поэтому путь, работающий на локальной тестовой странице разработчика, может быть отклонён на странице продукта. Проверяйте фактическую среду развёртывания, включая политику страницы и использование worker, и фиксируйте относящееся к задаче требование. Это полезнее, чем собирать несвязанные свойства среды выполнения.

Предположения о параллельном выполнении также входят в контракт развёртывания. Модулю с общей памятью или координацией worker могут требоваться условия страницы, не нужные однопоточному модулю. Если продукт поддерживает оба пути, проверьте выбор и сохранение одинакового пользовательского контракта данных. Однопоточный вариант может быть менее отзывчивым, но всё ещё давать корректный результат для ограниченной задачи. Не делайте всю функцию недоступной только потому, что дополнительный параллельный путь не запускается. Укажите поддерживаемый контекст и проверьте запасной путь при той же политике развёртывания, что и основной.

Полезно различать три границы, на которых возникают отличия: скомпилированный модуль, реализация WebAssembly в браузере и сервисы среды, предоставленные приложением. Если изменился только артефакт, результат может объясняться новой целью компиляции или ревизией исходного кода. Если артефакт прежний, но изменился импортируемый сервис, следует проверить интеграцию страницы. Если оба фактора неизменны, а поведение различается между выпусками браузера, среда выполнения становится предметом сравнения. Этот порядок не предполагает причину заранее, а помогает последовательно проверить свидетельства и не считать любое платформенное отличие дефектом браузера.

Конфиденциальность и воспроизводимость

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

Передавайте модулю только данные, нужные для его задачи. Скомпилированный модуль доставляется клиенту, поэтому это обозримый код приложения, а не место для сокрытия учётных данных или частных записей. Для чувствительных сервисных операций нужна соответствующая авторизация; среда должна предоставлять только сервисы, необходимые пользователю. При отмене задачи или закрытии представления по возможности остановите работу и освободите ссылки, удерживающие входные данные.

Для воспроизводимых результатов фиксируйте артефакт модуля, параметры компиляции, импорты, входы и необходимые функции браузера. Модуль, который читает часы, получает от среды случайные данные или обращается к изменяемому хранилищу, может закономерно выдавать разные результаты при повторных запусках. Эти входы относятся к контракту приложения. Для повторяемости тесты должны их контролировать, а если на них зависит пользовательский сценарий, следует учитывать их изменение явно.

Сведения о доступных функциях помогают выбрать совместимый путь, но по умолчанию не должны становиться постоянной записью об идентичности. Если нужна диагностика, свяжите её с сообщённой пользователем проблемой, сохраните только версию и результат, необходимые для воспроизведения, и удалите запись после завершения поддержки. Не собирайте несвязанные временные или ресурсные наблюдения. Так проверяется конкретный сценарий, а не классифицируется среда.

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

Описывайте локальное выполнение точно. Модуль в браузере может оставить промежуточный расчёт на устройстве, но приложение всё равно способно отправить входные данные до выполнения или результаты после него. Страница также может загружать модуль и модель из удалённого источника. Проверяйте сетевые запросы и хранение данных вокруг модуля, а не выводите политику данных из формата выполнения. Если приложение поддерживает работу без сети, проверьте её без соединения и укажите доступные функции. Такие формулировки должны соответствовать поведению продукта, а не общему обещанию, связанному с WebAssembly.

Совместимость модуля

Документируйте минимальный набор WebAssembly, нужный модулю, и импорты среды, необходимые странице. Храните требования рядом с ревизией модуля, чтобы следующая сборка незаметно не повысила базовую версию браузера. Для дополнительных функций подготовьте другую сборку или запасной путь на странице. Заметка о совместимости должна описывать проверенный пользовательский сценарий, а не обещать, что формат сам по себе поддерживается везде.

Проверяйте весь путь вокруг модуля: загрузку, создание экземпляра, импорты, обычные входы, интерпретацию результата и ожидаемые отказы. Успешное создание экземпляра не доказывает, что пользовательская задача даёт приемлемый результат. Сбой также может быть вызван преобразованием входов или интеграцией со средой, а не отсутствующей инструкцией WebAssembly. Разделяйте случаи в тестах, чтобы устранять проблему на правильной границе.

Для чисел, которыми обмениваются WebAssembly и JavaScript, задайте формат представления и диапазон. Определите, использует ли интерфейс целые или дробные значения, байтовые буферы либо структурированные записи, и проверьте преобразования с обеих сторон. Сериализация и хранилище добавляют собственные правила представления. Для точного десятичного учёта выбирайте подходящий формат и задавайте округление на интерфейсе, а не полагайтесь на случайное поведение одной среды выполнения.

Запасной путь является частью совместимости. Если нужная функция недоступна, приложение может выбрать модуль для более широкого базового набора, ограниченный вариант или объясняющее сообщение. Проверьте этот путь с теми же пользовательскими данными и убедитесь, что незавершённая работа не теряется. Если отличаются точность результата или допустимая нагрузка, объясните компромисс. Запасной код, который нельзя выбрать на развёрнутой странице, пользователю не помогает.

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

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

Сравнение выпусков браузера

Сравнивайте кандидатный выпуск с тем же артефактом модуля, ревизией приложения, импортами, входами и средой развёртывания. Запишите выпуск и функциональный результат каждого необходимого сценария. Если модуль или тесты тоже меняются, сохраните прежний артефакт и ожидания до выяснения различий. Одновременное изменение нескольких переменных затрудняет определение причины результата: браузер, компилятор, приложение или тест.

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

Если тест изменился, сократите его до небольшого входного примера и проверьте требование стандарта. Для строго определённого поведения и операции с допустимым приближением нужны разные выводы. Прежде чем приписать результат выпуску браузера, проверьте преобразования приложения, импорты, параметры сборки и данные среды. Небольшое воспроизведение даёт конкретный вопрос совместимости без пользовательских данных и инвентаризации несвязанных свойств.

Тот же подход применяйте к обновлению компилятора и доставке модуля. Компилятор может изменить набор функций или артефакт, хотя браузер остаётся прежним. Если приложение распространяет несколько вариантов, проверьте выбор и кэширование, чтобы после выпуска каждая поддерживаемая среда получила нужный файл. Пересматривайте диапазон браузеров при изменении требований продукта. Этот процесс дополняет проверку выпуска браузера и отличается от темы временных сигналов браузера.

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

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

Публичные источники

• Спецификация WebAssembly Core, версия 2: импорты
• Спецификация WebAssembly Core, версия 2: проверка корректности
• Спецификация WebAssembly Core, версия 2: инстанцирование
• Спецификация WebAssembly Core, версия 2: пользовательские секции
• MDN: WebAssembly.validate()
• MDN: WebAssembly.compile()
• MDN: WebAssembly.instantiate()