Intellij 的Java/安卓工具链有着一种不可持续性，这种不可持续性体现在多个方面。
首先是不可持续运行。IDEA 使用时间越长，内存占用越大，从不主动释放。运行时间越长，日志越多，从不主动清理。
然后是不完整的开源，从源码编译时需要下载更多依赖。而研究更多依赖就要消耗更多的精力与资源……
合理选择 IDEA 与 Gradle 版本
Android studio 是闭源的工具。它使用gradle构建安卓项目。gradle又是从网络下载下来的，至少有三个部分、三种语言。
Android SDK 也是闭源的。并且还附加了使用协议，只能用于为安卓兼容的设备开发app。
IDEA 的 Android Support Plugin 是开源的，效果和 Android studio 基本一致。但仅有内置的 Android 插件还不行，首次编译安卓项目时 IDEA 还需要下载许多资源。
Gradle 的中文意译当为 —— 小混球儿。它也是开源的。但是兼容性很差，需要配合特定版本的 IDEA 才能正常运行。
Gradle wrapper 7，比如 gradle-7.3.3-bin 相比于版本 6 ，增量编译更快。原本十秒，优化至三四秒，甚至1秒。但是版本 7 不支持 IDEA 2023 以前的版本，所报错误匪夷所思：
Querying the mapped value of map … before task ‘:app:compileDebugJavaWithJavac’ has completed is not supported CSDN博客
Android Studio：Gradle project sync failed_unable to find method ''java.lang.string org.gradle-CSDN博客
如果升级最新版本的 IDEA 2023，那么恭喜你，这个问题不出现了。不是因为解决了，而是免费的 IDEA 2023 压根不让你玩安卓，需要付费解锁 ultimate 。
如果尝试自行编译 gradle ，那么你会遇到更多问题，占用更多c盘空间。
Gradle / Can not build gradle from source code · Issue #5282 · gradle/gradle
只能用不新不旧的 IDEA 2023.1 。几番测试下来，已经用了 c 盘十个G了……
不新不旧的 IDEA 内置不新不旧的 open jdk 17。这玩意儿最恶心在于强制模块化，许多旧项目需要添加许许多多的 jvm 参数才能编译：
jdk17运行程序报错module java.base does not open java.lang.reflect to unnamed module @_module java.base does not "opens java.lang.reflect-CSDN博客
上面博客是将启动参数放到设置里。我参考的是博客写入 gradle.properties。
如果编译过程使用了gradle插件，可能还需要更多参数，比如我的改成：
org.gradle.jvmargs=-Xmx2048m --add-exports=java.base/sun.nio.ch=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.reflect=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.model=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED \
\ --add-opens=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED \
\ --add-opens=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED
这么一长串启动参数，每一个add-opens都要试出来的，谁懂啊。也可降级，用旧的 jvm 运行 gradle。
解决log无底洞
运行 gradle deamon 会持续记录log，这些日志累积可达 10G、甚至百G，从不自动清理。
Gradle / Gradle logging hygiene · Issue #2688 · gradle/gradle
这个问题仍然存在，按照issue中的方法提高 Log 等级、自定义任务等，只能缓解无法根治。
我的解决方法很有技巧性，配合了符号链接(Symbolic Link) 与 用户空间文件系统（Filesystem in Userspace）。
用户空间文件系统（Filesystem in Userspace）： 是虚拟的文件系统，但可以挂载。第三方程序感觉起来，无异于真实文件系统。windows上的fuse是dokanky，持续开源、性能好、上手简单（借鉴官方mirror.c镜像文件系统）。
dokany mirror.c github
自己写的 fuse 可以移花接木，拦截修改，令行禁止：
-
可以直接禁止创建log文件，但是那样 gradle deamon 启动崩溃。
-
可以禁止写入，但守护进程陷入死循环。
-
于是只能循环写入：只允许写入 1kb，超出部分从头写入。
符号链接(Symbolic Link)： 有别于普通的lnk快捷方式，会被第三方程序识别为目录，从而达到移花接木的效果。
使用指令创建符号链接： mklink /D deamon V:\deamonX，其中 V:\deamonX 是镜像文件系统，强制IDEA打印日志时循环写入。
为什么不直接将 fuse 挂载到 deamon 呢？因为 dokany 一个线程只能有一个挂载点，为了节省性能，我用一个盘符为所有磁盘开启镜像文件系统，并用不同目录区分不同功能：
J:\c\ 代表 c 盘回收站内容（解码了文件名乱码，可正常打开）。其中双横杠开头的文件夹代表特殊功能区域：
– encrypt – 是对该磁盘回收站内容的加密镜像。（调用 openssl aes 加密）
– entropy – 是对该磁盘所有文件的加密镜像，以及加密文件的解密镜像。
– equator – 是对该磁盘所有文件的原始镜像，添加了上述日志写入的限制。
这样我就能用一个挂载点，实现许许多多不同的功能。
再配合ahk用户脚本引擎，添加快捷键，可以一键往返真实目录与镜像目录，任意穿梭，方便无比。
解决内存无底洞
其实 c++ 调用 java 方法可以归还内存，实现零泄漏、占用零增长的。不知为何 IDEA 只能持续占用内存，从不归还。
编译几次就整个重启？还可以结束 gradle 守护进程，保留IDEA本体。本体重启守护只需几十秒，很值，只需：
windows的任务管理器。没谁了吧，mac、linux、安卓哪一个这么能打？
其中图标写着JB二字的进程里，就住着我们的小混球gradle，等他增长到1gb，idea本体4gb的时候就可以结束他，开启新的轮回，实现可持续性编译！
