问题还原
新的一期版本开发，过程比较顺利，测试那边的bug也比较少，正是美滋滋的打release包，让测试人员再确认一下，就可以上线的时候了。然而在打正式包的时候，Android Studio毫不客气的给我浇了来了一出错误：
org.gradle.api.GradleException: Lint found fatal errors while assembling a release target.
To proceed, either fix the issues identified by lint, or modify your build script as follows:
...
android {
lintOptions {
checkReleaseBuilds false
// Or, if you prefer, you can continue to check for errors in release builds,
// but continue the build even when errors are found:
abortOnError false
}
}
也算是给我当头一棒了，这让原以为开发、debug都没问题，编译正式包也没问题的我，有点懵逼。我们都知道，Lint是检查静态资源的（也就是布局文件啦、图片啊等等res目录下的各种文件），Lint检查出问题一般都是资源文件的问题。好啦，接下来就分析一下问题吧。
问题分析与解决
这段话简单翻译一下的意思就是，Lint在编译release包的时候发现了致命的错误。为了继续编译或解决Lint标记的问题，或许应该对你的构建脚本进行如下的改动，即在app主module的build.gradle里增加lintOptions，其中checkReleaseBuilds false表示在进行Release构建时不再进行Lint检查，abortOnError false则表示检查到错误后继续编译，不取消当前的构建任务。
好了，问题的大意我们明白了，而且Gradle也给出了解决方案——不过，这个所谓的解决方案，虽然能让编译继续进行，但作为开发人员，绝对不应该逃避这种错误。是的，很显然，Gradle给出的方案就是一种逃避，实际上我们的程序真的是某个地方存在问题，才导致了这样的错误。
那么到底问题可能出在哪里呢？实际上Gradle还是给我们生成了相应的细节文件的，具体位置在app(假如你的app主module就叫app)/build/reports目录下，有一个名为lint-results-release-fatal.html的网页文件，我们打开这个网页文件后，就能看到具体问题出在哪里了。
比如我这次遇到的问题，实际上是因为这个叫做activity_learning_therapy的布局文件的119行有错，mBJPlayerView并没有定义。好吧，真是一个简单而愚蠢的问题，感谢Lint的强大。
总结
- Lint的功能还是很强大的，开启它的检查也很有必要，没到迫不得已的时候，是不应该关闭Lint检查功能的。什么是迫不得已的时候？说实话我也不知道。
- 代码中有错误，哪怕就是这么粗心马虎的小问题，也可能会造成严重的后果。比如我这次的问题，如果用户来到了这个布局文件所在的页面，那么整个页面的展现会跟UI设计完全不同。
- 作为一个合格的开发人员，绝对不应该逃避问题，而是应该想方设法的解决这些问题。越是承担责任，你越是会进步的更快。
评论