基本介紹
- 中文名：跨平台技術
- 套用：跨套用伺服器跨資料庫跨作業系統
- 特點：一般的計算語言都可做到跨平台
- 屬於：軟體開發
廣義面言,跨平台概念,跨平台 語言,跨平台套用,
廣義面言
一般的計算語言都可做到跨平台，開發商只需要提供各種平台下的Runtime/中間件環境即可。嚴格而言是指用某種計算機語言編制的程式只需要做小量的修改，編譯之後即可在另外一種平台下運行，此時並不提供Runtime/中間件環境。例如Java是一種提供Runtime環境的跨平台解決方案，而C只是一種標準且嚴格的跨平台語言。
跨平台概念
是軟體開發中一個重要的概念，即不依賴於作業系統，也不信賴硬體環境。一個作業系統下開發的套用，放到另一個作業系統下依然可以運行。相對而言如果某種計算機語言不用修改代碼即可做到高度跨平台，那么此語言就越抽象，硬體控制力就越低，只適合開發高度抽象的模型系統。諸如java,delphi和易語言，都已做到了跨平台。它們將可以在多種系統下開發，運行和維護。
跨平台 語言
大部分電腦語言從絕對意義而言
都是跨平台的：因為都是以高級的、人類可讀的方式來對CPU發號指令，這樣也就沒必要依賴於任何作業系統。但如果要用系統的部件工具箱，來新建用戶圖形界面（GUI），就可能會用到開發員特定系統中的API函式或庫類。雖然C++是跨平台的，但Windows下用到Win32 API的C++程式，一般就不能在Unix機器上編譯。不同編譯器對語言規範的解釋也有所差異。這樣的話，在針對不同系統進行構建之前，程式就得加以考慮。
一些如Java這樣的語言，從一開始就意識到要在各個平台下運行，所以跨平台在其平台的本地語言環境中已經實現。例如，Java可以跨平台使用，正是由於Swing庫在許多平台下的實現。類似的，能進行跨平台的檔案存取，是因為有各自平台下檔案存取的庫（實際上java裡面的部分東西在windows平台下編寫好後，移植到Linux平台下是會出現少許問題的，問題比較小並且不多，我們還是可以理解為sun公司所說的跨平台的）。以此類推，各種跨平台問題，都需要各自的本地庫來解決。wxWidgets框架就是這樣的一個跨平台庫，根據不同的跨平台問題，提供了許多不同的解決方案；類似的庫有許多，可以根據不同語言的跨平台開發，而採用相應的庫。
針對每種作業系統、CPU，而提供並測試各自的編譯版本，這種做法的可行性很小；開源軟體則允許用戶自己來編譯目的碼（object code），這樣在跨平台方面更好一些。類似的，那些解釋型語言，或者需要虛擬機的語言，也更加符合跨平台的要求，因為用戶也要自己進行編譯。Sun公司的Java虛擬機Hotspot，只針對幾種而不是全部平台，提供編譯好的二進位檔案。例如，Sun對於GNU/Linux，只支持i386平台，但如果誰在PowerPC或者SPARC電腦上運行Linux，就只好自己編譯本地的機器碼（machinecode），或者使用第三方軟體，才能運行Java程式。
許多API（應用程式介面）依賴於平台。OpenGL可以看作是跨平台的，因為其不依賴於任何特定的作業系統、CPU構架或者某個牌子的圖形設備。特定平台的API可以在其他系統上作為兼容層而新建，例如WINE的庫，Windows程式就可以在UNIX系統上運行。
另外許多程式語言還有跨平台的擴展以及中間件，這樣程式設計師對於同樣的原始碼，只要進行一點小修改，就可以在不同平台下編譯/運行，例如Qt和wxWidgets。
跨平台套用
跨套用伺服器
這一點，看起來好像有些多餘，java的口號之一不就是“一次編譯，到處運行”嘛，可實際經驗告訴我們，這僅僅是一個口號而已。實際中是“一次編譯，到處調試”。為什麼會這樣？從套用伺服器來說，各個產品或多或少都在標準的java規範之上進行了一些拓展，小規模的套用開發，多以tomcat為基準；大規模的套用，多以weblogic/websphere為基準。
那么開發完成的套用，可否在所有的套用伺服器上正常部署呢？答案是否定的。在tomcat5上部署沒問題，在tomcat4上卻可能有問題；在tomcat5/4上沒問題，卻可能在resin/jetty/weblogic/websphere上有問題。在我的經歷中，在resin/jetty/weblogic為基準進行開發的套用，部署到tomcat上基本上沒什麼問題。但是以tomcat為基準的套用，部署到其他套用伺服器中，卻可能出現各種各樣的問題。這與tomcat本身的定位和開發方式有關，它更像是一個學術產品，而不是一個商業產品。
小型的套用，我偏好resin，它的速度、穩定性、兼容性、中文處理，都是非常不錯的。相比而言，以“純java、快速”著稱的jetty，就不太令人滿意。jetty的4/5/6各個版本中，對session的存放位置、web.xml的標準、struts的plugin的支持、log4j的處理，都各不相同。在最新的jetty6中，竟然會要命地“不能使用session.validate()”方法，一使用此方法之後，就無法再使用set/getAttribute了。
也曾經在將一個套用轉移到websphere5上時，費勁周折。這個套用跑在其他套用伺服器上都沒問題，但是一部署到ws5上，就無法正常載入struts的配置檔案。本以為是struts配置檔案寫得有問題，但即便把所有的action/form配置均去掉，只保留一個空的配置檔案，也無法正常啟動。最後實在無法，只能亂碰運氣，考慮是否是struts的幾個jar包版本有問題，經檢查，發現套用中使用的是struts1.2的jar包，換成struts1.1的jar包，再啟動後就一切正常。這樣的問題，可真的是折磨人呢。
所以，我認為跨套用伺服器是很重要的。你不能告訴客戶，俺們的系統只能跑在tomcat下面，至於您花重金購買的weblogic/websphere，對不起，我們暫時還不支持。客戶會吐血的。
跨資料庫
經常看到某大公司產品，要求必須使用oracle或者sqlserver資料庫，你想換個資料庫來部署？沒門，人家說了，我們的產品只支持這一種資料庫，你就老實的用吧。但對於客戶方來說，為了減少投資，並且保證內部系統儘可能使用同一種資料庫以減少維護成本（總不能請一個oracle DBA，再請一個sqlserver DBA吧？），總會希望新系統使用的資料庫是以前用過的吧。
有了hibernate，在此基礎上開發的套用，基本上是能滿足跨資料庫要求的，個人認為這是hibernate最大的亮點。但也要注意，在開發中儘可能考慮到不同資料庫的特性。諸如sqlserver的text/image欄位上不能查distinct，oracle內的各種對象名稱長度不得超過30等，儘量不要調用資料庫的內部特性（如存儲過程、視圖等）
