Android 重構方案

2020 年 9 月 12 日
筆記
Android 性能優化

前言

最近面試了很多候選人，發現很多同學在簡歷上都寫得非常厲害，負責架構設計，項目重構之類的。但是問起來，很多人都說不出個所以然來。今天我們不談架構設計，我們聊一下重構。我面試時候經常會問，你是怎麼重構的，從哪些方面入手。大部分的人基本上回答就是換一下網絡請求的框架，圖片處理的框架，好一些的能夠說出一些MVP/MVVM,再好一點的能夠說出一些模塊化，組件化的東西。給我最大的感覺就是為了重構而重構，或者是無中生有的重構，沒有全面的思考過為什麼要這樣做。我們重構的目的就是為了讓項目的可讀性，可維護性，擴展性更強。後期其他同學接手，不至於把祖宗都問候一遍。剛好，最近我一直在維護一個2010年到現在的一個項目，談一談重構的過程。

1、注釋， activity、fragment、類、方法一定要有注釋

每一個頁面，類，方法，都要有對應的注釋，寫明作者是誰，時間，還有是做什麼，這樣對後面的同學梳理流程的時候，會順暢很多。畢竟自己覺得自己寫的代碼很清晰，在其他人眼中就不一定是這樣了。
activity：C:\Program Files\Android\Android Studio\plugins\android\lib\templates\activities\EmptyActivity\root\src\app_package
在頭部添加

/**
 * @Description: 
 * @Author: huangjialin
 * @CreateDate: ${.now?string("yyyy-MM-dd")}
 */

普通類的，可以直接在studio中進行設置 settings — > File and Code Templates — >File Header 中添加

/**     
  * @Description:     java類作用描述 
  * @Author:         huangjialin
  * @CreateDate:     ${DATE} ${TIME}
  */

命名規範，統一，包括資源，java文件，布局，方法名，字段等等

這裡推薦使用插件：Alibaba Java Coding Guidelines
要求：
1、（從命名上能夠知道這個是activity，fragment還是adapter等等）
2、見其名，能知其意

在我重構的過程中，遇到很多這樣的

這是直接從項目中進行截圖的，我都不擔心會出現什麼泄密的情況。這樣的命名，就只比使用A,B,C這樣的命名好一點而已。好的命名基本上能夠知道這個類，頁面，方法是幹什麼的，對後面維護的同學也是非常友好的。

java文件命名，一定要做到見其名，知其意，即使名字長一些也是可以的，比如說aaaActivity ,aaaFragment…,這個aaa基本就是這個文件是做什麼的。布局，方法名，字段這些，也是如此，但是命名的同時，也要注意編碼規範。
針對於資源的命名，不光要能從名字中知道含義，還需要考慮後期組件化後，可能會產生的資源衝突
這裡建議在module的build.gradle中添加

//給 Module 內的資源名增加前綴, 避免資源名衝突
resourcePrefix "${project.name.toLowerCase().replaceAll("-", "_")}_"

這樣給資源命名是會提示添加上對應module的前綴了。

3、工具類封裝

Log,Toast,SharedPreferences,dialog,animation 等等等等，特別是對於經歷過多人維護的項目，很多工具類都有很幾套，一人弄一套，所以我們要做的就是統一，一個項目中不要出現多個重複的工具類，否則對於後期維護那是很困難的。

4、第三方jar的統一如網絡，圖片等等

比如說我維護的這個項目，2010年寫的到現在，光網絡請求的就有四個，最早以前就是用HttpURLConnection，然後又有Volley，然後到Okhttp，接着就是Retrofit + okhttp,導致了現在一個很嚴重的問題，新人維護都不敢亂動，一直堆代碼，當然，現在這樣的請求是沒事，但是如果後期,比如說需要更改域名，加密，在頭部添加一些參數，等等等等，那倒霉的永遠是最後一個接手的人。
當然這裡需要注意兩個問題
第一：不要一上來就直接全部替換，要循序漸進，直接全部替換，那麼風險會非常大，對開發人員，測試人員，壓力都會很大。
第二：既然要統一，那麼選用個框架比較好？我個人的看法是首先是選擇穩定性好的，性能好的，自己擅長的。

5、模塊化->組件化，MVP/MVVM

做到這一步，多少對項目有些熟悉了，接下來要先做的是架構的分層還是代碼的分離，取決於自身對項目的熟悉程度，如果項目中已經做了模塊化，那麼需要考慮的是以下幾點：
1、此時的模塊分離的粒度是否符合當前，可能當時分層的時候是合理的，但是隨着業務的增加，是不是存在一些臃腫的代碼，需不需要更加細緻的分離。這個需要根據項目來決定的。
2、項目越大，那就考慮組件化，組件化是在模塊化的基礎上弄的，所以一定要先模塊化在組件化。
3、組件化需要分層更加細緻，比如第三方jar層，公共組件層，組件層，調試層等等，還需要考慮組件間的耦合，通信等，具體的可以專門去學習組件化。
4、插件化，如果做完組件化，在做插件化，那麼插件化將會容易很多，同理，需不需要做插件化，根據公司項目來決定。

MVP/MVVM
這個主要是針對於代碼的隔離，如果項目中已經使用了mvp，那就接着用mvp，不要因為一些東西出來了，比如現在Google強推一個jetpack，就馬上換MVVM，那樣風險是非常大的，如果都是allinone在一個activity，那麼直接就使用MVVM來進行重構。LiveData + ViewModel優勢是很大的。

組件化 + MVP + MVVM可參考：//www.cnblogs.com/huangjialin/p/13086553.html

6、涉及模式的使用

到這一步，基本對整個項目都是有一個明顯的認識了，到這裡就要考慮業務了，需要考慮更多的是業務的擴展性好不好，可讀性好不好，好不好維護了。在這裡我們可以根據自己實際的項目來使用一些設計模式，比如單例，觀察者，工廠，Build模式，策略模式等等

7、網絡數據結構重構

這個看公司業務來決定，這個處理的是後端返回的數據結構是否需要統一，這裡看公司和前後端的情況來決定。畢竟這個改動，不光是前端改，也需要後端同學改動了，工作量大，風險很高。

8、性能優化：卡頓，內存，啟動，布局優化，apk體積

到這一步，重構代碼這部分，基本OK了，現在需要考慮的是應用的性能問題了，這裡我列出來，我個人覺得從左到右優先級由高到底的順序來處理，具體怎麼做，參考這裡。
卡頓優化：//www.cnblogs.com/huangjialin/p/13389421.html
內存優化：//www.cnblogs.com/huangjialin/p/13327949.html
啟動優化：//www.cnblogs.com/huangjialin/p/13292042.html
布局優化：//www.cnblogs.com/huangjialin/p/13353541.html

9、文檔輸出

非常重要！！！非常重要！！！非常重要！！！
這一步沒做好，很容易導致前面做的前功盡棄。所以需要一邊重構，一邊輸出文檔，後面接手的人，會感謝你的。

10、重構之路，任重而道遠，需要定期重構。

除非非常大的重構，否則重構不需要特意排期，只要我們發現某個地方不合理，都可以進行重構，但是需要通知測試人員注意測試。重構之路，任重而道遠！！！！！！！！！！！！！！！！

Tags: Android 性能優化