Google đã làm gì với Android để điện thoại gập có được trải nghiệm tốt hơn? (Phần 2)

Trang chủ > Tin tức > Chuyên mục UH Vip

Google đã làm gì với Android để điện thoại gập có được trải nghiệm tốt hơn? (Phần 2)

06/05/2026 06:26

TinhTe/Huy Phạm - Google đã làm gì với Android để điện thoại gập có được trải nghiệm tốt hơn? (Phần 2)

Google đã thực hiện một nỗ lực lớn nhằm "sửa sai" sau nhiều năm bỏ ngỏ thị trường màn hình lớn, bắt đầu từ Android 12L và hiện nay là các bộ quy chuẩn Adaptive App Quality Guidelines vô cùng khắt khe.
Trong kiến trúc Android hiện đại, chất lượng của một ứng dụng không còn được đo lường bằng một thang điểm duy nhất mà được phân tách thành ba cấp độ năng lực. Mỗi cấp độ đại diện cho một ngưỡng cam kết của nhà phát triển đối với trải nghiệm người dùng trên các màn hình có diện tích lớn.

Hệ thống phân tầng chất lượng ứng dụng thích ứng

Cấp độ 3 (T3)

Đây là ngưỡng tối thiểu để một ứng dụng không bị coi là "lỗi thời" trên các thiết bị hiện đại. Trọng tâm của T3 là sự ổn định và khả năng tương thích cơ bản. Ở cấp độ này, ứng dụng phải đảm bảo không bị hỏng hóc hoặc hiển thị sai lệch khi người dùng thay đổi kích thước cửa sổ hoặc xoay thiết bị. Một trong những yêu cầu quan trọng nhất là việc loại bỏ hoàn toàn tình trạng letterboxing, tức là các dải đen xuất hiện ở hai bên ứng dụng khi tỷ lệ khung hình không khớp.
Quy trình kỹ thuật ở T3 đòi hỏi nhà phát triển phải cấu hình ứng dụng để nó có thể thay đổi kích thước một cách linh hoạt (resizable activity). Kể từ Android 12 trở đi, hệ thống mặc định cho phép tất cả các ứng dụng đi vào chế độ đa cửa sổ (multi-window), bất kể nhà phát triển có thiết lập thuộc tính resizeableActivity trong mã nguồn hay không. Tuy nhiên, để đạt chuẩn T3, ứng dụng phải chủ động xử lý các thay đổi cấu hình (configuration changes) này mà không làm mất dữ liệu người dùng, như văn bản đang nhập dở hoặc vị trí cuộn trang.

Cấp độ 2 (T2)

Ở cấp độ này, ứng dụng bắt đầu thể hiện sự thông minh trong việc sử dụng không gian màn hình bổ sung. Thay vì chỉ đơn giản là trải rộng giao diện từ trái sang phải, các ứng dụng T2 áp dụng bố cục đa bảng (multi-pane layouts). Mô hình phổ biến nhất là List-Detail, nơi người dùng có thể xem danh sách các mục ở một bên và nội dung chi tiết ở bên còn lại mà không cần phải thực hiện các bước điều hướng "Back" liên tục (ứng dụng Gmail là 1 ví dụ).

Ứng dụng T2 cũng phải điều chỉnh các thành phần điều hướng để phù hợp với công thái học của màn hình lớn. Thay vì sử dụng thanh điều hướng phía dưới (bottom navigation) vốn được thiết kế cho ngón cái trên điện thoại, nhà phát triển sẽ chuyển sang sử dụng thanh điều hướng dọc (navigation rail) hoặc ngăn kéo điều hướng (navigation drawer) ở cạnh bên. Điều này không chỉ giúp tận dụng chiều rộng của màn hình mà còn giúp người dùng dễ dàng thao tác khi cầm máy bằng hai tay. Ngoài ra, việc hỗ trợ các thiết bị nhập liệu ngoại vi như chuột và bàn phím ở mức độ cơ bản, bao gồm cả các trạng thái di chuột là một yêu cầu bắt buộc.

Cấp độ 1 (T1)

Đây là đỉnh cao của trải nghiệm Android, nơi ứng dụng cung cấp những tính năng mà các thiết bị màn hình nhỏ không thể có được. Các ứng dụng T1 được thiết kế để tận dụng tối đa các đặc tính vật lý của thiết bị gập, chẳng hạn như nhận diện tư thế để bàn hoặc tư thế quyển sác. Khi người dùng gập thiết bị một góc 90 độ, ứng dụng Tier 1 sẽ tự động chuyển đổi giao diện, ví dụ như biến nửa dưới màn hình thành một bàn phím hoặc bảng điều khiển chuyên dụng, trong khi nội dung chính vẫn hiển thị rõ ràng ở nửa trên.

Sự khác biệt của T1 còn nằm ở khả năng hỗ trợ các thiết bị ngoại vi ở mức độ chuyên sâu như máy tính để bàn. Điều này bao gồm việc hỗ trợ các phím tắt bàn phím tương đương với phiên bản Web hoặc PC, hỗ trợ bút cảm ứng (stylus) với độ trễ cực thấp và khả năng nhận diện áp lực nét vẽ, cũng như các tính năng kéo và thả (drag and drop) dữ liệu mượt mà giữa các ứng dụng khác nhau đang mở đồng thời.

Window Size Classes

Để thực hiện việc tối ưu hóa, các nhà phát triển không còn dựa vào kích thước màn hình vật lý theo inch hay mật độ điểm ảnh truyền thống. Thay vào đó, Google đã chuẩn hóa quy trình thông qua khái niệm Window Size Classes, một hệ thống phân loại dựa trên không gian thực tế mà ứng dụng đang chiếm dụng.

Hệ thống này chia không gian hiển thị thành ba ngưỡng (Compact, Medium, Expanded) dựa trên chiều rộng (Width) và chiều cao (Height). Đơn vị đo lường là dp (density-independent pixels) để đảm bảo tính nhất quán trên mọi loại màn hình.

Lớp Nhỏ (Compact - < 600dp): Đây là không gian điển hình của điện thoại thông minh ở chế độ dọc. Quy tắc thiết kế ở đây là ưu tiên hiển thị theo chiều dọc, sử dụng một bảng duy nhất và thanh điều hướng phía dưới để dễ dàng tiếp cận bằng ngón cái.

Lớp Trung bình (Medium - 600dp đến 840dp): Phổ biến trên máy tính bảng cỡ nhỏ, điện thoại gập ở chế độ mở, hoặc điện thoại lớn ở chế độ ngang. Đây là ngưỡng "vàng" nơi ứng dụng bắt đầu chuyển đổi sang thanh điều hướng dọc (Navigation Rail) và có thể bắt đầu hiển thị hai bảng nội dung nếu chiều rộng cho phép.

Lớp Mở rộng (Expanded - > 840dp): Dành cho máy tính bảng cỡ lớn, laptop chạy Android hoặc chế độ Desktop. Tại đây, ứng dụng có đủ không gian để triển khai các bố cục đa bảng phức tạp, cố định ngăn kéo điều hướng và hiển thị nhiều cột nội dung đồng thời.

Responisve và Adaptive

Trong quy trình tối ưu, nhà phát triển phải kết hợp cả hai phương pháp thiết kế để đạt được hiệu quả cao nhất.

Responsive hay thiết kế đáp ứng: Tập trung vào việc thay đổi kích thước và vị trí của các thành phần dựa trên tỷ lệ màn hình. Chẳng hạn, một lưới ảnh có thể hiển thị 3 cột trên điện thoại và tự động giãn ra thành 5 cột trên máy tính bảng. Công cụ chủ đạo ở đây là ConstraintLayout, giúp các thành phần giao diện tự liên kết với nhau và với các cạnh màn hình một cách linh hoạt.

Adaptive hay thiết kế thích ứng: Đây là bước tiến cao hơn, nơi cấu trúc của ứng dụng thay đổi hoàn toàn tại các điểm ngắt. Ví dụ, một ứng dụng ghi chú trên điện thoại chỉ hiện danh sách các ghi chú, nhưng khi phát hiện màn hình ở lớp "Expanded", nó sẽ tự động hiển thị danh sách ở bên trái và nội dung soạn thảo ở bên phải. Quy trình này đòi hỏi nhà phát triển phải tạo ra nhiều tệp tài nguyên bố cục khác nhau hoặc sử dụng các logic lập trình hiện đại để "vẽ" lại giao diện dựa trên lớp kích thước cửa sổ hiện tại.

Tính liên tục

Đối với người dùng điện thoại gập, một trong những trải nghiệm quan trọng nhất là tính liên tục khi chuyển đổi giữa màn hình ngoài và màn hình trong. Quy trình này trong kỹ thuật Android được gọi là xử lý "Configuration Change".

Mặc định, khi kích thước màn hình thay đổi (ví dụ khi mở điện thoại gập), hệ thống Android sẽ hủy bỏ hoạt động hiện tại và tạo mới (recreate) nó để áp dụng các tài nguyên đồ họa mới phù hợp hơn. Nếu nhà phát triển không xử lý đúng cách, người dùng sẽ gặp phải các tình trạng khó chịu như: video đang xem bị tải lại từ đầu, văn bản đang gõ bị biến mất, hoặc trang web đang cuộn bị nhảy về đầu trang.

Để giải quyết vấn đề này, quy trình tối ưu hóa bao gồm:

• Lưu trạng thái giao diện (UI State): Nhà phát triển sử dụng các bộ lưu trữ tạm thời như SavedStateHandle hoặc ViewModel để giữ lại các biến trạng thái quan trọng trước khi ứng dụng bị tái tạo.

• Duy trì trạng thái đa phương tiện: Ứng dụng phải đảm bảo các luồng phát media tiếp tục diễn ra một cách liền mạch. Ví dụ, Spotify phải tiếp tục phát nhạc mà không bị khựng lại dù người dùng đang thay đổi kích thước cửa sổ từ nhỏ sang lớn.

• Quản lý tài nguyên độc quyền: Trong chế độ đa nhiệm, ứng dụng phải xử lý thông minh việc chia sẻ camera hoặc microphone. Chẳng hạn, nếu một ứng dụng họp trực tuyến đang mở và người dùng mở thêm một ứng dụng chụp ảnh, ứng dụng đầu tiên phải biết cách tạm dừng quyền truy cập camera một cách duyên dáng thay vì bị crash.

Tuy nhiên đời đâu như là mơ, bộ quy chuẩn thì Google đã có rồi nhưng mà thực tế đang xảy ra là các ứng dụng có tuân thủ theo quy chuẩn này không lại là một câu chuyện khác mình sẽ chia sẻ tiếp ở phần sau.