之前執(zhí)行代碼一直沒有問題五续，打debug包也不會(huì)報(bào)錯(cuò)，然后昨天上線打正式包的時(shí)候奸鬓，突然就報(bào)了一個(gè)匪夷所思的問題
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
}
}
大體翻譯下是
在發(fā)布版本中找到了一個(gè)很嚴(yán)重的錯(cuò)誤
你可以去解決這個(gè)在lint發(fā)現(xiàn)的問題，或者修改生成腳本
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
}
}
尋找原因
趕緊打開百度，把Lint found fatal errors while assembling a release target.搜索一遍棺耍，然后一水的把上面兩句話加到項(xiàng)目里就解決了。
android studio都告訴你了种樱，是個(gè)致命的錯(cuò)誤蒙袍，就這么忽略了俊卤，真的好嗎？
辛虧我們有良好的提交代碼的習(xí)慣害幅，于是乎我在git上一個(gè)版本一個(gè)版本的打包消恍，找到了開始出現(xiàn)這個(gè)異常的版本，發(fā)現(xiàn)在一段代碼中有兩行可以忽略的異常
這兩句代碼狠怨，是由于強(qiáng)行引用第三方arr文件下res目錄下面控件造成的，原因是因?yàn)榈谌絠d為btnSubmit和btnCancel的兩個(gè)button和我們自己寫的布局文件id相同的兩個(gè)TextView一致邑遏，編輯器以為你強(qiáng)行引用錯(cuò)誤了佣赖，所以在打包release時(shí)報(bào)錯(cuò)
解決方案
告訴編輯器，這里有代碼是錯(cuò)誤的view檢測(cè)
再次打包记盒，就成功了憎蛤！
思考
其實(shí)這個(gè)問題就是因?yàn)榇a編寫習(xí)慣不良好造成的
所以要：
1：代碼命名要規(guī)范
2：及時(shí)檢測(cè)有紅線的代碼，不要因?yàn)榭梢跃幾g過去纪吮，就無(wú)視
3：有時(shí)候這個(gè)問題會(huì)指出錯(cuò)誤在哪俩檬，可以通過編輯器報(bào)出的錯(cuò)誤信息去解決
