Android性能優化全方面解析
目的
公司的新需求終于解決完了，離測試和發布還有段時間，第一次體驗了下沒需求沒bug的感覺，真是舒爽，然后翻了翻有什么可以學的。無意翻到了Android后期發展的五大趨勢。一、性能優化。二、高級UI。三、JNI/NDK開發。四、架構師。五、RN開發。這也許將會是我的進階趨勢。早已知道在瓶頸期的我，似乎看到了突破的希望的。初級進階中級也好，中級進階高級也罷，現在的市場無非是根據經驗規定的，根據能力的少之又少。
其實，關注我的或者在群里的小伙伴也知道，UI那塊我問題不大。但是高級UI就有難度了。我們先不管他，一個一個來。先從性能優化來。其實我是拒絕寫這篇文章的。為什么？性能優化的分類很多，一個分類寫一篇感覺篇幅量很小，結合在一起寫有感覺很大。而我目前打算整體的整理一下。
那么我們先分析下性能優化有那幾個方面：一、內存優化。二、UI優化（布局優化和繪制優化）。三、速度的優化（線程優化/網絡優化）。四、電量優化。五、啟動優化。應該就這些了。那么這只是五大方面，里面還結合了各種細節方面的。不急，我們下面一個個地介紹。
內存優化
關于性能優化我們可以不知道其他的，但一定要知道內存優化。因為內存泄漏可以Android的常客。那么什么是內存泄漏呢？內存不在GC的掌控范圍之內了。那么Java的GC內存回收機制是什么？某對象不在有任何引用的時候才會進行回收。那么GC回收機制的原理是什么？又或者說可以作為GC Root引用點的是啥？或許有人聽不懂我在講啥。我們先來看張圖。
當我們向上尋找，一直尋找到GC Root的時候，此對象不會進行回收，例如，一個Activity。那么如果我們向上尋找，直到找到GC Root對象的時候，就說明它是不可以回收的，例如，我定義了一個int a；但是這個數據，我整個頁面或者說整個項目都沒有用到，則這個對象會被GC掉。
GC的引用點
1. Java棧中引用的對象
2. 方法靜態引用的對象
3. 方法常量引用的對象
4. Native中JNI引用的對象
5. Thread——“活著的”線程
如何判斷
那么我們如何判斷一個對象是一個垃圾對象，可以講他進行回收呢？舉了小例子教你們如何區分：
一般在學校吃飯，我們有兩種情況，第一：吃完飯就直接走人，碗筷留給阿姨來收拾處理。
第二：吃完之后把碗筷放到收盤處直接進行回收。
但我們是個有素質的人，一般采用第二種情況，但根據想法，我們更傾向于第一種。
那么一般在飯店或者KFC中，都是第一種情況。
那么此時，問題來了，如果我已經吃完飯，然后我并沒有離開飯店，做在位置上和朋友吹吹牛逼，談談理想，聊聊人生。
那么桌上那一堆碗筷是收還是不收？講道理是不能收的。雖然實際也是不能收的。因為顧客是上帝~~~
So，我們如何判斷一個對象是一個可回收的垃圾對象呢？這是我們的一個主觀的判斷。但是有種情況我們是必須要考慮到的，沒錯，就是內存過多無法釋放的時候，會直接導致OOM。整個項目boom炸了。什么鬼？outofmemory。沒錯就是它。
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%