android内存优化

访问成员变量比访问本地变量慢得多，下面一段代码：

for ( int  i = 0 ; i < this .mCount; i++)  {
dumpItem( this .mItems);
}

最好改成这样：

int  count = this .mCount;
Item[] items = this .mItems;
for ( int  i = 0 ; i < count; i++)  {
       dumpItems(items);
}

　　另一个相似的原则是：永远不要在for的第二个条件中调用任何方法。如下面方法所示，在每次循环的时候都会调用getCount()方法，这样做比你在一个int先把结果保存起来开销大很多。

for ( int  i = 0 ; i < this .getCount(); i++) {
dumpItems( this .getItem(i));
}

　　同样如果你要多次访问一个变量，也最好先为它建立一个本地变量，例如：

protected  void  drawHorizontalScrollBar(Canvas canvas, int  width, int  height) {
if (isHorizontalScrollBarEnabled()) {
intsize = mScrollBar.getSize( false );
if (size <= 0 ) {
       size = mScrollBarSize;
}
mScrollBar.setBounds( 0 , height - size, width, height);
mScrollBar.setParams(computeHorizontalScrollRange(), computeHorizontalScrollOffset(), computeHorizontalScrollExtent(), false );
mScrollBar.draw(canvas);
}
}

　　这里有4次访问成员变量mScrollBar，如果将它缓存到本地，4次成员变量访问就会变成4次效率更高的栈变量访问。

　　另外就是方法的参数与本地变量的效率相同。

6)       针对ListView的性能优化

                    i.    复用convertView。

                    ii.    在getItemView中，判断convertView是否为空，如果不为空，可复用。如果couvertview中的view需要添加 listerner，代码一定要在if(convertView==null){}之外。

                   iii.    异步加载图片，item中如果包含有web image，那么最好异步加载。

                    iv.    快速滑动时不显示图片

　　　　　　　　　　当快速滑动列表时（SCROLL_STATE_FLING），item中的图片或获取需要消耗资源的view，可以不显示出来；而处于其他两种状 态（SCROLL_STATE_IDLE 和SCROLL_STATE_TOUCH_SCROLL），则将那些view显示出来。

                      v.    item尽可能的减少使用的控件和布局的层次；背景色与cacheColorHint设置相同颜色；ListView中item的布局至关重要，必须尽可 能的减少使用的控件，布局。　　　　　　　　　　　　　RelativeLayout是绝对的利器，通过它可以减少布局的层次。同时要尽可能的复用控件，这样可以减少 ListView的内存使用，减少滑动时gc次数。ListView的背景色与cacheColorHint设置相同颜色，可以提高滑动时的渲染性能。

                      vi.    getView优化

　　　　　　　　ListView中getView是性能是关键，这里要尽可能的优化。getView方法中要重用view；getView方法中不能做复杂的逻辑计算，特别是数据库和网络访问操作，否则会严重影响滑动时的性能。优化如下所示：

@Override
public View getView(int position, View convertView, ViewGroup parent) {
       Log.d("MyAdapter", "Position:" + position + "---" + String.valueOf(System.currentTimeMillis()));
       final LayoutInflater inflater = (LayoutInflater) mContext.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
       View v = inflater.inflate(R.layout.list_item_icon_text, null);
       ((ImageView) v.findViewById(R.id.icon)).setImageResource(R.drawable.icon);
       ((TextView) v.findViewById(R.id.text)).setText(mData[position]);
       return v;
}

建议改为：

@Override
public View getView(int position, View convertView, ViewGroup parent) {
       Log.d("Adapter", "Position:" + position + " : " + String.valueOf(System.currentTimeMillis()));
       ViewHolder holder;
       if (convertView == null) {
              final LayoutInflater inflater = (LayoutInflater) mContext.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
              convertView = inflater.inflate(R.layout.list_item_icon_text, null);
              holder = new ViewHolder();
             holder.icon = (ImageView) convertView.findViewById(R.id.icon);
             holder.text = (TextView) convertView.findViewById(R.id.text);
             convertView.setTag(holder);
       } else {
             holder = (ViewHolder) convertView.getTag();
       }
              holder.icon.setImageResource(R.drawable.icon);
              holder.text.setText(mData[position]);
              return convertView;
       }
 
       static class ViewHolder {
               ImageView icon;
               TextView text;
       }
}

　　以上是Google IO大会上给出的优化建议，经过尝试ListView确实流畅了许多。使用1000条记录，经测试第一种方式耗时：25211ms，第二种方式耗时：16528ms。

2)       数据压缩

传输数据经过压缩 目前大部门网站都支持GZIP压缩，所以在进行大数据量下载时，尽量使用GZIP方式下载，可以减少网络流量，一般是压缩前数据大小的30%左右。

HttpGet request = new HttpGet("http://example.com/gzipcontent");
HttpResponse resp = new DefaultHttpClient().execute(request);
HttpEntity entity = response.getEntity();
InputStream compressed = entity.getContent();
InputStream rawData = new GZIPInputStream(compressed);

加载位图原理分析

1、BitmapFactory提供了几种解码方式(decodeByteArray(), decodeFile(), decodeResource()等等)，以便从多种资源中创建一个Bitmap(位图)对象。可以根据你的图片数据来源选择最合适的解码方式。这些方法视图为构造Bitmap对象分配内存，因此很容易导致OutOfMemory(OOM)异常。每一种解码方式都有额外的特征，你可以通过BitmapFactory.Options类类指定解码方法。

2、尽量不要使用setImageBitmap或setImageResource或BitmapFactory.decodeResource直接使用图片路径来设置一张大图，因为这些函数在完成decode后，最终都是通过java层的createBitmap来完成的，需要消耗更多内存。改用先通过BitmapFactory.decodeStream方法，创建出一个bitmap，再调用上述方法将其设为ImageView的source。decodeStream最大的秘密在于其直接调用JNI>>nativeDecodeAsset()来完成decode，无需再使用java层的createBitmap，从而节省了java层的空间。下面是使用InputStream加载图片的几种方法：

使用BitmapFactory的decodeResource方法会占据大量内存，
　　而使用使用decodeStream方法，则占据更小的内存。
　　从时间上来说，看看日志输出，大概估算了一下加载一张图片所需要的时间，发现，
　　decodeResource加载图片需要约0.17秒的时间，
　　而使用decodeStream方法，只需要约0.08秒的时间!
　　这说明了，decodeStream无论是时间上还是空间上，都比decodeResource方法更优秀!!

 Drawable和Bitmap的区别
Drawable占用空间小，但显示的清晰度相同，绘制速度Drawable快，但是Drawable不支持像素操作。

解决方案：
private ImageView preview;
//1.加载位图
String path = Environment.getExternalStorageDirectory().toString()+"/DCIM/device.png";
inputStream is = new FileInputStream(path)

//2.为位图设置100K的缓存
BitmapFactory.Options opts=new BitmapFactory.Options();
opts.inTempStorage = new byte[100 * 1024];

//3.设置位图颜色显示优化方式
//ALPHA_8：每个像素占用1byte内存（8位）
//ARGB_4444:每个像素占用2byte内存（16位）
//ARGB_8888:每个像素占用4byte内存（32位）
//RGB_565:每个像素占用2byte内存（16位）
//Android默认的颜色模式为ARGB_8888，这个颜色模式色彩最细腻，显示质量最高。但同样的，占用的内存//也最大。也就意味着一个像素点占用4个字节的内存。我们来做一个简单的计算题：3200*2400*4 bytes //=30M。如此惊人的数字！哪怕生命周期超不过10s，Android也不会答应的。

opts.inPreferredConfig = Bitmap.Config.RGB_565;

//4.设置图片可以被回收，创建Bitmap用于存储Pixel的内存空间在系统内存不足时可以被回收
opts.inPurgeable = true;

//5.设置位图缩放比例。width，hight设为原来的四分一（该参数请使用2的整数倍）,这也减小了位图占用的内存大小；例如，一张//分辨率为2048*1536px的图像使用inSampleSize值为4的设置来解码，产生的Bitmap大小约为//512*384px。相较于完整图片占用12M的内存，这种方式只需0.75M内存(假设Bitmap配置为//ARGB_8888)。

opts.inSampleSize = 4;

//6.设置解码位图的尺寸信息
opts.inInputShareable = true; 
Bitmap btp =BitmapFactory.decodeStream(is,null, opts);    
preview.setImageBitmap(bitmap);

一般来说，如果能够获得Bitmap对象的引用，就需要及时的调用Bitmap的recycle()方法来释放Bitmap占用的内存空间，而不要等Android系统来进行释放。

下面是释放Bitmap的示例代码片段。

// 先判断是否已经回收 if(bitmap != null && !bitmap.isRecycled()){          // 回收并且置为null         bitmap.recycle();          bitmap = null;  }  System.gc();

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。

 

构造adapter没有使用缓存contentview。  
    在继承BaseAdapter时会让我们重写getView(int position, View   convertView, ViewGroup parent)方法， 
    第二个参数convertView就是我们要用到的重用的对象 

 @Override
 public View getView(int position, View convertView, ViewGroup parent) {
     ViewHolder vHolder = null;
                //如果convertView对象为空则创建新对象，不为空则复用
     if (convertView == null) {
         convertView = inflater.inflate(..., null);
         // 创建 ViewHodler 对象
         vHolder = new ViewHolder();
         vHolder.img= (ImageView) convertView.findViewById(...);
         vHolder.tv= (TextView) convertView
                 .findViewById(...);
         // 将ViewHodler保存到Tag中
         convertView.setTag(vHolder);
     } else {
                        //当convertView不为空时，通过getTag()得到View
         vHolder = (ViewHolder) convertView.getTag();
     }
     // 给对象赋值，修改显示的值
     vHolder.img.setImageBitmap(...);
     vHolder.tv.setText(...);
     return convertView;
 }
        //将显示的View 包装成类
 static class ViewHolder {
     TextView tv;
     ImageView img;
 }

    这里只讲使用方法，具体性能测试文章请见： 
    ListView中getView的原理＋如何在ListView中放置多个item 
    http://www.cnblogs.com/xiaowenji/archive/2010/12/08/1900579.html 
    Android开发之ListView适配器（Adapter）优化 
    http://shinfocom.iteye.com/blog/1231511 
3.调用registerReceiver()后未调用unregisterReceiver().  
     广播接收者（BroadcastReceiver）经常在应用中用到，可以在多线程任务完成后发送广播通知UI更新，也可以接收系统广播实现一些功能 
     可以通过代码的方式注册： 
    IntentFilter postFilter = new IntentFilter(); 
    postFilter.addAction(getPackageName() + ".background.job"); 
    this.registerReceiver(receiver, postFilter); 
    当我们Activity中使用了registerReceiver()方法注册了BroadcastReceiver，一定要在Activity的生命周期内调用unregisterReceiver()方法取消注册 
    也就是说registerReceiver()和unregisterReceiver()方法一定要成对出现，通常我们可以重写Activity的onDestory()方法： 

 @Override
 protected void onDestroy() {
       this.unregisterReceiver(receiver);
       super.onDestroy();
 }

4.未关闭InputStream/OutputStream。  
    这个就不多说了，我们操作完输入输出流都要关闭流 

 

5.Context泄漏。 这是一个很隐晦的OutOfMemoryError的情况。先看一个Android官网提供的例子： 

 private static Drawable sBackground;
 @Override
 protected void onCreate(Bundle state) {
   super.onCreate(state);

   TextView label = new TextView(this);
   label.setText("Leaks are bad");

   if (sBackground == null) {
     sBackground = getDrawable(R.drawable.large_bitmap);
   }
   label.setBackgroundDrawable(sBackground);

   setContentView(label);
 }

    这段代码效率很快，但同时又是极其错误的； 

在第一次屏幕方向切换时它泄露了一开始创建的Activity。当一个Drawable附加到一个 View上时， 
    View会将其作为一个callback设定到Drawable上。上述的代码片段，意味着Drawable拥有一个TextView的引用， 
    而TextView又拥有Activity（Context类型）的引用，换句话说，Drawable拥有了更多的对象引用。即使Activity被 销毁，内存仍然不会被释放。 
    另外，对Context的引用超过它本身的生命周期，也会导致Context泄漏。所以尽量使用Application这种Context类型。 
    这种Context拥有和应用程序一样长的生命周期，并且不依赖Activity的生命周期。如果你打算保存一个长时间的对象， 
    并且其需要一个 Context，记得使用Application对象。你可以通过调用Context.getApplicationContext()或 Activity.getApplication()轻松得到Application对象。 
    最近遇到一种情况引起了Context泄漏，就是在Activity销毁时，里面有其他线程没有停。 
    总结一下避免Context泄漏应该注意的问题： 
    1.使用Application这种Context类型。 
    2.注意对Context的引用不要超过它本身的生命周期。 
    3.慎重的使用“static”关键字。 
    4.Context里如果有线程，一定要在onDestroy()里及时停掉。 

1. WebView  控件：

使用了 WebView 控件一定要注意清理缓存  destroy() 方法，但之前必须调用 removeAllViews() 要不然有时出错

1 myWebView.removeAllViews();
2 myWebView.destroy();

2.线程

在退出活动窗口时一定要注意开启的线程是否已经关闭，可以在debug查看线程的开启情况。

如果只是刷新Ui线程 建议不用线程可以使用 Handler 来刷新 方法如下。这种方法只能做简单的操作，复杂操作建议使用线程。

01 private Handler _ui_handler = new Handler() {
02
03     @Override
04     public void handleMessage(Message msg) {
05
06     switch (msg.what) {
07         case 0://下面你可以写你需要处理的代码
08                 _ui_handler .sendEmptyMessageDelayed(0,1000)//1000 为延时发送的时间 单位是毫秒
09         break;
10         }
11     }
12 }

(四) 释放对象的引用

描述：

    这种情况描述起来比较麻烦，举例子进行说明。

假设有如下操作

public class DemoActivity extends Activity {

    ... ...

    private Handler mHandler = ...

    private Object obj;

    public void operation() {

     obj = initObj();

     ...

     [Mark]

     mHandler.post(new Runnable() {

            public void run() {

             useObj(obj);

            }

     });

    }

}

    我们有一个成员变量 obj，在operation()中我们希望能够将处理obj实例的操作post到某个线程的MessageQueue中。在以上的代码中，即便是mHandler所在的线程使用完了obj所引用的对象，但这个对象仍然不会被垃圾回收掉，因为DemoActivity.obj还保有这个对象的引用。所以如果在DemoActivity中不再使用这个对象了，可以在[Mark]的位置释放对象的引用，而代码可以修改为：

... ...

public void operation() {

    obj = initObj();

    ...

    final Object o = obj;

    obj = null;

    mHandler.post(new Runnable() {

        public void run() {

            useObj(o);

        }

    }

}

... ...

三、内存监测工具 DDMS --> Heap 5

四、内存分析工具 MAT(Memory Analyzer Tool) 7

目标屏幕尺寸及解决方法

在Android世界里目前有超过100种的不同屏幕尺寸，但解决方法也很丰富。为使你的应用适应不同的屏幕配置有两件事情你需要确定：你对不同的屏幕尺寸有一个好的布局和结构你的图像在不同分辨率下工作良好

这些都是独立的任务，你可能有一个超级的tablet布局，但上面的图形看起来很糟糕。我们会依次讨论他们。

为不同的屏幕而设计

1.通常会用ScrollView 和 ListView 轻松搞定

当我们有一系列不同尺寸的大屏手机时，它们之间最大的不同就是屏幕的高度。因此ScrollView和ListView通常可是有效的工作，虽然有时它们并不能完全覆盖全部屏幕。在OpenSignal中的Dashboard标签下我们可以看到所有部件一气呵成，不存在滑动、对于许多高级类型标签中，滑动展示并不见得是一件坏事。如果你能够为你所有的设计匹配到各种屏幕上面去，那么最好不过。否则，这两个控件会让你用最小的开发代价来保证你的软件在大多数屏幕上正常展示。

Dashboard style 的设计不需要scroll

2: 使用文件夹. Android 的资源文件夹结构非常强大, 它允许开发者将不同的图片、字符串、布局文件、外形、颜色这些资源，在api、代码、屏幕尺寸等部分. 下面是一个例子，展示了在资源文件夹下你可以怎样做:

在 values-small 文件夹中存放了一个 bools.xml 文件, 文件中有如下几行代码:123true

在代码中我可这样引用:123if(getResources().getBoolean(R.bool.small_screen)){getSupportActionBar().hide();}

在小尺寸设备中boolean值将置为true 我此时将因此ActionBar来节省空间. 这段代码正是非凡的ActionBarSherlock 扩展库中的一部分,稍后再详细介绍. 在values-sw360dp文件夹中，存放对应屏幕宽于360dp的资源文件。与上面相同的位置，有如下代码123false

对于大屏幕而言，ActionBar就置为了显示状态.

我不需要将 bools.xml 文件放入 values-sw400dp文件夹中, 因为操作系统会自动按相应路径搜索. 例如一个设备宽 600dp (600/160=3.75 英寸, 这就是我们通常所说的7片装) 操作系统会在values-sw600dp 和其包含的的文件夹中搜索 bools.xml 文件, 若没有找到则搜索 values-sw400dp 文件夹,在搜索 values-sw360dp 文件夹以此类推.

建议3:160dp = 1英寸。320 dp = 2英寸。dp = dip

建议4:你可以用这些目录结构技巧来应付所有资源类型**，比如你的XML布局用指定的系统目录名称

来解决这个问题，如：layout-sw360dp目录可以匹配目标宽是360dp的机器。如果你也要支持横竖屏布局切换的话，可以用如下目录：

layout-sw360dp-land

layout-sw360dp-port

别急，你有一半的用户是说阿拉伯语的？那就将布局名称改为下面的样子吧：

layout-sw360dp-land

layout-sw360dp-port

layout-sw360dp-land-ar

layout-sw360dp-port-ar

前两个可以适用于所有语言，-ar代表阿拉伯语。

建议5：资源规则简介：

XXX //例子：没有添加目录名：默认-适用于Nexus One，Droid 2,S2

XXX-sw360dp // 比较大的手机 – Galaxy Nexus, S3, S4

XXX-sw600dp // 7〃 平板

XXX-sw720dp // 10” 平板

在Kindle设备有些不同，如下：

XXX-large-mdpi // kindle fire 7〃

XXX-large-hdpi // kindle fire 7〃 HD

建议6：如果你不想裁剪所有的布局文件，你可以用dimens.xml文件**。你要是留心我上面的文章，你就会注意到在我的values目录里有很多dimens.xml，这样是因为我更喜欢在一个layout.xml里设置值，在每一个布局文件里我喜欢这样做：12345678910111213 small_margin是在dimen.xml文件里定义的： 4dp

这个4dp变量在所有dimen文件里。我有个Excel文件，里面创建了所有不同的基于不同因素所需的尺寸定义。也许你会问：为什么不让android OS来处理所有尺寸的问题？为什么不呢，为什么不用一个values目录和一个布局目录来代替所有写死的数值呢？那当然是可以的，如果设置得当，都会得到所有的尺寸，但是对于有些元素看起来就不是那么好计算尺寸了。

建议7:让空白空间大于图像空间。让图像空间大于按钮的大小。如果将按钮，多选框，切换控件放大后是很丑陋的。一个100dip(0.63")大小的按钮是不想在平板上显示为原来两倍宽度200dip(1.25")的.原因是屏幕变大了，这不是说平板是给巨人用的。我们可以这样做，在按钮增加的空间和图片扩展的空间里添加空白。

建议8:用GraphicalLayout工具快速预览。GraphicalLayout是WYSIWG XML编辑器。我喜欢直接编写元素-而不是拖，丢弃的可见编程方式，但在添加一些元素之后，可以在GraphicalLayout的下拉选择菜单里选择不同屏幕尺寸进行测试。

这里有很多选项供你选择。

图片缩放

建议9:不要把所有的图片都缩放了。用布局文件来适应不同屏幕尺寸的方法只是成功的一半，布局里的元素(如：图片)也要能在高分辨率的屏幕下良好工作。在概念上比较简单的方式就是创建一套完整的图片目录并将它们与很多drawable目录匹配起来。

drawable-sw600dp-ldpi

drawable-sw600dp-mdpi

drawable-sw600dp-hdpi

drawable-sw600dp-xhdpi

drawable-sw600dp-xxhdpi

...其它的类似。

不要这样做：

你不要太尽信书了。

一般来说有drawble-ldpi, drawable-hdpi等目录就足够了，不需要将所有的情况都加上。

建议10:避免使用位图(jpg,png)。对于一些图标来说，用位图是个不错的选择，因为它们使用简单。但是如果可以避免使用位图，你可以节省很多空间。但用不同的方法也可以达到很好的结果。

建议11:用XML绘图。位图都可以用XML绘图来代替的。XML绘图不是万能的，但是它的方便性还是使我感到惊讶。Android开发文档中有详细的介绍，这里有个简单的例子：1234567891011121314151617

这里是定义了一个圆角矩形，一个有渐变的边(深蓝)。你可以在布局文件的任何地方来引用，而且它可以适应于任何屏幕。用它可以做出理想的按钮。

建议12:用更多的XML绘图。再来介绍一个用XML绘图制作出能更加让你兴奋的例子，下面的雷达背景看起来是不是更加的复杂：

不用位图对你的UI是没有坏处的(除过图标)。

建议13:仍然用更多的XML绘图(如果必须，就用位图)。那我们怎样为天气信号构建一个超酷的图标-让灯泡动态的依据光的强度来进行自动填充，以及怎么点击指针后让其旋转呢？这里我们用位图和XML结合起来做个例子：

灯泡我们用PNG图：icon_magnitude_min(一个空的灯泡)和icon_magnitude_max(充满光的灯泡)，然后我们动态的裁剪后者。为了实现这个目标我是这样做的：123456789101112

在java程序中我将得到回形针的引用，然后可以用它来控制光的强度。

建议14: 为什么要用9-patch (当你可以用XML drawables的时候)? Android具有使用9-patches 来定义drawables的选择，有些教程阐述了怎样用它们来做一个按钮，这样可以在伸展的时候保持几个角不变 (并且避免了像素处理)。如果你已经知道怎样使用9-patches，可能是从web设计中学会的，那么它们或许值得一用。如果你对9-patches并不熟悉，我建议你维持原样。如果你想适应什么东西——例如拐角的圆弧或者颜色，创建9个小块要比创建位图更多被涉及，这就像回到了图像编辑器的时代。许多用9-patches获得的效果也可以通过XML获得。

建议15: 通过覆盖onDraw()创建自定义views. 有些事情XML并不十分在行，我们在OpenSignal和WeatherSignal中画过许多图像，为此有许多的库，但是我们要为自定义图像自己编写代码。这很有趣。或许你永远也不需要做这个，但为了使图像高度动态并自定义，这经常是唯一可行的办法。

建议16:在不能使用XML的地方使用SVG. 有时候覆盖onDraw()并勤勤恳恳的为自定义view编写代码画出需要的线条与弧线是过于技术化了。毕竟有一种矢量图像语言，它称作…Scalable Vector Graphics（可扩展矢量图形）。它也是史上最酷的Android应用之一—Androidify的动力来源。事实上他们创建这个库就是为了那款应用，他们将它发布在这里：SVG for Android 。这也就是我们在OpenSignal中画仪表盘所用到的。

建议17: 对SVG文件GZip压缩将它们变得更小它们就会处理的更快。

建议18: SVG库并不是支持一切.在一些特定的alpha通道中似乎不能正常工作，你甚至不得不在代码中将它们剔除。

达到在android所有版本里表示展现一致的目标

建议19：在一些android系统里（如TouchWhizz/HTC Sense/MotoBlur等等），默认的buttons和其他UI组件会跟原生系统里的看起来差别很大。**我希望这不是真的，但事实却是如此。

建议20：自定义你的UI组件。为了确定你的app在所有的设备里看起来是一致的，你将需要自定义所有的东西。这其实没有你想象中那么难，只要你做到了，你将能更加好地把握到你的app的展示外观。

建议21：Selectors是创建buttons的利器。我们在上面提到了如何在XML里定义button的背景，但是你将如何创建一个当按下去会改变的button呢？很简单：像下面那样在xml文件里定义背景。该xml文件将接收到button当前状态并且在外观上做出相应的改变。123456<?xml version="1.0" encoding="utf-8"?>

建议22:在Honeycomb之前的版本里时不存在ActionBar跟很多 animation 样式的，所以可以使用ActionBarSherlock 跟**NineOldAndroids来代替。Jake Wharton写的Android开源 组件都是往下兼容的精心杰作。更为惊喜的是，ABS 拥有强大的功能用来定义ActionBar。

把速度作为目标

建议23:在运行慢的手机上测试。你将在运行慢的手机上发现很多问题，同时它让你抓狂，没人会喜欢运行慢的程序。

建议24:尽量减少XML布局层次。更多的层次意味着系统将为解析你的代码付出更多的工作，这将会让图像渲染的更慢。

建议25:用Android Lint。在工程目录上右键选择Eclipse>Android Tools>Run Lint。它将会得到程序的一些信息，并能提高程序的运行速度，或者它能让你得代码更加清爽。

建议26:Android Lint可以得到错误信息。它可以给你的代码提供很详细的信息，并在你出错之前就可以给做出提示。

建议27:用可以帮助你减少视图层次结构。这是一种简单的方式来去除多余的层次。好的文章都对此有所解释，而且在 Android Developer中它也显得与众不同。

建议28:用HierarchyViewer可以直观的看到你布局的层次。这个智能的工具可以显示布局中有多少层次，而且可以提示出那些可以让程序变慢。

建议29:如果可以尽量用RelativeLayout**。**AbsoluteLayout已经过期了，就不要用了。你经常会遇到在RelativeLayout和LinearLayout中做出选择的情况，那就直接用RelativeLayouot吧，因为它可以让你减少视图层次。比如，你想实现一个如下视图：

盒子 A 在屏幕左半边 |盒子 B在屏幕右半边

你首先会想到这么做：

LinearLayout

android:layout_width=match_parent

android:layout_height=wrap_content

android:orientation=horizontal

”That works just fine, but you could also use:

RelativeLayout

android:layout_width=match_parent

android:layout_height=wrap_content

android:orientation=horizontal”

View

android:id=+id/dummy_center”

android:layout_width=”0dip”

android:layout_height=”0dip”

android:layout_gravity=”center”/”@

第二个表单比第一个难看的多，事实上是相当的糟糕：我们已经介绍过一个完整的新元素了。但是假如我们要给每个盒子里加入一个图片，一般的我们将这样做：

盒子 A 在屏幕左半边 图片|盒子 B在屏幕右半边 图片

用第一中方法，你得创建一个有两个层次的LinearLayout，如果用第二种方法，你可以直接在同一个RelativeLayout中加入图片，比如要指定第一个图片必须在“dummy_center”的左边，而且一个TextView A必须也在其左侧。那么你就得用7个元素3个视图层次了(LinearLayout 方式)，而(RelativeLayout方式)只用6个元素2个层次，这样所有的工作添加完成。

建议30：用一些扩展工具如DDMS。这可以帮助你发现一些不必要的网络调用、查看电池使用量、垃圾回收信息，状态变化(例子：当回调onStop和onDestroy时)等。LittleEye是我目前比较喜欢的工具。

建议31：用AsyncTasks。Anroid工程团队受够了人们经常在UI线程里面实现网络调用(译注：耗时操作，容易阻塞UI刷新)，所以他们实现了一些可产生编译级错误信息的API。但是仍然在很多app中的一些工作会拖垮UI线程，我们要考虑到UI布局要快以及提高UI的响应性。

目标机器空间小

建议32：一些Aandroid设备有100mb空间大小的限制。现在情况已有变化了，但是仍然有很多用户还会担心5Mb大小的app会浪费空间。如果你可以选择将app装入SD卡的话，这就不是问题了，但如果你的app需要在onBoot里启动的话你就不能装入SD卡了(例子：如一些窗体小部件).甚至对于一些新的设备，如果能很快的下载一个小的APK的话，用户还是很高兴的。

建议33：用XML资源(我发誓上次我已经提醒过了)，这将比PNG资源节省很多空间，当你仅仅需要一个可以满足很多屏幕大小的配置时，一个XML文件会比能实现同样功能的PNG省空间。

建议34：如果要用PNG，最好优化一下(用PNGCrush或ImageOptim)

目标bugs

建议35:在Android开发者控制台里检查所有被自动检测出来的bugs.　

建议36: ProGuard现在是默认启动着的. Proguard太好用了 (提高你app的速度和降低文件大小)，但这也让StackTraces 非常难以处理。你将需要重新追踪你的StackTraces，因此你将需要继续保留在每次构建中创建的Proguard的映射文件。我把它们都放到以代码版本号命名的文件夹里。

建议37: 为了显示StackTraces里的行数，你需要修改ProGuard的配置。确认你的proguard.cfg拥有下面这句话：

-keepattributes SourceFile,LineNumberTable

建议38：使用staged rollouts。测试5%的基础用户，并且观察bug报告。

建议39：使用真实设备测试平台。Device Anywhere and Perfecto Mobile提供了虚拟测试平台，在那里，你可以使用真正的移动设备。我发现他们有一些笨拙，加入连续不断地进行测试的话，会导致有一些糟糕的情况。如果你在联合办公的环境里工作，或者有一些Android开发的好友，那么去启动一个“设备池”吧。

 BitmapFactory.decodeResource和BitmapFactory.decodeStream，相信对于有过android app开发经验的人来说都是很熟悉了。关于Bitmap的OOM问题，网上也有很多文章进行了分析，不少文章都说为避免OOM，最好使用BitmapFactory.decodeStream，
3，BitmapFactory.decodeResource比起BitmapFactory.decodeStream来说，在没有参数Options opts的情况下，确实是多占用了内存，因为多了BitmapFactory.finishDecode这一步，这里多了一个Bitmap.createScaledBitmap操作；

使用BitmapDrawable是最节省内存的方法，原因是frameworks\base\core\java\android\content\res\Resources.java对Bitmap做了缓存处理，文中所有的array其实都是指向同一个Bitmap，这一点也可以通过Bitmap.toString的输出信息来证明。

因此，改用先通过BitmapFactory.decodeStream方法，创建出一个bitmap，再将其设为ImageView的source，decodeStream最大的秘密在于其直接调用JNI>>nativeDecodeAsset()来完成decode，无需再使用java层的createBitmap，从而节省了java层的空间。
如果在读取时加上图片的Config参数，可以跟有效减少加载的内存，从而跟有效阻止抛out of Memory异常
另外，decodeStream直接拿的图片来读取字节码了， 不会根据机器的各种分辨率来自动适应， 使用了decodeStream之后，需要在hdpi和mdpi，ldpi中配置相应的图片资源， 否则在不同分辨率机器上都是同样大小（像素点数量），显示出来的大小就不对了。