Android的bitmap和优化

内存管理是个永恒的话题！  

 http://www.trinea.cn/android/android-performance-demo/

http://www.cnblogs.com/killmyday/archive/2013/06/12/3132518.html      //android 内存管理原理

内存溢出：就是分配的内存不足以放下数据项序列。如在一个域中输入的数据超过了它的要求就会引发数据溢出问题，多余的数据就可以作为指令在计算机上运行。就是你要求分配的内存超出了系统能给你的，系统不能满足需求，于是产生溢出

内存泄漏：是指在堆上分配的内存没有被释放，从而失去对其控制。这样会造成程序能使用的内存越来越少，导致系统运行速度减慢，严重情况会使程序宕掉。

1.在Android应用里，最耗费内存的就是图片资源。而且在Android系统中，读取位图Bitmap时，分给虚拟机中的图片的堆栈大小只有    8M，如果超出了，就会出现OutOfMemory异常。
1) 要及时回收Bitmap的内存
Bitmap类有一个方法recycle()，从方法名可以看出意思是回收。这里就有疑问了，Android系统有自己的垃圾回收机制，可以不定期的回收掉不使用的内存空间，当然也包括Bitmap的空间。那为什么还需要这个方法呢？
Bitmap类的构造方法都是私有的，所以开发者不能直接new出一个Bitmap对象，只能通过BitmapFactory类的各种静态方法来实例化一个Bitmap。仔细查看BitmapFactory的源代码可以看到，生成Bitmap对象最终都是通过JNI调用方式实现的。所以，加载Bitmap到内存里以后，是包含两部分内存区域的。简单的说，一部分是Java部分的，一部分是C部分的。这个Bitmap对象是由Java部分分配的，不用的时候系统就会自动回收了，但是那个对应的C可用的内存区域，虚拟机是不能直接回收的，这个只能调用底层的功能释放。所以需要调用recycle()方法来释放C部分的内存。从Bitmap类的源代码也可以看到，recycle()方法里也的确是调用了JNI方法了。
那如果不调用recycle()，是否就一定存在内存泄露呢？也不是的。Android的每个应用都运行在独立的进程里，有着独立的内存，如果整个进程被应用本身或者系统杀死了，内存也就都被释放掉了，当然也包括C部分的内存。
Android对于进程的管理是非常复杂的。简单的说，Android系统的进程分为几个级别，系统会在内存不足的情况下杀死一些低优先级的进程，以提供给其它进程充足的内存空间。在实际项目开发过程中，有的开发者会在退出程序的时候使用Process.killProcess(Process.myPid())的方式将自己的进程杀死，但是有的应用仅仅会使用调用Activity.finish()方法的方式关闭掉所有的Activity。
经验分享：
Android手机的用户，根据习惯不同，可能会有两种方式退出整个应用程序：一种是按Home键直接退到桌面；另一种是从应用程序的退出按钮或者按Back键退出程序。那么从系统的角度来说，这两种方式有什么区别呢？按Home键，应用程序并没有被关闭，而是成为了后台应用程序。按Back键，一般来说，应用程序关闭了，但是进程并没有被杀死，而是成为了空进程（程序本身对退出做了特殊处理的不考虑在内）。
Android系统已经做了大量进程管理的工作，这些已经可以满足用户的需求。个人建议，应用程序在退出应用的时候不需要手动杀死自己所在的进程。对于应用程序本身的进程管理，交给Android系统来处理就可以了。应用程序需要做的，是尽量做好程序本身的内存管理工作。
一般，如果能够获得Bitmap对象的引用，就需要及时的调用Bitmap的recycle()方法来释放Bitmap占用的内存空间，而不要等Android系统来进行释放。
下面是释放Bitmap的示例代码片段。
// 先判断是否已经回收
if(bitmap != null && !bitmap.isRecycled()){ 
        // 回收并且置为null
        bitmap.recycle(); 
        bitmap = null; 
} 
System.gc();
从上面的代码可以看到，bitmap.recycle()方法用于回收该Bitmap所占用的内存，接着将bitmap置空，最后使用System.gc()调用一下系统的垃圾回收器进行回收，可以通知垃圾回收器尽快进行回收。这里需要注意，调用System.gc()并不能保证立即开始进行回收过程，而只是为了加快回收的到来。
如何调用recycle()方法进行回收已经了解了，那什么时候释放Bitmap的内存比较合适呢？一般来说，如果代码已经不再需要使用Bitmap对象了，就可以释放了。释放内存以后，就不能再使用该Bitmap对象了，如果再次使用，就会抛出异常。所以一定要保证不再使用的时候释放。比如，如果是在某个Activity中使用Bitmap，就可以在Activity的onStop()或者onDestroy()方法中进行回收。
2) 捕获异常
因为Bitmap是吃内存大户，为了避免应用在分配Bitmap内存的时候出现OutOfMemory异常以后Crash掉，需要特别注意实例化Bitmap部分的代码。通常，在实例化Bitmap的代码中，一定要对OutOfMemory异常进行捕获。
以下是代码示例。
Bitmap bitmap = null;
try {
    // 实例化Bitmap
    bitmap = BitmapFactory.decodeFile(path);
} catch (OutOfMemoryError e) {
}
if (bitmap == null) {
    // 如果实例化失败 返回默认的Bitmap对象
    return defaultBitmapMap;
}
这里对初始化Bitmap对象过程中可能发生的OutOfMemory异常进行了捕获。如果发生了OutOfMemory异常，应用不会崩溃，而是得到了一个默认的Bitmap图。
经验分享：
    很多开发者会习惯性的在代码中直接捕获Exception。但是对于OutOfMemoryError来说，这样做是捕获不到的。因为OutOfMemoryError是一种Error，而不是Exception。在此仅仅做一下提醒，避免写错代码而捕获不到OutOfMemoryError。
3) 缓存通用的Bitmap对象
有时候，可能需要在一个Activity里多次用到同一张图片。比如一个Activity会展示一些用户的头像列表，而如果用户没有设置头像的话，则会显示一个默认头像，而这个头像是位于应用程序本身的资源文件中的。
如果有类似上面的场景，就可以对同一Bitmap进行缓存。如果不进行缓存，尽管看到的是同一张图片文件，但是使用BitmapFactory类的方法来实例化出来的Bitmap，是不同的Bitmap对象。缓存可以避免新建多个Bitmap对象，避免内存的浪费。
经验分享：
    Web开发者对于缓存技术是很熟悉的。其实在Android应用开发过程中，也会经常使用缓存的技术。这里所说的缓存有两个级别，一个是硬盘缓存，一个是内存缓存。比如说，在开发网络应用过程中，可以将一些从网络上获取的数据保存到SD卡中，下次直接从SD卡读取，而不从网络中读取，从而节省网络流量。这种方式就是硬盘缓存。再比如，应用程序经常会使用同一对象，也可以放到内存中缓存起来，需要的时候直接从内存中读取。这种方式就是内存缓存。
4) 压缩图片
如果图片像素过大，使用BitmapFactory类的方法实例化Bitmap的过程中，需要大于8M的内存空间，就必定会发生OutOfMemory异常。这个时候该如何处理呢？如果有这种情况，则可以将图片缩小，以减少载入图片过程中的内存的使用，避免异常发生。
使用BitmapFactory.Options设置inSampleSize就可以缩小图片。属性值inSampleSize表示缩略图大小为原始图片大小的几分之一。即如果这个值为2，则取出的缩略图的宽和高都是原始图片的1/2，图片的大小就为原始大小的1/4。
如果知道图片的像素过大，就可以对其进行缩小。那么如何才知道图片过大呢？
使用BitmapFactory.Options设置inJustDecodeBounds为true后，再使用decodeFile()等方法，并不会真正的分配空间，即解码出来的Bitmap为null，但是可计算出原始图片的宽度和高度，即options.outWidth和options.outHeight。通过这两个值，就可以知道图片是否过大了。
    BitmapFactory.Options opts = new BitmapFactory.Options();
    // 设置inJustDecodeBounds为true
    opts.inJustDecodeBounds = true;
    // 使用decodeFile方法得到图片的宽和高
    BitmapFactory.decodeFile(path, opts);
    // 打印出图片的宽和高
    Log.d("example", opts.outWidth + "," + opts.outHeight);
在实际项目中，可以利用上面的代码，先获取图片真实的宽度和高度，然后判断是否需要跑缩小。如果不需要缩小，设置inSampleSize的值为1。如果需要缩小，则动态计算并设置inSampleSize的值，对图片进行缩小。需要注意的是，在下次使用BitmapFactory的decodeFile()等方法实例化Bitmap对象前，别忘记将opts.inJustDecodeBound设置回false。否则获取的bitmap对象还是null。
经验分享：
如果程序的图片的来源都是程序包中的资源，或者是自己服务器上的图片，图片的大小是开发者可以调整的，那么一般来说，就只需要注意使用的图片不要过大，并且注意代码的质量，及时回收Bitmap对象，就能避免OutOfMemory异常的发生。
如果程序的图片来自外界，这个时候就特别需要注意OutOfMemory的发生。一个是如果载入的图片比较大，就需要先缩小；另一个是一定要捕获异常，避免程序Crash。

2.一般来说，优秀的程序员在写完代码之后都会不断的对代码进行重构。重构的好处有很多，其中一点，就是对代码进行优化，提高软件的性能。下面我们就从几个方面来了解Android开发过程中的代码优化。

 1）静态变量引起内存泄露
在代码优化的过程中，我们需要对代码中的静态变量特别留意。静态变量是类相关的变量，它的生命周期是从这个类被声明，到这个类彻底被垃圾回收器回收才会被销毁。所以，一般情况下，静态变量从所在的类被使用开始就要一直占用着内存空间，直到程序退出。如果不注意，静态变量引用了占用大量内存的资源，造成垃圾回收器无法对内存进行回收，就可能造成内存的浪费。
先来看一段代码，这段代码定义了一个Activity。
private static Resources mResources; 
@Override
protected void onCreate(Bundle state) {
super.onCreate(state);
if (mResources == null) {
    mResources = this.getResources();
    }
}
这段代码中有一个静态的Resources对象。代码片段mResources = this.getResources()对Resources对象进行了初始化。这时Resources对象拥有了当前Activity对象的引用，Activity又引用了整个页面中所有的对象。如果当前的Activity被重新创建（比如横竖屏切换，默认情况下整个Activity会被重新创建），由于Resources引用了第一次创建的Activity，就会导致第一次创建的Activity不能被垃圾回收器回收，从而导致第一次创建的Activity中的所有对象都不能被回收。这个时候，一部分内存就浪费掉了。
经验分享：
在实际项目中，我们经常会把一些对象的引用加入到集合中，如果这个集合是静态的话，就需要特别注意了。当不需要某对象时，务必及时把它的引用从集合中清理掉。或者可以为集合提供一种更新策略，及时更新整个集合，这样可以保证集合的大小不超过某值，避免内存空间的浪费。
 2）使用Application的Context
在Android中，Application Context的生命周期和应用的生命周期一样长，而不是取决于某个Activity的生命周期。如果想保持一个长期生命的对象，并且这个对象需要一个Context，就可以使用Application对象。可以通过调用Context.getApplicationContext()方法或者Activity.getApplication()方法来获得Application对象。
依然拿上面的代码作为例子。可以将代码修改成下面的样子。
private static Resources mResources; 
@Override
protected void onCreate(Bundle state) {
super.onCreate(state);
if (mResources == null) {
    // mResources = this.getResources();
    mResources = this.getApplication().getResources();
    }
}
在这里将this.getResources()修改为this.getApplication().getResources()。修改以后，Resources对象拥有的是Application对象的引用。如果Activity被重新创建，第一次创建的Activity就可以被回收了。
3）及时关闭资源
Cursor是Android查询数据后得到的一个管理数据集合的类。正常情况下，如果我们没有关闭它，系统会在回收它时进行关闭，但是这样的效率特别低。如果查询得到的数据量较小时还好，如果Cursor的数据量非常大，特别是如果里面有
Blob信息时，就可能出现内存问题。所以一定要及时关闭Cursor。
下面给出一个通用的使用Cursor的代码片段。
Cursor cursor = null;
try{
    cursor = mContext.getContentResolver().query(uri,null,null,null,null);
    if (cursor != null) {
        cursor.moveToFirst();
        // 处理数据
    }
} catch (Exception e){
    e.printStatckTrace();
} finally {
    if (cursor != null){
        cursor.close();
    }
}
即对异常进行捕获，并且在finally中将cursor关闭。同样的，在使用文件的时候，也要及时关闭。
4）使用Bitmap及时调用recycle()
前面的章节讲过，在不使用Bitmap对象时，需要调用recycle()释放内存，然后将它设置为null。虽然调用recycle()并不能保证立即释放占用的内存，但是可以加速Bitmap的内存的释放。在代码优化的过程中，如果发现某个Activity用到了Bitmap对象，却没有显式的调用recycle()释放内存，则需要分析代码逻辑，增加相关代码，在不再使用Bitmap以后调用recycle()释放内存。
5）对Adapter进行优化
下面以构造ListView的BaseAdapter为例说明如何对Adapter进行优化。
在BaseAdapter类中提供了如下方法：
public View getView(int position, View convertView, ViewGroup parent)
当ListView列表里的每一项显示时，都会调用Adapter的getView方法返回一个View，
来向ListView提供所需要的View对象。
下面是一个完整的getView()方法的代码示例。
public View getView(int position, View convertView, ViewGroup parent) {
　　ViewHolder holder;
if (convertView == null) {
　　    convertView = mInflater.inflate(R.layout.list_item, null);
　　    holder = new ViewHolder();
　　    holder.text = (TextView) convertView.findViewById(R.id.text);
　　    convertView.setTag(holder);
　　} else {
　　    holder = (ViewHolder) convertView.getTag();
　　}
　　holder.text.setText("line" + position);
　　return convertView;
}
private class ViewHolder {
　　TextView text;
}
当向上滚动ListView时，getView()方法会被反复调用。getView()的第二个参数convertView是被缓存起来的List条目中的View对象。当ListView滑动的时候，getView可能会直接返回旧的convertView。这里使用了convertView和ViewHolder，可以充分利用缓存，避免反复创建View对象和TextView对象。如果ListView的条目只有几个，这种技巧并不能带来多少性能的提升。但是如果条目有几百甚至几千个，使用这种技巧只会创建几个convertView和ViewHolder（取决于当前界面能够显示的条目数），性能的差别就非常非常大了。
6）代码“微优化”
    当今时代已经进入了“微时代”。这里的“微优化”指的是代码层面的细节优化，即不改动代码整体结构，不改变程序原有的逻辑。尽管Android使用的是Dalvik虚拟机，但是传统的Java方面的代码优化技巧在Android开发中也都是适用的。
还有其他：
创建新的对象都需要额外的内存空间，要尽量减少创建新的对象。
将类、变量、方法等等的可见性修改为最小。
针对字符串的拼接，使用StringBuffer替代String。
不要在循环当中声明临时变量，不要在循环中捕获异常。
如果对于线程安全没有要求，尽量使用线程不安全的集合对象。
使用集合对象，如果事先知道其大小，则可以在构造方法中设置初始大小。
文件读取操作需要使用缓存类，及时关闭文件。
慎用异常，使用异常会导致性能降低。
如果程序会频繁创建线程，则可以考虑使用线程池。
7.if(cursor!=null&&!cursor.isClosed()){

        cursor.close();
        }
-------------------------------------------------------------
handler.postDelayed(new Runnable(){
@Override
public void run() {
     mLoadingLayout.setVisibility(View.VISIBLE);
     }
            
   }, 1000);
-----------------------------------------------------------------
            numFlag += 1;
                    mMenu = 0;
                    if(numFlag < 4){
                    Message msg = new Message();
                        msg.arg1 = ISTouchSystemMessageID.TYPE.INSIDE;
                        msg.arg2 = InsideMessageID.ADD_DATA;
                    msg.obj = mPosterInfo;
                        mHandler.sendMessage(msg);
                    }
代码的微优化有很多很多东西可以讲，小到一个变量的声明，大到一段算法。尤其在代码Review的过程中，可能会反复审查代码是否可以优化。不过我认为，代码的微优化是非常耗费时间的，没有必要从头到尾将所有代码都优化一遍。开发者应该根据具体的业务逻辑去专门针对某部分代码做优化。比如应用中可能有一些方法会被反复调用，那么这部分代码就值得专门做优化。其它的代码，需要开发者在写代码过程中去注意。

（http://blog.csdn.net/jdsjlzx/article/details/7871516）

2.线程惹的祸  
线程也是造成内存泄露的一个重要的源头。线程产生内存泄露的主要原因在于线程生命周期的不可控。我们来考虑下面一段代码。  
public class MyActivity extends Activity {      
@Override      
public void onCreate(Bundle savedInstanceState) {          
  super.onCreate(savedInstanceState);          
  setContentView(R.layout.main);          
  new MyThread().start();      
}        
private class MyThread extends Thread{          
@Override          
  public void run() {              
  super.run();    
    }      
  }  
}   
    这段代码很平常也很简单，是我们经常使用的形式。我们思考一个问题：假设MyThread的run函数是一个很费时的操作，当我们开启该线程后，将设备的 横屏变为了竖屏，一般情况下当屏幕转换时会重新创建Activity，按照我们的想法，老的Activity应该会被销毁才对，然而事实上并非如此。  

    由于我们的线程是Activity的内部类，所以MyThread中保存了Activity的一个引用，当MyThread的run函数没有结束 时，MyThread是不会被销毁的，因此它所引用的老的Activity也不会被销毁，因此就出现了内存泄露的问题。

这种线程导致的内存泄露问题应该如何解决呢？ 
    第一、将线程的内部类，改为静态内部类。 
    第二、在线程内部采用弱引用保存Context引用。 
    另外，Hanlder是线程与Activity通信的桥梁，我们在开发好多应用中会用到线程，有些人处理不当，会导致当程序结束时，线程并没有 被销毁，而是一直在后台运行着，当我们重新启动应用时，又会重新启动一个线程，周而复始，你启动应用次数越多，开启的线程数就越多，你的机器就会变得越慢。 
package com.tutor.thread;  
public class ThreadDemo extends Activity {  
    private static final String TAG = "ThreadDemo";  
    private int count = 0;  
    private Handler mHandler =  new Handler();  
    private Runnable mRunnable = new Runnable() {    
        public void run() {  
            count++;  
            setTitle("" +count);  
            //每2秒执行一次   
            mHandler.postDelayed(mRunnable, 2000);  
        }          
    };  
    @Override  
    public void onCreate(Bundle savedInstanceState) {  
        super.onCreate(savedInstanceState);  
        setContentView(R.layout.main);   
        //通过Handler启动线程   
        mHandler.post(mRunnable);  
    }        
} 
所以我们在应用退出时，要将线程销毁，我们只要在Activity中的，onDestory()方法处理一下就OK了，如下代码所示: 
  @Override  
  protected void onDestroy() {  
    mHandler.removeCallbacks(mRunnable);  
    super.onDestroy();  
  } 

====java性能小技巧====

1.避免重复创建对象
更少的对象会需要更少的垃圾回收，使用的空间越少，应用的性能越好
怎么做：
重复利用一个对象，而不是在每次需要的时候都去创建一个功能一样的对象（这样做）

String s = “No longer silly”;
（不要这样）
String s = new String(“silly”);
不可变类中既提供构造函数，又提供了静态工厂方法的，优先考虑使用静态工厂方法。复用那些一旦初始化（使用静态初始化）就不会改变的对象
2.避免循环引用
一组相互引用的对象，如果他们没有被其他对象直接引用的话，它们会变得不可达，这样会导致它们一直都保留在内存里。
怎么做：
你可以使用强引用来表示“父到子“的引用关系，使用弱引用来表示“子到父”的引用关系。
3.使用==操作符来替代equals(Object)方法
==操作符的性能更好
例如，对于字符串比较，equals()方法会去比较字符串对象里的字符。==操作符会比较两个对象的引用，来比较它们是否指向同一个实例。
怎么做：
当且仅当a == b 的时候才会有a.equals(b)
例如，对于重复调用的地方，使用静态工厂方法来返回相同的对象。
4.清除无用的对象的引用 为什么：
无用的对象引用会导致更多的垃圾回收动作，从而降低性能
无用的对象引用会导致更多的内存占用，从而降低性能
怎么做：
如果一个引用时废弃的话，把它设置为null（这样做）
public Object pop() {
    if (size == 0)
        throw new EmptyStackException();
    Object result = elements[--size];
    elements[size] = null;  // 清除无用对象的引用
    return result;
}
（不要这样）
public Object pop(){
    if (size == 0)
        throw new EmptyStackException();
    return elements[--size];
}
5.避免使用finalizer
垃圾回收器需要单独记录等待终结的对象
调用finalize方法也有一定的开销
Finalizer是不安全的，因为它有可能会复活一个对象，这样会干扰垃圾回收。
6.避免使用引用对象
和finalizer一样，垃圾回收器需要特别处理软引用、弱引用以及幽灵引用。
尽管引用对象在某些方面很有作用，例如，简化cache的实现，但是大量引用对象的存在会使得垃圾回收运行缓慢。
记录一个引用对象的开销远远超过一个普通对象（强引用）的开销
7.避免使用对象池
对象池不仅会使得更多的数据对象保持活动，同时会使得对象的存活时间延长
值得注意的是，大量存活的数据对象的处理是GC的瓶颈，GC被优化成适合于处理许多寿命较短的对象
并且，创建新的对象而不是保持旧的对象存活，会对缓存的局部性有益
不过，在一个包含大量大对象的环境下，例如大的数组，性能或许会因为使用对象池而有所提升。
8.选择好的算法和数据结构
考虑一下通过链表来实现队列的场景
即使你的程序不需要遍历整个链表，但是垃圾回收器还是需要这样做的。
如果元素的封装者没有把元素没有把元素放在内存中邻近的位置，这样会破坏缓存局部性。因而会导致程序长时间的暂停，尤其是对象的指针分散在一个很大的堆区时，垃圾回收器会在标记阶段追随指针的时候频繁遭遇缓存失效。
9.避免使用System.gc
Java语言规范里没有保证调用System.gc会做什么事情。如果它规定了的话，或许会超出你的期望，也或许每次调用都做不同的事情。
10.避免使用太多的线程
进程上下文切换的次数会随着要调度的进程的数目相应地增长，这样会对性能有隐性的影响。
例如，Intel A-64处理器上的本地线程上下文的大小大概是几千KB
11.避免使用竞争锁
竞争锁一般都是程序的瓶颈，因为它的出现意味着多个线程想访问同一个资源或者执行同一段代码。
12避免不需要的异常
异常处理会占用一定的事件，并且会打断程序的正常执行流程。
作者曾经遇到这样一场景，在客户的应用里，一个正常的执行流程每秒会抛出成千上万的NullPointerException。这个错误被纠正后，应用的性能里面有了一个数量级的提升。
13.避免使用大对象
大对象有时候需要直接在堆而不是在线程本地存储区（thread local areas, TLA）进行内存分配。
大对象直接在堆上分配是有坏处的，因为它会更快地产生内存碎片。
在虚拟机（例如JRockit）上分配大对象会降低性能，因为分配内存的时候会使用堆的全局锁。
过度使用大对象会造成频繁的全栈压缩，这样做是具有破坏性的，而且这样会导致导致所有的线程暂停很长一段时间。