App的迭代过程中，线上问题频繁发生。开发时很容易写出一些问题代码，例如Serializable的使用：实现了Serializable接口的类，如果其成员变量引用的对象没有实现Serializable接口，序列化时就会Crash。我们对一些常见问题的原因和解决方法做分析总结，并在开发人员组内或跟测试人员一起分享交流，帮助相关人员主动避免这些问题。
为了进一步减少问题发生，我们逐步完善了一些规范，包括制定代码规范，加强代码Review，完善测试流程等。但这些措施仍然存在各种不足，包括代码规范难以实施，沟通成本高，特别是开发人员变动频繁导致反复沟通等，因此其效果有限，相似问题仍然不时发生。另一方面，越来越多的总结、规范文档，对于组内新人也产生了不小的学习压力。
有没有办法从技术角度减少或减轻上述问题呢？
我们调研发现，静态代码检查是一个很好的思路。静态代码检查框架有很多种，例如FindBugs、PMD、Coverity，主要用于检查Java源文件或class文件；再例如Checkstyle，主要关注代码风格；但我们最终选择从Lint框架入手，因为它有诸多优势：
功能强大，Lint支持Java源文件、class文件、资源文件、Gradle等文件的检查。
扩展性强，支持开发自定义Lint规则。
配套工具完善，Android Studio、Android Gradle插件原生支持Lint工具。
Lint专为Android设计，原生提供了几百个实用的Android相关检查规则。
有Google官方的支持，会和Android开发工具一起升级完善。
在对Lint进行了充分的技术调研后，我们根据实际遇到的问题，又做了一些更深入的思考，包括应该用Lint解决哪些问题，怎么样更好的推广实施等，逐步形成了一套较为全面有效的方案
大多数开发者可能都不知道：你可以自己写 Lint 规则。其实，在很多使用案例中，自定义的 Lint 规则往往大有用处：
如果你在写一个代码库/SDK，你想帮助开发者正确地使用它，Lint 规则就能派上用场。有了 Lint，你可以轻易地提醒他们忽略或做错的事情。
如果你的团队有了新加入的开发者，Lint 可以帮助他快速了解团队的最佳实践，或命名惯例。
https://blog.csdn.net/wangpeng198688/article/details/50751367
Android ------ 美团的Lint代码检查实践
https://blog.csdn.net/dickyqie/article/details/79950167
android 自定义Lint
https://blog.csdn.net/xiangzhihong8/article/details/62041022
gradle配置
