下面，说一点题外话，希望借此和读者一起探讨交流，共同进步。开源世界，开放平台，关键就是能做到兼容并包。 1. CTS和单元测试 了解一点驱动开发的人可能都会知道，芯片的类型太多了，操作起来也不一样。这必然导致，一个东西就得写一套代码，非常繁琐，并可能反复创造低价值。 做为一个应用层开发者，我非常不希望的是，下层驱动的变动影响上层的应用（在工作中经常发现问题像病毒一样随意扩散）。当然，Android已经提供了HAL层，任何硬件厂商都需要实现这些接口。硬件厂商的这些代码是需要编译成程序来进行验证的，可我不想拿应用层程序来做测试程序。因为应用层程序有自己的复杂逻辑，可能触发一个声音的bug，需要满足很多预期的条件，否则会非常影响HAL的测试。有没有办法解决这一问题呢？像Google这样的公司，面临着很多硬件厂商，它又是怎么解决的呢？ 我从CTS上看到了希望。CTS是Google为Android搞的一个兼容性测试，即不管是怎么实现硬件驱动的，反正得通过我的CTS测试。当然，CTS并不是用来测试硬件的，但是它的这种思想可以参考和借鉴。 **我很羡慕iOS的应用开发者，他们面临的由于硬件变化导致的问题要少得多。** 其实，如果做驱动移植的同仁们能以测试驱动开发的态度来严格测试，可能我们这些上层开发人员就不会总怀疑是驱动的问题 了。 2. ALSA——Advanced Linux Sound Architecture ALSA是什么，大伙儿可以网上google之。现在在大力推广ALSA，但在Android这块，我个人感觉它还不是很好用。“不好用”，是从上层用户的角度说的，ALSA提供了一个用户空间的libasound库，而这个库的确比较难用。不过有了Audio HAL的帮助，应用层就不用做改动了，但是实现HAL层的厂商要做的改动就比较大了。相比较而言，我觉得现在的源码中使用的open/ioctl方法更为方便。 >[info] 说明：这可能和我做过的应用太简单有一定关系（就是ffmpeg编解码MP3，然后播出来即可）。而libasound提供的API较多，在权衡各种情况后，我觉得它不适合快速简单应用的开发。 3. Desktop Check Desktop Check虽然是一种行为，但我更觉得它的产生是基于了一种态度。DesktopCheck本意是桌面检查。起因是在计算机技术刚兴起时，程序员调试代码非常费劲，因为那时机器配置很差，调试工具也不像现在这么发达，有时要跑到机房，预约机器然后启动调试器，所需时间远远多于坐在电脑前修改一个bug的时间。对于这种情况怎么办？为什么不像考试那样对自己的代码多检查几遍呢？自己虚拟一些应用场景，结合参数代入程序，在大脑中Trace岂不更好？这正是DesktopCheck行为的本意。 今天，很多开发人员不厌其烦得添加log，然后运行看输出。当然，这是解决问题的一种比较好的办法，但是在时间充裕的情况下，我还是希望开发人员能像我们前辈那样，用Desktop Check的这种方式先反复阅读和检查程序，争取在大脑中模拟程序的运行，最后才用打印log的方法来验证自己的想法。 另外，Desktop check对提升阅读代码的能力有重要帮助。 * * * * * **说明**：已记不得第一次接触Desktop Check一词是什么时候了，或许当时还不叫Desktop Check，但我觉得它所蕴含的思想是正确的，是颇有价值的。 * * * * *