13518219792
感觉主要还是软件厂商自控力不够，有些数据权限根本无法控制，比如你注册时候的信息。另外就是用户对于权限管理不清晰，意识薄弱，让软件钻空子因为对于系统来说，android在权限方面管理越来越严格，自7.0以来引入的运行时权限能更好的保护隐私，同时在文件管理方面也做了很多限制。
成都创新互联从2013年创立，先为原州等服务建站，原州等地企业，进行企业商务咨询服务。为原州企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。
依赖库即可，重点在分析工具和分析方法：
debugImplementation'com.squareup.leakcanary:leakcanary-android:2.8.1'
分析工具：MAT 、AndroidStudioProfiler 和 自带分析工具；
这里先看一下Leaking的状态（YES、NO、UNKNOWN），NO表示没泄露、YES表示出现泄漏、UNKNOW表示可能泄漏。
具体学习资料： 学习资料
首先了解下Android中最重要的四大内存指标的概念
我们主要使用USS和PSS来衡量进程的内存使用情况
dumpsys meminfo命令展示的是系统整体内存情况，内存项按进程进行分类
查看单个进程的内存信息，命令如下
adb shell dumpsys meminfo [pid | packageName]
Objects中Views、Activities、AppContexts的异常可以判断有内存泄露，比如刚退出应用，查看Activites是否为0，如果不为0，则有Activity没有销毁。
具体用法直接参考大佬的资源即可，不赘述。
android studio 中Memory Profile的用法
接入LeakCanary，监控所有Activity和Fragment的释放，App所有功能跑一遍，观察是否有抓到内存泄露的地方，分析引用链找到并解决问题，如此反复，直到LeakCanary检查不到内存泄露。
adb shell dumpsys meminfo命令查看退出界面后Objects的Views和Activities数目，特别是退出App后数目为否为0。
打开Android Studio Memory Profiler，反复打开关闭页面多次，点击GC，如果内存没有恢复到之前的数值，则可能发生了内存泄露。再点击Profiler的垃圾桶图标旁的heap dump按钮查看当面内存堆栈情况，按包名找到当前测试的Activity，如果存在多份实例，则很可能发生了内存泄露。
在Eclipse中新建一个Android工程，名字叫做：memoryleak。功能很简单，只有一个MainActivity和一个ImageUtil。我们在MainActivity中使用ImageUtil来加载图片。注意我们的ImageUtil是单例类。在创建的时候需要传入context。
应用起来以后，转屏。转屏以后，MainActivity会重建，导致ImageUtil重新加载图片。很不幸的是，因为ImageUtil并没有重建，还持有之前的Context，也就是之前的那个MainActivity实例。多次转屏以后，我们在Eclipse的DDMS里面，导出内存映像文件。导出的文件叫做：com.example.memoryleak.hprof。
DDMS导出的内存映像文件并不能被MAT直接使用。需要转换一下。在命令行输入：hprof-conv com.example.memoryleak.hprof memoryleak.hprof。
用MAT打开memoryleak.hprof。
点击“Histogram”
步骤阅读
在Class Name后面的输入框输入应用的名字：com.example.memoryleak。
可以看到有4个MainActivity实例，如果没有泄露的情况下只应该有一个实例，说明存在内存泄露。在MainActivity上点击右键-"Merge
Shortest Paths To GC Roots"-"exclude all phantom/weak/soft
etc.refrences"。
8
在打开的页面中，点击可以看到详细的引用信息。
9
上图中可以看出来是ImageUtil引用了一个MainActivity的实例。这样就找到了泄露的根源，就可以进行处理了。
