12/08/2018, 13:35

Optimize battery life in Android [P1]

Để phát triển một ứng dụng tốt, bạn cần quan tâm đến mức tiêu tốn pin của nó. Tối ưu thời lượng pin bằng các cách như: gộp các request network, tắt dịch vụ chạy nền (background service) khi mất kết nối, giảm cập nhật khi pin yếu... Bạn có thể đảm bảo tiết kiệm thời lượng pin sử dụng mà không làm ...

Để phát triển một ứng dụng tốt, bạn cần quan tâm đến mức tiêu tốn pin của nó. Tối ưu thời lượng pin bằng các cách như: gộp các request network, tắt dịch vụ chạy nền (background service) khi mất kết nối, giảm cập nhật khi pin yếu... Bạn có thể đảm bảo tiết kiệm thời lượng pin sử dụng mà không làm ảnh hưởng đến quá trình sử dụng của người dùng.

Lợi ích của tối ưu

Một ứng dụng tốn pin thường khiến người dùng khó chịu, hệ quả dẫn đến gỡ bỏ ứng dụng và nhận review với rate thấp. So với iOS, người dùng Android thường có thói quen vào phần quản lý pin tiêu thụ nhiều hơn và họ dễ dàng phát hiện ra ứng dụng nào tốn pin nhất. Bằng chứng là ra rả các ứng dụng giúp tiết kiệm pin trên Android được release, và đen đủi là khi người dùng bật lên thì một số ứng dụng của bạn chậm đi đáng kể như kiểu bị đơ. Do đó nếu không tối ưu tiêu thụ pin của ứng dụng để cạnh tranh với các ứng dụng khác cùng chức năng nhưng tối ưu tốt hơn, bạn có thể sẽ mất đi lượng lớn người dùng.

image42.jpg

Làm gì để tối ưu

Không giống như bộ nhớ, thời lượng pin sẽ không được IDE thông báo cho lập trình viên khi nó tốn quá, không có một luật nào giới hạn tiêu thụ pin, do đó chúng ta thường lờ đi một cách êm đẹp. Do đó bạn để có thể phát hiện ra vấn đề thì bạn để ý và thực hiện tối ưu nếu bạn thật sự là người muốn phát triển ứng dụng tốt.

Hầu hết tài liệu sẽ chỉ ra các phần chính

  • Giảm sử dụng pin của tầng mạng (Network): Học cách phân tích tầng mạng (bao gồm tài nguyên sử dụng download, upload...) để thiết kế một tầng mạng phù hợp
  • Tối ưu Doze và App Standby (Tính năng mới trên Android 6.0)
  • Kiểm soát việc cấp pin
  • Kiểm soát Docking State và Type: Tìm hiểu và kiểm soát thành phần Docking và Type nào ảnh hưởng đến ứng dụng của bạn
  • Thao tác với Broadcast Receivers theo yêu cầu: broadcast được bắn ra nhưng không phải chúng luôn được sử dụng. Tìm hiểu để nâng cao hiệu quả của broadcast.

Network activity

Tìm hiểu một chút về các trạng thái mạng hiện tại:

  • EDGE (2G) sử dụng ít năng lượng cho việc truyền 1bytes dữ liệu nhưng tốc độ thì chậm
  • Wifi: sử dụng nhiều năng lượng hơn một chút nhưng tốc độ nhanh
  • 3G: tốn nhiều năng lượng hơn wifi, tốc độ chậm hơn wifi
  • 4G: tốn hơn nhiều năng lượng hơn 3G và tuỳ vào khả năng, thường nhanh hơn Wifi

Như vậy về mặt tiêu tốn năng lượng, ta thu được kết quả 4G > 3G > Wifi > 2G.

dt-3.png

Nên bỏ chút thời gian tìm hiểu kĩ hơn về ảnh hưởng của network đến pin trên thiết bị di động, tôi khuyến khích bạn đọc thêm tài liệu sau: http://people.cs.umass.edu/~arun/papers/TailEnder.pdf

(Có hơi hàn lâm một chút, nhưng kiến thức tổng quát và hữu ích)

Best practise for network

  • Gộp các request lại với nhau:

Lấy dữ liệu: Bản chất của mỗi lần request dữ liệu phải trải qua nhiều bước: thiết lập kết nối, gửi tham số, lắng nghe phản hồi, xử lý timeout... Để tránh việc xử lý các bước dư thừa, hãy thử đọc nhiều dữ liệu nhất có thể trong mỗi request.

Trong quá trình phát triển ứng dụng chúng ta sẽ rất dễ gặp trường hợp request một ít data sau, chờ một lúc sau đó request thêm nhiều data. Ví dụ mỗi request sẽ đưa thiết bị vào trạng thái Fully Awake một thời gian để chờ phản hồi (response), trong trường hợp xấu nhất bạn sẽ đánh thức thiết bị ngay khi nó trở về trạng thái standby.

Cách tốt nhất để tránh khỏi trường hợp này là bạn phải phân biệt trường hợp nào cần xử lý ngay, trường hợp nào nào có thể để sau. Gộp các công việc liên quan đến networking nhiều nhất có thể. Do đó thiết bị của bạn sẽ chỉ phải vào trạng thái Awake 1 lần và ở trạng thái Standby lâu nhất có thể.

Còn để tránh cảm giác phải chờ đợi khá khó chịu của người dùng thì tốt nhất nên tải dữ liệu từ trước. Về việc này Google có khuyến cáo nên tải trước dữ liệu sau mỗi 2 đến 5 phút, thứ tự từ 1-5MB, dữ liệu nên gửi theo lô chứ không phải theo yêu cầu. Ví dụ: nên thu thập cả loạt data rồi gửi cùng lúc thay vì mỗi lần có cập nhật nhỏ thì lại tạo request. Hoặc lấy cả loạt data rồi hiển thị thay vì cần hiển thị gì thì request nhỏ giọt (trong trường hợp mỗi request lấy 1 ít dữ liệu)

  • Cố gắng tránh kết nối nhiều lần khi mạng đã ngắt kết nối. Hạn chế sử dụng GCM khi có thể. Hạn chế số lần thay đổi trạng thái hiển thị trên màn hình
  • Sử dụng caching tối đa nhất có thể, may mắn là hiện nay các thư viện network đều hỗ trợ tốt caching dữ liệu nên việc của bạn chỉ là bật chế độ này lên thôi.
  • Kiểm soát việc load trước dữ liệu để tránh bị dư thừa, dạng load dư liệu nhưng không được sử dụng về sau
  • Dùng fomat data thích hợp: Thông thường sử dụng JSON sẽ tiết kiệm năng lượng hơn dùng xml, dùng gson sẽ tiết kiệm năng lượng hơn dùng json parse thông thường.
  • Cân nhắc những việc có thể tiến hành khi điện thoại đang được sạc, hay khi sử dụng wifi : Điều này hẳn là quá rõ ràng rồi. Khi chúng ta tiến hành các công việc khi điện thoại đang được sạc, nó sẽ không được tính vào pin. Trừ khi có những việc bạn phải làm ngay hoặc làm trong thời gian ngắn, còn không tốt hơn hết bạn nên thực hiện nó khi chiếc điện thoại được cắm sạc.Với việc download các file có dung lượng lớn hãy tiến hành khi điện thoại có kết nối wifi, bởi thông thường wifi có tốc độ cao hơn 3G và không tính phí nữa . Một ví dụ cho trường hợp này là việc đồng bộ dữ liệu với web services như đồng bộ danh bạ hoặc đồng bộ ảnh.

Trong phần tiếp theo của bài viết, tôi sẽ trình bày phần Doze và App Standby trên Android. Còn bây giờ đến lượt bạn áp dụng những tips trên cho ứng dụng của mình.

Happy coding!

Reference

http://www.slideshare.net/littleeye/power-optimization-for-android-developers

https://developer.android.com/training/monitoring-device-state/index.html

0