移动端Hybrid应用与响应式

前端是一个很是庞大和复杂的领域。

若是说多年前的前端只是须要学习几个 HTML 标签，看到别的网站用了狂拽酷炫的特效就 copy 下来，稍微懂点 jQuery 作平常使用，再了解几个 Prototype 和 MooTools（貌似都再也不维护了）等高冷脱俗的库作装X用就能显得很“专家”了。那么如今要仍是持这样的想法，就不适合搞前端。

且不说 JavaScript 在与时俱进，更新出了 ES6，增长了茫茫多的特性，用 CSS 也能够作一些简单动画了。当一个新的 JS 库或者框架发布时，它可能在 0.x 的版本就能火起一片天，又或者立刻出现竞争对手，多的是咱们听都没听过的工具。另外一方面，连咱们使用的设备也从 PC 的一统天下慢慢转成了移动端的主场。

响应式与混合应用的概念

收，这篇文章的重点仍是在于如何去考虑作移动端的响应式布局。

响应式（Responsive Web Design）是一个很早就出现的概念，当时人们就预想到 mobile 的占有率会飙升吧。它指的是同一个页面可以适应不一样尺寸的屏幕进行布局。这里说尺寸是由于咱们大部分时间是在关注屏幕大小，而不是它用的是多少比例的屏幕、设备的颜色深度等等，因此其余一些用途就不必说了，实行一下28原则吧（20% 的概念能够解决 80% 的问题）。

而后说 Hybrid 应用，它一样不是一个新词。不少专一于业务而非性能的 APP 都会采用这种方式去开发。它指的是用前端技术（HTML, CSS, JS）配合中间件（好比 cordova）去开发一个移动端应用。由于 WebView 的存在使这些都成为了现实。

它并非什么高深的技术，只要稍微懂点英文单词，根据它官方文档描述的内容，花半天去看就能配出一个 apk 来了。

难的永远不是框架或者工具，而是思考问题的角度和解决问题的方式。

毕竟从 apk 走到产品仍是有很长一段路的。

屏幕尺寸

前端的同窗应该对兼容性是恨透了，那作混合型应用的话就不多会有兼容性问题了，然而换来的倒是另外一个问题——屏幕适配。

移动端屏幕尺寸的碎片化很是严重，小的有 320 * 480，大的有 1920 * 1080，而后你知道手机都支持旋转的吧，因此这些尺寸的宽高对调一下又是一副新面孔。但只要有问题就有解决办法，毕竟市面上那么多页面都显示的好好的，它们是怎么作到的呢？

乔布斯还活着的时候，他坚持认为 3.5 英寸的手机是最符合人体工学的，但咱们知道，iphone 4s 比 iphone 3gs 的像素高。这是由于有个度量单位叫 PPI (Pixels per Inch)，指的是每英寸的长度上有多少像素。

也就是说 320 * 480 的屏幕上一个像素，至关于 640 * 960 的屏幕上的四个像素。若是纯粹按照像素来算的话，显而后者能够在一样大小的屏幕上显示更多内容，这会致使有些内容甚至小到看不清。

缩放比例

咱们但愿对于一样物理大小的屏幕，能有相同的布局，尽管他们的实际像素可能差几倍。因此这里又有一个倍率的概念。以前提到响应式中的尺寸，就宽度来讲的话，有两种，一个是 width，另外一个是 device-width 。前者是实际宽度，好比某手机屏幕的宽是 1080 像素；后者指的是按照倍率缩放以后的宽度，好比这款手机是 3 倍率的，那么 device-width 就是 360 像素了。

不少大屏手机，或者不一样分辨率的手机，通过倍率的换算以后，device-width 是至关统一的。

因此这就是为何咱们会在手机端的页面上设置以下标签：

html<meta name="viewport" content="width=device-width, initial-scale=1">

就是为了让 CSS 在设置大小（盒子宽高、行高、间距、字体大小等）时，按照 device-width 而不是实际像素来计算。

这样子的话，一样的页面，在 1 倍率的 320 * 480 屏幕，和在 3 倍率的 960 * 1280 屏幕上会有如出一辙的布局。

至于如何计算这个缩放比例，很简单，用

javascriptwindow.devicePixelRatio

通常桌面浏览器的 devicePixelRatio 是 1，手机上就会有 1.5, 2, 3 等值，而后与

javascriptscreen.width

结合换算一下就能获得咱们须要适配的屏幕宽度了。

关于响应式布局的几点建议

选择断点

首先须要明确的一点是，咱们是针对屏幕尺寸布局，而不是针对设备布局。

因此，若是用 @media 作判断的话，不须要针对 iphone 几，或者 samsung 多少而无谓增长各类条件，只须要问本身，在 320 像素、360 像素、768 像素等宽度的屏幕中，页面应该作怎样的调整。

各位应该都知道，响应式布局中有一个“断点”的概念，就是说，假设有

css@media (max-width: 768px) {
  /* 针对 768px 宽如下的屏幕 */
}

那么 768px 的宽度（若是在 meta 中设置了 width=device-width，这里的宽度就指的是 device-width）就是一个临界点，小于等于 768px 的屏幕会执行这段 css，而大于 768 px 的屏幕就不会。

可能说屏幕你们会误会，手机端的屏幕宽度就是视口（viewport）宽度，由于它不支持调整窗口大小，而 PC 端的浏览器能够调大小，那屏幕宽度确切地来讲应该是视口宽度了，也就是网页可视区域的宽度。

至于你应该怎样去挑选断点，就须要根据应用场景来决定了。我通常是开了 Firefox 的响应式设计模式，那里预置了不少尺寸，若是用户对象是移动端，那么 360 * 640 就挺常见的。若是不知道应该怎么选的话，能够尝试用一下。

利用 GPU 减小 DOM 操做

既然是作响应式，那么不少兼容性问题都不须要考虑了，毕竟只有 IE 9+ 才支持 @media 指令，那手机端就更不用说了。

CSS 3中新增了 transform 和 transition 这两个和动画相关的属性。以往若是要实现将一个方框从 100 * 100 放大到 200 * 200，可能须要用 JS 去定时改变 style 中的 width 和 height 属性，后果是每次 style 的改变都会引起 DOM 重绘。用 transition 能够这么来作：

css.box {
  width: 100px;
  height: 100px;
  transition: all ease-in .3s;
}

.box.active {
  width: 200px;
  height: 200px;
}

须要放大的时候，经过 JS 给 .box 加上 active 类就能够了，GPU 会帮你完成过渡效果。固然，深刻研究的话还有不少知识能够讨论，只不过我想引出的就是，能用 CSS 完成的效果就不要用 JS 去作，各司其职。

从另外一个角度谈性能

性能，常常看博客的同窗可能都知道：压缩 CSS 和 JS，作 sprite 图，将图片（要优化的话，图片每每是重头）部署到静态资源服务器，用 CDN，等等。

可是那么多条条框框下，咱们能够作到什么？对于不少前端工程师来讲，这些事情是不须要本身去作的，公司中天然有专门的构建工具帮你部署。在学校中的同窗，历来不会考虑这些方面，甚至没有专门作前端的，就像本文开头所说的，从别的网站上挪几段样式表过来。

而后，咱们比较两款产品，搜狗输入法和QQ输入法（好吧，虽然跟前端没太大关系）。若是尝试过各类输入法的话，你会发现搜狗输入法的启动速度很慢。我无数次卸载过，换成必应输入法、百度输入法、QQ输入法……但他们的皮肤都没搜狗作的好，因而又可耻地装了回来。

因此我以为比性能更重要的产品特点。可能作前端的不会去多考虑产品相关的领域，但具体问题具体分析，不要为了刻意去提升性能而花不少工时在优化上。计算机界不是有句话颇有名么：

过早的优化是万恶之源。

并非说不须要提升性能了，而是说，搞清楚何时该作什么事情。

却是有些优化在编码的时候就能作到的，就好比以前所说的利用 CSS 动画而非 JS 去模拟。在用高级的 CSS 属性时，想想代价，能用低级的属性就用低级的。意思就是说，用 flex 能够实现任何布局，但它的计算代价很是大，因此不到万不得已就不用。

若是能保持一种代码整洁的强迫感，那在优化这条路上就会走的很顺畅吧。

（小结放到文章开头了……）