2015-9-30 用心設計
藍藍設計( www.skdbbs.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供有效的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
如果您想訂閱本博客內容，每天自動發到您的郵箱中， 請點這里
來源：莫貝網
最近火熱的有聲娛樂平臺 APP，企鵝 FM，在8月28日鬼節前夕，聯合《盜墓筆記》推出了“勇敢者的游戲”活動。作為一個 UI 工程師，在這個移動互聯網叱咤風云的時代，每次看到朋友圈中被分享的各種花樣 H5 頁面，總是心癢難耐，也想做有著酷炫動畫和帶感聲效的 H5 呢?；叵氲阶龉砉澔顒禹摰臅r候，接近午夜零點還在調整頁面效果，看著頁面上漸隱漸現的可怕畫面，活生生嚇到了自己，也是蠻難忘的。作為剛剛來到活動頁新手 村的朋友，踩到了一些坑，所以讓我進入正題吧。哦，等一下，請先掃一下二維碼啦~
在拿到視覺稿和需求單之后，我們需要了解整個活動的流程。有的時候，設計師并不會把每個頁面的動畫效果做成視頻，而是用口述的方式和工程師進行溝通。這樣就需要工程師結合活動頁流程和設計稿之后，自己先構思一些動效再去同產品以及設計溝通，這樣交流的效率才會比較高。
動畫新手有的時候會天馬行空想到一些奇怪的效果，可能會不符合整體設計風格，可能會違反現實物理規律，有自己的想法，還要和產品設計確認。比如這個頁面：
一開始是做成了先出現手電筒，再出現光，在我的設想中剛開始手電筒上不會有那層黃綠色的光。后來經設計師提醒：如果完全沒有光源，也應該看不到手電筒。才改成了現在的方案：燈光閃兩下：物理定律什么的，我才記不清了呢T T。
P.S. 做動畫的時候銘記動效原則，基本上動畫的效果不會跑偏。
仔細想想，這個活動頁面并沒有用到什么高深技巧，基本上是用 position 定位和 CSS3 動畫完成的。不過在寫頁面之前，還是有不少擔心的：
zoom 或者 transform: scale(x) 拉伸頁面或者拉伸元素。在實際開發的時候，我一度對這兩個屬性的用法產生混淆，所以作些了研究，稍后會詳細說說這兩個屬性。
perspective 和 perspective-origin 這兩個屬性了，雖然教程和分享都看過不少，但真正寫起來還是有一些摸不著頭腦，各種搜索關于 3D 動畫的解釋之后我認為原理大概是這樣的：
簡
單粗暴地說，請想象你是站在上圖中的紅點位置，你與物體間的距離是 perspective，眼睛的位置是
perspective-origin。好了，現在站定位置，去看這個物體，想象物體投影在某個平面上的效果（這里的平面就是我們的顯示屏），這就是
3D 投影的結果。關于 perspective-origin，可以看看這個demo。
想要重點說一下磁帶的實現，主要牽涉到的圖片資源是下面這幾個：
磁帶被分成了3個部分，磁帶底部，磁帶封面和磁帶。其中封面和磁帶是正視圖，需要使用 3D
旋轉，讓這兩個元素“躺下去”，而且為了保證這三個元素之間不會因為屏幕的縮放，出現錯位的問題，需要保證磁帶封面和磁帶的定位是基于磁帶底部的。其實磁
帶上還有兩片蓋子，不知道大家有沒有注意到。其實這個蓋子是左右對稱且中心對稱的，所以完全可以只用一張圖片完成這樣的效果，用 transform: scale(-1, 1); 和transform: scale(1, -1); 實現。
這
個活動頁面我個人最喜歡的地方就是星星砸下去的動畫，感覺所有的戲份都在它身上。開始的設想只是星星砸下去，感謝在制作過程中，經驗豐富的同事所提的建
議：星星砸下去的時候要有灰塵濺起或者火星四濺的效果。后來和設計商量，最后用了灰塵濺起的效果。不過本來還想做，星星背后的鐵板應該要有震動的效果。由
于時間關系，震動的效果有點不好添加，所以放棄了，這一點感覺有一些遺憾?？赡茼撁嫘率值慕涷灢粔?，很多動畫的效果因為有限的想象力所以不太完善。這個時
候和身邊經驗豐富的同事請教是很有效的方法。同時，一定要多看 B 站拓寬視野才行哦。
頁面布局并不復雜。前文也提到，基本上使用 position: absolute; 來實現的，不過遇到了一些問題就有了以下總結：
上圖是首頁的截圖，頁面加載之后應該可以看到“膽量測試”下面的藍色線條有一個動畫。故事是這樣的，自從 SVG 帝王小啪帶著神器 svgartisan 降臨（對 SVG 有興趣的同學歡迎加群 426886128 一同討論 SVG 技術），做頁面的時候總想加上一點 SVG。然而這個藍色線條上有，所以用 PS 導出 SVG 后還要做二次處理才能還原設計稿
上的效果，而且 SVG
的代碼你懂得，它總是有點長。其實有個簡單粗暴的方法：改變藍色線條的圖片寬度，雖然這個方法從性能上看并不好，但考慮到這個頁面也只有這里發生了重繪，
所以還是用圖片+寬度控制來實現了。不知道大家會不會為了某一種技術而去做某一件事情，但其實完成那件事情才是真正的目的，卻因為那個技術而耽誤了不少進
度，這樣就有點進入了炫技的誤區。
Android
上坑多，不要一次應用太多新技術。比如在魅族上用 flexbox 布局，就要加上 display:
-webkit-box。還有一個教訓就是，頁面果然應該做一個測試一個啊QAQ。因為這個項目是重構和前端并行開發的……把偽元素改成實際 DOM
元素的時候，是懷著一顆對不起前臺的心的。
與UI工程師對
接的前臺同學需要看注釋才知道什么時候要加什么class，想到剛剛開始接需求的時候，從來不寫注釋…真是對不起前臺同學T
T現在我個人的注釋如上圖所示。也看過組里不同同事的注釋風格，大同小異，主體思想就是“在XX時候添加XX
class”這樣，和對接的同學約定好就可以~
我將會在接下來詳細談到前文提到的 zoom 和 transform: scale(x); 問題。
現在不管是活動頁的設計稿還是產品頁的設計稿，逐漸以 375×667 的 iPhone6 為基礎。但是實際生活里，這些頁面是會出現在細細長長的 iPhone5、480px 高度的 iPhone4 還有大屏幕的 iPhone 6+，更不要說在三星小米魅族一加等等等等尺寸都不知道怎么辦才好的 Android 系列上打開會是什么gui。
拿這次的活動頁面設計稿 來說，與用戶產生交互的按鈕在頁面篇底部的位置。有一個前提，為了兼容不同寬度的屏幕，所以頁面是基于 iPhone 6 的 375px 用 zoom 屬性進行縮放，可以看出iPhone 5 和 iPhone 4 的寬度一樣，而且看設計稿，頁面元素是從上到下分布的：
也就是說，使用相同的 zoom 值，滿足了 iPhone5 的頁面效果，但是在 iPhone4 上，按鈕就會偏底，頁面整體感覺也偏底。但是 zoom 值不能隨便更改，否則紅框中的錄音機圖片的左右邊界就會顯示出來。所以要針對 iPhone 4 調整元素的之間的間距，最終的效果大概是這樣的：
可以看得出效果并不是很好，整個頁面非常的擁擠，所以在這個情況下，我覺得用統一 zoom 值來調整有點一棍子打倒了，如果一個個元素微調，那么最好效果會好得多。加上 zoom 會有一定的性能問題，組里的同事有些是 zoom 調整，也有給每個元素加 class 通過 transform: scale() 調整的。重構最神奇的就是，條條大路通羅馬，怎么樣都能達到自己想要的視覺效果，但是中間會因為各種原因，實現的方式不太一樣。
拿到設計稿一開始就先看看這個設計稿的布局，有一些是從頁面頂部到底部都有效果的，這個時候就要考慮在 iPhone4 這樣屏幕不夠高的設備上如何保證頁面完整呈現；或者在不影響交互的情況下，隱藏哪些元素。有的時候頁面上元素比較集中，這個時候就要考慮在 iPhone6+ 這樣的大屏幕設備上，要不要調整間距使得頁面不會太空曠。
要知曉設計稿背后的含義，不是一拿到就開始做了，有些元素其實是要整體考慮的。有些乍一看好像是用 position 定位，分別寫 top 值就好。殊不知，設計師真正要表達的是，作為一個整體，它們在頁面上要絕對居中。沒有 get 到這個 point，兼容的時候就要哭了。
先來看一下 zoom 和 transform:scale 的說明：
Specifies the initial zoom factor for the window or viewing area. This is a magnifying glass type of zoom. Interactively changing the zoom factor from the initial zoom factor does not affect the size of the initial or the actual viewport.
從定義上看 zoom 縮放的是被 zoom 的容器的視口，可以把它想象成放大鏡的效果，這個屬性是可被繼承的，所以我們做設備屏幕兼容的時候，可以在 body 標簽下加一個 div 包裹住頁面上的其他元素，然后在這個 div 上加 zoom，達到的視覺效果就是頁面上其他元素也被縮放了。但是有些元素并不支持 zoom。
A two-dimensional transformation is applied to the coordinate system an element renders in through the ‘transform’ property. This property contains a list of transform functions. The final transformation value for a coordinate system is obtained by converting each function in the list to its corresponding matrix (either defined in this specification or by reference to the SVG specification), then multiplying the matrices.
在說 scale 應該要先看看 transform。transform 屬性應用到元素的過程其實是矩陣變換的過程，在渲染的時候，元素的坐標就會被確定下來，然后和 transform 的屬性值進行矩陣運算得到最終的坐標，不過你會發現，一個絕對定位的元素通過 transform 改變顯示位置后，這個元素的 tbrl 值并不會被更新，且 transform 屬性不可繼承的。
The value of the transform property is a list of applied in the order provided. … specifies a scale operation using the [sx,1] scaling vector, where sx is given as the parameter. … specifies a scale operation using the [1,sy] scaling vector, where sy is given as the parameter.
scale 是 transform 的一個屬性值，這是一個縮放矩陣。當一個元素被定義了 transfrom: scale(x); 后，還是再結合它的 transfrom-origin，才能確定最后的縮放效果。依然是兼容屏幕分辨率的問題，要想 transfrom: scale(x) 達到和 zoom 相似的效果，要記得把 transfrom-origin 設置成 0 0。這么設置的原因是，在文檔流中的元素，是以它的左上角為中心進行 zoom 的，而當元素脫離文檔流時，要使 transform: scale(x) 和 zoom 達到相同的效果，還要具體分析 transform-origin 要如何設置。
大概你也注意到了，在前一句中，我說的是“相似的效果”而不用“一樣的效果”，這是因為使用 scale 的時候可能遇到下面這樣的問題。下圖中左邊為 transform:scale(.85)，右邊為 zoom: .85：
下面這段是外層容器的樣式，背景是定義在 switch-wh 動畫中，通過絕對定位讓瀏覽器自行計算，保證容器大小占滿整個屏幕：
因為 zoom 是作用在 body 下面這個占滿了屏幕空間的容器，所以根據定義以及 zoom 的繼承性，我們可以說在這個頁面上使用 zoom 其實是縮放了整個屏幕（也就是視口），可以想象成在瀏覽器中打開了頁面，然后放大這個頁面的效果：
為什么 scale 會留下右部和底部的迷の白色呢？讓我們回到 transform 的定義中，“applied to the coordinate system an element renders in through the ‘transform’ property”。當元素都進行渲染了，坐標已經確定了，再進行縮放，也就是在原來元素基礎上改變大小。所以 .sf-index 雖然在渲染時四個角的位置分別是(0,0)、(100%,0)、(0,100%)、(100%, 100%)，經過以 (0,0) 為變換中心的 scale，就變成了(0,0)、(85%,0)、(0,85%)、(85%,85%)。我們就會看到頁面右邊出現寬度為15%的一條白邊，以及頁面下方 高度為15%的白邊。
看起來，好像兼容的時候應該用 zoom 呢。嗯看到 scale 之后的結果我就是這么想的。接著就發現 zoom 之后的頁面，文字的顯示不太正常。下圖左邊是被 zoom 的 iPhone4，右邊是沒有被 zoom 的 iPhone6：
由于頁面是被整體縮放了，所以文字也自然出現了縮放，剛好這種好像被砍了一刀的文字效果還蠻適合鬼節的活動頁面，所以我并沒有做處理。正常來說，如果需要做處理就是調整文字的 line-height 和容器的 height，使其不出現遮擋。
正如頁面元素經過 zoom 后，實際的大小會發生改變，圖片的大小也發生了改變，使用雪碧圖就出現了一些問題。雪碧圖是把各種小圖拼合到一張大圖上面，通過 width、height 和 background-position 定位到圖片，看下圖可以發現相鄰圖片的邊界也一起顯示出來了。
審查元素發現，用于顯示圖片的元素尺寸也不對?。?/span>
可以看出這個元素正確的尺寸應該是 198×52，經過 zoom: 1.10 放大后容器反而變小了，后來將 zoom 值調整到 1.104（414/375），圖片的邊界問題算是解決了。
關于圖片沒有正常顯示的問題，我的推斷是，原因在于 zoom 值設定偏小，圖片經過 zoom 后沒有被正確地計算，而圖片的容器又偏大，所以相鄰圖片的邊就被顯示了出來。后來 zoom 值是根據比例設定了，就不會出現這個問題。
最后，zoom 對性能不友好，下面兩個 gif 分別是 zoom 和 transform: scale 引起的重繪：
很明顯，在文檔流中 zoom 加在任意一個元素上都會引起整個頁面的重新渲染，而 transform: scale 只是在當前的元素上重繪。
這樣說來，簡直兩個方法都不能用了嘛…還有沒有什么別的兼容的方法呢？
有的。
像需要大量圖片的頁面，做兼容的時候我們常常擔心的是什么？當然是圖片比例出問題咯，所以也會使用通過偽元素設置 padding-top
的方法，保證圖片比例正常地顯示出來。只是這樣的寫法通常要結合 background-size:cover; 而我們常用的工具 CssGaga
在生成雪碧圖了之后會覆蓋 background-size。目前的這個方案的話……就不合成雪碧圖了。
還有一個方案是使用 media query 結合 rem （或百分比）完成這樣的布局，不過目前 gaga 不支持 background-size 的 rem，所以要采用什么方式合成雪碧圖以及如何生成新的樣式，還需要尋找新的方向。在不需要合成雪碧圖的時候，可以用這兩種方法。