Android 操作系统-如何保障上亿行代码的质量与安全？

看到锤子发布会，写了一篇微信朋友圈，想了想又删掉，因为可能会引起误会，但又不吐不快，所以用这篇文章，聊一聊Android的质量与安全，吐槽下这个让人又爱又恨的操作系统。

爱，是因为它方便，易用，兼容性好，更新快。

恨，则是因为其操作系统漏洞何其多，Bug何其多，分层何其多，维护何其难，功能添加修改极不易。下面的链接，是互联网上最大的漏洞库CVE（Common Vulnerabilities and Exposures）上关于Android关键字的漏洞，总数目是78792条，从很早的1.0版本到现在的6.x版本，各种漏洞层出不穷。

http://www.cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Android

国内外绝大多数的手机厂商都基于Android系统进行了各种各样的调整，做成了自己的ROM和UI，伴随硬件发售给客户，因此第三方ROM及UI呈百花齐放之势，COOLUI、EUI、MIUI、Samsung、Smartisan（为表公平，排序为字母顺序）....林林总总数不胜数，我没有做过对比，相信各家有各家的长处，也相信大家都做了各种努力进行系统调优，尽自己的全力做到最好。

题外话，我很推崇国内技术型团队的工匠精神，上次我们老大来到北京拜访客户，很是感慨。他是清华大学的客座教授，很多年前来过北京，当时的北京还比较传统，高楼都很少。那天在和某技术团队交流后，他深刻的感觉到了中国一流企业中技术至上的氛围 - 这很像德国的“工程师文化 ”。关于这个，搜索后发现管理学大师赫尔曼·西蒙在其所著《隐形冠军》一书中有一些介绍：首先，德国企业对创新研发普遍都很重视，尤其那些隐形冠军企业，每年研发投入占销售额比例为6%，这个数字是世界上1000家研发最强企业的1.66倍。第二，创新由技术和市场需求共同推动。第三，为了提升效率和减少不必要的内耗，创新工作常常组建尽可能的小规模团队来担任。第四，高层管理者亲自挂帅创新工作，并参与到所有开发的细节。而在国内的一流互联网企业与创新行业，我们看到的研发投入往往更高，高到让人不敢相信。

桃李不言，下自成蹊，投入和回报是成正比的，所以你能够看到国内的创新型企业和行业层出不穷。

言归正传，我们还是回到Andriod，按下葫芦起了瓢，Android原生操作系统本身代码质量就不是特别好（相信我，你要是用Coverity检测一遍原生Android源代码的漏洞去修复，我保证能改的你不想吃饭），在这种状况下，如何保障Android系统的质量与安全？对手机厂商至关重要甚至生死攸关-时间就是金钱和市场。

我们先来看看根源：软件的Bug和漏洞，大部分都来自于编码阶段，看看Caper Jones的这张图（浅蓝色的曲线代表缺陷被引入的软件生命周期和比例，淡黄色的曲线代表缺陷发现的阶段和比例，红色的曲线代表在某一个软件研发生命周期中平均的Bug修复成本）：

结论是什么呢？编码阶段引入的Bug和漏洞最多，但发现的最少，绝大多数的缺陷/漏洞在软件测试阶段甚至软件发布后被发现。这样会带来什么问题？

1. 缺陷/漏洞定位到根源的源代码位置需要大量的时间和人力成本-你看到的现象是突然崩溃，后端可能是空指针引用的问题，但是这个指针是哪一个？研发人员抽丝剥茧，printf打几百次甚至上千次断点才能找到，我亲耳听到过一个Bug调试两个月的故事-别不相信，它是真的。当然也有人说可以用APM技术找到堆栈-但你仍旧避免不了下一步的痛苦。

2.Bug/漏洞定位到源代码后，修复所需的回归测试成本-要知道改动每行代码都需要一轮回归性的测试，确保你没有引入新问题-假如你有10个问题需要修复，那。。。。

如何解决？我目前推荐的解决方案是Coverity - 市面上唯一一个能够一次性检测上千万行甚至上亿行Android源代码的静态分析工具。它能够找到900多种质量和安全缺陷，（更详细的请查看http://www.coverity.com/products/code-advisor/#CWEcoverage，不仅包括CWE Top 25与OWASP Top 10，可以说Coverity是最全的，也是最准确的):）。：

• API usage errors
• Best practice coding errors
• Build system issues
• Buffer overflows
• Class hierarchy inconsistencies
• Code maintainability issues
• Concurrent data access violations
• Control flow issues
• Cross-site scripting (XSS)
• Cross-site request forgery (CSRF)
• Deadlocks
• Error handling issues
• Hard-coded credentials
• Incorrect expression
• Insecure data handling
• Integer handling issues
• Integer overflows
• Memory – corruptions
• Memory – illegal accesses
• Null pointer dereferences
• Path manipulation
• Performance inefficiencies
• Program hangs
• Race conditions
• Resource leaks
• Rule violations
• Security best practices violations
• Security misconfigurations
• SQL Injection
• Uninitialized members

第二个问题，是关于静态分析的部署模式：Android代码库这么大，每次分析后都要修复这么大量的缺陷？不现实啊。
我的推荐是"No New Defects"策略，简单的来说就是新添加的代码中不要引入新的缺陷，而遗留的历史缺陷，逐步、分层次、递进性的进行修复，这样就能够保证持续的质量提升。
举一个实际的例子，下图是典型的SDLC（软件研发生命周期）集成过程：

1. 研发人员（如张三）在本地编写代码后提交到源代码管理器SCM（Git）。
2. 持续集成工具Jenkins定时或自动执行构建并使用Coverity检测，找到研发人员最新源代码中包含的质量和安全问题。
3. 静态分析系统自动将Coverity的缺陷导出到缺陷管理工具中（如Jira），之后自动发邮件通知研发人员去修复。
4. 修复完毕，确保没有问题，SCM仓库接受提交。
这是典型的集中式部署和分析流程，然而对Android代码仓库可能不可行，为何？
太大了-几千万行代码的下载往往就需要几个小时时间，而研发人员肯定想尽快看到问题并修复缺陷，怎么办？
其实大家在图中可以看出，研发人员本地也可以执行Coverity检测，这一个策略，我们叫做“Clean Before Check In”，往往是“No New Defect”策略实施后再进行。这一个策略也可以改写为增量分析-即只检测修改后的文件和代码，避免全量分析造成的时间浪费。


时间已然不早，今天就写到这里，大家如果想使用Coverity，请随时联系我，我的手机(微信)：13311307163，邮箱是[e-mail]。
笔者刚从技术转销售，感觉并不容易，感谢大家一直以来的支持。

逸松手书。