Phát triển ứng dụng Android - 34 điều tôi đã rút ra được kinh nghiệm
Bài đăng này đã không được cập nhật trong 6 năm
Có hai loại người - những người học bằng cách trải qua những hậu quả của việc phạm sai lầm và những người học bằng cách lấy lời khuyên của ai đó. Dưới đây là một số điều tôi đã học được theo cách mà tôi muốn chia sẻ với bạn:
- Suy nghĩ kỹ trước khi thêm bất kỳ thư viện của bên thứ ba nào, đó là một sự ràng buộc thực sự nghiêm túc;
- Nếu người dùng không nhìn thấy nó, đừng vẽ nó !;
- Không sử dụng cơ sở dữ liệu trừ khi bạn thực sự cần;
- Đạt mức 65k method sẽ đến rất nhanh chóng, ý tôi là rất nhanh! Và multidexing có thể cứu bạn;
- RxJava là giải pháp thay thế tốt nhất cho AsyncTask và nhiều hơn thế nữa;
- Retrofit là thư viện networking tốt nhất;
- Rút ngắn mã của bạn với Retrolambda;
- Kết hợp RxJava với Retrofit và Retrolambda tạo nên sự tuyệt vời hơn !;
- Tôi sử dụng EventBus và nó rất tuyệt, nhưng tôi không sử dụng nó quá nhiều vì codebase sẽ thực sự lộn xộn
- Package theo tính năng, không phải lớp
- Di chuyển mọi thứ ra khỏi application thread
- lint views của bạn để giúp bạn tối ưu hóa các bố trí và bố trí hệ thống phân cấp để bạn có thể xác định views dư thừa có thể được gỡ bỏ;
- Nếu bạn đang sử dụng gradle, bạn có thể tăng tốc độ;
- Kiểm tra profile reports về các bản build của bạn để xem cái gì mất bao nhiêu thời gian build.
- Sử dụng một kiến trúc nổi tiếng;
- Quá trình kiểm thử cần có thời gian nhưng nhanh hơn và mạnh mẽ hơn mã hóa mà không cần kiểm tra khi bạn đã bị treo;
- Sử dụng tính năng dependency injection để làm cho ứng dụng của bạn thêm mô đun và do đó dễ kiểm hơn;
- Tham khảo trang fragmentedpodcast sẽ rất tuyệt vời cho bạn;
- Không bao giờ sử dụng email cá nhân của bạn cho tài khoản publisher trên Playstore ;
- Luôn sử dụng các loại input keyboard thích hợp;
- Sử dụng analytics để tìm các usage patterns và cách ly các lỗi;
- Luôn luôn cập nhật các thư viện mới (sử dụng dryrun để kiểm tra chúng ra nhanh hơn);
- Các services của bạn nên làm những gì nó cần làm và hủy chúng càng nhanh càng tốt;
- Sử dụng Account Manager để đề xuất tên người dùng và địa chỉ email đăng nhập;
- Sử dụng CI (Continuous Integration) để xây dựng và phân phối bản beta và sản xuất của bạn .apk’s;
- Không chạy máy chủ CI của riêng bạn, bởi vì việc disk space/security issues/updating máy chủ để bảo vệ khỏi các cuộc tấn công SSL, v.v. Sử dụng circleci, travis hoặc shippable, chúng rẻ và ít hơn lo lắng về những thứ khác;
- Tự động hóa các triển khai của bạn đến playstore;
- Nếu một thư viện lớn và bạn chỉ sử dụng một tập nhỏ các hàm của nó, bạn nên tìm một tùy chọn nhỏ hơn thay thế (dựa vào proguard chẳng hạn);
- Không sử dụng nhiều mô-đun hơn bạn thực sự cần. Nếu các mô-đun đó không được sửa đổi liên tục, điều quan trọng là phải cân nhắc rằng thời gian cần thiết để compile chúng từ đầu (xây dựng CI là một ví dụ tốt), hoặc thậm chí để kiểm tra xem việc xây dựng mô-đun cá nhân trước đó có được cập nhật hay không lên đến gần gấp 4 lần so với việc đơn giản là tải dependency đó dưới dạng tệp .jar / .aar nhị phân.
- Bắt đầu suy nghĩ về việc thay các PNG cho SVG;
- Tạo library abstraction classes, sẽ dễ dàng chuyển sang thư viện mới nếu bạn chỉ cần chuyển đổi ở một nơi (ví dụ: AppLogger.d (“message”) có thể chứa Log.d (TAG, message) và sau đó nhận ra rằng Timber.d (message) là một lựa chọn tốt hơn);
- Theo dõi power source và battery (có thể follow theo trường hợp như cập nhật dữ liệu nhiều hơn trong khi sạc, tạm dừng cập nhật khi pin yếu);
- Giao diện người dùng thật nực cười. Nếu bạn phải giải thích nó về việc nó phải dùng như thế nào, nó có nghĩa là giao diện của bạn không tốt;
- Các cách thử nghiệm rất tốt cho performance: Viết từ từ thôi (nhưng chính xác), sau đó tìm cách tối ưu hóa không làm hỏng bất kỳ điều gì với các bài test;
Bài viết được dịch theo nguồn: https://medium.com/@cesarmcferreira/building-android-apps-30-things-that-experience-made-me-learn-the-hard-way-313680430bf9 Người dịch: Nguyễn Khuyến.
All rights reserved