Các yêu cầu mà ứng dụng gửi đến mạng là nguyên nhân chính gây tiêu hao pin vì những yêu cầu này sẽ bật đài di động hoặc Wi-Fi tiêu thụ điện năng. Ngoài năng lượng cần thiết để gửi và nhận các gói, những đài phát này tiêu tốn thêm năng lượng chỉ để bật và duy trì trạng thái thức. Một thực tế đơn giản như yêu cầu mạng 15 giây một lần có thể giúp đài phát trên thiết bị di động luôn bật liên tục và nhanh chóng làm hết pin.
Có ba loại bản cập nhật định kỳ chung:
- Do người dùng khởi tạo. Thực hiện cập nhật dựa trên một số hành vi của người dùng, chẳng hạn như cử chỉ kéo để làm mới.
- Do ứng dụng khởi tạo. Cập nhật định kỳ.
- Do máy chủ khởi tạo. Thực hiện cập nhật để phản hồi thông báo từ máy chủ.
Chủ đề này xem xét từng yếu tố và thảo luận thêm về những cách tối ưu hoá để giảm hiện tượng tiêu hao pin.
Tối ưu hoá các yêu cầu do người dùng đưa ra
Yêu cầu do người dùng đưa ra thường xảy ra để phản hồi một số hành vi của người dùng. Ví dụ: một ứng dụng dùng để đọc các tin bài mới nhất có thể cho phép người dùng thực hiện cử chỉ kéo để làm mới để kiểm tra các bài viết mới. Bạn có thể sử dụng các kỹ thuật sau để phản hồi các yêu cầu của người dùng trong khi tối ưu hoá việc sử dụng mạng.
Chặn yêu cầu của người dùng
Bạn nên bỏ qua một số yêu cầu do người dùng đưa ra nếu không cần thiết, chẳng hạn như nhiều cử chỉ kéo để làm mới trong một khoảng thời gian ngắn để kiểm tra dữ liệu mới trong khi dữ liệu hiện tại vẫn mới. Việc thực hiện theo từng yêu cầu có thể làm lãng phí một lượng pin đáng kể do luôn bật đài. Một phương pháp hiệu quả hơn là điều tiết các yêu cầu do người dùng đưa ra để chỉ có thể thực hiện một yêu cầu trong một khoảng thời gian, giúp giảm tần suất sử dụng đài.
Sử dụng bộ nhớ đệm
Bằng cách lưu dữ liệu của ứng dụng vào bộ nhớ đệm, bạn đang tạo một bản sao cục bộ của thông tin mà ứng dụng cần tham chiếu. Sau đó, ứng dụng của bạn có thể truy cập vào cùng một bản sao thông tin cục bộ nhiều lần mà không cần phải mở kết nối mạng để đưa ra yêu cầu mới.
Bạn nên lưu dữ liệu vào bộ nhớ đệm ở mức tối đa, bao gồm cả các tài nguyên tĩnh và nội dung tải xuống theo yêu cầu, chẳng hạn như hình ảnh có kích thước đầy đủ. Bạn có thể dùng các tiêu đề bộ nhớ đệm HTTP để đảm bảo rằng chiến lược lưu vào bộ nhớ đệm của bạn không làm cho ứng dụng hiển thị dữ liệu cũ. Để biết thêm thông tin về việc lưu phản hồi của mạng vào bộ nhớ đệm, hãy xem phần Tránh tải xuống quá nhiều.
Trên Android 11 trở lên, ứng dụng của bạn có thể dùng chính tập dữ liệu lớn mà các ứng dụng khác dùng cho các trường hợp sử dụng như học máy và phát nội dung đa phương tiện. Khi cần truy cập vào tập dữ liệu dùng chung, trước tiên, ứng dụng của bạn có thể kiểm tra phiên bản đã lưu vào bộ nhớ đệm trước khi tìm cách tải bản sao mới xuống. Để tìm hiểu thêm về tập dữ liệu dùng chung, hãy xem phần Truy cập vào tập dữ liệu dùng chung.
Sử dụng băng thông lớn hơn để giảm tải xuống dữ liệu nhiều hơn thường xuyên hơn
Khi được kết nối qua đài không dây, băng thông cao hơn thường đi kèm với chi phí pin cao hơn, nghĩa là 5G thường tiêu thụ nhiều năng lượng hơn LTE, vốn đắt hơn so với 3G.
Tức là mặc dù trạng thái vô tuyến cơ bản thay đổi tuỳ theo công nghệ vô tuyến, nhưng nhìn chung, tác động tương đối của thời lượng pin đối với thời gian đuôi thay đổi trạng thái sẽ lớn hơn đối với các đài có băng thông cao hơn. Để biết thêm thông tin về thời gian chờ, vui lòng xem phần Máy trạng thái vô tuyến.
Đồng thời, băng thông càng cao, bạn có thể tìm nạp trước linh hoạt hơn, tải nhiều dữ liệu hơn xuống cùng một lúc. Có lẽ không mấy dễ hiểu, vì chi phí pin theo thời gian đuôi tương đối cao hơn, nên việc duy trì đài phát trong thời gian dài hơn trong mỗi phiên chuyển để giảm tần suất cập nhật cũng hiệu quả hơn.
Ví dụ: nếu một đài LTE có băng thông cao gấp đôi và chi phí năng lượng của 3G gấp đôi, thì bạn nên tải dữ liệu xuống gấp bốn lần trong mỗi phiên — hoặc có thể lên tới 10 MB. Khi tải nhiều dữ liệu này xuống, bạn phải xem xét ảnh hưởng của hoạt động tìm nạp trước đến bộ nhớ cục bộ còn trống và thường xuyên xoá bộ nhớ đệm tìm nạp trước.
Bạn có thể sử dụng ConnectivityManager để đăng ký trình nghe cho mạng mặc định và TelephonyManager để đăng ký PhoneStateListener nhằm xác định loại kết nối thiết bị hiện tại. Sau khi xác định loại kết nối, bạn có thể sửa đổi các quy trình tìm nạp trước cho phù hợp:
Kotlin
val cm = getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
val tm = getSystemService(Context.TELEPHONY_SERVICE) as TelephonyManager
private var hasWifi = false
private var hasCellular = false
private var cellModifier: Float = 1f
private val networkCallback = object : ConnectivityManager.NetworkCallback() {
// Network capabilities have changed for the network
override fun onCapabilitiesChanged(
network: Network,
networkCapabilities: NetworkCapabilities
) {
super.onCapabilitiesChanged(network, networkCapabilities)
hasCellular = networkCapabilities
.hasTransport(NetworkCapabilities.TRANSPORT_CELLULAR)
hasWifi = networkCapabilities
.hasTransport(NetworkCapabilities.TRANSPORT_WIFI)
}
}
private val phoneStateListener = object : PhoneStateListener() {
override fun onPreciseDataConnectionStateChanged(
dataConnectionState: PreciseDataConnectionState
) {
cellModifier = when (dataConnectionState.networkType) {
TelephonyManager.NETWORK_TYPE_LTE or TelephonyManager.NETWORK_TYPE_HSPAP -> 4f
TelephonyManager.NETWORK_TYPE_EDGE or TelephonyManager.NETWORK_TYPE_GPRS -> 1/2f
else -> 1f
}
}
private class NetworkState {
private var defaultNetwork: Network? = null
private var defaultCapabilities: NetworkCapabilities? = null
fun setDefaultNetwork(network: Network?, caps: NetworkCapabilities?) = synchronized(this) {
defaultNetwork = network
defaultCapabilities = caps
}
val isDefaultNetworkWifi
get() = synchronized(this) {
defaultCapabilities?.hasTransport(TRANSPORT_WIFI) ?: false
}
val isDefaultNetworkCellular
get() = synchronized(this) {
defaultCapabilities?.hasTransport(TRANSPORT_CELLULAR) ?: false
}
val isDefaultNetworkUnmetered
get() = synchronized(this) {
defaultCapabilities?.hasCapability(NET_CAPABILITY_NOT_METERED) ?: false
}
var cellNetworkType: Int = TelephonyManager.NETWORK_TYPE_UNKNOWN
get() = synchronized(this) { field }
set(t) = synchronized(this) { field = t }
private val cellModifier: Float
get() = synchronized(this) {
when (cellNetworkType) {
TelephonyManager.NETWORK_TYPE_LTE or TelephonyManager.NETWORK_TYPE_HSPAP -> 4f
TelephonyManager.NETWORK_TYPE_EDGE or TelephonyManager.NETWORK_TYPE_GPRS -> 1 / 2f
else -> 1f
}
}
val prefetchCacheSize: Int
get() = when {
isDefaultNetworkWifi -> MAX_PREFETCH_CACHE
isDefaultNetworkCellular -> (DEFAULT_PREFETCH_CACHE * cellModifier).toInt()
else -> DEFAULT_PREFETCH_CACHE
}
}
private val networkState = NetworkState()
private val networkCallback = object : ConnectivityManager.NetworkCallback() {
// Network capabilities have changed for the network
override fun onCapabilitiesChanged(
network: Network,
networkCapabilities: NetworkCapabilities
) {
networkState.setDefaultNetwork(network, networkCapabilities)
}
override fun onLost(network: Network?) {
networkState.setDefaultNetwork(null, null)
}
}
private val telephonyCallback = object : TelephonyCallback(), TelephonyCallback.PreciseDataConnectionStateListener {
override fun onPreciseDataConnectionStateChanged(dataConnectionState: PreciseDataConnectionState) {
networkState.cellNetworkType = dataConnectionState.networkType
}
}
connectivityManager.registerDefaultNetworkCallback(networkCallback)
telephonyManager.registerTelephonyCallback(telephonyCallback)
private val prefetchCacheSize: Int
get() {
return when {
hasWifi -> MAX_PREFETCH_CACHE
hasCellular -> (DEFAULT_PREFETCH_CACHE * cellModifier).toInt()
else -> DEFAULT_PREFETCH_CACHE
}
}
}
Java
ConnectivityManager cm =
(ConnectivityManager) getSystemService(Context.CONNECTIVITY_SERVICE);
TelephonyManager tm =
(TelephonyManager) getSystemService(Context.TELEPHONY_SERVICE);
private boolean hasWifi = false;
private boolean hasCellular = false;
private float cellModifier = 1f;
private ConnectivityManager.NetworkCallback networkCallback = new ConnectivityManager.NetworkCallback() {
@Override
public void onCapabilitiesChanged(
@NonNull Network network,
@NonNull NetworkCapabilities networkCapabilities
) {
super.onCapabilitiesChanged(network, networkCapabilities);
hasCellular = networkCapabilities
.hasTransport(NetworkCapabilities.TRANSPORT_CELLULAR);
hasWifi = networkCapabilities
.hasTransport(NetworkCapabilities.TRANSPORT_WIFI);
}
};
private PhoneStateListener phoneStateListener = new PhoneStateListener() {
@Override
public void onPreciseDataConnectionStateChanged(
@NonNull PreciseDataConnectionState dataConnectionState
) {
switch (dataConnectionState.getNetworkType()) {
case (TelephonyManager.NETWORK_TYPE_LTE |
TelephonyManager.NETWORK_TYPE_HSPAP):
cellModifier = 4;
Break;
case (TelephonyManager.NETWORK_TYPE_EDGE |
TelephonyManager.NETWORK_TYPE_GPRS):
cellModifier = 1/2.0f;
Break;
default:
cellModifier = 1;
Break;
}
}
};
cm.registerDefaultNetworkCallback(networkCallback);
tm.listen(
phoneStateListener,
PhoneStateListener.LISTEN_PRECISE_DATA_CONNECTION_STATE
);
public int getPrefetchCacheSize() {
if (hasWifi) {
return MAX_PREFETCH_SIZE;
}
if (hasCellular) {
return (int) (DEFAULT_PREFETCH_SIZE * cellModifier);
}
return DEFAULT_PREFETCH_SIZE;
}
Tối ưu hoá yêu cầu do ứng dụng khởi tạo
Các yêu cầu do ứng dụng khởi tạo thường diễn ra theo lịch biểu, chẳng hạn như một ứng dụng gửi nhật ký hoặc số liệu phân tích đến một dịch vụ phụ trợ. Khi xử lý các yêu cầu do ứng dụng đưa ra, hãy cân nhắc mức độ ưu tiên của các yêu cầu đó, liệu các yêu cầu đó có thể được phân theo lô cùng nhau hay không, và liệu có thể trì hoãn các yêu cầu đó cho đến khi thiết bị sạc hoặc kết nối với một mạng không đo lượng dữ liệu hay không. Bạn có thể tối ưu hoá các yêu cầu này bằng cách lên lịch cẩn thận và bằng cách sử dụng các thư viện như WorkManager.
Yêu cầu mạng theo lô
Trên thiết bị di động, quá trình bật đài, kết nối và giữ đài phát ở trạng thái bật sẽ tốn một lượng lớn pin. Vì lý do này, việc xử lý từng yêu cầu vào các thời điểm ngẫu nhiên có thể tiêu thụ đáng kể pin và giảm thời lượng pin. Một phương pháp hiệu quả hơn là xếp một tập hợp các yêu cầu mạng vào hàng đợi và xử lý chúng cùng nhau. Điều này cho phép hệ thống thanh toán chi phí năng lượng của việc bật đài chỉ một lần và vẫn nhận được tất cả dữ liệu mà một ứng dụng yêu cầu.
Sử dụng WorkManager
Bạn có thể sử dụng thư viện WorkManager để thực hiện công việc theo một lịch biểu hiệu quả xem xét liệu các điều kiện cụ thể có được đáp ứng hay không, chẳng hạn như khả năng sử dụng mạng và trạng thái nguồn. Ví dụ: giả sử bạn có một lớp con Worker tên là DownloadHeadlinesWorker để truy xuất các tiêu đề tin tức mới nhất. Trình chạy này có thể được lên lịch để chạy mỗi giờ, miễn là thiết bị được kết nối với một mạng không đo lượng dữ liệu và pin của thiết bị vẫn còn nhiều, bằng chiến lược thử lại tuỳ chỉnh nếu có bất kỳ sự cố nào khi truy xuất dữ liệu, như thể hiện dưới đây:
Kotlin
val constraints = Constraints.Builder()
.setRequiredNetworkType(NetworkType.UNMETERED)
.setRequiresBatteryNotLow(true)
.build()
val request =
PeriodicWorkRequestBuilder<DownloadHeadlinesWorker>(1, TimeUnit.HOURS)
.setConstraints(constraints)
.setBackoffCriteria(BackoffPolicy.LINEAR, 1L, TimeUnit.MINUTES)
.build()
WorkManager.getInstance(context).enqueue(request)
Java
Constraints constraints = new Constraints.Builder()
.setRequiredNetworkType(NetworkType.UNMETERED)
.setRequiresBatteryNotLow(true)
.build();
WorkRequest request = new PeriodicWorkRequest.Builder(DownloadHeadlinesWorker.class, 1, TimeUnit.HOURS)
.setBackoffCriteria(BackoffPolicy.LINEAR, 1L, TimeUnit.MINUTES)
.build();
WorkManager.getInstance(this).enqueue(request);
Ngoài WorkManager, nền tảng Android còn cung cấp một số công cụ khác giúp bạn tạo lịch biểu hiệu quả để hoàn thành các tác vụ nối mạng, chẳng hạn như thăm dò ý kiến. Để tìm hiểu thêm về cách sử dụng các công cụ này, hãy xem Hướng dẫn xử lý nền.
Tối ưu hoá các yêu cầu do máy chủ khởi tạo
Yêu cầu do máy chủ khởi tạo thường xảy ra để phản hồi thông báo của máy chủ. Ví dụ: một ứng dụng dùng để đọc các tin bài mới nhất có thể nhận được thông báo về một loạt bài viết mới phù hợp với lựa chọn cá nhân hoá ưu tiên của người dùng mà sau đó ứng dụng sẽ tải xuống.
Gửi bản cập nhật máy chủ bằng Giải pháp gửi thông báo qua đám mây của Firebase
Gửi thông báo qua đám mây của Firebase (FCM) là một cơ chế gọn nhẹ dùng để truyền dữ liệu từ máy chủ đến một thực thể ứng dụng cụ thể. Khi sử dụng FCM, máy chủ có thể thông báo cho ứng dụng đang chạy trên một thiết bị cụ thể rằng có dữ liệu mới dành cho thiết bị đó.
So với thăm dò ý kiến, trong đó ứng dụng phải thường xuyên ping máy chủ để truy vấn dữ liệu mới, mô hình dựa trên sự kiện này cho phép ứng dụng chỉ tạo kết nối mới khi biết có dữ liệu cần tải xuống. Mô hình này giảm thiểu các kết nối không cần thiết và giảm độ trễ khi cập nhật thông tin trong ứng dụng của bạn.
FCM được triển khai bằng kết nối TCP/IP liên tục. Điều này giúp giảm thiểu số lượng kết nối liên tục và cho phép nền tảng tối ưu hoá băng thông cũng như giảm thiểu tác động liên quan đến thời lượng pin.