Android锁屏解锁卡顿优化原理分析与GC回收

一、问题描述

我在使用Android手机，解锁屏幕时出现了卡顿现象，从解锁到菜单页面需要卡顿3~4秒。对于这一方面，从事Android开发的我决定，测试分析解决这一问题。

二、分析问题

我们使用systrace，我这里是用的ddms录制trace.html，用chrom打开systrace提供了一些UI Thread耗时CPU耗时等分析图，从图上分析可以看出，有很长一段时间，系统在进行GC，大约花费3~4s的时间，感觉可以查一下问题，从网上查询资料，知道是系统进行GC的时候是会阻塞当面界面的，表现上就是界面卡住了，但是GC是虚拟机系统行为，code无法控制，还得需要找源头，为何会有这么多垃圾需要回收。

三、GC回收原理与解析

那我们就先来搞懂GC的源头

GC原理

将内存中不再被使用的对象进行回收，GC中用于回收的方法称为收集器，由于GC需要消耗一些资源和时间，Java在对对象的生命周期特征进行分析后，按照新生代、旧生代的方式来对对象进行收集，以尽可能的缩短GC对应用造成的暂停。

常见GC算法引用计数标记清除标记整理分待回收（V8用到的）算法解析1、引用计数法（Reference Counting）：

在对象中添加一个引用计数器，每当一个地方引用它时，计数器就加1；当引用失效时，计数器就减1；当引用计数为0时就会被回收。但是它存在一个很大的问题就是循环引用：如下图，当实例化A时，A会持有实例B，B会持有C，C持有A。这样一来我们就会发现:如果需要回收A，除了释放初始实例化引用，还需要释放C的引用。但是由于ABC互相引用，所以就造成谁也无法释放。主流的垃圾回收都没有采用这种判断方法，因为需要额外的工作来解决它（感兴趣的童鞋可以看看智能指针）。

“”

可达性分析算法（Reachability Analysis）：

在java虚拟机中就是通过可达性分析法来判定对象是否存活的。思路是通过“GC Roots”的对象（可以认为是确定固定存在的对象）作为起始点，然后从这些节点开始遍历所有引用链，如果某个对象没有GC Roots直接或间接的连接的话，这个对象（白色节点）就被认为程序中不再使用可以被回收了。如下图：

“”

代码示例：const user1 = { age: 11 }const user2 = { age: 12 }const user3 = { age: 13 }const nameList = [user1.age, user2.age, user3.age]function fn() { const num1 = 1 const num2 = 2 num3 = 3}fn()

当函数调用过后，num1和num2在外部不能使用，引用数为0，会被回收 ; num3是挂载在window上的，所以不会被回收 ; 上面的user1、user2、user3被nameList引用，所以引用数不为0不会被回收 ;

上面无法回收循环应用对象举例：function fn() { const obj1 = {} const obj2 = {} obj1.name = obj2 obj2.name = obj1 return 'hello world'}fn()// obj1和obj2，因为互相有引用，所以计数器并不为0，fn调用之后依旧无法回收这两个对象2、标记清除：

其分为“标记”和“清除”两个阶段。首先标记出所有死亡的对象，然后把所有死亡的的对象进行清除操作。如下图，我们可以清楚地看到，这种回收算法有一个很大的问题：造成很多的不连续内存碎片，这样一来，如果需要创建稍微大一点的对象，就很可能无法找到足够大的内存空间。这就需要整个再进行一次标记整理来解决这一问题（耗时耗力）。

3.标记整理：

算法分为”标记-整理-清除“阶段，首先需要先标记出存活的对象，然后把他们整理到一边，最后把存活边界外的内存空间都清除一遍。这个算法的好处就是不会产生内存碎片，但是由于整理阶段移动了对象，所以需要更新对象的引用。

4.标记复制：

算法分标记-复制两个阶段。首先会标记存活的对象，完成后，该算法会把存活的对象都复制到一块新的空内存里去。最后将原来的内存空间清空。过程如下图，这个算法最大的问题就是需要很大的内存（实际用地，用于复制的内存空间），同时如果存活的对象非常多的话，标记和复制阶段都就会很慢。同时也涉及到了对象位置改变需要更新引用。尽管看起来问题很大，但是根据分代理论：弱分代假说里大多数对象生命周期短，这种情况下标记复制就很适合了（复制的存活对象少）。至于内存消耗太大的问题，java虚拟机通过将新生代分为一个Eden区与2个Survivo区，其中一个Survivo区用来复制，这样一来极大地提高了内存空间利用率。

了解到GC的原理以及他的算法，我们就来看看如何解决问题。

四、解决方案

打开著名的traceview工具，也是分析性能问题的好帮手。同样使用DDMS工具上集成的方式，我使用的是MTK release的工具GAT首先我用traceView看了一下，traceview主要是看一些方法的耗时和调用情况，以及消耗cpu的状态，从函数方法的调用来看，耗时最高的就是主线程，达到了4.7秒，图形上看，似乎这个Binder操作耗费的时间有点高。

双击这一块看到信息，Binder操作的inc cpu time占用14%，但是incl Real Time是73%的时间，达到了5秒多，这种情况主要是因为可能CPU的上下文切换、阻塞、GC等原因造成，与systrace上看出的问题一致，如图：

下面再录制一份log，找关键字ActivityManager和Binder看看情况，找到如下log:

01-21 14:07:49.951 1109 1285 I ActivityManager: Displayed com.android.settings/.SubSettings: 5s544ms [aosp]

可见，这个subSetting花了5秒半，相当长，循着时间往前看5s，看看是否有什么蛛丝马迹，找到了binder出错的信息：

01-21 14:07:43.931 4218 4218 E ActivityThread: Activity com.android.settings.SubSettings has leaked ServiceConnection com.android.settings.password.ChooseLockGeneric$ChooseLockGenericFragment1 @ 680 f 7 e 9 t h a t w a s o r i g i n a l l y b o u n d h e r e 01 − 2114 : 07 : 43.93142184218 E A c t i v i t y T h r e a d : a n d r o i d . a p p . S e r v i c e C o n n e c t i o n L e a k e d : A c t i v i t y c o m . a n d r o i d . s e t t i n g s . S u b S e t t i n g s h a s l e a k e d S e r v i c e C o n n e c t i o n c o m . a n d r o i d . s e t t i n g s . p a s s w o r d . C h o o s e L o c k G e n e r i c 1@680f7e9 that was originally bound here 01-21 14:07:43.931 4218 4218 E ActivityThread: android.app.ServiceConnectionLeaked: Activity com.android.settings.SubSettings has leaked ServiceConnection com.android.settings.password.ChooseLockGeneric1@680f7e9thatwasoriginallyboundhere01−2114:07:43.93142184218EActivityThread:android.app.ServiceConnectionLeaked:Activitycom.android.settings.SubSettingshasleakedServiceConnectioncom.android.settings.password.ChooseLockGenericChooseLockGenericFragment1 @ 680 f 7 e 9 t h a t w a s o r i g i n a l l y b o u n d h e r e 01 − 2114 : 07 : 43.93142184218 E A c t i v i t y T h r e a d : a t a n d r o i d . a p p . L o a d e d A p k 1@680f7e9 that was originally bound here 01-21 14:07:43.931 4218 4218 E ActivityThread: at android.app.LoadedApk1@680f7e9thatwasoriginallyboundhere01−2114:07:43.93142184218EActivityThread:atandroid.app.LoadedApkServiceDispatcher.(LoadedApk.java:1532)01-21 14:07:43.931 4218 4218 E ActivityThread: at android.app.LoadedApk.getServiceDispatcher(LoadedApk.java:1424)01-21 14:07:43.931 4218 4218 E ActivityThread: at android.app.ContextImpl.bindServiceCommon(ContextImpl.java:1605)01-21 14:07:43.931 4218 4218 E ActivityThread: at android.app.ContextImpl.bindService(ContextImpl.java:1557)01-21 14:07:43.931 4218 4218 E ActivityThread: at android.content.ContextWrapper.bindService(ContextWrapper.java:684)01-21 14:07:43.931 4218 4218 E ActivityThread: at com.android.settings.password.ChooseLockGenericC h o o s e L o c k G e n e r i c F r a g m e n t . b i n d S e r v i c e ( C h o o s e L o c k G e n e r i c . j a v a : 297 ) 01 − 2114 : 07 : 43.93142184218 E A c t i v i t y T h r e a d : a t c o m . a n d r o i d . s e t t i n g s . p a s s w o r d . C h o o s e L o c k G e n e r i c ChooseLockGenericFragment.bindService(ChooseLockGeneric.java:297) 01-21 14:07:43.931 4218 4218 E ActivityThread: at com.android.settings.password.ChooseLockGenericChooseLockGenericFragment.bindService(ChooseLockGeneric.java:297)01−2114:07:43.93142184218EActivityThread:atcom.android.settings.password.ChooseLockGenericChooseLockGenericFragment.onCreate(ChooseLockGeneric.java:201)01-21 14:07:43.931 4218 4218 E ActivityThread: at android.app.Fragment.performCreate(Fragment.java:2489)01-21 14:07:43.931 4218 4218 E ActivityThread: at android.app.FragmentManagerImpl.moveToState(FragmentManager.java:1237)01-21 14:07:43.931 4218 4218 E ActivityThread: at android.app.FragmentManagerImpl.addAddedFragments(FragmentManager.java:2407)01-21 14:07:43.931 4218 4218 E ActivityThread: at android.app.FragmentManagerImpl.executeOpsTogether(FragmentManager.java:2186)01-21 14:07:43.931 4218 4218 E ActivityThread: at android.app.FragmentManagerImpl.removeRedundantOperationsAndExecute(FragmentManager.java:2142)01-21 14:07:43.931 4218 4218 E ActivityThread: at android.app.FragmentManagerImpl.execPendingActions(FragmentManager.java:2043)01-21 14:07:43.931 4218 4218 E ActivityThread: at android.app.FragmentManagerImpl.executePendingTransactions(FragmentManager.java:799)01-21 14:07:43.931 4218 4218 E ActivityThread: at com.android.settings.SettingsActivity.switchToFragment(SettingsActivity.java:781)01-21 14:07:43.931 4218 4218 E ActivityThread: at com.android.settings.SettingsActivity.launchSettingFragment(SettingsActivity.java:439)01-21 14:07:43.931 4218 4218 E ActivityThread: at com.android.settings.SettingsActivity.onCreate(SettingsActivity.java:327)01-21 14:07:43.931 4218 4218 E ActivityThread: at android.app.Activity.performCreate(Activity.java:7023)01-21 14:07:43.931 4218 4218 E ActivityThread: at android.app.Activity.performCreate(Activity.java:7014)01-21 14:07:43.931 4218 4218 E ActivityThread: at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1215)01-21 14:07:43.931 4218 4218 E ActivityThread: at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2734)01-21 14:07:43.931 4218 4218 E ActivityThread: at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2859)01-21 14:07:43.931 4218 4218 E ActivityThread: at android.app.ActivityThread.-wrap11(Unknown Source:0)01-21 14:07:43.931 4218 4218 E ActivityThread: at android.app.ActivityThreadH . h a n d l e M e s s a g e ( A c t i v i t y T h r e a d . j a v a : 1592 ) 01 − 2114 : 07 : 43.93142184218 E A c t i v i t y T h r e a d : a t a n d r o i d . o s . H a n d l e r . d i s p a t c h M e s s a g e ( H a n d l e r . j a v a : 106 ) 01 − 2114 : 07 : 43.93142184218 E A c t i v i t y T h r e a d : a t a n d r o i d . o s . L o o p e r . l o o p ( L o o p e r . j a v a : 164 ) 01 − 2114 : 07 : 43.93142184218 E A c t i v i t y T h r e a d : a t a n d r o i d . a p p . A c t i v i t y T h r e a d . m a i n ( A c t i v i t y T h r e a d . j a v a : 6518 ) 01 − 2114 : 07 : 43.93142184218 E A c t i v i t y T h r e a d : a t j a v a . l a n g . r e f l e c t . M e t h o d . i n v o k e ( N a t i v e M e t h o d ) 01 − 2114 : 07 : 43.93142184218 E A c t i v i t y T h r e a d : a t c o m . a n d r o i d . i n t e r n a l . o s . R u n t i m e I n i t H.handleMessage(ActivityThread.java:1592) 01-21 14:07:43.931 4218 4218 E ActivityThread: at android.os.Handler.dispatchMessage(Handler.java:106) 01-21 14:07:43.931 4218 4218 E ActivityThread: at android.os.Looper.loop(Looper.java:164) 01-21 14:07:43.931 4218 4218 E ActivityThread: at android.app.ActivityThread.main(ActivityThread.java:6518) 01-21 14:07:43.931 4218 4218 E ActivityThread: at java.lang.reflect.Method.invoke(Native Method) 01-21 14:07:43.931 4218 4218 E ActivityThread: at com.android.internal.os.RuntimeInitH.handleMessage(ActivityThread.java:1592)01−2114:07:43.93142184218EActivityThread:atandroid.os.Handler.dispatchMessage(Handler.java:106)01−2114:07:43.93142184218EActivityThread:atandroid.os.Looper.loop(Looper.java:164)01−2114:07:43.93142184218EActivityThread:atandroid.app.ActivityThread.main(ActivityThread.java:6518)01−2114:07:43.93142184218EActivityThread:atjava.lang.reflect.Method.invoke(NativeMethod)01−2114:07:43.93142184218EActivityThread:atcom.android.internal.os.RuntimeInitMethodAndArgsCaller.run(RuntimeInit.java:438)01-21 14:07:43.931 4218 4218 E ActivityThread: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)01-21 14:07:43.987 1109 3345 W ActivityManager: Unbind failed: could not find connection for android.os.BinderProxy@8d5f5b4

好巧，报错也是因为Binder没有unBinder成功，与traceview的Binder耗时，以及systrace的GC耗时的信息都有千丝万缕的关系，也许就是问题的所在，接下来就是解决这个错误，并验证的时刻。找到如下资料：

Google Android Issue中有这个缺陷，缺陷详细信息在这里(Google Android Issue 2483)，Using getApplicationContext().bindService instead of just bindService on your activity solves the problem as it is using the higher level application context.先调用getApplicationContext()获取其所属的Activity的上下文环境才能正常bindService，也就是在onCreate()方法中使用this.getApplicationContext().bindService([args…])就可以了,否则bindService将永远失败返回false。

那么就看log找到对应的地方，我们发现绑定binder的地方是用的getContext().Binder(xxxx),解绑的地方是用的getActivity().unBinder(xxx),我们通通换成getActivity().getApplicationContext().binder(xxx) (unBinder),编译push验证，查看log如下：

Line 2240: 01-21 15:29:12.629 1167 1325 I ActivityManager: Displayed com.android.settings/.SubSettings: 2s672ms [aosp]

Android性能优化知识学习，获~可私信发送：“核心笔记”或“手册”即可获取！

五、文末

成功优化了大约3秒的时间，虽然还感觉有卡顿，但是已经好很多，因为为了方便调试，编译的是userdebug版本，使用user版本后效果还有提升，算是能够过的去了！

更多性能优化（卡顿优化、UI优化、布局优化、稳定性优化、电量优化等）可前往私信哦。

安卓手机卡顿卡顿原因及解决方法

　　Android是一种基于Linux的自由及开放源代码的操作系统，主要使用于移动设备，如智能手机和平板电脑，由Google公司和开放手机联盟领导及开发那么你知道安卓手机卡顿卡顿原因及解决方法么?接下来是我为大家收集的安卓手机卡顿卡顿原因及解决方法，欢迎大家阅读：

　　安卓手机卡顿卡顿原因及解决方法 篇1

　　一、安卓系统本身太过于开放

　　它是开放的系统，频繁的安装与卸载必然会在手机内积累大量残留，这些手机底层的残留物并不会因为你把APP卸载了而自动删除，卸载APP没用的，一般用户也意识不到它的存在，久而久之越积越多。手机用久了，视频、微博、QQ这类APP必然会产生垃圾，使用最频繁，所以垃圾产生也多。如果不及时清理，产生大量垃圾也是正常现象。

　　二、软件开发者水平良莠不

　　APP开发者技术有高低，有的算法和优化做得很烂，导致应用在使用时产生大量不必要的垃圾文件占用ROM空间，各种毫无必要的后台自动启动和进程占用RAM。这又要说到安卓宽松的审核机制，使得这些不规范APP得以流向消费者。由于安卓用户没有良好的付费习惯，安卓程序基本只能靠植入广告来挣钱，所以很多APP拼命植入广告插件，双十一那天，我手机一晚上竟然收到了26条由APP推送的通知消息。

　　三、不良软件厂商的无耻行径

　　强制在通知栏推送消息还算是轻的，更要命的是那些不良软件厂商的钓鱼推广。很多朋友可能在通知栏看到一条消息，就去点击它，但是只要你点击了里面变成软件下载了，而且连停止按钮都没有，根本停不下来。这些垃圾软件一旦安装了，无时无刻不在后台占用你的手机内存和存储空间。

　　对于上面这些情况，我们该怎么办呢?

　　1、定期清理手机缓存

　　a、桌面--文件管理--文件清理，来清理所有应用软件的缓存垃圾文件;

　　b、借助应用软件自带的清除缓存功能。比如清除微信的缓存垃圾文件，进入微信--我--设置--通用--清理微信存储空间，就可以选择性删除各种文件。

　　c、借助三方软件清除缓存，比如猎豹清理大师。

　　2、关闭不用的软件后台进程

　　长按HOME键--再点击“小扫把”清理。或直接下拉通知栏--点击一键清理后台运行程序。

　　3、桌面尽量减少使用动态壁纸和过多小插件

　　一些具有实时刷新功能的小插件会一直在后台运行，不仅占据了宝贵的RAM，还会在后台偷偷跑流量并持续消耗电量;所以应尽量减少此类数据密集型应用的小插件。

　　4、在软件商店搜索下载安装应用程序

　　现在第三方等市场太复杂，有不少程序自带恶意插件，从而拖慢了速度，所以要想使自己的爱机保持良好的运行速度，关键还是保持良好的使用习惯，维护好自己的.手机。

　　5、关闭自动启动软件程序

　　桌面--安全中心--权限隐私--自启动管理--进行相关设置。

　　6、少用动画效果：

　　Android设备大都内置了动画效果，我们可以通过设置提高手机运行速度

　　a、关闭动画：设置--常规--更多--开发者选项--分别点击窗口动画缩放、过渡动画缩放和动画程序时长缩放--关闭动画--即可;

　　b、打开强制进行GPU渲染：设置--常规--更多--开发者选项--打开强制进行GPU渲染;

　　c、设置后台进程控制：设置--常规--更多--开发者选项--后台进程限制--进行相关设置。

　　7、每天都开关机一次

　　重启手机可以关闭后台运行程序，清除系统产生的临时缓存垃圾(非软件)，解决系统或者软件未知错误，用最简单的方法释放内存

　　8、及时更新手机固件版本

　　新版本在系统各方面都进行过优化，而且也更稳定。

　　安卓手机卡顿卡顿原因及解决方法 篇2

　　一、手机变卡的原因

　　1.运行内存不足

　　这个是手机卡慢的最主要原因，随着手机安装软件的增多，用户往往也会经常使用它们，这样每个打开的程序都会占用一部分的运行内存，如果本身手机内存就比较少，就会只剩下很少的内存容量，这样手机系统运行会非常的卡顿。可能有的朋友有疑问：手机软件打开的多了会卡倒也正常，但是很多时候我已经关闭了软件，怎么还是会占用运行内存呢？其实这个要从安卓系统的内存回收机制说起，安卓手机中的每个界面都是绑定一个Activity(活动)的，它是有自己的生命周期的，每次一个活动被上一个活动覆盖，它就处于暂停状态，到一定的时间才会被销毁，释放内存。另外很多软件都使用service（服务)，来处理后台任务，而且也方便快速打开软件。当用户退出该软件的时候，服务依然还在后台运行，占用内存。

　　2.存储空间被占用太多

　　当手机长期使用后，会出现存储空间被大量占用的情况，其中一些是软件运行后留下的日志文件，一些是下载的缓存数据，还有一些是用户自己下载的数据，比如音乐，视频，图片等。另外还有一些下载的安装包，卸载软件后的残留数据等等。当存储空间被大量占用时会导致系统文件和应用软件加载变慢，读取时间变长，也会感到手机变卡变慢。

　　二、手机变卡的解决办法

　　1.限制软件的开机自启

　　首先打开手机“设置”

　　接着打开“权限管理"

　　接下来我们再点击打开”应用启动管理“

　　最后选择对应的应用将启动关闭就好了

　　2.卸载长期不用或者不需要的软件

　　安卓手机卸载软件只需要长按屏幕上的某个软件图标，拖到顶部卸载区就可以了。

　　3.利用安卓手机自带的手机管家

　　手机管家有两个功能很实用，一个是内存清理，可以把软件退出后又没有释放掉的内存清理掉，这样运行内存就可以腾出来给系统使用，这样会使用起来会感觉流畅很多。另外一个是垃圾文件清理，将存储区中多余无用的文件清除，可以加快系统对存储区文件读取的速度，也会提高系统的运行速度。

　　安卓手机卡顿卡顿原因及解决方法 篇3

　　天生短板

　　大家都知道安卓系统是开源的，而开源的一大弊端就是无法约束第三方应用，从而导致应用质量参差不齐。很多应用在开发的时候，考虑最多的是如何常驻运存，就算被用户清理也要想办法再爬起来。常驻运存的应用越多，后台进程和空进程自然也就越多，于是小运存手机上的资源争夺战就此打响。安卓种下了因，但是卡顿这个锅还是要那些赖在运存里的应用来背。

　　配置不足

　　不只是手机硬件更新换代，手机系统和应用也在不断升级。早期的微信只占用几十MB的运存，现在则需要几百MB。要求几年前的手机流畅运行现在的应用，这件事确实有点难。

　　定制系统

　　同样是6G运存的手机，有些品牌的手机开机后占用2G运存，有些手机则要占据3G甚至是更多。就算以后出10G、20G运存的手机，随之更新的系统和应用也会对照当前的主流配置，用更多的功能把运存“充填”到一半左右，这样既保证系统不卡顿，又能刺激用户换更大运存的手机。所以说，我们选购和比较手机时不能只看配置，还要看这个品牌的定制系统表现如何。

　　解决办法

　　定制系统自带的很多应用都不能禁止自启，对于第三方应用，我们也只能控制它们的部分行为，不过我们还是通过一些设置提高手机的整体流畅度。还是拿这个只有2G运存的红米note2为例吧，其他品牌的手机也是大同小异。

　　在手机设置中点选“授权管理”—“自启动管理”，关闭没必要自启的应用。请注意，微信、QQ这种经常使用的社交应用最好不要关闭，以免收不到重要信息。

　　在手机设置中点选“通知和状态栏”—“通知管理”，找出没必要弹出通知的应用后关闭“允许通知”开关。

　　在手机设置中点选“电量和性能”—“应用配置”，找出不常使用但是又常驻后台的应用，然后点选“禁止后台运行”。

　　在手机设置中点选“我的设备”—“全部参数”，连点5次“miui版本”激活开发者模式。

　　返回到手机设置后点选“更多设置”—“开发者选项”，把“窗口动画缩放”、“过渡动画缩放”和“动画程序时长缩放”都设置为0.5X。

　　安卓手机卡顿卡顿原因及解决方法 篇4

　　应用程序方面

　　我们国内厂商使用的还是深度定制的安卓系统，虽然较原生安卓，会更个性化，但不可避免的会在系统内加入各类程序，所以安卓便会因为臃肿的应用程序变得卡顿。

　　后台管理方式

　　安卓的后台属于真后台，当你在安卓手机上开启一个程序后，如果你没有将其关闭，这个程序依旧会在后台运行，并且在后台运行的程序还能进行交叉唤醒，静默启动等等，即使锁屏了也依旧会运行。所以我们开启程序过多的情况下，会感觉到有一些卡顿，设备越旧，感觉越明显。

　　缓存问题

　　安卓在缓存后，便会将缓存文件保存到手机上，如果你没有清理，便会一直保存着，这样会使得手机的存储空间越来越小，也会使得启动APP的时候耗费时间更长。所以如果你的手机没有清理缓存的习惯的话，也会导致手机运行速度受到影响。

　　措施一

　　定期清理应用程序缓存垃圾

　　措施二

　　下载安装程序的时候将其安装到SD卡中

　　措施三

　　一周重启手机一次，让手机自动清除部分内存数据

Android为什么卡顿系统原理分析

安卓APP卡顿的原因如下：
一、Android系统本身太过于开放
它是开放的系统，频繁的安装与卸载必然会在手机内积累大量残留，这些手机底层的残留物并不会因为你把APP卸载了而自动删除，卸载APP没用的，一般用户也意识不到它的存在，久而久之越积越多。手机用久了，视频、微博、QQ这类APP必然会产生垃圾，使用最频繁，所以垃圾产生也多。如果不及时清理，产生大量垃圾也是正常现象。
二、应用开发者水平良莠不齐
APP开发者技术有高低，有的算法和优化做得很烂，导致应用在使用时产生大量不必要的垃圾文档占用ROM空间，各种毫无必要的後台自动启动和进程占用RAM.这又要说到Android宽松的审核机制，使得这些不规范APP得以流向消费者。由于Android用户没有良好的付费习惯，Android程序基本只能靠植入广告来挣钱，所以很多APP拼命植入广告插件。