#lamapp

Tôi vẫn nhớ ngày đó, năm 2014, khi tôi quyết định dấn thân vào lập trình Android, và đó là một trong những quyết định thành công nhất trong đời tôi. Với hai năm rưỡi trong ngành, tôi đã có cơ hội học tập và nhận ra nhiều điều về Android.

Khi mới bắt đầu, vì không có đàn anh nào chỉ dẫn cả, nên tôi phạm rất nhiều lỗi và mất rất nhiều thời kì mò mẫm.

Một năm rưỡi sau, khi đã có thời cơ được tiếp xúc và học tập từ một số lập trình viên Android rất nhân tài và kinh nghiệm, giai đoạn này tôi học được nhiều hơn và nhanh hơn. Qua cả hai thời đoạn, tôi dần biết được mình NÊN và đặc biệt là KHÔNG NÊN LÀM gì.

Tôi vẫn nhớ ngày đó, năm 2014, khi tôi quyết định dấn thân vào lập trình Android, lúc đó tôi chưa biết lập trình app Với hai năm rưỡi trong ngành, tôi đã có cơ hội học tập và nhận ra nhiều điều về Android.

Khi mới khởi đầu, vì không có đàn anh nào hướng dẫn cả, nên tôi phạm rất nhiều lỗi và mất rất nhiều thời gian mò mẫm.

Một năm rưỡi sau, tôi lập trình app trên store ios/ android đã có cơ hội được xúc tiếp và học tập từ một số lập trình viên Android rất tuấn kiệt và kinh nghiệm, giai đoạn này tôi học được nhiều hơn và nhanh hơn. Qua cả hai thời đoạn, tôi dần biết được mình NÊN và đặc biệt là KHÔNG NÊN LÀM gì. 3. Đọc code nhiều hơn cái Chúng tôi dành hồ hết thời kì để đọc code của nhau, còn nhiều hơn là ngồi viết code nữa. Nếu bạn vẫn chưa làm thế này, hãy khởi đầu ngay đi.

Bất cứ đoạn code nào mà bạn viết được hiện tại là chỉ vì bạn đã đọc và học thứ gì đó, từ đâu đó, và từ lúc nào đó mà thôi. Đó chỉ là sự đề đạt của những gì bạn đã biết. Bạn chỉ có thể phát triển và cải thiện bản thân bằng cách học và đọc từ tác phẩm của người khác mà thôi.

làm app ios/ android có một lợi thế rất lớn, đó chính là nền tảng nguồn mở hoàn toàn. Với lợi thế này, bạn có thể nghiên cứu code xem họ đã thực hiện framework đó như thế nào. Có đến hàng nghìn thư viện nguồn mở trong Github. Chỉ việc lựa chọn thư viện phù hợp và tham khảo.

Bonus: Đây là danh sách các thư viện được cập nhật liên tục, và đây là hầu hết ứng dụng Android open-source hiện thời.

4. Lạy chúa, code theo chuẩn, đừng hứng lên là viết bậy Nếu bạn so sánh code với văn viết, thì chuẩn code cũng giống như chữ viết của bạn vậy.

Khi độc giả code của người khác nhiều hơn, người ta cũng sẽ đọc lại rất nhiều code của bạn, bạn không muốn dọa người đó sợ vãi c*t đúng không nào? Và nếu bạn đang hiệp tác cường độ cao với các lập trình viên khác tại nơi làm việc, bạn càng phải quan tâm đặc biệt đến điểm này. Hãy viết code ngắn, sạch, và dễ đọc dể làm cuộc sống của người khác trở thành tươi đẹp hơn. Đọc code phải như đọc thơ.

Một ngày đẹp trời, đồng nghiệp đọc code của bạn rồi không chuyện trò với bạn vài ngày sau, lúc đó đừng có than.

5. Bạn cần ProGuard, đúng vậy, cần lắm lắm! Đừng, đừng bao giờ phạm sai trái tung áp dụng lên Play Store mà không dùng ProGuard. ProGuard không chỉ tối thiểu hóa code của bạn, mà còn “tung hỏa mù” trong code khiến đối thủ khó lòng, hiểu, tái tạo và kiểm soát code của bạn. công cụ hoàn toàn miễn phí tổn và đính kèm với Android SDK, và hoàn toàn không có lý do nào khiến bạn không nên dùng đến nó cả.

Tôi từng thấy nhiều bạn tung áp dụng lên market mà không có ProGuard. Vận dụng “trần trụi” như vậy chỉ mất vài tiếng để hack (với hacker có trình độ tay ngang).

Pro Tip: ProGuard thỉnh thoảng cũng chỉ là muỗi, Nếu bạn muốn bảo mật siêu cấp, hãy dùng DexGuard.

6. Dùng đúng kiến trúc Khi chọn đúng kiến trúc ngay từ đầu project, bạn sẽ cảm thấy “làm lập trình viên thật tuyệt”. Bạn có thể sử dụng kiến trúc MVP (Model-View-Presenter), có thể decouple code thành nhiều lớp dễ-quản-lý, từ đó cải thiện độ linh hoạt của code và giảm đang kể thời kì cho maintain. User Interface giống như chuyện đùa, nếu bạn phải giải thích, thì chuyện ấy nhạt tuếch Nếu bạn “chỉ” đảm trách việc lập trình và phát triển trong đơn vị, có lẽ bạn sẽ không cần lo về khoản này, vì đã đã có UI/UX designer viện trợ rồi.

Nhưng nếu là lập trình viên “đánh lẻ”, bạn cần phải rất chú ý đến UI và UX nữa, nếu thiếu hai điểm này, tính năng hay cũng vô dụng.

Hãy thiết kế một giao diện sạch, đơn giản, đẹp và dễ nhìn. Không chỉ nên nghĩ như lập trình viên, mà còn phải đánh thức tâm hồn thiết kế bên trong bạn nữa.

Với một UI đẹp và hợp lý, bạn có thể để lại ấn tượng sâu sắc trong mắt người dùng, từ đó học có thể tiếp tục quay lại vời ứng dụng và có tỷ lệ convert (sang bản premium chẳng hạn) cao hơn.

Theo xu hướng hiện giờ, bạn nên đi theo khuynh hướng tối giản, thay vì thêm thắt quá nhiều chi tiết rườm rà.

8. Analytics là người bạn thân nhất Nếu muốn làm ra một vận dụng thật sự tuyệt vời, bạn cần phải theo dõi sát sao hiệu năng và tần suất sử dụng của các phần khác nhau của ứng dụng (thông qua dụng cụ analytics uy tín).

Với analytics, bạn cần cả crash reporting lẫn app usage tracking.

Dù có làm gì đi chăng nữa, bạn sẽ chả bao giờ đạt đến mức “hoàn hảo”. Khi người dùng thật bắt đầu sử dụng bắt đầu sử dụng ứng dụng của bạn trên nhiều thiết bị và phiên bản Android khác nhau, bạn sẽ bắt đầu thấy nhiều đoạn code mình từng “tấm tắc tự khen” dần dần kéo cả ứng dụng đi xuống.

phương tiện report crash có thể giúp bạn theo dõi và fix chúng, từng crash một.

Bạn cũng phải bắt đầu nghĩ suy như một marketer và phân tách tiêu thụ phần cứng của từng phần trong áp dụng. Khi đã có những số liệu cần thiết, bạn sẽ có thể rút ngắn khoản cách giữa thứ mình làm ra với thứ người dùng thật sự mong muốn.

Pro Tip: Firebase Crash Reporting and Analytics là phương tiện tuyệt vời nhất cho mọi người mọi nhà.

9. Biến thành Marketer thứ thiệt Là lập trình viên “đánh lẻ”, bạn cần phải có hiểu biết hơi “toàn diện” một tí, và đương nhiên, marketing cũng nằm trong số đó.

Tôi đã từng thấy rất nhiều sản phẩm tốt thất bại vì không được marketing đúng cách, còn một số sản phẩm không-tốt-lắm lại nổi như cồn vì biết cách marketing.

Nếu bạn trang nghiêm về sản phẩm của mình và muốn tiếp cận lượng người dùng lớn hơn nữa, bạn cần phải đầu tư thời kì và tiền nong để marketing vận dụng cho ra hồn. Nhưng trước khi khởi đầu chiến dịch marketing, hãy bảo đảm rằng áp dụng của bạn đã có đầy đủ các tính năng ổn định.

Bạn cũng nên để ý xem đối thủ đang làm gì, nếu có thể thì cạnh tranh hết mức, còn nếu đối thủ quá “khó nhằn”, bạn có thể nhất thời gác lại rồi “chiến” sau.

Pro Tip: Đây là một phương tiện phân tích thị trường khá hay nên dùng.

10. Đến lúc tối ưu ứng dụng rồi đấy phần đông chúng ta không hề để ý đến khâu này, nhưng bạn nên và cần làm ngay từ bữa nay đi.

Có sự dị biệt rất lớn giữa viết code và viết code “tối ưu”. Hãy viết code làm sao để ứng dụng chạy nhanh, tiêu thụ bộ nhớ ít hơn và chiếm ít dung lượng.

Dưới các tình huống bình thường, ứng dụng chưa tối ưu vẫn chạy tốt, nhưng khi đặt vào nhiều tính huống “căng như dây đàn”, vấn đề sẽ liên tiếp xuất hiện.

Bạn có thể bắt đầu bằng việc kiểm tra lượng bộ nhớ được ứng dụng tiêu thụ và tìm memory leaks. Bạn cũng nên biết cách vận hành của Garbage Collector trong Java, tạo heap dumps và phân tách live objects.

Pro Tip: Leak Canary có thể giúp bạn tự động xác định memory leaks khôn cùng tiện lợi.

11. Tiếp kiệm khối thời gian với Gradle Builds Rất có thể bạn đang sử dụng Android Studio để phát triển áp dụng Android và dùng Gradle làm build system. Gradle rất tốt nhưng lại chậm, và ngày một chậm hơn khi dự án bắt đầu phình ra.

Tôi còn nhớ hồi ngồi “dài cổ” đợi Gradle build xong. Mấy ngày nhiều việc, mỗi ngày mất cả tiếng đồng hồ là chuyện thường nhật, tính ra là mỗi tuần đã mất 5 tiếng chả làm được gì rồi.

Nhưng đương nhiên vẫn có cách tăng tốc rồi.

Bạn có thể làm theo bài viết này và này để cải thiện đáng kể build speed. Build time của tôi giảm mạnh từ 4 phút đến ít hơn 30 giây sau khi được tối ưu đúng cách.

12. Test, Test và khi Test xong, Test lại lần nữa! Trên đời không có gì quan trọng bằng testing cả. Hãy test áp dụng của bạn kỹ càng nhất có thể, tốt nhất là bạn nên dành thời gian ra để viết các trường hợp test tự động. Tạo nhiều tình huống “khó nhằn” cho áp dụng, thử xem bạn có sống sót được không. Hồi trước cũng có lần tôi vội đưa áp dụng lên mà không dành đủ thời gian test. Lúc đó tâm lý của tôi là ngồi chờ người dùng gặp lỗi, report, rồi mới fix. Đừng, đừng, đừng bao giờ làm như vậy nha. Bạn có thể tiếp kiệm một hai ngày, hay một tuần từ việc cắt giảm thời gian cho testing, nhưng bạn có thể mất gấp đôi khoảng thời kì này sau đó.

Đừng làm gì quá vội vàng, cứ từ từ và nghĩ theo “đường dài”. Gieo trước, gặt hái sau.

13. Phân Mảnh Android là quỷ đội lốt người Phân mảnh thiết bị là một trong những vấn đề lớn nhất trong Android, và có vẻ như Google lại lần khần không muốn giải quyết.

hiện giờ, lượng thiết bị Android với các kích thước màn hình và tham số phần cứng khác nhau đã lên đến một con số đồ sộ. Và tệ hơn nữa, nhà nào nhà ấy còn thi nhau tinh chỉnh OS tán loạn cả lên để có cái gọi là “điểm riêng cho thương hiệu”.

Không dừng lại ở đó, có nhiều phiên bản Android mà Google đột nhiên thêm/bớt tính năng API để làm cuộc sống của chúng ta khó khăn hơn nữa.

thí dụ như, chưa từng có lập trình viên Android nào làm xong một áp dụng mà không dùng đến SharedPreferences API. API này hết sức thường thấy, ấy thế mà cũng bug đầy trong bản Android 2.2 cho Samsung Galaxy S (bug report đây).

Hãy lưu ý đến các layout khác nhau cho từng kích tấc màn hình, test trên các thiết bị với các phiên bản khác nhau, nhiều tham số và từ nhiều OEMs.

14. Dancing vào Git ngay và luôn! Nếu bạn vẫn chưa biết đến Git, còn chờ gì nữa nào?

Khi mới khởi đầu lập trình Anroid, tôi có biết Git là cái giống quái gì đâu. Tôi từng copy cả một project của mình mỗi ngày và giữ một bản backup trong ổ cứng, một bản nữa trên cloud. Nghe ngu quá ha? Thì đúng là ngu thật mà.

Git có thể cải thiện mạnh mẽ workflow của bạn. Nếu ai đó hỏi tôi tôi tên của công cụ mà tôi sử dụng mỗi ngày và chẳng thể ngừng sử dụng? Tôi sẽ trả lời là Git và luôn luôn là Git.

Nếu bạn muốn tìm hiểu kết cấu bên trong của Git, đây là nơi bạn cần tới. Còn nếu bạn khởi đầu chuyển qua những dự án lớn mà không biết nên maintain một model phân nhánh như thế nào, hãy tham khảo ở đây nhé.

Bonus: Nếu không đủ nguồn lực tài chính trả chi phí cho private repo trong GitHub, bạn có thể dùng thử miễn tổn phí BitBucket.

15. Làm khó Hackers bản chất open source của Android khiến môi trường này rất dễ bị tiến công. Mọi áp dụng Android đều có thể bị decompiled, kiến trúc ngược, xé toạc, phân tích và chi phối rất dễ dàng.

cố nhiên, bạn không muốn điều này xảy ra với ứng dụng của mình đúng không nào?

Bạn cần biết cách lưu trữ API key cục bộ, bảo mật trong áp dụng. Với dữ liệu nhạy cảm của người dùng, bạn bắt buộc phải biết cách mã hóa chúng, và biết nên chọn thuật toán nào (vừa an toàn vừa nhanh). Bạn cũng nên lưu trữ encryption key thật an toàn trong server hoặc cục bộ (nếu cần thiết), và tránh để dữ liệu của áp dụng bị ADB (Android Debug Bridge) back up.