Theo đó, tính năng Adaptive Battery sẽ chỉ cho phép các ứng dụng bạn sử dụng được truy xuất dưới nền hệ thống, tính năng Auto Brightness mới giúp điều chỉnh độ sáng màn hình tối ưu hơn, và nhóm phát triển Android còn thực hiện nhiều thay đổi trong cách thức hoạt động trên CPU của các ứng dụng chạy nền. Tất cả các tính năng này hứa hẹn sẽ mang lại thời lượng pin tốt hơn cho người dùng Android.
Để biết thêm nhiều thông tin chi tiết, hãy cùng trò chuyện với bộ đôi kỹ sư Android: Benjamin Poiesz, quản lý sản phẩm đối với Android Framework, và Tim Murray, kỹ sư Android cao cấp. Trong cuộc trò chuyện này, chúng ta còn được biết thêm một ít thông tin tổng quát liên quan Android P và những thông tin chi tiết về việc Google đã làm cách nào để chuẩn đoán và theo dõi thời lượng pin trên một loạt các thiết bị được cài đặt hệ điều hành này.
Chọn đúng nhân CPU để thực hiện công việc phù hợp
Mở đầu cuộc nói chuyện, Poiesz và Murray nói về CPU Affinity. Các CPU đa nhân ngày nay đã trở nên rất phổ biến, và trong khi trên desktop, các lõi trên CPU có kích cỡ y hết nhau, thì trên điện thoại di động, các lõi này lại có kích cỡ khác biệt, được dành để xử lý các công việc khác nhau. Trên một CPU ARM 8 nhân thông thường, bạn sẽ có một con chip với kiến trúc big.LITTLE. Với kiến trúc này, 4 nhân “lớn” (big) nhanh và tốn năng lượng hơn, còn 4 nhân “nhỏ” (little) chậm hơn nhưng lại tiết kiệm năng lượng hơn. Việc một ứng dụng chạy trên nhân lớn hay nhỏ có thể ảnh hưởng lớn đến mức điện năng nó tiêu thụ và tốc độ hoạt động của nó. Chỉ định một tiến trình cho một CPU hay một nhân cụ thể gọi là thiết lập CPU Affinity.
Android P sẽ thay đổi cách mà CPU Affinity (Core Affinity) hoạt động đối với các tiến trình chạy nền, nhờ đó tiết kiệm một lượng đáng kể năng lượng.
Tim Murray: Chúng tôi đã tìm cách để Core Affinity hoạt động đối với nền tảng big.LITTLE từ năm 2015. Hồi tháng 3/2015, tôi có đọc được một bài báo về chiếc HTC One M9, chiếc điện thoại đầu tiên chạy chip Snapdragon 810. Lúc đó tôi đang nghiên cứu một số thứ liên quan hiệu năng thiết bị trên Android nói chung, và tôi biết chiếc Nexus 6P mà chúng tôi (Google) dự định ra mắt trong năm đó sẽ sử dụng Snapdragon 810. Bài báo có nói rằng Snapdragon 810 rất nóng. Và tôi nghĩ “liệu chúng tôi có thể làm tốt hơn không”. Vậy là tôi bắt đầu nghĩ về nó và bắt tay vào việc cùng mọi người trong nhóm phát triển kernel và nhóm framework. Chúng tôi đã tìm ra một phương thức để điều khiển affinity của các dịch vụ và các tiến trình cụ thể từ ActivityManager.
Trên Android, một “Activity” là một màn hình đơn lẻ của một ứng dụng, ví dụ, inbox của ứng dụng email, do đó dịch vụ hệ thống “ActivityManager” thực hiện công việc đúng như tên gọi của nó: quản lý các hoạt động (activity) và các dịch vụ chạy nền – mở và đóng chúng khi được yêu cầu hay khi cần thiết để đảm bảo đủ bộ nhớ sử dụng cho máy.
Murray: Từ dịch vụ quản lý hoạt động, chúng tôi đã theo dõi xem điều gì quan trọng đối với người dùng. Bạn có thể nghĩ về dịch vụ này như một loại macro-scheduler. Trong khi kernel scheduler thực hiện các quyết định trong vài mili giây hoặc micro giây, dịch vụ activity manager sẽ theo dõi những loại tương tác vĩ mô đó, như dịch vụ gì đang chạy chẳng hạn. Ứng dụng nào hiện đang chạy trên nền (foreground)? Người dùng thực sự nhận thấy điều gì? Ví dụ, nếu bạn đang chạy ứng dụng điều hướng và nghe nhạc, và màn hình máy tắt đi, bạn biết điều đó ngay cả khi màn hình tắt và bạn không hề tương tác với điện thoại. Bạn quan tâm đến hiệu năng của ứng dụng điều hướng. Bạn quan tâm về hiệu năng của trình phát nhạc. Có lẽ bạn chẳng hề quan tâm nhiều về những thứ khác ở thời điểm đó.
Chúng tôi bắt đầu thực hiện kiểm soát Affinity bằng cách sử dụng những kiến thức trong dịch vụ quản lý hoạt động. Chúng tôi chỉ cho phép các dịch vụ chạy nền và các ứng dụng trên bộ nhớ đệm chạy trên các nhân nhỏ. Các dịch vụ trên nền có thể sử dụng một vài nhân lớn, nhưng không phải tất cả số nhân đó, và ứng dụng bạn đang tương tác có thể sử dụng bất kỳ nhân nào. Kết quả khiến chúng tôi thực sự choáng ngợp. Phần trăm hiệu năng trên mỗi watt điện tăng ở mức 2 con số trong mọi bài test. Như vậy, về cơ bản, thông báo với kernel scheduler – một hình thức ép buộc kernel scheduler về những thứ quan trọng với người dùng – sẽ cho phép nó đưa ra những quyết định tốt hơn, dẫn đến kết quả là hệ số năng lượng – hiệu năng được cải thiện đáng kể.
Chúng tôi đã nghiên cứu điều đó khá lâu rồi, và thậm chí là trên Pixel 1 – vốn là một CPU big.LITTLE nhưng số lượng big.LITTLE ít hơn nhiều so với các CPU khác. Nó vẫn mang lại lợi ích trên Pixel 1, do đó chúng tôi áp dụng nó lên mọi thứ.
Những gì chúng tôi làm trên Android P là tìm hiểu điều gì đang chạy trên nhân lớn khi màn hình tắt, bởi các nhân lớn tiêu thụ nhiều năng lượng hơn đáng kể so với các nhân nhỏ. Chúng tôi phát hiện ra rằng có rất nhiều thứ liên quan đến hệ thống đang chạy. Chúng là các dịch vụ hệ thống. Chúng tôi đã tìm hiểu xem có bao nhiêu trong số đó ảnh hưởng lớn đến hiệu năng, và hóa ra là không nhiều, ít nhất là khi màn hình tắt. Nếu chúng ảnh hưởng nghiêm trọng đến hiệu năng khi màn hình tắt, chúng sẽ bị xem là một dịch vụ thông thường trên nền hay một thứ gì đó khác. Có một vài chuỗi khác cũng thực hiện việc thông báo cho activity manager rằng tiến trình đó là quan trọng.
Trên Android P, những gì chúng tôi làm là, khi bạn tắt màn hình, thì những loại dịch vụ hệ thống đó sẽ bị chuyển đến một CPU stack giới hạn hơn. Thay vì cho phép chúng được sử dụng mọi nhân nhỏ và một số nhân lớn, chúng tôi giới hạn chỉ cho chúng sử dụng các nhân nhỏ, từ đó tiết kiệm năng lượng hơn một chút. Việc này giúp viên pin của bạn dễ dự báo hơn, vì nếu xảy ra trường hợp một dịch vụ hệ thống sắp sử dụng một lượng lớn năng lượng khi màn hình tắt, sự tiêu hao năng lượng sẽ được giảm đi đáng kể đơn giản là vì các nhân lớn lớn hơn rất nhiều so với các nhân nhỏ và chúng cũng sử dụng nhiều năng lượng hơn.
Chẳng phải CPU scheduling phụ thuộc vào các hãng sản xuất thiết bị sao? Liệu họ có gạt bỏ những thiết lập mà Google đã thực hiện hay không?
Murray: Đúng vậy. Chúng tôi thực ra đã thấy nó được sử dụng trên các thiết bị bên thứ 3. Nó chỉ là một phần của Android thông thường, do đó bạn có thể xây dựng một tập tin ảnh Android với khả năng hỗ trợ CPU như đã nói ở trên, và mọi thứ sẽ hoạt động một cách hoàn hảo. Các OEM không cần phải làm gì trừ việc thiết lập CPU tương ứng với vi xử lý cụ thể của họ. Đây không phải là một điều gì đó to tát hay can thiệp sâu vào hệ thống, chỉ là một tweak không hề phức tạp mà chúng tôi sử dụng để quản lý scheduling từ không gian người dùng mà thôi.
Có phải trước đây hệ thống không bao giờ chuyển các tác vụ chạy nền sang các nhân khác hay không?
Murray: Trước 2015, chúng tôi chưa nghiên cứu sâu về SoC big.LITTLE trong dự án Nexus. Các OEM có các phương thức của riêng mình để giải quyết vấn đề này, nhưng chủ yếu họ tập trung vào kernel scheduler và đưa ra các quyết định thuần túy bên trong Kernel Scheduler để đạt được hiệu quả tương tự. Những gì chúng tôi làm là biến điều đó trở nên rõ ràng, và giúp bất kỳ thứ gì kernel scheduler không sử dụng trở nên dễ dàng hơn – dù nó là một trong những biến thể HMT hay EAS hay bất kỳ thứ gì. Chúng tôi còn giúp scheduler đưa ra quyết định đúng dễ dàng hơn, giảm sự phức tạp của kernel scheduler bởi bạn có tất cả thông tin có thể sử dụng được này từ các cấp độ cao hơn của hệ thống.
Poiesz: Nói rộng ra, khi một scheduler thấy có rất nhiều công việc cần xử lý, nó không hiểu được rằng liệu đó có phải là công việc quan trọng hay không. Và Activity Manager càng “dạy” cho subsystems bên dưới bao nhiêu, nó sẽ càng đưa ra được những quyết định thông minh hơn. Đó là một trong những điểm mấu chốt.
Như vậy, khi màn hình tắt, có lẽ sẽ không có nhiều thứ cần phải diễn ra ngay lập tức. Bạn có thể kết luận rằng vì không có nhiều việc phải làm nên CPU sẽ ít hoạt động lại. Nhưng đôi lúc, vì nhiều lý do khác nhau, subsystem lại đặt báo thức, thiết lập các công việc, cố tìm cách thực hiện việc xử lý. Và không thực sự có một phương thức để ăn khớp, “Tôi có một tá việc phải làm, nhưng làm bất kỳ khi nào cũng được”. Điều đó mang lại cho chúng ta một cách tốt hơn để làm mọi thứ hoàn hảo hơn nhiều, trái ngược với việc hỏi các kỹ sư “làm ơn đánh dấu những gì quan trọng hoặc không”. Điều đó sẽ rất khó. Trong khi những gì đang xảy ra sẽ biến chúng hoàn hảo hơn.
Tham khảo: ArsTechnica Android P sở hữu hình ảnh dấu vân tay vô cùng màu mè, vì Google muốn người sử dụng chịu dùng bảo mật vân tay nhiều hơn
Để biết thêm nhiều thông tin chi tiết, hãy cùng trò chuyện với bộ đôi kỹ sư Android: Benjamin Poiesz, quản lý sản phẩm đối với Android Framework, và Tim Murray, kỹ sư Android cao cấp. Trong cuộc trò chuyện này, chúng ta còn được biết thêm một ít thông tin tổng quát liên quan Android P và những thông tin chi tiết về việc Google đã làm cách nào để chuẩn đoán và theo dõi thời lượng pin trên một loạt các thiết bị được cài đặt hệ điều hành này.
Chọn đúng nhân CPU để thực hiện công việc phù hợp
Mở đầu cuộc nói chuyện, Poiesz và Murray nói về CPU Affinity. Các CPU đa nhân ngày nay đã trở nên rất phổ biến, và trong khi trên desktop, các lõi trên CPU có kích cỡ y hết nhau, thì trên điện thoại di động, các lõi này lại có kích cỡ khác biệt, được dành để xử lý các công việc khác nhau. Trên một CPU ARM 8 nhân thông thường, bạn sẽ có một con chip với kiến trúc big.LITTLE. Với kiến trúc này, 4 nhân “lớn” (big) nhanh và tốn năng lượng hơn, còn 4 nhân “nhỏ” (little) chậm hơn nhưng lại tiết kiệm năng lượng hơn. Việc một ứng dụng chạy trên nhân lớn hay nhỏ có thể ảnh hưởng lớn đến mức điện năng nó tiêu thụ và tốc độ hoạt động của nó. Chỉ định một tiến trình cho một CPU hay một nhân cụ thể gọi là thiết lập CPU Affinity.
Android P sẽ thay đổi cách mà CPU Affinity (Core Affinity) hoạt động đối với các tiến trình chạy nền, nhờ đó tiết kiệm một lượng đáng kể năng lượng.
Tim Murray: Chúng tôi đã tìm cách để Core Affinity hoạt động đối với nền tảng big.LITTLE từ năm 2015. Hồi tháng 3/2015, tôi có đọc được một bài báo về chiếc HTC One M9, chiếc điện thoại đầu tiên chạy chip Snapdragon 810. Lúc đó tôi đang nghiên cứu một số thứ liên quan hiệu năng thiết bị trên Android nói chung, và tôi biết chiếc Nexus 6P mà chúng tôi (Google) dự định ra mắt trong năm đó sẽ sử dụng Snapdragon 810. Bài báo có nói rằng Snapdragon 810 rất nóng. Và tôi nghĩ “liệu chúng tôi có thể làm tốt hơn không”. Vậy là tôi bắt đầu nghĩ về nó và bắt tay vào việc cùng mọi người trong nhóm phát triển kernel và nhóm framework. Chúng tôi đã tìm ra một phương thức để điều khiển affinity của các dịch vụ và các tiến trình cụ thể từ ActivityManager.Trên Android, một “Activity” là một màn hình đơn lẻ của một ứng dụng, ví dụ, inbox của ứng dụng email, do đó dịch vụ hệ thống “ActivityManager” thực hiện công việc đúng như tên gọi của nó: quản lý các hoạt động (activity) và các dịch vụ chạy nền – mở và đóng chúng khi được yêu cầu hay khi cần thiết để đảm bảo đủ bộ nhớ sử dụng cho máy.
Murray: Từ dịch vụ quản lý hoạt động, chúng tôi đã theo dõi xem điều gì quan trọng đối với người dùng. Bạn có thể nghĩ về dịch vụ này như một loại macro-scheduler. Trong khi kernel scheduler thực hiện các quyết định trong vài mili giây hoặc micro giây, dịch vụ activity manager sẽ theo dõi những loại tương tác vĩ mô đó, như dịch vụ gì đang chạy chẳng hạn. Ứng dụng nào hiện đang chạy trên nền (foreground)? Người dùng thực sự nhận thấy điều gì? Ví dụ, nếu bạn đang chạy ứng dụng điều hướng và nghe nhạc, và màn hình máy tắt đi, bạn biết điều đó ngay cả khi màn hình tắt và bạn không hề tương tác với điện thoại. Bạn quan tâm đến hiệu năng của ứng dụng điều hướng. Bạn quan tâm về hiệu năng của trình phát nhạc. Có lẽ bạn chẳng hề quan tâm nhiều về những thứ khác ở thời điểm đó.
Chúng tôi bắt đầu thực hiện kiểm soát Affinity bằng cách sử dụng những kiến thức trong dịch vụ quản lý hoạt động. Chúng tôi chỉ cho phép các dịch vụ chạy nền và các ứng dụng trên bộ nhớ đệm chạy trên các nhân nhỏ. Các dịch vụ trên nền có thể sử dụng một vài nhân lớn, nhưng không phải tất cả số nhân đó, và ứng dụng bạn đang tương tác có thể sử dụng bất kỳ nhân nào. Kết quả khiến chúng tôi thực sự choáng ngợp. Phần trăm hiệu năng trên mỗi watt điện tăng ở mức 2 con số trong mọi bài test. Như vậy, về cơ bản, thông báo với kernel scheduler – một hình thức ép buộc kernel scheduler về những thứ quan trọng với người dùng – sẽ cho phép nó đưa ra những quyết định tốt hơn, dẫn đến kết quả là hệ số năng lượng – hiệu năng được cải thiện đáng kể.
Chúng tôi đã nghiên cứu điều đó khá lâu rồi, và thậm chí là trên Pixel 1 – vốn là một CPU big.LITTLE nhưng số lượng big.LITTLE ít hơn nhiều so với các CPU khác. Nó vẫn mang lại lợi ích trên Pixel 1, do đó chúng tôi áp dụng nó lên mọi thứ.
Những gì chúng tôi làm trên Android P là tìm hiểu điều gì đang chạy trên nhân lớn khi màn hình tắt, bởi các nhân lớn tiêu thụ nhiều năng lượng hơn đáng kể so với các nhân nhỏ. Chúng tôi phát hiện ra rằng có rất nhiều thứ liên quan đến hệ thống đang chạy. Chúng là các dịch vụ hệ thống. Chúng tôi đã tìm hiểu xem có bao nhiêu trong số đó ảnh hưởng lớn đến hiệu năng, và hóa ra là không nhiều, ít nhất là khi màn hình tắt. Nếu chúng ảnh hưởng nghiêm trọng đến hiệu năng khi màn hình tắt, chúng sẽ bị xem là một dịch vụ thông thường trên nền hay một thứ gì đó khác. Có một vài chuỗi khác cũng thực hiện việc thông báo cho activity manager rằng tiến trình đó là quan trọng.Trên Android P, những gì chúng tôi làm là, khi bạn tắt màn hình, thì những loại dịch vụ hệ thống đó sẽ bị chuyển đến một CPU stack giới hạn hơn. Thay vì cho phép chúng được sử dụng mọi nhân nhỏ và một số nhân lớn, chúng tôi giới hạn chỉ cho chúng sử dụng các nhân nhỏ, từ đó tiết kiệm năng lượng hơn một chút. Việc này giúp viên pin của bạn dễ dự báo hơn, vì nếu xảy ra trường hợp một dịch vụ hệ thống sắp sử dụng một lượng lớn năng lượng khi màn hình tắt, sự tiêu hao năng lượng sẽ được giảm đi đáng kể đơn giản là vì các nhân lớn lớn hơn rất nhiều so với các nhân nhỏ và chúng cũng sử dụng nhiều năng lượng hơn.
Chẳng phải CPU scheduling phụ thuộc vào các hãng sản xuất thiết bị sao? Liệu họ có gạt bỏ những thiết lập mà Google đã thực hiện hay không?
Murray: Đúng vậy. Chúng tôi thực ra đã thấy nó được sử dụng trên các thiết bị bên thứ 3. Nó chỉ là một phần của Android thông thường, do đó bạn có thể xây dựng một tập tin ảnh Android với khả năng hỗ trợ CPU như đã nói ở trên, và mọi thứ sẽ hoạt động một cách hoàn hảo. Các OEM không cần phải làm gì trừ việc thiết lập CPU tương ứng với vi xử lý cụ thể của họ. Đây không phải là một điều gì đó to tát hay can thiệp sâu vào hệ thống, chỉ là một tweak không hề phức tạp mà chúng tôi sử dụng để quản lý scheduling từ không gian người dùng mà thôi.
Có phải trước đây hệ thống không bao giờ chuyển các tác vụ chạy nền sang các nhân khác hay không?
Murray: Trước 2015, chúng tôi chưa nghiên cứu sâu về SoC big.LITTLE trong dự án Nexus. Các OEM có các phương thức của riêng mình để giải quyết vấn đề này, nhưng chủ yếu họ tập trung vào kernel scheduler và đưa ra các quyết định thuần túy bên trong Kernel Scheduler để đạt được hiệu quả tương tự. Những gì chúng tôi làm là biến điều đó trở nên rõ ràng, và giúp bất kỳ thứ gì kernel scheduler không sử dụng trở nên dễ dàng hơn – dù nó là một trong những biến thể HMT hay EAS hay bất kỳ thứ gì. Chúng tôi còn giúp scheduler đưa ra quyết định đúng dễ dàng hơn, giảm sự phức tạp của kernel scheduler bởi bạn có tất cả thông tin có thể sử dụng được này từ các cấp độ cao hơn của hệ thống.
Poiesz: Nói rộng ra, khi một scheduler thấy có rất nhiều công việc cần xử lý, nó không hiểu được rằng liệu đó có phải là công việc quan trọng hay không. Và Activity Manager càng “dạy” cho subsystems bên dưới bao nhiêu, nó sẽ càng đưa ra được những quyết định thông minh hơn. Đó là một trong những điểm mấu chốt.
Như vậy, khi màn hình tắt, có lẽ sẽ không có nhiều thứ cần phải diễn ra ngay lập tức. Bạn có thể kết luận rằng vì không có nhiều việc phải làm nên CPU sẽ ít hoạt động lại. Nhưng đôi lúc, vì nhiều lý do khác nhau, subsystem lại đặt báo thức, thiết lập các công việc, cố tìm cách thực hiện việc xử lý. Và không thực sự có một phương thức để ăn khớp, “Tôi có một tá việc phải làm, nhưng làm bất kỳ khi nào cũng được”. Điều đó mang lại cho chúng ta một cách tốt hơn để làm mọi thứ hoàn hảo hơn nhiều, trái ngược với việc hỏi các kỹ sư “làm ơn đánh dấu những gì quan trọng hoặc không”. Điều đó sẽ rất khó. Trong khi những gì đang xảy ra sẽ biến chúng hoàn hảo hơn.
Tham khảo: ArsTechnica Android P sở hữu hình ảnh dấu vân tay vô cùng màu mè, vì Google muốn người sử dụng chịu dùng bảo mật vân tay nhiều hơn
