android泄露,app泄露

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

android手机上的隐私泄露主要根源是应用软件权限过多过高的原因吗？

感觉主要还是软件厂商自控力不够，有些数据权限根本无法控制，比如你注册时候的信息。另外就是用户对于权限管理不清晰，意识薄弱，让软件钻空子因为对于系统来说，android在权限方面管理越来越严格，自7.0以来引入的运行时权限能更好的保护隐私，同时在文件管理方面也做了很多限制。

相关问答

Q1: Android内存泄露检测（二）

依赖库即可，重点在分析工具和分析方法：

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，如果存在多份实例，则很可能发生了内存泄露。

Q2: android内存泄露怎样解决

在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"。

在打开的页面中，点击可以看到详细的引用信息。

上图中可以看出来是ImageUtil引用了一个MainActivity的实例。这样就找到了泄露的根源，就可以进行处理了。