今日頭條品質(zhì)優(yōu)化(今日頭條品質(zhì)優(yōu)化怎么做)背景作為一個內(nèi)容類應(yīng)用，看新聞讀資訊一直是頭條用戶的核心需求，頁面的打開速度直接關(guān)系到用戶使用頭條的核心體驗(yàn)，在頭條中，為了更多的承載足夠豐富的樣式和邏輯下保持多端體驗(yàn)的統(tǒng)一，詳情頁的內(nèi)容我們是通過WebView來承載的，但WebView本身的性能相比Native來說比較差，因此，今日頭條技術(shù)團(tuán)隊一直致力于優(yōu)化詳情頁的加載速度。經(jīng)過不斷的優(yōu)化，目前今日頭條中詳情頁在線上的打開體驗(yàn)，從肉眼上基本已經(jīng)感知不到加載過程。在接下來這篇文章里，我們會逐步拆解和介紹我們對詳情頁加載優(yōu)化的思路和實(shí)踐。先讓我們來看看優(yōu)化前后的效果吧~今日頭條詳情頁加載體驗(yàn)優(yōu)化前今日頭條詳情頁加載體驗(yàn)優(yōu)化后數(shù)據(jù)建立性能當(dāng)我們開始著手優(yōu)化頁面加載速度之前，我們需要明確一個問題，怎樣才是用戶真正體驗(yàn)到的頁面加載時間。首先我們可以看下面這個公式：頁面加載時間=頁面加載完成時間-頁面開始加載時間頁面開始加載時間很好確定，當(dāng)用戶點(diǎn)擊了Feed上的卡片，我們就可以認(rèn)為頁面開始加載了。問題是怎么定義頁面加載完成了呢？從客戶端的角度上看，無論是iOS還是Android，WebView都提供了一個loadFinsih的回調(diào)，但在實(shí)際應(yīng)用中我們發(fā)現(xiàn)，loadFinish回調(diào)并不能反應(yīng)用戶的真實(shí)體驗(yàn)。一般來說，WebView渲染需要經(jīng)過下面幾個步驟解析HTML文件加載JavaScript和CSS文件解析并執(zhí)行JavaScript構(gòu)建DOM結(jié)構(gòu)加載圖片等資源頁面加載完畢而loadFinish實(shí)際上是在頁面加載完畢階段，而DOM構(gòu)建完成時頁面結(jié)構(gòu)就已經(jīng)基本渲染完成，所以從用戶真實(shí)體驗(yàn)的角度出發(fā)，我們以DOM結(jié)構(gòu)構(gòu)建完成（即domready）的時間點(diǎn)作為頁面加載完成時間點(diǎn)。白屏在詳情頁瀏覽過程中，除了頁面加載速度之外，還有一個特別影響用戶體驗(yàn)的問題，就是頁面的白屏，也是早期的時候用戶反饋比較多的問題，但有很多場景都可能導(dǎo)致詳情頁發(fā)生白屏，比如說網(wǎng)絡(luò)異常，WebView異常等等，需要從用戶體驗(yàn)的角度出發(fā)去檢測用戶發(fā)生白屏的情況。目前可以想到最直觀的方案就是對WebView進(jìn)行截圖，遍歷截圖的像素點(diǎn)的顏色值，如果非白屏顏色的顏色點(diǎn)超過一定的閾值，就可以認(rèn)為不是白屏，目前需要考慮的是這個方案的性能問題和檢測時機(jī)。iOS中提供了WebView快照的接口獲取當(dāng)前WebView渲染的內(nèi)容，底層采用異步回調(diào)的實(shí)現(xiàn)方式，API耗時10ms左右，用戶基本無感知。-(void)takeSnapshotWithConfiguration:(nullableWKSnapshotConfiguration*)snapshotConfigurationcompletionHandler:(void(^)(UIImage*_Nullablesnapshotimage,NSError*_Nullableerror))completionHandlerAPI_AVAILABLE(ios(11.0));Android中系統(tǒng)提供的獲取視圖內(nèi)容的接口為getDrawingCache，API耗時在40ms左右，性能損耗也不是特別大。除了截圖的性能損耗，像素點(diǎn)檢測也是白屏檢測中比較耗時的場景，經(jīng)過實(shí)驗(yàn)，我們把WebView截圖的圖片進(jìn)行縮小到原圖的1/6，遍歷檢測圖片的像素點(diǎn)，當(dāng)非白色的像素點(diǎn)大于5%的時候我們就認(rèn)為是非白屏的情況，可以相對高效檢測準(zhǔn)確得出詳情頁是否發(fā)生了白屏。指標(biāo)建立確定好口徑之后，我們還有需要明確的一個問題是，什么指標(biāo)可以反映用戶刷頭條時的真實(shí)體驗(yàn)。最早的時候，我們用的是詳情頁頁面的頁面平均加載時長，也就是頁面加載時長的總和/頁面pv，在開始的時候這個指標(biāo)也的確可以明確我們的加載速度。后來隨著詳情頁的加載優(yōu)化逐漸的深入，會發(fā)現(xiàn)平均加載時長雖然也可以反映詳情頁加載速度，但是因?yàn)樵斍轫摰膒v比較高，如果使用平均加載速度化很多用戶體驗(yàn)問題就被平均掉了，并不能反映用戶的真實(shí)情況，后面我們又調(diào)整了口徑，將指標(biāo)調(diào)整為所有用戶進(jìn)入詳情頁的80分位值，比如說，假如頭條詳情頁加載速度80分位值是1秒，那么就說明80%的情況下用戶進(jìn)入詳情頁都能在1s內(nèi)加載完成，當(dāng)然經(jīng)過我們的不斷優(yōu)化，詳情頁加載的80分位值已經(jīng)能夠達(dá)到0.3s以內(nèi)，也就是說，80%的情況下用戶都能夠在0.3s內(nèi)完成頁面加載。80分位優(yōu)化數(shù)據(jù)對比再后來我們又發(fā)現(xiàn)，在頭條詳情頁的量級下面，即使是80分位的數(shù)據(jù)也不能反應(yīng)許多長尾用戶的真實(shí)情況，也為了更極致的追求詳情頁的加載性能，我們最后將詳情頁的性能口徑調(diào)整到95分位。到目前在我們的努力下，今日頭條詳情頁的加載速度95分位也優(yōu)化了將近80%。我們究竟做了什么呢，接下來會慢慢介紹一下。模板優(yōu)化模板拆分如前所述，圖文詳情頁是通過WebView來承載的，而WebView承載頁面最簡單的做法就是直接通過URL去加載一個線上頁面。那么先來一道簡單的面試題，當(dāng)用戶從瀏覽器輸入一個URL到頁面展現(xiàn)發(fā)生了什么呢？之前已經(jīng)介紹過頁面的渲染流程了，現(xiàn)在我們再簡單看看用戶從點(diǎn)擊到看到頁面內(nèi)容需要經(jīng)歷如下幾個階段：WebView加載流程可以看到，通過線上頁面加載用戶每次進(jìn)入詳情頁都要通過多次網(wǎng)絡(luò)加載，極容易受網(wǎng)絡(luò)波動的影響，這種情況下，也無法保證頁面加載的時長和成功率，極大的影響了用戶體驗(yàn)。于是在頭條中，我們將新聞中標(biāo)題和正文內(nèi)容進(jìn)行拆分，把頭條詳情頁的公共樣式CSS和邏輯JS都抽離出來，形成一個獨(dú)立而完備的詳情頁模板，這樣我們就可以把模板直接內(nèi)置在客戶端中。同時我們會與前端約定好的JS腳本，通過接口將正文內(nèi)容數(shù)據(jù)注入頁面完成詳情頁的頁面展示，通過該這種方式我們可以將接口放到客戶端上進(jìn)行請求。這樣用戶進(jìn)入詳情頁的時候只需要本地加載模板，而且加載模板的時候也可以同時并行請求詳情頁數(shù)據(jù)，再將數(shù)據(jù)注入進(jìn)模板中。那么用戶點(diǎn)擊到看到頁面內(nèi)容只需要經(jīng)歷下面的階段：模板拆分如上圖所示，我們只需要通過一次網(wǎng)絡(luò)加載就可以完成頁面渲染。還能不能更快一點(diǎn)呢？當(dāng)然能！為了提高頁面的加載速度，客戶端通過一定的策略去預(yù)加載新聞數(shù)據(jù)，這樣在理想狀態(tài)下用戶進(jìn)入頁面時看到頁面時就可以直接使用緩存的數(shù)據(jù)，用戶在看新聞的時候可以實(shí)現(xiàn)完全離線化，避免受到網(wǎng)絡(luò)的影響。本地加載模板預(yù)熱完全脫離了網(wǎng)絡(luò)加載之后，還能再快一點(diǎn)呢？當(dāng)然還是可以的！當(dāng)全流程離線化之后，頁面加載的瓶頸就變成了本地模板的加載時間，所以我們接下來要做的就是優(yōu)化模板加載時間。對于模板來說，我們做了兩件事情模板合并，正常來說，WebView需要在加載玩主HTML之后再去加載HTML中的JS和CSS，需要多次IO操作，于是我們將JS和CSS還有一些圖片都內(nèi)聯(lián)到一個文件中，這樣，加載模板時就只需要一次IO操作，也大大減少因?yàn)镮O加載沖突導(dǎo)致模板加載失敗問題模板簡化，我們將部分非必須的腳本異步化拉取，精簡不必要的樣式和JS代碼，將模板大小壓縮了20%以上通過上面優(yōu)化，我們就已經(jīng)將模板加載時間大大優(yōu)化了，但是還能不能更給力呢？還是可以的。對于客戶端來說，當(dāng)模板跟數(shù)據(jù)分離之后，由于每次用戶點(diǎn)擊的時候加載的都是同一個模板，所以實(shí)際上，我們并不需要在用戶進(jìn)入頁面的時候才去創(chuàng)建WebView以及加載模板，我們只需要在合適的時機(jī)在后臺創(chuàng)建WebView，并且提前預(yù)熱加載模板，當(dāng)用戶點(diǎn)擊進(jìn)入頁面的時候就能使用已經(jīng)加載好模板的WebView，直接將詳情頁的內(nèi)容數(shù)據(jù)通過JS注入到頁面中，前端收到數(shù)據(jù)后進(jìn)行頁面渲染即可。此時用戶進(jìn)入詳情頁實(shí)際就不再需要重新加載模板了，路徑就變成了：模板預(yù)熱可以看下，通過本地測試的模板預(yù)熱和數(shù)據(jù)預(yù)取的優(yōu)化效果，還是比較明顯的，基本上已經(jīng)達(dá)到了上面的截圖中的驗(yàn)證效果。本地測試數(shù)據(jù)模板復(fù)用當(dāng)我們拆分完模板和數(shù)據(jù)之后，數(shù)據(jù)上優(yōu)化已經(jīng)比較明顯，但我們說過，除了驗(yàn)證數(shù)據(jù)，我們還需要看線上用戶的真實(shí)體驗(yàn)數(shù)據(jù)，從95分位上看實(shí)際數(shù)據(jù)優(yōu)化卻不是很明顯，所以我們從數(shù)據(jù)上觀察，用戶預(yù)熱模板的命中率只有53%，還有進(jìn)一步的提升空間。模板預(yù)熱率為了盡可能的提高頁面的加載速度，我們希望用戶每次進(jìn)入詳情頁的時候都能夠使用預(yù)熱好模板的WebView，一般情況下，我們都會使用模板預(yù)創(chuàng)建池的手段來優(yōu)化用戶進(jìn)入詳情頁時的預(yù)熱模板命中率。但其實(shí)在很多情況下，WebView的創(chuàng)建是一個性能開銷比較大的操作，如果我們使用預(yù)創(chuàng)建池的方案，那么就會在后臺頻繁創(chuàng)建WebView，這樣對用戶在Feed場景的瀏覽體驗(yàn)也會有一定的影響。而且假如用戶頻繁且快速進(jìn)出詳情頁時，實(shí)際場景中用戶也很容易遇到無法命中預(yù)熱模板的場景。這個時候?yàn)榱藘?yōu)化用戶的體驗(yàn)，如前文所述，我們每次使用的時候都是同一個模板，所以我們使用完當(dāng)前WebView之后，只需要在用戶退出頁面的時候把正文數(shù)據(jù)清空，這樣進(jìn)入下一個頁面的時候就能夠繼續(xù)復(fù)用這個WebView重新注入數(shù)據(jù)即可。通過這個手段，我們既避免了頻繁在后臺預(yù)創(chuàng)建WebView對用戶刷Feed體驗(yàn)的影響，把用戶進(jìn)入頁面時候的預(yù)熱模板命中率從53%提升到92%，優(yōu)化了用戶體驗(yàn)。預(yù)熱模板命中率網(wǎng)絡(luò)優(yōu)化說完我們在模板WebView方面的優(yōu)化之后，再介紹一下我們在內(nèi)容請求上的優(yōu)化。CDN加速由于頭條詳情頁請求有以下特點(diǎn)流量大，之前說過，看新聞作為用戶在頭條的核心場景，每天都有上億用戶在使用頭條，詳情頁的數(shù)據(jù)流量十分大。數(shù)據(jù)屬性基本不變，在詳情頁的請求中，很多熱點(diǎn)文章是重復(fù)渲染計算的，正文、標(biāo)題、作者信息、圖片控制以及一些樣式和業(yè)務(wù)邏輯渲染是基本不變的，這部分重復(fù)計算耗費(fèi)了帶寬、服務(wù)器資源，是比較沒有必要的。用戶分布廣，網(wǎng)絡(luò)狀況難以保證，頭條的用戶量很大，覆蓋了各種運(yùn)營商網(wǎng)絡(luò)和網(wǎng)絡(luò)狀態(tài)，網(wǎng)絡(luò)質(zhì)量無法得到很好的保證。而CDN能夠?qū)?shù)據(jù)緩存在各地的邊緣節(jié)點(diǎn)，用戶就近接入了邊緣節(jié)點(diǎn)，避免在網(wǎng)絡(luò)質(zhì)量無法保證的公網(wǎng)上長時間傳輸，從而提高了響應(yīng)速度和響應(yīng)的成功率。接口數(shù)據(jù)大，由于正文數(shù)據(jù)的存在，接口返回的數(shù)據(jù)常常會很大，如果每一次都實(shí)時返回，對網(wǎng)絡(luò)的壓力會比較大，可能會把帶寬打滿而影響其他服務(wù)所以我們將詳情頁內(nèi)容數(shù)據(jù)分為靜態(tài)和動態(tài)兩部分，將正文內(nèi)容、標(biāo)題、作者欄等用戶主要消費(fèi)的又基本不變的內(nèi)容托管到了CDN上。CDN的全稱是ContentDeliveryNetwork，即內(nèi)容分發(fā)網(wǎng)絡(luò)。其目的是通過在現(xiàn)有的Internet中增加一層新的網(wǎng)絡(luò)架構(gòu)，將網(wǎng)站的內(nèi)容發(fā)布到最接近用戶的網(wǎng)絡(luò)“邊緣”，使用戶可以就近取得所需的內(nèi)容，提高用戶訪問網(wǎng)站的響應(yīng)速度。CDN有別于鏡像，因?yàn)樗如R像更智能，或者可以做這樣一個比喻：CDN=更智能的鏡像+緩存+流量導(dǎo)流。因而，CDN可以明顯提高Internet網(wǎng)絡(luò)中信息流動的效率。從技術(shù)上全面解決由于網(wǎng)絡(luò)帶寬小、用戶訪問量大、網(wǎng)點(diǎn)分布不均等問題，提高用戶訪問網(wǎng)站的響應(yīng)速度。托管到CDN之后，全國各地的用戶可以直接從最佳節(jié)點(diǎn)就獲取到詳情頁數(shù)據(jù)，也大大節(jié)省了帶寬成本。容災(zāi)1.多域名備份為了防止某個CDN出現(xiàn)故障，導(dǎo)致服務(wù)雪崩，服務(wù)端會下發(fā)多個CDN鏈接，當(dāng)用戶訪問當(dāng)前CDN節(jié)點(diǎn)的出異常時，可以快速自動切換到下個CDN節(jié)點(diǎn)。2.快速超時一般的超時策略，客戶端在請求時，會遍歷請求CDN1、2、3。如果這些CDN都請求失敗，則整個網(wǎng)絡(luò)請求算作失敗。但這個方案的問題是，假設(shè)請求CDN的超時時間是15s。如果CDN1出現(xiàn)故障，則需要等待15s才能切換到CDN2上，這對于詳情頁的加載時間來說是不可接受，如果用戶網(wǎng)絡(luò)突然變差，則需要等待45s才能返回失敗展示錯誤頁。基于此我們設(shè)計了詳情頁請求的快速動態(tài)超時策略單次請求CDN的超時時間，根據(jù)上次成功請求CDN的值計算，因子1.5（z值）。且最小為1s（x值），最大為4s（y值）。超過這一時間不取消，直接請求下個CDN。單次請求CDN有一個硬性超時時間4s（w值，w需>=y），超過這一時間請求取消。n個CDN的請求全部取消后反饋用戶失敗。幾個case：第1個CDN突然掛掉（假設(shè)上次成功請求的耗時為a）下一次請求：第一個CDN很快超時（a_1.5）；開始請求第二個CDN（超時時間為a_1.5，但實(shí)際上b秒就會返回請求）。用戶本次等待時間為a_1.5+b下兩次請求：第一個CDN很快超時（b_1.5）；開始請求第二個CDN（超時時間為b_1.5，但實(shí)際c秒就會返回請求）。用戶本次等待時間為b_1.5+c用戶突然進(jìn)入了一個網(wǎng)絡(luò)很差的環(huán)境（假設(shè)上次成功請求的耗時為a）下一次請求：第一個CDN很快超時（a_1.5）；開始請求第二個CDN（a_1.5）也超時；開始請求第三個CDN（a_1.5）。最后一個請求會在a_3+w后返回失敗（這個值會在12s以內(nèi)）。可以看到，通過多域名備份和快速超時的策略，即使用戶在網(wǎng)絡(luò)或者服務(wù)異常的情況下，也能快速恢復(fù)或者讓用戶能感知到自身網(wǎng)絡(luò)問題。渲染優(yōu)化當(dāng)我們在模板層和網(wǎng)絡(luò)層優(yōu)化到極致的時候，限制我們的就是WebView的渲染速度了！服務(wù)端預(yù)渲染正常來講，正常的內(nèi)容數(shù)據(jù)可能是類似JSON等數(shù)據(jù)，客戶端獲取到數(shù)據(jù)之后，將數(shù)據(jù)注入給前端，前端還需要將JSON數(shù)據(jù)跟模板進(jìn)行組裝，拼上HTML標(biāo)簽等模板了之后再呈現(xiàn)到WebView渲染，導(dǎo)致前端渲染上耗時也比較久。為了提高用戶的首屏效率，我們在服務(wù)端就會把所有的詳情頁正文的HTML數(shù)據(jù)組裝好，通過將服務(wù)端直出內(nèi)容注入到頁面中時，可以直接給WebView進(jìn)行渲染，對于其他動態(tài)下發(fā)的內(nèi)容（比如相關(guān)搜索），前端再進(jìn)行二次異步處理，提升用戶效率。客戶端渲染一般來說，我們正文中所有內(nèi)容都是通過WebView渲染，經(jīng)過上述的優(yōu)化之后，文章的文字部分渲染效率已經(jīng)很高了，但是實(shí)際場景中，很多文章會包含比較多的圖片和視頻場景。在實(shí)際場景中，WebView渲染非文字內(nèi)容會存在以下問題：相比于文字內(nèi)容，非文字內(nèi)容比如說圖片和視頻類資源的渲染對于WebView來說渲染效率比較差在詳情頁中文章有大量圖片的場景，對于WebView的渲染內(nèi)存占用和滑動體驗(yàn)也有問題最后，如果用戶多次打開同一篇文章，這篇文章中的圖片也會存在多次加載的問題，無法與客戶端進(jìn)行緩存共享，對用戶的流量也是一種浪費(fèi)。所以在詳情頁中，我們會將圖片和視頻等非文字內(nèi)容通過原生組件的方式放在客戶端進(jìn)行渲染，既可以提高渲染效率，也可以減少不必要的流量消耗。原生化渲染還有一個好處，圖片越來越成為文章體驗(yàn)的重要部分，對于多圖文章，我們在Feed頁面也可以智能加載詳情頁需要的圖片，增加用戶的文章首屏體驗(yàn)。白屏優(yōu)化講完了性能優(yōu)化，最后再分享一下我們對詳情頁白屏率的一些優(yōu)化，其實(shí)很多用戶反饋白屏問題大部分都可能是由于網(wǎng)絡(luò)等問題導(dǎo)致頁面加載時間過長，導(dǎo)致用戶從體驗(yàn)上觀感是白屏了，這部分通過上面分享的性能優(yōu)化手段已經(jīng)能夠解決，所以下面只是簡單介紹下一些非網(wǎng)絡(luò)原因的白屏問題。我們通過白屏檢測和上報之后的數(shù)據(jù)分析之后發(fā)現(xiàn)，非網(wǎng)絡(luò)原因?qū)е碌脑斍轫摰陌灼羻栴}大體是WebView加載的問題。在iOS中，我們使用的是系統(tǒng)提供的WKWebView，WKWebView是運(yùn)行在一個獨(dú)立進(jìn)程中的組件，所以當(dāng)WKWebView上占用內(nèi)存過大時，WKWebView所在的WebContentProcess會被系統(tǒng)kill掉，反映在用戶體驗(yàn)上就是發(fā)生了白屏。根據(jù)網(wǎng)上的做法，我們可以在WKWebView提供的回調(diào)webViewWebContentProcessDidTerminate函數(shù)中通過reload方法重新加載當(dāng)前頁面恢復(fù)，但是這種情況只適用于通過loadRequest加載的請求，在詳情頁中，由于使用了模板化的WebView中，重新reload只能重新reload模板，并不能正常恢復(fù)整個詳情頁，需要客戶端重新加載模板之后再重新注入數(shù)據(jù)。另外由于我們有預(yù)熱模板的邏輯，所以可能在進(jìn)入詳情頁的時候使用的WKWebView就已經(jīng)崩潰，在調(diào)用JS注入數(shù)據(jù)時會直接返回失敗，失敗時，我們會嘗試重新加載模板。但后來實(shí)際操作中發(fā)現(xiàn)一個問題，如果直接調(diào)用數(shù)據(jù)注入的方法，等待系統(tǒng)WebView返回失敗的回調(diào)耗時比較久，所以后續(xù)也調(diào)整了數(shù)據(jù)注入的接口，我們提前在注入的腳本中判斷是否存在數(shù)據(jù)注入的接口，如果不存在，就說明模板存在問題，直接重試即可。而在Android中，我們采用的是自研內(nèi)核WebView，也會遇到一些奇奇怪怪的坑。多線程讀模板文件問題，WebView在運(yùn)行中會讀取的文件模板，如果此時另外一個線程同時更新模板文件時，就出現(xiàn)了模板加載問題，所以需要保證模板加載的原子性Render卡死問題，內(nèi)核是一個比較復(fù)雜的邏輯，內(nèi)部渲染極少數(shù)情況也會出現(xiàn)Render卡死問題，但是在詳情頁整體用戶的量級下，即使只有十萬分之一的可能，對用戶來說也是一個比較大的問題，此時我們會從業(yè)務(wù)上做白屏監(jiān)控進(jìn)行重試當(dāng)然不管是iOS和Android，WebView加載的邏輯都比較復(fù)雜，有時候怎么重試也無法成功，這個時候我們會直接降級到加載線上的詳情頁，優(yōu)先保證用戶的體驗(yàn)。總結(jié)限于篇幅原因，我們還做了很多其他事情，包括請求精簡，push文章預(yù)拉取，數(shù)據(jù)注入的方式優(yōu)化等等，也做了很多其他的方向的探索，這里不做展開，希望有機(jī)會能再分享給大家。最后總結(jié)一下我們在優(yōu)化詳情頁打開速度之后的一些想法數(shù)據(jù)很重要，我們在優(yōu)化加載速度之前做的第一件事情其實(shí)是建立了一個詳情頁的數(shù)據(jù)看板，只有通過數(shù)據(jù)我們才能真正了解目前線上用戶的現(xiàn)狀，從真實(shí)用戶的體驗(yàn)中找到瓶頸和優(yōu)化點(diǎn)。用戶體驗(yàn)優(yōu)先，優(yōu)化方案有很多，除了加載速度之外，還需要從整體應(yīng)用體驗(yàn)出發(fā)，選擇對用戶最佳的方案追求極致，其實(shí)最開始的優(yōu)化是比較簡單的，但是越到后面越難，需要一點(diǎn)點(diǎn)摳細(xì)節(jié)，才能達(dá)到極致的用戶體驗(yàn)更多分享字節(jié)跳動自研線上引流回放系統(tǒng)的架構(gòu)演進(jìn)iOS大解密：玄之又玄的KVO今日頭條Android'秒'級編譯速度優(yōu)化今日頭條技術(shù)團(tuán)隊今日頭條技術(shù)團(tuán)隊不僅致力于在業(yè)務(wù)上不斷深耕挖掘，在技術(shù)上也一直在追求極致的用戶體驗(yàn)。如果你也向往在一個億級DAU業(yè)務(wù)里成長，也期待在技術(shù)上有突飛猛進(jìn)的提升，歡迎你加入我們。無論你是iOS/Android/前端/后端，我們在深圳/北京/廣州等你來，一起做更有挑戰(zhàn)的事！簡歷投遞郵箱：tech@bytedance.com；郵件標(biāo)題：姓名-工作年限-頭條技術(shù)團(tuán)隊。歡迎關(guān)注字節(jié)跳動技術(shù)團(tuán)隊