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主导的这类应用估计会多些。

从08年3月开始用微博，到现在三年半了。至今认真用了四个微博，因为不同的原因迁移。

第一个用的是饭否，微博的先驱，有感情的一个平台。可惜用了一年半后，在09年7月7日饭否被关了，被迫迁移到第二个平台twitter，在twitter上混了一年，后来政府慢慢对twitter封得越来越紧，把中文圈全干掉了，我不想折腾，迁移到腾讯微博用了几个月，后来朋友们都去了新浪微博，起初我只是在新浪微博评论他们的微博，后来就慢慢迁移到新浪微博了。

在很早我就说过，我用哪个微博平台取决于我朋友们用哪个平台，相信这是大部分人的选择方式，还有一部分是看明星在哪个微博，不过如果不是狂热的明星粉丝，开个马甲关注足矣，决定真正使用哪个平台的，还是身边朋友。

前两次微博迁移是迫不得已，最后一次是新浪硬生生把人抢过去了，平台效应已经形成了，腾讯微博即使有内嵌QQ的方便，仍比不上新浪微博。不知道在其他人群是怎样，在我所接触到的人群范围内，除了同事 (我在腾讯)，其他有用微博的都是新浪微博了。感觉腾讯微博已经输了，不过我猜可能90后那些喜欢玩QQ秀的比较多人用腾讯微博，没研究。

腾讯微博的活跃用户应该远少于新浪，用户数量水分很多，甚至活跃用户的水分也很多，很多是通过Q空间和签名同步，有的是从其他微博同步过去。腾讯微博僵尸粉丝很多，很长一阵子我一发微博就被不认识的人无评论转发，而且是即刻，貌似腾讯微博没严打这些用户，在新浪微博没出现过。在腾讯微博有1000个粉丝，可能只相当于在新浪有100个。

新浪腾讯微博同质化严重，微博这样的平台不需要两家一模一样的，就像QQ。MSN和QQ不是一样的，至少MSN是有主攻市场的，但现在腾讯和新浪就是一模一样的，微博没有用户就玩不转，用户只会越来越聚集在本来就多的那个平台。

新浪腾讯微博上娱乐信息过多，互联网十几年在BBS等地方积累下来的老段子在微博上不断转来转去，重复内容很多，无营养，无意义。不是说不关注某些人就可以避免这些内容，整体氛围如此，避不了。

挺羡慕其他国家有facebook的，微博对所有人都公开，跟facebook性质不同，偏向媒体/传播，个人品牌打造，facebook偏向个人生活，有隐私设置。我发的微博大多是生活，没办法，人人网太不争气了。

饭否在刚复出的时候还好，跟几个朋友在上面交流感觉不错，但一年过去了，饭否没什么跟新浪腾讯微博差异化的举动，只是做了几个应用，不免令人失望。twitter越来越少人上了，已经成为一个高端人群的微博，没事上去看看感觉挺好的。

iOS5一出来，很多对safari的溢美之声，那些新增的特性确实好，但这个版本的safari很有问题。

document.getElementById("test").innerHTML = '<div ontouchstart="alert(\'touchstart\')"></div>'

一般，这样的代码是没问题的，一段HTML字符串赋给DOM的innerHTML后，自动生成DOM，并且上面的内联事件都是有效的。在至今所有浏览器都可以这样，但现在在iOS5的Safari不行，生成的DOM中ontouchstart事件无效，目前测试ontouchstart/ontouchmove/ontouchend都不行，若改成onmousedown，onclick等都是可以的。这个问题导致了jquery，sencha的一些应用都挂了。

目前的解决办法就是，先把HTML加入一个新建的DOM里，再用cloneNode把创建好的DOM取出来加入目标位置，这样才可以。如果不用cloneNode而是直接把创建好的元素塞进去还是不行的。

var dom = document.createElement("div");                                    
dom.innerHTML = '<span ontouchstart="alert(\'touchstart\')">touchstart dom create</span>    ';                                                                          
document.getElementById("testTSdom") .appendChild(dom.childNodes[0].cloneNode(true));

可以在这里 http://bangswork.googlecode.com/svn/trunk/lab/ios5touchstart/index.html 看到效果

这应该属于一个bug，居然就带着这么明显的bug发布出来了，要折腾死做移动版的前端了。

此外，还发现iOS5下Safari的一些其他问题，例如缓存很奇怪，js excution timeout，还有一些已经碰到但未明原因的，总之，这个safari很有问题。