ThinkSSL🔒 一键申购 5分钟快速签发 30天无理由退款 购买更放心 广告
下面,说一点题外话,希望借此和读者一起探讨交流,共同进步。开源世界,开放平台,关键就是能做到兼容并包。 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,但我觉得它所蕴含的思想是正确的,是颇有价值的。 * * * * *