背景：
在日常调试Android Native代码时，点完Gradle Build便可拿起手边的快乐水小嘬一口，等着编译完成，若是刚刚改了一些影响范围较大的文件，亦或是pull了一下代码，一次build便可以打开手机小搓一下。但是某一次搓完手机回头看电脑时，gradle build faild出现在了build栏，甚至还是嘲讽的√号开头。
于是气不打一处来重启了 AS、重启了电脑，发现无济于事....所以开始认真解决问题了
排查步骤
首先怀疑的是Clang编译时间过长，导致Gradle的daemon Crash，因此导致整个build failed，于是关闭了gradle daemon，问题依旧。接下来尝试手动打开build的log查看崩溃点在哪里，发现clang居然OOM Crash了，而且每次Dump的位置还不一样，但是查看编译时的RAM消耗，发现至少还有1GB的RAM处于FREE，因此拓展内存的想法也被暂时放在后面。
开始怀疑是不是gradle和AS对clang造成了什么影响，因为AS此时的JVM占用了近6GB的RAM。因此尝试关闭AS，手动调用Ninja对Native部分进行编译，发现编译正常通过，同时内存占用在编译到最后发生了一次快速增长，从300MB*8Clang++Thread猛增到700MB*8Clang++Thread，简单计算一下，原来之前编译到最后发生的卡顿有可能是引起了Swap，同时由于Swap空间有限，AS占用的RAM超过SWAP能释放的空间，引发了Clang的OOM Crash。所以.....没有办法，只能暂时在RAM上做妥协，一是缩减AS中JVM的RAM大小（因为主机又整了几根内存，所以JVM的RAM分配不减反增），二是提升整机的RAM容量。双管齐下后Gradle build正常工作。
总结
没想到8核的Clang能吃掉如此之多的内存，因为Gradle 在 Failed没有dump出错误，因此问题排查的难度被提高了，同时由于Clang在申请内存时十分突然，导致Top工具和free等内存监控工具来不及刷新出内存平静就已经Crash了，因此真正的原因被放过了一次。还有就是吐槽AS现在每一个版本更新后，确实带来了很多不错的新功能，但是RAM消耗也越来越大了，对开发者主机的性能的要求也是一步步的提高了，经过这次问题解决，开发机RAM成功升级到32G（笑
