開發生產就緒應用程式的建議
當您為 Azure 球體裝置開發應用程式時，有幾個事項需要考慮，以確保您的應用程式已準備就緒。 本主題包含最佳做法檢查清單，以確認您的應用程式已準備好進行試驗或生產部署。 確認這些專案是否完成，可以減少您在生產中遇到的問題數量，並讓您更容易診斷出現的任何問題。
當您開發 Azure 球體應用程式時，請決定是否要在 高階 (HL) 、 即時 (RT) 核心或兩者混合式上執行。 高階應用程式會在 Azure 球體作業系統上執行容器化，而支援 RTApps 的即時應用程式 (RTApps) 在金屬上執行，或在即時核心上使用即時操作系統 (RTOS) 。
此處提供的建議旨在協助您提高生產就緒應用程式的質量和生產力。 下列檢查清單提供這兩種應用程式類型的設計建議簡潔清單，以及建議的程式代碼基礎和解決方案設計考慮，包括討論各點之主題的連結。。 這些建議衍生自我們與客戶的合作關係，包括現場分析、程式代碼檢閱，以及支援實際解決方案和裝置設計中生產部署應用程式的互動。
常見問題
- 確定生產就緒的應用程式不會使用 Beta 工具組。
- 以 API 集為目標時，請使用最新的 CMake 和 Azure 球體工具。
- 若要確保完整程式代碼優化和大小，請考慮先在發行模式中編譯最終映像套件，然後再將應用程式部署到生產階段。 請務必先建置及測試發行套件，再進行部署。
- 執行完整組建時，請使用零警告原則，以確保系統刻意解決編譯者警告的問題。
- 設定一致的 CI/CD 管線，並使用適當的分支策略。
記憶體相關問題
- 盡可能將所有常用的固定字串定義為
global const char*非硬編碼，以便用來做為數據指標。 - 如果全域數據結構相當小，請考慮為陣列成員提供固定的長度，而不是使用指標來動態配置的記憶體。
- 盡可能避免動態記憶體配置。
- 對於將指標傳回記憶體緩衝區的函數，請考慮轉換為會傳回參照緩衝指標及其對來電者之相關大小的函數。
- 盡可能將所有常用的固定字串定義為
動態容器和緩衝區
- 考慮針對清單和向量等容器使用增量配置方法。
一般基本概念
- 在結束或錯誤時正確初始化並銷毀所有處理程式。
- 一律使用結束代碼。
- 如果應用程式偵測到它處於無法回復的狀態，且需要重新啟動，請確定它一律以「乾淨」的應用程式結束方式處理，而不會造成死鎖狀態的風險。
- 實作錯誤處理和記錄。 如需詳細資訊，請參閱 錯誤處理和記錄。
- 使用系統定時器做為預設值來偵測應用程式是否處於無法回復的狀態或停滯 (例如死鎖、記憶體疲累或連線無法復原，但實作邏輯) ，並影響適當的復原。 如需詳細資訊，請參 閱使用系統定時器做為監管。
處理並行性
- 盡可能使用 EventLoop。
- 尋找並行工作的效率。
- 評估何時只對特定工作使用對話和範圍。 如需有關何時使用對話的詳細資訊，請參閱處理並行。
線上監控
- 根據定期檢查因特網聯機狀態的強固狀態計算機，實作適當的聯機健康情況檢查工作。
- 如需需要電源管理的解決方案，請在傳送數據后關閉 Azure 球體晶片、追蹤總時數，並設定關機定時器。
- cURL 最近更新了回撥行為和最佳行為。 雖然 Azure 球體已努力確保舊版 cURL 行為繼續如預期般運作，但建議您遵循使用curl_multi時的安全性與可靠性的最新指導方針，因為使用週期性回撥可能會導致非預期的當機、聯機中斷和潛在的安全性弱點。 如果 TimerCallback 在逾時 0ms 時發生火災，請將其視為逾時 1ms 以避免重複回撥。 請務必在curl_multi_add_handle接聽來電之後，至少curl_multi_socket_action一次明確地撥號給curl_multi_add_handle。
記憶體管理和使用方式
- 使用 Azure 球體 OS API 追蹤應用程式記憶體使用量，並確保應用程式對非預期的記憶體使用做出適當反應。
- 啟用 MT3620 接收定時器來偵測死鎖並實作適當的復原邏輯。
- 針對混合式 HL 核心和 RT 核心應用程式實作核心間通訊。
線上能力需求與疑難解答
- 確定符合所有網路先決條件。 如需詳細資訊，請參閱 連線需求和疑難解答。
- 使用和疑難解答連線問題
OSNetworkRequirementCheck-HLApp。OSNetworkRequirementChecker-PC
建議的內容
若要在將IoT解決方案移至生產環境時考慮其他專案，請參閱將IoT解決方案從測試移到生產。