目錄

一、代碼混淆proguard

二、調整第三方庫

三、環境差異依賴

四、代碼習慣

五、插件化

六、總結

---

在前兩章我們分別從圖片資源和jni動態庫這兩個方面來分析apk瘦身的優化點

Android App 瘦身總結 第一章 圖片資源的優化處理

Android App 瘦身總結 第二章 jni動態庫及cpu兼容

本章我們從代碼角度來繼續進行分析。

代碼是一個app的核心，但是實際上一款應用真正自有的代碼在空間占有率并不多（當然像淘寶微信這樣的航母級自有代碼也一定十分龐大），更多的是各種依賴引用的框架、lib和第三方sdk等。所以這部分的優化可能效果沒有那么顯著，但是十分必要，可以通過優化發現代碼習慣問題、深入了解業務。

代碼優化主要有一下幾點：

一、代碼混淆proguard

老生常談的問題，代碼混淆主要目的是增加反編譯解讀源碼的難度，提高應用安全性。但是它同時的確帶來了代碼量的減少，雖然減少的可能不是特別顯著。

代碼混淆是android apk的常態，建議大家在應用中使用。關于混淆怎么用網上也有太多的文章了，就不列舉了大家可以自行搜索。

但是要注意幾點：

（1）引入第三方庫時，一定要按照官方文檔添加混淆，否則很容易出錯

（2）引入jar包時（沒有官方文檔或者官方未給出），盡量不進行混淆。一個是大部分正規的jar包其實已經混淆過了；而是混淆后容易引起問題。

（3）在不完全了解proguard語法時，不要盲目復制粘貼網上提供一個proguard樣本，盡量弄清除每一行語法的作用在使用。

（4）在每次發布版本后，一定要保存好對應的mapping文件，可以用于錯誤統計分析時將堆棧信息反解析回源碼。

二、調整第三方庫

這個于動態庫類似，很多時候我們為了實現一些功能，會利用已有的輪子——第三方庫。但是實際上大部分人對輪子沒有全面了解，這就造成了一種情況的出現：舉例來說就是我們只是想用一個簡單計算功能，但我們引入的卻是一臺超級電腦。

拿我們的App來說，前期瘋狂迭代期沒有太多時間去考慮這些，當我們回過頭來看的時候發現居然用到了二十多個第三方庫。其中很多庫都是巨無霸級別，是一套完整健全的某個功能的解決方案，但是我們可能只用其中一個組件、一套工具類等等，這就造成了大量的浪費。

所以這時候我們要注意幾點：

（1）以最小的代價實現功能：盡量去尋找那些精準的貼合你的需求的第三方庫；如果引入的是一個龐大的庫而只用極少的功能，可以考慮將使用的功能部分源碼直接拿出來使用。

（2）盡量使用同一家平臺的服務：比如友盟、百度等，因為很多服務sdk會依賴一些基礎jar包，一般同一家平臺的都會用同一套基礎jar包。如果不同的功能用不同平臺的服務，很容易造成同一種基礎功能存在多中解決方案的jar包。比如網絡請求就存在volley、okhttp等多種解決方案，如果在一個app中使用了太多家平臺的服務，就會出現在應用中同時存在volley、okhttp...，功能重復而且浪費。

（3）自己動手豐衣足食：有時候可能我們需要的是一個沒有特別復雜的功能，但是可能由于時間緊張等情況使用了第三方庫；另外一種情況是前期需要一個復雜的功能，經過幾輪迭代后功能簡化了。這時候我們就可以考慮拋開第三方庫自己來實現，這樣也會提高自身的能力。

（4）不要盲目跟風：現今還有一種現象，部分開發者很喜歡跟風新的框架、新的解決方案。關注新技術固然無錯，但是要考慮實際應用場景。我面試過一家公司，兩個開發者將時下最新最潮的全都塞入了他們的app，但其實那只是一個有十幾個頁面功能單一的應用。甚至有個框架只用在了一處地方，最大的功效是減少幾行代碼而已。而apk大小卻接近航母級應用了。

這部分需要我們重新審視應用，更好的辦法是嚴格把關第三方庫的引入，雖然這樣會比較麻煩，但是以后會受益匪淺。

三、環境差異依賴

有時候我們會為應用引入一些監控、校驗等幫助測試的第三方庫，但是這些其實正式包中沒有必要存在。

這時可以考慮只在debug版本的時候依賴即可， 如：

debugCompile 'com.squareup.leakcanary:leakcanary-android:1.3'

但是就會出現一個問題，在我們的代碼里需要有一些初始化之類的代碼。如果只是debugCompile，編譯release版本時就會出錯，因為找不到對應的類。

解決方法很簡單，android studio允許我們創建不同環境的包，如圖

我們在main目錄的同級別上創建類release和debug兩個環境的目錄，在包下各有一個Application。這樣編譯不同環境的時候，編譯器會自動將對應環境的目錄中的java文件和mian目錄下的java文件一起編譯。

這樣我們就可以在不同的Application中編寫不同的代碼，比如在debug目錄下的Application中添加leakcancanary的初始化代碼，而在release目錄下的則沒有。這樣就不會出現release版本編譯問題了。

要注意幾點：

（1）在main目錄下不能有同樣的java文件（如上面的Application）

（2）Application只是個例子，在實際開發中，有差異的java代碼盡量保證最少，最好只將不一致的部分封裝到不同的環境目錄中。比如上面的例子，如果Application代碼較多，可以保留在main下，在debug和release下分別創建個LeakManager類，Applicaiton來調用LeakManager的方法即可。

通過這些操作就可以在打release版本是不加入這些與debug有關的第三方庫，減少一定的應用大小。

四、代碼習慣

另外要養成良好的代碼習慣，盡量去寫一些高復用的代碼，減少應用中的重復代碼。定期對代碼進行review，小規模的進行代碼重構，封裝一些頻繁使用的工具類等。養成用最少代碼完成功能的習慣和能力。這樣不僅會讓代碼結構清晰，也會讓代碼量大大的減少。

五、插件化

瘦身不是插件化的主要目的，但是一款app發展到航母級別的時候就必須考慮插件化了。關于插件化有很多開源框架，而且IT大佬們也陸續開源了自己的插件化框架，這個框架各有優缺，根據自身應用的特點去選擇。

六、總結

本章主要從代碼角度分析優化點，其中代碼這方面對app瘦身影響沒有那么大，因為代碼編譯打包時都會經過壓縮，本身占用空間不會太大。

但是追求極致的目的不是極致，而是在追求極致的過程中提升自己的能力和思維高度。

經過這三章的講解，關于app瘦身這部分就告一段落了，我相信自己會有理解不到位的情況，而且還有很多未了解未探索的部分，希望大家多提寶貴意見！！謝謝！！

?

總結

以上是生活随笔為你收集整理的Android App 瘦身总结 第三章 代码混淆及优化的全部內容，希望文章能夠幫你解決所遇到的問題。

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