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

作者: Jake Lin  來源: 博客園  發布時間: 2009-12-16 10:44  閱讀: 2432 次  推薦: 1   原文鏈接   [收藏]  

緣由

經常聽到一些剛剛接觸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, ARMSuperH。由于各個平臺之間的指令集不一樣,所以可執行文件不能互相支持其他平臺。使用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。由于有了這一個過程,所以所有托管代碼都依賴于CLR,因此,需要運行托管代碼的設備必須安裝 .NET Compact Framework。

Native-Managed-01

圖來自于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 Framework32feet.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去。

1
0
 
 
 

文章列表

arrow
arrow
    全站熱搜
    創作者介紹
    創作者 大師兄 的頭像
    大師兄

    IT工程師數位筆記本

    大師兄 發表在 痞客邦 留言(0) 人氣()