创新互联专注于企业营销型网站建设、网站重做改版、江永网站定制设计、自适应品牌网站建设、HTML5、商城网站建设、集团公司官网建设、外贸网站建设、高端网站制作、响应式网页设计等建站业务,价格优惠性价比高,为江永等各大城市提供网站开发制作服务。
OOM可能是因为Memory Leak,也可能是你的应用本身就比较耗内存(比如图片浏览型的,或者应用本身的设计有问题)。所以,出现OOM不一定是Memory Leak。
同样,Memory Leak也不一定就会导致OOM,如果泄露的速度很慢,可能还没用完可用内存应用就被重启了,那就不会OOM咯。当然了,有bug解决了最好。
shallow heap:你自身占了多少内存,比如你有一个int属性,就占4字节。不包括你引用的其他对象。
retained heap:如果你被销毁,总共会释放多少内存。这些因你存在被占据的空间就是retained heap。
更详细的解释请看这篇博客
GC的时候,是从这些节点开始遍历,不停的寻找其子节点直到结束。然后把不能遍历到的节点释放。这些遍历的起点(注意,可不是一个哦)就叫做GC roots。
那,对于java来说,谁是GC roots?简单点说(不是那么准确)包括以下几种:
栈上面的局部变量
栈上面的函数参数变量
所有由Bootstrap Loader加载的类变量
另外,JNI相关的也会有
更多详细解释请看这篇博客
其实到最后,谁是GC roots不是那么重要,因为一般来说,到最后就剩下一些系统框架类,以及jvm和class相关的东西。这里给大家说GC roots主要是因为使用mat需要了解它。
histogram视图显示了每个类有多少实例,并可以按照这些实例占据的Retained size和Shallow size排序。通过过滤包名,很容易发现有问题的类。
这里有几个简单的原则,比如,activity的实例通常只应该有一个。已经关闭的activity不应该出现。实体类的Retained size应该是比较小的,也就几十KB。
对于Android程序来说,内存泄露通常都会牵扯到activity。因此,dump之前,可以多旋转几次屏幕并反复的进出可能有问题的activity,让问题尽可能的凸现。
通过Histogram我们可以看每个类有多少个实例,shallow和retained heap分别有多大。如果只是看java的基础类型和framework的类,没有什么意义,一定要过滤出自己的类型,如下图
发现LeakInnerClassActivity产生了9个实例,一定是被hold住了。
大家来看这个图,左侧是对象引用关系,右侧是dominator tree
Note that A, B and C are dominated by a “virtual” root object.
Note that the dominator relationship is transitive;C dominates E which dominates G therefore C also dominates G.
这个视图非常强大,它把所有实例按Retained heap和Shallow heap列出来;并且,只要展开就可以看到这个实例所占有的实例(换句话说,如果该对象被释放,还会有哪些对象被释放)
使用这个视图,可以很方便的追踪被泄露的内存到底是谁占用了,更多参考这篇博客
打开一个HPROF文件,切换到histogram视图
在Navigation View中右键点击histogram,选择Add to compare basket
打开另一个HPROF文件,并重复上一个步骤
对比两次heap dumps的内容,看下图,LeakInnerClassActivity的实例又增加了一个。而我仅仅是又启动了一次该Activity,所以问题显而易见。
参考:Memory Analysis for Android Applications
如果非静态内部类的方法中,有生命周期大于其所在类的,那就有问题了。比如:AsyncTask、Handler,这两个类都是方便开发者执行异步任务的,但是,这两个都跳出了Activity/Fragment的生命周期。或许,是时候学习Loader了
为什么?因为非静态内部类会自动持有一个所属类的实例,如果所属类的实例已经结束生命周期,但内部类的方法仍在执行,就会hold其主体。也就使主体不能被释放,亦即内存泄露。
静态类呢?静态类编译后和非内部类是一样的,有自己独立的类名。不会悄悄引用所属类的实例,所以就不容易泄露。
- //首先,静态类
- static class IncomingHandler extends Handler {
- //其次,弱引用
- private final WeakReference mService;
- IncomingHandler(UDPListenerService service) {
- mService = new WeakReference
(service); - }
- @Override
- public void handleMessage(Message msg) {
- UDPListenerService service = mService.get();
- if (service != null) {
- service.handleMessage(msg);
- }
- }
- }
加载时使用option,用多大,载入多大。
res目录下的图片也是一样,及时清理过大的图片资源。
如果还有问题,就想办法把不可见的资源释放掉,比如,TabActivity中不可见的Tab,ViewPager中的Fragment。
如果activity的图片资源较多,需要考虑屏幕旋转时,销毁已有资源。请参考这篇文章
看使用的周期是否在activity周期内,如果超出,必须用application;常见的情景包括:AsyncTask,Thread,第三方库初始化等等。
还有些情景,只能用activity:比如,对话框,各种View,需要startActivity的等。
总之,尽可能使用Application。参考stackoverflow
类变量,一旦用完,尽快释放。因为类的存活时间最长,所以,占用的资源越少越好;
比较耗时且耗内存的方法内的局部变量,比如,图片处理的方法,每个bitmap对象用完就及时丢弃。尽可能让gc介入。
网页名称:Android内存溢出分析
链接分享:http://www.shufengxianlan.com/qtweb/news21/41171.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联