IceTea Việt | Lập trình cuộc sống

Chào các bạn!

Khi bắt đầu với lập trình Android, chúng ta đều được học rằng KHÔNG THỂ truyền tham chiếu của một đối tượng (object references) tới các Activity hoặc fragment. Để đối mặt với vấn đề khó khăn này chúng ta phải "gói" chúng vào một Intent/Bundle.

Truyền những tham số có kiểu nguyên thủy (primitive data types) như là string, integer, float,... qua Intents thì khá dễ dàng trong Android. Tất cả những gì bạn cần làm là "put" dữ liệu với một key duy nhất làm từ khóa vào Intent và gửi nó đến một Activity bất kỳ.

Nhìn vào API, ta nhận ra rằng có hai cách để truyền Java object qua Intent: một là implements Java class đó từ Percelable interface, hai là implements từ Serializable interface. Là một lập trình viên Java/C# chúng ta chắc hẳn đã biết rõ cơ chế hoạt động của Serializable, vậy tại sao ta lại phải bận tâm với Parcelable?

Để trả lời câu hỏi đó, hay tiếp cận rõ hơn để xem tại sao như vậy nhé!




SERIALIZABLE - BẬC THẦY CỦA SỰ ĐƠN GIẢN

Serializable là một interface chuẩn của Java. Vẻ đẹp của Serializable là việc bạn đơn giản chỉ cần đánh dấu một class Serializable bằng cách implements interface đó lên nó và các class con của nó, sau đó máy ảo Java (Java Virtual Machine) sẽ tự động serialize class theo từng trường hợp khác nhau. Đây là một marker interface, nghĩa là không cần phải cài đặt lại bất cứ method nào của khi implements.


Vấn đề xảy ra với hướng tiếp cận này là Java Reflection được sử dụng, và nó làm tiến trình của phần mềm bị chậm đi. Cơ chế này thường hay tạo rất nhiều đối tượng tạm (temporary object) và khi đó cơ chế dọn rác Garbage Collection của Java sẽ hoạt động và tốn tài nguyên máy tính.


PARCELABLE - ÔNG VUA TỐC ĐỘ

Parcelable là một interface riêng của Android, nơi mà bạn phải tự cài đặt các hàm serialization một cách thủ công mà không được sự hỗ trợ từ JVM. Parcelable được tạo ra cải tiến từ Serializable, nó hiệu quả hơn và khắc phục được một số vấn đề tồn tại ở Java Serializable, đó là lý do tại sao đa phần lập trình viên Android ưu tiên sử dụng Parcelable hơn là Serializable.


Theo những gì mình đọc trên StackOverflow, hay theo các google engineers thì đoạn code trên sẽ chắc chắn thực thi nhanh hơn. Một trong các lý do đó là chúng ta đã cài đặt tường minh các hàm thể hiện quá trình serialization thay vì sử dụng Java Reflection. Khi tối ưu hóa như vậy thì cơ chế dọn rác GC của Java sẽ làm việc ít hơn làm chương trình "nhanh" hơn.

Tuy nhiên, rõ ràng cái gì cũng có cái giá của nó. Với hướng tiếp cận này chúng ta sẽ sinh ra một "đống" code khá phức tạp và làm cho những class này rất khó đọc và fix bug, bảo trì.


KẾT QUẢ KIỂM TRA TỐC ĐỘ

Dĩ nhiên, chúng ta đều muốn biết Parcelable nhanh hơn tới mức nào!

Phương pháp:
- Mô phỏng quá trình truyền object vào activity
- Chạy quá trình đó trong vòng lặp 1000 lần
- Chạy trung bình 10 lần khác nhau để tính dung lượng bộ nhớ, cpu chiếm dụng,..
- Các object được test là HCMUSDeveloper và IceTeaVietDeveloper ở trên.
- Test trong nhiều thiết bị android (LG Nexus 4 - Android 4.2.2, Samsung Nexus 10 - Android 4.2.2, HTC Desire Z - Android 2.3.3)

Kết quả:

Thời gian thực thi của bộ test (hình ảnh và dữ liệu theo developerphil.com)

Nexus 10
Serializable: 1.0004ms, Parcelable: 0.0850ms - 10.16x improvement.

Nexus 4
Serializable: 1.8539ms - Parcelable: 0.1824ms - 11.80x improvement.

Desire Z
Serializable: 5.1224ms - Parcelable: 0.2938ms - 17.36x improvement.


TỔNG KẾT

Trong ví dụ trên, Android Parcelable tỏ ra nhanh hơn nhiều so với kỹ thuật Java Serializable. Một trong những lý do chính là do Parcelable hoàn toàn tùy chỉnh code, cho phép lập trình viên convert dữ liệu cần thiết thành Parcel trong khi Serialazation convert đối tượng thành một data stream sử dụng Java Reflection API.

Nếu bạn muốn trở thành một lập trình viên giỏi, hãy bỏ thời gian để cài đặt Parcelable bởi vì nó có thể thực thi nhanh hơn từ 4 - 10 lần và sử dụng ít tài nguyên hơn, khiến GC hoạt động ít hơn.

Tuy nhiên trong nhiều trường hợp, sự "chậm chạp" của Serializable không đáng nhắc tới. Hãy thoải mái sử dụng nó đối với những class nhỏ, nhưng hãy nhớ là nó luôn "ngốn tài nguyên" nên hãy giảm thiểu đến mức đáng kể khi cần những đoạn code đẹp - dễ đọc và bảo trì. Còn nếu bạn đang muốn truyền một List với hàng nghìn object, thì sự "chậm chạp" đó sẽ lên tới con số nhiều giây. Và khi đó chuyển động giao diện cũng như hiệu năng của ứng dụng sẽ trở nên khá tồi tệ và đó cũng là lúc bạn cần dùng đến vị cứu tinh dành riêng cho lập trình viên Android - Parcelable.

________________________________________________________________________

Trên là những chia sẻ của mình về hai hướng tiếp cận cho việc truyền object ref. Cảm ơn các bạn đã theo dõi, chúc các bạn học tốt và hãy để lại bình luận bên dưới nhé! 
Bonus cho các bạn 1 tấm hình từ slide của anh Huynh Q. Thao về những tip trong Android Perfomance, đó cũng là lý do và động lực để mình viết bài này :D

Bất cứ nơi đâu chúng ta đến, ta đều bị vây quanh bởi những thiết kế tồi tệ - từ chỗ ngồi của máy bay làm biến dạng tư thế ngồi của chúng ta đến một chiếc xe máy với thiết kế khiếm nhã. Những cảnh quan đã từng là màu xanh của sự sống và bây giờ một màu xám xịt đang dần phủ lên. Môi trường xung quanh của chúng ta chứa đầy những cơ hội bị bỏ lỡ để đem đến sự hài lòng, phấn khích và niềm vui cho cuộc sống con người!

Chỗ ngồi máy bay làm biến dạng tư thế ngồi

Những đồ vật với thiết kế tồi tệ làm chúng ta chậm lại, và làm phiền lòng mọi người - giống như tòa nhà xấu xí của ông hàng xóm làm bạn nhăn nhó mỗi khi nhìn thấy nó, hay cái remote TV với quá nhiều nút bấm, hay chỉ là một phần mềm không thể hoạt động đúng như chức năng của nó.
Những thứ như vậy đa phần là hậu quả của sự hiểu lầm, tham lam, không đồng cảm, thiếu tập trung. Những thiết kế tồi tệ đặc biệt làm phiền lòng con người khi ảnh hưởng rất nhiều tới hành tinh xanh này. Nói có hơi quá, nhưng đôi khi nó có vẻ như đang lấp đầy thế giới này bằng rác rưởi linh tinh.



Cùng với sự trưởng thành của nền công nghiệp thông tin, chúng ta đã chứng kiến sự quan tâm và đầu tư nhiều hơn cho việc thiết kế. Nhiều công ty hiện giữ vững quan điểm cho rằng thiết kế có thể trở thành lợi thế trong việc cạnh tranh với các đối thủ khác. Những hiểu biết của con người về ý nghĩa của "thiết kế" ngày càng trở nên sâu sắc qua từng năm tháng, vượt qua cả thẩm mỹ để đến với những kỹ năng giải quyết vấn đề. Trong những thập kỷ gần đây, trong ngành công nghiệp phần mềm chúng ta cho rằng một sản phẩm là "thiết kế toàn diện" khi sản phầm đó được cho rằng hữu dụng, dễ dùng và hấp dẫn khách hàng. Chúng ta có thể làm tốt hơn vậy - chúng ta cần làm tốt hơn vậy!

Tôi đang muốn ám chỉ điều gì? Trước khi chúng ta đi sâu vào vấn đề, hay để tôi cung cấp cho bạn một vài bối cảnh bằng cách quay trở lại và review những cấp độ khác nhau mà thiết kế có thể được hiểu.


Thiết kế = Hình mẫu

Hầu hết mọi người đều cho rằng thiết kế thì thường liên quan đến thẩm mỹ. Những nguyên tắc phổ quát của cái đẹp, như là Tỉ lệ vàng (Golden Ratio), quy tắc 1/3 (Rule of Thirds) hay là những quy tắc của sự tương đối, căn chỉnh liên kết, tương phản và sự lặp lại thông báo cho tiềm thức của chúng ta rằng vật đó có đẹp hay không. Ở mức độ hiểu biết này đối với thiết kế, chúng ta sẽ nghĩ rằng thiết kế là vẻ ngoài của đồ vật, ví dụ như chiếc xe hơi trông có vẻ chạy nhanh, có vẻ đắt hay có vẻ rất cứng cáp,...




Thiết kế = Chức năng

Tuy nhiên thiết kế không phải chỉ là vật thế đó trông như thế nào mà còn là nó hoạt động như thế nào. Chúng ta xem một vật thể là "thiết kế toàn diện" không chỉ khi nó đẹp mà còn khi nó dễ sử dụng. Thiết kế tốt sẽ giúp cuộc sống chúng ta dễ dàng hơn. tiết kiệm thời gian hơn, và giúp ta không cần phải suy nghĩ nhiều, từ đó giảm thiểu stress trong cuộc sống và giữ gìn ý chí và thiện chí đối với những người xung quanh. Trong trường hợp này, thiết kế  giống như là một cái tủ lạnh - khi nó hoạt động thì mảy may chẳng ai chú ý, nhưng khi nó ngừng hoạt động thì mọi thứ trở nên tệ hại cả lên!

Ở bài tiếp theo mình sẽ đưa đến một khía cạnh hoàn toàn khác của thiết kế, các bạn hay đón xem nhé!