10 Lỗi phổ biến của lập trình viên Android (phần 1)
Android là một nền tảng được nhiều người ưa thích, vừa miễn phí vừa dễ tùy biến nên đã nhanh chóng phát triển và có mặt trên nhiều loại thiết bị như điện thoại, máy tính bảng, đồng hồ thông minh, tivi, ô tô.Sau sự ra mắt của AOSP và bản update Lollipop, Android đã mang lại cho người dùng khá nhiều kì vọng. Phong cách thiết kế Material hứa hẹn đem lại trải nghiệm tốt hơn.Có cả ngàn thiết bị Android khác nhau kích thước màn hình, chip xử lý, cấu hình phần cứng và phiên bản phần mềm. Sự đa dạng ấy dẫn tới việc ứng dụng Android mà bạn viết có thể không hoạt động được trên các thiết bị khác nhau cho dù bạn có là một lập trình viên Android già dặn.Bỏ qua sự khác biệt kia, phần lớn lỗi mọi người biết đến lại là lỗi logic. Những lỗi này có thể dễ dàng xử lý nếu chúng ta làm đúng từ những điều cơ bản.Dưới đây là danh sách 10 lỗi thường thấy mà các lập trình viên Android tạo ra.
Lỗi đầu tiên: cố gắng bắt chiếc giao diện iOS
Thật may là hiện nay lỗi này đã trở nên ít phổ biến hơn (một phần vì khách hàng đã nhận ra rằng Apple đã thiết lập những tiêu chuẩn thiết kế từ lâu rồi). Nhưng dù có thế thì chúng ta vẫn đang và sẽ tiếp tục thấy những ứng dụng sao chép lại từ iOS.
Người dùng Android đã quen thuộc với nền tảng này, việc cố gắng nhồi nhét các chuẩn thiết kế của iOS vào sẽ rất tồi tệ. Nếu bạn không có lí do cực kì đáng giá nào để phá vỡ các nguyên tắc thì đừng làm thế.
Đây là một số ví dụ phổ biến cho lỗi này:
+) Bạn không nên tạo các tab cố định mà chúng không ở phía dưới (ví dụ: Instagram).
+) Các Icon thông báo hệ thống không nên màu mè
+) Icon của ứng dụng không nên có khung viền chữ nhật bo góc (trừ khi logo của bạn vốn đã có nó, ví dụ như Facebook)
+) Màn hình load ứng dụng (splash screen) chỉ nên dùng khi thiết lập lần đầu hoặc giới thiệu, không nền dùng trong các trường hợp khác.
+) Danh sách không nên có đánh dấu
Trên đây chỉ là một số ít trong số rất nhiều vấn đề lặt vặt có thể phá hỏng trải nghiệm người dùng.
Lỗi thứ hai: Chỉ lập trình và thử trên đúng thiết bị Android bạn có
Trừ khi bạn muốn tạo ra một ứng dụng phổ biến cho riêng loại thiết bị nào đó, nếu không thì ứng dụng của bạn có thể sẽ trông khá tệ trên các thiết bị khác. Bạn nên lưu ý các vấn đề sau:
+) Density-independent pixels (dp) khác với pixel (px).
+) Resources được thêm nhiều lần vào tài khoản đối với mật độ và định hướng khác nhau.
+) 9-patch drawables sẽ được kéo dãn cho khít với màn hình.
Chắc chắn bạn không có cả ngàn thiết bị để thử, Android Emulator sẽ giúp giả lập gần đúng cấu hình thiết bị bạn muốn thử. Android Emulator có thể chọn được kích thước màn hình, bộ nhớ, chức năng cảm biến.... Còn nếu bạn muốn một trình giả lập tốt hơn nữa, hãy thử Genymotion, emulator chạy nhanh và có nhiều cài đặt giả lập phổ biến cho các thiết bị.
Còn một vấn đề nữa, bạn có thử xoay ngang dọc điện thoại hoặc emulator khi chạy thử ứng dụng chưa? Bạn sẽ thấy ngay rất nhiều lỗi giao diện phải sửa.
Lỗi thứ ba: không dùng Intent
Intent là một trong những thành phần chủ chốt của Android. Nó là một cách để truyền dữ liệu giữa các phần của một ứng dụng hoặc hơn thế nữa, giữa các ứng dụng khác nhau trong một hệ thống.
Giả sử bạn có một ứng dụng gallery ảnh cho phép chia sẻ link download ảnh qua SMS. Lựa chọn nào sau đây sẽ logic hơn?
Lựa chọn 1:
+) Yêu cầu cấp quyền SEND_SMS
<uses-permission android:name="android.permission.SEND_SMS" />
+) Viết code gửi SMS theo cách của bạn, sử dụng SmsManager
+) Giải thích cho người dùng vì sao ứng dụng của bạn cần truy cập các dịch phụ có thể tính phí và vì sao người dùng phải cấp quyền truy cập đó cho ứng dụng của bạn.
Lựa chọn 2:
+) Bắt đầu một SMS Intent và để việc gửi Sms cho một ứng dụng chuyên gửi Sms
Intent sendIntent = new Intent(Intent.ACTION_VIEW);
sendIntent.setData(Uri.parse("sms:" + telephoneNumber));
sendIntent.putExtra("sms_body", x);
startActivity(sendIntent);
Nếu bạn còn lưỡng lự thì câu trả lời là: cách thứ 2 là cách tốt nhất.
Phương pháp này có thể áp dụng với hầu hết mọi thứ, ví như: chia sẻ nội dung, chụp ảnh, quay video, chọn các liên lạc, thêm sự kiện, ...
Trừ trường hợp có một lý do hợp lý để tự làm phần chức năng bổ sung (ví dụ: camera có áp dụng các bộ lọc chỉnh ảnh), nếu không thì cứ dùng Intent. Nó sẽ tiết kiệm cực kì nhiều thời gian lập tình và giảm bớt các yêu cầu cấp quyền không cần thiết trong file AndroidManifest.xml.
Lỗi thứ tư: không dùng Fragments
Một thời gian trước trên Honeycomb, Android giới thiệu khái niệm Fragments. Bạn có thể xem nó như là các khối được xây dựng riêng biệt với vòng đời riêng trong một Activity. Nó hỗ trợ rất nhiều trong việc tối ưu cho các loại màn hình, đồng thời dễ dàng được quản lý bởi activity cha, có thể sử dụng lại, kết hợp và bố trí theo ý muốn.
Chạy từng activity riêng cho mỗi màn hình ứng dụng sẽ có hiệu quả rất tệ khi hệ thống phải cố lưu trữ chúng trong bộ nhớ lâu hết mức có thể. Tắt một cái trong số đó cũng không giải phóng các tài nguyên được sử dụng bởi những cái còn lại.
Nếu bạn không muốn đào sâu nghiên cứu về core Android hay phản đối việc sử dụng fragment thì bạn nên dùng fragments bất cứ khi nào có thể. Cơ bản thì fragments và cursor loaders có mục đích tốt nhưng cách thực hiện thì khá thô.
Lỗi thứ năm: Blocking Main Thread (tác vụ chạy lâu cản trở luồng thực thi chính)
Main thread (luống chính) có một mục đích duy nhất: phản hồi tương tác của người dùng và cập nhật giao diện.
Mặc dù theo các phương pháp đo đếm một cách khoa học về tốc độ khung hình (frame rate) thì mắt/não của chúng ta có khả năng cảm nhận rất phức tạp và chịu ảnh hưởng của nhiều yếu tố nhưng có một nguyên tắc chung là cứ cái gì dưới 24 fps (khung hình/giây) với độ trễ trên 100ms thì được coi là không mượt mà.
Có nghĩa là hành vi của người dùng sẽ có một khoảng trễ và ứng dụng Android mà bạn lập trình sẽ dừng việc phản hồi lại. Bỏ qua yếu tố cách sử dụng của người dùng dẫn tới ứng dụng chạy không như ý, người dùng của bạn chỉ cần thấy ứng dụng không chạy như họ muốn là sẽ có các nhận xét tiêu cực.
Tệ hơn nữa, nếu main thread bị block một lúc (5 giây đối với các Activity, 10 giây đối với Broadcast Receivers), ANR sẽ xảy ra. (Nếu bạn quan tâm ANR là cái gì, đọc thêm ở đây).
Vấn đề này từng rất phổ biến trên Android 2.x trong khi đó các phiên bản mới hơn của hệ thống không cho phép bạn tạo các lời gọi network trong main thread.
Để tránh bị lỗi này, tốt nhất là bạn luôn sử dụng worker/background thread cho các trường hợp sau: gọi network (network call), nạp hình ảnh (bitmap loading), xử lý ảnh (image processing), truy vấn dữ liệu (database querying), đọc/ghi vào thẻ nhớ (SD reading/writing).
BTV. Phạm Thị Mỹ Phương
Phòng Truyền Thông ImicroSoft Hồ Chí Minh
Hotline: 0916 878 224
Email: phuongptm@imicrosoft.edu.vn
Bạn đang muốn tìm kiếm 1 công việc với mức thu nhập cao.
✅ Hoặc là bạn đang muốn chuyển đổi công việc mà chưa biết theo học ngành nghề gì cho tốt.
✅ Giới thiệu với bạn Chương trình đào tạo nhân sự dài hạn trong 12 tháng với những điều đặc biệt mà chỉ có tại IMIC và đây cũng chính là sự lựa chọn phù hợp nhất dành cho bạn:
👉 Thứ nhất: Học viên được đào tạo bài bản kỹ năng, kiến thức chuyên môn lý thuyết, thực hành, thực chiến nhiều dự án và chia sẻ những kinh nghiệm thực tế từ Chuyên gia có nhiều năm kinh nghiệm dự án cũng như tâm huyết truyền nghề.
👉 Thứ hai: Được ký hợp đồng cam kết chất lượng đào tạo cũng như mức lương sau tốt nghiệp và đi làm tại các đối tác tuyển dụng của IMIC. Trả lại học phí nếu không đúng những gì đã ký kết.
👉 Thứ ba: Cam kết hỗ trợ giới thiệu công việc sang đối tác tuyển dụng trong vòng 10 năm liên tục.
👉 Thứ tư: Được hỗ trợ tài chính với mức lãi suất 0 đồng qua ngân hàng VIB Bank.
👉 Có 4 Chương trình đào tạo nhân sự dài hạn dành cho bạn lựa chọn theo học. Gồm có:
1) Data Scientist full-stack
2) Embedded System & IoT development full-stack
3) Game development full-stack
4) Web development full-stack
✅ Cảm ơn bạn đã dành thời gian lắng nghe những chia sẻ của mình. Và tuyệt vời hơn nữa nếu IMIC được góp phần vào sự thành công của bạn.
✅ Hãy liên hệ ngay với Phòng tư vấn tuyển sinh để được hỗ trợ về thủ tục nhập học.
✅ Chúc bạn luôn có nhiều sức khỏe và thành công!