位置: 编程技术 - 正文
android app 内存分析(android内存占用分析)
编辑：rootadmin推荐整理分享android app 内存分析(android内存占用分析)，希望有所帮助，仅作参考，欢迎阅读内容。
文章相关热门搜索词:android app 最大内存,android app 内存分析,android手机存储应用占用空间大,安卓内存占用实时显示软件,android内存占用分析,android app 内存分析,android app 内存分析,安卓应用内存,内容如对您有帮助，希望把文章链接给更多的朋友！
最近app的oom异常比较多，重点要求解决oom的bug，所以着重研究了一下eclipse中的mat分析内存的方法。
针对阅读页的分析比较繁琐，代码也比较多，不多说了，下面记录一下起始页ActLoading的内存分析及解决方案：
1.首先，在onDestroy中放一个System.gc();方法来提醒虚拟机进行内存回收，然后我们就可以在每次进出这个Activity的时候观察logcat中的情况，GC_EXPLICIT 这个表示调用System.gc时产生的内存回收：
GC_EXPLICIT freed K, % free K/K, paused 3ms&#;9ms, total ms，
上面的代码中就是调用关闭这个Activity的时候onDestroy中回收的日志，我重点看的是这个空闲的百分比（%）和后面的总共分配的堆内存空间（K），反复进出后这个百分比越来越小或者总空间变大，证明有泄露的嫌疑。
2.反复进出几次，生成内存分析文件，过程不多说了，直接看图：
每个人都有自己的一套分析方法，我自己的方法是以直方图为主的：
因为要分析自己的写的类，所以先根据包名分一下类，方便查找自己的Activity。
很容易的找到这个Activity代码了，发现退出以后还存在8个Activity对象，下面要分析这个对象为啥没有被回收掉了：
一个对象在gc的时候没有被回收说明它在通往GC根节点的路径上有其他的引用。
右键这个类，找它到GC根节点之间所有的排除软引用，弱引用，虚引用的其他引用。
可以看到有两个原因使它不能被回收；一个线程，一个就是我们公司自己的开发的一个app统计sdk。
这里面的线程是不是一个主要原因，因为它只是延迟了我们的内存释放，并不会一直占用，当到一定的时间后，线程执行完毕，会自己回收掉的，但是我们并不能不管它，因为QA在测试的时候，不会给你足够的时间来回收这些耗时间的线程。
那么到底是哪里的线程呢，分析了一下代码整个Activity里面只有了一个网络请求：
那么内存泄露的点就有可能在这里，其实可以粗略的判断一下，这个是不是泄露点，那就是先把这个方法注释掉，重复以上的步骤，看看上面的线程泄露还在不在。如果注释以后，问题不在了，那么它就是我们重点解决的对象；
上面的测试看到，原来的线程泄露不在了，那么那个网络请求的方法到底有什么问题呢？
在于参数用到了LoginUtils.getSessionId()，而不是一个单纯的string，我修改一下这个方法：
上面的线程泄露问题就解决了。
至于第二个内存泄露的问题analysis.collect.DatabaseAdapater：是由于自家公司的统计sdk占用了第一次赋予的Activity实例，而不能被回收，我还无能为力，只能依靠sdk修改了。。。。
内存分析方法多多，我只是列举了自己摸索的一套分析方式而已
activity 的启动模式 详细实验报告。。。 activity的启动模式有4种：standard（默认模式），singleTop，singleTask，singleInstance四种模式的作用：文档中解释的intent.setFlags中的Flag测试1：manifest中未设置
Android：跟手滑动的布局ViewGroup 跟手滑动很多开发者对布局的跟手滑动不太了解，在此就举一个例子，看一个RelativeLayout的滑动显示原理无论是跟手滑动，还是弹入弹出动画，本质上都
1、Android Studio创建android项目 1创建Helloworld工程1.1创建工程启动androidstudio,然后点击file-new-newproject菜单（如图所示），弹出CreateNewProject界面图、创建新工程图、新工程选项这里我们
标签: android内存占用分析
本文链接地址:https://www.jiuchutong.com/biancheng/385223.html 转载请保留说明！
