Windows及Mac OS X在操作系統(tǒng)架構(gòu)、開發(fā)環(huán)境、API、圖形環(huán)境等環(huán)節(jié)上的相近處與不同的地方，也簡單提出了跨平臺應(yīng)用程序開發(fā)的兩種策略。事實(shí)上在兩種平臺上開發(fā)所需要了解的概念跟技能沒有太大的不同，兩種平臺在性能上的差異也不大。大體說來，Windows和Mac OS X都是為桌面應(yīng)用環(huán)境、圖形用戶接口(GUI)而設(shè)計(jì)的操作系統(tǒng)。雖然不同平臺細(xì)節(jié)各有特色，但兩者相近的抽象概念，其實(shí)遠(yuǎn)遠(yuǎn)多于相左之處。本文試圖指出方向上明顯的異同所在，而非詳細(xì)列舉各種細(xì)項(xiàng)差別。最后，我也將簡短分享自己在開發(fā)跨平臺軟件時(shí)的一些技巧和心得。

系統(tǒng)架構(gòu)與開發(fā)環(huán)境的差異

用最簡單的話來說，Mac OS X與Windows在架構(gòu)與開發(fā)環(huán)境上最大的不同點(diǎn)在于：OS X是UNIX也不是UNIX；OS X主要開發(fā)工具Xcode使用GCC作為編譯程序，與其他種類的UNIX相同；不過OS X也有獨(dú)樹一格的"bundle"軟件包裝格式這樣的東西，成為它與其他操作系統(tǒng)不同之處。

Windows和OS X都屬于現(xiàn)代的操作系統(tǒng)，所以Windows在操作系統(tǒng)層級所提供的功能──執(zhí)行文件與鏈接庫加載、多任務(wù)與多線程、內(nèi)存管理──在OS X上都找得到對等的API和作法。不過，相較于Windows在微軟獨(dú)力開發(fā)下，架構(gòu)和API都維持著相對的一貫性（另一方面，也背負(fù)著各種歷史遺跡和向下相容的包袱），Mac OS X則是底層源自NeXTSTEP的Mach微核心（現(xiàn)在稱為XNU），而應(yīng)用層（用準(zhǔn)確的UNIX術(shù)語來說叫userland）來自FreeBSD 4。這件事情相當(dāng)重要：OS X透過這樣的架構(gòu)，才擁有和一般Linux/FreeBSD相似的UNIX應(yīng)用環(huán)境。有相當(dāng)多Mac軟件開發(fā)者喜歡在UNIX shell下工作，使用各種UNIX工具。在Windows上，必須加裝Cygwin之類的環(huán)境才能辦到。

Apple幾年前有則廣告是「把其他牌子的UNIX送進(jìn)/dev/null里」（用過UNIX的朋友應(yīng)該不難體會其中的吹噓意涵）。平心而論，OS X受益自UNIX環(huán)境之處不少。尤其，Apple使用了大量的open source工具。舉例來說，Apple不像微軟，沒有自己的C語言編譯工具，Apple用的是UNIX業(yè)界的標(biāo)準(zhǔn)──open source的GCC（其中當(dāng)然有不少OS X的擴(kuò)展功能就是）。雖然Apple有自己的開發(fā)環(huán)境Xcode，但是底層采用GCC這件事對開發(fā)者來說是相當(dāng)重要的。同時(shí)，Apple的C/C++鏈接庫用的也是GCC標(biāo)準(zhǔn)的stdc/stdc++。了解這個(gè)差異，在遇到與Microsoft C/C++ compiler不同的地方時(shí)，就更容易能找到解答的資源（這類型問題往往不限于OS X，其他UNIX平臺也會發(fā)現(xiàn)）。

但是Mac OS X并不完全是UNIX。它的GUI環(huán)境（Aqua）就完全不是一般Linux/FreeBSD所使用的X11。而在UNIX層之下的微核心也和其他UNIX不同。接下來這一點(diǎn)很重要：OS X雖然有和Windows .EXE和.DLL相對應(yīng)的文件（OS X跟其他UNIX一樣，可執(zhí)行文件一般不加擴(kuò)展名，UNIX系的動態(tài)加載鏈接庫則冠以.dylib），但更重要的架構(gòu)差異是bundle。

Bundle概念承襲自NeXTSTEP。簡單來說，就是由操作系統(tǒng)提供一種類似對象封裝的文件包裹。OS X上最常見的bundle要屬.app結(jié)尾的應(yīng)用程序了。雖然.app外觀上是個(gè)文件，在UNIX shell下看就能發(fā)現(xiàn)它其實(shí)是個(gè)目錄，內(nèi)含各種metadata（通常至少會有一個(gè)名為Info.plist的數(shù)據(jù)文件）、可執(zhí)行文件、動態(tài)鏈接模塊、各種資源等。除了.app外，OS X的各種框架檔（以.framework結(jié)尾，是一種同時(shí)包含頭文件及鏈接庫的包裝）、應(yīng)用程序的外掛模塊（通常以.bundle結(jié)尾）等等，都是以bundle形式呈現(xiàn)的。了解這個(gè)差異，才能了解為什么OS X上很少有程序需要額外的安裝程序，也鮮少聽說有所謂的"DLL hell"（因共享鏈接庫版本不兼容造成的困擾）。

項(xiàng)目 Windows Mac OS X

操作系統(tǒng)最近桌面版本 Windows Vista Mac OS X 10.5 Leopard操作系統(tǒng)核心 NT Kernel XNUCLI Shell環(huán)境 CMD.EXE UNIX shell (bash/tcsh/etc., 可使用Terminal.app一類的終端機(jī)軟件進(jìn)入)GUI (Shell) 環(huán)境 Windows Explorer Aqua (Finder)程序二進(jìn)制文件格式 Portable Executable (PE): .EXE, .DLL Mach-O "universal" binary (可執(zhí)行文件通常不帶附加名，DLL結(jié)尾為.dylib)用來辨認(rèn)軟件組件的方式 GUID bundle identifier (Java式的id，例如com.apple.TextEdit)廠商提供或販賣的開發(fā)環(huán)境 Microsoft Visual Studio Xcode可視化的GUI制作工具 Visual Studio內(nèi)建的WinForm designer Interface BuilderC編譯程序 Microsoft C Compiler GCC

表一：Windows與Mac OS X在架構(gòu)上的對照

開發(fā)語言與API；Objecitve-C, Core API, Carbon, Cocoa

如果使用微軟工具來開發(fā)Windows軟件，就一定會碰到Platform SDK，MFC或者.Net平臺，同時(shí)，也相對應(yīng)到C、C++、C#和其他.Net平臺所提供的語言（這種區(qū)分并不是絕對的，僅僅是為了方便接下來的模擬所做的簡化）。在OS X上，Apple則是鼓勵(lì)大家盡量采用Objective-C作為開發(fā)語言，并且熟悉Cocoa。

接下來的問題既尷尬又麻煩。很多人會問：我們是否非學(xué)Objective-C不可？另外一個(gè)常見的問題是：Apple不是也有名叫Carbon的C API嗎？（延伸出來的問題則是：可不可以用C++開發(fā)Mac程序？）。

簡單的答案（同時(shí)一定程度上也代表Apple的態(tài)度）是：要用Objective-C才能完全發(fā)揮OS X圖形應(yīng)用環(huán)境的長處，而Cocoa這個(gè)用Objective-C寫成的API framework就是最佳的施力點(diǎn)。#p#分頁標(biāo)題#e#

復(fù)雜的答案則是這樣：

OS X的本體，也就是所有非UNIX的部份，并不像Windows一開始就（幾乎）全以C寫成的。因此OS X沒有所謂"Win32 API"這么純粹的東西。OS X核心的、非GUI的服務(wù)和鏈接庫，有時(shí)稱為"Core API"。Core API大部分以C寫成，并且多半奠基于CoreFoundation這套鏈接庫之上。CoreFoundation提供了一貫的內(nèi)存管理模式（CFRetain, CFRelease）、基礎(chǔ)的數(shù)據(jù)型別（字符串、數(shù)組、字典）、property list文件管理、文件、網(wǎng)絡(luò)存取等等。CoreFoundation使用上跟Win32 API有點(diǎn)相似，都透過存取handle的方式來達(dá)到某種近似「用C語言操作對象」的效果。但CoreFoundation最大的不同在于它還有reference counting的內(nèi)存管理模式，大幅簡化了內(nèi)存管理的復(fù)雜性。

至于Carbon，嚴(yán)格說來，是Mac OS X在發(fā)行之初，為了維持與Mac OS 9兼容，才提供一套以C寫成的GUI工具集，主要包括所有的GUI組件（Apple 稱為 HIToolbox ，HI 意思是 Human Interface）以及所有OS X之前的API（QuickDraw等等）。隨著OS X 10.5的推出，Apple漸漸舍棄了舊式的API ，鼓勵(lì)大家使用Objective-C寫成的Cocoa來開發(fā)程序。Carbon現(xiàn)在的意義等于就是HIToolbox，也就是OS X GUI 的C API。

但是，Apple在2007年夏天做了重大的宣布；Carbon不會有64-bit的版本。也就是說這一套C API是「沒有未來」的。這意味著所有使用Carbon寫成的軟件──Microsoft Office、Adobe Photoshop都不可能順利過渡到64-bit。至于像QT這一類跨平臺的GUI kit也勢必要順應(yīng)這項(xiàng)改變。

其實(shí)Objective-C并不難學(xué)。由C轉(zhuǎn)換到C++/C#時(shí)需要學(xué)習(xí)很多新觀念、新用語，但Objective-C大體上只是在C語言上加上一層薄薄的、動態(tài)的面向?qū)ο髮印ocoa則是相當(dāng)容易上手的API。透過Cocoa就可以用面向?qū)ο蟮姆绞酱嫒S X八成上的系統(tǒng)服務(wù)（其余兩成可以用C來呼叫）。Objective-C可以跟C完全混用。同時(shí)Apple也提供了所謂的"Objective-C++"，可以在C++程序中呼叫Objective-C程序，或者在Objective-C里撰寫C++程序代碼。Apple自家的瀏覽器Safari就有不少核心的程序代碼（WebKit）使用了Objective-C++來撰寫。

項(xiàng)目 Windows Mac OS X主要開發(fā)語言 C/C++/C#（及其他.Net支持的語言，如C++/CLI） Objective-C/Objective-C++/C/C++操作系統(tǒng)服務(wù) Win32 API 系統(tǒng)服務(wù)多半可從POSIX layer用stdc/stdc++取用系統(tǒng)核心服務(wù) Win32 API CoreFoundation/CoreServices繪圖與GUI Win32 (GDI32, USER32) Quartz (C API)/HIToolBox (Carbon)/AppKit (Cocoa)面向?qū)ο蟮腁PI .NET Framework/MFC Cocoa面向?qū)ο蟮腉UI及繪圖系統(tǒng) WPF/GDI (with MFC) AppKit (Cocoa)以及Cocoa Graphics桌面應(yīng)用程序的數(shù)據(jù)庫方案 ODBC/ADO.Net CoreData基礎(chǔ)繪圖系統(tǒng)使用的單位 Pixel (GDI) Point (Quartz)默認(rèn)的屏幕分辨率 96 DPI 72 DPI

表二：開發(fā)語言與API的對照

圖形作業(yè)環(huán)境的差異：繪圖系統(tǒng)

大家對OS X最主要的印象，想必還是它的圖形作業(yè)環(huán)境。GUI的確是OS X與Windows差異最多的地方。

在Windows環(huán)境里，傳統(tǒng)上Win32 API同時(shí)包括了繪圖（所謂的GDI/GDI+）和GUI組件（窗口、對話盒、按鈕等等）的操作。到了.Net 3.0有所謂的WPF (Windows Presentation Foundation)。嚴(yán)格說來所有Windows上的概念和組件，都可以在OS X上找到相對應(yīng)的作法。但是在架構(gòu)上OS X確實(shí)和Windows有相當(dāng)大的差異。

OS X的繪圖系統(tǒng)核心是Quartz。Quartz的繪圖基礎(chǔ)概念是路徑（path），而不是像素（pixel）。驚人的事實(shí)是：Quartz是一套PDF繪圖系統(tǒng)。所有Quartz能繪制的對象都能輕易轉(zhuǎn)換為PDF文件。至于在圖像處理上，Quartz提供了一套完整的合成模型（compositing model）。簡單地說，Quartz賦予了Mac OS X極為優(yōu)異的繪圖能力。從一些細(xì)節(jié)就可以看出Quartz在視覺上的細(xì)致度：例如，OS X在顯示字型時(shí)的去鋸齒（anti-aliasing）處理就要比Windows來得細(xì)膩，在點(diǎn)陣影像的縮放上效果也往往比Windows好。OS X的應(yīng)用程序可以輕易做出各種透明度的圖層、以及為圖形對象加上陰影、或者繪制不規(guī)則形狀（但這并不代表你應(yīng)該只是為了為了吹噓而濫用這些功能，我們馬上會提到用戶體驗(yàn)這件事）。倒是有個(gè)細(xì)節(jié)應(yīng)該馬上一提，那就是Quartz的默認(rèn)分辨率是72 DPI，所使用的單位是點(diǎn)（point），這跟PDF繪圖系統(tǒng)是一致的，和Windows預(yù)設(shè)為96 DPI、以像素為單位的點(diǎn)陣式繪圖系統(tǒng)很不一樣。這在一開始可能很困擾人。因?yàn)樵贠S X上，不改變屏幕設(shè)定的情況下，12 pt的字，就真的會被會繪制成12 px（而在Windows上，12 pt卻是16 px）。同時(shí)，Quartz默認(rèn)的坐標(biāo)系統(tǒng)跟數(shù)學(xué)上的習(xí)慣相同，也就是(0, 0)坐標(biāo)起點(diǎn)是位于左下方，而不是一般計(jì)算機(jī)繪圖使用的左上方（當(dāng)然，Quartz有各種坐標(biāo)變換功能，因此當(dāng)然還是可以把(0, 0)設(shè)定為左上方的）。

看似復(fù)雜，然而，當(dāng)你開始想輸出PDF（打印作業(yè)大幅簡化）或進(jìn)行精細(xì)的繪圖工作時(shí)，慢慢就會發(fā)現(xiàn)Quartz這樣設(shè)計(jì)的直觀了。

另外，Quartz的基礎(chǔ)API是以C寫成的，所有對象操作方式都跟CoreFoundation一樣（從Quartz建立的對象都是用reference counting的方式在管理內(nèi)存，同時(shí)也都可以用CFRelease來釋放）。不過，Cocoa也提供了絕大多數(shù)的API對應(yīng)。使用Objective-C來操作繪圖對象會更輕松些。

在Quartz之上，或者與Quartz并行的，還有Apple的各種圖形和媒體相關(guān)的子系統(tǒng)。諸如可以快速制作動畫的Quartz Composer、新一代文字輸出編排系統(tǒng)CoreText、應(yīng)用層的2D動畫系統(tǒng)CoreAnimation，以及Apple的招牌多媒體架構(gòu)QuickTime，還有業(yè)界標(biāo)準(zhǔn)的OpenGL，這些構(gòu)成了Mac OS X在視覺及媒體經(jīng)驗(yàn)上的核心。#p#分頁標(biāo)題#e#

圖形作業(yè)環(huán)境的差異：GUI，以及，用戶體驗(yàn)

Windows上，尤其是Win32 API里面，絕大多數(shù)關(guān)于GUI的概念和技能，都可以直接轉(zhuǎn)換到OS X上。OS X的GUI同樣是采用事件驅(qū)動模型（event-driven model）來設(shè)計(jì)的，每個(gè)GUI應(yīng)用程序同樣都有所謂的run loop（或稱event loop/message loop）。兩者甚至在某些系統(tǒng)限制上也雷同：例如，.Net跟Cocoa都不鼓勵(lì)或甚至禁止程序在主線程以外的地方創(chuàng)建或操作GUI對象。

盡管如此，GUI是造就Mac OS X在外觀上與其他平臺不同的最大要素。與之相伴的是OS X對于用戶體驗(yàn)近乎執(zhí)著的追求。

OS X在GUI上并沒有一個(gè)特別的子系統(tǒng)。通常我們用接觸到的API來區(qū)分。好比說如果用的是Carbon我們會稱為HIToolkit，如果用的是Cocoa則會說是AppKit（Cocoa主要是由非GUI的Foundation──不要和CoreFoudation搞混了──以及提供GUI組件的AppKit所組成的）。Apple的開發(fā)工具中并沒有類似Visual Basic一類把接口畫完、在組件上點(diǎn)兩下鼠標(biāo)，把程序填進(jìn)去就完成應(yīng)用程序的工具或流程。最接近的是Interface Builder (IB)這套工具。IB做出來的.nib文件其實(shí)就是封存好的GUI對象，生成之后再回Xcode將必要的連結(jié)關(guān)系拉完，程序代碼填上（通常量不會很多）就完成程序了。IB會是Xcode以外，OS X開發(fā)者最常用的工具。

OS X提供的GUI組件特色為細(xì)膩、一致、直觀。這并不代表OS X的GUI無法做復(fù)雜的設(shè)定和客制化。但是相較之下，OS X的應(yīng)用程序更傾向于善用或組合現(xiàn)有的視覺元素，而較少自創(chuàng)新的custom control。這一點(diǎn)和Windows上，尤其是小型工具程序，喜歡一種程序就創(chuàng)造一種視覺風(fēng)格，或是大量提供使用者可更換的skin，有著相當(dāng)大的文化差異。雖然Apple自家的軟件跟微軟相似，喜歡提前使用下一個(gè)版本才出現(xiàn)的視覺風(fēng)格或元素，有時(shí)讓開發(fā)者覺得難以捉摸，但大體上遵守Apple自家的HIG (Human Interface Guideline)還是常態(tài)。

我們提到了文化差異；OS X在視覺上的細(xì)膩，以及對用戶體驗(yàn)的追求，造就了一種高要求的文化。這可以說是一種正向循環(huán)。我們或許很少聽說哪個(gè)Windows開發(fā)者會為了icon向左偏了1 pixel而大改特改，或是要求自己的軟件要在視覺及操作上符合哪個(gè)規(guī)范的一致性。但OS X的開發(fā)者真的會談?wù)摬?yán)肅看待這件事情（著名的icon設(shè)計(jì)商IconFactory以及獨(dú)立軟件商Panic是著名的兩個(gè)代表），同樣的也有相當(dāng)多OS X使用者以同樣嚴(yán)苛的標(biāo)準(zhǔn)看待他們使用的軟件，甚至可能寫信告訴你，指出你的軟件在用戶體驗(yàn)或視覺設(shè)計(jì)上的缺陷（筆者就曾經(jīng)收到使用者來信，指出筆者的一個(gè)軟件在pull-down menu中使用的icon「語意」不合乎用戶對該種GUI組件的期待）。又好比說，從OS X 10.5 Leopard開始，icon最大可以大到512x512，Apple也強(qiáng)烈建議開發(fā)者要準(zhǔn)備這么大的尺寸（除了原有的16x16、32x32、128x128之外）。這當(dāng)然無形中提高了開發(fā)的挑戰(zhàn)。Windows在XP以前僅支持16x16、32x32、48x48，直到Vista才開始加大到64x64和256x256。

另一個(gè)與GUI不直接相關(guān)，但卻影響用戶體驗(yàn)的，是OS X的本地化（localization）系統(tǒng)。這一點(diǎn)也是和Windows不同的地方。OS X因?yàn)橛衎undle的設(shè)計(jì)，因此能讓一個(gè)應(yīng)用程序同時(shí)包裝各種不同語系的資源文件，同時(shí)開發(fā)多語系程序在OS X上也相對容易（通常是以提供各種不同版本的.nib bundle放進(jìn)應(yīng)用程序bundle中Content/Resources/底下以語系區(qū)域來區(qū)分的子目錄中就完成了。Windows程序設(shè)計(jì)一向以"resource file"概念來管理icon及本地化等「外部」資源，名稱相似，開發(fā)方式卻不那么一貫而直觀；另外，OS X的語系是可以按照順序fallback的，例如要是繁體中文語系檔找不到，而用戶在語言設(shè)定中將簡體中文設(shè)定在繁體中文的后頭，那么OS X便會嘗試套用簡體中文語系檔），結(jié)果是OS X使用者對本地化同樣有著高標(biāo)準(zhǔn)與高期待。另一方面，筆者也建議大家，除非軟件確定只有中文用戶使用，不然一開始先以英文界面開發(fā)，再加上中文的本地化資源，以長期來說是值得（甚至是必要）的投資。

一些較難歸類但同樣重要的差別

Mac OS X跟Windows在軟件開發(fā)作法上的差異還有很多，上述只就最大的方向差異闡釋。有些較細(xì)微但值得一提的差別，我們也在這里簡單說明。

首先，OS X跟Windows一樣，內(nèi)部字符串編碼以Unicode為準(zhǔn)。但在操作系統(tǒng)不同的層級，使用方式并不相同。Windows的Unicode layer很一致地使用了UTF-16作為編碼，并偏好使用BOM輔助判別。OS X的文件系統(tǒng)使用UTF-8，而CoreFoundation及Cocoa則用UTF-16。如果使用Cocoa自己的serialization機(jī)制，Cocoa會正確儲存和還原UTF-16的位順序。不過，筆者自己建議，盡可能使用UTF-8作為各種交換時(shí)的編碼（相對于Windows對于UTF-8的支持不夠干脆簡明，Cocoa自己就提供了像stringWithUTF8String以及UTF8String兩種NSString的method，方便在native string與UTF-8間的游走）。

其次，相對于Windows使用registry來管理應(yīng)用程序設(shè)定，Mac OS X使用的是一種叫做property list（文件擴(kuò)展名為.plist，簡稱plist）的XML文件。Plist可以直接變成CoreFoundation及Cocoa的各種容器對象，也可以將后者輕易地serialize成plist。因此OS X上的應(yīng)用程序大量使用plist作為配置文件的格式，甚至作為數(shù)據(jù)單元格式。將設(shè)定用個(gè)別文件儲存也減少了Windows集中管理registry所帶來的各種弊病。

Mac OS X并不使用COM (Component Object Model)來作為面向?qū)ο蟮倪M(jìn)程間通信(IPC; interprocess communication)的機(jī)制。因?yàn)橛肅ocoa寫成的程序，可以透過Objective-C Distributed Object (DO)這個(gè)強(qiáng)大機(jī)制來達(dá)成IPC的任務(wù)。除此之外，因?yàn)閎undle架構(gòu)，OS X軟件要設(shè)計(jì)外掛模塊架構(gòu)也相當(dāng)容易。OS X有相當(dāng)多支持外掛的應(yīng)用程序，應(yīng)歸功于這種開發(fā)上的便利度。

OS X應(yīng)用程序能夠利用所有OS X在UNIX環(huán)境上所提供的功能。同時(shí)OS X一安裝好就已經(jīng)幫你準(zhǔn)備好了大量的open source鏈接庫，例如可用來制作密碼密鑰認(rèn)證的OpenSSL、負(fù)責(zé)解壓縮的libz、內(nèi)嵌式數(shù)據(jù)庫引擎SQLite等等。這些都是加速開發(fā)的好幫手。#p#分頁標(biāo)題#e#

最后要提的是，正因?yàn)镺S X的文化與Windows有許多不同處，筆者建議跨足OS X的開發(fā)者應(yīng)該要盡可能貼近甚至配合OS X的習(xí)慣。舉例來說，大多數(shù)OS X應(yīng)用程序都不需要安裝程序，只需要直接將軟件拷貝到想要存放的目錄（通常是/Applications）即可。而解安裝也就直接刪除該.app bundle就解決了。在Windows上就沒那么容易了（特別是有相當(dāng)多組件依存關(guān)系的軟件）。這些都是開發(fā)上需要注意的地方，但是開發(fā)者多付出一份心力，使用者就會多一份便利，終究會得到用戶肯定的。

項(xiàng)目; Windows; Mac OS X 系統(tǒng)內(nèi)部編碼 Unicode (UTF-16) Unicode (文件系統(tǒng)使用 UTF-8, 系統(tǒng)API一般使用 CFString/NSString, 內(nèi)部使用UTF-16)語系處理 區(qū)分Codepage 不區(qū)分Codepage應(yīng)用程序的設(shè)定管理方式 Windows registry Property list filesIPC的幾種方式 COM/Windows RPC Objective-C Distributed Object/Apple Event/BSD Socket腳本語言的支持 VBScript/JScript/CScript/DOS Batch script AppleScript/Perl/Ruby/Python/shell script

表三：一些重要的系統(tǒng)特性（摘錄）

項(xiàng)目 Windows (.NET) Mac OS X (Cocoa)字符串處理 System.String NSString 數(shù)據(jù)結(jié)構(gòu)與容器 System.Collections NSArray/NSDictionary/etc. HTTP網(wǎng)絡(luò)存取 System.Net System.Net,NSURLConnectionXML解譯 System.XML NSXMLDocument etc.

表四：幾個(gè)代表性的.NET namespace/class在Cocoa中的對應(yīng)class

跨平臺的建議

最后簡短分享一些跨平臺軟件開發(fā)所可能遇到的問題。

要同時(shí)在Windows和Mac上開發(fā)，有兩種可能的思維方式。一種是追求真正的"write once, run everywhere"。此時(shí)開發(fā)的選擇，可能是采用Java平臺，Adobe的AIR，抑或使用C++搭配像QT這樣的跨平臺鏈接庫。這三種主流方案各有千秋，但在視覺和用戶體驗(yàn)上往往皆無法與原生（native）的Mac應(yīng)用程序相比。

因此，另一個(gè)方向則是體認(rèn)到，要保有Windows及Mac各自平臺的特長，就必須割舍GUI跨平臺的可能性。也就是說，GUI是最無法移植到其他平臺的部分。我們能做的是將共通的邏輯部分獨(dú)立出來，然后開發(fā)兩套前端接口（frontend）。若以在Windows及Mac上皆能使用為前提，共通邏輯開發(fā)語言的選擇就很少了，不是C就是C++。所幸Windows和Mac上具有平臺特色的語言，要和C++結(jié)合，也不是那么困難的事（在.Net上是透過C++/CLI，在Mac上是透過Objective-C++這兩種擴(kuò)展的語言）。

不過，在開發(fā)共享部分的時(shí)候，最容易碰到的問題，恐怕還是要如何省下力氣去做例如解譯XML文件、存取網(wǎng)絡(luò)這一類不是GUI的工作。這類工作的麻煩在于，Windows和Mac都各自提供了相當(dāng)便利、但也絕對和平臺相依的鏈接庫（例如.Net的System.Xml，Cocoa的NSXMLDocument）。在這種情況下，我們也大體有兩種選擇：不是全部采用跨平臺的鏈接庫（例如使用expat來解譯XML），就是善用面向?qū)ο蟮某橄蠡约癆bstract Factory這樣的設(shè)計(jì)模式（design pattern），讓程序邏輯呼叫抽象的接口，然后在于各自平臺的版本中藉由呼叫平臺相依的API來實(shí)現(xiàn)這些對象。

結(jié)論

本文簡要地討論了Windows及Mac OS X在操作系統(tǒng)架構(gòu)、開發(fā)環(huán)境、API、圖形環(huán)境等環(huán)節(jié)上的相近處與不同的地方，也簡單提出了跨平臺應(yīng)用程序開發(fā)的兩種策略。事實(shí)上在兩種平臺上開發(fā)所需要了解的概念跟技能沒有太大的不同，兩種平臺在性能上的差異也不大，但是在實(shí)現(xiàn)細(xì)節(jié)、視覺表現(xiàn)與用戶體驗(yàn)上，OS X有自身獨(dú)特的風(fēng)格與文化。OS X軟件開發(fā)社群常常說要"be a good Mac citizen"意思也就在此。了解這些差異和獨(dú)特性是撰寫合宜的OS X軟件的第一步。