Android性能优化——之防止内存泄露

也是好长时间沒有写文章赚钱了，一直都很忙，近期总算有时间沉积和梳理一下近期学得和处理的一些难题。

近期开展服务支持的情况下，碰到了好多个奔溃的难题，全是OOM出现异常，一般OOM出现异常给人的觉得应该是载入大的图片导致的，可是历经看页面合理布局，而且剖析上传图片的尺寸发觉上传图片层面早已没什么能够提升的了，可是仍然奔溃，没法了，又用的IDEA专用工具中的运行内存监控器，来分辨究竟是哪里导致运行内存猛增，做什么实际操作导致网页页面資源沒有立即释放出来。最终发觉原来是每一次关掉这一页面，也没有立即的释放出来資源，每一次打开，都是会再次申请办理資源，导致内存泄露难题。下边我也说一下大家敲代码的情况下，这些地区非常容易会导致内存泄露。

最先是在Activity中申明静态变量或是静态方法或是静态数据控制

静态变量或是方式是放到数据格式区的，也就是在程序执行的全过程中，只需载入过这一类以后，静态数据的自变量或是方式，就一直会在数据格式区存有，不容易释放出来資源。由于静态变量或是方式并不是无故存有的，因此 必须Activity做为支撑点，换句话说这一自变量不但占有了自变量自身所存取数据的运行内存，还占有了这一Activity所占的运行内存。也就是这个Activity即便被客户关掉了，可是資源并沒有被释放出来。

次之，一些载入数据库查询动态性申请注册广播节目沒有立即关掉销户也是非常容易导致内存泄露的

比如比如BroadcastReceiver、ContentObserver，FileObserver在Activity的onDeatory或是某种的生命期完毕后，一定要unregister掉，不然这一Activity会一直被system强引入，不容易被运行内存收购 。

单例模式造成的内存泄露，

单例模式的特性就是他的生命期和Application一样，假如某一Activity实例被一个单利所拥有，换句话说单利里边引入了他，便会导致Activity目标会没法一切正常收购 释放出来。

注：这儿的基本原理和第一种是一样的，都是由于静态变量引入Activity目标，导致Activity没法一切正常释放出来資源导致的。

特性动漫造成内存泄露

比如编码中设定了特性动漫（ObjectAnimator），在Activity中运行了动漫，可是在消毁的情况下，沒有启用cancle方式，尽管大家看不见动漫了，可是这一动漫仍然会不断播放视频下来，动漫引入所属的控制，所属的控制引入Activity，这就导致Activity没法一切正常释放出来。

Handler内部类导致内存泄露

当应用内部类（包含匿名内部类）来建立Handler的情况下，Handler目标会隐式的拥有一个外部类目标（一般 是Activity）的引入，而handler一般 会随着这一个用时的后台管理进程（比如从互联网获取照片）一起出現，这一后台管理进程在每日任务实行结束以后，根据信息体制，通告Handler随后Handler见照片升级到页面，假如客户在互联网要求中关掉了Activity，一切正常状况下，Activity不会再被应用，因该会被Gc收购 掉，可是，因为该进程未实行完，而该进程拥有的Handler的引入，就造成Activity没法被收购 （直至互联网要求完毕），假如你实行了Handler的postDelayed()方式，该方式会将你的Handler装进一个Message，并把这一条Message推倒MessageQueue中，那麼在你设置的delay抵达以前，会出现一条MessageQueue -> Message -> Handler -> Activity的链，造成你的Activity被拥有引入而没法被收购 。能够在Activity完毕后，关掉进程，假如你的Handler是被delay的Message拥有了引入，那麼启用void removeCallbacksAndMessages（null）方式来清除消息队列。