VnReview
Hà Nội

Tìm hiểu về ART - phần mềm thực thi ứng dụng mới trên Android

Tại sự kiện I/O diễn ra vào tháng 6, Google đã công bố rộng rãi kế hoạch ra mắt phần mềm thực thi ứng dụng mới cho Android. Theo đó, Android RunTime (ART) sẽ thay thế cho bộ máy ảo Dalvik cũ kỹ trên Android.

Android RunTime là gì

Tại sự kiện I/O diễn ra vào tháng 6, Google đã công bố rộng rãi kế hoạch ra mắt phần mềm runtime mới cho Android. Theo đó, Android RunTime – ART sẽ thay thế cho bộ máy ảo Dalvik cũ kỹ trên Android. Android RunTime là gì Thông thường, các hệ điều hành khác iOS, Windows hay Tizen sẽ chạy các phần mềm được biên dịch từ mã nguồn sang mã thực thi tương thích với kiến trúc phần cứng của hệ điều hành đó. Ví dụ, iOS chỉ có thể chạy trên vi xử lý kiến trúc ARM còn các phiên bản Windows lớn (XP, 7, 8…) chỉ có thể chạy trên kiến trúc x86.  Android không đi theo xu hướng này. Phần lớn các phần mềm trên Android đều được xây dựng bằng Java và sau đó được biên dịch thành "byte-code", tức là mã nguồn cho máy ảo Java. Trước đây, byte-code sẽ được chuyển tới máy ảo Dalvik để biên dịch một lần nữa thành các file thực thi .dex và .odex. Sau đó, các file thực thi này sẽ được chạy trên thiết bị của bạn. Ban đầu, Dalvik chỉ là một máy ảo khá đơn giản. Song, khi các thiết bị di động ngày càng trở nên phức tạp hơn, Google sẽ cần phải giải quyết các vấn đề hiệu năng (hiệu năng máy ảo sẽ luôn kém cỏi hơn rất nhiều so với chạy trực tiếp như trên iOS hay Windows). Đồng thời, do là phần mềm chịu trách nhiệm thực thi gần như tất cả các ứng dụng Android, Google sẽ phải tìm cách giúp máy ảo Android của mình có thể bắt kịp với các tiến bộ của ngành công nghiệp phần cứng. Dần dần, Google đã trang bị cho Dalvik một bộ biên dịch JIT (Just-in-time: biên dịch mã nguồn ngay trước khi thực thi), khả năng chạy nhiều thread (chạy song song nhiều luồng) cùng vô số thay đổi nhỏ khác. Tuy vậy, trong những năm vừa qua, tốc độ phát triển của hệ sinh thái Android đã vượt quá khả năng phát triển Dalvik. Do đó, Google cần phải xây dựng một phần mềm runtime (phần mềm chịu trách nhiệm chạy các ứng dụng khác) mới để làm cơ sở vững chắc cho tương lai. Cụ thể hơn, giải pháp phần mềm runtime mới của Google sẽ phải thích ứng với hiệu năng của cả các vi xử lý của ngày hôm nay cũng như các vi xử lý 8 nhân của những năm tới, có thể mở rộng thêm bộ nhớ và RAM của thiết bị. Từ đó, ART ra đời. Kiến trúc của ART Trước hết, ART được thiết kế để tương thích hoàn toàn với mô hình biên dịch bytecode của Dalvik. Do đó, khi nhìn từ góc độ nhà phát triển ứng dụng , bạn sẽ không cần phải viết mã nguồn riêng cho Dalvik rồi viết lại cho ART. Bạn không cần phải lo lắng gì về tính tương thích giữa 2 môi trường cả. Sự thay đổi lớn nhất về thiết kế mà ART mang tới là khả năng biên dịch code theo mô hình AOT (Ahead of Time) thay vì JIT (Just in Time) như trước đây. Điều này có ý nghĩa là gì? Bộ runtime mới của Android không còn cần phải dịch từ byte-code sang mã máy mỗi lần chạy ứng dụng. Thay vào đó, ART sẽ chỉ biên dịch byte-code sang mã máy đúng một lần. Quá trình thực thi ứng dụng trong các lần chạy tương lai sẽ được thực hiện từ các đoạn mã máy đã được tạo ra từ trước. Dĩ nhiên, việc biên dịch từ bytecode sang mã máy để chạy ứng dụng bất cứ khi nào bạn muốn sẽ đòi hỏi thêm bộ nhớ. Phương pháp cài đặt ứng dụng mới (biên dịch một lần) chỉ trở nên khả thi do bộ nhớ điện thoại đã được tăng lên rất nhiều so với trước đây – khi mà bộ nhớ Android chỉ dừng lại ở 2GB hoặc 4GB. Sự thay đổi này sẽ giúp mang tới các ứng dụng được tối ưu hơn. Đây thực sự là một bước tiến hoàn toàn nằm ngoài khả năng của Dalvik. Trên Android L, do mã nguồn sẽ được tối ưu và biên dịch sang mã máy đúng một lần duy nhất, chu trình tối ưu này sẽ cần phải được thực hiện rất tốt. Theo Google, Android giờ đã có thể đạt đến mức tối ưu tốt hơn đối với toàn bộ code-base (tất cả mã nguồn) của 1 ứng dụng. Điều này là do trình biên dịch mới giờ đã có thể nhìn vào tổng thể toàn bộ mã nguồn, trong khi trình biên dịch JIT hiện tại chỉ có thể tối ưu mã trên phạm vi method/local (trong một hàm nhất định). Nhờ đó, các đoạn code sẽ có thể lược bỏ các đoạn mã "phụ", ví dụ như check exception (kiểm tra và bắt trước các lỗi có thể xảy ra trong quá trình chạy). Quá trình gọi hàm hoặc gọi interface cũng sẽ nhanh hơn đáng kể. Quá trình này sẽ được thực hiện bên trong phần mềm "dex2oat" – phiên bản thay thế cho dexopt trên Dalvik. Các file odex (file dex đã được tối ưu) cũng sẽ bị thay thế bằng file ELF. Do ART biên dịch các file thực thi ELF, nhân của Android giờ có thể quản lý các trang của code page (tập ký tự mã hóa của 1 ngôn ngữ cụ thể) một cách hiệu quả hơn. Nhờ đó mà  hệ điều hành di động của Google có thể quản lý bộ nhớ tốt hơn và tốn ít RAM hơn.  Ảnh hưởng của ART tới thời lượng pin có lẽ cũng là rất đáng kể, do hệ điều hành không cần phải biên dịch mã nguồn trong quá trình chạy ứng dụng nữa. Nhờ đó, quá trình chạy ứng dụng sẽ giảm được đáng kể sức ép lên CPU, giúp tiết kiệm pin tốt hơn. Điểm yếu lớn nhất của ART so với ELF là quá trình biên dịch mã sẽ tốn nhiều thời gian hơn. Quá trình khởi động điện thoại cũng như lần bật ứng dụng đầu tiên sẽ tốn nhiều thời gian hơn so với ứng dụng tương đương trên Dalvik. Tuy vậy, theo tuyên bố của Google, phiên bản hoàn thiện sẽ có thời gian khởi động tương đương hoặc nhanh hơn Dalvik. Kể cả nếu gã khổng lồ tìm kiếm không thể thực hiện lời hứa này, người dùng thông thường cũng sẽ chỉ trong lần đầu cài đặt. Trải nghiệm sử dụng sau đó sẽ trở nên mượt mà hơn rất nhiều. Trong bức ảnh phía trên, bạn có thể thấy hiệu năng ứng dụng trên ART (màu đỏ) tốt hơn rất nhiều so với Dalvik (xanh). Thậm chí, ứng dụng Chessbench còn cho thấy mức độ cải thiện lên tới gần 3 lần. Theo tuyên bố của Google, đây sẽ là con số phản ánh chính xác thực tế khi Android L ra mắt chính thức vào tháng 10 sắp tới.

Thông thường, các hệ điều hành khác iOS, Windows hay Tizen sẽ chạy các phần mềm được biên dịch từ mã nguồn sang mã thực thi tương thích với kiến trúc phần cứng của hệ điều hành đó. Ví dụ, iOS chỉ có thể chạy trên vi xử lý kiến trúc ARM còn các phiên bản Windows lớn (XP, 7, 8…) chỉ có thể chạy trên kiến trúc x86.

Android không đi theo xu hướng này. Phần lớn các phần mềm trên Android đều được xây dựng bằng Java và sau đó được biên dịch thành "bytecode", tức là mã nguồn cho máy ảo Java. Trước đây, bytecode sẽ được chuyển tới máy ảo Dalvik để biên dịch một lần nữa thành các file thực thi .dex và .odex. Sau đó, các file thực thi này sẽ được chạy trên thiết bị của bạn.

Ban đầu, Dalvik chỉ là một máy ảo khá đơn giản. Song, khi các thiết bị di động ngày càng trở nên phức tạp hơn, Google sẽ cần phải giải quyết các vấn đề hiệu năng, bởi hiệu năng máy ảo sẽ luôn kém cỏi hơn rất nhiều so với chạy trực tiếp như trên iOS hay Windows. Đồng thời, do Dalvik là phần mềm chịu trách nhiệm thực thi gần như tất cả các ứng dụng Android, Google sẽ phải tìm cách giúp máy ảo Android của mình có thể bắt kịp với các tiến bộ của ngành công nghiệp phần cứng. Dần dần, Google đã trang bị cho Dalvik một bộ biên dịch JIT (Just-in-time: biên dịch mã nguồn ngay trước khi thực thi), khả năng chạy nhiều thread (chạy song song nhiều luồng) cùng vô số thay đổi nhỏ khác.

Tại sự kiện I/O diễn ra vào tháng 6, Google đã công bố rộng rãi kế hoạch ra mắt phần mềm runtime mới cho Android. Theo đó, Android RunTime – ART sẽ thay thế cho bộ máy ảo Dalvik cũ kỹ trên Android. Android RunTime là gì Thông thường, các hệ điều hành khác iOS, Windows hay Tizen sẽ chạy các phần mềm được biên dịch từ mã nguồn sang mã thực thi tương thích với kiến trúc phần cứng của hệ điều hành đó. Ví dụ, iOS chỉ có thể chạy trên vi xử lý kiến trúc ARM còn các phiên bản Windows lớn (XP, 7, 8…) chỉ có thể chạy trên kiến trúc x86.  Android không đi theo xu hướng này. Phần lớn các phần mềm trên Android đều được xây dựng bằng Java và sau đó được biên dịch thành "byte-code", tức là mã nguồn cho máy ảo Java. Trước đây, byte-code sẽ được chuyển tới máy ảo Dalvik để biên dịch một lần nữa thành các file thực thi .dex và .odex. Sau đó, các file thực thi này sẽ được chạy trên thiết bị của bạn. Ban đầu, Dalvik chỉ là một máy ảo khá đơn giản. Song, khi các thiết bị di động ngày càng trở nên phức tạp hơn, Google sẽ cần phải giải quyết các vấn đề hiệu năng (hiệu năng máy ảo sẽ luôn kém cỏi hơn rất nhiều so với chạy trực tiếp như trên iOS hay Windows). Đồng thời, do là phần mềm chịu trách nhiệm thực thi gần như tất cả các ứng dụng Android, Google sẽ phải tìm cách giúp máy ảo Android của mình có thể bắt kịp với các tiến bộ của ngành công nghiệp phần cứng. Dần dần, Google đã trang bị cho Dalvik một bộ biên dịch JIT (Just-in-time: biên dịch mã nguồn ngay trước khi thực thi), khả năng chạy nhiều thread (chạy song song nhiều luồng) cùng vô số thay đổi nhỏ khác. Tuy vậy, trong những năm vừa qua, tốc độ phát triển của hệ sinh thái Android đã vượt quá khả năng phát triển Dalvik. Do đó, Google cần phải xây dựng một phần mềm runtime (phần mềm chịu trách nhiệm chạy các ứng dụng khác) mới để làm cơ sở vững chắc cho tương lai. Cụ thể hơn, giải pháp phần mềm runtime mới của Google sẽ phải thích ứng với hiệu năng của cả các vi xử lý của ngày hôm nay cũng như các vi xử lý 8 nhân của những năm tới, có thể mở rộng thêm bộ nhớ và RAM của thiết bị. Từ đó, ART ra đời. Kiến trúc của ART Trước hết, ART được thiết kế để tương thích hoàn toàn với mô hình biên dịch bytecode của Dalvik. Do đó, khi nhìn từ góc độ nhà phát triển ứng dụng , bạn sẽ không cần phải viết mã nguồn riêng cho Dalvik rồi viết lại cho ART. Bạn không cần phải lo lắng gì về tính tương thích giữa 2 môi trường cả. Sự thay đổi lớn nhất về thiết kế mà ART mang tới là khả năng biên dịch code theo mô hình AOT (Ahead of Time) thay vì JIT (Just in Time) như trước đây. Điều này có ý nghĩa là gì? Bộ runtime mới của Android không còn cần phải dịch từ byte-code sang mã máy mỗi lần chạy ứng dụng. Thay vào đó, ART sẽ chỉ biên dịch byte-code sang mã máy đúng một lần. Quá trình thực thi ứng dụng trong các lần chạy tương lai sẽ được thực hiện từ các đoạn mã máy đã được tạo ra từ trước. Dĩ nhiên, việc biên dịch từ bytecode sang mã máy để chạy ứng dụng bất cứ khi nào bạn muốn sẽ đòi hỏi thêm bộ nhớ. Phương pháp cài đặt ứng dụng mới (biên dịch một lần) chỉ trở nên khả thi do bộ nhớ điện thoại đã được tăng lên rất nhiều so với trước đây – khi mà bộ nhớ Android chỉ dừng lại ở 2GB hoặc 4GB. Sự thay đổi này sẽ giúp mang tới các ứng dụng được tối ưu hơn. Đây thực sự là một bước tiến hoàn toàn nằm ngoài khả năng của Dalvik. Trên Android L, do mã nguồn sẽ được tối ưu và biên dịch sang mã máy đúng một lần duy nhất, chu trình tối ưu này sẽ cần phải được thực hiện rất tốt. Theo Google, Android giờ đã có thể đạt đến mức tối ưu tốt hơn đối với toàn bộ code-base (tất cả mã nguồn) của 1 ứng dụng. Điều này là do trình biên dịch mới giờ đã có thể nhìn vào tổng thể toàn bộ mã nguồn, trong khi trình biên dịch JIT hiện tại chỉ có thể tối ưu mã trên phạm vi method/local (trong một hàm nhất định). Nhờ đó, các đoạn code sẽ có thể lược bỏ các đoạn mã "phụ", ví dụ như check exception (kiểm tra và bắt trước các lỗi có thể xảy ra trong quá trình chạy). Quá trình gọi hàm hoặc gọi interface cũng sẽ nhanh hơn đáng kể. Quá trình này sẽ được thực hiện bên trong phần mềm "dex2oat" – phiên bản thay thế cho dexopt trên Dalvik. Các file odex (file dex đã được tối ưu) cũng sẽ bị thay thế bằng file ELF. Do ART biên dịch các file thực thi ELF, nhân của Android giờ có thể quản lý các trang của code page (tập ký tự mã hóa của 1 ngôn ngữ cụ thể) một cách hiệu quả hơn. Nhờ đó mà  hệ điều hành di động của Google có thể quản lý bộ nhớ tốt hơn và tốn ít RAM hơn.  Ảnh hưởng của ART tới thời lượng pin có lẽ cũng là rất đáng kể, do hệ điều hành không cần phải biên dịch mã nguồn trong quá trình chạy ứng dụng nữa. Nhờ đó, quá trình chạy ứng dụng sẽ giảm được đáng kể sức ép lên CPU, giúp tiết kiệm pin tốt hơn. Điểm yếu lớn nhất của ART so với ELF là quá trình biên dịch mã sẽ tốn nhiều thời gian hơn. Quá trình khởi động điện thoại cũng như lần bật ứng dụng đầu tiên sẽ tốn nhiều thời gian hơn so với ứng dụng tương đương trên Dalvik. Tuy vậy, theo tuyên bố của Google, phiên bản hoàn thiện sẽ có thời gian khởi động tương đương hoặc nhanh hơn Dalvik. Kể cả nếu gã khổng lồ tìm kiếm không thể thực hiện lời hứa này, người dùng thông thường cũng sẽ chỉ trong lần đầu cài đặt. Trải nghiệm sử dụng sau đó sẽ trở nên mượt mà hơn rất nhiều. Trong bức ảnh phía trên, bạn có thể thấy hiệu năng ứng dụng trên ART (màu đỏ) tốt hơn rất nhiều so với Dalvik (xanh). Thậm chí, ứng dụng Chessbench còn cho thấy mức độ cải thiện lên tới gần 3 lần. Theo tuyên bố của Google, đây sẽ là con số phản ánh chính xác thực tế khi Android L ra mắt chính thức vào tháng 10 sắp tới.

Tuy vậy, trong những năm vừa qua, tốc độ phát triển của hệ sinh thái Android đã vượt quá khả năng phát triển của Dalvik. Do đó, Google cần phải xây dựng một phần mềm runtime (phần mềm chịu trách nhiệm chạy các ứng dụng khác) hoàn toàn mới để làm cơ sở vững chắc cho tương lai. Cụ thể hơn, giải pháp phần mềm runtime mới của Google sẽ phải thích ứng với hiệu năng của cả các vi xử lý của ngày hôm nay cũng như các vi xử lý 8 nhân của những năm tới, có thể mở rộng thêm bộ nhớ và RAM của thiết bị.

Từ đó, ART ra đời.

Kiến trúc của ART

Tại sự kiện I/O diễn ra vào tháng 6, Google đã công bố rộng rãi kế hoạch ra mắt phần mềm runtime mới cho Android. Theo đó, Android RunTime – ART sẽ thay thế cho bộ máy ảo Dalvik cũ kỹ trên Android. Android RunTime là gì Thông thường, các hệ điều hành khác iOS, Windows hay Tizen sẽ chạy các phần mềm được biên dịch từ mã nguồn sang mã thực thi tương thích với kiến trúc phần cứng của hệ điều hành đó. Ví dụ, iOS chỉ có thể chạy trên vi xử lý kiến trúc ARM còn các phiên bản Windows lớn (XP, 7, 8…) chỉ có thể chạy trên kiến trúc x86.  Android không đi theo xu hướng này. Phần lớn các phần mềm trên Android đều được xây dựng bằng Java và sau đó được biên dịch thành "byte-code", tức là mã nguồn cho máy ảo Java. Trước đây, byte-code sẽ được chuyển tới máy ảo Dalvik để biên dịch một lần nữa thành các file thực thi .dex và .odex. Sau đó, các file thực thi này sẽ được chạy trên thiết bị của bạn. Ban đầu, Dalvik chỉ là một máy ảo khá đơn giản. Song, khi các thiết bị di động ngày càng trở nên phức tạp hơn, Google sẽ cần phải giải quyết các vấn đề hiệu năng (hiệu năng máy ảo sẽ luôn kém cỏi hơn rất nhiều so với chạy trực tiếp như trên iOS hay Windows). Đồng thời, do là phần mềm chịu trách nhiệm thực thi gần như tất cả các ứng dụng Android, Google sẽ phải tìm cách giúp máy ảo Android của mình có thể bắt kịp với các tiến bộ của ngành công nghiệp phần cứng. Dần dần, Google đã trang bị cho Dalvik một bộ biên dịch JIT (Just-in-time: biên dịch mã nguồn ngay trước khi thực thi), khả năng chạy nhiều thread (chạy song song nhiều luồng) cùng vô số thay đổi nhỏ khác. Tuy vậy, trong những năm vừa qua, tốc độ phát triển của hệ sinh thái Android đã vượt quá khả năng phát triển Dalvik. Do đó, Google cần phải xây dựng một phần mềm runtime (phần mềm chịu trách nhiệm chạy các ứng dụng khác) mới để làm cơ sở vững chắc cho tương lai. Cụ thể hơn, giải pháp phần mềm runtime mới của Google sẽ phải thích ứng với hiệu năng của cả các vi xử lý của ngày hôm nay cũng như các vi xử lý 8 nhân của những năm tới, có thể mở rộng thêm bộ nhớ và RAM của thiết bị. Từ đó, ART ra đời. Kiến trúc của ART Trước hết, ART được thiết kế để tương thích hoàn toàn với mô hình biên dịch bytecode của Dalvik. Do đó, khi nhìn từ góc độ nhà phát triển ứng dụng , bạn sẽ không cần phải viết mã nguồn riêng cho Dalvik rồi viết lại cho ART. Bạn không cần phải lo lắng gì về tính tương thích giữa 2 môi trường cả. Sự thay đổi lớn nhất về thiết kế mà ART mang tới là khả năng biên dịch code theo mô hình AOT (Ahead of Time) thay vì JIT (Just in Time) như trước đây. Điều này có ý nghĩa là gì? Bộ runtime mới của Android không còn cần phải dịch từ byte-code sang mã máy mỗi lần chạy ứng dụng. Thay vào đó, ART sẽ chỉ biên dịch byte-code sang mã máy đúng một lần. Quá trình thực thi ứng dụng trong các lần chạy tương lai sẽ được thực hiện từ các đoạn mã máy đã được tạo ra từ trước. Dĩ nhiên, việc biên dịch từ bytecode sang mã máy để chạy ứng dụng bất cứ khi nào bạn muốn sẽ đòi hỏi thêm bộ nhớ. Phương pháp cài đặt ứng dụng mới (biên dịch một lần) chỉ trở nên khả thi do bộ nhớ điện thoại đã được tăng lên rất nhiều so với trước đây – khi mà bộ nhớ Android chỉ dừng lại ở 2GB hoặc 4GB. Sự thay đổi này sẽ giúp mang tới các ứng dụng được tối ưu hơn. Đây thực sự là một bước tiến hoàn toàn nằm ngoài khả năng của Dalvik. Trên Android L, do mã nguồn sẽ được tối ưu và biên dịch sang mã máy đúng một lần duy nhất, chu trình tối ưu này sẽ cần phải được thực hiện rất tốt. Theo Google, Android giờ đã có thể đạt đến mức tối ưu tốt hơn đối với toàn bộ code-base (tất cả mã nguồn) của 1 ứng dụng. Điều này là do trình biên dịch mới giờ đã có thể nhìn vào tổng thể toàn bộ mã nguồn, trong khi trình biên dịch JIT hiện tại chỉ có thể tối ưu mã trên phạm vi method/local (trong một hàm nhất định). Nhờ đó, các đoạn code sẽ có thể lược bỏ các đoạn mã "phụ", ví dụ như check exception (kiểm tra và bắt trước các lỗi có thể xảy ra trong quá trình chạy). Quá trình gọi hàm hoặc gọi interface cũng sẽ nhanh hơn đáng kể. Quá trình này sẽ được thực hiện bên trong phần mềm "dex2oat" – phiên bản thay thế cho dexopt trên Dalvik. Các file odex (file dex đã được tối ưu) cũng sẽ bị thay thế bằng file ELF. Do ART biên dịch các file thực thi ELF, nhân của Android giờ có thể quản lý các trang của code page (tập ký tự mã hóa của 1 ngôn ngữ cụ thể) một cách hiệu quả hơn. Nhờ đó mà  hệ điều hành di động của Google có thể quản lý bộ nhớ tốt hơn và tốn ít RAM hơn.  Ảnh hưởng của ART tới thời lượng pin có lẽ cũng là rất đáng kể, do hệ điều hành không cần phải biên dịch mã nguồn trong quá trình chạy ứng dụng nữa. Nhờ đó, quá trình chạy ứng dụng sẽ giảm được đáng kể sức ép lên CPU, giúp tiết kiệm pin tốt hơn. Điểm yếu lớn nhất của ART so với ELF là quá trình biên dịch mã sẽ tốn nhiều thời gian hơn. Quá trình khởi động điện thoại cũng như lần bật ứng dụng đầu tiên sẽ tốn nhiều thời gian hơn so với ứng dụng tương đương trên Dalvik. Tuy vậy, theo tuyên bố của Google, phiên bản hoàn thiện sẽ có thời gian khởi động tương đương hoặc nhanh hơn Dalvik. Kể cả nếu gã khổng lồ tìm kiếm không thể thực hiện lời hứa này, người dùng thông thường cũng sẽ chỉ trong lần đầu cài đặt. Trải nghiệm sử dụng sau đó sẽ trở nên mượt mà hơn rất nhiều. Trong bức ảnh phía trên, bạn có thể thấy hiệu năng ứng dụng trên ART (màu đỏ) tốt hơn rất nhiều so với Dalvik (xanh). Thậm chí, ứng dụng Chessbench còn cho thấy mức độ cải thiện lên tới gần 3 lần. Theo tuyên bố của Google, đây sẽ là con số phản ánh chính xác thực tế khi Android L ra mắt chính thức vào tháng 10 sắp tới.

Trước hết, ART được thiết kế để tương thích hoàn toàn với mô hình biên dịch bytecode của Dalvik. Do đó, khi nhìn từ góc độ nhà phát triển ứng dụng, bạn sẽ không cần phải viết mã nguồn riêng cho Dalvik rồi viết lại cho ART. Bạn không cần phải lo lắng gì về tính tương thích giữa 2 môi trường này cả.

Sự thay đổi lớn nhất về thiết kế mà ART mang tới là khả năng biên dịch code theo mô hình AOT (Ahead of Time) thay vì JIT (Just in Time) như trước đây. Điều này có ý nghĩa là gì? Bộ runtime mới của Android không còn cần phải dịch từ bytecode sang mã máy mỗi lần chạy ứng dụng. Thay vào đó, ART sẽ chỉ biên dịch bytecode sang mã máy đúng một lần duy nhất. Quá trình thực thi ứng dụng trong các lần chạy tương lai sẽ được thực hiện từ các đoạn mã máy đã được tạo ra từ trước.

Dĩ nhiên, việc biên dịch từ bytecode sang mã máy để chạy ứng dụng bất cứ khi nào bạn muốn sẽ đòi hỏi thêm bộ nhớ. Phương pháp cài đặt ứng dụng mới (biên dịch một lần) chỉ trở nên khả thi do bộ nhớ điện thoại hiện nay đã được tăng lên rất nhiều so với trước đây. Hãy nhớ rằng vài năm trước, ngay cả smartphone Android cao cấp cũng chỉ có 2GB hoặc 4GB bộ nhớ.

Lợi ích của ART

Sự thay đổi này sẽ giúp mang tới các ứng dụng được tối ưu hơn. Đây thực sự là một bước tiến hoàn toàn nằm ngoài khả năng của Dalvik. Trên Android L, do mã nguồn sẽ được tối ưu và biên dịch sang mã máy đúng một lần duy nhất, chu trình tối ưu này sẽ cần phải được thực hiện rất tốt. Theo Google, Android giờ đã có thể đạt đến mức tối ưu tốt hơn đối với toàn bộ code-base (tất cả mã nguồn) của 1 ứng dụng. Điều này là do trình biên dịch mới giờ đã có thể nhìn vào tổng thể toàn bộ mã nguồn, trong khi trình biên dịch JIT hiện tại chỉ có thể tối ưu mã trên phạm vi method/local (trong một hàm nhất định).

Tại sự kiện I/O diễn ra vào tháng 6, Google đã công bố rộng rãi kế hoạch ra mắt phần mềm runtime mới cho Android. Theo đó, Android RunTime – ART sẽ thay thế cho bộ máy ảo Dalvik cũ kỹ trên Android. Android RunTime là gì Thông thường, các hệ điều hành khác iOS, Windows hay Tizen sẽ chạy các phần mềm được biên dịch từ mã nguồn sang mã thực thi tương thích với kiến trúc phần cứng của hệ điều hành đó. Ví dụ, iOS chỉ có thể chạy trên vi xử lý kiến trúc ARM còn các phiên bản Windows lớn (XP, 7, 8…) chỉ có thể chạy trên kiến trúc x86.  Android không đi theo xu hướng này. Phần lớn các phần mềm trên Android đều được xây dựng bằng Java và sau đó được biên dịch thành "byte-code", tức là mã nguồn cho máy ảo Java. Trước đây, byte-code sẽ được chuyển tới máy ảo Dalvik để biên dịch một lần nữa thành các file thực thi .dex và .odex. Sau đó, các file thực thi này sẽ được chạy trên thiết bị của bạn. Ban đầu, Dalvik chỉ là một máy ảo khá đơn giản. Song, khi các thiết bị di động ngày càng trở nên phức tạp hơn, Google sẽ cần phải giải quyết các vấn đề hiệu năng (hiệu năng máy ảo sẽ luôn kém cỏi hơn rất nhiều so với chạy trực tiếp như trên iOS hay Windows). Đồng thời, do là phần mềm chịu trách nhiệm thực thi gần như tất cả các ứng dụng Android, Google sẽ phải tìm cách giúp máy ảo Android của mình có thể bắt kịp với các tiến bộ của ngành công nghiệp phần cứng. Dần dần, Google đã trang bị cho Dalvik một bộ biên dịch JIT (Just-in-time: biên dịch mã nguồn ngay trước khi thực thi), khả năng chạy nhiều thread (chạy song song nhiều luồng) cùng vô số thay đổi nhỏ khác. Tuy vậy, trong những năm vừa qua, tốc độ phát triển của hệ sinh thái Android đã vượt quá khả năng phát triển Dalvik. Do đó, Google cần phải xây dựng một phần mềm runtime (phần mềm chịu trách nhiệm chạy các ứng dụng khác) mới để làm cơ sở vững chắc cho tương lai. Cụ thể hơn, giải pháp phần mềm runtime mới của Google sẽ phải thích ứng với hiệu năng của cả các vi xử lý của ngày hôm nay cũng như các vi xử lý 8 nhân của những năm tới, có thể mở rộng thêm bộ nhớ và RAM của thiết bị. Từ đó, ART ra đời. Kiến trúc của ART Trước hết, ART được thiết kế để tương thích hoàn toàn với mô hình biên dịch bytecode của Dalvik. Do đó, khi nhìn từ góc độ nhà phát triển ứng dụng , bạn sẽ không cần phải viết mã nguồn riêng cho Dalvik rồi viết lại cho ART. Bạn không cần phải lo lắng gì về tính tương thích giữa 2 môi trường cả. Sự thay đổi lớn nhất về thiết kế mà ART mang tới là khả năng biên dịch code theo mô hình AOT (Ahead of Time) thay vì JIT (Just in Time) như trước đây. Điều này có ý nghĩa là gì? Bộ runtime mới của Android không còn cần phải dịch từ byte-code sang mã máy mỗi lần chạy ứng dụng. Thay vào đó, ART sẽ chỉ biên dịch byte-code sang mã máy đúng một lần. Quá trình thực thi ứng dụng trong các lần chạy tương lai sẽ được thực hiện từ các đoạn mã máy đã được tạo ra từ trước. Dĩ nhiên, việc biên dịch từ bytecode sang mã máy để chạy ứng dụng bất cứ khi nào bạn muốn sẽ đòi hỏi thêm bộ nhớ. Phương pháp cài đặt ứng dụng mới (biên dịch một lần) chỉ trở nên khả thi do bộ nhớ điện thoại đã được tăng lên rất nhiều so với trước đây – khi mà bộ nhớ Android chỉ dừng lại ở 2GB hoặc 4GB. Sự thay đổi này sẽ giúp mang tới các ứng dụng được tối ưu hơn. Đây thực sự là một bước tiến hoàn toàn nằm ngoài khả năng của Dalvik. Trên Android L, do mã nguồn sẽ được tối ưu và biên dịch sang mã máy đúng một lần duy nhất, chu trình tối ưu này sẽ cần phải được thực hiện rất tốt. Theo Google, Android giờ đã có thể đạt đến mức tối ưu tốt hơn đối với toàn bộ code-base (tất cả mã nguồn) của 1 ứng dụng. Điều này là do trình biên dịch mới giờ đã có thể nhìn vào tổng thể toàn bộ mã nguồn, trong khi trình biên dịch JIT hiện tại chỉ có thể tối ưu mã trên phạm vi method/local (trong một hàm nhất định). Nhờ đó, các đoạn code sẽ có thể lược bỏ các đoạn mã "phụ", ví dụ như check exception (kiểm tra và bắt trước các lỗi có thể xảy ra trong quá trình chạy). Quá trình gọi hàm hoặc gọi interface cũng sẽ nhanh hơn đáng kể. Quá trình này sẽ được thực hiện bên trong phần mềm "dex2oat" – phiên bản thay thế cho dexopt trên Dalvik. Các file odex (file dex đã được tối ưu) cũng sẽ bị thay thế bằng file ELF. Do ART biên dịch các file thực thi ELF, nhân của Android giờ có thể quản lý các trang của code page (tập ký tự mã hóa của 1 ngôn ngữ cụ thể) một cách hiệu quả hơn. Nhờ đó mà  hệ điều hành di động của Google có thể quản lý bộ nhớ tốt hơn và tốn ít RAM hơn.  Ảnh hưởng của ART tới thời lượng pin có lẽ cũng là rất đáng kể, do hệ điều hành không cần phải biên dịch mã nguồn trong quá trình chạy ứng dụng nữa. Nhờ đó, quá trình chạy ứng dụng sẽ giảm được đáng kể sức ép lên CPU, giúp tiết kiệm pin tốt hơn. Điểm yếu lớn nhất của ART so với ELF là quá trình biên dịch mã sẽ tốn nhiều thời gian hơn. Quá trình khởi động điện thoại cũng như lần bật ứng dụng đầu tiên sẽ tốn nhiều thời gian hơn so với ứng dụng tương đương trên Dalvik. Tuy vậy, theo tuyên bố của Google, phiên bản hoàn thiện sẽ có thời gian khởi động tương đương hoặc nhanh hơn Dalvik. Kể cả nếu gã khổng lồ tìm kiếm không thể thực hiện lời hứa này, người dùng thông thường cũng sẽ chỉ trong lần đầu cài đặt. Trải nghiệm sử dụng sau đó sẽ trở nên mượt mà hơn rất nhiều. Trong bức ảnh phía trên, bạn có thể thấy hiệu năng ứng dụng trên ART (màu đỏ) tốt hơn rất nhiều so với Dalvik (xanh). Thậm chí, ứng dụng Chessbench còn cho thấy mức độ cải thiện lên tới gần 3 lần. Theo tuyên bố của Google, đây sẽ là con số phản ánh chính xác thực tế khi Android L ra mắt chính thức vào tháng 10 sắp tới.

Nhờ đó, các đoạn code sẽ có thể lược bỏ các đoạn mã có thể bị coi là thừa nhưng vẫn bắt buộc phải có nếu sử dụng kiến trúc cũ, ví dụ như check exception (kiểm tra và bắt trước các lỗi có thể xảy ra trong quá trình chạy). Quá trình gọi hàm hoặc gọi interface cũng sẽ nhanh hơn đáng kể. Quá trình này sẽ được thực hiện bên trong phần mềm "dex2oat" – phiên bản thay thế cho dexopt trên Dalvik. Các file odex (file dex đã được tối ưu) cũng sẽ bị thay thế bằng file ELF.

Do ART biên dịch các file thực thi ELF, nhân của Android giờ có thể quản lý các trang của code page (tập mã hóa ký tự của 1 ngôn ngữ) một cách hiệu quả hơn. Nhờ đó mà; hệ điều hành di động của Google có thể quản lý bộ nhớ tốt hơn và tốn ít RAM hơn.

Ảnh hưởng của ART tới thời lượng pin có lẽ cũng là rất đáng kể, do hệ điều hành không cần phải biên dịch mã nguồn trong quá trình chạy ứng dụng nữa. Nhờ đó, quá trình chạy ứng dụng sẽ giảm được đáng kể sức ép lên CPU, giúp tiết kiệm pin tốt hơn.

Điểm yếu lớn nhất của ART so với ELF là quá trình biên dịch mã sẽ tốn nhiều thời gian hơn. Do đó, quá trình khởi động điện thoại cũng như lần bật ứng dụng đầu tiên sẽ tốn nhiều thời gian hơn so với ứng dụng tương đương trên Dalvik. Tuy vậy, theo tuyên bố của Google, phiên bản hoàn thiện sẽ có thời gian khởi động tương đương hoặc nhanh hơn Dalvik. Kể cả nếu gã khổng lồ tìm kiếm không thể thực hiện lời hứa này, người dùng thông thường cũng sẽ chỉ phải tốn thêm thời gian chờ đợi trong lần đầu cài đặt. Trải nghiệm sử dụng sau đó sẽ trở nên mượt mà hơn rất nhiều.

Tại sự kiện I/O diễn ra vào tháng 6, Google đã công bố rộng rãi kế hoạch ra mắt phần mềm runtime mới cho Android. Theo đó, Android RunTime – ART sẽ thay thế cho bộ máy ảo Dalvik cũ kỹ trên Android. Android RunTime là gì Thông thường, các hệ điều hành khác iOS, Windows hay Tizen sẽ chạy các phần mềm được biên dịch từ mã nguồn sang mã thực thi tương thích với kiến trúc phần cứng của hệ điều hành đó. Ví dụ, iOS chỉ có thể chạy trên vi xử lý kiến trúc ARM còn các phiên bản Windows lớn (XP, 7, 8…) chỉ có thể chạy trên kiến trúc x86.  Android không đi theo xu hướng này. Phần lớn các phần mềm trên Android đều được xây dựng bằng Java và sau đó được biên dịch thành "byte-code", tức là mã nguồn cho máy ảo Java. Trước đây, byte-code sẽ được chuyển tới máy ảo Dalvik để biên dịch một lần nữa thành các file thực thi .dex và .odex. Sau đó, các file thực thi này sẽ được chạy trên thiết bị của bạn. Ban đầu, Dalvik chỉ là một máy ảo khá đơn giản. Song, khi các thiết bị di động ngày càng trở nên phức tạp hơn, Google sẽ cần phải giải quyết các vấn đề hiệu năng (hiệu năng máy ảo sẽ luôn kém cỏi hơn rất nhiều so với chạy trực tiếp như trên iOS hay Windows). Đồng thời, do là phần mềm chịu trách nhiệm thực thi gần như tất cả các ứng dụng Android, Google sẽ phải tìm cách giúp máy ảo Android của mình có thể bắt kịp với các tiến bộ của ngành công nghiệp phần cứng. Dần dần, Google đã trang bị cho Dalvik một bộ biên dịch JIT (Just-in-time: biên dịch mã nguồn ngay trước khi thực thi), khả năng chạy nhiều thread (chạy song song nhiều luồng) cùng vô số thay đổi nhỏ khác. Tuy vậy, trong những năm vừa qua, tốc độ phát triển của hệ sinh thái Android đã vượt quá khả năng phát triển Dalvik. Do đó, Google cần phải xây dựng một phần mềm runtime (phần mềm chịu trách nhiệm chạy các ứng dụng khác) mới để làm cơ sở vững chắc cho tương lai. Cụ thể hơn, giải pháp phần mềm runtime mới của Google sẽ phải thích ứng với hiệu năng của cả các vi xử lý của ngày hôm nay cũng như các vi xử lý 8 nhân của những năm tới, có thể mở rộng thêm bộ nhớ và RAM của thiết bị. Từ đó, ART ra đời. Kiến trúc của ART Trước hết, ART được thiết kế để tương thích hoàn toàn với mô hình biên dịch bytecode của Dalvik. Do đó, khi nhìn từ góc độ nhà phát triển ứng dụng , bạn sẽ không cần phải viết mã nguồn riêng cho Dalvik rồi viết lại cho ART. Bạn không cần phải lo lắng gì về tính tương thích giữa 2 môi trường cả. Sự thay đổi lớn nhất về thiết kế mà ART mang tới là khả năng biên dịch code theo mô hình AOT (Ahead of Time) thay vì JIT (Just in Time) như trước đây. Điều này có ý nghĩa là gì? Bộ runtime mới của Android không còn cần phải dịch từ byte-code sang mã máy mỗi lần chạy ứng dụng. Thay vào đó, ART sẽ chỉ biên dịch byte-code sang mã máy đúng một lần. Quá trình thực thi ứng dụng trong các lần chạy tương lai sẽ được thực hiện từ các đoạn mã máy đã được tạo ra từ trước. Dĩ nhiên, việc biên dịch từ bytecode sang mã máy để chạy ứng dụng bất cứ khi nào bạn muốn sẽ đòi hỏi thêm bộ nhớ. Phương pháp cài đặt ứng dụng mới (biên dịch một lần) chỉ trở nên khả thi do bộ nhớ điện thoại đã được tăng lên rất nhiều so với trước đây – khi mà bộ nhớ Android chỉ dừng lại ở 2GB hoặc 4GB. Sự thay đổi này sẽ giúp mang tới các ứng dụng được tối ưu hơn. Đây thực sự là một bước tiến hoàn toàn nằm ngoài khả năng của Dalvik. Trên Android L, do mã nguồn sẽ được tối ưu và biên dịch sang mã máy đúng một lần duy nhất, chu trình tối ưu này sẽ cần phải được thực hiện rất tốt. Theo Google, Android giờ đã có thể đạt đến mức tối ưu tốt hơn đối với toàn bộ code-base (tất cả mã nguồn) của 1 ứng dụng. Điều này là do trình biên dịch mới giờ đã có thể nhìn vào tổng thể toàn bộ mã nguồn, trong khi trình biên dịch JIT hiện tại chỉ có thể tối ưu mã trên phạm vi method/local (trong một hàm nhất định). Nhờ đó, các đoạn code sẽ có thể lược bỏ các đoạn mã "phụ", ví dụ như check exception (kiểm tra và bắt trước các lỗi có thể xảy ra trong quá trình chạy). Quá trình gọi hàm hoặc gọi interface cũng sẽ nhanh hơn đáng kể. Quá trình này sẽ được thực hiện bên trong phần mềm "dex2oat" – phiên bản thay thế cho dexopt trên Dalvik. Các file odex (file dex đã được tối ưu) cũng sẽ bị thay thế bằng file ELF. Do ART biên dịch các file thực thi ELF, nhân của Android giờ có thể quản lý các trang của code page (tập ký tự mã hóa của 1 ngôn ngữ cụ thể) một cách hiệu quả hơn. Nhờ đó mà  hệ điều hành di động của Google có thể quản lý bộ nhớ tốt hơn và tốn ít RAM hơn.  Ảnh hưởng của ART tới thời lượng pin có lẽ cũng là rất đáng kể, do hệ điều hành không cần phải biên dịch mã nguồn trong quá trình chạy ứng dụng nữa. Nhờ đó, quá trình chạy ứng dụng sẽ giảm được đáng kể sức ép lên CPU, giúp tiết kiệm pin tốt hơn. Điểm yếu lớn nhất của ART so với ELF là quá trình biên dịch mã sẽ tốn nhiều thời gian hơn. Quá trình khởi động điện thoại cũng như lần bật ứng dụng đầu tiên sẽ tốn nhiều thời gian hơn so với ứng dụng tương đương trên Dalvik. Tuy vậy, theo tuyên bố của Google, phiên bản hoàn thiện sẽ có thời gian khởi động tương đương hoặc nhanh hơn Dalvik. Kể cả nếu gã khổng lồ tìm kiếm không thể thực hiện lời hứa này, người dùng thông thường cũng sẽ chỉ trong lần đầu cài đặt. Trải nghiệm sử dụng sau đó sẽ trở nên mượt mà hơn rất nhiều. Trong bức ảnh phía trên, bạn có thể thấy hiệu năng ứng dụng trên ART (màu đỏ) tốt hơn rất nhiều so với Dalvik (xanh). Thậm chí, ứng dụng Chessbench còn cho thấy mức độ cải thiện lên tới gần 3 lần. Theo tuyên bố của Google, đây sẽ là con số phản ánh chính xác thực tế khi Android L ra mắt chính thức vào tháng 10 sắp tới.

Trong bức ảnh phía trên, bạn có thể thấy hiệu năng ứng dụng trên ART (màu đỏ) tốt hơn rất nhiều so với Dalvik (xanh). Thậm chí, ứng dụng Chessbench còn cho thấy mức độ cải thiện lên tới gần 3 lần. Theo tuyên bố của Google, đây sẽ là con số phản ánh chính xác thực tế khi Android L ra mắt chính thức vào tháng 10 sắp tới.

Lê Hoàng

Theo AnandTech

Chủ đề khác