排解網路問題

應用程式產生的網路流量可能會大幅影響裝置的電池續航力。如要盡量爭取這類流量，您必須評估流量並找出來源。網路要求可能直接來自使用者動作、您自己的應用程式程式碼，或是與應用程式通訊的伺服器。

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

使用網路分析器監控要求

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

圖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() 值，自動標記插座。透過 Keep-Alive 集區回收插座時，程式庫也會標記及取消標記插座，如下列程式碼範例所示：

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 剖析電池用量」。