Windows Mobile開發，Native C++ PK .NET Compact Framework

緣由

經常聽到一些剛剛接觸Windows Embedded CE和Windows Mobile開發的人會提出一些疑問。進行Windows Mobile開發，到底使用什麼語言呢？C++還是C#？Java行不行？下面就我自己的想法講述一下Native C++ 和 .NET Compact Framework的異同和選擇。

 

什麼是Native

Native翻譯成原生，Native是使用C,C++或者彙編等語言代碼編寫的，編譯成處理器相關的binary檔案(執行檔案,DLL等可執行檔)， 關於可執行檔可以參考http://en.wikipedia.org/wiki/Portable_Executable 。當前Windows Embedded CE和Windows Mobile支援的硬體平台包括x86, MIPS, ARM和SuperH。由於各個平台之間的指令集不一樣，所以可執行檔不能互相支援其他平台。使用Native 開發，程式不依賴於任何其他子系統，例如.NET Compact Framework運行環境，JVM運行環境等，但是一套程式必須為各個硬體平台編譯不同的可執行檔。

 

什麼是.NET Compact Framework

基於.NET Compact Framework開發的程式，可以叫做託管程式，英文叫做Managed code。所謂Managed code就是使用C#,VB.NET語言來編寫代碼，使用.NET Compact Framework來開發，編譯成平台無關的中繼語言(Intermediate Lanuage, IL)的檔案的程式。基於.NET Compact Framework開發的程式，在編寫的時候會使用到.NET Compact Framework 基礎類庫(.NET Compact Framework Base Class Libraries, BCL) ，BCL為應用程式提供API。託管程式在啟動並執行時候會使用到運行時執行引擎(run-time Execution Engine, EE), BCL和EE統稱為Common Language Runtime (CLR)。當託管程式首次執行的時候，CLR會把IL檔案編譯成相關平台的binary檔案(可執行檔)。這個過程叫做Just-In-Time (JIT) compilation。由於有了這一個過程，所以所有Managed 程式碼都依賴於CLR，因此，需要運行Managed 程式碼的裝置必須安裝 .NET Compact Framework。

圖來自於Windows Embedded CE 6.0 Fundamentals Chapter 9.

 通俗化Native Code vs. Managed Code

上面講述了一堆理論的東西，下面使用一個通俗但不是很貼切的例子講述Native和Managed，Native翻譯成原生，其實有地道的，與生俱來的意思，例如你天生說普通話，那麼可以說你是Mandarin Native Speaker。也就是與生俱來說普通話，地地道道的普通話。如果你要做一些語言相關的產品進行銷售，如果你在銷售產品之前把之翻譯成各個語言，例如在國內銷售翻譯成中文，在美國翻譯成英文，在日本翻譯成日文，這好比你使用Native Code來開發，在編譯時間已經為各個硬體平台產生原生的機器代碼。但是Managed(託管)代碼就好比世界語，世界上沒有那個民族和地區天生就說世界語，但是你使用世界語來銷售你的產品。針對每個不同國家和地區，你附送一個及時翻譯機，這個翻譯機會在使用者使用的時候把世界語翻譯成當地原生語言。這就好比基於.NET Compact Framework開發的代碼，需要CLR來翻譯執行。這裡注意不同硬體平台CLR是不一樣的，他們功能都是把IL編譯成Native的機器碼，但是各個平台的機器碼不一樣，所以.NET Compact Framework也不一樣。.NET Compact Framework幫你處理了平台差異性，因此.NET Compact Framework的程式是跨平台的，就像世界語加上翻譯機那樣，基於.NET Compact Framework編寫的代碼可以支援任何平台，前提是微軟為具體平台實現CLR。例如大家都知道Yahoo，其實世界上有一種快要消失的語言就叫做Yahoo，如果你做一個世界語到Yahoo語的翻譯機，那麼你的產品可以不做任何修改就賣到講Yahoo語的地方了。

理論講Native Code vs. Managed Code

Native Code	Managed Code
編譯成平台相關的機器碼	編譯成IL(Intermediate Language)
為各個不同裝置編譯不同版本的執行檔案	一次編譯，各種裝置到處運行
不需要其他架構支援（相對於.NET Compact Framework來說）	需要CLR支援，也就是需要安裝.NET Compact Framework Rumtime
可以最大限度的訪問系統提供的API和服務	只能訪問.NET Compact Framework 提供的服務，例如WIFI和Bluetooth，.NET Compact Framework 的BCL不提供支援，所以如果只是使用.NET Compact Framework 是不能進行WIFI和Bluetooth的開發的。 由於有上述的限制性，所以微軟提供P/Invoke來訪問平台相關的API和COM。
可以使用MFC，ATL，WTL，STL等庫進行開發	可以使用.NET Compact Framework 的BCL進行開發

 

 

如何選擇Native Code和Managed Code

瞭解了Native Code 和 Managed Code的異同，可以根據其特點和相應的需求進行選擇。沒有絕對的好壞，所以才存在兩個平台同時存在的現狀。

 

Native Code開發速度相對慢一些，因為沒有.NET Compact Framework 的Base Class Libraries的支援。BCL為開發人員做了大量的封裝，例如Garbage Collection，Windows form，Web Service等等。基於BCL開發人員可以專註於業務的開發。所以使用.NET Compact Framework一般來說可以節省不少開發時間。時至今日，庫對語言的影響越來越多，如果沒有RoR，Ruby可能還是一個籍籍無名的日本方言。C++之父Bjarne Stroustrup說，C++的擴充更多的在STL的擴充，通過STL來支援新特性，以此C++從文法上一直沒有大變化，但是由於STL的不斷擴充而不斷帶來新的活力。可見庫對一個語言和開發人員的重要性。在這方面.NET Compact Framework 勝出，但是Native C++還是可以通過MFC，ATL，WTL，STL來補救。我本人十分喜歡使用WTL處理介面和大量使用STL，關於WTL，可以參考：

Windows Mobile和Wince(Windows Embedded CE)下的WTL(Windows Template Library)開發

Windows Mobile 和 Wince(Windows Embedded CE) 下的 WTL(Windows Template Library) 介面(UI)開發

Windows Mobile和Wince下使用WTL進行Windows Media Player開發

關於在今日外掛程式使用WTL的問題

 

Windows Mobile下使用Native C++(WTL, MFC, Win32)開發，如何為對話方塊加入菜單

Windows Mobile下如何去掉WTL對話方塊CStdDialogImpl的OK按鈕

在Windows Mobile下使用WTL進行Native C++開發，如何顯示等待表徵圖

在Windows Mobile和Wince(Windows Embedded CE)下進行WTL開發，如何加入超連結(HyperLink)

 

但是Native Code執行速度相對快，因為基於.NET Compact Framework 的代碼有JIT的過程，第一次執行需要把IL編譯到Native機器碼，而Native Code本身就是機器碼，所以Native Code快很多。

 

同時Native Code使用的memory footprint也少很多很多，Native Code使用的footprint只是和你編寫的代碼分配記憶體有關。但是基於.NET Compact Framework 的代碼，儘管一個幾乎沒有任何功能的程式，啟動的時候也需要1到2M的記憶體。這些記憶體用於處理Garbage Collection等用途。

 

Native Code和Managed Code存在一個可控性的gap，.NET Compact Framework 是.NET Framework的精裝版，封裝了一部分.NET Framework的功能，但是不完全包含.NET Framework的所有功能。Native Code具有完全訪問系統API和服務，平台API的能力，而.NET Framework不完全具備，.NET Compact Framework 就更加不具備，所以從系統可操控性來說，Native Code和Managed Code存在一個gap，這個gap是指有些功能Native Code可以做，但是Managed Code卻無法實現的功能，例如WIFI，Bluetooth。要在.NET Compact Framework 實現這些功能必須通過P/Invoke來實現，關於P/Invoke可以參考一下

.NET Compact Framework 下Win32 API P/Invoke 的使用

開發P/Invoke的工具與Website

如何在Windows Mobile下使用Native C++動態載入DLL

Windows Mobile和Wince(Windows Embedded CE)下如何封裝Native DLL提供給.NET Compact Framework進行調用

Windows Mobile和Wince(Windows Embedded CE)下封裝Native DLL進一步探討

在Windows Mobile和Wince(Windows Embedded CE)下封裝Native DLL的回呼函數

由於這個可控性的gap的存在，所以出現了OpenNETCF的Smart Device Framework，32feet.net等庫，這些庫為基於.NET Compact Framework的程式封裝了P/Invoke的調用，這樣減少了gap的存在。32feet.net可以參考  基於32feet.net對Broadcom(Widcomm) stack藍芽(Bluetooth)裝置開發Windows Mobile與PC程式 等系列文章。當然微軟也不斷的在填補這個gap，.NET Compact Framework的不斷升級，這個gap越來越小了，例如.NET Compact Framework 1.0沒有串口操作，但是在.NET Compact Framework 2.0已經加上。可是.NET Compact Framework的rumtime就越來越大，同時啟動也越來越慢，任何都是均衡，行動裝置受到CPU速度和記憶體的限制，.NET Compact Framework 並不是加入越多功能越好。過猶不及，中國人常說的。

Balabala...說那麼多還是沒有說到底如何選擇，其實是trade-off(均衡)，沒有絕對真理，還是根據具體需求，結合上述Native Code和Managed Code的特點來選擇。我自己的經驗，如果速度要求快，記憶體要求少的核心模組都是使用Native C++（一般包括無介面，純資料處理的程式和完全自訂介面的GDI程式），其他模組都用.NET Compact Framework。如果一個模組需要大量使用P/Invoke，也是需要考慮使用Native C++來代替.NET Compact Framework的。目前覺得選擇還是OK的。

 

寫到這裡，希望看官能明白，有疑問請回複交流。下午Christmas party, happy去。