這本書基本上涵蓋了移動開發中常見的關注點，之所以用關注點而不用技術點這個詞是因為這本書並沒有講到具體的技術實現，但提供了行之有效的解決方案。讀這本書的時候非常有感觸，它很多的框架設計和解決方案與我實際開發中都是不謀而合的（有點自誇的意思哈）。所以也非常感謝作者能這麼詳細的記錄下來。這篇讀書筆記是記錄我在閱讀過程中感覺需要重點強調的地方和自己的一些理解，也供大家能快速的瀏覽本書的章節。

關於重構

• 對於新專案，一開始就要把它設計好，因為產品留給我們的重構機會不多

• 對於老專案：

  1、如果不重構帶來的開發難度或者引發的bug 很嚴重，那麼必須要跟產品商量了。

  2、重構的程式碼一定的在本期迭代上線後，再合併到下期程式碼裡。

  3、重構計劃要詳細要拆分到幾次迭代裡，分期上線。

• AndroidLib

  搭建一套AndroidLib，或者叫Common，它裡邊封裝了所有於業務無關的邏輯。這樣做為後期的Android模組化 和 Android外掛化開發打下基礎。（模組化開發和外掛化開發是兩個不同的概念）

  這裡有人可能會問把所有的與業務無關的邏輯封裝在一起會不會耦合性太高？其實封裝和解耦本來就是一對矛盾的概念，需要我們自己合理的把握設計，我們這裡講的AndroidLib只是為一個特定的App做框架支援，所以不存在耦合性，假如有多個App需要，則必須把AndroidLib拆分成更小的Lib以適應靈活的場景。

• 重構後的專案結構

  在拆分package（iOS裡Group）原則上，建議按照bu（業務單元）來分，而不是按照Class來分。因為一個App的bu是不斷變化，不斷增加的，而Class的型別隨著API變化不會變化太大，例如Android上常用就是Activity、Fragment、Adapter等等。

網路底層的優化

• 我們需要做一個BaseCallback來做統一的onStart、onFinish、onFail、Cookie過期的處理，例如在onStart裡進行showDialog、在onFinish裡隱藏Dialog，在Cookie過期後調整登入頁。這個地方是一個有爭議的設計，因為網路請求的Callback從分層設計上應該屬於Modle，不應該跟UI耦合在一起。在我個人而言更喜歡把BaseCallback看做一個Component，而不是單純的一層Model，這樣更好理解。

HTTP頭的利用

• 我們在MobileAPI 設計的時候，一開始就要把當前App的資訊通過Http Header告訴伺服器，以便服務端排程Api。一般的做法是把App的package、platform、version等等放在UserAgent裡告訴服務端。

• 對於手機系統時間不準的問題，該書也有提到，每次呼叫伺服器api時，伺服器api都在reponse header裡返回伺服器的時間，然後跟手機系統時間做時間差，然後每次本地獲取時間就加上這個時間差。

App圖片快取設計

• 該書介紹了Fresco的三層快取技術

  1、Bitmap快取，在Android5.0及以上Bitmap直接緩存於dalvik vm heap中，而在4.x 及以下bitmap快取在 native heap （ashmem）中，因為dvm對heap大小是有限制的，如果超過這個限制就是OOM

  2、記憶體快取：記憶體快取儲存了圖片的原始壓縮格式，從記憶體快取取出圖片後需要先解碼才能顯示。這個地方會經常提到的Lru 和 SoftReference，SoftReference在2.3以後不再推薦了，因為垃圾回收機制做了修改。

  3、磁碟快取

網路流量的優化

1. API返回資料要使用gzip壓縮，大於1kb才有必要進行壓縮否則得不償失

2. 推薦使用ProtoBuffer，這種協議是二進位制格式的，佔空間更小。

3. 減少API呼叫，一個頁面儘量只發一個請求獲取所需要的資料。

4. http1.x 是不支援多路複用，為了提升訪問速度可以做TCP長連線或者使用http2.0，當然維護一套TCP長連代價也是不小的。

5. 建立取消網路請求的機制，這個最新的retrofit2.0 原生支援推薦使用。

6. 合理的重試機制

7. 大資料列表的增量更新機制，當遇到一個很大的列表資料有改動時，最好使用增量更新機制來減少傳輸的資料量。

圖片策略優化

• 做一套ImageServer，App請求圖片url時會帶上它需要的width、height、圖片質量，然後由ImageServer對原始圖片做壓縮處理。目前有很多廠商提供這種服務，比如七牛。

• App是不是需要把每個ImageView的width、height獲取到呢，按照我的經驗只需要給App定義大、中、小三套width、height基本就夠用了。

• 在弱網情況下再定義一套圖片質量（quality）的值，就會減少弱網下的流量。

App與H5的互動

• 定義一套App 和H5 之間跳轉協議，可以通過JS 或者 OverrideUrl來實現。這個跳轉協議裡可以定義簡單的資料型別，String不需要指定，對於int、double需要在值錢記上類似（int）這個的標記，這樣App才能正常解析。

常見錯誤

• JSONObject 和 JSONArray是不支援序列化的，所以最好是轉換成相應的可序列化的Model再使用。

程式碼規範

• 在xml的檔名命名時最好加入module（或者叫bu）的名字，例如account_adduser_activity.xml

• 空格、tab、換行這些格式建議一個團隊裡統一規範，建議使用工具自動檢查：AndroidCodeQuality

• 將程式碼裡的常量抽取到string.xml中：這個也可以使用工具自動檢查：AndroidLintPlus

安裝包大小

• png 和 jpg 的區別和使用場景

  同樣尺寸的圖片，png要比jpg大很多，因為png是有透明通道、無失真壓縮的。但系統會對png進行硬體加速，所以同一張圖，png體積大但載入速度卻比jpg快。

• 從網路載入的圖片考慮到流量和下載速度優先使用jpg，對於引導圖，也傾向於使用jpg，減少包體積。對於iOS啟動圖必須是png，否則稽核會被拒。

  Google釋出了壓縮率更高的WebP,不過iOS想要支援這種格式需要單獨引入WebP解碼器。

• 單色的icon可以轉換成字型檔案，因為字型是向量圖拉伸不會失真，並且體積會很小。

熱修復能力

• Android 有andfix、nuwa等，ios有jspatch ，這裡就不在展開了。

後門

後門裡常做的功能有：

1. API伺服器切換，極大的方便測試人員。

2. 列印請求API的請求引數和返回結果，不用每次都開代理和後端聯調。

3. 提供一個後門頁面供H5團隊除錯H5是否與Native工作正常。

4. 更多的還有 流量統計、電量統計