文／Jollen Chen（原文刊載於「零組件雜誌」2011年11月號）

經過10個月的等待，最新的Android源碼，千呼萬喚始出來。Android開始源碼專案，稱之為Android Open Source Project（即AOSP)，目前的最新版本是2.3，下一個AOSP將會是4.0。Google跳過Android 3.0的原因，據信是因為「Android 3.0程式碼不適合開源」，從技術面的角度來看，可能是碼源的組織結構尚未建全，以及架構設計並未經過全面驗證。

Android 4.0 跨裝置作業系統

從目前已公開的Android 4.0 SDK來看，確實是一個「跨裝置」的作業系統。代號為Ice Cream Sandwich的Android 4.0強調「手機與平板」通用，在新特色列表裡，我們也能發現，應用程式面的特色增加不少。事實上，這次Android 4.0的發佈，Google並沒有說明框架或底層技術細節的變動，而是強調應用軟體面的新功能。

Android 4.0可以說是Android發展史的「第三個重要時代」。熱呼呼的Android 4.0源碼即將到手，廠商應該如何調整接下來的研發策略？在此提供一些想法，請不吝指教。

軟體與產品公司興起、ODM 模式走入尾聲？

第一、產品公司的利基已經顯現。第三個Android發展時期，即Android 4.0的時代，訴求已經很明顯，那就是「應用軟體」。重視應用軟體，並不等於組織一個應用軟體研發團隊。實際上，Android Market近20萬個軟體，都是最好的「創意庫」。因此，Android 4.0對於產品公司特別有利基點，因為有了自有產品，才有機會專注在應用軟體與網路服務的整合，發展創新特色。

第二、系統廠應消除研發累贅。所謂的研發累贅，廣義上來說，可以是符合以下二個條件的工作：1. 重覆性工作、2. 研發成本過高的活動。重覆性工作視廠商性質不同而定，例如：感測器研發系統廠，「Android 移植」就是一個重覆性工作，因為接下來，廠商將能直接由「社群」或是「處理器原廠」取得完整度很高的參考設計，只需將重心放在感測器本身的整合，以及應用層面的創新等工作即可。研發成本過高的活動，說明在第三點。

走錯研發方向、修正成本相當昂貴

第三、研發成本很低或無限大。研發成本過高的活動，內容千羅萬象，在這裡舉一個例子：「技術研究」。技術研究的目的在於「精確掌握接下來的軟體與技術趨勢」，例如：多核心（Multi-core）接下來的主流會是「異質性」或「同質性」模型。這樣的能力通常只有專家型公司辦得到，例如：知名的技術服務公司Infosys就是一個例子。Infosys曾經提過，「當企業無法跟上技術變化，創新過程將變得緩慢」，因為一但走錯研發方向，修正錯誤的代價將極為昂貴。因此，技術研究是自組團隊，或尋求專家公司的協助，需要經營者的智慧。

彼得杜拉克：「巨變時代、徹底改造」

以上三個想法，主要是推測Android 4.0降臨後，產業現況可能會發生的化學效應，並取其重，當然還會有更多的變化，不只於這三個想法。面臨變化，新策略的制定，過去的經驗是否有幫助，這可能需要省思。企業經理人，可以從彼得杜拉克「巨變時代的管理」一書中找到一些想法，包含「徹底改造」也是巨變時代的一個藥方。

距離上次為自已的部落格裡新增文章分類，已經有一年的時間了，這次加入了一個 Multi-core Software 的分類，也代表自已接下來的技術研究重心，將會在多核心軟體開發上投入時間。

就在上週四(11/3)，Moko365與MagicLego團隊共同舉辦了一場「Multi-Core 嵌入式開發」研討課程。這次的課程，可以說是多核心軟硬體開發的「電腦概論」課程，不但是多核心開發的第一門課，更是了解「沒有軟體、沒有多核心效能」的基礎課程。針對自已的講題部份，在此做一些簡單的紀錄。

沒有良好的軟體設計，無法發揮多核心處理器的效能。既然如此，多核心軟體的涉及範圍為何？只需要作業系統支援多核心即可嗎？

答案是，多核心處理器需要軟體全面的支援，範圍從應用程式開始，一直往底層，直到作業系統，甚致驅動程式，都有很大的關聯。軟體如何支援多核心處理器，最大的關鍵在於「任務切割與指派」。研討課程當天，另一位講師Frank也利用一個影像處理的例子，說明影像處理如何分割任務，並將不同的任務，分派給不同的處理器。

另一個多核心軟體的關鍵為資料合併(Combine)，Frank同樣也以影像處理做為例子，說明每個處理器在完成計算後，將分別得到的結果(Data)合併成最終計算結果。這個部份，梁老師也利用了一個矩陣運算的例子做了很清楚的說明。

由以上的說明可以了解，資料合併的關鍵，最終在於「如何取用另一個處理器核心的結果(Data)」。在ARM Cortex A8/A9架構裡，這個問題，是透過共用記憶體方式解決。也就是Cortex A8/A9多核心架構，處理器核心間是共用記憶體。共用的記憶體包含二種，第一種是成本較高，但速度較快的 L2 Cache；另一個共用記憶體則是DRAM，它的成本較低、容量較大，但速度較慢。

任務切割的目的，在於將應用程式裡的計算工作，切割後指派至另一個處理器核心；讓應用程式，能真正使用多核心的計算能力。這就是為什麼多核心軟體的設計，決定了多核心系統效能。上述的觀念，就是「平行處理」。

從應用程式的層面，就要考慮多核心的設計。如何將一個計算工作切割出來，並指派至另一個處理器核心？方式就是使用multi-thread。以Linux作業系統為例，multi-thread程式設計使用一個稱為pthread的程式庫；因此，學習pthread程式設計，就是打好多核心軟體開發的第一個功課。

Android作業系統同樣是使用pthread程式庫，雖然Android的pthread程式庫，與Linux的pthread程式庫「是二個2不同的實作版本」，但同樣是依循POSIX的標準（pthread是POSIX thread的縮寫），因此，有志進入多核心軟體開發的工程師，可以先在Linux系統底下，學習Linux pthread程式設計。

此外，Android應用程式與框架層，採用Java程式語言撰寫，並且採用物件導向的基礎理論。目前所談論的pthread程式設計，則是用C或C++撰寫，我們將透過pthread所產生的thread稱之為native thread。應用程式使用Java語言撰寫，所產生的thread稱為Java thread。Java thread本質上是一個物件，因此也稱為Thread object。

應用程式與框架層的Thread object與更底層的Native thread關係為何？答案是決取於Java Virtual Machine的設計；JVM的Thread model設計，將會影響Java thread的行為，在多核心系統上，Thread model也會影響Java thread的效能。

「佔領硬體街」，原文出處：Calling all hackers: Occupy Hardware Street。很有趣，因為寫得很有戰帖的味道，但其實是很發人省思的一篇文章。

它的開場白：

This ought to be the era of the software developer.

「這應該是軟體人的時代」

在佔領華爾街後，為什麼要招集軟體高手佔領硬體街？從下一句話，就可以知道，軟體的價值，以及軟體時代真的到來了。原文的 Hacker 是「軟體高手」的意思：

Every week sees a new event courting the lowly hacker. Here are a few recent examples from my day timer: The Android Dev Con, ARM Tech Con, Blackberry Dev Con, Ubuntu Dev Con…and the list goes on.

「每週，都有很多活動，想要拉攏軟體高手，像是 Android Dev Con、ARM Tech Con、Blackberry Dev Con、UBuntu Dev Con。」

所以，不意外的，或許接下來會有 Baba Dev Con、Tizen Dev Conf 吧。拉攏開發者的活動，或是換個角度，「與開發者合作」的能力，是很重要的競爭力。這應該列入現代公司經營管理的一環，公司要建立與開發者的合作能力，而不是去雇用為員工，這個新改變很巨大，因為企業要學習如何與「Hackers」合作。

例如，軟體高手，他（她）可能想要發展自已的 App，並且在 Android Market 上銷售自已的軟體，甚至這些軟體高手，已經有多個熱銷的 App 了。「收編旗下」實在是個不好的主意，要招募他們為員工的可能機會不高，但可以和他們結為伙伴關係。這就是為什麼有些廠商，認為「好的軟體人才難尋」的原因之一。雖然旁邊的釘子很多，但這塊磁鐵吸不到半支。

看到這點，讓我想到，政府部門這陣子很用心在執行「App 軟體人才」的計畫，值得肯定；但方向可能有錯，或許是對「App 軟體人才」的認知不夠。正確的做法，應該是去協助並扶植 App 人才或團隊，形成一個新的產業，就像當初政府發展「竹科」一樣。從政府的角度，只做就業媒合，格局太小，需要全套的政策。

原文提到「Software Bay」的看法，很值得政府來做。在十月份的零組件雜誌專題報導中，我認為「台灣沒有軟體人才的問題」，但「管理軟體人才的方式出問題」是近二年教育訓練的心得。實際上，台灣軟體高手不少，很多軟體高手在國際上都有「好利害」的表現。像是最近在 AppStore 排行榜前十名的熱門軟體，有一個就是台灣的軟體團隊作品。

過去二年，為許多企業做 Android & Linux 教育訓練，觀察「軟體人才」問題也有很長一段時間了。我的心得是「其實軟體人才就在裡面」，這段期間，也遇到不少利害的軟體高手，我這個「老師」和他們的領域相比，相形見絀。例如，過去幾年，代工廠內部產出一批可以客製化 Linux kernel 的工程師，但就像原文提及：

Even Taiwan's notebook makers are hungry for all the low level software architects they can find—especially those who can help them customize Android kernels for their future smartphones and tablets.

代工廠，你們有 Developer 等級的 Linux 高手，為什麼還缺人才，確實值得思考。所以，台灣有軟體高手，產出人才不是重點，怎麼去凝聚這些人，才是重點，怎麼做？這個部份，其實像是創新工場，或是台灣的 Mr. Jamie 都有很不錯的做法。或許學習 Mr. Jamie 的模式，才是政府該做的事情。

原文最後，是我覺得最好玩的一句話：

So, software developers, today is your day to unite. You have nothing to lose but your shackles.

「所以，軟體人，今天是你們要團結的日子，你們沒有什麼包袱，只要解開你的桎梏」

這個「shackle」是什麼？作者的意思應該是「不要怕、要勇敢」，意思是軟體人要站出來做點自已的事情了。因為「Software is becoming the key differentiator in electronics everywhere you turn.」，你的產業或許不把軟體當一回事，就這是不要怕，要拿開 shackles 的意思。如果您是在科技業的軟體人，也參與過一些硬體研發專案，這不需要再多講了，我想我們都有默契。

關於Java virtual machine的Thread object model，理論上的做法是「一個Thread object連繫(Binding)到一個native thread」。從multi-core的角度來看，這是一個很理想的做法，實務上是否有採用這種Thread object model的Java virtual machine呢？答案是，有的；這取決於virtual machine與作業系統的設計。

JDK6搭配Ubuntu 8.04的環境，以及Android 2.3搭配MagicLego的kernel來看，都是上述的thread model。當然，這裡只是以我自已目前使用中的開發環境當例子，不僅只於這二個環境。

為什麼一個Thread object連繫一個Native thread是比較好的做法，適合應用在multi-core的場合，這涉及到多核心的kernel scheduling技術，在後續的文章裡再做討論。基本上，只要您的系統是屬於上述的Thread object model，未來都能提供一個良好的多核心軟體開發環境。

應用程式到框架，框架透過JNI來到C/C++底層，Thread object與Native thread是一對一關係時，作業系統再將指定的Native thread指派到另外一個處理器，接下來就可以得到這樣的效果：Thread object被指派到另外一個處理器了。這就是為什麼應用程式的設計，以及底層的軟體系統，決定了系統是否能實現「多核心運算」的原因。

本課程範例目前已順利移植至 Android 4.0.1 版本。「Android HAL & Framework: 軟硬整合實作訓練」課程，從2009年開辦至今，已經將有二年半的時間了，在這二年多的時間裡，歷經了 Android 1.6/2.1/2.2/2.3 共四個版本，今天也正式踏入了 Android 4.0 版本。

還記得「Android HAL & Framework: 軟硬整合實作訓練」第一次開課是在2009年7月份，在北京紫竹橋附近的訓練教室，大約有50位同學參加。當時，大家是在「不太了解」什麼是 HAL 與 Framework 的情況下來上課，所以似乎是 Android 的超高人氣幫了最大的忙。

這次將課程範例移植至 Android 4.0，其實是一個「無痛」的過程，程式碼實作本身並沒有什麼修改，只須對 Android.mk 做微幅調整，再重新編譯即可。學員若有意將課堂範例移植到 Android 4.0，可參考仕橙3G教室發佈的修改方法，再重新編譯即可。

課程範例的主要訴求是「依循標準架構」來設計，設計如果能符合標準架構，並依循物件導向的觀念，便能得到相當容易維護並移植的程式碼實作。當然這就是這門課程的主軸，「了解 HAL 與 Framework 的架構、設計與原理」。Android 的開發有許多觀念必須事先建立，例如：範例儘可能不去更動 Android 框架的原始碼。由於沒有對 Android 框架程式碼做修改，因此將新功能移植至新版本時，可以節省相當多的時間。