共用方式為


活動協調器 API 和術語

若要瞭解活動協調器 API,請務必熟悉 API 所使用的詞彙。

活動協調器 API 會協調在系統上執行可延遲的工作,稱為活動。 開發人員可以使用 API,根據所需的系統狀態,取得何時啟動或停止活動的通知。 此狀態是由原則所定義,其描述執行活動時系統資源的最佳狀況。 開發人員訂閱這些原則,以將通知傳送至提供的回呼,用來協調其活動的執行。

注意

這些通知是協調低優先順序或資源密集型工作,這些工作可以延遲到稍後。 如果不論系統狀況為何,都需要執行高優先順序的工作,則不應該依賴此 API。

API 特定術語

資源

資源是被取用或受活動影響之系統的實體元件或屬性。 簡單的範例是傳統系統資源,例如CPU、系統磁碟和 GPU。 較不傳統的資源包括電源和用戶閑置等專案。

Condition

條件是資源所需狀態的質化描述,可能是 良好中等未設定。 在基本層級,良好的條件表示是使用資源的好時機。 您可以使用各種維度來評估指定的資源條件組。

開發人員必須選擇要用於個別資源的條件,使其符合其工作負載的需求。 這可讓 API 在其取用者之間最佳協調工作。

可延遲

可延遲的工作 是那些不會立即影響應用程式用戶體驗的工作,不過長時間的執行不足仍會影響整體體驗。 一般而言,這些工作不需要立即執行,而且可以將執行延遲到系統處於理想狀態的時間。 執行工作時,這些時間不會干擾用戶體驗或系統效能。 這類工作可能包括:

  • 重新編製媒體目錄的索引
  • 定型或更新建議模型
  • 安裝外掛程式更新

活動

活動開發人員所定義的可延遲工作單位。 活動原本會耗用系統資源來執行,這可能會對用戶體驗造成影響。 開發人員必須瞭解其活動如何使用這些資源,以便適當地使用 API。 然後,他們可以使用 API 將活動執行延遲到更理想的時間,而不是立即執行這類工作,這可能會影響用戶體驗。

原則

原則會 藉由描述執行或受開發人員活動影響所需的各種資源所需條件,來定義運行時間的理想時間 。 原則是由數對資源和條件所組成,定義個別 資源條件

原則可能會指定 Power、記憶體和 CPU 等資源的條件,但也會根據其相關性排除 GPU 等資源。 當符合並關閉所有資源條件時,就會將原則視為開啟。 原則不會描述活動預期會耗用多少特定資源。 API 會使用原則設定,在 API 取用者之間做出協調決策。

設定原則時,建議開發人員從每個資源的最佳(良好)條件開始,如此一來,當執行最可能影響用戶體驗或系統效能時,API 可協助它們在最佳時間執行。 如果活動未收到通知,以達到開發人員的需求,則條件可能會降低(例如,從 良好中等)。

訂用帳戶

訂用帳戶是活動的協調機制。 開發人員使用回呼來訂閱原則,API 會使用協調通知呼叫此原則。 這些通知會通知開發人員何時應該啟動/繼續或停止/暫停其活動。 通知是以訂閱原則的資源條件為基礎,如訂用帳戶時所設定,以及 API 所做的協調決策。

原則範本

列舉 ACTIVITY_COORDINATOR_POLICY_TEMPLATE的成員。 建立原則以預先設定原則時,可以使用這些原則,以符合大部分活動的常見需求,並將對使用者的影響降到最低。

降級

您可以將 原則或資源從較佳變更為較小條件來降級 ,使其更寬鬆,並增加滿足原則條件的可能性。 例如,您可以將 CPU 條件變更為中等條件,以降級 CPU 的良好條件。 中等條件具有較不嚴格的需求,因此更有可能符合。 在原則層級,這會增加原則開啟的可能性(所有資源條件都已滿足)的頻率和較長的時間,請記住,這些可能是造成使用者影響或降低系統效能的可能性更大的時候。

可執行的動作

API 可讓開發人員執行下列動作:

  • 設定原則。
  • 訂閱/取消訂閱原則的通知。

API 提供自定義原則以最符合開發人員案例的彈性,從空的原則設定或其中一個以大部分應用程式需求為目標的範本組態開始。 最簡單的情況是:

  • 在 ACTIVITY_COORDINATOR_POLICY_TEMPLATE 內,使用範本原則標識碼來配置原則。

如需更自定義的開發人員案例,

  • 配置範本原則(可能是空的範本原則)。
  • 設定相關資源所需的條件。

活動協調器 API 概觀

選擇正確的活動協調器原則

活動協調器範例專案