排解網路問題

應用程式產生的網路流量可能會對裝置的電池續航力造成重大影響。如要最佳化這類流量，您必須進行評估並找出來源。網路要求可能直接來自使用者動作、應用程式程式碼，或與應用程式通訊的伺服器。

本主題說明如何監控及分類網路流量，並提供找出及解決問題的指引。

使用網路分析器監控要求

使用網路分析器追蹤應用程式的網路要求。您可以監控應用程式轉移資料的方式和時機，並適當調整基礎程式碼。

圖1. 追蹤網路流量。網路流量模式顯示，預先擷取要求或彙整上傳作業，可大幅提升效率。

監控資料移轉頻率和每次連線期間移轉的資料量，即可找出應用程式中可提高電池效率的部分。一般來說，您會尋找可以延遲的短暫尖峰。

為了更準確地找出傳輸量激增的原因，Traffic Stats API 可讓您使用 TrafficStats.setThreadStatsTag() 標記特定執行緒內通訊端發生的資料移轉。呼叫這個函式不會自動標記特定執行緒的所有流量，必須將標記套用至通訊端。

設定執行緒標記後，您可以使用 TrafficStats.tagSocket() 和 TrafficStats.untagSocket() 手動標記及取消標記個別通訊端。如果執行緒上開啟通訊端，或伺服器通訊端接受連線，系統也會套用標記。

多個執行緒同時存取同一個通訊端時，會使用通訊端在傳送或接收網路封包時所使用的標記 (由於緩衝和重新傳輸，這可能與使用者寫入或讀取資料時不同)。

注意： 這項技術用於標記應用程式的網路流量，取決於您使用的 API 如何存取及管理網路通訊端。部分網路程式庫可能不允許 TrafficStats 公用程式標記應用程式的流量。

舉例來說，您可以定義常數來代表不同類型的網路流量，如以下程式碼範例所示：

Kotlin

const val USER_INITIATED = 0x1000
const val APP_INITIATED = 0x2000
const val SERVER_INITIATED = 0x3000

Java

public static final int USER_INITIATED = 0x1000;
public static final int APP_INITIATED = 0x2000;
public static final int SERVER_INITIATED = 0x3000;

接著，您可以據此標記網路要求：

Kotlin

TrafficStats.setThreadStatsTag(USER_INITIATED)
TrafficStats.tagSocket(outputSocket)
// Transfer data using socket
TrafficStats.untagSocket(outputSocket)

Java

TrafficStats.setThreadStatsTag(USER_INITIATED);
TrafficStats.tagSocket(outputSocket);
// Transfer data using socket
TrafficStats.untagSocket(outputSocket);

HttpURLConnection 程式庫會根據目前的 TrafficStats.getThreadStatsTag() 值自動標記通訊端。當通訊端透過持續連線集區回收時，程式庫也會標記及取消標記通訊端，如以下程式碼範例所示：

Kotlin

class IdentifyTransferSpikeTask {
    @WorkerThread
    fun request(url: String) {
        TrafficStats.setThreadStatsTag(APP_INITIATED)
        // Make network request using HttpURLConnection.connect()
        ...
        TrafficStats.clearThreadStatsTag()
    }
}

Java

public class IdentifyTransferSpikeTask {
    @WorkerThread
    public void request(String url) {
        TrafficStats.setThreadStatsTag(APP_INITIATED);
        // Make network request using HttpURLConnection.connect()
        ...
        TrafficStats.clearThreadStatsTag();
    }
}

注意： 執行效能測試時，APK 應盡可能接近正式版本。為此，您可能需要建立新的可偵錯建構類型，與偵錯建構類型分開。如要進一步瞭解如何建立建構類型，請參閱「設定建構類型」。

分析網路流量類型

查看應用程式產生的網路流量時，您需先瞭解流量來源，才能據此進行最佳化。如果應用程式確實會回應使用者的操作，那麼其所產生的頻繁網路活動可能就完全不是問題；但如果應用程式不在前景之中，或使用者只是將裝置放在口袋或皮包中，這樣就完全不適合。

分析使用者導致的流量

使用者在應用程式中執行特定工作時，系統可能會有效率地將使用者啟動的網路流量歸納分組；如果使用者要求應用程式必須取得的額外資訊，網路流量就會不平均分散。之所以要分析使用者導致的網路流量，目的是找出長期頻繁使用網路的模式，並嘗試將要求分組歸類，以降低使用頻率。

由於使用者要求難以預測，要在應用程式中最佳化這類網路使用行為並不容易。此外，使用者的期望是使用應用程式時能快速獲得回應，所以如果您為了提高效率而延後處理他們的要求，可能會導致使用者體驗不佳。一般來說，當使用者與應用程式直接互動時，您應先快速回應使用者需求，第二順位才是提高網路使用效率。

如需最佳化使用者發起流量的建議，請參閱「最佳化使用者發起的請求」。

注意： 請特別留意使用者活動測試資料中的網路活動分組偏誤。如果您是透過網路測試方案執行模擬使用，那麼使用者啟動的網路存取圖表可能就不會和真實情況一樣進行分組歸類，而這可能導致您最佳化的並非實際發生的使用者行為。請確保您的使用者網路測試能確實反映應用程式的真實使用情況。

分析應用程式發起的流量

應用程式啟動的網路流量通常是您可以大幅影響網路頻寬使用效益的區域。分析應用程式的網路活動時，請尋找無活動的時段，然後判斷這些時段是否可以增加。如果發現應用程式存取網路時的模式一致，請嘗試批次處理這類流量，讓裝置無線電能夠在活動期間切換回低耗電模式。

如需最佳化應用程式啟動流量的建議，請參閱「最佳化應用程式啟動的要求」。

分析伺服器導致的流量

伺服器與應用程式通訊而啟動的網路活動，通常也是可以大幅影響網路頻寬使用效益的區域。Firebase 雲端通訊 (FCM) 是一種輕量機制，可從伺服器傳送資料至特定應用程式執行個體。使用 FCM，伺服器可以通知在特定裝置上執行的應用程式，有新資料可用。

如需最佳化伺服器啟動流量的建議，請參閱「最佳化伺服器啟動的要求」。

使用 Battery Historian 視覺化呈現網路流量影響

Battery Historian 是一種工具，可將裝置在一段時間內的電池消耗情形視覺化。您可以使用這項工具，分析網路活動對電池消耗的影響。舉例來說，Battery Historian 可以顯示應用程式使用手機無線電的頻率是否高於預期。如要進一步瞭解如何使用 Battery Historian，請參閱「使用 Batterystats 和 Battery Historian 剖析電池用量」。