“自主”手機操作系統：如何判定及怎么做

　　案例

　　這里給大家介紹筆者早先和美國一家公司合作，嘗試搭建的一個操作系統，其實在當年這些東西的基礎上，搭建出來一個有別于Android的開源“自主”操作系統還是非常快的。

　　這個系統使用了Linux內核和標準的C/C++函數庫，以及一些和Android體系結構類似的C/C++運行庫，使用了筆者公司的開源軟件MiniGUI、WebKit瀏覽器核心引擎等等。基礎的東西就這些。之上是開源的KaffeJVM(后來改成了CacaoJVM)，和符合J2SE規范的類庫實現，再往上就是運行環境和框架了。見下圖：

　　可惜的是，真正具有核心價值的運行環境和框架，是美國合作方自己開發的，我手里沒有源代碼。相信讀者也能明白，美國合作方掌握的才是精華。

　　如果要在這套系統基礎之上快速開發一個“自主”的操作系統，我們需要：

　　·重新定義類庫，也就是基礎API，讓我們的系統從靈魂上有別于其他系統。必要的話，優化或替代開源的虛擬機(淘寶最近開源了一個JDK虛擬機，不過是針對J2EE的)。

　　·全新設計和實現適合于智能手機的運行環境、框架。

　　·全新設計基本的智能手機應用軟件。

　　·開發模擬器，并集成到Eclipse集成開發環境中。

　　·還有，這個系統是2006年開發的，我們還需要將底層的內核、基礎函數庫等更新到比較新的版本。

　　要做的工作還是蠻多的，但這個系統在2007年的時候，就已經可以運行在主頻在200MHz左右的手機上了。

　　當然，這個系統離本人定義的真正“自主”的操作系統還有很大的距離。但是，起碼技術上的方向是基本正確的，要知道，這個系統幾乎是和Android同時發起的。后來在2007年，谷歌宣布開源Android后，美國合作方敏銳感覺到了Android將是未來的趨勢，就直接轉向了Android平臺，項目也就終止了。

　　五、給相關人員的建議

　　1、給政策制定者：“自主”切忌急功近利

　　這里所說“政策制定者”主要指的是“核高基”等政府資助項目的決策人。其實前面已經說過了，這里重申一下：

　　政府需要在更長的周期內(至少五年)，考核受資助企業的市場份額是否有擴大，是否建立了良好的生態系統，讓使用者、開發者欲罷不能，而不是簡單的著作權證書和專利數量，或者是否達到了一個給定的出貨量(因為出貨量是可以作假的)。也就是說，我們應該重新定義“自主”這兩個字，從“自有知識產權”向“有效知識產權保護下的自己主導”轉移;在知識產權方面，要強調有效專利數量，而不是著作權;甚至應該要求受資助企業按某種許可證條款開放源代碼。

　　政策制定者甚至可以參照本文第三章給出的“自主”操作系統之定義，將整個“自主”操作系統的研發和推廣分為三個部分：

　　·科研類，兩到三年為周期，以研究新的編程語言及其相關設施(如虛擬機及其優化技術)為主。

　　·工程類，兩到三年為周期，圍繞指定的編程語言發展外圍工具鏈(編譯器、調試器)、開發工具、運行環境、框架等。

　　·法律類，半年到一年為周期，研究和分析采納已有編程語言面臨的知識產權風險，如何規避等等。

　　政策制定者切忌急功近利，要按照客觀規律辦事，將科研類的課題交給研究機構，將工程類以及市場推廣等方面的課題交給企業，將法律類的課題交給大專院校。只有這樣，才能首先讓方法正確，方法上正確，加上合理的考核制度，才能讓錢產生真正的效益。

　　在花錢方面，在一盤大棋下的統一部署下，初期讓多一些的企業或機構參與，一年一驗收，逐步淘汰那些不合格的，最后剩下來一、兩個企業就好。十億美金，外加企業自籌部分，我看基本夠了。

　　2、給大型企業決策者：“自主”大不易

　　有意開發“自主”操作系統的大型企業決策者首先要明白，開發“自主”操作系統是一個長期、艱巨的系統工程。甚至，你需要準備一大筆錢來和已有的巨頭打官司(微軟賠付給Sun幾十億美金之后，才讓自己的C#和.Net平臺成為“干凈”的語言和平臺)。

　　另外，如前所述，不管是真心還是假意，都要拿出十足的架勢來真做，而且，對內、對外都要強調這點。要知道，你期望得100分，下屬大多數情況下只能給你80分;你期望得1000分，下屬也許就可以給你500分。這樣才能超出決策者自己的預期，才能收到更好的效果。

　　3、給技術負責人：難度不亞于“兩彈一星”

　　這事兒如果恰好讓你負責，那簡直是，怎么說呢，是個“揚名立萬”的機會啊!你要知道的是，這事兒和制造“兩彈一星”差不多。

　　首先你要掂量掂量，你有沒有這個本事。所謂“沒有金剛鉆，不攬瓷器活”，說的就是這個道理。有興趣的也別來找我，我做點小項目可以，真要我負責，我沒這個本事。

　　另外一方面，你要是違背知識分子的良知，幫助一些不良人員騙取國家的資助款項，就更不應該了。這可是要被人戳脊梁骨的;有沒有錢拿永遠是小事，昧了自己的良心可是大事。

　　4、工程上的建議

　　在具體的研發實施過程當中，開發負責人必須特別注意工程方面的問題：

　　先做什么、后做什么，或者那些可以并行做。

　　不同的軟件模塊，應采取不同的軟件開發管理模型。API設計、框架等的開發，適合采用瀑布法模型;應用軟件或者小型模塊的開發，適合采用敏捷開發模型。但整個系統，應要不停迭代，所以版本控制非常重要。

　　特別要注意代碼的質量控制以及文檔的全面、完備、簡潔和邏輯性。