RAM（Random-access memory）在任何软件开发中都是非常宝贵的资源，移动操作系统由于其物理内存的局限性更是如此。尽管ART（Android Runtime）与Dalvik虚拟机会执行常规的垃圾回收，但这并不意味着可以忽略App中的内存分配与释放。我们应当避免引起内存泄露，如持有静态成员变量而导致无法释放，应当在应用的生命周期回调中释放掉所有的引用。
本文为慕课网App性能优化之内存优化课程的学习笔记。
常用内存分析工具
在实现内存优化之前，我们必须能很好的认识到这些问题。所以，我们很有必要学习使用一些常见的内存分析工具。
1. android Studio 中的Monitors
通过该工具，可以之间直观的看出内存、cpu、网络等使用的具体情况。如图：
montiors.png
2. android Device Monitor 工具查看
有时候，通过Monitors并不能完全满足我们的要求，这个时候我们可以使用功能更加强大的android Device Monitor来进行查看。
Paste_Image.png
可以看到，通过android Device Monitor 查看到的信息更加丰富。参数还是比较简单，就不做介绍了。
3. 通过adb命令来查看相关信息
当然，这个会比较好玩。重点介绍以下怎么通过命令行的形式来查看我们的app内存使用情况。
我们这里直接通过Terminal工具来输入命令。
- 输入
adb shell进入虚拟机 - 输入
ps查看当前进程
Paste_Image.png - 选择我们需要查看的进程。输入
dumpsys meminfo + 包名来显示我们要查看的信息。
Paste_Image.png
如此，我们便能通过adb 查看到当前手机app的运行情况了。
Pase.png
4. 通过代码来检测
通过工具来检测我们app的内存比较简单。同时google也开发者提供了api来让我们直接在代码中进行内存监控。
我们可以通过下面的代码来查看应用当前的内存情况：
ActivityManager manager = (ActivityManager) getSystemService(ACTIVITY_SERVICE);
int memory = manager.getMemoryClass();//获取内存信息
int large = manager.getLargeMemoryClass();//获取最大内存信息
double totalmemory = Runtime.getRuntime().totalMemory()*1.0f/(1024*1024);//获取运行时总共的内存
double maxmemory = Runtime.getRuntime().maxMemory()*1.0f/(1024*1024);//获取运行的最大内存
double freememory = Runtime.getRuntime().freeMemory()*1.0f/(1024*1024);//获取运行时剩余的内存
内存基本知识梳理
android系统内存分配与回收方式。
- 一个App通常就是一个进程，对应一个虚拟机。
- GC在Heap剩余空间不足的时候才触发。
- GC触发时，所有线程都会暂停，极端情况下会发生线程抖动。
切换应用时后台app清理机制
- app切换时使用的是LRU Cache策略
- onTrimMemory()回调方法
在系统清理（或者内存变化)的时候会回调activity中in个的OnTrimMemory（int level）方法。我们可以在此时进行判断，如果系统内存不足了，就清理掉应用的一些不用的内存来使应用的占用内存变小，减少被系统清理掉的可能性。当然，leve也有不同的级别，详细可以参看这里。
几点关键性的建议
- 频繁字符串拼接用StringBuilder
- 用ArrayMap、SparseArray代替HaspMap。
- 避免内存抖动
- 避免无谓的class（再小的clas也要耗费0.5k空间）
- HaspMap的一个entry需要额外占用32b控件
对象复用
- 复用系统自带的资源
- ListView/GridView/Recyclerview的Conview复用
- 避免在OnDraw方法里执行对象的创建。
避免内存泄露
内存泄露：
由于代码的问题，导致这块内存，虽然是停止不用了，但依然被其他的东西应用着，使得GC没法对他回收。
- 内存泄露会导致剩余可用的Heap越来越少，频繁触发GC。
- 尤其是Activity的内存泄露问题（）
- 用Application Context代替Activity Context。
- 注意即使关闭Cursor对象、
- 通过使用弱引用避免内存泄露
类似于private SoftReference<String> softref;声明的软引用，在其生命周期内，在不使用的提前下，GC是可以对其进行回收的。通过图片的加载来说明软引用的用法：
private Map<String, SoftReference<Bitmap>> imageCache =
new HashMap<String, SoftReference<Bitmap>>();
public void addBitmapToCache(String path) {
// 强引用的Bitmap对象
Bitmap bitmap = BitmapFactory.decodeFile(path);
// 软引用的Bitmap对象
SoftReference<Bitmap> softBitmap = new SoftReference<Bitmap>(bitmap);
//WeakReference<Bitmap> weakBitmap=new WeakReference<Bitmap>(bitmap);
TranslateAnimation animation;
// 添加该对象到Map中使其缓存
imageCache.put(path, softBitmap);
}
public Bitmap getBitmapByPath(String path) {
// 从缓存中取软引用的Bitmap对象
SoftReference<Bitmap> softBitmap = imageCache.get(path);
// 判断是否存在软引用
if (softBitmap == null) {
return null;
}
// 取出Bitmap对象，如果由于内存不足Bitmap被回收，将取得空
return softBitmap.get();
}
优化OOM（out of memory）
- 注意零时Bitmap对象的及时回收。
- 避免Bitmap浪费
- Try-Cartch 某些大内存分配操作、
- 加载Bitmap优化策略：缩放比例、解码格式、局部加载。
下面通过两个实例代码来距离说明内存优化。
我们知道，内存优化主要针对的对象是图片，因为图片占局的内存比较多。下面就通过一个实例说明如何通过软引用来管理多张图片。
public class BitmapCache {
static private BitmapCache cache;
private ArrayMap<String,MySoftRe> hashRef;
//软引用被回收后，回收对象放在这，可以查看哪些被回收了
private ReferenceQueue<Bitmap> queue;
//
private BitmapCache(){
hashRef=new ArrayMap<>();
queue=new ReferenceQueue<>();
}
/*
继承SoftReference，使得每一个实例都具有可识别的标识
*/
private class MySoftRe extends SoftReference<Bitmap> {
private String key="";
public MySoftRe(Bitmap referent, ReferenceQueue<? super Bitmap> q,String key) {
super(referent, q);
this.key=key;
}
}
public static BitmapCache getInstance(){
if (cache==null){
cache=new BitmapCache();
}
return cache;
}
/*
以软引用的方式对一个bitmap对象的实例进行引用并保存该引用
*/
public void addCacheBitmap(String key, Bitmap bitmap){
cleanCache();//清除立即引用
MySoftRe msf=new MySoftRe(bitmap,queue,key);
hashRef.put(key,msf);
}
/**
* 依据所指定的drawable下的图片资源ID号，（可以根据自己的需要从网络或者本地path下获取），重新获取相应的BItymap对象实例
*
* @param key 资源ID
* @return bitmap对象
*/
public Bitmap getBitmap(String key){
Bitmap bitmap=null;
try {
//缓存中是否有该Bitmap实例的软引用，如果有，从软引用中取得
if (hashRef.containsKey(key)){
MySoftRe msf=hashRef.get(key);
bitmap=msf.get();
}
return bitmap;
}catch (NullPointerException e){
return null;
}
//如果没有软引用，或者从软引用中得到的实例是null，重新构建一个实例
//并保存对这个新建实例的软引用
}
private void cleanCache() {
MySoftRe msf=null;
while ((msf= (MySoftRe) queue.poll())!=null){
hashRef.remove(msf.key);
}
}
/**
* 清除软引用的全部内容
*/
public void clearCache(){
cleanCache();
hashRef.clear();
System.gc();
System.runFinalization();
}
}
上面多多张图片的加载并没有使用任何的算法，下面我们尝试优化一下图片加载的策略（使用LRU算法）来进行图片的加载：
public class MemoryCache {
private static final String TAG="MemoryCache";
//LinkedHashMap专门用来构建LRU算法,但是线程不安全
private Map<String,Bitmap> cache= Collections.synchronizedMap(
new LinkedHashMap<String, Bitmap>(8,0.75f,true));
private long size=0;//MemoryCache已经分配的大小
private long limit=1000000;//最大的内存限制
public MemoryCache(){
setLimit(Runtime.getRuntime().maxMemory()/4);
}
private void setLimit(long l) {
limit=l;
Log.d(TAG,"MemoryCache will use up to"+limit/1024/1024+"MB");
}
public Bitmap get(String id){
try {
if (!cache.containsKey(id)){
return null;
}
return cache.get(id);
}catch (NullPointerException e){
return null;
}
}
public void put(String id,Bitmap bitmap){
try {
if (cache.containsKey(id)){
size-=getSizeInBytes(cache.get(id));
//把原来的图片覆盖
}
cache.put(id,bitmap);
size+=getSizeInBytes(bitmap);
checkSize();
}catch (Throwable th){
th.printStackTrace();
}
}
private void checkSize() {
Log.i(TAG,"cache size="+size+"length="+cache.size());
if (size>limit){
Iterator<Map.Entry<String,Bitmap>> iterator=cache.entrySet().iterator();
while (iterator.hasNext()){
Map.Entry<String,Bitmap> entry=iterator.next();
size-=getSizeInBytes(entry.getValue());
iterator.remove();
if (size<=limit){
break;
}
}
Log.d(TAG,"Clean cache,new size="+cache.size());
}
}
private long getSizeInBytes(Bitmap bitmap) {
if (bitmap==null) {
return 0;
}
return bitmap.getRowBytes()*bitmap.getHeight();
}
public void clear(){
cache.clear();
}
}
