Android性能优化方法地地总结[整理].pdfVIP

实用标准文案 工作中每个人难免会遇到各种各样的问题，在移动开发中，大家最关注的一个问题就 是性能的优化。下面就 Android 性能优化总结的几点方法。 虽然现在安卓手机基本配置都可以了，但是由于他里面的多后台，耗电量，运行的流 畅性等等问题，都要求了我们能优化性能，每一分的性能优化都是程序更流畅的体验，更 是客户满意度的一个体现，所以我们一般从如下几个方面来考虑性能优化： 1、对于资源的占用和释放 Android 的成功依赖于你的程序提供的用户体验。而这种用户体验，部分依赖于你的 程序是响应快速而灵活的，还是响应缓慢而僵化的。因为所有的程序都运行在同一个设备 之上，都在一起，这就如果在同一条路上行驶的汽车。而这篇文档就相当于你在取得驾照 之前必须要学习的交通规则。如果大家都按照这些规则去做，驾驶就会很顺畅，但是如果 你不这样做，你可能会车毁人亡。这就是为什么这些原则十分重要。 当我们开门见山、直击主题之前，还必须要提醒大家一点：不管 VM是否支持实时 （JIT ）编译器（ xing: 它允许实时地将 Java 解释型程序自动编译成本机机器语言，以使程 序执行的速度更快。有些 JVM包含 JIT 编译器。），下面提到的这些原则都是成立的。假 如我们有目标完全相同的两个方法，在解释执行时 foo() 比 bar() 快，那么编译之后， foo() 依然会比 bar() 快。所以不要寄希望于编译器可以拯救你的程序。 2、对象的管理（避免建立对象） 很多情况下，我们需求用到传递引用，但是我们无法确保引用传递出去后能否及时的 回收。比如比较有代表性的 Context 泄漏，很多情况下当 Activity 结束掉后，由于仍被 其他的对象指向导致一直迟迟不能回收，这就造成了内存泄漏。 3、善用 SoftReference/WeakReference/LruCache Java 、Android 中有没有这样一种机制呢，当内存吃紧或者 GC扫过的情况下，就能及 时把一些内存占用给释放掉，从而分配给需要分配的地方。答案是肯定的， java 为我们提 供了两个解决方案。如果对内存的开销比较关注的 APP，可以考虑使用 WeakReference ，当 GC 回收扫过这块内存区域时就会回收；如果不是那么关注的话，可以使用 SoftReference ， 它会在内存申请不足的情况下自动释放，同样也能解决 OOM问题。同时 Android 自 3.0 以 后也推出了 LruCache 类，使用 LRU算法就释放内存，一样的能解决 OOM，如果兼容 3.0 一 下的版本，请导入 v4 包。关于第二条的无关引用的问题，我们传参可以考虑使用 WeakReference 包装一下。 4、static 静态成员 精彩文档 实用标准文案 static 声明赋值调用就是那么的简单方便，但是伴随而来的还有性能问题。由于 static 声明变量的生命周期其实是和 APP 的生命周期一样的，有点类似与 Application 。 如果大量的使用的话，就会占据内存空间不释放，积少成多也会造成内存的不断开销，直 至挂掉。 static 的合理使用一般用来修饰基本数据类型或者轻量级对象，尽量避免修复集 合或者大对象，常用作修饰全局配置项、工具类方法、内部类。 5、Bitmap 大杀器 很多 OOM的出现都是由于 Bitmap 处理不当而造成的。 Bitmap 位图是 android 中的巨 无霸，由于 Dalivk 并不会主动的去回收，需要开发者在 Bitmap 不被使用的时候 recycle 掉。使用的过程中