“紙上得來終覺淺，絕知此事要躬行。”
“沒有調查就沒有發言權。”
“實踐出真知。”

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

筆者從最初對安卓開發萌生興趣到現在已有兩年之久了，期間做過幾個專案也開發過別的，今天就跟大家分享一下這段時間裡筆者親身總結的7條經驗。

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

Android Arsenal上的一些庫在開始第一個專案時，所有的操作筆者都想從零開始，然後幾乎是把第三方庫打入了冷宮，本想著自己可能以這種方式會學到更多的東西。興許是第一個專案，不用第三方庫也行，但這通常是不可取的。最後無非是浪費大量的時間“造輪子”（指業界已有公認的軟體或庫），所以千萬別這樣。有了第一次的經驗，筆者開始使用開源庫。

任何情況下都會有免費的庫，這點非常好。所以就新增了一個庫，結果根本停不下來。猜猜後來怎樣了？筆者的專案到最後就是雜七雜八的第三方庫扭為一體。所以及時止損吧，好好選庫。不是所有的都靠譜，況且不一定好上手。

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

如果下載和管理的影像很多的話，就用 Glide，這些庫絕對好用，還穩定，誰人都知道。但記住不是所有的庫都會這麼美好。最好每次都查查這些庫出自何方神聖，有時間的話再研究一下開原始碼，看看問題是如何解決的。Android Arsenal幾乎動用了所有可用的安卓庫來維護大型資料庫。

2.從一開始就選對架構

你聽說過類似於MVC、MVP、MVVM這樣的縮略詞嗎？它們代表不同的軟體架構，而且都是需要了解的。很多小白是在activity類中敲程式碼，剛開始這樣似乎行得通，但相信我，這件事沒這麼簡單。專案越大，程式碼就會越複雜還高度耦合，使得後續的測試、維護、新功能的研發變得非常棘手。所以才推薦大家從一開始就選用一目瞭然的軟體架構。如上文提到的這些架構各有千秋，下面是迄今為止谷歌推薦的App架構：

安卓開發員推薦的App架構從圖中可以看出，每一個部分僅由下部與其相連的元件決定。這樣就會帶來一致的使用者體驗，不僅考慮到了關注點分離（separationof concerns），還針對測試和可擴充套件度進行了最佳化。

很顯然，任何架構都有不完美的時候，就像谷歌說的一樣：根本不存在一個架構能滿足任何軟體的情況。言外之意，對於大多數軟體和工作流，從一開始就使用推薦的架構會是好的開端。

由於不是本文的重點，筆者不會對該架構展開過多的解釋，但會給大家列舉一些有用的資源：
l app架構的指南
l 安卓架構元件的基礎樣本

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

你曾多少次想過：“在手機上測試app，發現成功了！”

其實並不夠，簡單的測試可能會在開發時讓你少費幾天功夫，但做起來可就要搭上好幾周的時間了。產品釋出前，做足測試可以幫助我們檢查系統的魯棒性、操作性以及可用度。那該如何測試app呢？這個問題可就太寬泛了，測試型別五花八門，各個都有自己的使命。

安卓開發員提供的測試等級在瞭解上圖的基礎上，可以將測試分為以下三類：l 單元測試：一次使用一個類來驗證效能類別。

l 整合測試：驗證模組內不同層次堆疊間的互動以及相連模組的互動。

l UI測試：驗證使用者介面和使用者流基於app的用例，需要自行決定進行多少種不同測試。谷歌的經驗法則建議---將測試分為70%的小測驗（單元測試），20%的中等測試（整合測試）和10%的大型測試（UI和端到端測試）。
l 在安卓平臺上測試應用：這裡講了測試應用所需的所有東西

l 在安卓上測試驅動開發（TDD）：Google I/O 2017的關於TDD的視訊會議

4.Android Studio ，我們的好夥伴

無可厚非，我們已經利用了IDE（整合開發環境），但真的其物盡其用了嗎？Android Studio裡內建了很多有助於軟體開發的工具，下面列舉了一些筆者最常用到的：

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

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

l 實時效能分析器（Realtime Profilers）可以對CPU、記憶體和網路使用情況進行實時統計分析。

l Firebase助手可以將應用程式與其聯絡起來，只需幾步操作即可將所有Firebase服務都新增上。

l Vector Asset Studio可以幫助給每個密度（密度指磁碟儲存資料的可用空間）建立新的點陣圖影像。
你知道Android Studio還有一個功能是將PC變成“烤爐”嗎？

更多介紹和功能請參見Android Studio 使用指南

5.簡單清晰的使用者介面（UI）

如果在一家大型企業當安卓開發員，UI和UX的設計就是設計者的事了，程式設計師們大可不必擔心。不過要是初創企業或是私人專案，可能就得費些心思設計UI和UX。

相信我，好的介面會錦上添花，而糟糕的介面會毀了一個好專案。“使用者介面就跟笑話一樣，你若解釋它，就證明它還不夠好。”——馬丁·勒布朗（Martin LeBlanc）

過去筆者常犯的一個錯誤就是使用者介面上放的東西太多，元素過多隻會給使用者帶來困擾，還會讓別人覺得沒有美感。建議大家從簡，簡單且清晰。特別是不擅長設計的人更要避諱這一塊，儘量做使用者一看就懂的基礎介面。成形後可以進行改進使其更美觀，這樣使用者會留下更深的體驗印象。

記住透過不同大小的顯示器和DPI來測試UI，不要用固定的測量單位，比如px；多用動態的單位，比如用dp（或測試文字的sp）。l Dribbble：裡面彙集了各路神仙，不知道從哪下手，可以在這上面尋找靈感。

l 材料設計語言（Google Material Design）：該系統適應性強，為設計最佳使用者介面提供了指導、元件和工具系統。

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

6.釋出清單（Release Checklist）

現在覺得自己的應用程式可以釋出了？真的嗎？你怎樣肯定呢？

這個時候，千萬不可草率行事，最好問自己幾個問題：

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

l 測試足量嗎？

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

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

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

l 是否在Google Play上準備了開發者賬戶？如果答案都是“嗯”，那就可以繼續自己的計劃了。

筆者建議大家做一個Android App Bundle （aab）來最佳化應用程式的大小和資源，而非APK。在 Google Play釋出應用程式後，要不斷檢視使用者的反饋和所有的分析資料。這對程式的改進有非常大的幫助。這是安卓開發員提供的檢查清單，不容錯過。

7.要用Git

Git是版本控制系統（VCS），它最基本的兩大作用：一是追蹤檔案的變動，二是簡化由多個開發員參與的大型專案中的工作。我也不知道自己為何會用Git,其實直接給專案進行備份也可以。——來自三年前的我現在筆者知道了。

並且告訴大家：程式設計師們需要Git，它對工作流的幫助簡直妙極了。（這句話要是三年前有人跟我說就好了）。
Git妙在何處？理由如下：

l 資原始碼安全地儲存在雲端，隨用隨取。

l 所有以往的程式碼版本都可使用，可以檢測舊版本，而且出現錯誤時可以回到以前的版本。

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

l 能開發數以千計的開源專案。l 有GitHub和BitBucket這樣的平臺，建立並展示自己專案的介紹也可以實現。

理由千萬條，而筆者希望這些足以傳遞一條資訊：認為自己不需要Git，是錯的。GitHub和BitBucket指南幫你上手Git

最後

今天，筆者分享了一些自己在安卓開發期間親身學到的東西，但肯定有更多的知識有待探索，我們可以一起來學習

附上筆者的Android核心技術學習大綱，獲取相關內容來GitHub：
vx：xx13414521

還有Android的精選學習進階影片，三星架構師、阿里p7、聯通架構師等大牛講解進階內容，私信【學習影片 】領取