QQ邮箱iPhone版开发了几个月,多次延迟发布,过程十分艰辛。这是第一次尝试混搭的开发方式,即整个应用主要由web组成,APP给web套上一个壳并提供一些原生的接口,以达到更好的体验。我们使用了开源的PhoneGap框架,但其实到后来已经可以抛弃它了,没用它多少接口,自己实现一下也只是时间的问题。
总体
整个APP主要是以下三点:
- APP由js驱动,与手机邮箱触屏版/ipad版使用同一套逻辑,同样的M层,架构一致。
- 由APP客户端提供绘制头尾以及动画切换的接口,由js调用。
- 使用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比,它是有带来一些好处的。
- 云端升级:应用的某些升级无需通过AppStore,无需用户下载安装,可以快速迭代。
- 代码复用:触屏版/ipad版的多数代码可以复用或者共用,降低开发成本,提高开发速度。
- 跨平台:我们暂时没用到这个好处。若要跨平台,数据层没问题,VC层还是有很多的不同。
总结
混搭的开发方式,APP最好不要参与到表现层的东西,只提供必须的功能接口,否则js与APP一起管理整个表现,会导致复杂度增加,开发困难。但目前没办法,可能走得有点快,就目前来说,纯web的表现还与APP的差距甚大,必须借助APP的力量,像最基本的头尾固定,只能由APP来展现。
目前iOS5的浏览器支持了position:fixed属性,可以在屏幕上固定元素,支持-webkit-overflow-scrolling: touch,可以原生支持对区域滚动,就具备了使用纯web实现目前的体验的基础。等接口提供再加上硬件不断加强,性能上的差距也会缩小,等市面最低版本是iOS5了,硬件都升级了,web主导的这类应用估计会多些。