android开发技巧精髓七
18. Android内存管理-SoftReference的使用
很 多时候我们需要考虑Android平台上的内存管理问题，Dalvik VM给每个进程都分配了一定量的可用堆内存，当我们处理一些耗费资源的操作时可能会产生OOM错误(OutOfMemoryError)这样的异 常，Android123观察了下国内的类似Market客户端设计，基本上都没有采用很好的内存管理机制和缓存处理。
如果细心的网友可能发现Android Market客户端载入时，每个列表项的图标是异步刷新显示的，但当我们快速的往下滚动到一定数量比如50个，再往回滚动时可能我们看到了部分App的图 标又重新开始加载，当然这一过程可能是从SQLite数据库中缓存的，但是在内存中已经通过类似SoftReference的方式管理内存。
在Java中内存管理，引用分为四大类，强引用HardReference、弱引用WeakReference、软引用SoftReference和虚引 用PhantomReference。它们的区别也很明显，HardReference对象是即使虚拟机内存吃紧抛出OOM也不会导致这一引用的对象被回收，而WeakReference等更适合于一些数量不多，但体积稍微庞大的对象，在这四个引用中，它是最容易被垃圾回收的，而我们对于显示类似 Android Market中每个应用的App Icon时可以考虑使用SoftReference来解决内存不至于快速回收，同时当内存短缺面临Java VM崩溃抛出OOM前时，软引用将会强制回收内存，最后的虚引用一般没有实际意义，仅仅观察GC的活动状态，对于测试比较实用同时必须和 ReferenceQueue一起使用。
对于一组数据，我们可以通过HashMap的方式来添加一组SoftReference对象来临时保留一些数据，同时对于需要反复通过网络获取的不经常改变的内容，可以通过本地的文件系统或数据库来存储缓存，希望给国内做App Store这样的客户端一些改进建议。
19. 反射在Android开发中的利弊
由 于Android 2.2的推出，很多新的API加入导致很多项目移植需要考虑使用Java的反射机制Reflection来动态调用，动态调用的好处就是不需要使用引用文件，直接通过JDK中声明好的方法直接调用,本身原理基于JVM的，从Java 1.5开始支持，原理上就是根据类名而不实例化对象的情况下，获得对象的方法或属性而直接调用。
Android开发时反射能帮助我们多少?
1. 有些网友可能发现Android的SDK比较封闭，很多敏感的方法常规的用户无法编译，我们如果翻看了代码直接在反射中声明动态调用即可。比如很多internal或I开头的AIDL接口均可以通过反射轻松调用。
2. 反射对于Android123来说更重要的是考虑到应用的兼容性，我们目前主要兼容从Android 1.5到2.2的项目，API Level从3到8可以方便的扩充，调用前我们预留一个标志位声明该API的最低以及最高的API Level为多少可以调用。
3. 对于调试Java的反射是功臣了，在Logcat中我们可以看到出错的地方肯定有类似java.lang.reflect.XXX的字样，这种自检机制可以帮助我们方便的调试Android应用程序。
反射的缺点有哪些?
1. 因为是动态执行的，效率自然没有预编译时引用现有的库效率高，就像平时我们Win32开发时，可以不用h文件，直接通过GetProcAddress一样 去动态获取方法的地址。当然效率要根据复杂程度而决定，一般稍微复杂的处理性能损失可能超过20%，对于一些复杂的涉及Java自动类型转换判断，执行时 间可能是直接引用的上千倍，所以最终我们调试时必须考虑性能问题。
2. 因为反射是动态的，所以需要处理很多异常，不然Dalvik崩溃出Force Close的概率会大很多，很简单的一个反射就需要至少3个异常捕获，本身try-catch效率就不是很高，自然进一步影响运行效率，对于 Android开发我们必须考虑这些问题。
3. 反射因为导致代码臃肿，自然稍微复杂的几个方法实用反射将会导致代码可读性和维护性降低，如果很抽象的调用Android开发网强烈不推荐这种方法。
最后要说的是Reflection并不是Java的专利，微软的.Net也同样支持，同时更多的动态语言如Ruby等均支持这一特性。
20.AsyncTask对比Thread加Handler
很 多网友可能发现Android平台很多应用使用的都是AsyncTask，而并非Thread和Handler去更新UI，这里Android123给大 家说下他们到底有什么区别，我们平时应该使用哪种解决方案。从Android 1.5开始系统将AsyncTask引入到android.os包中，过去在很早1.1和1.0 SDK时其实官方将其命名为UserTask，其内部是JDK 1.5开始新增的concurrent库，做过J2EE的网友可能明白并发库效率和强大性，比Java原始的Thread更灵活和强大，但对于轻量级的使 用更为占用系统资源。Thread是Java早期为实现多线程而设计的，比较简单不支持concurrent中很多特性在同步和线程池类中需要自己去实现 很多的东西，对于分布式应用来说更需要自己写调度代码，而为了Android UI的刷新Google引入了Handler和Looper机制，它们均基于消息实现，有事可能消息队列阻塞或其他原因无法准确的使用。
Android开发网推荐大家使用AsyncTask代替Thread+Handler的方式，不仅调用上更为简单，经过实测更可靠一些，Google在 Browser中大量使用了异步任务作为处理耗时的I/O操作，比如下载文件、读写数据库等等，它们在本质上都离不开消息，但是AsyncTask相比 Thread加Handler更为可靠，更易于维护，但AsyncTask缺点也是有的比如一旦线程开启即dobackground方法执行后无法给线程发送消息，仅能通过预先设置好的标记来控制逻辑，当然可以通过线程的挂起等待标志位的改变来通讯，对于某些应用Thread和Handler以及 Looper可能更灵活。
21. Android Drawable叠加处理方法
大 家可能知道Bitmap的叠加处理在Android平台中可以通过Canvas一层一层的画就行了，而Drawable中如何处理呢? 除了使用BitmapDrawable的getBitmap方法将Drawable转换为Bitmap外，今天Android123给大家说下好用简单的 LayerDrawable类，LayerDrawable顾名思义就是层图形对象。下面直接用一个简单的代码表示:
Bitmap bm = BitmapFactory.decodeResource(getResources(),R.drawable.cwj);
Drawable[] array = new Drawable[3];
array[0] = new PaintDrawable(Color.BLACK); //黑色
array[1] = new PaintDrawable(Color.WHITE); //白色
array[2] = new BitmapDrawable(bm); //位图资源
LayerDrawable ld = new LayerDrawable(array); //参数为上面的Drawable数组
ld.setLayerInset(1, 1, 1, 1, 1); //第一个参数1代表数组的第二个元素，为白色
ld.setLayerInset(2, 2, 2, 2, 2); //第一个参数2代表数组的第三个元素，为位图资源
mImageView.setImageDrawable(ld);