共用方式為

高階核心應用程式設計建議

  • 發行項

若要在穩固的基礎上建置高階 (HL) 核心應用程式，您應該使用基本的最佳做法。 以下是最相關的專案：

高階 (HL) 核心應用程式會在 Azure 球體 OS 上執行容器化。 在客戶解決方案的程式代碼和設計審查期間，我們發現幾個 HL 核心應用程式的一般問題。 本主題討論改善設計以解決這些問題的建議。

一般基本概念

若要在實心基礎上建置 HL 核心應用程式，您應該使用基本的最佳做法。 以下是最相關的專案：

  • 初始化與終止： 請務必務必處理 Azure 球體 OS 的 SIGTERM 訊號，並適當地初始化並銷毀所有 (，例如介面設備) 在當機或錯誤時執行的處理程式。 如需詳細數據，請參閱 初始化與終止 ，以及關於 終止訊號的 GNU 檔。
  • 一律使用結束代碼： 確認 HL 核心應用程式在結束或當機時一律提供有意義的傳回代碼 (例如，使用 SIGTERM 處理器) 對於正確診斷裝置的行為，特別是從裝置的損毀傾印遙測而言是不可或缺的。 如需詳細資訊，請參閱 結束驗證碼 和 收集及解譯錯誤數據。
  • 確定失敗案例一律會導致應用程式結束或當機，而不是死鎖狀態： 複雜的失敗復原邏輯可能會造成不合作用，因為它可能會導致錯誤或行為導致死鎖或難以診斷的狀態。 設計完善的 Azure 球體應用程式應一律使用非零結束代碼來當機或結束 (，) 可能的死鎖狀況，因為這兩種情況的結果如下：
    • 錯誤遙測，啟用此問題的診斷
    • 由於 Azure 球體作業系統將重新啟動應用程式，立即復原到正常運作狀態的機會
  • 錯誤處理和記錄： 精確的錯誤處理和記錄是品質應用程式開發的核心。 快速功能實作會一直埋藏在程式代碼圖層中，然後隨著應用程式全面開發而建置。 如需最佳做法的詳細資訊，請參閱 錯誤處理和記錄。
  • 使用系統定時器做為監督者： 其中一個最重要的最佳做法是實作「裝訂定時器」回傳 (很像在無金屬 MCU) 中可用的硬體，可追蹤重要的應用程式狀態、偵測死鎖並據以執行 (例如結束和傳送遙測) 。 如需詳細資訊，請參 閱使用系統定時器做為監管。
  • 永遠不要部署已建置以 Beta 發行工具表為目標的生產應用程式： 不建議使用Beta版本工具集，因為無法保證Beta子集不會在後續作業系統版本中變更。 Beta 工具集只是為了在正式 SDK 發行之前測試新功能而發行。

處理並行性

  • 盡可能使用 EventLoop： 線程和同步處理物件 (，也就是靜音符號、架構符號等) 用來完成幾乎並行的工作，但在內嵌系統中，就系統資源使用量而言，這些成本高。 因此，若要改善效能，請考慮針對不具有時間臨界性且對共同封鎖不敏感的工作，使用ep並取代線程。 如需如何使用 EventLoop 監控和分派事件的相關信息，請參閱 Applibs eventloop.h，包括相關樣本。
  • 尋找並行工作的效率： 請務必確保封鎖作業和逾時會保持在ep保護回撥的最小值，否則所有其他ep並會影響回撥。
  • 何時使用對話 (pthread) ： 針對特定案例，例如當您無法避免封鎖來電時，使用對話會對您有所益處，但通常這些案例的存留期有限，且應限於特定工作。 例如，由於執行Linux (的 Azure 球體作業系統) 不會將 IRQ 公開到 HL 核心應用程式 (這僅適用於 RT 核心應用程式) ，使用 eppher 和 pthread 工作的組合在處理上可能是最佳方式，例如，從因特網下載數據時的下層序列通訊。

重要

Azure 球體作業系統可能會中斷及時作業，尤其是在執行裝置證明、檢查更新或上傳遙測時。 如需時間關鍵控制工作，請考慮將這些工作移至 M4 核心，並透過核心間的信箱與適當的通訊協議進行協調。 如需詳細資訊，請參閱 核心間通訊範例。

除了這些建議之外，請檢閱關於異 步事件和並行的 Azure 球體檔。

線上監控

設計完善、高階的 HL () 核心應用程式必須實作適當的 連線健康情況檢查 工作，該工作應以穩固的狀態計算機為基礎，以定期檢查因特網聯機 (狀態，例如使用 ep保護 定時器) 利用 Networking_IsNetworkingReady API。 在某些情況下，您可以使用 Networking_GetInterfaceConnectionStatus函數，因為它會提供與特定網路介面相關的聯機狀態更深入的狀態，HL 核心應用程式可以使用該功能來更佳地解決其狀態，雖然這是成本，因為它不建議每隔 90 秒更頻繁地呼叫它。

狀態電腦回撥通常應具有下列屬性：

  • 儘快執行。
  • 必須根據特定的應用程式案例和整體解決方案需求， (如常數時間、遞增延遲等) ，仔細設計輪詢區間。
  • 偵測到中斷連線後，建議您撥打 Networking_GetInterfaceConnectionStatus 一次來記錄特定網路介面的狀態，這個狀態可用來診斷問題，並透過 LED、顯示器、終端機) 等 UI (通知使用者。 此方法的樣本可在 Azure 球體 DHCP 樣本的主程式代碼中找到。
  • 啟動機制 (例如，透過全域變數) 來終止 HL 核心應用程式中執行 (或系結至) 網路通訊的所有其他工作，以優化資源使用量，直到重新建立連線為止。
  • cURL 最近更新了回撥行為和最佳行為。 雖然 Azure 球體已努力確保舊版 cURL 行為繼續如預期般運作，但建議您遵循使用curl_multi時的安全性與可靠性的最新指導方針，因為使用週期性回撥可能會導致非預期的當機、聯機中斷和潛在的安全性弱點。 如果 TimerCallback 在逾時 0ms 時發生火災，請將其視為逾時 1ms 以避免重複回撥。 請務必在curl_multi_add_handle接聽來電之後，至少curl_multi_socket_action一次明確地撥號給curl_multi_add_handle。

除了先前的建議之外，您也應該考慮下列電源管理案例：

  • 傳送數據后，關閉 Azure 球體晶片。 如需詳細數據，請參閱 管理 Azure 球體裝置的 Power Down 狀態。
  • 由於長時間指數的後退逾時可能會造成數個問題，因此追蹤總上線時間並將關機定時器設定為合理的限制，以免在因外部中斷或應用程式無法控制的其他因素而無法再連線的情況下消耗電池電力。
  • 在控制中斷期間的連線監控時，Wi-Fi 收發器可以停 wlan0 用網路介面來降低電源， (查看 Networking_SetInterfaceState ，然後等到下次再次檢查連線時，節省約 100mW。

記憶體管理和使用方式

在受記憶體限制的平臺上，經常執行記憶體配置和去配置的應用程式可能會導致操作系統記憶體管理與效率抗量，因而導致過度分散和記憶體用盡。具體來說，在 Azure 球體 MT3620 上，這可能會導致記憶體不足的條件觸發 Azure 球體 OS 的 cgroup OOM 殺手 起始。

可以理解的是，應用程式通常是從初始概念證明開始開發而來，它隨著漸進式版本所需的功能而變得更加全面，最終納入最初包含的次要功能。 下列是針對欄位中分析的許多分析案例所證明有效的建議和優化：

  • 尤其是在大量使用記憶體的 HL 核心應用程式中，透過 Azure 球體 API 追蹤應用程式記憶體使用量至關重要，詳述於 決定運行時間應用程式 RAM 使用量中所述。 一般說來，這會在ep的定時器託管中實作，而應用程式會據此回應非預期的記憶體使用量，以合理的方式重新啟動;例如，使用適當的結束代碼結束。

    許多客戶和合作夥伴發現使用 Azure 球體圖庫中發佈的 Heap Tracker 記憶體追蹤公用程式很有用。 此文件庫會以透明的方式連結至現有的 HL 核心應用程式，並追蹤記憶體配置及其相關指標，簡化偵測大多數記憶體洩漏和指標誤用的情況。

重要

此做法可以減少欄位中通常回報的裝置無回應或失敗明顯無法解析。 這類失敗通常是因為記憶體洩漏或溢位，而 HL 核心應用程式無法正確處理，並導致 OOM 殺手關閉應用程式的程式。 此外，由於連線不良，導致 Azure 球體 OS 無法傳送遙測，也可能導致潛在的欄位事件，因為只有提取 Azure 球體 OS 的診斷記錄才能偵測到診斷。

  • 在受記憶體限制的平臺上，通常建議盡可能避免動態記憶體配置，尤其是在常用的函數中。 這會大幅減少堆的記憶體分散，以及後續堆布配置失敗的可能性。 另請考慮從重複分配暫時工作緩衝區到直接存取堆疊 (，以取得合理大小) 或全域配置緩衝區的變數，這種差異會在溢出時透過) 增加大小 (realloc (請參閱 動態容器和緩衝) 。 如果需要卸載記憶體，請考慮善用 M4 核心上未使用的記憶體 (請參閱 Azure 球體) 上可用的記憶體 ，其中各有 256KiB，並提供輕量型 RT 核心應用程式來進行數據快取。 您最終可能會使用外接式 SD 記憶卡或刷新。 您可以在下列復原中找到範例：

遵循上述建議也有助於評估及保留 HL 核心應用程式在整個生命週期內以完整容量運作所需的記憶體，同時讓您更完善地預估應用程式的整體記憶體容量，以供日後的設計優化使用。 如需優化 HL 核心應用程式記憶體使用量的詳細資訊，包括 Azure 球體作業系統和 Visual Studio 中的功能，請參閱下列文章：