我们知道移动开发上面有个设备像素比：window.devicePixelRatio，现在在开发页面的时候，一定会在head中添加个viewport的meta类似下面的代码：
<meta name="viewport" content="width=device-width,initial-scale=1,minimum-scale=1,maximum-scale=1,user-scalable=no">
但是随着手机屏幕越来越大，于是页面会遇见下面的问题，手机屏幕越大，右边留白越多，字体越小也不清晰，影响体验：
rem是以document.documentElement（即<html>标签）的font-size为基准的，举例说明：
为了切图方便，我们手百使用了Rem切图，首先类似淘宝的flexible方案，会在页面head中引入一个flexible.js。
拖了一年多的文章，终于开始慢慢补上了。。。上周末整理了下hexo的模板，本周末写了2015年的第一篇文章。
从14年开始，手机百度就开始支持localstorage的细粒度缓存，配合inline渲染模式使用，在2G慢速网站将页面的js和css嵌入到script和style标签，然后将源码存到localstorage，第二次访问的时候从localstorage读取，提高页面访问速度。
传统的localstorage缓存，流程图如下：
最大的缺点是：需要页面渲染之后，读取localstorage缓存内容，然后二次拉取没有缓存或需要更新的资源。
本文将围绕我半年来在移动前端工程化做的一些工作做的总结，主要从 localstorage缓存和版本号管理 ， 模块化 ， 静态资源渲染方式 三个方面总结手机百度前端一年内沉淀的解决方案，希望对大家移动开发有所帮助。
可能因为之前项目节奏紧，人力不足原因，一部分phper承担了前端的工作，于是暴漏了一些问题。
从第一次在厂子写代码开始，就被前辈告诉移动页面，所以的静态资源都要内嵌，即写在script和style内，这样的好处是，网络情况不好的时候，减少http请求。因为2G等网络不稳定的情况下，多开一个http请求，对手机资源消耗是巨大的，比如我们在手机信号不好的地方，访问网络，耗电量会急剧增高。
但是随着3G，甚至4G的普及，实际统计显示，手机百度上2G用户不到30%，所以上面提到的这种一刀切的方案是不妥的。
第二个问题是没有规范和模块化的问题。大家写码都是 意识流 ，除了都是用zepto.js之外，没有沉淀下模块。碰到以前写过的代码，都是ctrl+c + ctrl+v。这种粗放的方式，虽然可以暂时解决问题，但是当出现之前的一段代码不能满足需求的时候（比如新版app发布，之前的代码需要做兼容和升级），需要遍历所有的代码，挨个修改，麻烦！