Android Runtime - Google ART project: Bước đi tiếp theo của Android

12/11/2013 10:34
Mai Phương

Chúng ta có thể thấy vì sao Google tuyên bố là Android 4.4 sẽ dành cho những thiết bị 512 MB ram vẫn chạy tốt. Vì bộ nhớ ram sử dụng chỉ là do ứng dụng sử dụng. Trình quản lý bộ nhớ Android sẽ dọn dẹp ứng dụng khác khi ứng dụng đó cần thêm bộ nhớ. Và phần bộ nhớ do Dalvik VM chạy đã được trả lại cho thêm các ứng dụng khác.

android-runtime-google-art-project-buoc-di-tiep-theo-cua-android1
Android được thiết kế để chạy trên một dải phần cứng rất rộng: từ những bo mạch, đồng hồ đeo tay, mắt kính, laptop, điện thoại, tablet và cả trên tv nữa. Những phần cứng càng ngày càng mở rộng ra nhưng có 1 thứ thiết yếu trên android mà kể từ khi nó được giới thiệu đến giờ vẫn chưa hề được thay đổi là Dalvik VM (Máy ảo Dalvik) – một lớp mà nhờ đó ứng dụng có thể chạy trên rất nhiều phần cứng khác nhau mà việc lập trình chỉ diễn ra một lần duy nhất. Cần phải nhắc là là iOS chỉ chạy trên phần cứng riêng việt, Windows Phone cũng thiết kế để chạy trên vài CPU và BB10 cũng thế. Android hỗ trợ dải phần cứng rộng là nhờ có Dalvik VM giúp giải quyết việc chạy trên đa nền tảng của Android. Nhưng vấn để của Dalvik VM chính là làm cho thiết bị chạy Android không mượt mà bằng các nền tảng khác, tốn pin và hao bộ nhớ. Google ART ra đời nhằm giải quyết các vấn đề trên.

ART là gì?

ART là từ viết tắt của Android Runtime. Đây là một dự án của Google được bắt đầu từ năm 2011 (tức từ 2 năm trước) nhằm mục đích thay thế Dalvik VM (máy ảo Dalvik) vốn được giới thiệu từ tháng 5/2010 ở phiên bản Android 2.2 (Tên mã froyo). Dalvik VM là một trình JIT (Just-in-time) nhằm biên dịch code ở dạng tiền biên dịch (Interpreted code) thành bytecode (mã thực thi chạy được trược tiếp trên CPU) ngay khi ta chạy chương trình bất kì trên Android. Một ứng dụng Android khi lập trình và được biên dịch thì nó được điên dịch bán phần (Liên kết các thư viện phần mềm cần thiết và kiên kết các hàm – function – cần thiết). Khi được lên máy Android bất kì, bạn chỉ cần để Dalvik cache biên dịch lại là bạn có thể chạy ứng dụng đó trên phần cứng của bạn mà không quan tâm bộ vi xử lý của bạn là gì. Khác với Dalvik, ART dùng cách khác để có được bytecode (mã nhị phân để chạy trên vi xử lý trên máy của bạn) đó là Ahead-Of-Time (AOT). Ngay sau trong lúc cài đặt phần mềm, ART sẽ làm nhiệm vụ biên dịch code ở dạng tiền biên dịch sang bytecode cho máy đó (tức là ứng dụng sẽ ở dạng native – được thiết kế riêng cho máy đó). Việc đó sẽ làm cho ứng dụng chạy nhanh hơn, và loại bỏ hoàn toàn lag và tăng việc đáp ứng của ứng dụng đồng thời làm giảm lượng bộ nhớ RAM.

ART vs. Dalvik

android-runtime-google-art-project-buoc-di-tiep-theo-cua-android2

(1) Khi ứng dụng chạy, chỉ phần code nào được chạy, thì sẽ được Dalvik biên dịch. Sẽ có độ trễ nhất định khi bạn dùng sang một phần khác của ứng dụng. Khi đó Dalvik sẽ biên dịch tiếp phần code bạn chạy đó và lag xảy ra khi đoạn mã thực thi không có sẵn mà phải đợi biên dịch.

Như các trong bảng trên, chúng ta có thể thấy vì sao Google tuyên bố là Android 4.4 sẽ dành cho những thiết bị 512 MB ram vẫn chạy tốt. Vì bộ nhớ ram sử dụng chỉ là do ứng dụng sử dụng. Trình quản lý bộ nhớ Android sẽ dọn dẹp ứng dụng khác khi ứng dụng đó cần thêm bộ nhớ. Và phần bộ nhớ do Dalvik VM chạy đã được trả lại cho thêm các ứng dụng khác.

Ứng dụng hoàn toàn Native sẽ giúp Android có được độ mượt tương đương iOS và Windows Phone vốn các ứng dụng đã được biên dịch sẵn thành bytecode (mã thực thi của máy)

Thời gian chạy ứng dụng sẽ nhanh hơn rất nhiều. Trên thực tế, người ta thử nghiệm ART và Dalvik nhận thấy thời gian chạy ứng dụng đã nhanh hơn gấp đôi.

Pin sẽ được cải thiện đáng kể vì CPU sẽ không còn phải biên dịch ứng dụng liên tục khi ứng dụng được chạy.

Và còn một điều nữa khi Google xây dựng Google ART chính là tranh chấp bản quyền java giữa Oracle và Google năm 2011 đã đẩy Google phải phát triển ART (Dalvik VM đựa trên Java VM). Vấn đề bản quyền sẽ được bỏ qua khi Google thiết kế ART. Một mũi tên đã đi trúng nhiều đích.

Native code vs. interpreted code

Native code (Mã đã được biên dịch) là thứ mà ART tạo ra. Interpreted code là những gì để Dalvik VM chạy ứng dụng. Dễ hiểu hơn. Chúng ta hãy nhắc đến 1 ví dụ: javascript trên trình duyệt, mỗi khi nạp trang web, javascript sẽ được trình duyệt biên dịch và chạy nó. Nhờ thế mà javascript có thể chạy trên rất nhiều môi trường hệ điều hành: Linux, Windows, … mà không chịu ảnh hưởng của phần cứng. Chúng ta hãy xem bảng so sánh sau để biết native code chạy nhanh đến thế nào.

Các bạn sẽ thấy là Native code chạy nhanh hơn đến ~10 lần so với mã chưa được biên dịch trước.

Các bạn sẽ thấy là Native code chạy nhanh hơn đến ~10 lần so với mã chưa được biên dịch trước.

Mong đợi gì – phát triển

Hiện tại, Google ART mới chỉ ở giai đoạn tìm kiếm nhà phát triển và sự hợp tác tối ưu từ các hãng phần cứng. Sự xuất hiện của nó ở trên Android 4.4 mới chỉ giới hạn ở môi trường developer. Bạn phải bật nó từ trong menu Developer Option. Trên website của Android thì Google cũng cảnh báo đây là bản xem trước (preview) và ở đạng trải nghiệm trước (experimentally). Nhưng theo cảm nhận của cá nhân với thiết bị Nexus 4, thì ứng dụng hoạt động nhanh hơn đáng kể với thư viện ART, ứng dụng hoạt động với giao diện mượt mà và độ đáp ứng được cải thiện thấy rõ. Tuy nhiên khá nhiều ứng dụng như Whatsapp … chưa tương thích. Nhưng trong tương lai không xa nữa, có thể ở Android 4.5 hoặc 5.0 thì Google ART sẽ trở thành mặc định, các ứng dụng sẽ tương thích tốt hơn nữa và sự cải thiện sẽ nhiều hơn nữa so với Dalvik VM khi so với hiện nay.

Có lẽ thì ARM sẽ là người mừng nhất, việc biên dịch ứng dụng liên tục với Dalvik cache sẽ tiêu tốn CPU và RAM rất nhiều. Công nghệ little.BIG sẽ luôn phải kích hoạt nhân A15 (Big) để ứng dụng được biên dịch nhanh nhất có thể nhưng trong tương lai, khi các ứng dụng đã được biên dịch sẵn như thế thì chúng ta sẽ cần rất ít đến nhân A15 (Big) mà thay vào đó là nhân A7 (little) để ứng dụng chạy. Nhờ thế mà thời lượng pin sẽ được cải thiện đáng kể.

Liệu có ảnh hưởng đến việc bào chế các bản Rom?

Câu trả lời là có. Nếu bạn đang là tín đồ của rom chế thì đây sẽ là tin không vui xíu nào. Ngoại trừ các rom xuất phát từ việc build từ AOSP thì các rom gốc sẽ gần như không thể thay đổi được do phải trải qua quá trình deodex để thay đổi code. Nhưng như thế thì ART sẽ gặp lỗi khi biên dịch ứng dụng thành mã máy. Hiện nay vẫn chưa tìm ra được cách nào nhưng có thể trong tương lai chúng ta sẽ tìm ra cách để bào chế chỉnh sửa các bản rom dễ dàng mà không ảnh hưởng đến ART

Tạm kết

Google đang có bước đi cực kỳ cần thiết để có thể giữ chân người dùng lại với hệ sinh thái Android, tiếp tục phát triển Android một cách bền vững nhất. Nếu Google giải quyết được vấn đề về “vấn nạn” lag, vấn đề về pin và bộ nhớ thì việc phát triển thêm triệu người dùng tiếp theo nhờ vào những phần cứng thấp hơn sẽ trở nên hiện thực hóa hơn rất nhiều. Nhưng có lẽ mình hoan nghênh Google nhất nếu giảm sự phân mảnh và cập nhập hệ điều hành trên các thiết bị được nhanh hơn thì sẽ là niềm vui lớn nhất với cộng đồng android. Có lẽ việc đó sẽ còn không xa nữa.

(Vozforums)

Bình luậnViết cảm nhận

Mới nhất
TopTrong ngày
TopTrong tuần