摘要：最近被分配到移動(dòng)端開(kāi)發(fā)組，支持某活動(dòng)的頁(yè)面頁(yè)面制作。這算是我第一次真正接觸移動(dòng)端頁(yè)面制作，下面就談?wù)剛€(gè)人總結(jié)和思考。這無(wú)疑會(huì)增強(qiáng)程序的可維護(hù)性。規(guī)范正如上面討論的，一個(gè)頁(yè)面由多個(gè)組成。的兼容性在安卓及以下是不支持的。

最近被分配到移動(dòng)端開(kāi)發(fā)組，支持某活動(dòng)的頁(yè)面頁(yè)面制作。這算是我第一次真正接觸移動(dòng)端頁(yè)面制作，下面就談?wù)剛€(gè)人總結(jié)和思考。

開(kāi)會(huì)大體講解、討論與排期 -> 交互設(shè)計(jì) -> 視覺(jué)設(shè)計(jì) -> 頁(yè)面頁(yè)面制作 -> 前端開(kāi)發(fā) -> 測(cè)試

每個(gè)步驟環(huán)環(huán)相扣，每個(gè)職位都需要和其前后的人溝通協(xié)調(diào)。

測(cè)試遇到問(wèn)題則會(huì)反饋到相應(yīng)環(huán)節(jié)負(fù)責(zé)人。

當(dāng)然，涉及的職位也不僅于此，還有法務(wù)同事審核內(nèi)容是否符合當(dāng)前法規(guī)等等。

前端開(kāi)發(fā)離不開(kāi)構(gòu)建工具，除了敲代碼，其余都交給構(gòu)建工具（如組件開(kāi)發(fā)、CSS 兼容處理、圖片 Base64、圖片雪碧圖和壓縮處理等）。
在 Athena 中，文件層級(jí)結(jié)構(gòu)如下：項(xiàng)目 project -> 模塊 module（具體每個(gè)活動(dòng)） -> 頁(yè)面 page -> 部件 widget。

舉例： 某項(xiàng)目 -> X、Y 活動(dòng) -> 預(yù)熱頁(yè)和高潮頁(yè) -> 頭部、彈框等 widget。一般文件目錄如下：

Xproject
    - gb (公共部分，如初始化樣式和一些常用 widget)
    - X活動(dòng)
        - page
            - 預(yù)熱頁(yè)
            - 高潮頁(yè)
        - widget
            - header
            - footer
            - diglog
    - Y 活動(dòng)
    - ...

剛開(kāi)始接觸時(shí)，存在這樣的一個(gè)疑惑：什么是 widget，一個(gè)不可復(fù)用的頁(yè)面頭部可以作為 widget 嗎？
答：我最初的想法是：“錯(cuò)誤地把 widget 當(dāng)成 component，component 一直被強(qiáng)調(diào)的 特性之一是可復(fù)用性。對(duì)于不可復(fù)用的部分就不應(yīng)該抽出為一個(gè)widget了？”其實(shí)對(duì)于一個(gè)相對(duì)獨(dú)立的功能，我們就可把它抽出來(lái)。這無(wú)疑會(huì)增強(qiáng)程序的可維護(hù)性。

對(duì)于一個(gè)項(xiàng)目，一般一個(gè)模塊由一個(gè)人負(fù)責(zé)。但考慮到每個(gè)模塊間可能存在（或未來(lái)存在）可復(fù)用的 widget，需要規(guī)范命名以形成命名空間，防止沖突（具體會(huì)在下面的規(guī)范-命名中闡述）。

Component 與 Widget 的區(qū)別   
Component 是更加廣義抽象的概念，而Widget是更加具體現(xiàn)實(shí)的概念。所以Component的范圍要比Widget大得多，通常 Component 是由多個(gè) Widget 組成。

舉個(gè)例子，可能不是很恰當(dāng)，希望幫助你的理解，比如家是由床，柜子等多個(gè) Component 組成，柜子是由多個(gè)抽屜 Widget 組成的。
而 Component 和 Widget 的目的都是為了模塊化開(kāi)發(fā)。

其實(shí)，在這里并沒(méi)有對(duì) widget 和 component 做這么細(xì)的區(qū)分。

正如上面討論的，一個(gè)頁(yè)面由多個(gè) widget 組成。因此，一個(gè)頁(yè)面看起來(lái)如下：

  

    
    <%= widget.load("app_market_main_header") %>
    
    
    <%= widget.load("app_market_answer") %>
    
    
    <%= widget.load("app_market_coupons") %>
    
    
    <%= widget.load("app_market_camp") %>
    
    
    <%= widget.load("app_market_collocation") %>
    
    
    <%= widget.load("app_market_dialog") %>
    
  

widget 一般存在可復(fù)用性。但如何控制細(xì)粒度呢？分得越細(xì)代碼就越簡(jiǎn)潔，但工作量和維護(hù)難度可能會(huì)上升，因此需要權(quán)衡你當(dāng)時(shí)的情況。

由于一個(gè)項(xiàng)目中，一個(gè)模塊由某一個(gè)人負(fù)責(zé)，但模塊之間的 widget 存在或未來(lái)存在可復(fù)用的可能（而且開(kāi)發(fā)可能會(huì)為你的頁(yè)面添加已有的組件，如頁(yè)面會(huì)嵌在某 APP 內(nèi)，該 APP 已有現(xiàn)成的一些提示框）。因此，需要命名空間將其它們進(jìn)行區(qū)分以防止沖突。由于 CSS 不存在命名空間，因此只能通過(guò)類(lèi)似 BEM 的方式（具體根據(jù)團(tuán)隊(duì)的規(guī)范），如：app_market_header、app_market_list_item。app_market 是模塊（即某個(gè)活動(dòng)）的標(biāo)識(shí)，在該項(xiàng)目下，它是唯一的。

另外，還有一點(diǎn)：類(lèi)名是否要按照 html 層級(jí)關(guān)系層層添加呢？如：

div.app_market_header
    div.app_market_header_icon
    div.app_market_header_**

對(duì)于 app_market_header_icon，盡管在 header 中，但 icon 并不只屬于 header，而屬于整個(gè)模塊（活動(dòng)），那么我們就可以改為 app_market_icon。

老司機(jī) Code review 后，講了以下內(nèi)容：
反面教材：

  

  

    

      

      

      去圍觀
    

存在的問(wèn)題是：嵌套層級(jí)越深，類(lèi)名就越長(zhǎng)。

較好的解決方案：

  

  

    

      
***
      
***
      去圍觀***
    

這是基于『姓名』原理進(jìn)行優(yōu)化的，舉例：app_market_answer_item 是姓名（庫(kù)日天），那么它的子元素只需繼承它的『姓』（庫(kù)姆斯） app_market_answer_itop，而不是它的姓名（庫(kù)日天姆斯） app_market_answer_item_top。每當(dāng)類(lèi)名達(dá)到三到四個(gè)單詞長(zhǎng)時(shí)，就要考慮簡(jiǎn)化名字。

進(jìn)一步優(yōu)化，app_market 可以看成是『復(fù)姓』，有時(shí)為了書(shū)寫(xiě)便利，可以以?xún)蓚€(gè)單詞的首字母結(jié)合形成一個(gè)新的『新姓』- 『am』。當(dāng)然，追求便利的副作用是犧牲了代碼的可讀性。如果你負(fù)責(zé)的項(xiàng)目或頁(yè)面沒(méi)有太大的二次維護(hù)或者交叉維護(hù)的可能性，推薦做此簡(jiǎn)化。

BTW：此簡(jiǎn)化后的『姓』可以在代碼中稍加注釋說(shuō)明，如下代碼所示：

  

  

    

      

      

      去圍觀
    

    ...

至少加一個(gè)類(lèi)名，任何時(shí)候都盡量要『針對(duì)類(lèi)名書(shū)寫(xiě)樣式，而不是針對(duì)元素書(shū)寫(xiě)樣式』，除非你能預(yù)判元素是末級(jí)元素。
因此對(duì)于以下 CSS：

.app_market_coupons > div {
    ...
}

可優(yōu)化成：

.app_market_coupons > .xxx {
    ...
}

移動(dòng)端采用 rem 布局方式。通過(guò)動(dòng)態(tài)修改 html 的 font-size 實(shí)現(xiàn)自適應(yīng)。

REM 布局有兩種實(shí)現(xiàn)方式：CSS 媒介查詢(xún)和 JavaScript 動(dòng)態(tài)修改。由于 JavaScript 更為靈活，因此現(xiàn)在更多地采用此方式。

JavaScript

凹凸的實(shí)現(xiàn)方式是：在 head 標(biāo)簽?zāi)┘尤胍韵麓a

從以上代碼可得出以下信息：

以 iPhone 6 為基準(zhǔn)，iPhone 6 的縮放比 zoom 為 1

由于只針對(duì)移動(dòng)端，因此最大寬度為768（恰好等于 iPad 的豎屏寬度）

通過(guò) document.documentElement.clientWidth 獲取視口寬度

resize 事件主要考慮橫豎屏切換和你在PC上調(diào)試時(shí)?

zoom 系數(shù)是 20。系數(shù)決定了在寬度 375 的 iPhone6 下，1 rem 的值是多少 px（20px）。當(dāng)然如果想過(guò)渡到 vw，可以將 zoom 系數(shù)設(shè)置為 3.75，那么 100rem 就是 375px 了

有人說(shuō) rem 布局是 vw 和 vh 的替換方案，當(dāng) vw 和 vh 成熟時(shí)，兩者可能會(huì)各司其職吧。

vw 的兼容性：在安卓 4.3 及以下是不支持的。

哪些地方要用

由于 rem 布局是相對(duì)于視口寬度，因此任何需要根據(jù)屏幕大小進(jìn)行變化的元素（width、height、position 等）都可以用 rem 單位。

但 rem 也有它的缺點(diǎn)——不精細(xì)（在下一節(jié)闡述），其實(shí)這涉及到了瀏覽器渲染引擎的處理。因此，對(duì)于需要精細(xì)處理的地方（如通過(guò) CSS 實(shí)現(xiàn)的 icon），可以用 px 等絕對(duì)單位，然后再通過(guò) transform: scale() 方法等比縮放。

字體

那 font-size 是否也要用 rem 單位呢？ 這也是我曾經(jīng)糾結(jié)的地方。如果不等比縮放，對(duì)不起設(shè)計(jì)師，而且對(duì)于小屏幕，一些元素內(nèi)的字體會(huì)換行或溢出。當(dāng)然這可以通過(guò) CSS3 媒介查詢(xún)解決這種狀況。

字體不采用 rem 的好處是：在大屏手機(jī)下，能顯示更多字體。

看到 網(wǎng)易新聞 和 聚劃算 的字體大小都采用 rem 單位，我就不糾結(jié)了。當(dāng)然，也有其它網(wǎng)站是采用絕對(duì)單位的，兩者沒(méi)有絕對(duì)的對(duì)與錯(cuò)，取決于你的實(shí)際情況。

小數(shù)點(diǎn)（不精細(xì)，有間隙）

由于 rem 布局是基于某一設(shè)備實(shí)現(xiàn)的（目前一般采用 iPhone6），對(duì)于 375 倍數(shù)寬的設(shè)備無(wú)疑會(huì)擁有最佳的顯示效果。而對(duì)于非 375 倍數(shù)寬的設(shè)備，zoom 就可能是擁有除不盡的小數(shù)，根元素的字體大小也相應(yīng)會(huì)有小數(shù)。而瀏覽器對(duì)小數(shù)的處理方式不一致，導(dǎo)致該居中的地方?jīng)]完全居中，但你又不能為此設(shè)置特定樣式（如 margin-top: *px;），因?yàn)闉g覽器多如牛毛，這個(gè)瀏覽器微調(diào)居中了，而原本居中的瀏覽器變得不居中了。

對(duì)于圖標(biāo) icon，rem 的不精細(xì)導(dǎo)致通過(guò)多個(gè)元素（偽元素）組合而成的 icon 會(huì)形成錯(cuò)位/偏差。因此，在這種情況下，需要權(quán)衡是否需要使用 CSS 實(shí)現(xiàn)了。

SASS 無(wú)疑增強(qiáng)了原本聲明式的 CSS，為 CSS 注入了可編程等能力。在這次項(xiàng)目，算是我第一次使用 SASS，由于構(gòu)建工具和基礎(chǔ)庫(kù)的完善，只需通過(guò)查看/模仿已有項(xiàng)目的 SASS 用法，就能快速上手。后續(xù)還是要系統(tǒng)地學(xué)習(xí)，以更合理地使用 SASS。

使用 SASS 的最大問(wèn)題是：層級(jí)嵌套過(guò)深，這也是對(duì) SASS 理解不深入的原因。可以關(guān)注一下轉(zhuǎn)譯后的 CSS。

這次項(xiàng)目的 APP 采用手機(jī)自帶瀏覽器內(nèi)核，而這些瀏覽器內(nèi)核依賴(lài)于系統(tǒng)版本等因素。另外，國(guó)產(chǎn)機(jī)也會(huì)對(duì)這些內(nèi)核進(jìn)行定制和修改。特別是華為、OPPO。

下面列出我所遇到的兼容性問(wèn)題（不列具體機(jī)型，因?yàn)檫@些兼容性處理終會(huì)過(guò)時(shí)，不必死記硬背，遇到了能解決就好（要求基礎(chǔ)扎實(shí)））：

flexbox：在構(gòu)建工具處理下（實(shí)現(xiàn)了新舊語(yǔ)法）可以大膽用，但個(gè)別設(shè)備不支持 flex-wrap: wrap。因此對(duì)于想使用 flex-wrap 實(shí)現(xiàn)自動(dòng)分行的情況，建議使用其他實(shí)現(xiàn)。如果個(gè)數(shù)固定（如 N 行，每行 M 個(gè)），則可使用 N 個(gè) flexbox（這樣就可以使用 flexbox 的特性了）。flexbox 的其他屬性也有支持不好的情況，可以通過(guò)顯式聲明 display、overflow、width、height 等方法解決。

background-size：需要多帶帶寫(xiě)，否則在 安卓 4.3 及以下，IOS 6.1及以下不兼容。

漸變：線(xiàn)性漸變大膽使用，徑向漸變有兼容性問(wèn)題。但是不建議對(duì)整體背景使用，會(huì)有性能問(wèn)題（可簡(jiǎn)單地通過(guò) 1px 高的圖片替代，注意，不要 background-size: 100% auto; 應(yīng)該采用 background-size: 100% 1px; 因?yàn)橛行g覽器（視口寬度較小）會(huì)忽略小數(shù)點(diǎn)【auto = img.Height * (screen.Width/img.Width)】，導(dǎo)致圖片未顯示）。另外，需要注意的是：透明的色標(biāo)在iOS 默認(rèn)是黑色的，即 transparent 等于 rgba(0,0,0,0)。因此即使是完全透明的色標(biāo)，也要指定顏色。否則后果如下：

classlist.remove(String[, String])，傳遞多個(gè)參數(shù)時(shí)，會(huì)有不兼容的情況。建議每次寫(xiě)一個(gè)。add (String[, String])同理。

根節(jié)點(diǎn) html font-size 渲染錯(cuò)誤：在華為、魅族的某設(shè)備上（手Q），會(huì)出現(xiàn)一個(gè)非常奇葩的渲染 Bug，同一個(gè)網(wǎng)頁(yè)，“掃一掃”打開(kāi) html 的 font-size 正常，直接點(diǎn)擊鏈接會(huì)出現(xiàn)渲染出來(lái)的 html font-size 會(huì)比設(shè)置得值大（如：設(shè)置25.8，渲染出來(lái)是 29），因此導(dǎo)致整體變大，且布局錯(cuò)亂。
我的方法是：為 html font-size 重新設(shè)置大小：渲染字體大小 - (渲染與正常差值)

function getStyle(ele, style) {
return document.defaultView.getComputedStyle(ele, null)[style]
}
;(function fixFontSize() {
var target = window.o2Zoom * 20
var cur = parseInt(getStyle(document.documentElement, "fontSize"))
while(cur - target >= 1) {
    document.documentElement.style["fontSize"] = target - (cur - target) + "px"
    cur = parseInt(getStyle(document.documentElement, "fontSize"))
}          
})();

有網(wǎng)友提供這個(gè)方法 ，經(jīng)測(cè)試不可行。此方法是針對(duì) UC 瀏覽器的。

上面主要列出了對(duì)使用有影響的兼容性問(wèn)題，有些由于瀏覽器渲染引擎導(dǎo)致的問(wèn)題（不影響使用），若無(wú)法通過(guò) transform、z-index 等解決，也許只能通過(guò) JavaScript 解決或進(jìn)行取舍了。

圖片占位元素：對(duì)于寬高比例固定的坑位（如商品列表項(xiàng)），通過(guò)將圖片放置在占位元素中，可避免圖片加載時(shí)引起的頁(yè)面抖動(dòng)和圖片尺寸不一致而導(dǎo)致的頁(yè)面布局錯(cuò)亂。代碼實(shí)現(xiàn)：

.img_placeholder {
position: relative;
height: 0;
overflow: hidden;
padding-top: placeholder 的高/寬%; // padding-top/bottom: 百分比; 是基于父元素的寬度
img {
    width: 100%;
    height: auto;
    position: absolute;
    left: 0;
    top: 0;
}
}

1px：在 retina 屏幕下，1 CSS像素是用 4 個(gè)物理像素表示，為了在該屏幕下顯示更精細(xì)，通過(guò)為 ::after 應(yīng)用以下代碼（以上邊框?yàn)槔?/p>

div {
position: relative;
&::after {
    content: "";
    position: absolute;
    z-index: 1;
    pointer-events: none;
    background: $borderColor;
    height: 1px;left: 0;right: 0;top: 0;
    @media only screen and (-webkit-min-device-pixel-ratio:2) {
        &{
            -webkit-transform: scaleY(0.5);
            -webkit-transform-origin: 50% 0%;
        }
    }
}
}

根據(jù)元素個(gè)數(shù)應(yīng)用特定樣式：

/* one item */
li:first-child:nth-last-child(1) {
width: 100%;
}
/* two items */
li:first-child:nth-last-child(2),
li:first-child:nth-last-child(2) ~ li {
width: 50%;
}
/* three items */
li:first-child:nth-last-child(3),
li:first-child:nth-last-child(3) ~ li {
width: 33.3333%;
}
/* four items */
li:first-child:nth-last-child(4),
li:first-child:nth-last-child(4) ~ li {
width: 25%;
}

應(yīng)用樣例有：根據(jù)元素個(gè)數(shù)自適應(yīng)標(biāo)簽樣式。

而對(duì)于反方向標(biāo)簽，可先首先對(duì)整體 transform: scale(-1)，然后再對(duì)字體 transform: scale(-1) 恢復(fù)從左向右的方向。效果如下：

卡券：『帶孔且背景是漸變的卡券』在復(fù)雜背景中的實(shí)現(xiàn)。由于背景是復(fù)雜的（非純色），因此孔不能簡(jiǎn)單地通過(guò)覆蓋（與背景同色）產(chǎn)生。這里可以應(yīng)用徑向漸變 background-image: radial-gradient(rem(189/2) 100%, circle, transparent 0, transparent 3px, #fa2c66 3px);，其中 3px 是孔的半徑。另外，卡券的上下部分是線(xiàn)性漸變的，因此可以在上下部分分別通過(guò)偽類(lèi)元素添加 background-image: linear-gradient(to top, #fa2e67 0, #fb5584 100%);，當(dāng)然，要從離外上/下邊界 3px 的地方開(kāi)始。雖然這不能完美地從最邊界開(kāi)始，但效果還是可以的。但由于徑向漸變的兼容性問(wèn)題，我最終還是用圖片替換了這種實(shí)現(xiàn)。?

多行文本的多行padding：讓背景只出現(xiàn)在有文字的地方，可直接設(shè)置 display: inline;，但還會(huì)存在一個(gè)問(wèn)題是：padding 只會(huì)出現(xiàn)在多行文本的首和尾，對(duì)于需要為每行文本的首尾都需要相同的 padding，可以參考這篇文章：《multi-line-padded-text》 。該文章提供了多種實(shí)現(xiàn)方式，根據(jù)具體情況選擇一種即可。另外，對(duì)于每行的間距，可通過(guò)設(shè)置 line-height 和 padding-top/bottom 實(shí)現(xiàn)，其中 line-height 要大于（字體高度+padding-top/bottom）。

最小字體限制：PC上最小字體是 12px、移動(dòng)端最小是 8px，當(dāng)然可通過(guò) transform:scale() 突破限制。

基礎(chǔ)：合理運(yùn)用 CSS 的威力更好地完成對(duì)設(shè)計(jì)稿的重現(xiàn)目的。

溝通：由于分工較細(xì)，只負(fù)責(zé)頁(yè)面制作的同學(xué)，需要與產(chǎn)品和設(shè)計(jì)溝通，以達(dá)到交給開(kāi)發(fā)后更少修改的目的。如哪些地方可跳轉(zhuǎn)、哪些地方最多顯示幾行文字、超出如何處理（直接隱藏/省略號(hào)等）、坑位中的圖片擺放（頂部對(duì)齊/居中等）等等。

代碼上的溝通：HTML 注釋要寫(xiě)好、HTML 與 CSS 代碼要規(guī)范（命名等）清晰。

由于工具的成熟，我不需要考慮構(gòu)建工具的搭建。
由于發(fā)布方式的成熟，頁(yè)面制作和開(kāi)發(fā)能更好地分離，頁(yè)面制作者負(fù)責(zé)輸出 HTML、CSS，開(kāi)發(fā)負(fù)責(zé) copy html 代碼和引入 CSS 頁(yè)面片。CSS 頁(yè)面片由頁(yè)面制作者更新發(fā)布，開(kāi)發(fā)無(wú)需關(guān)心。這達(dá)到了互不干擾、多線(xiàn)程并行的效果。
成熟的基礎(chǔ)設(shè)施讓我們免除了非代碼相關(guān)的煩惱，但這也讓我擔(dān)心：假如有一天我脫離了這些基礎(chǔ)設(shè)施，我該如何保持高效。

CSS 頁(yè)面片

JS 頁(yè)面片

Combo Handler是Yahoo!開(kāi)發(fā)的一個(gè)Apache模塊，它實(shí)現(xiàn)了開(kāi)發(fā)人員簡(jiǎn)單方便地通過(guò)URL來(lái)合并JavaScript和CSS文件，從而大大減少文件請(qǐng)求數(shù)。 http://www.cnblogs.com/zhengy...

這就是我的第一次...? 學(xué)習(xí)很多，完！

以上僅是我個(gè)人完成某項(xiàng)目頁(yè)面制作的思考和總結(jié)，不小心暴露了團(tuán)隊(duì)下限。?