Android 產品開發工作談:嵌入式系統技術講求整機開發

jollen 發表於 November 17, 2010 11:41 AM

嵌入式系統畢竟是一個需要高度「軟硬整合」的技術工作,這和過去台灣所熟悉的「PC」是很不一樣的工程。過去把 PC 模組化,大家可以分工生產個別模組,組裝後,安裝作業系統以及軟體。把這個思惟用在嵌入式系統開發上,可能會產生一些盲點。

以 Android 作業系統為例,廠商都能取得 reference code,以及 Android 使用許多開放源碼專案的成果,因此技術人員能進行更精緻的技術工作,例如:針對處理器優化編譯器。過去,把硬體做好,再安裝微軟作業系統,是台灣習慣的模式,但廠商無法取得源碼,最多只能使用 API 進行開發,所以直接取得能支援硬體的作業系統,是微軟模式的特色。

近期與許多經理人洽談 Android 產品的合作,發現微軟習慣真是如影隨形,以舊思惟思考新的產品,可能有許多盲點。產品研發的根本是技術,尚未脫離技術工作階段時,把專業的工作交給專業,是最基本的態度與責任。以下是小弟的一些個人看法,希望在此與大家分享,讓專案的成敗由技術決定,而不是身段與心態。請不吝指教。

嵌入式系統技術講求整機開發

如同一開始提的,嵌入式系統是非常講求細節的工作,所有的細節是為了讓軟體與硬體有更好的整合性,效能與穩定性的期中考卷,技術工作者必須努力交出及格的成績單。嵌入式系統的技術細節,往往超乎技術人員自已的想像。

過去的 PC & NB 研發工作,努力把硬體做好,用更快的處理器,把作業系統安裝到硬體上。「直接把軟體安裝在硬體上」,不管是硬體工程師,或軟體工程師,都不需要考慮軟硬體間的細節。所以,PC & NB 是一種不必過度講究開發細節的工作。

現在把 Android 放到 ARM 平臺上,開發手機,不但需要把 Android 提供的 reference code 做實作,更要進行許多細節的工作。幾個大細節像是:

1. Android 提供的 reference Launcher 夠不夠用?(穩定性、反應速度等)
2. Android 提供的 prebuilt toolchain 夠不夠用?(符號處理、指令集等等)
3. 開機速度。

還有更多的小細節需要我們努力,例如:PNG24 在 PNG8 的處理有失真問題 (GIF)。不同的硬體,細節不會相同,例如這裡提到的 PNG24 與 PNG8 處理問題。所有的細節是為了讓「整機」有更棒的表現,例如避免 PNG24 不出現失真,這個失真會是肉眼可見的問題,不該被忽略。

我們是一個專注嵌入式系統的研發團隊,開發「整機」讓我們全心在「這個硬體」上處理各種軟體細節。Android 產品也是如此。一開始就定位「整機研發」,因為這是技術的本質,嵌入式系統考慮硬體來做軟體,所以軟體綁硬體,是技術所導致的結果。

在我們 A 機器上表現良好的軟體,直接安裝到 B 機器,我們的軟體可能是 dirty software:達不到好的穩定性,也做不到好的速度,或許只有部份功能可以正常。因此,身為一個專業的技術工作者,當您遇到客戶提出「給我們源碼與硬體設計」,「我們要自已改硬體」,「我們自已改Driver」,「應用程式可以用外包方式處理」,等典型要求時,最好為自已爭取一段時間,靜下心來思考專案的可行性。

請不要把我的 Android framework 軟體直接「安裝」在您的硬體上。

技術學習者也應該更務實,以「Embedded Linux」來說,我們應該有耐心地去了解每個單元的設計、運作原理與架構,因為細節就是在處理這些技術,而不是學習操作或是 how-to。

取得參考設計,在硬體上加入模組,更換零件,把源碼當護身符,「因為樣機都可以跑了、改改東西不難」,是良方還是毒藥,需專業判斷,而不是籠統的認定。例如:2個G-Sensor還是3個G-Sensor,是不同的二件事情。商業周刊第1191期的標題「忘記會做微軟 不然就等死」,看起來聳動,但也真實;但是,我們必須往好處想,因為我們面臨的將不會是技術問題,而是心態問題。《待續》

Jollen's Blog 使用 Github issues 與讀者交流討論。請點擊上方的文章專屬 issue,或 open a new issue

您可透過電子郵件 jollen@jollen.org,或是 Linkedin 與我連絡。更歡迎使用微信,請搜尋 WeChat ID:jollentw