此次对Android地图SDK 的修改，主要是针对OOM，CRASH, 程序卡死,其它问题的问题,,可能某些地方是错误的，希望大家多多指 正,非常感谢（按说OOM 也属于CRASH，因为其原因多样及处理起 来比较费劲，故单独列了出来）。

在修改过程中，非常感谢大家给予的全力支持和帮助！！！

一.OOM类型

回顾一下修改的过程，总结一下，有以下几个方面：

以下常见的几种：

1.Bitmap 的回收

调用recycle(),并解除对自身的所有引用。

2.Drawable 的回收

通过setCallback(null),解除对Bitmap 的引用.并解除自身的所有引用.

3.输入输出流及其子类的回收

注意通过close 释放其拥有的资源.

4.ArrayList 等容器类的回收：可以通过手动持有的对象一个一个删除，并清空后置为空的方式释放容器持有的资源。

举例来说：

其释放方式如下： 从Java 的垃圾回收机制上讲，只要不再引用该对象即可。

为什么需要手动把对象一一删除呢？我认为应该是没有直接继承 Object 的缘故（为什么没有测试下呢？JAVA 的内存回收不是实时的，既然这部分不太确定，为确保避免这部分的内存泄漏，建议还是手动释放，尽管看起来多费劲了），对比Symbian,iPhone 中的集合类得出的结论。

Symbian 中，如果你定义一个非CBase 类的普通类对象添加到容器中， 在释放时，需要如上一一把对象释放，不然，内存泄漏就发生了.但是，编 译时运行都OK。

5.静态对象如何回收

静态对象的生命周期比较长，可以通过在程序退出时，手动清除该静态对象 持有的资源，尤其是持有的一些占用内存较大UI资源，尽量确保它持有的资源全部被清除，同时把自己置为null。

比如说：一个activity 的context 被一个静态全局对象引用，那应该在销毁该activity 时需要静态对象把context 的引用释放掉。

另外，如果能用普通对象取代静态对象更好.修改android API 时，部分 静态对象被调整成普通对象（不否认，使用全局对象的确是很方便）。

iOS 版本的API 微博在使用的时候，同一个程序创建了多个地图对象，由 于存在一些全局的对象和消息，而这些全局的对象没有做数据同步（不应该做同步，做同步就是不良低效的设计了），导致多个地图对象在重复切换多次后会崩溃。

后来，把整个工程中的全局对象更改为普通的对象。保证了同一程序中 多个地图对象时也不会相互干扰。

6.UIHandler 对象的回收

需要把相关的消息移除

7.Canvas 的回收

分为程序运行时和退出时程序运行时，可通过如下方式释放Canvas 持有的资源程序退出时，可通过如下方式释放Canvas 持有的资源 Canvas 做如下处理呢？

如果在退出时添加如上CODE，会导致空指针的异常，直接CRASH。

8.类的继承派生导致的泄漏(比较特殊，咱们得多小心)

像Overlay 这个基类接下来添加个clear 的接口，其派生类如需要进行资源清理，则直接继承该接口即可，释放Overlay 时，会对所有Overlay 手动调用clear 函数。例如下图所示：

以上均是针对成员类型的数据，如果是临时的呢？和成员类型的类似。使 用完后，就立刻手动解除引用，释放相应的资源，便于虚拟机及时回收，降低内存使用的峰值。

以上内存泄漏的点，是根据OOM 时的日志，大致确定一个方向，人工检查所有相关CODE查出来的，在某些中低低端机型上比较容易出现OOM 的问题。像华为U9510，中兴U960，三星5830，金立GN205，LG 的某些机型等。

MAT 内存泄漏检测工具，大多数情况下，并不靠谱，指出来的不少信息比较粗略，很难断到真正出问题之处。深感android 内存泄漏比C，或C＋＋上的更可怕，工具太不好使，只能靠咱们自己多加注意了。

二.关于空指针的问题

因为手动解除对象的引用时，会把对对象的引用置为null，因此，可能 存在空指针的问题。尤其是在使用多线程之后，稍微处理不当，极容易出现 空指针的CRASH。

1.多线程下的空指针类型的CRASH

原因是数据在释放时未做同步处理。

举例来说，某个线程中RUN 函数如下所示： 那么终止该线程时，需要对某些同步访问的对象也做同步释放。不然， 也会出现莫名其妙的空指针类型的CRASH。

2.创建Bitmap 在回收时可能会CRASH（leven 发现的）：

如下所示： 为什么会出现这种情况呢？如果旋转的角度为0 时，调用createBitmap 不会重新创建一个图片，而是直接指向源图。这时，如果你在回收该图时不和源图比较下（正确的是：目标图和源图不同时去做回收，和源图相时不做回收），而直接回收掉，有可能把源图回收掉。那你再从源图创建bitmap时直接就crash 了。

另外，从源图创建位图时要对源图的宽和高做判断，在某些机型上，出 现过，源图在正常加载的情况下，宽和高有时会为负数。此时，如果对源图创建目标图，直接崩溃。所以在这种情况下，程序退出时，需要对图片及时清理。

3.其它情况的空指针问题，就比较容易处理了,直接做非空判断

在不能确保所有功能逻辑在运行或退出时完全按预期的处理逻辑走，加 个非空判断吧，测试人员的测试用例的场景，开发的使用场景，可能会有不少是咱们想不到的。 总结：多线程时释放数据时，注意同步。注意Bitmap 的特殊情况。其它的， 建议采取防御性编程的做法吧。

三．程序卡死问题

这个问题和网络有关，当网络不可用（例如关闭）时，使用程序时，多次来回切换会直接导致整个程序卡死。目前的解决办法是：当网络不可用时，直接不去做网络IO 了。QQ 软件管理最后发现的程序卡死问题，也是这种原因导致的，

做法和咱们目前一样。问题的原因不太清楚，怀疑是系统在这方面有BUG。

四．其它问题

在金立的GN205 出现过定不了位的情况,比较诡异.