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

總體

整個APP主要是以下三點：

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

加上各種細節(jié)，就可以構建一個仿原生應用了。

問題

實際上說得簡單，做起來難，碰到很多問題。

性能

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

manifest

applicationCache的manifest是個令人頭痛的東西，項目過程中幾度出問題。它最大的不足在于不能清空緩存，一旦使用了它，將很難拋棄它，只能更新，不能拋棄。造成的問題是，manifest更新時，拉取新的資源文件，一旦主頁面在后臺輸出的是個不正確的頁面，被緩存起來了，就萬劫不復，再也無法進入應用了，因為沒有機會再次取拉正確的頁面了。所以要使用它，需要強力保證主頁面絕不會輸出錯誤，最好是個靜態(tài)頁面。

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

JS-APP不同步

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

在初期經常出現(xiàn)APP頭尾和模塊內容不一致的問題，由各種原因導致，可能在切換模塊整個流程沒結束時馬上又切換模塊了，或者再調一次畫頭尾，會打亂流程。這通過APP那邊把命令加入一個隊列順序執(zhí)行，并且在動畫過程不響應事件來解決。

登錄問題

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

溝通成本

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

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

webView/網(wǎng)絡

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

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

好處

與純原生APP比，它是有帶來一些好處的。

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

總結

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

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