一個專案的版本更新的過程總是伴隨著技術的演進和程式碼的重構,只要你在維護你總是會發現有更好的或者說是更合適的控制元件,框架值得去適用,這個過程可以是幾個星期或者是幾個月。
在這裡我試著去分析一下通用專案更新跌代的維護歷程。

常見的UI控制元件演進：
1. 跟隨流行風尚將普通主頁改為側滑主頁，玩起來更炫更簡單有趣；
2. 用RecyclerView代替ListView，因為RecyclerView具有更強的擴充套件性，靈活性，以後的不管什麼資料展示，瀑布流什麼之類，寶寶再也不用大刀闊斧的進行程式碼重構了。

網路框架的演進：
在最開始決定使用那種網路框架的時候我們做了個貨比三家不吃虧，下面我就來對比一下這些常用網路框架的特點和優缺點吧

在看android基礎的時候，關於網路操作一般都會介紹HttpClient以及HttpConnection這兩個包。前者是apache的開源庫，後者是android自帶的api。既然提到了他們，都二者進行一個比較，谷歌在官方文件已經說明了，建議在2.3以及以上版本使用 HttpConnection。具體原因呢，是因為對2.1和2.2版本，HttpURLConnection有那麼幾個Bug，所以建議用Apache 的HTTP Client；之後的版本，建議用HttpURLConnection。Apache的HTTP Client比較強大，擁有龐大而靈活的API，這個實現很穩定，並且Bug很少。然而，也就是因為太龐大了，以至於很難在保證相容性的情況下改進它，故 android 開發團隊不應該維護該庫而是轉投更為輕量級的httpurlconnection。
當我們開發企業級應用的時候，一般都會選擇使用已經封裝好的http框架。開源的比較流行的有：
volley

特色 :
Google推出了官方的針對Android平臺上的網路通訊庫volley，能使網路通訊更快，更簡單，更健壯，Volley在提供了高效能網路通訊功能的同時，對網路圖片載入也提供了良好的支援，完全可以滿足簡單REST客戶端的需求, 我們沒有理由不跟上時代的潮流。另外，但volley的擴充套件性很強，可以根據需要定製你自己的網路請求。所以，最後推薦還是使用volley進行開發，當然其他幾個庫也是非常具有學習以及參考意義的，可以將他們的精髓之處汲取到volley框架的拓展開發之中，做出自己理想的http通訊框架。
簡單來說，它提供瞭如下的便利功能：
JSON，影象等的非同步下載；
網路請求的排序（scheduling）
網路請求的優先順序處理
快取
多級別取消請求
和Activity和生命週期的聯動（Activity結束時同時取消所有網路請求）
底層的網路請求程式碼更加清晰，在Volley返回的結果即直接返回了我們需要的Object，同時將統一的錯誤處理、公共的引數處理和一些公共的返回使用的引數，全部放在我們自定義的Request當中，這樣外部請求所需要傳入的引數更少，對於錯誤的處理更加簡單，只需要考慮業務需要的Response，其他全域性的返回內容則無需進行干擾。通過Volley的引入，幫助我們在業務的開發上變得更加便捷。

缺點：比如大資料（large payloads ），流媒體，這些case，還需要使用原始的方法，比如Download Manager等。

2、OkHttp優點較多
OkHttp是一個現代，快速，高效的Http client，支援HTTP/2以及SPDY，一種開放的網路傳輸協議，由Google開發，它為你做了很多的事情。

OKHttp是Android版Http客戶端。非常高效，支援SPDY、連線池、GZIP和HTTP快取。

支援SPDY，可以合併多個到同一個主機的請求

OkHttp實現的諸多技術如：連線池，gziping，快取等就知道網路相關的操作是多麼複雜了。

OkHttp扮演著傳輸層的角色。

OkHttp使用Okio來大大簡化資料的訪問與儲存，Okio是一個增強 java.io 和 java.nio的庫。

OkHttp 處理了很多網路疑難雜症：會從很多常用的連線問題中自動恢復。如果您的伺服器配置了多個IP地址，當第一個IP連線失敗的時候，OkHttp會自動嘗試下一個IP。

OkHttp還處理了代理伺服器問題和SSL握手失敗問題。

OkHttp是一個Java的HTTP+SPDY客戶端開發包，同時也支援Android。需要Android 2.3以上

OKHttp是Android版Http客戶端。非常高效，支援SPDY、連線池、GZIP和 HTTP 快取。

預設情況下，OKHttp會自動處理常見的網路問題，像二次連線、SSL的握手問題。

如果你的應用程式中集成了OKHttp，Retrofit預設會使用OKHttp處理其他網路層請求。

從Android4.4開始HttpURLConnection的底層實現採用的是okHttp

快取響應避免重複的網路請求

目前，該封裝庫志支援：

1， 一般的get請求

2，一般的post請求

3，基於Http的檔案上傳

4， 檔案下載

5，上傳下載的進度回撥

6， 載入圖片

7， 支援請求回撥，直接返回物件、物件集合

8， 支援session的保持

9， 支援自簽名網站https的訪問，提供方法設定下證書就行

10， 支援取消某個請求

為什麼要做快取，或者說有什麼好處？

減少伺服器負荷，降低延遲提升使用者體驗。

複雜的快取策略會根據使用者當前的網路情況採取不同的快取策略，比如在2g網路很差的情況下，提高快取使用的時間；不用的應用、業務需求、介面所需要的快取策略也會不一樣，有的要保證資料的實時性，所以不能有快取，有的你可以快取5分鐘，等等。你要根據具體情況所需資料的時效性情況給出不同的方案。當然你也可以全部都一樣的快取策略，看你自己。

3. xUtils簡介

xUtils 最初源於Afinal框架，進行了大量重構，使得xUtils支援大檔案上傳，更全面的http請求協議支援(10種謂詞)，擁有更加靈活的ORM，更多的事件註解支援且不受混淆影響…
xUitls最低相容android 2.2 (api level 8)

目前xUtils主要有四大模組：
DbUtils模組：
android中的orm框架，一行程式碼就可以進行增刪改查；
支援事務，預設關閉；
可通過註解自定義表名，列名，外來鍵，唯一性約束，NOT NULL約束，CHECK約束等（需要混淆的時候請註解表名和列名）；
支援繫結外來鍵，儲存實體時外來鍵關聯實體自動儲存或更新；
自動載入外來鍵關聯實體，支援延時載入；
支援鏈式表達查詢，更直觀的查詢語義，參考下面的介紹或sample中的例子。
ViewUtils模組：
android中的ioc框架，完全註解方式就可以進行UI，資源和事件繫結；
新的事件繫結方式，使用混淆工具混淆後仍可正常工作；
目前支援常用的20種事件繫結，參見ViewCommonEventListener類和包com.lidroid.xutils.view.annotation.event。
HttpUtils模組：
支援同步，非同步方式的請求；
支援大檔案上傳，上傳大檔案不會oom；
支援GET，POST，PUT，MOVE，COPY，DELETE，HEAD，OPTIONS，TRACE，CONNECT請求；
下載支援301/302重定向，支援設定是否根據Content-Disposition重新命名下載的檔案；
返回文字內容的請求(預設只啟用了GET請求)支援快取，可設定預設過期時間和針對當前請求的過期時間。
BitmapUtils模組：
載入bitmap的時候無需考慮bitmap載入過程中出現的oom和android容器快速滑動時候出現的圖片錯位等現象；
支援載入網路圖片和本地圖片；
記憶體管理使用lru演算法，更好的管理bitmap記憶體；
可配置執行緒載入執行緒數量，快取大小，快取路徑，載入顯示動畫等…
使用xUtils快速開發框架需要有以下許可權：

<uses-permission android:name="android.permission.INTERNET" /> <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" /> 

混淆時注意事項：
新增Android預設混淆配置${sdk.dir}/tools/proguard/proguard-android.txt
不要混淆xUtils中的註解型別，新增混淆配置：-keep class * extends java.lang.annotation.Annotation { *; }
對使用DbUtils模組持久化的實體類不要混淆，或者註解所有表和列名稱@Table(name=”xxx”)，@Id(column=”xxx”)，@Column(column=”xxx”),@Foreign(column=”xxx”,foreign=”xxx”)；

缺點：程式碼量大，程式碼可讀性變差，冗餘影響程式執行效率

4. Retrofit
Retrofit2.0用了動態代理技術，通過解析註解生成Http請求，把請求交給OkHttp，然後通過我們設定的ConverterFactory進行serialization和deserialization，最後通過CallAdapter把結果進行進一步適配，實現了對Rxjava,Guava和java8的支援。

retrofit使用了builder模式，我們可以在此設定請求的URL，ConverterFactory（此處用了Gson解析，當然你也可以自定義資料解析器，只要你的解析器繼承 Converter.Factory就行），或者設定回撥時的介面卡。在retrofit中提供了三種CallAdapterFactory：GuavaCallAdapterFactory，Java8CallAdapterFactory和RxJavaCallAdapterFactory。

圖片載入框架的演進

是以圖片加文字為主體的內容，因此會有大量的圖片顯示需求。和網路框架選型類似，早期選擇了比較熟悉的UIL來做圖片載入，可以同時支援本地圖片和網路圖片的載入，在當時可以滿足我們的基本需求。
我們開始使用更加高清的圖片，隨之載入速度變慢，佔用更多的記憶體，而且這個時候UIL的作者基本很少維護。我們開始調研使用新的圖片載入框架。此時Fresco剛剛出來，還不太穩定，當時沒敢用。給我們的可選項有Picasso和Glide兩個可選項，Picasso比較輕量，但是相比於UIL在效能上沒有太好的提高。Glide程式碼量較大，不過它會在本地儲存多份快取（原始圖片和實際顯示尺寸的圖片），這樣載入本地快取的時候，可以直接顯示大小剛好的尺寸，減少解碼的時間，因此會比UIL要快很多。
後來我們需要支援gif的動畫顯示，而Glide對動畫的相容性又不是特別好，這個時候我們直接切到了Fresco。同時Fresco對webp的良好支援，使得我們在後期切換到webp格式的時候，減少了很多工作量。Fresco在4.4及以下版本使用匿名記憶體來作為記憶體快取，為我們減少OOM做了巨大的貢獻。
我們使用的這幾個圖片載入框架，每個框架的使用都有非常大的區別，這就導致遷移的時候工作量巨大。為了降低遷移成本，我們封裝了自己的ImageLoader，在ImageLoader中來實現具體的圖片載入，這樣保證在遷移的時候，最大程度的降低程式碼的改動（不過在遷移到Fresco的時候還是改動巨大，因為我們不能直接使用ImageView了o(︶︿︶)o。

推送的升級
推送，我覺得也有必要說一說。最初我們快速選用了百度雲推送，在當時看來百度的推送比較穩定，同時接入比較簡單。實際使用了一年之後，發現送達率不是特別高，並且資料統計做的不太好，無法比較好的統計推送效果。在調研之後，我們決定遷移到小米推送+友盟推送的模式，針對小米使用者開啟小米推送，其他使用者採用友盟推送，為了平滑過渡，在切換期間同時向未升級的老使用者繼續使用百度雲推送進行推送。

架構升級
一般專案中由於一直以來在業務開發佔用的時間比較多，目前App的整體架構沒有做過太大的改變。
在Adapter的使用方面，我們將ListView或RecyclerView的Item放到單獨的ItemHander，這樣可以在不同的頁面可以通過將不同的Item組裝到一起，從而滿足不同地方的需求。這樣可以在ListView或RecyclerView來複用相同的程式碼，提高程式碼的可維護性。
前面網路層說到我們的錯誤處理，這個也是做過比較大的升級。最初時候，網路錯誤、http請求錯誤、後臺和客戶端的錯誤，都分別在不同的層級進行處理。目前我們在發生錯誤的時候將錯誤全部以Exception的方式丟擲，最後在上層進行錯誤的處理。
App中的狀態同步，早期使用使用資料庫快取部分資料，或者使用LocalBroadcast進行廣播通訊，前者有很多的限制，後者使用起來較為複雜。近期我們改用EventBus進行狀態同步，同時這樣也使得各個頁面之間的耦合也低。
App中佔比很大的部分是從網路請求資料，獲得資料後進行展示，還是以MVC為主。在一些模組的部分地方，做一些databinding，MVP等的測試。後面有機會會更多大範圍的重構。

APK最初大約只有5M，歷史最高峰達到了23M，在App減肥上我們也做了一些努力，主要是使用tinypng壓縮圖片，so只保留arm的支援.

現在持續整合還是蠻火的，自然我們也在用。最初的時候，我們每天需要手動打包，打完包之後開啟fir的網站，將apk傳上去，然後在公司的微信群吼一聲，告訴大家我們發包了。經歷一段時間後，我們編寫了一個Gradle外掛幫助我們自動上傳到fir，在之後我們搭建了Jenkins自動完成這一系列步驟，並通過郵件告知大家;