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

關(guān)于重構(gòu)

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

• 對于老項目：

  1、如果不重構(gòu)帶來的開發(fā)難度或者引發(fā)的bug 很嚴重，那么必須要跟產(chǎn)品商量了。

  2、重構(gòu)的代碼一定的在本期迭代上線后，再合并到下期代碼里。

  3、重構(gòu)計劃要詳細要拆分到幾次迭代里，分期上線。

• AndroidLib

  搭建一套AndroidLib，或者叫Common，它里邊封裝了所有于業(yè)務無關(guān)的邏輯。這樣做為后期的Android模塊化 和 Android插件化開發(fā)打下基礎。（模塊化開發(fā)和插件化開發(fā)是兩個不同的概念）

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

• 重構(gòu)后的項目結(jié)構(gòu)

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

網(wǎng)絡底層的優(yōu)化

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

HTTP頭的利用

• 我們在MobileAPI 設計的時候，一開始就要把當前App的信息通過Http Header告訴服務器，以便服務端調(diào)度Api。一般的做法是把App的package、platform、version等等放在UserAgent里告訴服務端。

• 對于手機系統(tǒng)時間不準的問題，該書也有提到，每次調(diào)用服務器api時，服務器api都在reponse header里返回服務器的時間，然后跟手機系統(tǒng)時間做時間差，然后每次本地獲取時間就加上這個時間差。

App圖片緩存設計

• 該書介紹了Fresco的三層緩存技術(shù)

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

  2、內(nèi)存緩存：內(nèi)存緩存存儲了圖片的原始壓縮格式，從內(nèi)存緩存取出圖片后需要先解碼才能顯示。這個地方會經(jīng)常提到的Lru 和 SoftReference，SoftReference在2.3以后不再推薦了，因為垃圾回收機制做了修改。

  3、磁盤緩存

網(wǎng)絡流量的優(yōu)化

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

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

減少API調(diào)用，一個頁面盡量只發(fā)一個請求獲取所需要的數(shù)據(jù)。

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

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

合理的重試機制

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

圖片策略優(yōu)化

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

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

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

App與H5的交互

• 定義一套App 和H5 之間跳轉(zhuǎn)協(xié)議，可以通過JS 或者 OverrideUrl來實現(xiàn)。這個跳轉(zhuǎn)協(xié)議里可以定義簡單的數(shù)據(jù)類型，String不需要指定，對于int、double需要在值錢記上類似（int）這個的標記，這樣App才能正常解析。

常見錯誤

• JSONObject 和 JSONArray是不支持序列化的，所以最好是轉(zhuǎn)換成相應的可序列化的Model再使用。

代碼規(guī)范

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

• 空格、tab、換行這些格式建議一個團隊里統(tǒng)一規(guī)范，建議使用工具自動檢查：AndroidCodeQuality

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

安裝包大小

• png 和 jpg 的區(qū)別和使用場景

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

• 從網(wǎng)絡加載的圖片考慮到流量和下載速度優(yōu)先使用jpg，對于引導圖，也傾向于使用jpg，減少包體積。對于iOS啟動圖必須是png，否則審核會被拒。

  Google發(fā)布了壓縮率更高的WebP,不過iOS想要支持這種格式需要單獨引入WebP解碼器。

• 單色的icon可以轉(zhuǎn)換成字體文件，因為字體是矢量圖拉伸不會失真，并且體積會很小。

熱修復能力

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

后門

后門里常做的功能有：

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

打印請求API的請求參數(shù)和返回結(jié)果，不用每次都開代理和后端聯(lián)調(diào)。

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

更多的還有 流量統(tǒng)計、電量統(tǒng)計

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。