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

關于重構

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

• 對于老項目：

  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、磁盤緩存

網絡流量的優化

API返回數據要使用gzip壓縮，大于1kb才有必要進行壓縮否則得不償失

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

減少API調用，一個頁面盡量只發一個請求獲取所需要的數據。

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

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

合理的重試機制

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

圖片策略優化

• 做一套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 ，這里就不在展開了。

后門

后門里常做的功能有：

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

打印請求API的請求參數和返回結果，不用每次都開代理和后端聯調。

提供一個后門頁面供H5團隊調試H5是否與Native工作正常。

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

總結

以上是生活随笔為你收集整理的《App研发录》读书笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。