QQ郵箱iPhone版開(kāi)發(fā)了幾個(gè)月，多次延遲發(fā)布，過(guò)程十分艱辛。這是第一次嘗試混搭的開(kāi)發(fā)方式，即整個(gè)應(yīng)用主要由web組成，APP給web套上一個(gè)殼并提供一些原生的接口，以達(dá)到更好的體驗(yàn)。我們使用了開(kāi)源的PhoneGap框架，但其實(shí)到后來(lái)已經(jīng)可以拋棄它了，沒(méi)用它多少接口，自己實(shí)現(xiàn)一下也只是時(shí)間的問(wèn)題。

總體

整個(gè)APP主要是以下三點(diǎn)：

1. APP由js驅(qū)動(dòng)，與手機(jī)郵箱觸屏版/ipad版使用同一套邏輯，同樣的M層，架構(gòu)一致。
2. 由APP客戶端提供繪制頭尾以及動(dòng)畫(huà)切換的接口，由js調(diào)用。
3. 使用HTML5的sqlite/localstorage緩存數(shù)據(jù)，applicationCache緩存靜態(tài)文件和頁(yè)面。

加上各種細(xì)節(jié)，就可以構(gòu)建一個(gè)仿原生應(yīng)用了。

問(wèn)題

實(shí)際上說(shuō)得簡(jiǎn)單，做起來(lái)難，碰到很多問(wèn)題。

性能

DOM的性能差，渲染速度慢，最初在各個(gè)模塊之間切換時(shí)速度不能忍受，經(jīng)過(guò)各種優(yōu)化后情況才好轉(zhuǎn)。優(yōu)化包括：去除所有高級(jí)CSS特性，例如陰影漸變等，減少list默認(rèn)顯示條數(shù)，緩存DOM，APP頭尾控件緩存，APP動(dòng)畫(huà)拍照優(yōu)化。即使經(jīng)過(guò)很多優(yōu)化，目前性能上還是跟原生APP有所差距。這種差距目前來(lái)看只能等待硬件升級(jí)。其實(shí)在未做任何優(yōu)化前，在mac的模擬器上體驗(yàn)已經(jīng)很好了，無(wú)性能問(wèn)題，因?yàn)閙ac的硬件夠好。

manifest

applicationCache的manifest是個(gè)令人頭痛的東西，項(xiàng)目過(guò)程中幾度出問(wèn)題。它最大的不足在于不能清空緩存，一旦使用了它，將很難拋棄它，只能更新，不能拋棄。造成的問(wèn)題是，manifest更新時(shí)，拉取新的資源文件，一旦主頁(yè)面在后臺(tái)輸出的是個(gè)不正確的頁(yè)面，被緩存起來(lái)了，就萬(wàn)劫不復(fù)，再也無(wú)法進(jìn)入應(yīng)用了，因?yàn)闆](méi)有機(jī)會(huì)再次取拉正確的頁(yè)面了。所以要使用它，需要強(qiáng)力保證主頁(yè)面絕不會(huì)輸出錯(cuò)誤，最好是個(gè)靜態(tài)頁(yè)面。

此外用manifest還要非常細(xì)心。項(xiàng)目過(guò)程中有兩次出現(xiàn)突然無(wú)法離線的情況。一次是manifest針對(duì)高清屏輸出的文件有個(gè)地方?jīng)]換行，導(dǎo)致緩存無(wú)效。很難看出它沒(méi)換行，因?yàn)閙anifest文件是套模板的，模板上是有換行的，轉(zhuǎn)完輸出就沒(méi)有了。只針對(duì)高清屏錯(cuò)誤就導(dǎo)致模擬器和iphone3都沒(méi)問(wèn)題，只有iphone4有問(wèn)題。折騰這個(gè)詭異的問(wèn)題半天。另一次是寫(xiě)在APP里的啟動(dòng)網(wǎng)址參數(shù)里多了個(gè)’s’，導(dǎo)致打開(kāi)的頁(yè)面跟緩存的頁(yè)面不一致，很難發(fā)現(xiàn)，也查了挺久。

JS-APP不同步

APP提供了繪制頭部底部的接口，何時(shí)繪制以及繪制什么由JS控制。模塊的切換會(huì)有動(dòng)畫(huà)效果，在js調(diào)用模塊切換時(shí)，先拍照，再畫(huà)頭畫(huà)底，再回調(diào)開(kāi)始動(dòng)畫(huà)的事件，JS渲染自身的dom，動(dòng)畫(huà)切過(guò)去，整個(gè)流程挺簡(jiǎn)單挺清晰，但實(shí)際會(huì)有各種問(wèn)題出現(xiàn)。

在初期經(jīng)常出現(xiàn)APP頭尾和模塊內(nèi)容不一致的問(wèn)題，由各種原因?qū)е?，可能在切換模塊整個(gè)流程沒(méi)結(jié)束時(shí)馬上又切換模塊了，或者再調(diào)一次畫(huà)頭尾，會(huì)打亂流程。這通過(guò)APP那邊把命令加入一個(gè)隊(duì)列順序執(zhí)行，并且在動(dòng)畫(huà)過(guò)程不響應(yīng)事件來(lái)解決。

登錄問(wèn)題

由于歷史問(wèn)題，登錄沒(méi)有使用ajax，整個(gè)應(yīng)用不可避免地需要頁(yè)面跳轉(zhuǎn)，這會(huì)導(dǎo)致非常多的問(wèn)題：
1.在某些網(wǎng)速非常慢的情況下，整個(gè)應(yīng)用白屏無(wú)法避免，因?yàn)樵谔D(zhuǎn)了頁(yè)面并且頁(yè)面還未載入時(shí)，必然會(huì)先出現(xiàn)一個(gè)空白頁(yè)面。
2.登錄的loading菊花卡住不轉(zhuǎn)，因?yàn)樘D(zhuǎn)了頁(yè)面本頁(yè)面的無(wú)論是gif還是canvas都停止運(yùn)行了。
3.一旦出現(xiàn)運(yùn)營(yíng)商劫持/wifi驗(yàn)證頁(yè)面，整個(gè)應(yīng)用就會(huì)調(diào)轉(zhuǎn)到這個(gè)頁(yè)面去，完蛋了。這個(gè)后來(lái)通過(guò)把表單提交到iframe解決。
所以，最好不要出現(xiàn)跳轉(zhuǎn)頁(yè)面的情況，必須整個(gè)應(yīng)用在一個(gè)頁(yè)面里。

溝通成本

本來(lái)一個(gè)iPhone APP的開(kāi)發(fā)鏈就是，UI-客戶端-后臺(tái)，加入js后，多了js與客戶端溝通的成本。而在這種開(kāi)發(fā)模式不成熟的時(shí)候，這個(gè)溝通成本挺大。另外在APP出問(wèn)題的時(shí)候，有時(shí)挺難判斷是js的問(wèn)題還是客戶端的問(wèn)題。

由于APP介入了表現(xiàn)層，進(jìn)入JS的邏輯，所以必須對(duì)APP和JS兩端都熟悉了解，才能掌握整個(gè)流程。之前不清楚為什么phoneGap不推出這個(gè)固定畫(huà)頭畫(huà)底的接口，這是所有APP必備而在web上實(shí)現(xiàn)性能又很差的東西?，F(xiàn)在知道這會(huì)使APP變復(fù)雜，phoneGap只提供功能接口，作為后臺(tái)角色，其他全交給JS，不需要與APP進(jìn)行過(guò)多的溝通。

webView/網(wǎng)絡(luò)

出現(xiàn)了一些問(wèn)題我們還沒(méi)弄清除是不是webView的問(wèn)題，例如，記住cookie的問(wèn)題，登陸過(guò)后是設(shè)了cookie的，但如果這時(shí)馬上退出，下次進(jìn)來(lái)就不會(huì)有cookie，如果是隔個(gè)二三十秒過(guò)后再退出，cookie就能記住。非常奇怪的行為，對(duì)此我們只能打個(gè)補(bǔ)丁，把某些cookie存到localstorage，下次進(jìn)來(lái)如果沒(méi)有cookie就從localstorage里取，這個(gè)方案還依賴了mainifest。

另一個(gè)是APP環(huán)境改變時(shí)ajax的行為問(wèn)題，在請(qǐng)求或者上傳時(shí)，APP切換到后臺(tái)，APP切換網(wǎng)絡(luò)，APP切換到后臺(tái)長(zhǎng)時(shí)間不用再打開(kāi)，APP終止webView的請(qǐng)求，都會(huì)由可能導(dǎo)致ajax卡死，無(wú)onsuccess或onerror的callback，有時(shí)還會(huì)導(dǎo)致JS被阻塞，接下來(lái)無(wú)法正常響應(yīng)請(qǐng)求。這是我們框架的緣故，還是webView的緣故，還待查。

好處

與純?cè)鶤PP比，它是有帶來(lái)一些好處的。

1. 云端升級(jí)：應(yīng)用的某些升級(jí)無(wú)需通過(guò)AppStore，無(wú)需用戶下載安裝，可以快速迭代。
2. 代碼復(fù)用：觸屏版/ipad版的多數(shù)代碼可以復(fù)用或者共用，降低開(kāi)發(fā)成本，提高開(kāi)發(fā)速度。
3. 跨平臺(tái)：我們暫時(shí)沒(méi)用到這個(gè)好處。若要跨平臺(tái)，數(shù)據(jù)層沒(méi)問(wèn)題，VC層還是有很多的不同。

總結(jié)

混搭的開(kāi)發(fā)方式，APP最好不要參與到表現(xiàn)層的東西，只提供必須的功能接口，否則js與APP一起管理整個(gè)表現(xiàn)，會(huì)導(dǎo)致復(fù)雜度增加，開(kāi)發(fā)困難。但目前沒(méi)辦法，可能走得有點(diǎn)快，就目前來(lái)說(shuō)，純web的表現(xiàn)還與APP的差距甚大，必須借助APP的力量，像最基本的頭尾固定，只能由APP來(lái)展現(xiàn)。

目前iOS5的瀏覽器支持了position:fixed屬性，可以在屏幕上固定元素，支持-webkit-overflow-scrolling: touch，可以原生支持對(duì)區(qū)域滾動(dòng)，就具備了使用純web實(shí)現(xiàn)目前的體驗(yàn)的基礎(chǔ)。等接口提供再加上硬件不斷加強(qiáng)，性能上的差距也會(huì)縮小，等市面最低版本是iOS5了，硬件都升級(jí)了，web主導(dǎo)的這類應(yīng)用估計(jì)會(huì)多些。