谈一谈Android内存优化那些事（二）Android常用的内存优化方法

2401_84097427

于 2024-04-02 22:47:41 发布

阅读量729

点赞数 19

分类专栏：程序员文章标签： android

本文链接：https://blog.csdn.net/2401_84097427/article/details/137295871

版权

程序员专栏收录该内容

262 篇文章 0 订阅

订阅专栏

图片存在像素浪费，对于.9图，美工可能在出图时在拉伸与非拉伸区域都有大量的像素重复。而这些图片是可以缩小，但并不影响显示效果。
inSampleSize:缩放比例，在把图片载入内存之前，我们需要计算一个合适的缩放比例，避免不必要的大图载入。
选择ARGB_8888/RBG_565/ARGB_4444/ALPHA_8，存在很大差异。
inBitmap：这个参数用来实现Bitmap内存的复用，但复用存在一些限制，具体体现在：在Android 4.4之前只能重用相同大小的Bitmap的内存，而Android 4.4及以后版本则只要后来的Bitmap比之前的小即可。使用inBitmap参数前，每创建一个Bitmap对象都会分配一块内存供其使用，而使用了inBitmap参数后，多个Bitmap可以复用一块内存，这样可以提高性能。

参考：

Android 官网文档Managing Bitmap Memory、Handling bitmaps

二、代码优化

这里介绍一些好的编码习惯：

考虑使用ArrayMap/SpareseArray而不是传统的HashMap等数据结构，Android系统为移动系统设计的容器ArrayMap更加高效，占用内存更少，因为HashMap需要一个额外的实例对象来记录Mapping的操作。而SparesArray高效的避免了key和value的自动装箱，而且避免了装箱后的解箱。详细参考Android性能优化典范
在onDraw这种频繁调用的方法要避免对象的创建操作，因为他会迅速增加内存的使用，引起频繁的gc，甚至内存抖动。
SoftReference(软引用)、WeakReference(弱引用)、PhantomReference(虚引用)

SoftReference：如果一个对象只具有软引用，则内存空间足够，垃圾回收器就不会回收它；如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存。

WeakReference：与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。

PhantomReference：虚引用”顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收器回收。虚引用主要用来跟踪对象被垃圾回收器回收的活动。虚引用与软引用和弱引用的一个区别在于：虚引用必须和引用队列（ReferenceQueue）联合使用。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。

谨慎使用large heap，android设备由于软硬件的差异，heap阀值不同，特殊情况下可以在manifest中使用largeheap=true声明一个更大的heap空间，使用getLargeMemoryClass()来获取到这个更大的空间。但是要谨慎使用，因为额外的空间会影响到系统整体的用户体验，切换任务时性能大打折扣，对于oom异常是治标不治本的一种做法。
谨慎使用多进程，使用多进程可以把应用中的部分组件运行在单独的进程当中，这样可以扩大应用的内存占用范围，但是这个技术必须谨慎使用，绝大多数应用都不应该贸然使用多进程，一方面是因为使用多进程会使得代码逻辑更加复杂，另外如果使用不当，它可能反而会导致显著增加内存。当你的应用需要运行一个常驻后台的任务，而且这个任务并不轻量，可以考虑使用这个技术，一个典型的例子是创建一个可以长时间后台播放的Music Player。如果整个应用都运行在一个进程中，当后台播放的时候，前台的那些UI资源也没有办法得到释放。类似这样的应用可以切分成2个进程：一个用来操作UI，另外一个给后台的Service。
考虑第三方库的大小，如果会和现有的代码或其他库的代码重复，考虑不要真个引入而是把库的代码精简之后再引入。

三、内存泄漏优化

内存泄漏的原因有很多，下面介绍一些常见的，我们需要在开发中多注意：

Activity调用了finish，但是引用Activity的对象未被释放(生命周期没有结束)，Activity Context被传递到其他实例中，可能导致自身被引用而发生泄露，建议使用weakReferce。
除必须使用Activity Context的情况(Dialog的context必须是Activity),我们可以使用Application Context来避免Activity泄露。
大多数情况下，我们对Bitmap对象增加缓存机制，但是有时候部分bitmap需要及时回收。比如我们临时创建的摸个相对大的bitmap对象，变换得到新的bitmap对象后，尽快回收原始的bitmap，及时释放原来的空间。
webview引起的内存泄漏主要是因为org.chromium.android_webview.AwContents 类中注册了component callbacks，但是未正常反注册而导致的。让onDetachedFromWindow先走，在主动调用destroy()之前，把webview从它的parent上面移除掉(Basewebfragment onDestroy())
虽然单例模式简单实用，提供了很多便利性，但是因为单例的生命周期和应用保持一致，使用不合理很容易出现持有对象的泄漏。
我们在对数据库进行操作时，使用完cursor没有及时关闭，cursor的泄露，会对内存管理带来负面影响。
谨慎使用static对象，因为static的生命周期过长，和应用的进程保持一致，使用不当很可能导致对象泄漏。

总结：在实际的线上环境中发现，大部分内存泄漏是因为被调用的对象生命周期不同步导致，生命周期不同步不仅仅会导致内存泄漏，更会出现异常，崩溃等更严重的问题。

做好上面说的1、2、3就够了吗？

上篇文章我们已经从系统级别了解了Android Framework、Darlvik/Art虚拟机、Linux在内存分配上的原理，接着又在代码级别分别从减少内存占用、避免内存泄漏和代码优化三个方面介绍了如何避免内存问题，再加上当前科技发展是如此迅速，4GB内存已经是很常见的手机配置。LPDDR4X的高速闪存也越来越被广泛的使用。对于内存优化我们是不是就已经可以高枕无忧了，有上面这些就够了吗？

我想即使我们再了解内存，写的代码再好，用户的手机再先进，总还是有出错的时候，那么事后的内存分析和监控是必不可少的了！下一篇文章我们就来谈一谈内存分析和监控。