一开始以hybrid形式做了一个android的小说阅读客户端，叫4G阅读。而后由于业务需求，要迅速实现纯手机html5 版的，所以就直接在原先客户端内内嵌的网页进行改版，快速实现以后在优化的过程中发现越改越多越改越多…
注意此web应用只支持android及iphone内的浏览器，及PC或mac上的chrome,safari,firefox等支持html5的浏览器。IE10以上浏览器
这算是试验版了吧，以前没这么弄过..
手机访问http://crapi.4gshu.com:8096/4g-read-qd/#index
先上图，有图有真像
文件结构及路由
HTML
Index.html
整个应用框架的基础，包含了头部，尾部HTML，及主要各个页面部分的容器(content-panel)
根据hash路由通过ajax方式加载对应的内容页再添加到对应的comtent-panel内
以下是主要内容模块(内容为html片段)
Index-c.html逛
Category-c.html分类
Rank-c.htm排行
Discovery-c.html发现
Channel-c.html男频，女频...
Search-c.html搜索
Bookshelf-c.html书架
Catalog-c.html 目录
CSS
编写css时使用了less，特别是在修改时，尤其的好用
Public.css 包含了大部分的应用样式
Idangerous.swiper.css 切换插件的样式文件
内容页的样式可以在自身页面内自行添加
Javascript
Avalon.js
在此处用这个MV*框架，主要是方便处理将json数据渲染到DOM上
Jquery.js
很想使用zepto之类的轻DOM框架，但最终还是选择了jquery2.0,原因是方便扩展插件，很多插件不兼容zepto，其实JS文件的大小远没有你想象的那么影响web应用的表现，其实css的渲染影响更大，血的教训啊。关于JS文件过大的问题，其实应用基本上是在3G或wifi情况下使用，你非要在2G环境下使用，那干麻不用WAP版...
Idangerous.swiper.js
非常强大的轮播插件，其实可以实现很多东西。所以选用它来实现轮播
Mango-decoupling.js
很好用的消息插件，用于程序中解耦设计，其消息机制也非常强大
Config.js
由于将这个应用分发到不同的渠道，而不同渠道又有一些不同的配置需求，所以用了config.js来配置一些属性
Core.js
整个框架通用JS的核心，包含了本地储存，通信，通用的事件与方法
为了方便实现，及减少JS文件数，各个内容模块的JS业务逻辑都直接写在各自的html片段中。内容模块在渲染完毕后应该向框架发送一个渲染完毕的消息，或执行框架提开放的渲染完毕API，比如“page_ready”,方便框架处理loading等全局的控制
本地存储
1、离线存储cloudary.appcache，尽可能的将css，js,image,及HTML代码片段文件都离线存储至本地。初次访问时会将所有相关文件都离线到本地，以后再次访问，会优先读取离线到本地的文件
2、Localstorage存储接口数据。开发过程中明显感觉到，后台提供的数据接口的速度明显影响了整个应用的表现，所以在初次访问动态数据接口时将使用localstorage将整个接口返回的数据存储到本地，以后再次访问时先优先读取本地的数据，然后后台会静默更新数据到localstorage内，由于应用没有那么高的实时性要求，所以此方案可行。
Hash路由
整个应用的内容模块content-panel其实是由hash路由来连起来的，构成了所谓的单面应用，即不刷新整个页面。一开始使用的是popstate来实现，结果发现在chrome浏览器下一进页面就会触发一次popstate事件，比较奇葩，这个问题是在应用完成后发现的，还好popstate事件是在core.js中进行过封装的，我就在封装处将popstate事件替换成了hashchange事件，所以说对外部的API还是要抱有不信任的态度，尽量进行封装分隔，万一发生改变，改起来也快。在加载不同的内容模块时，通过wndow.history的pushState和replaceState来实现hash值的改变，在一进页面时首先得把自身页面进行一次replaceState,将自身加入history队列，否则history队列会乱(一大坑啊，反正我以前没replaceState时是遇到过，怎么也管理不好队列)。
根据UI上的设计及功能的不同，我将路由分成了两类，
主页路由：
Index 逛
Category分类
Rank 排行
Discovery 发现
子页路由：
Channel频道
category-detail 分类详情
Topic 专题
Detail 详情
Search 搜索
Bookshelf 书架
Catalog 目录
关于路由的速度优化
1、很多内容模块打开过一次后再次打开时完全是不用再请求的，所以得判断是否打开过，打开过的应用再次打开时就不再请求对应的html片段了，直接显示之前请求下来的html片段，比如index,category,rank,discovery,topic,bookshelf,search这几个内容模块
2、对于需要更新内容的模块，比如detail，channel模块，第一次请求到html片段后也可以缓存下来，以后每次请求新的内容时只需要通过JSON数据更新dom即可，即无需把dom清掉再重新创建新dom。这一点的优化对于性能比较差的mobile设备上尤其重要，这样实现后，请求数据这个动作需要在路由发生变化时发送自定义消息（如：refresh_with_new_data），接受到自定义消息时再发送数据请求，得到消息后再更新dom的内容。
3、即使对于需要更新的内容，同一个链接，连续被打开时，由于数据完全没有变化，所以也可以完全不去请求数据，即可做到所谓的“秒开”
理论上应该用但并未使用的技术
1、backbone,算是比较广泛的mvc框架了，自身提供了路由功能，但个人觉得需要写的代码量太大，如果是团队使用用来规范代码还行，如果个人使用的话，我觉得还是太重了。写一个简单的功能就一大堆代码及对应的JS文件。
2、Requirejs或seajs
本身应用中就首页这几个JS文件，写完就没了，没必要再多一个额外的JS文件请求
3、一些新的CSS3属性
某些比较好用的CSS3属性在移动端支持有限，所以没有使用，比如布局的两端对齐
4、较高的内容模块分段显示，即滚动到了后再渲染到DOM中，首先后台并未提供分断加载的API，其次，自适应的布局加大了实现的难度，最后，木有足够的时间
不足
1、开发时间过短，很多公司的通病吧
2、产品在设计时未考虑单页应用的场景，层级太深的页现在还是刷新整个页面
3、有些功能还未按以上的构架实现，比如动态接口本地存储只做了index首页等
4、比较丑，样子丑，代码实现也比胶水
No zuo no die
为何在内容模块切换过程中未添加一些像native应用切换一样的动画效果？
由于android的机型无花八门，性能参差不齐，css3动画支持力度不一，很多hybrid应用的出现正是为了弥补这样的缺点。布局用html,切换动画使用native。如果你的web应用只要求跑在iphone这等高大上的设备上的话，完全可以使用css3来实现界面切换动画，如果你要求跑在所有平台上，那么......该吃药了亲..
如果你非要尝试，那么你应该会体会到什么叫no zuo no die
结束语
优化工作是个系统性工程，得从方方面面考虑，从产品设计--》UI设计--》前端代码实现--》后台数据接口提供
现在的优化只能算是皮毛吧，不仅前端部分需要优化，而且后台数据接口速度过慢也严重导致了响应速度。
纯粹的手机web单页应用本来就做的比较少，经验太少，需要继续努力学习..
码农啊...
有看到这篇文章的同学欢迎提意见，优化方面特别是
