移动端微博读书浅尝.pptVIP

大家好，我是迟斌，新浪微博前端。最近做了一个微博读书移动端的项目，今天分享一下我们做的时候的得与失以及一些心得体会。1、微博搞card，读书也不例外，但微博读书目前没有专门的读书页2、作为前端，基于HTML5做移动端的web1、书籍列表页（1）呈现所有的书在这里（2）最近阅读呈现最近读过的书籍2、书评页（1）从微博读书发出的微博挑选的精华在这里（2）我的书评，当前用户从此项目发出的微博3、阅读页（1）读书区域，可以向左向右翻页阅读。（2）滚动条跳转书籍位置（3）右上角发微博（4）阅读设置，可以更改字体大小和页面样式4、我们是山寨多看阅读+微博功能介绍下技术整体架构1、HTML5+Manifest技术，保证离线也可以访问到页面2、页面css3响应式布局，保证旋屏样式，等能够适应各种移动端3、js框架用senchatouch2.2版本，由于第一次做这种项目，选择比较成熟的框架来做4、服务器端PHP+Memcache+Mysql断网情况下，我们用localstorage和websql来做5、底层的数据，saestorage用来存好分好章节的书，OpenApi来获得用户信息，微博内容等数据。然后就开始干了4个苦逼全是前端，PHP不太熟，所有学吧。只有3周时间，包括学习熟悉框架等时间，干不完只好加班吧，跟老大承诺的时间点功能比较多，还好我既是负责人又是产品经理又是技术经理，砍需求吧。3周后很高兴的交工了老大用IPADmini看，悲剧了，页面崩了，卡死了，各种问题都来了。因为主要开发都是拿PC来调试测试，到IPADMINI这种设备上，就完全跑不起来。。。当然4个屌丝一个IPAD，实在悲剧。2B地方很多1、base64，一开始图片都已base64编码存储，导致iossafari如果超过2mb像素以上，就不加载显示了。2、CSS3造成崩溃，因为有大量的渲染放在了页面上，比如旋屏CSS3自动分栏计算，就直接崩溃3、CPU占用很高，由于一些密集的for计算，导致CPU的峰值一下飙升假死4、内存回收，包括事件、对象的都没做回收，导致阅读越多内存占用越大5、webSql在IPHONE和Androidmobile版的原生浏览器根本不支持，离线的时候应该做友好的提示。6、移动端手势也不够丰富，作为产品经理的我责任很大NB地方也是有的，不是一无是处1、学会了使用st框架2、用到了响应式布局的技术3、用到了Manifest缓存技术4、使用了WebSql主要的大问题：分页性能问题老的:1、一本书全部放到article标签里，每一自然段用P标签表示。2、然后用css3column分栏自动排版分页，确实方便，但性能低下至极3、密集for循环运算，计算量很大，包括算当前在第几页，总页数有多少，跳转到某页、转屏后重新css3分页后的计算等等，CPU挂了新的：1、页面只渲染当前页、前一后一，减小页面渲染的压力2、固定字高行宽高等到行数/页3、把上面的宽高告诉PHP，由php进行全本书的分章分页计算由于不用css3分栏分页计算，那手工的算法呢？举例，顺序排下，判断P标签位置是否超过页面底部。这种超过，怎么办？用nodeclone，超出部分overflow:hiddenPHP和JS都是如此算法计算后结果：PHP算一本9MB约等于480万字的巨大书籍，用几秒？只需要2sJS计算一本哈利波特，大概473kb，不用设备的原生浏览器给出以下答案未渲染到页面——JS引擎纯数学运算放到div里——加载前一页当前页后一页，android机悲剧了。结论。。。因为一章内容一般不超过50k，而章是从页顶开始，所以JS只算当前章即可。离线情况，静态的JS、图片、css等均访问manifest缓存web数据库，用WebSql，这块数据来源是在线时和线上Mysql同步手势也是移动开发必须的基础事件：TS,TM,TE我们用到了tap，一般操作pinchout和pinch用来显示隐藏菜单和滚动条swipeRight和SwipeLeft翻页阅读fingers，用到了三指，因为四指及以上则会关闭此应用。阅读页三指往下拉和往上推会触发阅读设置的现实隐藏，三指往里收会触发关闭当前阅读页，返回书架。其他性能提升点。1、减少HTTP请求，把不需要一开始加载的，都做触发才加载。2、GZIP3、页面的滚动用transition代替scrolleft4、用RAF代替move事件的自发式相应，优化页面渲