每次会议都会有一个大的主题，这一次是移动互联网应用的性能问题，来自Google的Steve Souders，也就是：高性能网站建设指南（http://book.douban.com/subject/3132277/）一书的作者，给大家介绍了如何测量和优化移动互联网应用的性能，其中有一些不错的在线工具帮助大家做测量：
Mobile Perf
http://stevesouders.com/mobileperf/mobileperfbkm.php
书签形式的快捷入口，方便查看加载，Dom等信息，比较有用的是WebTiming，查看加载时间。
jdrop
http://jdrop.org/home
Json的云存储服务，方便在手机上收集数据，然后在电脑上查看分析。
blaze
http://www.blaze.io/mobile/
测量指点站点在不同移动设备上加载的工具。
PCAP
http://pcapperf.appspot.com/
分析移动浏览器网络信息的工具，介绍见这儿：http://www.infoq.com/cn/news/2011/01/google-pcapperf
同时作者针对之前适用于桌面浏览器提出的前端性能原则做了修正：
移动设备上的浏览器，因为最大连接数比桌面要小，需要尽量减少连接数。
因为网络的问题，特别需要考虑图片的优化，如针对不同分辨率的屏幕提供不同大小的图片。
同时因为现在的智能手机对css3支持的都不错，可以用一些css3的特性，来减少图片的使用
特别小的图片，可以用CSS3的 Data Uri来做，相关介绍见：http://dancewithnet.com/2009/08/15/data-uri-mhtml/
缓存部分，推荐使用HTML5的Cache和本地存储来做。
--------------------------------------------------------------------------------
新一代Facebook移动平台
新平台的接口和功能
平台上移动应用的研发流程
平台为移动应用提供的传播支持
Facebook的DavidWei，他的演讲内容丰富，条理清晰，每次听的人都很多。
首先介绍了Facebook移动应用的增长情况：
增长量大
活跃度高
有大量的站点和应用连接到Facebook
然后介绍了Facebook移动设备上的信息传播渠道：
好友请求：点对点，针对性好。
用户Feed：一对多，类似于推荐，使用了某个不错的应用等。
以及Open Graph：一对多，类似于轻量级的Feed，用于访问了哪些网站，like了哪些餐馆，歌曲等等，谁做了某件事的表达形式，干扰少。
关于：Open Graph 的详细介绍，见这儿：
http://yogar.blogbus.com/logs/62725127.html
同时还介绍了facebook的JS界面库，登录，加好友，支付等接口。
在交互设计方面，作者也做了分享：
好友请求，同时推荐可能认识的人。
新的消息，在右上角，以红色数字的形式高亮显示。
用户Feed与推荐，在创建时，显示要发送的内容，防止应用开发者使用夸张的介绍内容。
多条类似的Feed会自动合并。
安装新应用时，告诉你有哪些好友也安装了这个应用。
这部分推荐看一下这本书：
社交网站界面设计
http://book.douban.com/subject/4909176/
DavidWei还提出了：Applications on multiple devices的观点，即你可以在不同设备上无缝的使用同一个应用，同时数据会共享。
这个有点像Kindle的用户体验，会自动同步书签和笔记，我们可以考虑在背单词应用上采用类似的设计。
--------------------------------------------------------------------------------
快速的移动互联网网站与商业KPI的关系：来自一线的案例分析
介绍了在移动互联网环境下，性能对用户体验以及转化率的影响。
Joshua Bixby 首先介绍了从2005年以来
移动设备的变化情况，目前以IPhone，IPad，以及Android为主。
在facebook等社交站点上，移动设备所占流量的比例在加大。
来自移动设备上的支付也在增加，主要的例子有Amazon和eBay等。
同时以图表的形式，介绍了一个站点的流量来源变化情况：
完整的站点
wap站点
app应用
还举了一个实际的例子：
100个移动用户，其中有35个去了完整的站点，24个只看了一页就离开，有40个人看了一些页面，只有一个产生的购买行为。
如果从购买的比例来看，这儿的转化率就是1%，我们需要的是提高这儿的转化率。
从移动设备的统计方式来看，有JS脚本形式以及基于服务器日志2种方式。因为iphone，ipad，android等设备都支持js脚本，所以2种形式的比例差不多，有差别的是blackberry和Symbian，因为这2种系统的版本和设备比较复杂，对JS脚本的支持不是特别好。
网页加载速度，对于转化率的影响，作者举了个形象的例子：
15个人，要做一个需要5个步骤才能完成的操作，例如注册，假设每个页面速度都一样的情况下：最终有5个人完成了转化。
修改页面速度，让第一页加载很慢，结果，只有2个人完成了转化，很多人在第一页就被挡掉了。
修改页面速度，让第三页加载很慢，结果，只有3个人完成了转化，这次要好一些，大家愿意多等一会。
结论是首页的加载速度最重要，直接影响用户的最初体验。
在最后，作者还提出了一些自己的观点：
App应用的形式，只适合某些站点。
用户并不喜欢wap站点。
移动设备的访问速度，直接影响收入。
--------------------------------------------------------------------------------
来自淘宝的低功耗服务器定制与绿色计算
http://www.greencompute.org/
http://www.infoq.com/cn/news/2011/11/taobao-greencompute
介绍了淘宝的CDN系统中，使用定制的低功耗服务器的情况。
我的感觉有2点比较有用：
1 节省了空间，一个2U的机箱可以放8台低功耗服务器，每台机器为双核的CPU，4G内存，3块硬盘（1个SSD，2个SATA）。
2 能耗很低，看了介绍，只要25瓦。
结合我们自己的情况，我们目前会用配置较高的服务器做虚拟化，虽然总体运行比较稳定，但IO会是瓶颈，如果是重要的数据，还会担心稳定性的问题。而多数web和文件服务器等，平时压力并不大，这样可以考虑用这种小型的低功耗服务器来做，压力大的时候做负载即可。
如果有合适的商用解决方案，我们也可以考虑购买，查了一下，戴尔和惠普都有这方面的计划。
--------------------------------------------------------------------------------
上午主要是概念和趋势性的介绍，下午则会针对具体的问题做介绍。
比较好的有来自Facebook的DavidWei对于：移动互联网应用的性能优化
介绍了：
移动互联网的技术特点：从应用开发者的角度，哪些特点需要我们注意；
移动应用的性能：测量和优化移动互联网产品的一些方法和工具；
新技术的应用：HTML5为移动互联网产品带来的机遇和挑战。
首先介绍了桌面浏览器和移动设备上关注点的不同，移动设备需要关注耗电和安全的问题。
因为移动设备的网络通讯不是一直连接的，会在最后一次网络请求后过几分钟再断开，如果一个页面或应用，频繁的进行网络连接，会造成更多的网络连接开销，而这其实是可以优化的，建议是把多个操作放在一个请求里去做。
因为移动设备会使用很多公用的wifi信号，这就带来安全问题，别人可以通过抓包，来截取和重放已有的操作。为了安全，同时保证速度，可以考虑以下几种方式：
1 除了图片以外，页面请求用https加密的方式。
2 只在需要cookie验证的页面使用https加密的方式。
在桌面浏览器的情况下，我们会放置更多按钮，或滚动到页面末尾时，自动加载更多内容，这在移动设备上会产生问题：
1 加载更多内容后，dom节点数量会增加，占用更多内存。
2 页面内容多了以后，会影响滑动的速度和用户体验。
所以不推荐，或者需要有针对性的优化，如回收顶部内容的dom节点。
另外还介绍了如何统计DNS解析时间的小技巧：
随机数.facebook.com/test_pixel 空文件的形式，来统计dns加载时间。
关于如何收集和统计移动设备的型号，可以通过Agent来做，但移动设备的型号过多而且分散，这时可以用：
wurfl来做，wurfl是一个开源的移动设备浏览器agent数据汇总，xml形式，可以很方便的加载和处理，还有.net客户端封装。
http://wurfl.sourceforge.net/
http://wurfl.sourceforge.net/dotNet/
http://sourceforge.net/projects/wurfl/files/WURFL/2.3/
对于facebook来说，因为开发人员数量有限，为了尽快的推出各个平台上的应用，并保证界面交互的一致性，目前主要是采用app外壳，内嵌HTML页面的方式来做，也就是我们之前评估过的PhoneGap。
同时采用循序渐进的方式：Wap页面，3G页面。
为了方便调试，有2种方式：
1 修改Safari浏览器的Agent，访问移动页面，然后看加载情况。
2 http://phonegap.github.com/weinre/ 在移动设备里访问页面，通过Debug服务器，在桌面环境，看页面信息。
3 http://www.charlesproxy.com/ 代理服务器的方式，查看加载情况。
--------------------------------------------------------------------------------
基于应用场景的NoSQL选型与实践
介绍了奇艺网使用MongoDB和Redis的经验和心得。
和我们相关的主要是图片存储的部分：
图片-需求
单条长，不可变，最近最热
增量写，主键查
元数据：大小，尺寸，日期
用MongoDB存储时，推荐的方式是Doc，而不是GridFS，后者速度慢，内存占用大，并且有更多的操作日志。在1.8版本，单条记录最大16M，如果可以确认所有的文件都小于这个尺寸，就可以直接Doc形式存储，GridFS则没有这个限制。每个图片在存储时，还要有个uid信息，以方便分片。
同时还介绍了奇艺网储存用户播放记录的经验：
特点是：
写多读少，读写比 < 1：10
更新频繁：数据量小，oplog大
用户数据分散：浪费内存，多次seek
这个其实和我们的背单词应用有些类似。
1 用MongoDB存储时，设置同步时间为1小时。
2 关闭oplog，取而代之的是定时备份。
3 多个子记录合并为一条。
关于如何优化MongoDB的性能，好多是和MongoDB本身设计相关的，如：key的大小，锁定机制等，这块在幻灯片里有详细的说明。
作者还维护了一个NOSQL的网站：
--------------------------------------------------------------------------------
支持迭代计算的MapReduce框架
介绍了豆瓣的MapReduce 框架实现与应用。
具体的见幻灯片，我这儿记一下其中比较有意思的观点：
1 豆瓣使用了社区版的InfoBright，即列式数据库在做数据分析。
http://www.infobright.com/
http://bbs.tech.ccidnet.com/read.php?tid=244201
列式数据库在做数据分析时，有很多优点，存储空间和性能都不错。
2 网络带宽已经大于硬盘读取速度，所以豆瓣的框架，数据读取时，从一个中心数据库读取，而不是分布式存储。
3 在不是海量数据的情况下，比hadoop稍微慢一些，性能可以接受，并且近期会开源。
--------------------------------------------------------------------------------
Web应用的加密算法实现缺陷与利用
介绍了不同加密算法的特点，与注意点。
其中举了PHPWind和Discuz!在加密和验证时的漏洞，这块有2个原因：
1 使用了自己的加密算法，这时往往思考的不够全面。
2 这2个项目都是开源的，这样相当于白盒了，别人可以通过代码级，寻找漏洞。
这样，其实也告诉我们，如果是使用第三方的内容系统，需要有人关注和跟进版本更新和漏洞，否则很容易被人扫到漏洞。
另外一个很重要的是，这种第三方的内容系统，在部署时，要尽量隔离。
幻灯片在：
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。