目前能看到的NativeHeap大小是:
应用启动:26M 此时已经初始化了 X5内核和IM SDK
UGC录音:26M->34M 退出之后时32M,还有部分没释放,疑似内存泄漏
发起直播:32M->72M 退出之后42M,同样没有完全释放
具体内部占用情况还没测…
这一段明显看到占用了很多内存。各个场景下的使用情况是:
1)刚进入应用:38M
2)再使用UGC录音:38.28M
3)再使用视频直播(发起直播):46M
4)打开应用内WebView(X5内核):56M
以上是主进程的内存,占用相当多。需要注意的是code内存占用一般是通过read-only方式mmap映射到内存中的的dex、odex、so等文件,因此在内存紧张的情况下,系统会回收这些内存,只是在oom-killer中仍然会计算在内。
另外播放进程2.27M,service进程1.1M还属于比较正常的水平。
显然主进程的Code内存占用太多了,需要分析。这里通过解析Linux标准的 /proc/<pid>/smaps文件,这个文件记录了进程内每一段虚拟内存的文件映射情况,这个文件只有进程自己有读权限,所以要么用root的机器,要么就自己写段代码copy出来。结合上面提到的工具。分析结果如下:
● 应用so占用 app so map Rss = 3984 kB (其中IM SDK 2576k)
● 应用的dex占用 app dex map Rss = 15101 kB
● X5内核的so+dex内存占用 tbs mem map Rss = 29048 kB
● 直播so相关 avlive mem map Rss = 3092 kB
● 其中X5内核的代码没有打进apk,因此可以比较独立的统计出来,占用有29M之多,让人惊讶!
● 其次直播的java代码打进了apk不方便单独统计内存用量,但是so是独立加载的,内存占用3M也是不少的。
● 最后是应用自身的dex占用有15M之多,因为自身代码量很大,似乎可以理解,但是仍然很多啊!
这里需要考虑的是 X5 内核能否延时加载?因为没打开WebView的时候就已经占用了数M了。另外WebView关闭之后是否可以销毁。
直播相关SO,可以考虑直播退出之后从内存中卸载掉。(java规范是加载so的classloader被GC,相关so即可卸载)。
应用自身dex占用。android 8.0 对art优化一个叫做DexLayout的能力,应为mmap映射的文件不会被立即加载进内存,在用到的时候是按照页大小(4k)加载的,当用到的类在dex中分布很分散的时候,就会导致盲目加载很多页,DexLayout就是把热点类集中放到一起。这里FaceBook推出了ReDex工具,可以参考一下。
更多山东IT培训相关资讯,请扫描下方二维码