在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占用的情况的方式，只是我不太懂这种和上面用命令行的方式进行测试的区别，数值上存在很大的差异。这种方式我感觉更适合查看是否存在内存泄漏的情况，不知各位有什么看法。