Google giải thích lí do giao diện Android kém mượt hơn các OS khác

Giao diện Acer Ring trên máy tính bảng ICONIA TAB A200

Tinhte-Mới đây, kĩ sư tập sự Andrew Munn tại Google đã cho biết thông tin vì sao hầu hết các thiết bị chạy Androidthường phản hồi chậm hơn và hoạt động của giao diện không mượt mà bằng iOS hay Windows Phone 7. Trên trang Google+ của mình, Andrew Munn nói rằng việc chậm như vậy không phải do Android chạy bytecode (mã chương trình sẽ được dịch thẳng sang mã máy) hay do iOS sử dụng native code (tạm dịch: mã gốc, mã được viết cho một vi xử lí xác định). Cốt lõi của vấn đề nằm ở thứ tự ưu tiên cho việc dựng đồ họa trên các hệ điều hành này khác nhau. Android dựng hình liên tục, và tất cả thao tác đều có mức độ ưu tiên như nhau, theo đúng mô hình của máy tính truyền thống. Trong khi đó, thao tác dựng hình của iOS và Windows Phone 7 được "xếp hàng" và đợi đến khi cần thì chúng sẽ được bộ xử lí đồ họa tải lên (mức độ ưu tiên theo thời gian thực).

Đây chính là lí do khi chúng ta khởi động nhiều ứng dụng trên Android thì máy bắt đầu chậm lại. Trong iOS, nếu một ứng dụng chưa hoàn tất việc tải nhưng bạn vẫn chạm vào màn hình thì nó sẽ tạm dừng. Đến khi nào bạn bỏ ngón tay khỏi màn hình thì nó mới tiếp tục công việc. Ví dụ rõ nhất mà bạn có thể thử đó là khi Safari đang tải trang web, nếu chạm tay vào màn hình thì nó sẽ dừng mãi, bỏ tay ra thì tiếp tục tải về. Tương tự, khi iOS đang tải ứng dụng từ App Store, chạm tay lên màn hình sẽ khiến máy dừng lại. Việc này giúp cho thiết bị iOS hay Windows Phone 7 không phải hoạt động vất vả trong thực thi đa tác vụ, giúp tiết kiệm pin hơn. Android cố gắng làm tất cả mọi việc cùng một lúc nên kết quả là giao diện không còn mượt, máy chậm đi thấy rõ.

Bên cạnh nguyên nhân về khả năng render (các thao tác dựng hình nói chung, cần thiết để hiển thị đối tượng lên màn hình) giao diện theo luồng và tính ưu tiên khi xử lý thì việc Android giật hơn WP7 hay iOS còn phụ thuộc vào nhiều nguyên nhân khác.

Trước tiên là khả năng hỗ trợ của phần cứng. Sự tăng tốc về phần cứng tạo nên sự khác biệt lớn đối với những ứng dụng như Home Screen và Android Market. Việc giảm tải render đối với GPU sẽ giúp tăng thời lượng pin bởi GPU là phần cứng có chức năng không đổi (fix-function) và vì vậy, chúng hoạt động ở mức điện năng thấp hơn.

Vấn đề thứ 2 liên quan đến hệ thống tối ưu bộ nhớ (Garbage Collection - GC). GC có nhiệm vụ thu hồi các tập tin rác hay bộ nhớ do ứng dụng chiếm đóng trong quá trình khởi chạy và không còn được sử dụng. Ví dụ, nếu bạn sử dụng ứng dụng Photo Gallery trên phiên bản Android Honeycomb hay Ice Cream Sandwich, bạn sẽ ngạc nhiên khi tỉ lệ khung hình trong một giây (fps) khá thấp. Hình ảnh sẽ tự động được đưa về 30 fps bởi nếu không cắt bớt, việc vuốt qua lại giữa các bức ảnh sẽ được xử lý ở 60 fps. Ở 60 fps, GC đôi khi sẽ tạm ngưng gây nên tình trạng "vấp" trong khi vuốt. Vì vậy, bằng việc giảm tỉ lệ khung hình xuống 30 fps, hiện tượng "vấp" đã được giải quyết.

Thứ 3 tiếp tục là một vấn đề liên quan đến phần cứng. Chip NVIDIA Tegra 2 là chip lõi kép nhưng nó vẫn gặp phải tình trạng thiếu băng thông bộ nhớ và không hỗ trợ công nghệ NEON. (NEON là một công nghệ do ARM phát triển giúp tăng tốc khả năng xử lý thuật toán cho nội dung đa phương tiện và tín hiệu như giải mã/ghi mã video, đồ họa 2D/3D, game, âm thanh, xử lý giọng nói, hình ảnh, hội thoại và âm thanh tổng hợp). Máy tính bảng Honeycomb có thể sẽ tốt hơn nếu sử dụng một GPU khác.

Thứ 4, Android cần phải có một hệ thống giao diện phối hợp hiệu quả hơn. Trên iOS, mỗi thành phần của giao diện (UI) được render độc lập và được lưu trữ trong bộ nhớ, vì vậy rất nhiều hiệu ứng chuyển động chỉ yêu cầu GPU tái tổ chức UI. Nhưng thật không may, trên Android, hệ thống phân cấp của UI lại bị chắp vá trước khi render. Do đó, các hiệu ứng chuyển động yêu cầu mọi thành phần hoạt hóa của màn hình phải được vẽ lại (redrawn).

Thứ 5, bộ máy ảo Dalvik VM không đủ mạnh như máy ảo Java (Java Virtual Machine). Java nổi tiếng về khả năng xử lý các giao diện nặng trên máy tính bàn. Dalvik lại không thể thực hiện một điều tương tự. Hiện tượng lag cũng một phần do Dalvik là một nền tảng chéo chạy trên các API máy (native API) và làm nhiệm vụ phiên dịch các tập tin *.class được viết bằng Java sang những tập tin *.dex (Dalvik Excutable) để ứng dụng có thể chạy được trên Android. Trong khi đó, lõi UI của WP7 được xây dựng trên mã máy mặc dù theo kế hoạch ban đầu thì giao diện WP7 sẽ dựa trên Silverlight.

Tóm lại, giao diện của Android sẽ không thể hoàn toàn mượt mà bởi những ràng buộc sau:
-Việc render giao diện xảy ra trên luồng (thread) chính của ứng dụng;
-Việc render giao diện chỉ có phân cấp bình thường thay vì ưu tiên.

Ngay cả với chiếc Galaxy Nexus hay chiếc máy tính bảng bốn nhân EeePad Transformer Prime thì vẫn không thể đảm bảo độ mượt khi vận hành nếu 2 ràng buộc trên còn tồn tại. Vậy tại sao nhóm phát triển Android lại thiết kế bộ khung render như vậy?

Dự án Android được khởi động từ trước khi iPhone ra đời và vào thời điểm này, Android được thiết kế để cạnh tranh vớiBlackberry. Nguyên mẫu đầu tiên của Android không phải là một thiết bị có màn hình cảm ứng và bộ khung render của Android thực sự hữu ích với bàn phím QWERTY và trackball. Khi iPhone ra mắt, nhóm phát triển Android bị thúc giục phải phát hành một sản phẩm cạnh tranh trực tiếp với iPhone nhưng đã quá muộn để viết lại bộ khung giao diện.

Đây cũng chính là lý do tại sao Windows Mobile 6.5, Blackberry OS và Symbian hỗ trợ màn hình cảm ứng rất kém. Giống Android, cả 3 đều không được thiết kế để tối ưu hệ thống render giao diện. Để cạnh tranh với iPhone, cả RIM, Microsoft và Nokia đã từ bỏ nền tảng cũ của họ và phát triển nền tảng mới phù hợp hơn. Vì vậy, Android có thể nói là nền tảng di động duy nhất còn "vướn" lại ở thời đại "tiền iPhone".

Tại sao nhóm phát triển Android không viết lại bộ khung render? Lập trình viên Romain Guy cho biết:

... vẫn còn rất nhiều việc mà chúng tôi phải làm hôm nay bắt nguồn từ những lựa chọn trong quá khứ ... và việc xứ lý hiệu ứng hoạt hóa của UI theo thread là vấn đề lớn nhất. Chúng tôi đang nghiên cứu nhiều giải pháp để cải thiện điều này và giải pháp đơn giản có lẽ là phải tạo ra một bộ công cụ render UI mới nhưng không phải là điều dễ dàng.

Romain không nói khó ở điểm nào nhưng có thể suy đoán:

-Tất cả ứng dụng Android phải được viết lại để hỗ trợ bộ khung render mới;
-Android cần được trang bị chế độ hỗ trợ cho các phần mềm cũ;
-Việc phát triển các tính năng mới cho Android sẽ phá sản nếu đưa ra bô khung mới.

Thiết nghĩ việc thay đổi bộ khung phát triển của Android là điều cần xảy ra mặc cho những khó khăn và hệ lụy. Vấn đề lag của Android phải được đặt lên hàng đầu bởi nội dung phàn nàn nhiều nhất về Android vẫn là "chậm" và "giật". Bên cạnh đó, giao diện hay lag sẽ phá vỡ cốt lõi ngôn ngữ của màn hình cảm ứng. Thiết bị với màn hình cảm ứng sẽ không còn "tự nhiên" nữa và màn hình cảm ứng cũng mất đi tính chất "ma thuật" của nó. Android cần phải khắc phục nhược điểm kể trên nếu không muốn mất đi hình tượng của mình trong lòng người dùng.