Поделиться через

Предложения по проектированию основных приложений высокого уровня

  • Статья

Внимание

Это документация по Azure Sphere (устаревшая версия). Служба Azure Sphere (устаревшая версия) выходит на пенсию 27 сентября 2027 г., и к этому времени пользователи должны перейти в Azure Sphere (интегрированная). Используйте селектор версий, расположенный над toC, чтобы просмотреть документацию по Azure Sphere (интегрированная).

Чтобы создать высокоуровневое основное приложение (HL) на твердых основах, следует использовать основные рекомендации. Ниже приведены наиболее важные моменты.

Базовые приложения высокого уровня (HL) выполняют контейнеризованные в ОС Azure Sphere. Во время проверок кода и проектирования решений клиентов мы обнаружили несколько типичных проблем с приложениями HL-core. В этом разделе рассматриваются рекомендации по улучшению проектирования для решения этих проблем.

Общие основы

Чтобы создать приложение HL-core на твердых основах, следует использовать основные рекомендации. Ниже приведены наиболее важные моменты.

  • Инициализация и завершение. Всегда следует обрабатывать сигнал SIGTERM ОПЕРАЦИОННОй системы Azure Sphere и правильно инициализировать и уничтожить все обработчики (например, для периферийных устройств) при выходе либо после сбоя, либо при ошибке. Дополнительные сведения см. в разделе "Инициализация и завершение " и документация ПО GNU по сигналам завершения.
  • Всегда используйте коды выхода: убедитесь, что приложение HL-core всегда предоставляет значимый код возврата при выходе или сбое (например, с помощью обработчика SIGTERM) является важным для правильной диагностики поведения устройства, особенно из телеметрии аварийного дампа устройства. Дополнительные сведения см. в разделе "Коды выхода" и "Сбор и интерпретация данных об ошибках".
  • Убедитесь, что случаи сбоя всегда приводят к выходу или аварийному сбою приложения, а не в состоянии взаимоблокировки: сложная логика восстановления сбоев может быть контрпродуктивной, так как она может привести к ошибкам или поведению, что приводит к взаимоблокировке или состоянию, которое трудно диагностировать. Хорошо разработанное приложение Azure Sphere всегда должно предпочитать аварийное завершение или выход (с кодом выхода без нуля) в потенциальной ситуации взаимоблокировки, так как это приводит к обоим:
    • Ошибка телеметрии, включение диагностика для этой проблемы
    • Вероятность немедленного восстановления до рабочего состояния, так как ОС Azure Sphere перезагрузит приложение.
  • Обработка ошибок и ведение журнала. Точное обработка ошибок и ведение журнала находятся в основе разработки качественных приложений. Быстрые реализации функциональных возможностей могут оставаться скрытыми в слоях кода, а затем создаваться по мере разработки приложения до полного масштаба. Дополнительные сведения о рекомендациях см. в разделе "Обработка ошибок" и ведение журнала.
  • Используйте системный таймер в качестве сторожевой системы: одна из наиболее важных рекомендаций заключается в реализации обратного вызова "сторожевой таймер" (так же, как и аппаратные, доступные в аппаратных МК), которые отслеживают критические состояния приложения, обнаруживая взаимоблокировку и действуя соответствующим образом (например, выход и отправка телеметрии). Дополнительные сведения см. в разделе "Использование системного таймера в качестве наблюдателя".
  • Никогда не развертывайте рабочие приложения, созданные для набора инструментов бета-выпуска: использование наборов средств бета-выпуска не рекомендуется, так как не может быть гарантировано, что бета-подмножество не изменится в последующих версиях ОС. Наборы средств бета-версии выпускаются исключительно для тестирования новых функций заранее официального выпуска пакета SDK.

Обработка параллелизма

  • Используйте EventLoop всякий раз, когда это возможно: объекты потоков и синхронизации (т. е. мьютексы, семафоры и т. д.) используются для выполнения практически параллельных задач, но в внедренных системах это дорого с точки зрения использования системных ресурсов. Таким образом, чтобы повысить производительность, рассмотрите возможность использования epolls вместо потоков, для тех задач, которые не являются строго критически важными и не чувствительны к взаимной блокировке. Сведения о мониторинге и отправке событий с помощью EventLoop см. в разделе Applibs eventloop.h.
  • Ищите эффективность параллельных задач. Важно убедиться, что блокирующие операции и время ожидания сохраняются как минимум в пределах обратных вызовов epoll, в противном случае будут затронуты все остальные обратные вызовы epoll.
  • Когда следует использовать потоки (pthread): для определенных сценариев, таких как при блокировке вызовов, неизменяемыми, использование потоков может оказаться полезным, хотя обычно эти сценарии имеют ограниченное время существования и должны быть ограничены конкретными задачами. Например, учитывая, что ОС Azure Sphere (под управлением Linux) не предоставляет irQs для приложений HL-core (это доступно только для приложений RT-core), используя сочетание задач epoll и pthread, может быть оптимальным для обработки, например нижнего потока последовательной связи при скачивании данных из Интернета.

Внимание

ОС Azure Sphere может прерывать своевременные операции, особенно при выполнении аттестации устройств, проверки обновлений или отправки данных телеметрии. Для критически важных задач управления рекомендуется переместить их в ядра M4 и координировать их с соответствующим протоколом через межядерный почтовый ящик. Дополнительные сведения см. в примере взаимодействия между ядрами.

Помимо этих предложений, ознакомьтесь с документацией по Azure Sphere по асинхронным событиям и параллелизму.

мониторинг подключений;

Хорошо разработанное основное приложение высокого уровня (HL) должно реализовать правильную задачу проверки работоспособности подключения, которая должна основываться на надежном компьютере состояния, который регулярно проверяет состояние подключения к Интернету (например, с использованием таймера epoll), используя API Networking_IsNetworkingReady. В некоторых случаях можно использовать функцию Networking_GetInterfaceConnectionStatus, так как она обеспечивает более подробное состояние подключения, связанное с определенным сетевым интерфейсом, которое приложение HL-core может использовать для лучшего решения его состояния, хотя это происходит по стоимости, так как не рекомендуется вызывать его чаще, чем каждые 90 секунд.

Обратный вызов компьютера состояния обычно должен иметь следующие атрибуты:

  • Выполните как можно быстрее.
  • Его интервал опроса должен быть тщательно разработан на основе конкретного сценария приложения и общих требований к решению (например, постоянного времени, добавочной задержки и т. д.).
  • После обнаружения отключения может потребоваться вызвать Networking_GetInterfaceConnectionStatus один раз для регистрации состояния конкретного сетевого интерфейса, который можно использовать для диагностики проблемы и уведомления пользователя через пользовательский интерфейс (например, индикаторы, отображение, терминал). Пример этого подхода можно найти в основном коде примера DHCP Azure Sphere.
  • Активируйте механизм (например, с помощью глобальной переменной), которая останавливает все остальные задачи в приложении HL-core, выполняющем (или привязанные к) сетевым коммуникациям для оптимизации потребления ресурсов до тех пор, пока подключение не будет восстановлено.
  • cURL недавно обновил поведение обратного вызова и рекомендации. Хотя Azure Sphere предприняла усилия по обеспечению работы более старых версий cURL, рекомендуется следовать последним рекомендациям по обеспечению безопасности и надежности при использовании curl_multi, так как использование рекурсивных обратных вызовов может привести к непредвиденным сбоям, сбоям подключения и потенциальным уязвимостям безопасности. Если таймерCallback запускается с тайм-аутом 0ms, обработайте его как время ожидания 1 мс, чтобы избежать рекурсивных обратных вызовов. Не забудьте также вызывать curl_multi_socket_action явно по крайней мере один раз после вызовов curl_multi_add_handle.

В дополнение к предыдущим предложениям следует рассмотреть следующие сценарии управления питанием:

  • Выключите микросхему Azure Sphere после отправки данных. Дополнительные сведения см. в разделе "Управление состоянием Power Down" для устройств Azure Sphere.
  • Поскольку некоторые проблемы могут привести к длительным экспоненциальным тайм-аутам ожидания, важно отслеживать общее время простоя и задать таймер завершения работы в разумный предел, чтобы не слить батарею в условиях, когда подключение больше не возможно из-за внешних сбоев или других факторов за пределами контроля приложения.
  • При управлении мониторингом подключения во время сбоя транссивер Wi-Fi может отключить сетевой интерфейс (см. Networking_SetInterfaceState) и ждать, пока не будет снова проверять подключение, сохраняя wlan0 примерно 100mW.

Управление памятью и использование

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

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

  • Особенно в приложениях HL-core, которые интенсивно используют память, важно отслеживать использование памяти приложений с помощью API Azure Sphere, описанного в статье "Определение использования ОЗУ приложения во время выполнения". Как правило, это реализуется в сторожевой часы epoll-timer, и приложение реагирует соответствующим образом на непредвиденное использование памяти, чтобы перезапустить разумно; например, выход с соответствующим кодом выхода.

    Несколько клиентов и партнеров обнаружили, что полезно использовать программу отслеживания памяти Heap Tracker , которая публикуется в коллекции Azure Sphere. Эта библиотека прозрачно связывается с существующим приложением HL-core и отслеживает выделение памяти и связанные с ними указатели, что позволяет упростить обнаружение большинства случаев утечки памяти и неправильного использования указателя.

Внимание

Эта практика может уменьшить, по-видимому, необъяснимое устройство безответственности или сбоев, часто сообщаемых из поля. Такие сбои обычно вызваны утечками памяти или переполнениями, которые неправильно обрабатываются приложением HL-core и приводят к тому, что убийца OOM завершит процесс приложения. Это, а также плохое подключение, которое блокирует отправку телеметрии ОС Azure Sphere, может привести к потенциальным инцидентам полей, так как диагностика может быть обнаружена только путем извлечения журналов диагностики ОС Azure Sphere.

  • На платформах с ограниченным объемом памяти обычно рекомендуется избежать динамического выделения памяти, особенно в часто вызываемых функциях. Это значительно уменьшит фрагментацию памяти кучи и вероятность последующих сбоев выделения кучи. Кроме того, рассмотрим смену парадигмы от повторяющегося выделения временных рабочих буферов к непосредственному доступу к стеку (для переменных разумных размеров) или глобально выделенных буферов, которые увеличивают размер (через realloc) при переполнении (см . динамические контейнеры и буферы). Если требуется выгрузить память, рассмотрите возможность использования неиспользуемой памяти на ядрах M4 (см . сведения о памяти, доступной в Azure Sphere), которые имеют 256KiB с упрощенным приложением RT-core для кэширования данных. В конечном итоге можно использовать внешние SD-карты или флэш-память. Примеры можно найти в следующих репозиториях:

Следуя приведенным выше предложениям, также можно оценить и резервировать память, необходимую для работы приложения HL-core в полной емкости в течение всего жизненного цикла, позволяя лучше оценить общий объем памяти приложения для более поздних оптимизаций проектирования. Дополнительные сведения об оптимизации использования памяти в приложениях HL-core, включая функции в ОС Azure Sphere и Visual Studio, см. в следующих статьях: