Android studio运行很卡怎么清理缓存?
作者：佚名
字体：[ ] 来源：互联网 时间：01-15 11:20:43
最近打开Android studio软件感觉很卡，应该是运行程序的时候产生的缓存，想清理Android studio的缓存该怎么办呢？下面我们来看看Android studio清理缓存的教程，需要的朋友可以参考下
在eclipse的当中进行运行Android的运用的程序的时候，就会产生内存缓存的信息，而eclipse是可以直接点击停止运行程序，然后点击清除缓存，就可以解决了这个问题，而Android studio却不能直接点击停止运行的，而只能通过其它的方式来清除Android studio中的缓存。
1、可以看到Android studio的运行的结果界面中没有看到的为停止运行的按钮和清除缓存的按钮。
2、首先需要在Android studio的界面中找到一个正在运行的项目，选中正在开发的项目。
3、然后点击菜单栏中的&file&的选项。
4、弹出的下拉菜单中可以看到为&invalidate caches/restart&的选项，点击进入即可。
5、然后会弹出一个invalivdate caches的选项框中，根据提示进行确认，一般点击&invalidate and restart&的选项。
6、这样Android studio开始进行清除缓存然后进行重启，再次打开Android studio。
相关推荐：
大家感兴趣的内容
12345678910
最近更新的内容2016年8月 移动开发大版内专家分月排行榜第二
2016年9月 移动开发大版内专家分月排行榜第三
匿名用户不能发表回复！|
每天回帖即可获得10分可用分！小技巧：
你还可以输入10000个字符
(Ctrl+Enter)
请遵守CSDN，不得违反国家法律法规。
转载文章请注明出自“CSDN（www.csdn.net）”。如是商业用途请联系原作者。Android Studio编译慢、卡死和狂占内存怎么破？ - 知乎305被浏览60483分享邀请回答177 条评论分享收藏感谢收起Android Studio编译慢、卡死和狂占内存怎么破？ - 知乎305被浏览60483分享邀请回答compileDebugJavaWithJavac/compileReleaseJavaWithJavac
和 将 class 合并成 dex transformClassesWithDexForDebug/transformClassesWithDexForRelease
这两步很耗时，第一步还好，第二步会耗时非常久。首先在 gradle.properties 里设置 org.gradle.jvmargs=-Xmx4096m //越大越好
，然后在工程的 build.gradle 里的 android 结点下增加 dexOptions 配置，如下：dexOptions {
dexInProcess true
preDexLibraries true
javaMaxHeapSize "4g"//越大越好
incremental true
明确了 gradle 的生命周期，那么就可以看到加快编译速度的关键就是从第三步入手，当然，减少 setting.gradle 里的 modules 数量这一步也是必须的。下面说说我们公司的实践吧。项目插件化改造，每位业务上的同学只需要编译一个模块即可，这一点基本上从根本上解决了编译慢的问题（对于大多数没有插件化需求的朋友们可以看下面的一些实践），首先 setting.gradle 里的 module 只有自己开发的模块了，而对应的执行阶段的任务也只有这一个 module 的任务了。执行一次 gradle build ，我们就会发现，在这个过程中，其实是执行了多次打包任务的，在 buildTypes 里配置了多个编译打包类型，默认有 debug 和 release ，我们还可以手动配置其他的类型，而且还有 productFlavor 里的多渠道，这样就会执行多次编译打包，而正常开发过程中，只需要打
debug 包去调试，因此使用 gradle assembleDebug 即可，等发版的时候使用其他方式去打多渠道的包（如美团的方案）；既然编译主要时间都集中在 gradle 生命周期的第三步执行 task 任务里，那么我们就可以把一些无关紧要的任务给禁用掉，比如各种 Test ，各种 lint 等，刚好在 gradle 里有这样的指令 -x lint 可以临时禁掉 lint 任务，-x test 可以禁掉 test 任务，事实上对于一个稍微大一点的项目，lint 也是很耗时的，当然也可以通过 gradle 脚本彻底禁用 lint 和 test 任务，我也在一些微信群里分享过相关代码，但是不太建议这么做，因为有时候 lint 和 test 也是挺有用的；gradle 本身提供了一些指令参数可以加快编译，比如 --daemon ，开启守护进程，--parallel ，开启并行编译等，这个也可以在 gradle.propertites 里配置（编译使用的 jvm 内存也可以在这里配置）。定制 gradle 编译流程，利用官方提供的 API 完全可以定制一个适合自己的编译流程，可以参考一下携程的 ，里面有携程他们自己整个完整的编译流程，脚本本身很简单，一共只有两三百行代码。上面讲到的几点，现有环境就可以做到的大概是这样（有一点要特别注意，如果工程里有交叉依赖，一定不要使用 --parallel 参数）：gradle assembleDebug --daemon --parallel -x lint -x test
，如果是要直接安装到设备上的话，就把
assembleDebug 换成 installDebug ，assembleDebug 可以简写为 asD ，installDebug 可以简写为 iD 。最后讲一下，为什么减少 setting.gradle 里的 module 数量，确实可以加快编译，但是却限制颇多呢？首先，我们想一下整个编译过程，先去解析 gradle 配置，建立 tasks 依赖有向图，然后再去执行每一个 module 的 task ，如果我们通过 maven 依赖，使用 aar 替掉了 module（单指 android library），如果我们要改这个 module 里的文件，岂不是每次都要修改上传再下载，这其实还好，但是有一个致命的问题：不修改版本号的话，SNAPSHOT 在 IDEA 里经常会不好使。这样就导致修改的东西会不生效，去解决这个问题是非常耗费时间的。不过有一种方式，可以一定程度上解决问题，增加下面的脚本：project.configurations.all(new Action&Configuration&() {
void execute(Configuration files) {
files.resolutionStrategy.cacheDynamicVersionsFor(5, TimeUnit.MINUTES)
files.resolutionStrategy.cacheChangingModulesFor(0, TimeUnit.SECONDS)
那有人会问，插件化里，每个人开发一个模块，对于每个模块的维护不也是要打包上传到 maven ，每次一有修改，哪怕是非常微小的修改，也要做一次上传，同样会遇到 SNAPSHOT 不好使的问题。嘿嘿，这个问题嘛，我司自己维护了一个 gradle 插件，已经解决了，至于解决方案，是公司机密，我是不会讲的。然后，还有一点，我相信大部分开发者平常开发都是单 module 的，多 module 的情况并不多，因此大多数依赖基本也都是 aar 或者 jar ，根本就不存在所谓的将 library 转成 aar 上传的情况，因此一些答主说的根本毫无意义，这也是为什么我会说影响编译速度的情况主要集中在 gradle 生命周期的第三个阶段，至于第三个阶段的优化，看我上面的答案就好了。9117 条评论分享收藏感谢收起102 条评论分享收藏感谢收起查看更多回答1 个回答被折叠（）}