我们知道移动开发上面有个设备像素比：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发布，之前的代码需要做兼容和升级），需要遍历所有的代码，挨个修改，麻烦！
在iOS中，需要调起一个app可以使用scheme协议，这是iOS原生支持的，并且因为iOS系统中都不能使用自己的浏览器内核，所以所有的浏览器都支持，这跟android生态不一样，android是可以自己搞内核的，但是iOS不行。
在iOS中提供了两种在浏览器中打开APP的方法：Smart App Banner和scheme协议。
即通过一个meta 标签，在标签上带上app的信息，和打开后的行为，例如：app-id之类的，代码形如：
<meta name="apple-itunes-app" content="app-id=myAppStoreID, affiliate-data=myAffiliateData, app-argument=myURL">
今天Smart APP Banner不是我们的主角，我们说的是scheme
scheme类似自定义url协议，我们可以通过自定义的协议来打开自己的应用，形如：
myapplink://
# 例如 facebook的
fb://
# itunes的
itms-apps://
# 还有短信也是类似的
sms://
如果要打开一个app，最简单的方式是通过一个链接，如我们在html中这样写：
<a href="myapplink://">打开我的app</a>
当用户点击链接的时候就可以打开对应的app。
但是实际中我们更多的情况是绑定事件，比如做个弹层啥的，不能一味的用a标签啊，所以可以通过两种方式来解决：location.href和iframe。
location.href，简单，但是容易出现问题，比如没有安装可能会跳转啦。iframe，比较复杂，需要创建一个iframe，然后把scheme扔给srciframe的方式是开发中常用的，但是他也有一些问题：
所以现在的问题是：如何知道iframe已经打开了某个app，即解决iframe打开app回调