最近用纯html编写html5应用，发现离开引擎来写那些比较cool的UI似乎有一定难度。不过好在目前网络发达，掌握这些技能还是很快的。

但是，事实上使用过cocosjs以及白鹭引擎和layabox的我而言，实现这些非常简单的UI以及实现过程操作还是很快的，不过到了引擎阶段，这里的速度并没有得到提升，相反速度下降了。思考过原因，使用引擎调节UI都是可见即可得，并不会考虑说要一步一步调节UI的位置，这于我们而言，简直是一种煎熬。当然对于手脚快速的人而言，一切都是那么简单和急速！

这种感受，我在5年前深刻体会，使用php和java的区别。php作为一门脚本语言，其编写速度之快，令人昨舌。比起java和其他的脚本语言，速度快了很多。今天我要说的就是Html5了。

对于很多写页面的人而言，似乎编写网页是那么痛苦的事情。当然我在这里并不是说前端的不容易，事实上不论是客户端还是前端，本质上调节UI都是极其困难的，但是自从在引擎领域有了UI工具之后，编写速度之快，让人惊讶，现在早已经习惯了这种方式，所以回归到原始的html5的纯代码编写UI,自然有一定的反思。

那么对于编写web的童鞋而言，很多时候是不是希望我们的web应用可以适配所有的平台呢，其实对于很多开发内部系统的人而言，只要支持简单的pc即可，再高级一点支持移动设备即可，最高级的支持ipad以及其他的各种平板设备。对于开发面向普通用户的产品而言，我们的web app必须满足支持全部的平台了，不论是移动设备还是pc web最好可以做到全部支持。从这一点而言，能够实现的方案有很多。这里稍微讲解一点关于适配的知识。

第一点，我们可以为了适配简单的机型，例如iphone 系列 以及 一般的安卓手机系列；不包括ipad 以及安卓平板。简单地添加标签即可

这样我们的web应用就可以实现苹果手机和安卓手机端的跨平台了。

这种方式简单，不过有效。这里的maximum-scale设置为1.3是有其原因的。

这是通过计算而来的，大多数的设备页面都是以320px为基准的布局，即使到iphone6的高宽比例是375/320 = 1.17，iphone6+的是414/320 = 1.29,所以也就差不多是1.3，当然如果后面出现了比例更高的1.4,1.5,这里的maximum-scale也要变化。不过就效果而言，这种方式的适配并不是最好的，有时候会有一定的偏差，这种偏差在某些特殊的安卓机型上面会表现明显，所以也不是推荐的类型。

第二点，我们可以媒介查询方式。媒介查询的方式，这种方案可以实现各种特殊方式地加载css，例如查询到支持某个条件的，那么我们可以采用加载a.css;如果支持另外的条件，我们可以加载b.css,看起来效果也不错。事实上这种响应式的方案，在几年之前比较流行，毕竟这种方案真的很牛叉，不论是多么奇特的机型，我都可以制作一个UI的css，那么UI自然就可以根据特定的css进行展示了，效果可以说非常好，想法也非常酷。你来新的机型，我就处理新的方式，直到兼容绝大多数机型为止。

不过说句难听的，即使可以支持很多机型，如果为了某个div或者位置的调节，我们兼容了四五套设备，写了四五套css，这四五套css估计也是够呛。为了兼容这么多，得写多少css。在工作中可以使用，但是不建议。

第三点，rem布局。对很多人而言，rem是什么，这是一个问题。这样吧，我们可以这么简单描述。如果我们的页面已经可以自适应了，那么这个自适应可能基于图片也可能基于空白的页面，但是不论怎们思考，我们的这个页面一定是基于放缩式地自适应背景的，自适应于安卓设备，自适应于手机设备，自适应于ipad设备，自适应于平板设备等等，这个自适应简单说就是大小适配到不同的设备大小。那么rem就是某个单位了，通过在页面层获取不同设备的屏幕分辨率和页面大小，然后计算出符合不同平台的一个rem值，这个rem因不同的设备而不同，从而可以适配到不同的设备上去。例如我们设计了绝对位置left:10rem,那么这个针对iphone的就是x1 px,针对ipad就是x2 px 针对华为平板就是x3 px可是我们看到不同的设备上的展现，三个设备绝对位置相对于设备页面的位置基本不变化，这就是rem布局的奥秘。当然rem布局本身就要求我们的背景页面一定要自适应的而不是定死不变化的，如果在这种情况下使用rem那么绝对位置相对设备的页面的位置就会产生变化，因此这个时候的rem意义不大。

如果有需要，可以自己查询lib-flexible，个人表示该库不错。当然我们在这里也要熟悉flex布局，也就是弹性布局。下篇讲说弹性布局。