一、APP 的整體架構
從較高的層次來講，APP的整體架構可以分爲兩層，即應用層和基礎框架層，
- 應用層：專注與行業領域的實現，eg:金融、支付、地圖導航、社交等，他直接面對的是用戶，是用戶對產品的第一層感知。
- 基礎框架層：專注與技術領域的實現，提供API公有的特性，避免重複製造輪子，是用戶對產品的第二感知，eg:性能、穩定性等。
一個理想的APP應該是具有清晰的層次劃分，同一層模塊間進行解耦，模塊內部符合面向對象設計的六大原則，最後應該在功能、性能、穩定性等方面達到綜合最優，下面將進行對APP架構的圖解
可以看出，上圖將基礎框架層分成幾個部分了：組件層、基礎層、跨平臺層
1.1、 基礎層的分解
1.1.1 技術選型的考量點
在基礎層中，我們可以看到大多數是可以通過第三方SDK或者開源的函數庫去完成的，我們在對函數庫或者第三方SDK 的選擇上應該考慮什麼呢？
- 特性：提供的特性是否滿足項目的需求
- 可用性： 是否提供了簡便的API
- 性能
- 文檔
- 技術支持
- 大小
方法數
1.1.2 日誌記錄能力
日誌的記錄一定要有良好的設計技巧或者換一句通俗的話說就是要在能用的時候使用，不使用的時候將它關掉，在我們的開發中經常會有這樣的場景，我們程序調試的過程會用到打印日誌來測試代碼的流通性，加入我們使用Android 自帶的Log去測試，那等到我們的項目很大的時候我們沒辦法一個個刪除測試的Log信息，這個肯定是不行的，我們會不知不覺中將信息暴露給別人，所以我們要使用自己封裝的日誌打印或者Logger 這種開源的工具，logger具有很多有點，比如它支持日誌中源碼的跳轉，JSON、XML的格式化輸出，但是不能打印set\list\map等的格式化輸出，這時候可以參考LogUtils ，它具有上述特性缺失的彌補。 timber 也是一款開源的框架，它可以讓開發者將日誌打印到控制檯、打印到文件等等，所以開發中最好使用三者的結合 timber + Logger + LogUtils
1.1.3 JSON 解析能力
一般情況下，如果程序沒有特定的需求，一般使用的都是json串，交換數據，Android自身是有解析JSON 的類，但是它的過程是很緩慢的，當然心在開源的實現就有一下幾種
gson
- jackson
- fastJson
- LoganSquare
1.1.4 數據庫的操作能力
在這裏比較好的greenADAO
1.1.5 網絡通信的能力
當然這個大家因該非常熟悉了，比如OkHttp\Volley\Retrofit\xUtils等等 ，這個具體看需求確定
1.1.6 圖片緩存和顯示能力
這個開源的庫已經有很多了，Picasso、Glide、Fresco 等，具體遇到，看需求吧