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%