移動端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 能夠實現任何佈局，但它的計算代價很是大，因此不到萬不得已就不用。

若是能保持一種代碼整潔的強迫感，那在優化這條路上就會走的很順暢吧。

（小結放到文章開頭了……）