一般在web中实现drag与resize都是通过mouse的几个事件组合完成的，如果当前对象出现在iframe上方，就mousemove事件将变更非常卡，几乎完成不了拖拽。
解决方法很简单，就是在开始drag或者resize的时候，mosemove过程，屏蔽iframe,当然，我们不能隐藏它，可以用一个透明遮罩层覆盖在iframe上方。
观察了下，jquery.ui的dragable与resizable组件，同样存在这样的问题。
在dragable组件中，可以通过参数：{iframeFix：true }来解决，原理类似上面。
而resizable就没这么幸运，没有这个参数（大概，这两组件不是同一人写的，哈）。
要解决这个问题也不难，参考:
var opts = {};
//resize开始,添加一个遮罩层到body
opts.start = function (e) {
if (!$._resizeIframeMask) {
$._resizeIframeMask = $('
').css('opacity', '0').appendTo($(document.body));
} else {
$._resizeIframeMask.show();
}
}
//resize结束
opts.stop = function (e) {
$._resizeIframeMask.hide();
}
离开momo项目后的新项目，经过近两周时间的开发，基本完成了核心的交互，目前能够简单点对点通信。
完成率40%，未来一周要努力把所有消息类型处理完毕，再后面一周交互改进及UI贴图，希望早点推出去用呀。
发完最后一个版本，明天开始就要转新项目了，整理文档的时候，顺便分享下3G版的前端架构吧，不知不觉，MOMO两岁了，MOMO3G半岁了，希望MOMO有更好的发展吧。
MOMO 3G 前端架构
MOMO两年回顾：
2010-xx-xx：MOMO项目启动。（只记得开始是做游戏社区，然后因为手机互联网的热潮，不知不觉又启动了momo项目）
2010-08-20：MOMO网站前端开发规范， http://jslover.com/?p=165
2011-06-01：MOMO六一活动-MOMO的第一次推广， http://jslover.com/?p=293
2011-06-11：MOMO团队@晚上11点的办公室, http://jslover.com/?p=303
2011-09-16：MOMO 3G项目启动，评测各种html5 mobile框架， http://jslover.com/?p=343
2011-11-08：MOMO 3G第一版发布，http://jslover.com/?p=370
2012-03-30：MOMO 3G v1.16版本发布(svn:224145)， http://m.momo.im/t
有通过在线验证w3c标准的同学，应该都有遇到类似的提示 :
“& probably should have been escaped as &”。
由于之前在各种平台各种浏览器上测试不替换‘&’并没有什么“危害”，所以很多时候为了查看更直观，没有对‘&’进行标准化替换。
目前，移动MOMO开始在黑莓机上推广了，通过黑莓8230机子的测试，发现了wap版momo的一个BUG，部分页面解析一半就被中止了，从表现上看像是标签没有正确闭合。
通过W3C在线测试，只发现一个错误提示，就是上面的提示。替换之后一切正常。
前端测试想覆盖所有平台所有机型所有浏览器，几乎是不可能事件，只能尽量都遵循标准了。
先看下效果图：
通过这样的排序，结合无缝滚动加载，就可以在屏幕中呈现连续、紧凑的图片布局效果。比起传统的行对齐方式，减少了很多不必要的空白；比起等宽等高，更加自由、活跃。
算法很简单，就是预先设置到几个列（上图例子显示的是3列），然后让图片逐张加载，每次插入图片前先计算每列的高度，往最低的列里插入图片就好了。
在本DEMO中，只要修改body中的ul节点数，就可以达到显示列数的效果，比如body中初始化4对ul，则显示效果如下：
逻辑比较简单，不做具体分析，详见demo: http://jslover.com/wp-content/uploads/2012/03/imglayout/index.htm
要注意的几个点：
1、图片通过css强制成固定宽度、高度auto
2、图片加载回来之前，高度是未知的，为了精确计算列高度，需要用递归或者其它方式逐张加载图片，每加载完一张再插入一张
1、iphone/android原生app常见结构
似乎，所有的手机应用，都遵循这样的布局：固定的顶部+固定的底部+可滚动在中间区域。这种“雷同”的模式让人恶心，却不得不承认这是一种很规矩却又很实用的体验，或者说已经固化成一种设计模式。这一点好比我之前提到的一篇文章《twitter UI已成习惯》http://jslover.com/?p=305 .
如果是webapp，我们也希望这样做吗？如果是通过手机浏览器访问，由于浏览器的地址栏、状态栏等本身就占据了一定的高度，所以如果继续在内容页实现这种上下“fixed”的设计，显然是一种累赘的设计，不过如果想做的更“像APP”，通过一些hack来全屏浏览器，然后再加上这个“fixed”的显示，还是不错的。另外，如果是将我们的webapp打包成手机安装应用，那么这种“fixed”的设计将成为必须，否则，将“不太像”一个app.
2、通过position:fixed
在pc上，ie6以上的浏览器都是兼容这个属性的，而且ie6也有比较完美的解决方案，见《IE6中fixed抖动问题的解决》http://jslover.com/?p=66
而在手机上，情况就不容乐观了，iso5据说可以支持，没测试过，iso4是不支持这个属性的的，android2.1测试是通过的。
即使手机浏览器完全支持了这个属性，体验上还是不完美的，看下面这个截图就清楚了：
上面这个截图，顶部的导航栏是通过”position:fixed”实现固定位置，不过，可以看的出来，滚动条的区域还是针对整个页面的，在web上无所谓，在手机上，看到滚动条”爬到”导航栏上面一定很纠结吧。
3、使用iscroll
根据我们上面遇到的问题，如果不考虑性能问题，iscroll的解决方案决定是最完美的，几乎完全一致地模拟了原生app的滚动条效果.
iscroll的实现原理也很简单，上中下三个区域都用绝对定位，header部分top:0,footer部分bottom:0，中间区域top:header的高度，bottom:footer的高度。然后就是对中间区域进行滚动条事件的模拟。经过测试，在iso上运行顺畅，在android浏览器上存在性能问题，偶尔会出现浏览器卡死现象。但如果通过webview打包成app，在两个平台上都表现良好，未发现卡死现象。
iscroll下载：http://cubiq.org/iscroll-4
4、通过appcan框架
appcan对fixed的处理，其实也不完美，首先是使用css的fixed属性。当然对于不兼容的浏览器框架中封装了一个 zy_fix(..)的function，这个还得依赖于appcan的“壳”，zy_fix对过调用框架的uexWindow.openSlibing（..）动态生成了一个新的“webview”控件，通过“壳”级别来控制。可惜，它的处理方式还是有些令人失望，问题和上面的第2点似乎，中间区域的滚动条是针对整个界面的，内容区域都是可能通过“margin”来控制，不过滚动条的显示就没辙了。
appcan官网：http://appcan.cn
5、自定义webview
这种当然也是只能针对打包成app的情况，需要有android/iso开发人员配合。
应用默认初始化3个webview，上面不需要滚动，中间区域可以完美实现滚动。3个webview之间要提供相互访问JS和DOM的接口，当然最好还能动态改变这些webview是否显示等。
纵合以上，如果是基于手机浏览器的在线webapp，不建议使用fixed的设计。如果一定要使用，android版使用”position:fixed”。iso使用iscroll。
如果是打包成app，性能优先，考虑使用第5种方式。开发效率优先，使用第3种方案，毕竟iscroll在android平台上（打包后的应用）效果尚可，在iso上近乎完美。
记得今年的第一篇博客，<2012部分计划>有提到，每周都要坚持摄影，然后每月在这里分享。这个计划算是坚持执行了，每周末基本都带着相机到户外走走。顺便把之前注册的点点网帐号用来当摄影博客了。点点网真不错，还支持域名绑定，看照片轻进入：http://p.jslover.com
这个应用是作用appcan的web模式打包的，总共开发过程4个小时，同时打包成ios/android版本。
思路很简单，摇一摇，随机生成 一个id,去baidu图片库中搜索一张美女图片，并在页面中显示出来。
核心点有2：
1、“摇一摇”算法：
appCan的框架提供了传感器一些变量的捕捉，不过没有直接的“摇一摇”接口。我实现了一个简单的算法：
var isFirst = true;
var x0, y0, z0;
var num = 15;//灵敏度
var _div = document.getElementById("show_id");
function accelerometerChange(x, y, z) {
if (isFirst) {
isFirst = false;
} else if (Math.abs(x - x0) > num || Math.abs(y - y0) > num || Math.abs(z - z0) > num) {
//摇了
}
x0 = x;
y0 = y;
z0 = z;
}
当然上面的算法要结合api中的uexSensor.onAccelerometerChange(inX,inY,inZ)一起使用。
api:http://st.appcan.cn/dev/dev_api_uexsensor.html
2、图片捕捉：
研究了一些m.baidu.com上面的图片，找到了一些规律，打开下面这个地址你就明白了:
http://m.baidu.com/ssid=0/from=0/bd_page_type=1/uid=wiaui_1330061806_8189/pu=sz%40224_220/img?tn=bdwid&word=%E6%80%A7%E6%84%9F%E7%BE%8E%E5%A5%B3&pn=1&dw=w320″
提换上面的红色的1就可以显示不成的图片页面了
另外，如何跨域请求？
不用担心，appCan的框架也帮我们实现了跨域api,uexXmlHttpMgr
api:http://st.appcan.cn/dev/dev_api_uexxmlhttpmgr.html
其它的细节就不多说了，毕竟只是一个测试
使用iscroll模拟了滚动条，在iphone上测试发现，偶尔会发现滚动内容出现闪动的BUG，经过多数轮吐血测试，终于可以重现BUG了：
BUG重现：
滚动内容区域高度<=1024px，则显示正常。如果>1024，初始化iscroll组件时候就会出现闪动的BUG，或者在浏览器从后台重新激活的时候，也会出现闪动的“刷新”。
BUG解决：
通过逐步跟踪调试，终于找到了原因， 是webkit调用-webkit-transform：translate3d…导致的BUG。
所以最快的解决方法是，将配置文件中的useTransform设置为false。
BUG的根源：
查了一些资料，根源是ios4 webkit的bug,在iphone webkit创建纹理的时候，如果内容区域>1024象素，将会继续创新纹理，而iscroll中调用的translate3d动画在这个重绘的过程中出现了一些BUG，这些在iso5中得到了修正。
参考资料：
http://joehewitt.com/2011/10/05/fast-animation-with-ios-webkit
在这之前webapp要打包成手机应用，一般需要使用phonegap来打包，phonegap拥有很丰富的本地API，可以同时生成多平台应用，算是不错的选择，不过需要配置较繁琐的开发环境，对开发者来说不是很方便。appcan提供了一个在线发布的平台，最方便的方式就是提交你的webapp应用地址，然后选择图标与启动画面就可以生成一个标准的简单app，支持ios,android和symbian平台。
在手机本地api方向，也较为丰富，常用的接口都实现了，比如拍照、录音、联系人、位置、二维码扫描等。还提供了更为傻瓜式的easy模式，很容易创建出较为专业的应用。
API地址：http://st.appcan.cn/dev/dev_api_document.html#
目前还在内测，需要激活码，我也有幸捡到体验了一番。
我的一个webapp应用中使用了iscroll滚动条组件，从android平台测试来看，打包后的程序效率比直接使用原生浏览器访问还高些！