文章詳情頁(yè)

詳解盒子端CSS動(dòng)畫性能提升

瀏覽：294日期：2022-06-02 16:25:29

1.精簡(jiǎn) DOM ，合理布局
2.使用 transform 代替 left、top，減少使用耗性能樣式
3.控制頻繁動(dòng)畫的層級(jí)關(guān)系
4. 使用 will-change 可以在元素屬性真正發(fā)生變化之前提前做好對(duì)應(yīng)準(zhǔn)備
5. 使用 dev-tool 時(shí)間線 timeline 觀察，找出導(dǎo)致高耗時(shí)、掉幀的關(guān)鍵操作

總結(jié)一下

流暢動(dòng)畫的標(biāo)準(zhǔn)

理論上說(shuō)，F(xiàn)PS 越高，動(dòng)畫會(huì)越流暢，目前大多數(shù)設(shè)備的屏幕刷新率為 60 次/秒，所以通常來(lái)講 FPS 為 60frame/s 時(shí)動(dòng)畫效果最好，也就是每幀的消耗時(shí)間為 16.67ms。

直觀感受，不同幀率的體驗(yàn)

幀率能夠達(dá)到 50 ～ 60 FPS 的動(dòng)畫將會(huì)相當(dāng)流暢，讓人倍感舒適；
幀率在 30 ～ 50 FPS 之間的動(dòng)畫，因各人敏感程度不同，舒適度因人而異；
幀率在 30 FPS 以下的動(dòng)畫，讓人感覺(jué)到明顯的卡頓和不適感；
幀率波動(dòng)很大的動(dòng)畫，亦會(huì)使人感覺(jué)到卡頓。

盒子端動(dòng)畫優(yōu)化

在騰訊視頻客廳盒子端，Web 動(dòng)畫未進(jìn)行優(yōu)化之前，一些復(fù)雜動(dòng)畫的幀率僅有 10 ~ 30 FPS，卡頓感非常明顯，帶來(lái)很不好的用戶體驗(yàn)。

而進(jìn)行優(yōu)化之后，能將 10 ~ 30 FPS的動(dòng)畫優(yōu)化至 30 ~ 60 FPS，雖然不算優(yōu)化到最完美，但是當(dāng)前盒子硬件的條件下，已經(jīng)算是非常大的進(jìn)步。

盒子端 Web 動(dòng)畫性能比較

首先先給出在盒子端不同類型的Web 動(dòng)畫的性能比較。經(jīng)過(guò)對(duì)比，在盒子端 CSS 動(dòng)畫的性能要優(yōu)于 Javascript 動(dòng)畫，而在 CSS 動(dòng)畫里，使用 GPU 硬件加速的動(dòng)畫性能要優(yōu)于不使用硬件加速的性能。

所以在盒子端，實(shí)現(xiàn)一個(gè) Web 動(dòng)畫，優(yōu)先級(jí)是：

GPU 硬件加速 CSS 動(dòng)畫 > 非硬件加速 CSS 動(dòng)畫 > Javascript 動(dòng)畫

動(dòng)畫性能上報(bào)分析

要有優(yōu)化，就必須得有數(shù)據(jù)做為支撐。對(duì)比優(yōu)化前后是否有提升。而對(duì)于動(dòng)畫而言，衡量一個(gè)動(dòng)畫的標(biāo)準(zhǔn)也就是 FPS 值。

所以現(xiàn)在的關(guān)鍵是如何計(jì)算出每個(gè)動(dòng)畫運(yùn)行時(shí)的幀率，這里我使用的是requestAnimationFrame這個(gè)函數(shù)近似的得到動(dòng)畫運(yùn)行時(shí)的幀率。

考慮到盒子都是安卓系統(tǒng)，且大多版本較低且硬件性能堪憂，導(dǎo)致一是許多高級(jí) API 無(wú)法使用，二是這里只是近似得到動(dòng)畫幀率

原理是，正常而言requestAnimationFrame這個(gè)方法在一秒內(nèi)會(huì)執(zhí)行 60 次，也就是不掉幀的情況下。假設(shè)動(dòng)畫在時(shí)間 A 開(kāi)始執(zhí)行，在時(shí)間 B 結(jié)束，耗時(shí) x ms。而中間requestAnimationFrame一共執(zhí)行了 n 次，則此段動(dòng)畫的幀率大致為：n / (B - A)。

核心代碼如下，能近似計(jì)算每秒頁(yè)面幀率，以及我們額外記錄一個(gè)allFrameCount，用于記錄 rAF 的執(zhí)行次數(shù)，用于計(jì)算每次動(dòng)畫的幀率：

var rAF = function () {    return (window.requestAnimationFrame ||window.webkitRequestAnimationFrame ||function (callback) {    window.setTimeout(callback, 1000 / 60);}    );}(); var frame = 0;var allFrameCount = 0;var lastTime = Date.now();var lastFameTime = Date.now(); var loop = function () {    var now = Date.now();    var fs = (now - lastFameTime);    var fps = Math.round(1000 / fs);     lastFameTime = now;    // 不置 0，在動(dòng)畫的開(kāi)頭及結(jié)尾記錄此值的差值算出 FPS    allFrameCount++;    frame++;     if (now > 1000 + lastTime) {var fps = Math.round((frame * 1000) / (now - lastTime));// console.log("fps", fps); 每秒 FPSframe = 0;lastTime = now;    };     rAF(loop);}

研究結(jié)論

所以，我們的目標(biāo)就是在使用 GPU 硬件加速的基礎(chǔ)之上，更深入的去優(yōu)化 CSS 動(dòng)畫，先給出最后的一個(gè)優(yōu)化步驟方案：

1.精簡(jiǎn) DOM ，合理布局

2.使用 transform 代替 left、top，減少使用耗性能樣式

3.控制頻繁動(dòng)畫的層級(jí)關(guān)系

4.考慮使用 will-change

5.使用 dev-tool 時(shí)間線 timeline 觀察，找出導(dǎo)致高耗時(shí)、掉幀的關(guān)鍵操作

下文會(huì)有每一步驟的具體分析解釋。

Web 每一幀的渲染

要想達(dá)到 60 FPS，每幀的預(yù)算時(shí)間僅比 16 毫秒多一點(diǎn) (1 秒/ 60 = 16.67 毫秒)。但實(shí)際上，瀏覽器有整理工作要做，因此您的所有工作需要盡量在 10 毫秒內(nèi)完成。

而每一幀，如果有必要，我們能控制的部分，也是像素至屏幕管道中的關(guān)鍵步驟如下：

完整的像素管道JS / CSS > 樣式 > 布局 > 繪制 > 合成：

1.JavaScript。一般來(lái)說(shuō)，我們會(huì)使用 JavaScript 來(lái)實(shí)現(xiàn)一些視覺(jué)變化的效果。比如用 jQuery 的 animate 函數(shù)做一個(gè)動(dòng)畫、對(duì)一個(gè)數(shù)據(jù)集進(jìn)行排序或者往頁(yè)面里添加一些 DOM 元素等。當(dāng)然，除了 JavaScript，還有其他一些常用方法也可以實(shí)現(xiàn)視覺(jué)變化效果，比如：CSS Animations、Transitions 和 Web Animation API。

2.樣式計(jì)算。此過(guò)程是根據(jù)匹配選擇器（例如 .headline 或 .nav > .nav__item）計(jì)算出哪些元素應(yīng)用哪些 CSS 3. 規(guī)則的過(guò)程。從中知道規(guī)則之后，將應(yīng)用規(guī)則并計(jì)算每個(gè)元素的最終樣式。

3.布局。在知道對(duì)一個(gè)元素應(yīng)用哪些規(guī)則之后，瀏覽器即可開(kāi)始計(jì)算它要占據(jù)的空間大小及其在屏幕的位置。網(wǎng)頁(yè)的布局模式意味著一個(gè)元素可能影響其他元素，例如 <body> 元素的寬度一般會(huì)影響其子元素的寬度以及樹(shù)中各處的節(jié)點(diǎn)，因此對(duì)于瀏覽器來(lái)說(shuō)，布局過(guò)程是經(jīng)常發(fā)生的。

4.繪制。繪制是填充像素的過(guò)程。它涉及繪出文本、顏色、圖像、邊框和陰影，基本上包括元素的每個(gè)可視部分。繪制一般是在多個(gè)表面（通常稱為層）上完成的。

5.合成。由于頁(yè)面的各部分可能被繪制到多層，由此它們需要按正確順序繪制到屏幕上，以便正確渲染頁(yè)面。對(duì)于與另一元素重疊的元素來(lái)說(shuō)，這點(diǎn)特別重要，因?yàn)橐粋€(gè)錯(cuò)誤可能使一個(gè)元素錯(cuò)誤地出現(xiàn)在另一個(gè)元素的上層。

當(dāng)然，不一定每幀都總是會(huì)經(jīng)過(guò)管道每個(gè)部分的處理。我們的目標(biāo)就是，每一幀的動(dòng)畫，對(duì)于上述的管道流程，能避免則避免，不能避免則最大限度優(yōu)化。

優(yōu)化動(dòng)畫步驟

先給出一個(gè)步驟，調(diào)優(yōu)一個(gè)動(dòng)畫，有一定的指導(dǎo)原則可以遵循，一步一步深入動(dòng)畫:

1.精簡(jiǎn) DOM ，合理布局

這個(gè)沒(méi)什么好說(shuō)的，如果可以，精簡(jiǎn) DOM 結(jié)構(gòu)在任何時(shí)候都是對(duì)頁(yè)面有幫助的。

2.使用 transform 代替 left、top，減少使用耗性能樣式

現(xiàn)代瀏覽器在完成以下四種屬性的動(dòng)畫時(shí)，消耗成本較低：

position（位置）:transform: translate(npx, npx)
scale（比例縮放）：transform: scale(n)
rotation（旋轉(zhuǎn)）：transform: rotate(ndeg)
opacity（透明度）：opacity： 0...1

如果可以，盡量只使用上述四種屬性去控制動(dòng)畫。

不同樣式在消耗性能方面是不同的，改變一些屬性的開(kāi)銷比改變其他屬性要多，因此更可能使動(dòng)畫卡頓。

例如，與改變?cè)氐奈谋绢伾啾?，改變?cè)氐腷ox-shadow將需要開(kāi)銷大很多的繪圖操作。改變?cè)氐膚idth可能比改變其transform要多一些開(kāi)銷。如box-shadow屬性，從渲染角度來(lái)講十分耗性能，原因就是與其他樣式相比，它們的繪制代碼執(zhí)行時(shí)間過(guò)長(zhǎng)。

這就是說(shuō)，如果一個(gè)耗性能嚴(yán)重的樣式經(jīng)常需要重繪，那么你就會(huì)遇到性能問(wèn)題。其次你要知道，沒(méi)有不變的事情，在今天性能很差的樣式，可能明天就被優(yōu)化，并且瀏覽器之間也存在差異。

開(kāi)啟 GPU 硬件加速

歸根結(jié)底，上述四種屬性的動(dòng)畫消耗較低的原因是會(huì)開(kāi)啟了 GPU 硬件加速。動(dòng)畫元素生成了自己的圖形層（GraphicsLayer）。

通常而言，開(kāi)啟 GPU 加速的方法我們可以使用

will-change: transform

這會(huì)使聲明了該樣式屬性的元素生成一個(gè)圖形層，告訴瀏覽器接下來(lái)該元素將會(huì)進(jìn)行 transform 變換，讓瀏覽器提前做好準(zhǔn)備。

使用will-change并不一定會(huì)有性能的提升，因?yàn)榧词篂g覽器預(yù)料到會(huì)有這些更改，依然會(huì)為這些屬性運(yùn)行布局和繪制流程，所以提前告訴瀏覽器，也并不會(huì)有太多性能上的提升。這樣做的好處是，創(chuàng)建新的圖層代價(jià)很高，而等到需要時(shí)匆忙地創(chuàng)建，不如一開(kāi)始直接創(chuàng)建好。

對(duì)于 Safari 及一些舊版本瀏覽器，它們不能識(shí)別will-change，則需要使用某種 translate 3D 進(jìn)行 hack，通常會(huì)使用

transform: translateZ(0)

所以，正常而言，在生產(chǎn)環(huán)境下，我們可能需要使用如下代碼，開(kāi)啟硬件加速：

{    will-change: transform;    transform: translateZ(0);}

3.控制頻繁動(dòng)畫的層級(jí)關(guān)系

動(dòng)畫層級(jí)的控制的意思是盡量讓需要進(jìn)行 CSS 動(dòng)畫的元素的z-index保持在頁(yè)面最上方，避免瀏覽器創(chuàng)建不必要的圖形層（GraphicsLayer），能夠很好的提升渲染性能。

OK，這里又提到了圖形層（GraphicsLayer），這是一個(gè)瀏覽器渲染原理相關(guān)的知識(shí)（WebKit/blink內(nèi)核下）。它能對(duì)動(dòng)畫進(jìn)行加速，但同時(shí)也存在相應(yīng)的加速坑！

簡(jiǎn)單來(lái)說(shuō)，瀏覽器為了提升動(dòng)畫的性能，為了在動(dòng)畫的每一幀的過(guò)程中不必每次都重新繪制整個(gè)頁(yè)面。在特定方式下可以觸發(fā)生成一個(gè)合成層，合成層擁有單獨(dú)的 GraphicsLayer。

需要進(jìn)行動(dòng)畫的元素包含在這個(gè)合成層之下，這樣動(dòng)畫的每一幀只需要去重新繪制這個(gè) Graphics Layer 即可，從而達(dá)到提升動(dòng)畫性能的目的。

那么一個(gè)元素什么時(shí)候會(huì)觸發(fā)創(chuàng)建一個(gè) Graphics Layer 層？從目前來(lái)說(shuō)，滿足以下任意情況便會(huì)創(chuàng)建層：

硬件加速的 iframe 元素（比如 iframe 嵌入的頁(yè)面中有合成層）
硬件加速的插件，比如 flash 等等
使用加速視頻解碼的<video>元素
3D 或者硬件加速的 2D Canvas 元素
3D 或透視變換 (perspective、transform) 的 CSS 屬性
對(duì)自己的 opacity 做 CSS 動(dòng)畫或使用一個(gè)動(dòng)畫變換的元素
擁有加速 CSS 過(guò)濾器的元素
元素有一個(gè)包含復(fù)合層的后代節(jié)點(diǎn)(換句話說(shuō)，就是一個(gè)元素?fù)碛幸粋€(gè)子元素，該子元素在自己的層里)
元素有一個(gè) z-index 較低且包含一個(gè)復(fù)合層的兄弟元素

本小點(diǎn)中說(shuō)到的動(dòng)畫層級(jí)的控制，原因就在于上面生成層的最后一條：

元素有一個(gè) z-index 較低且包含一個(gè)復(fù)合層的兄弟元素。

這里是存在坑的地方，首先我們要明確兩點(diǎn)：

1.我們希望我們的動(dòng)畫得到 GPU 硬件加速，所以我們會(huì)利用類似transform: translateZ()這樣的方式生成一個(gè) Graphics Layer 層。

2.Graphics Layer 雖好，但不是越多越好，每一幀的渲染內(nèi)核都會(huì)去遍歷計(jì)算當(dāng)前所有的 Graphics Layer ，并計(jì)算他們下一幀的重繪區(qū)域，所以過(guò)量的 Graphics Layer 計(jì)算也會(huì)給渲染造成性能影響。

記住這兩點(diǎn)之后，回到上面我們說(shuō)的坑。

假設(shè)我們有一個(gè)輪播圖，有一個(gè) ul 列表，結(jié)構(gòu)如下：

<div><div>輪播圖</div><ul><li>列表li</li><li>列表li</li><li>列表li</li><li>列表li</li></ul></div>

假設(shè)給他們定義如下 CSS：

.swiper {    position: static;    animation: 10s move infinite;} .list {    position: relative;} @keyframes move {    100% {transform: translate3d(10px, 0, 0);    }}

由于給.swiper添加了translate3d(10px, 0, 0)動(dòng)畫，所以它會(huì)生成一個(gè) Graphics Layer，如下圖所示，用開(kāi)發(fā)者工具可以打開(kāi)層的展示，圖形外的黃色邊框即代表生成了一個(gè)獨(dú)立的復(fù)合層，擁有獨(dú)立的 Graphics Layer 。

但是！在上面的圖中，我們并沒(méi)有給下面的list也添加任何能觸發(fā)生成 Graphics Layer 的屬性，但是它也同樣也有黃色的邊框，生成了一個(gè)獨(dú)立的復(fù)合層。

原因在于上面那條元素有一個(gè) z-index 較低且包含一個(gè)復(fù)合層的兄弟元素。我們并不希望list元素也生成 Graphics Layer ，但是由于 CSS 層級(jí)定義原因，下面的 list 的層級(jí)高于上面的 swiper，所以它被動(dòng)的也生成了一個(gè) Graphics Layer 。

使用 Chrome，我們也可以觀察到這種層級(jí)關(guān)系，可以看到.list的層級(jí)高于.swiper：

所以，下面我們修改一下 CSS ，改成：

.swiper {    position: relative;    z-index: 100;} .list {    position: relative;}

這里，我們明確使得.swiper的層級(jí)高于.list，再打開(kāi)開(kāi)發(fā)者工具觀察一下：

可以看到，這一次，.list元素已經(jīng)沒(méi)有了黃色外邊框，說(shuō)明此時(shí)沒(méi)有生成 Graphics Layer 。再看看層級(jí)圖：

此時(shí)，層級(jí)關(guān)系才是我們希望看到的，.list元素沒(méi)有觸發(fā)生成 Graphics Layer 。而我們希望需要硬件加速的.swiper保持在最上方，每次動(dòng)畫過(guò)程中只會(huì)獨(dú)立重繪這部分的區(qū)域。

總結(jié)

這個(gè)坑最早見(jiàn)于張?jiān)讫埌l(fā)布的這篇文章CSS3硬件加速也有坑，這里還要總結(jié)補(bǔ)充的是：

GPU 硬件加速也會(huì)有坑，當(dāng)我們希望使用利用類似transform: translate3d()這樣的方式開(kāi)啟 GPU 硬件加速，一定要注意元素層級(jí)的關(guān)系，盡量保持讓需要進(jìn)行 CSS 動(dòng)畫的元素的z-index保持在頁(yè)面最上方。

Graphics Layer 不是越多越好，每一幀的渲染內(nèi)核都會(huì)去遍歷計(jì)算當(dāng)前所有的 Graphics Layer ，并計(jì)算他們下一幀的重繪區(qū)域，所以過(guò)量的 Graphics Layer 計(jì)算也會(huì)給渲染造成性能影響。

可以使用 Chrome ，用上面介紹的兩個(gè)工具對(duì)自己的頁(yè)面生成的 Graphics Layer 和元素層級(jí)進(jìn)行觀察然后進(jìn)行相應(yīng)修改。

上面觀察頁(yè)面層級(jí)的 chrome 工具非常吃內(nèi)存？好像還是一個(gè)處于實(shí)驗(yàn)室的功能，分析稍微大一點(diǎn)的頁(yè)面容易直接卡死，所以要多學(xué)會(huì)使用第一種觀察黃色邊框的方式查看頁(yè)面生成的 Graphics Layer 這種方式。

4. 使用 will-change 可以在元素屬性真正發(fā)生變化之前提前做好對(duì)應(yīng)準(zhǔn)備

// 示例.example {    will-change: transform;}

上面已經(jīng)提到過(guò) will-change 了。

will-change 為 web 開(kāi)發(fā)者提供了一種告知瀏覽器該元素會(huì)有哪些變化的方法，這樣瀏覽器可以在元素屬性真正發(fā)生變化之前提前做好對(duì)應(yīng)的優(yōu)化準(zhǔn)備工作。這種優(yōu)化可以將一部分復(fù)雜的計(jì)算工作提前準(zhǔn)備好，使頁(yè)面的反應(yīng)更為快速靈敏。

值得注意的是，用好這個(gè)屬性并不是很容易：

在一些低端盒子上，will-change會(huì)導(dǎo)致很多小問(wèn)題，譬如會(huì)使圖片模糊，有的時(shí)候很容易適得其反，所以使用的時(shí)候還需要多加測(cè)試。

不要將 will-change 應(yīng)用到太多元素上：瀏覽器已經(jīng)盡力嘗試去優(yōu)化一切可以優(yōu)化的東西了。有一些更強(qiáng)力的優(yōu)化，如果與 will-change 結(jié)合在一起的話，有可能會(huì)消耗很多機(jī)器資源，如果過(guò)度使用的話，可能導(dǎo)致頁(yè)面響應(yīng)緩慢或者消耗非常多的資源。

有節(jié)制地使用：通常，當(dāng)元素恢復(fù)到初始狀態(tài)時(shí)，瀏覽器會(huì)丟棄掉之前做的優(yōu)化工作。但是如果直接在樣式表中顯式聲明了 will-change 屬性，則表示目標(biāo)元素可能會(huì)經(jīng)常變化，瀏覽器會(huì)將優(yōu)化工作保存得比之前更久。所以最佳實(shí)踐是當(dāng)元素變化之前和之后通過(guò)腳本來(lái)切換 will-change 的值。

不要過(guò)早應(yīng)用 will-change 優(yōu)化：如果你的頁(yè)面在性能方面沒(méi)什么問(wèn)題，則不要添加 will-change 屬性來(lái)榨取一丁點(diǎn)的速度。 will-change 的設(shè)計(jì)初衷是作為最后的優(yōu)化手段，用來(lái)嘗試解決現(xiàn)有的性能問(wèn)題。它不應(yīng)該被用來(lái)預(yù)防性能問(wèn)題。過(guò)度使用 will-change 會(huì)導(dǎo)致生成大量圖層，進(jìn)而導(dǎo)致大量的內(nèi)存占用，并會(huì)導(dǎo)致更復(fù)雜的渲染過(guò)程，因?yàn)闉g覽器會(huì)試圖準(zhǔn)備可能存在的變化過(guò)程，這會(huì)導(dǎo)致更嚴(yán)重的性能問(wèn)題。

給它足夠的工作時(shí)間：這個(gè)屬性是用來(lái)讓頁(yè)面開(kāi)發(fā)者告知瀏覽器哪些屬性可能會(huì)變化的。然后瀏覽器可以選擇在變化發(fā)生前提前去做一些優(yōu)化工作。所以給瀏覽器一點(diǎn)時(shí)間去真正做這些優(yōu)化工作是非常重要的。使用時(shí)需要嘗試去找到一些方法提前一定時(shí)間獲知元素可能發(fā)生的變化，然后為它加上 will-change 屬性。

5. 使用 dev-tool 時(shí)間線 timeline 觀察，找出導(dǎo)致高耗時(shí)、掉幀的關(guān)鍵操作

1）對(duì)比屏幕快照，觀察每一幀包含的內(nèi)容及具體的操作

2）找到掉幀的那一幀，分析該幀內(nèi)不同步驟的耗時(shí)占比，進(jìn)行有針對(duì)性的優(yōu)化

3）觀察是否存在內(nèi)存泄漏

對(duì)于 timeline 的使用用法，這里有個(gè)非常好的教程，通俗易懂，可以看看：

瀏覽器渲染優(yōu)化 Udacity 課程

總結(jié)一下

對(duì)于盒子端 CSS 動(dòng)畫的性能，很多方面仍處于探索中，本文大量?jī)?nèi)容在之前文章已經(jīng)出現(xiàn)過(guò)，這里更多的是歸納總結(jié)提煉成可參照?qǐng)?zhí)行的流程。

本文的優(yōu)化方案研究同樣適用于 PC Web 及移動(dòng) Web

以上就是詳解盒子端CSS動(dòng)畫性能提升的詳細(xì)內(nèi)容，更多關(guān)于盒子端CSS動(dòng)畫性能提升的資料請(qǐng)關(guān)注其它相關(guān)文章！

上一條：如何在CSS中繪制曲線圖形及展示動(dòng)畫下一條：詳解CSS開(kāi)發(fā)過(guò)程中的20個(gè)快速提升技巧

相關(guān)文章：

1. CSS Hack大全-教你如何區(qū)分出IE6-IE10、FireFox、Chrome、Opera2. CSS 使用Sprites技術(shù)實(shí)現(xiàn)圓角效果3. 詳解CSS偽元素的妙用單標(biāo)簽之美4. CSS3實(shí)例分享之多重背景的實(shí)現(xiàn)(Multiple backgrounds)5. CSS3中Transition屬性詳解以及示例分享6. css代碼優(yōu)化的12個(gè)技巧7. 低版本IE正常運(yùn)行HTML5+CSS3網(wǎng)站的3種解決方案8. 使用css實(shí)現(xiàn)全兼容tooltip提示框9. CSS hack用法案例詳解10. 利用CSS3新特性創(chuàng)建透明邊框三角

排行榜

					
					JavaScript實(shí)現(xiàn)通訊錄功能
Docker容器如何更新打包并上傳到阿里云
spring+mybatis實(shí)現(xiàn)圖書管理系統(tǒng)
Django結(jié)合使用Scrapy爬取數(shù)據(jù)入庫(kù)的方法示例
詳解CSS偽元素的妙用單標(biāo)簽之美
PHP設(shè)計(jì)模式中工廠模式深入詳解
快速解決ajax返回值給外部函數(shù)的問(wèn)題
Jsp中request的3個(gè)基礎(chǔ)實(shí)踐
JavaScript實(shí)現(xiàn)組件化和模塊化方法詳解
AJAX的跨域問(wèn)題解決方案
WMLScript的語(yǔ)法基礎(chǔ)
				