Mobile Router.js的初衷
前言
这是一篇迟来的文章，最合适的应该是在这个项目最开始的时候来写的，但是迟迟没有来写，懒惰的自己O(∩_∩)。mobile-router.js这个项目最早应该追忆到2014年底，当时由于工作需要，需要对公司项目上的触屏版做一次重构，运用新的ui、交互。由于12年的时候做过一个移动端的项目，所以还算是有点经验，所以就重新梳理思考了自己以前遇到的问题以及当时自己对应的笔记；但是移动端变化还是很快的，虽然只是相隔了不到两年，但是这两年却又很大的变化，以前需要兼容的、一些bug可能现在都以及不需要考虑了。但是最基本的还是没有变，那就是mobile web app的限制，内存限制也好、特性限制也好，亦或者是各种厂商各种系统版本（当时指的是Android）亦或是各种浏览器（你懂得）；针对IOS的还好，毕竟性能好、不需要适配各种机器各种乱七八糟的版本，所以从源头上来说就以及注定了IOS要比Android好做一点。
梳理完之后，思考归思考，项目还是要进行的，所以就要继续往下前行了。。。
初衷
所以根据基本需求，当时拟定了一些基本要完成的任务以及对应的一些解决方案：
-
基础库，知名的zepto.js
-
模块化，依赖加载；选择了知名的RequireJS
-
解决移动端点击以及相关bug的库，知名的fastclick
-
待解决SEO问题，意味着支持服务端渲染
-
待解决路由问题，毕竟是要做SPA嘛🐴
-
切换动画问题，为了效果好啊，木办法o(╯□╰)o
为什么会是这样的结果呢，为什么不能使用非常火热的MV*框架（去TodoMVC发现各种框架吧）呢，他们这么火肯定是有原因的啊，为啥不用，下边就来简单分析下。
需求，需求、需求
重要的事情说三遍！这些MV*框架是能约束代码、提高开发效率，但是不大符合需求啊。路由问题，这个还好，基本的这些框架都会配备路由机制；切换动画，这个不是所有的都支持的，可能会需要第三方支持，当然是可以解决的，最重要的还是SEO问题了。
然后再来分析需求，其实要做出来的产品风格来说可能和一个应用商店性质比较像，有一些导航，能看到详情，有一级一级内容等。这样来看的话，能不能有这样的一种解决方案呢：和各种框架库（zepto.js、requireJS、fastclick）相结合，求取交叉点，各司其职。OK，结局显而易见，就是需要解决三个问题：SEO、路由以及切换动画。
所以这也就是当时的初衷，核心要解决的三个问题，谨记：SEO、路由以及切换动画。
解决方案
一个问题一个问题来看，最基础的路由问题，这个很好解决了，这样的只做路由的框架也有不少，而且像Backbone这样的框架中也内置了相应的模块，还可以单独拿出来使用。
下一个就是切换动画问题，如果说要有页面切换动画，其实就是需要在路由发生改变的时候去切换对应的页面内容（至于内容怎么得到，可以后端直接返回好拼接好的HTML片段，也可以是前端请求数据+模板引擎渲染），然后利用CSS的动画完成切换动画效果。
最后一个重头戏，SEO问题，约定一个结构，后端输出，前端在初始化的时候去判断，如果存在对应的结构，就认为是当前的路由通过渲染模板得到的页面结构就是如此，然后直接初始化一些东西就好。然后在路由发生改变的时候，此时由前端的路由去控制得到渲染对应的页面内容，然后由CSS动画去做切换效果。其实也就是必须约定，前后端路由系统的统一。
当然，解决了三个问题，还有很多细节需要做的，这里列下我认为比较重要的三点：
-
移动端内存问题，一定做好内存控制，也就是要有对整个的生命周期的管理。
-
内存控制的同时，也要缓存页面上部分内容，提高用户体验。
-
开发模式还是以组件式开发为基础、为目标。
结果
一直觉得像angular.js那种路由使用方式很好，配置一些路由规则，然后由对应的回调函数，依次实现不同路由下分模块去控制，各司其职，更容易模块化。所以整体风格也是如此，只是由于需要自己通过框架组合的方式来支撑起整个项目的运行，需要开发者需要自己处理一些释放内存的事情，也就是暴露了destroy接口来销毁一些事件，回收一些内存，依次来控制内存，管理各个页面（画面）的生命周期。
这也就形成了最初版本的mobile-router.js。