QQ邮箱iPhone版 — 混搭式开发的尝试

QQ邮箱iPhone版开发了几个月，多次延迟发布，过程十分艰辛。这是第一次尝试混搭的开发方式，即整个应用主要由web组成，APP给web套上一个壳并提供一些原生的接口，以达到更好的体验。我们使用了开源的PhoneGap框架，但其实到后来已经可以抛弃它了，没用它多少接口，自己实现一下也只是时间的问题。

总体

整个APP主要是以下三点：

1. APP由js驱动，与手机邮箱触屏版/ipad版使用同一套逻辑，同样的M层，架构一致。
2. 由APP客户端提供绘制头尾以及动画切换的接口，由js调用。
3. 使用HTML5的sqlite/localstorage缓存数据，applicationCache缓存静态文件和页面。

加上各种细节，就可以构建一个仿原生应用了。

问题

实际上说得简单，做起来难，碰到很多问题。

性能

DOM的性能差，渲染速度慢，最初在各个模块之间切换时速度不能忍受，经过各种优化后情况才好转。优化包括：去除所有高级CSS特性，例如阴影渐变等，减少list默认显示条数，缓存DOM，APP头尾控件缓存，APP动画拍照优化。即使经过很多优化，目前性能上还是跟原生APP有所差距。这种差距目前来看只能等待硬件升级。其实在未做任何优化前，在mac的模拟器上体验已经很好了，无性能问题，因为mac的硬件够好。

manifest

applicationCache的manifest是个令人头痛的东西，项目过程中几度出问题。它最大的不足在于不能清空缓存，一旦使用了它，将很难抛弃它，只能更新，不能抛弃。造成的问题是，manifest更新时，拉取新的资源文件，一旦主页面在后台输出的是个不正确的页面，被缓存起来了，就万劫不复，再也无法进入应用了，因为没有机会再次取拉正确的页面了。所以要使用它，需要强力保证主页面绝不会输出错误，最好是个静态页面。

此外用manifest还要非常细心。项目过程中有两次出现突然无法离线的情况。一次是manifest针对高清屏输出的文件有个地方没换行，导致缓存无效。很难看出它没换行，因为manifest文件是套模板的，模板上是有换行的，转完输出就没有了。只针对高清屏错误就导致模拟器和iphone3都没问题，只有iphone4有问题。折腾这个诡异的问题半天。另一次是写在APP里的启动网址参数里多了个’s'，导致打开的页面跟缓存的页面不一致，很难发现，也查了挺久。

JS-APP不同步

APP提供了绘制头部底部的接口，何时绘制以及绘制什么由JS控制。模块的切换会有动画效果，在js调用模块切换时，先拍照，再画头画底，再回调开始动画的事件，JS渲染自身的dom，动画切过去，整个流程挺简单挺清晰，但实际会有各种问题出现。

在初期经常出现APP头尾和模块内容不一致的问题，由各种原因导致，可能在切换模块整个流程没结束时马上又切换模块了，或者再调一次画头尾，会打乱流程。这通过APP那边把命令加入一个队列顺序执行，并且在动画过程不响应事件来解决。

登录问题

由于历史问题，登录没有使用ajax，整个应用不可避免地需要页面跳转，这会导致非常多的问题：
1.在某些网速非常慢的情况下，整个应用白屏无法避免，因为在跳转了页面并且页面还未载入时，必然会先出现一个空白页面。
2.登录的loading菊花卡住不转，因为跳转了页面本页面的无论是gif还是canvas都停止运行了。
3.一旦出现运营商劫持/wifi验证页面，整个应用就会调转到这个页面去，完蛋了。这个后来通过把表单提交到iframe解决。
所以，最好不要出现跳转页面的情况，必须整个应用在一个页面里。

沟通成本

本来一个iPhone APP的开发链就是，UI-客户端-后台，加入js后，多了js与客户端沟通的成本。而在这种开发模式不成熟的时候，这个沟通成本挺大。另外在APP出问题的时候，有时挺难判断是js的问题还是客户端的问题。

由于APP介入了表现层，进入JS的逻辑，所以必须对APP和JS两端都熟悉了解，才能掌握整个流程。之前不清楚为什么phoneGap不推出这个固定画头画底的接口，这是所有APP必备而在web上实现性能又很差的东西。现在知道这会使APP变复杂，phoneGap只提供功能接口，作为后台角色，其他全交给JS，不需要与APP进行过多的沟通。

webView/网络

出现了一些问题我们还没弄清除是不是webView的问题，例如，记住cookie的问题，登陆过后是设了cookie的，但如果这时马上退出，下次进来就不会有cookie，如果是隔个二三十秒过后再退出，cookie就能记住。非常奇怪的行为，对此我们只能打个补丁，把某些cookie存到localstorage，下次进来如果没有cookie就从localstorage里取，这个方案还依赖了mainifest。

另一个是APP环境改变时ajax的行为问题，在请求或者上传时，APP切换到后台，APP切换网络，APP切换到后台长时间不用再打开，APP终止webView的请求，都会由可能导致ajax卡死，无onsuccess或onerror的callback，有时还会导致JS被阻塞，接下来无法正常响应请求。这是我们框架的缘故，还是webView的缘故，还待查。

好处

与纯原生APP比，它是有带来一些好处的。

1. 云端升级：应用的某些升级无需通过AppStore，无需用户下载安装，可以快速迭代。
2. 代码复用：触屏版/ipad版的多数代码可以复用或者共用，降低开发成本，提高开发速度。
3. 跨平台：我们暂时没用到这个好处。若要跨平台，数据层没问题，VC层还是有很多的不同。

总结

混搭的开发方式，APP最好不要参与到表现层的东西，只提供必须的功能接口，否则js与APP一起管理整个表现，会导致复杂度增加，开发困难。但目前没办法，可能走得有点快，就目前来说，纯web的表现还与APP的差距甚大，必须借助APP的力量，像最基本的头尾固定，只能由APP来展现。

目前iOS5的浏览器支持了position:fixed属性，可以在屏幕上固定元素，支持-webkit-overflow-scrolling: touch，可以原生支持对区域滚动，就具备了使用纯web实现目前的体验的基础。等接口提供再加上硬件不断加强，性能上的差距也会缩小，等市面最低版本是iOS5了，硬件都升级了，web主导的这类应用估计会多些。