android开发过程中,测试apk进程对设备内存占用的一般方法
在android开发以及其他各种软件开发的过程中,我们几乎都要了解我们的应用在各种情况下占用多少内存。如果要将软件预装到手机设备厂商的出厂设备上,厂家肯定会对你的软件在内存消耗方面做严格的限制,不能对他们的设备性能带来影响。一般不同厂商有不同的内存测试机制,如果遇到这种情况,直接按照厂商的机制去测试自己的应用内存使用情况就行了。下面只简单说一下apk内存测试过程中的一些浅显的问题,不涉及内存的优化,大牛请多指点莫喷,哈。
我们测试apk的内存应该是要发版之前对正式打包的apk进行测试,而不是像平常那样通过开发工具,比如android studio(一下简称as)安装到设备上以后再测,这样的apk还是debug版本的,测出的结果不是我们想要的,这种测试结果会比较大,我开始测试的时候就是直接通过as运行到设备上,然后通过命令行去测试的,结果吓我一跳:比厂家要求的高处好多,怎么办?后来对apk签名,混淆,压缩一些列操作打包成apk手动安装到设备上以后,再测试发现,我去!内存小了太多了!其实,这才是你的正式发版apk测试内存的合理方式,直接通过as安装debug版的apk根本不能作为你的apk占用内存的情况,我真是太菜了。
图1
如图1,
在adb shell 模式下,执行procrank |grep <你的apk包名>的命令,就是一种测试进程占用内存的情况,不少厂商告诉你他们是用这个方式来测试你的apk内存占用情况的。执行完上述命令以后,下面的信息中有四列数字以"K"结尾,分别代表Vss,Rss,Pss,Uss,具体的含义请自行查询,不再赘述。想说的是大多都是以最后一列,也就是Uss做为内存占用标准的,我这个例子中的9024K就是直接通过as安装debug版的apk到设备上以后,在apk运行的过程中测试的,内存9M左右。
图2
且看图2,还是同一个版本apk,我用adb install命令直接安装而不是用as直接运行,就差了大概2M左右的内存。所以,测试apk的内存,起码不要用as直接安装后测试。
图3.
图4
图3和图4分别是对应图1和图2的后台运行情况,也是退出你的apk以后没有杀死你的进程时,你的apk作为后台进程时消耗的内存,这种没有太多意义,只是想告诉你,你测试内存的话,一般是在稳定运行你的apk的过程中去测试,是作为当前的前台应用去测试的,否则测出来的太局限。
图5
图5是正式签名发布的apk,adb install以后前台运行,但是没有做压缩,混淆等操作。也可以看出,已经比没签名时的9024k小多了,这还不算,大招来了:
图6
图6中是签名,混淆,压缩后的apk,install以后运行,发现正式的内存成了5868K,这比你用as直接运行debug版的apk后就测试可小多了吧?
上面的只是一个HelloWorld,没有任何功能,一个成熟的apk实际占用的内存比这个要大不少,所以你会发现这种情况下,正式签名,混淆,压缩后的apk文件以及占用的内存相比没有签名,混淆的apk来说简直是好了太多。
图7
图7所示,在app的build.gradle文件中,在release版参数的配置过程中,将minifyEnabled的值写为true,以及配置下面的几行后,就是压缩,签名,混淆的apk文件。apk的混淆配置请查看其它文章,本章不涉及具体的配置。
另外,用dumpsys meminfo |grep <包名>的命令也是查内存的一种方式,和上面procrank的结果不一样,比上述结果要大,可以具体按照厂商的要求去执行相应的命令。相信,不少人有自己更好的方式去测试,也请不吝赐教!
图8
图8中也是一种查看apk在运行时对内存和CPU占用的情况的方式,只是我不太懂这种和上面用命令行的方式进行测试的区别,数值上存在很大的差异。这种方式我感觉更适合查看是否存在内存泄漏的情况,不知各位有什么看法。