原來(lái)CSS這樣寫(xiě)是會(huì)讓app崩潰的

今天要說(shuō)的 CSS 代碼真的是讓 app 崩潰了，至于信不信，看圖就知道咯。

故事背景

昨晚在被窩中的我突然收到一封郵件，大概內(nèi)容是說(shuō)因?yàn)?CSS 的問(wèn)題讓 app 掛了。當(dāng)時(shí)在想，怎么樣的 CSS 如此牛逼，居然讓 app 掛了！于是掏出手機(jī)按照郵件中提示的 URL 打開(kāi)看了一下，我只想說(shuō)，這代碼，額，算了，還是不吐槽了，其實(shí)要是我寫(xiě)的話，肯定會(huì)更爛。

雖然是來(lái)自其他部門(mén)的一個(gè)頁(yè)面，但作為公司的一員，怎么能不為公司的產(chǎn)品考慮呢。聽(tīng)起來(lái)感覺(jué)像是在拍馬屁，其實(shí)真的是，因?yàn)槲易詈闷娴氖浅霈F(xiàn) bug 的原因是什么，當(dāng)然，肯定也是關(guān)心產(chǎn)品的啦。

于是第二天一早就到公司開(kāi)始排雷……

大概的過(guò)程

首先我仔細(xì)看了一下代碼，從最初懷疑是 animation 的性能影響低端設(shè)備運(yùn)行開(kāi)始排查。結(jié)果發(fā)現(xiàn)這個(gè)所謂的性能問(wèn)題其實(shí)也并沒(méi)那么厲害，一時(shí)也找不到頭緒，然后源文件又不是在我們自己這邊，只好打開(kāi)花瓶抓 CSS 文件，然后替換后，用刪除法一點(diǎn)點(diǎn)查。

最后在儲(chǔ)大師的提點(diǎn)以及提供的一個(gè) URL 來(lái)看，居然是 rem 導(dǎo)致的。

https://bugs.chromium.org/p/chromium/issues/detail?id=364222

這個(gè)網(wǎng)址大家應(yīng)該都知道，是專門(mén)看 bug 的，當(dāng)然，也可以提 bug 啦。

@-webkit-keyframes crashChrome {        0%{ -webkit-transform: translateX(0rem);}
}
.anim:before{    content: "";    width: 3rem;    height: 3rem;    
    border-radius: 3rem;    
    position: absolute;    
    left:5rem;    
    top: 5rem;        
    background-color: #06839f;        
    -webkit-animation: crashChrome;
}

<div class="anim"></div>

剛開(kāi)始看到這段 CSS 代碼的時(shí)候，我在想啊，這個(gè)好像也沒(méi)什么問(wèn)題啊，不就是通過(guò) :before 這個(gè)偽元素來(lái)做一個(gè) animation動(dòng)畫(huà)效果么，然后使用了 rem 這個(gè)單位量。

反正是百思不得其解。

還是找測(cè)試機(jī)，繼續(xù)刪除那個(gè)有問(wèn)題的頁(yè)面代碼吧。先是用了三星的，發(fā)現(xiàn)沒(méi)問(wèn)題，接著用了小米的，果然奔潰了。看了一下版本，三星的是 Android 4.4.2，小米的是 Android 4.4.4，難道是版本的關(guān)系？

總之，在最開(kāi)始那塊有動(dòng)畫(huà)效果的部分排查了很久都沒(méi)找到問(wèn)題。最后還是回到那個(gè)已經(jīng)報(bào)了 bug 的頁(yè)面上看具體說(shuō)明。

突然想到，這個(gè)頁(yè)面中用了 :before 來(lái)做動(dòng)畫(huà)，莫非我們的這個(gè)頁(yè)面中也有，于是一搜，結(jié)果，真的有！

趕緊我們自己頁(yè)面上的這段代碼拿過(guò)來(lái)做嘗試，終于找到你了。趕緊回郵件告訴對(duì)方……

再次感謝儲(chǔ)大師的提點(diǎn)，讓我有機(jī)會(huì)了解到未曾了解到的一個(gè)問(wèn)題。

簡(jiǎn)單分析

這個(gè) bug 在目前桌面端的設(shè)備中已經(jīng)被處理掉了，按照 bug list 頁(yè)面上說(shuō)的，當(dāng)時(shí)發(fā)現(xiàn)這個(gè) bug 是在

Chrome Version: 34.0.1847.116 (Official Build 260972) m

這個(gè)版本上的，并且各系統(tǒng)都有。然而，現(xiàn)在的 Chrome 都已經(jīng)是 50 以上的版本了，所以桌面端完全不需要去擔(dān)心了。

但是這次既然是在移動(dòng)端上遇見(jiàn)了，而且是 Android 4.4.4 這個(gè)版本，雖然是在小米3 中發(fā)現(xiàn)，但 Android 4.4.4 這個(gè)版本應(yīng)該還算是比較普遍的，難道真的會(huì)是這個(gè)問(wèn)題。

獲取一下這個(gè) webview 的 UA 信息，看到其中有一個(gè)是 Chrome/33.0.0.0 Mobile Safari，于是我想啊，可能應(yīng)該就是這個(gè) webview 的關(guān)系了，畢竟我在小米3 這臺(tái)測(cè)試機(jī)上的各個(gè)瀏覽器里都看了一遍，沒(méi)發(fā)現(xiàn)問(wèn)題。

嘗試了解

現(xiàn)在是知道 rem 和 animation 一起的時(shí)候回出現(xiàn)這個(gè) bug，但是在其他元素中并沒(méi)有問(wèn)題啊。出于自己的好奇心，于是又換了幾個(gè)方式來(lái)嘗試。

animation 換 transition

把 animation 換成 transition，并且也是通過(guò)改變有 rem 的屬性，結(jié)果發(fā)現(xiàn)這個(gè)想法的結(jié)果是，沒(méi)有任何問(wèn)題。

放棄這個(gè)想法……

:before 是偽元素

想到 :before 是偽元素，那么對(duì)于偽元素的選擇符還有幾個(gè)，都嘗試一下看看。

注：這個(gè)截圖是曾經(jīng)個(gè)人整理的有關(guān) CSS 選擇符的一張圖

結(jié)果發(fā)現(xiàn)這四個(gè)偽元素選擇符全部都會(huì)讓頁(yè)面崩潰……

小結(jié)一下

瀏覽器（webview）的底層渲染機(jī)制我不懂，但就目前來(lái)看，可能應(yīng)該就是因?yàn)?nbsp;Chrome/33.0.0.0 Mobile Safari 這個(gè)版本的問(wèn)題，如果在偽元素中使用 animation，并且改變了其中的 rem 的值就會(huì)出現(xiàn)頁(yè)面崩潰的問(wèn)題。

所以，可能應(yīng)該就是這樣：

• 使用了 :before 等偽元素中的其中一個(gè)來(lái)做 animation 動(dòng)畫(huà)；

• 在 animation 動(dòng)畫(huà)改變了其中的某個(gè) rem 的值；

在這樣的前提下，又是使用有這個(gè) bug 的版本瀏覽器，那么就會(huì)讓頁(yè)面崩潰。

如果要避免這個(gè) bug 的出現(xiàn)，那么應(yīng)該是：

換一個(gè) webview，高版本的應(yīng)該會(huì)好一些；

在偽元素中使用 animation 動(dòng)畫(huà)時(shí)，不用 rem 單位；

不過(guò)好像現(xiàn)在大家都會(huì)去用 rem 單位，然后也會(huì)去用 animation 做動(dòng)畫(huà)，那這樣好了，不在偽元素上使用者兩樣?xùn)|西咯。

題外話

說(shuō)到在偽元素上使用動(dòng)畫(huà)，我想起了幾年前自己在做國(guó)際網(wǎng)站的時(shí)候，當(dāng)時(shí)好像用的比較多的是 Firefox，然后在往返程的一個(gè)模塊中，就是用了偽元素的方式。

不過(guò)當(dāng)時(shí)我好像使用的是 transition，并且當(dāng)時(shí)主要是考慮 Firefox，所以也沒(méi)遇到什么問(wèn)題。印象中遇到的問(wèn)題就是，好像在某個(gè)瀏覽器中并沒(méi)看到那個(gè) transition 效果，而且這個(gè)只是作為一個(gè)小“亮點(diǎn)”的存在，產(chǎn)品經(jīng)理也沒(méi)砍我。想想也算萬(wàn)幸的……

哦，還有，如果各位已經(jīng)知道了這個(gè) bug，也請(qǐng)不要嘲笑我，我真的是第一次知道，平時(shí)日常中很少這樣去寫(xiě)樣式。-_”