下面，說一點題外話，希望借此和讀者一起探討交流，共同進步。開源世界，開放平臺，關鍵就是能做到兼容并包。 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，但我覺得它所蘊含的思想是正確的，是頗有價值的。 * * * * *