移動(dòng)端與服務(wù)器交互方案

1、移動(dòng)端與服務(wù)端交互內(nèi)容簡(jiǎn)介本文主要從架構(gòu)上進(jìn)行闡述，講解移動(dòng)端的開(kāi)發(fā)的兩種技術(shù)路線，以及移動(dòng)端如何與服務(wù)端進(jìn)行交互。移動(dòng)端開(kāi)發(fā)移動(dòng)端的開(kāi)發(fā)主要有兩種方式，第一種是基于手機(jī)的API開(kāi)發(fā)方式，第二種是基于手機(jī)端的瀏覽器開(kāi)發(fā)方式。首先介紹這兩種開(kāi)發(fā)的方式以及優(yōu)缺點(diǎn)。1、 基于手機(jī)API開(kāi)發(fā)原理：手機(jī)端使用手機(jī)API，如AndroidAPI，進(jìn)行開(kāi)發(fā)，服務(wù)端只是一個(gè)數(shù)據(jù)提供者，如JSON。手機(jī)端接到JSON后將JSON反序列化成對(duì)象，進(jìn)行邏輯處理，再在界面層進(jìn)行展示。當(dāng)然你也可以不用JSON，用XML、甚至你自己能讀懂的某種字符串如commaString（逗號(hào)分割的字符串），雖然這一切都沒(méi)有JSON在

2、JAVA中來(lái)的方便，本文就將使用JSON。這種方式，相當(dāng)于傳統(tǒng)開(kāi)發(fā)中的C/S模式。優(yōu)缺點(diǎn)：這種方式的優(yōu)點(diǎn)在于，手機(jī)端開(kāi)發(fā)更為靈活，可以應(yīng)用手機(jī)API提供的所有API，可以對(duì)手機(jī)進(jìn)行底層的控制，如：可以使用系統(tǒng)提供的更炫的UI、很方便的使用攝像頭、播放視頻、撥打電話、調(diào)用聯(lián)系人、發(fā)送短信（雖然后三者在android平臺(tái)用瀏覽器的方式也可以比較方便的實(shí)現(xiàn)，但這里講的是針對(duì)全平臺(tái)的思路）這種方式的缺點(diǎn)也顯而易見(jiàn)，手機(jī)端開(kāi)發(fā)周期長(zhǎng)、可移植性差、無(wú)法跨平臺(tái)，即使你之前已經(jīng)有了很強(qiáng)大的WEB應(yīng)用，針對(duì)手機(jī)客戶端這部分WEB端也可能要重新開(kāi)發(fā)。 服務(wù)器角色：在這種方式中，服務(wù)器所扮演的是數(shù)據(jù)提供者的角色，它

3、處理手機(jī)客戶端的請(qǐng)求，并將請(qǐng)求通過(guò)業(yè)務(wù)邏輯層的處理生成客戶端要求的JSON回發(fā)到客戶端，于是：視圖層僅僅是顯示JSON而已，沒(méi)有Jquery、沒(méi)有Ajax、甚至沒(méi)有HTML。其實(shí)這種方式就是開(kāi)發(fā)傳統(tǒng)意義上的APK，相當(dāng)于一個(gè)c/s開(kāi)戶端。2、 基于手機(jī)瀏覽器的開(kāi)發(fā)原理：遵循Webkit的標(biāo)準(zhǔn)為手機(jī)客戶端開(kāi)發(fā)跨平臺(tái)的網(wǎng)站應(yīng)用，這時(shí)手機(jī)端僅僅是一個(gè)包了瀏覽器外殼的簡(jiǎn)單程序，這個(gè)外殼通過(guò)訪問(wèn)Web服務(wù)器，獲得HTML流，并將HTML用支持WebKit的瀏覽器控件解析（如Android的WebView），從而實(shí)現(xiàn)界面的展現(xiàn)。另外在Android中，還可以“重載”JavaScript方法，獲得更接近An

4、droid原生程序的用戶體驗(yàn)，如將JS中的alert”轉(zhuǎn)換”成Android的AlertDailog，再比如解析鏈接中的tel: ”調(diào)用撥號(hào)界面，等等。但互動(dòng)效果依然有限。這種方法相當(dāng)于傳統(tǒng)開(kāi)發(fā)中的B/S模式。優(yōu)缺點(diǎn)：WebKit方式的優(yōu)缺點(diǎn)與API方式更好相反，廣義的講，WebKit無(wú)法提供手機(jī)原生UI、對(duì)手機(jī)硬件的控制能力有限，導(dǎo)致程序交互性較差；由于視圖層依賴于Web服務(wù)端，所以程序會(huì)更加依賴網(wǎng)絡(luò)，可能更加耗費(fèi)流量；但WebKit方式的優(yōu)點(diǎn)同樣令人著迷：跨平臺(tái)、手機(jī)端開(kāi)發(fā)周期很短、如果你已經(jīng)有了很強(qiáng)大的WEB應(yīng)用，開(kāi)發(fā)WebKit或許就僅僅是做一個(gè)新的視圖層那么簡(jiǎn)單。對(duì)于最后一點(diǎn)，也許我

5、該多說(shuō)幾句。對(duì)于JSON方式，由于要使用JSON輸出，你就要重新構(gòu)造一個(gè)各種類轉(zhuǎn)換成必要JSON的邏輯，比如我要在手機(jī)客戶端中顯示一個(gè)用戶的若干信息，我需要讓服務(wù)器傳一個(gè)User Json給客戶端，那這個(gè)JSON就要在服務(wù)器重新構(gòu)造，那怎么構(gòu)造呢？BLL要改、DAL同樣要改，這個(gè)不是個(gè)簡(jiǎn)單的事情！當(dāng)然，你也可以增加一個(gè)序列化對(duì)象為JSON的通用靜態(tài)方法，但這樣的方式往往并不是萬(wàn)能。首先通用靜態(tài)方法只能處理簡(jiǎn)單的對(duì)象，當(dāng)一個(gè)對(duì)象中包含另一個(gè)需要被序列化的對(duì)象，那通用方法則未必成功；又比如，你需要一些轉(zhuǎn)換，比方說(shuō)username屬性，輸出時(shí)改名為uid（為了給客戶端節(jié)約點(diǎn)流量嘛），那還是需要為每一

6、個(gè)類增加對(duì)應(yīng)的序列化方法，還是要在BLL、DAL動(dòng)手腳，延長(zhǎng)開(kāi)發(fā)周期。服務(wù)器角色：WebKit方式的服務(wù)器角色，就不僅僅是數(shù)據(jù)提供者那么簡(jiǎn)單，還需要提供完整的HTML視圖，似乎看來(lái)，相比第一種方式，是加了視圖層，但是從某種角度說(shuō)，添加視圖卻正好實(shí)現(xiàn)了對(duì)之前業(yè)務(wù)邏輯的復(fù)用，開(kāi)發(fā)反而更為簡(jiǎn)單?？偨Y(jié)：1、從界面效果用戶體驗(yàn)角度來(lái)看，肯定是基于手機(jī)的API開(kāi)發(fā)肯定要好。2、從項(xiàng)目開(kāi)發(fā)速度角度來(lái)看，基于手機(jī)瀏覽器的開(kāi)發(fā)要快，直接用開(kāi)發(fā)即可，移動(dòng)端只要開(kāi)發(fā)一個(gè)版本即可?；谑謾C(jī)的API開(kāi)發(fā)，安卓和蘋(píng)果需開(kāi)發(fā)兩個(gè)不同的版本。3、從人力資源角度來(lái)看，基于手機(jī)的API開(kāi)發(fā)需要多名精通安卓和蘋(píng)果的開(kāi)發(fā)人員。綜合考慮，可以采用兩種結(jié)合的方式。對(duì)于界面效果用戶體驗(yàn)要求比較高的模塊可以采用基于手機(jī)API的開(kāi)發(fā)方式，對(duì)于用戶的訂單管理、基本信息管理模塊可以采用基于手機(jī)瀏覽器的開(kāi)發(fā)方式。我的上家公司就是采用這種開(kāi)發(fā)方式。服務(wù)端與客戶端交互1、服務(wù)端建議采用三層架構(gòu)，再增加一個(gè)WebService層。2、客戶端與服務(wù)器交互，分兩種情況。第一種基于手機(jī)API開(kāi)發(fā)，交互過(guò)程如下：客戶端通過(guò)http協(xié)議訪問(wèn)服務(wù)器的一個(gè)頁(yè)面，http:/localhost:8080/api/Login.aspx?name=111服務(wù)器經(jīng)過(guò)處理后，把這個(gè)頁(yè)面生成為僅有json數(shù)據(jù)的文本流客戶端得到J