在下列情況下，設定檔要求可能不會立即完成或提供結果：
- 頻率限制：系統會限制收集頻率，以保護裝置效能 (請參閱「頻率限制的運作方式」)。
在傳送前終止應用程式：如果應用程式在擷取期間關閉或停止運作，系統會停止並在背景儲存設定檔，並在下次應用程式執行 (在前景或背景) 並註冊全域事件監聽器時傳送佇列結果。系統會保留未傳送的佇列結果最多 7 天，等待事件監聽器註冊；如果應用程式未在 7 天內註冊事件監聽器，佇列結果就會遭到捨棄。
其他錯誤：如果收集失敗 (例如因要求無效或內部錯誤)，
ProfilingResult會回報錯誤代碼和訊息。
頻率限制的運作方式
由於擷取設定檔會耗用大量資源，ProfilingManager 會在程序層級和系統層級強制執行頻率限制，以保護裝置效能和電池續航力。不同設定檔類型會產生不同的資源費用，系統會以兩個層級追蹤滾動時間範圍內的配額：
- 程序頻率限制：追蹤個別應用程式收集的設定檔資源成本，並與每個應用程式的配額進行比較。每個應用程式都會獲得相同的配額，且裝置上其他應用程式的分析活動不會影響應用程式的限制。如果應用程式在任何時間範圍內達到配額，要求就會失敗，並傳回
ERROR_FAILED_RATE_LIMIT_PROCESS。 - 系統頻率限制：追蹤裝置上所有應用程式收集的設定檔資源成本總和，並與共用的全域配額進行比較。由於所有應用程式都會計入這項裝置層級限制，因此即使應用程式尚未用盡自己的程序配額，要求仍可能失敗並傳回
ERROR_FAILED_RATE_LIMIT_SYSTEM。
管理實際工作環境中的設定檔數量
由於裝置層級的頻率限制取決於設定檔類型和整體系統活動，因此請勿嘗試在應用程式中追蹤或預測確切的本機頻率限制配額。請改為在相關使用者歷程或異常狀況發生時，專注於提出剖析要求，並讓 ProfilingManager 處理裝置端節流。
如要盡可能擴大涵蓋範圍，同時控制上傳頻寬和儲存空間成本，請使用使用者區隔和實驗平台 (例如遠端設定或 A/B 測試旗標) 控制整體設定檔數量：
- 對使用者族群進行抽樣：為一小部分隨機的使用者工作階段啟用剖析功能，而不是在每次執行時都要求所有使用者提供設定檔。
- 依同類群組區隔：指定特定應用程式版本、裝置層級、OS 版本或區域，調查迴歸問題 (例如，在 OOM 率偏高的低 RAM 裝置上啟用 Java 記憶體快照資料收集功能)。
- 跨使用者區隔觸發條件和直接要求：將不同的剖析觸發條件和直接剖析要求指派給不同的使用者區隔，讓部分使用者記錄一個設定檔，其他使用者則記錄另一個設定檔。由於裝置上的所有擷取作業都會共用相同的應用程式配額，因此在使用者區隔之間隔離擷取作業，可避免高頻率觸發條件或要求耗盡單一裝置上低頻率擷取作業所需的配額。