Android開發(fā)的經(jīng)驗總結

“紙上得來終覺淺，絕知此事要躬行?！?/p>

“沒有調查就沒有發(fā)言權?！?/p>

“實踐出真知?！?/p>

古今中外，無數(shù)名言警句都告訴我們實際去做一件事的重要性。

筆者從最初對安卓開發(fā)萌生興趣到現(xiàn)在已有兩年之久了，期間做過幾個項目也開發(fā)過別的，今天就跟大家分享一下這段時間里筆者親身總結的7條經(jīng)驗。

1.第三方庫：找到正確的平衡點

Android Arsenal上的一些庫

在開始第一個項目時，所有的操作筆者都想從零開始，然后幾乎是把第三方庫打入了冷宮，本想著自己可能以這種方式會學到更多的東西。

興許是第一個項目，不用第三方庫也行，但這通常是不可取的。最后無非是浪費大量的時間“造輪子”（指業(yè)界已有公認的軟件或庫），所以千萬別這樣。

有了第一次的經(jīng)驗，筆者開始使用開源庫。任何情況下都會有免費的庫，這點非常好。所以就添加了一個庫，結果根本停不下來。

猜猜后來怎樣了？筆者的項目到最后就是雜七雜八的第三方庫扭為一體。所以及時止損吧，好好選庫。不是所有的都靠譜，況且不一定好上手。

筆者的建議就是尋找平衡點。如果在開發(fā)的過程中遇到難題，而這個難題恰巧是別人用某個庫完美解決的，那就這個庫沒錯了。要是需要HTTP客戶端，選它—— Retrofit。

如果下載和管理的圖像很多的話，就用 Glide，這些庫絕對好用，還穩(wěn)定，誰人都知道。

但記住不是所有的庫都會這么美好。最好每次都查查這些庫出自何方神圣，有時間的話再研究一下開源代碼，看看問題是如何解決的。

Android Arsenal幾乎動用了所有可用的安卓庫來維護大型數(shù)據(jù)庫。

2.從一開始就選對架構

你聽說過類似于MVC、MVP、MVVM這樣的縮略詞嗎？它們代表不同的軟件架構，而且都是需要了解的。

很多小白是在activity類中敲代碼，剛開始這樣似乎行得通，但相信我，這件事沒這么簡單。

項目越大，代碼就會越復雜還高度耦合，使得后續(xù)的測試、維護、新功能的研發(fā)變得非常棘手。

所以才推薦大家從一開始就選用一目了然的軟件架構。如上文提到的這些架構各有千秋，下面是迄今為止谷歌推薦的App架構：

安卓開發(fā)員推薦的App架構

從圖中可以看出，每一個部分僅由下部與其相連的組件決定。

這樣就會帶來一致的用戶體驗，不僅考慮到了關注點分離（separationof concerns），還針對測試和可擴展度進行了優(yōu)化。很顯然，任何架構都有不完美的時候，就像谷歌說的一樣：

根本不存在一個架構能滿足任何軟件的情況。言外之意，對于大多數(shù)軟件和工作流，從一開始就使用推薦的架構會是好的開端。

由于不是本文的重點，筆者不會對該架構展開過多的解釋，但會給大家列舉一些有用的資源：

l app架構的指南

l 安卓架構組件的基礎樣本

3.重要的事情說三遍：測試測試測試

你曾多少次想過：“在手機上測試app，發(fā)現(xiàn)成功了！”

其實并不夠，簡單的測試可能會在開發(fā)時讓你少費幾天功夫，但做起來可就要搭上好幾周的時間了。

產(chǎn)品發(fā)布前，做足測試可以幫助我們檢查系統(tǒng)的魯棒性、操作性以及可用度。

那該如何測試app呢？這個問題可就太寬泛了，測試類型五花八門，各個都有自己的使命。

安卓開發(fā)員提供的測試等級

在了解上圖的基礎上，可以將測試分為以下三類：

l 單元測試：一次使用一個類來驗證性能類別。

l 集成測試：驗證模塊內不同層次堆棧間的交互以及相連模塊的交互。

l UI測試：驗證用戶界面和用戶流

基于app的用例，需要自行決定進行多少種不同測試。

谷歌的經(jīng)驗法則建議---將測試分為70%的小測驗（單元測試），20%的中等測試（集成測試）和10%的大型測試（UI和端到端測試）。

l 在安卓平臺上測試應用：這里講了測試應用所需的所有東西

l 在安卓上測試驅動開發(fā)（TDD）：Google I/O 2017的關于TDD的視頻會議

4.Android Studio ，我們的好伙伴

無可厚非，我們已經(jīng)利用了IDE（集成開發(fā)環(huán)境），但真的其物盡其用了嗎？

Android Studio里內置了很多有助于軟件開發(fā)的工具，下面列舉了一些筆者最常用到的：

l 設備模擬器可以對不同設備上、各種安卓版本的應用程序進行測試。

l 安卓PK分析器可以通過對APK大小的檢測分析出程序的大小。

l 實時性能分析器（Realtime Profilers）可以對CPU、內存和網(wǎng)絡使用情況進行實時統(tǒng)計分析。

l Firebase助手可以將應用程序與其聯(lián)系起來，只需幾步操作即可將所有Firebase服務都添加上。

l Vector Asset Studio可以幫助給每個密度（密度指磁盤存儲數(shù)據(jù)的可用空間）創(chuàng)建新的位圖圖像。

你知道Android Studio還有一個功能是將PC變成“烤爐”嗎？

更多介紹和功能請參見Android Studio

5.簡單清晰的用戶界面（UI）

如果在一家大型企業(yè)當安卓開發(fā)員，UI和UX的設計就是設計者的事了，程序員們大可不必擔心。

不過要是初創(chuàng)企業(yè)或是私人項目，可能就得費些心思設計UI和UX。相信我，好的界面會錦上添花，而糟糕的界面會毀了一個好項目。

“用戶界面就跟笑話一樣，你若解釋它，就證明它還不夠好。”——馬丁·勒布朗（Martin LeBlanc）

過去筆者常犯的一個錯誤就是用戶界面上放的東西太多，元素過多只會給用戶帶來困擾，還會讓別人覺得沒有美感。建議大家從簡，簡單且清晰。

特別是不擅長設計的人更要避諱這一塊，盡量做用戶一看就懂的基礎界面。成形后可以進行改進使其更美觀，這樣用戶會留下更深的體驗印象。

記住通過不同大小的顯示器和DPI來測試UI，不要用固定的測量單位，比如px；多用動態(tài)的單位，比如用dp（或測試文本的sp）。

l Dribbble：里面匯集了各路神仙，不知道從哪下手，可以在這上面尋找靈感。

l 材料設計語言（Google Material Design）：該系統(tǒng)適應性強，為設計最佳用戶界面提供了指導、組件和工具系統(tǒng)。

l 《設計心理學》（The Psychology Of Everyday Things）：唐·諾曼寫的這本書講了日用品的可用性設計，值得一看。

6.發(fā)布清單（Release Checklist）

來源：Pexels

現(xiàn)在覺得自己的應用程序可以發(fā)布了？真的嗎？你怎樣肯定呢？這個時候，千萬不可草率行事，最好問自己幾個問題：

l 是否移除了所有糾錯代碼？

l 測試足量嗎？

l 在構建Gradle時，是否更新了名稱和版本代碼？

l 是否啟用了Proguard 來混淆APK代碼？

l 是否對應用程序進行了本地化操作？

l 是否在Google Play上準備了開發(fā)者賬戶？

如果答案都是“嗯”，那就可以繼續(xù)自己的計劃了。筆者建議大家做一個Android App Bundle （aab）來優(yōu)化應用程序的大小和資源，而非APK。

在 Google Play發(fā)布應用程序后，要不斷查看用戶的反饋和所有的分析數(shù)據(jù)。這對程序的改進有非常大的幫助。

這是安卓開發(fā)員提供的檢查清單，不容錯過。

7.要用Git

Git是版本控制系統(tǒng)（VCS），它最基本的兩大作用：一是追蹤文件的變動，二是簡化由多個開發(fā)員參與的大型項目中的工作。

我也不知道自己為何會用Git,其實直接給項目進行備份也可以?！獊碜匀昵暗奈?/p>

現(xiàn)在筆者知道了。

并且告訴大家：程序員們需要Git，它對工作流的幫助簡直妙極了。（這句話要是三年前有人跟我說就好了）。

Git妙在何處？理由如下：

l 資源代碼安全地儲存在云端，隨用隨取。

l 所有以往的代碼版本都可使用，可以檢測舊版本，而且出現(xiàn)錯誤時可以回到以前的版本。

l 團隊工作得到了簡化。每個開發(fā)員都可以在并行分支上進行工作，有需要時合并更改。

l 能開發(fā)數(shù)以千計的開源項目。

l 有GitHub和BitBucket這樣的平臺，創(chuàng)建并展示自己項目的介紹也可以實現(xiàn)。

理由千萬條，而筆者希望這些足以傳遞一條信息：認為自己不需要Git，是錯的。

GitHub和BitBucket指南幫你上手Git

來源：Pexels

今天，筆者分享了一些自己在安卓開發(fā)期間親身學到的東西，但肯定有更多的知識有待探索。

如果大家有其他寶藏級建議，尤其是適合初學者的，請在下方踴躍留言哦。