用戶數過億的QQ空間前端優化的思路是什麼

5月7日，「騰訊SNG & msup技術開放日」在深圳召開。壹佰案例採訪了一些與會講師，談談他們將在會上分享的內容。本次採訪的是騰訊雲平臺產品技術負責人陳子舜。

壹佰案例：首先想請您介紹一下您目前的工做以及您關注的領域

陳子舜：我目前在騰訊雲團隊，負責平臺產品線的管理工做，其中包括前端團隊、團隊的能力建設等工做。從技術角度來講，我如今更多關注前端的發展，包括前端的一些趨勢和將來潛在的新技術。

壹佰案例：前端曾經被誤解爲「作網頁」、「切圖」的，但隨着前端技術不斷髮展，咱們也能夠看到前端技術是如今發展最快的技術之一，相似AngularJS、React等框架層出不窮。如今的前端開發從簡單的Web開發到Web富應用開發，您對這種前端技術的發展趨勢是怎麼看的？

陳子舜：我很是認同前端發展很快這個說法，但也要注意到前端技術的起步是相對比較晚的。從2004年穀歌出了Gmail提出Ajax開始，你們才意識到這個技術其實能解決不少問題，可是若是再往前看的話，終端的一些發展，包括整個計算機領域的發展，其實對客戶端的要求，這個路徑已經走了很長時間。

前端由於發展的比較晚，如今才走到「我要去作組件」，「我要去提出AngularJS」，「提出一些從前端Router」到「提出雙向綁定等方式」，包括像React提供了一種組件的管理方式。以上的這些說法實際上並不新鮮，在客戶端開發裏，這些概念一直都有，只是前端基本上是按照客戶端的發展路徑不斷快速的對齊如今的發展趨勢。如今若是要看前端之後能往什麼方向發展的話，我以爲更多能夠參考客戶端發展的路徑。

壹佰案例：QQ空間的業務隨着互聯網的發展、用戶數的增加，通過幾回技術升級的過程，您能從前端的角度談談QQ空間這幾回升級背後的故事嗎？

陳子舜：
第一個階段是我剛剛接觸QQ空間的工做，這個階段很重要的工做是什麼呢？當時咱們面臨十萬用戶同時在線的臺階，並且對咱們後臺負載有很高的要求。

因此在當時咱們最主要的工做是：咱們怎麼樣先扛住用戶快速增加的階段，可以給後臺下降負載壓力。由於2006年的前端開發模式，就是後臺主頁面的方式，咱們發現若是按照這個方式作，後臺壓力很大，並且當時的後臺也沒有如今那麼好的硬件條件。咱們前端的團隊當時也只有三我的，咱們就想各類各樣的辦法來幫助後臺減壓。

怎麼作呢？咱們把一些邏輯代碼提到前端來，恰好也有Ajax的一些技術能夠去創新，咱們能夠用這種前端異步的方式把不少東西移到前端來。同時咱們也更多考慮怎麼去減小後臺的請求，好比說文件合併、預加載等，實際上不少都是咱們在當時的架構考慮到的事情。

固然還有後臺請求過多的問題存在，不只僅是頁面請求，還包括後臺CGI過多，由於空間分不少模塊：我的中心、博客、留言、頭像等全部信息都表明後面有相應的服務。

當時按架構去考慮我怎麼樣在後端部署一個統一的環境來配合後臺，作好這種按照標區類的方式知道哪個模塊數據更新而後去動態拉取。其實這種邏輯在當時的前端是有些過於「重」的，但這也是一個標誌性的，讓咱們度過了2006-2007年用戶快速增加的階段。

第二個階段咱們發現前端變得愈來愈重。那個時候前端的代碼裏面揹負了不少歷史問題，因此咱們一直沒有對它進行太多改動。後來當時咱們決定花了很長時間對空間代碼進行重寫，須要重寫的代碼量在當時統計出來的數字是很是大的。

特別須要提到的是當時爲了作到極致，減小請求，把不少邏輯層代碼都拆分到很小的文件裏面。因此在重構的過程當中，咱們也引入了一些模塊化的管理方式。

坦白講，比如今的模塊化要引入的更早，但比較遺憾的是咱們沒有對外輸出這些工具。舉例來講，咱們內部寫了一些工具怎麼把這個文件拆分，把目錄變得更加合理；還有一些工具自動化去合併，進行程序壓縮；也採用了自動化的方式，可以保證咱們的代碼管理和部署。我以爲第二個很重要的階段就是咱們怎麼樣對代碼進行模塊化管理。

第三個階段是團隊變得更大，團隊規模從幾我的變成十幾我的的時候。那麼怎麼去作呢？這時候產品對前端的要求愈來愈高，須要你實現愈來愈多功能，並且跨團隊的配合也愈來愈多，在我總結起來應該經歷了一個叫技術規範化和標準化的過程。

在前面代碼已經管理好了，模塊已經作好了，那怎樣提高效率，怎樣讓代碼提交以後不會產生很明顯的錯誤。

咱們當時的用戶挑戰不少，好比瀏覽器兼容不行，當時其實有不少瀏覽器可使用，好比火狐、Chorme這些版本都出來了，咱們在瀏覽器測試上花了不少功夫，可是實際上仍是沒有達到要求。當時咱們就在想，咱們團隊得有一個標準組件，有一個標準的框架來解決瀏覽器的兼容問題。

在當時的階段，市面上能寫的框架也不是不少，因此咱們決定本身去寫。爲何本身寫呢？由於騰訊仍是有一種喜歡本身造輪子的心，因此後來我本身就給團隊作了一份這樣的標準框架，在內部咱們把它稱之爲QZFL，實現了規範化。

這個框架從1.0發展到2.0走了很長時間，也解決了你們在開發過程當中的問題，例如我不須要再去關注一些經常使用前端組件的實現、一些功能的實現，只要關注業務邏輯就能好了。

在技術標準化方面咱們引入了監控，引入監控後，咱們能夠對整個網絡的環境以及前端的客戶有了掌握，經過監控我知道前端的性能是如何的，知道我每個請求的返回成功率是怎樣的。監控發展到如今也拓展了不少新的維度，好比說我知道哪個省份的用戶比較慢；哪個運營商網絡比較慢；如今慢的用戶大概的百分比是多少等等。

這些數據能夠幫咱們不斷提高總體空間的運營水平、運營能力。我以爲這是一個很重要的標誌，讓咱們走到了一個工業化的程度。這是我以爲空間如今作得比較成熟的很標誌的一件事情。

壹佰案例：QQ空間相關的技術已經很成熟了，將來還會遇到哪些挑戰？

陳子舜：QQ空間如今相對穩定，我也很難判斷之後會遇到什麼樣的技術難點。我以爲真正的難點在於它能不能應對如今日益變化的用戶需求，很難說某一個技術難點能夠算做難點。而是我以爲QQ空間更多要應對的是如今終端用戶習慣的變化，技術能不能及時更新，解決用戶的問題。咱們作不少事情仍是以產品的價值爲導向，咱們要考慮經過技術手段解決具體的產品問題。

空間如今相對來講成熟，也是給咱們團隊一個很好的機會。由於客戶訪問量仍然很是大，也就是如今比較火的海量服務。海量服務的特色是你每作一件事情，你的判斷都會影響大量用戶的使用。因此對程序員有很高的要求，每一件事都要考慮得很是清楚才能夠去驗證明施。

其實QQ空間走到如今，還在作不少很前沿的嘗試。好比說但願嘗試HTTP2，空間的監控除了咱們以前講的這種地區性能、運營商性能的監控之外，本身自己的數據染色、數據採集等等這些能力其實也作得愈來愈深刻了，同時空間的前端組件從瀏覽器到接入層都是一整套完整的解決方案，這是QQ空間成熟的表現。

壹佰案例：前端的工做中優化是很是重要的一個模塊，在一些論壇上也會對優化有不少的爭論，前不久就有用戶在知乎上就QQ空間打開首頁就加載100+的JS提出問題，在這個優化標準的問題上您怎麼看，會不會以數字去衡量這些標準？

陳子舜：其實你們追求極致優化目標的衡量標準是惟一的，可是方案其實會隨着業務而產生多樣化的方案選擇。其實空間一直以來都在作優化，咱們對極致的作法可能和不少人的常見的理解是不太同樣。

咱們更喜歡不斷嘗試一些新方式，提出假設。我以爲前端的優化方式，都有必定的時效性和適用性。不見得說加載一百多個文件就是好或壞,固然咱們也不否定如今加載一百多個文件確實不見得很好，多是團隊管理，或一些其餘技術之外的緣由。而最後咱們其實都是須要拿出的數據衡量。

例如：哪怕真的加載了100個文件，有沒有想過：其實這100個文件也許並無使用戶打開的頁面變得很慢，而相反有辦法可讓他感受很快的？若是100多個文件並非在你首屏顯示的時候加載的，支撐首屏文件作好控制，其餘都走了異步請求，文件多也不見得對你的業務有太大影響。

因此咱們的判斷在於用戶看到的性能如何，他用這個功能的時候能不能快速得到想要的東西，這一切都是基於咱們有可靠的數據分析後進行論證的。不斷提出假設，設計方案，更有針對性的優化某一些地方，針對用戶常見的一些問題，拿出去論證、驗證，而後採用或推翻以前的假設。

也許你會以爲加載了100個文件有問題，可是從咱們這邊的數據看，可能這並不會真正的影響用戶體驗。簡單來講，比如咱們以前一直在說一些優化，要進行合併。通過幾回架構升級，咱們發現有一些文件咱們把它合了又拆，拆了又合，合了又拆。這是由於咱們隨着客戶的網絡、硬件的變化，一直在進行調整。沒有一個最終標準能夠說按照這個標準就能夠作到一勞永逸的優化。

壹佰案例：提到Web優化，有不少公司提出過一些黃金法則，例如Yahoo，您如何看待這些法則，騰訊內部有沒有總結過相似的東西？

陳子舜：咱們在技術總結方面的角度可能和其餘公司不太同樣。我以前也講了一些優化的原則，咱們的優化理念實際上是相似國外「增加黑客」的理念，就是提出假設，設計方案，分析數據，驗證，推翻假設的過程。

咱們以爲標準的東西不見得可以通用，因此咱們也沒有對外推出一些黃金標準。舉例來講Facebook也沒有對外提供標準，在給咱們分享Bigpipe的時候分享者最後說了一句話，「我如今作的優化可能也只適合Facebook用，不見得適合你們」。

在我看來，黃金法則是隻告訴作法，可是並無告訴你們爲何這樣思考爲何要用這些作法，而如今雅虎不少的優化理論會有一些不合適的地方。甚至說的更直接一點，若是HTTP/2有一天火了，基本上這個雅虎的優化黃金法則就廢掉了，那你還要去用嗎？

因此優化是不斷演進的，我剛剛也講到，前端優化是有必定的時效性和適用性的。這樣就對前端開發有更高要求，必定是一個懂思考的程序員，才能提出更多的假設，並知道怎麼去論證。

因此，在騰訊咱們不會看誰用了什麼法則而去判斷這我的能不能達到高級工程師的程度，而是看他的思考過程、思考邏輯，在解決這個問題的時候，你的思考邏輯是否是符合了這樣的方式，你找到了創新點，更漂亮地解決了一個具體的性能優化的問題。

壹佰案例：前端性能優化對普通用戶來講其實就是他打開這個網頁更快了，但實際上在這個快背後是有不少能夠作的技術工做。

陳子舜：沒錯，咱們的性能優化目標是什麼？剛剛講得很清楚就是爲了快。而快的目標是什麼？好比個人頁面打開時間是1秒鐘，咱們爲這1秒鐘打開花了不少工夫，不只是前端壓縮，不只是前端文件合併，我會採用一些cache，我在業務用的一些網絡延遲的手段、技術去讓網頁打開的更快。其實這裏面前端考慮了很是多的問題。

另外隨着發展，如今前端愈來愈重，對用戶的CPU是否是一個消耗，對CPU的把控是否是有一個方法？我監控CPU的即時狀況，可否保證首屏渲染的內容優先得到CPU資源，一些重資源能夠延遲渲染，不要影響用戶的打開，因此咱們也嘗試去經過對CPU資源的控制來提高性能。

另外也在思考在渲染方面咱們是否是能夠作得更深，咱們要去研究瀏覽器的內核，考慮渲染方式，包括和咱們的X5團隊、瀏覽器團隊也有不少交流。你會發現整個前端優化到最後，更多在於怎麼能發現問題，包括推進技術環節的各個角色去解決大部分的事情。

然而如今不少前端開發，大多數認爲只要運用了某某原則、某某法則就完成了性能優化這件事情。可是他沒有想到，在整個頁面打開的流程下面，會有不少基礎環節。包括頁面打開的JS問題，頁面的請求，後端的性能，瀏覽器發生什麼事情，都有可能成爲你的優化點。性能優化實際上是一個持續的技術運營。

最難的是，你怎麼從各個環節發現可能存在的一些優化，提出假設以後，帶領團隊跟你們一塊兒，把這種優化問題解決掉，這是程序工程師常常作的事情。

壹佰案例：提到帶領團隊，您經歷了從3我的到幾十我的的團隊演變過程，也成了一個管理者，團隊由小變大的過程當中有沒有一些好的管理經驗分享給你們。

陳子舜：我帶領了不少團隊，在雲以前我帶的基本上都是新團隊，我剛剛過去就是幾我的，人少的時候時候咱們先想辦法扛住業務的須要。

接下來團隊規模稍微大一些，咱們須要建設一些管理的部分，來幫助這個團隊有效運轉，怎樣管理工做流程、開發模式，包括團隊之間合做的方式、流程的建設等。

到團隊規模再大一些，要求再高一些，就看你對團隊提出的標準。好比說代碼規範、工程化管理，有更好的管理手段和工具引入進來，幫助團隊更有效的完成目標。

我以爲這是整個管理的過程，就好像咱們管理方法中一個團隊的造成階段和磨合階段，以及團隊自身的規範期階段，最後產生團隊的績效，基本上都是按照這樣的思考方式去作。

壹佰案例：您的團隊中確定有很多新人，隨着前端的火熱，也有很多人想去作前端，對於這些新人朋友，做爲一個十年經驗的前端前輩，有什麼建議給他們？

陳子舜：前端其實和之前同樣是很容易入門的一個技術，但這個技術的挑戰也是太容易入門了，致使不少不是程序員的人過來作前端。要是真正喜歡作前端，想成爲一個合格的前端開發，首先要是一個合格的程序員，而好的程序員是有一些要求的：

首先是計算機基礎，掌握一些網絡算法，對程序員來講這是根基，不管你是前端也好，仍是後臺也好，這些都是很重要的，這是計算機基礎能力。

第二，程序員在編碼過程中是不斷挑戰新問題、不斷提高代碼的。同時好的程序員不會給後輩留下坑，他會考慮代碼的可適用性，這種通用素質他會想得很好。

第三，做爲程序員應該有嚴謹的思惟邏輯。作任何事情、任何決策都須要數據論證，不會去猜想也不會輕易相信外界的一些黃金法則或建議。程序員懂得經過一個問題進行逆向思考，爲何會提出這樣一個問題，通常都會有這樣一種很叛逆的想法。

另外，程序員對新技術要保持好奇心，但不該停留在我用了哪些新技術，而是要思考爲何這個新技術會這麼設計，最終解決什麼問題，我以爲好的程序員在這方面會想得很是多。

在這些問題上，若是以爲本身均可以有這樣的想法以後，你再去前端領域，再去前端作更多事，那你是一個好的前端程序員，而不只僅是一個簡單的前端開發的角色。

壹佰案例：在重新人成長爲管理者的過程當中，特別是經歷過不少不一樣的業務，您是如何在快變的環境下學習並迅速融入新業務的？

陳子舜：我其實在騰訊作了不少業務，從QQ空間到作增值產品到如今在作雲，在這個過程當中我也在不斷學習。在作任何業務以前，我首先要了解這一塊業務是作什麼的，這一塊業務須要個人技術有什麼樣的變化。

從PC到手機終端的轉變過程當中，那咱們就說咱們要去擁抱H5，擁抱相似的開發能力，讓本身也能夠學習這一方面的知識，保證本身可以達到業務要求，能夠幫助業務解決問題。

如今作雲以後，發現作雲對狹義的前端（只寫JS）要求不像QQ空間那麼高，反而對程序員思惟邏輯，以及全棧的要求會更高，由於你首先要從新認識雲的業務，從新理解業務對應的用戶是誰，雲的用戶其實對應的是廣大開發者；那廣大開發者須要得到你什麼樣的幫助，你的產品能夠給他什麼樣的支持，你怎麼樣作得更好。

而後就會思考我這個團隊如今的一些技能能不能知足，個人團隊須要作出變化，可以嘗試更多，甚至是站在更廣的層面思考這些開發者他們會遇到什麼樣的困難。

因此我這個團隊基本上轉變爲全棧工程師的角色。到雲以後，咱們須要瞭解更全面的知識點。咱們就要把本身打形成一個全棧工程師，從前端JS到後臺NodeJS的能力，包括網絡各個方面的東西，都要有很全面的把握，你打造出來的產品才能夠解決更多客戶的問題。

我以爲在業務上個人學習方法，都是從業務的客戶需求出發，去考慮個人技術應該怎麼作出調整和轉型。

壹佰案例：騰訊如何看待前端，從公司層面會不會爲你們制定能力模型？

陳子舜：我恰好是騰訊前端通道的負責人，其實通道的標準在去年咱們也更新了一版，最先的晉升通道仍是聚焦在前端JS這方面。你怎麼解決問題，怎麼作到性能優化，怎麼去作好業務的可持續運營，這些都是前端通道的要求。可是由於市場發展很快，咱們也作了一些拆分，拆分紅什麼樣呢？

第一，前端的遊戲方向。遊戲的偏重在於要有更快的學習能力、學習要求，由於遊戲技術變化也是很是快的，有不少新的遊戲框架和引擎，包括H5自己也有不少遊戲方案，你能不能快速學習。遊戲還有一些新的要求，好比對安全的要求，由於會有不少人在寫外掛，因此安全性的要求也是這個方向要考察的部分。
第二，前端的終端方向。對這個方向的要求會跟普通的前端開發不太同樣，由於它得跨界，首先要對H5的能力有所瞭解，還要了解一些Native終端的知識。這樣能夠更好的解決用戶的問題，因此都會有一些偏重。

第三，全棧工程師，咱們內部叫全端工程師，這個就是說，咱們把Node.js和PHP這部分放進來了。咱們爲何認爲這個屬於前端領域呢？由於從用戶訪問頁面的「最後一千米」來看，用戶打開瀏覽器到瀏覽器頁面輸出內容，這些事情都應該是由前端來覆蓋的。輸出頁面的技術，咱們一般叫接入層，或者叫接入web服務，接入web服務這方面咱們在前端有必定的話語權，而且可以可控，我可以在上面開發咱們的業務，這樣作也能夠減小咱們和後臺開發協同的成本。

同時咱們在作新的優化，包括業務邏輯上更有可控性，而不像之前在空間的時候，好比說咱們要作一個優化，要push後臺實際上是很難的事情，由於你們節奏可能會不一致，並且他也不必定理解你爲何要這樣作。因此咱們就提出了第三個叫作全棧工程師，這也是行業比較流行的概念。

第四，騰訊有一個更加特殊的領域叫體驗工程師，也是一個專業化的前端團隊。因此目前咱們在通道里面分了四個方向，來覆蓋整個公司全端團隊他們所作的工做要求。而每個方向也都由高級工程師制定的新的具體的要求，幫助你們不斷成長，跟上行業對本身能力的要求。

壹佰案例：您對全棧如何看？

陳子舜：對全棧工程師我是這麼看的，仍是回到程序員的問題來說，程序員不該該是一個挑活兒的角色，不少技術都該感興趣。若是認爲說多學幾個語言、有必定的跨界就叫全棧工程師，那其實可能對全棧的理解就窄化了。

一個真正好的全棧工程師的概念是包括對覆蓋的技術、對業務的理解、對各個角色的理解都應該有很是全面的認識。對全棧工程師來說，他最大的特質是說他可以接受變化，遇到變化的時候，可以快速轉變，能夠解決具體問題，固然也要有必定的深度，這纔是一個比較好的全棧。

從我自己來講，我本身雖然也說全棧，各類技術我都接觸過，包括後臺，包括Java，基本上都研究過一遍，固然我不能說全部的方面都有很深的瞭解，可是有一件事情我是可以深刻了解的，其餘事情你讓我去作我也可以去完成，基本上就是適應性很強的一個程序員。

你們都知道國外的知名IT公司，都喜歡招全棧工程師，簡單來講就是程序員不該該把某一個語言把本身框死，其實這個是如今在國內不少程序員很可怕的一個想法，你們把語言的level看的過高了，其實把語言做爲一個工具，把本身從用這個工具的角色裏面跳出來，讓本身能夠接觸擁抱這個行業的變化，讓本身在思路上可以卻打開更多。

壹佰案例：React背後是Facebook，AngularJs背後是谷歌，彷佛尚未很強的中國力量參與其中。您對中國將來前端發展，包括一些開源的力量，是怎麼看的，將來有沒有可能有中國的公司去作相似的事情？

陳子舜：沒有能拿出一個框架來並非中國的程序員能力不夠，而是說是否有足夠的管理機制、管理辦法鼓勵這些程序員，可讓他們不斷提高，或者說不斷投入在這個事情上面。

由於在我看來，國內不少的互聯網公司仍是在積極進取開疆擴土的階段，不管是業務導向或運營導向都會要求程序員要去解決大量的眼前的問題。其實一個好的開源組件不只僅是你作出來了，最重要的是你能不能把社區維護起來，能不能把你們對這個組件的熱度維護起來。不可以持續地輸出更新、保持迭代，這個是大部分國內的前端的框架和組件遇到的困難。

若是說這個問題能夠解決，我相信國內仍是會拿出一些蠻出色框架，讓更多人去使用。據我所知，國內不少原來自己在一塊兒給公司提供前端標準的團隊慢慢也拆散了，我也但願有一天國內的公司能夠作出一些調整，可以專門有一個團隊，爲了行業去提供和設計這樣的一些技術能力。

但國內可能還不如國外有這種技術的氛圍。我問過React的團隊，我問他爲何Facebook願意鼓勵他們作這樣的事，他們也講到了一些點我以爲頗有意思：由於開源React能夠解決他們招聘的問題。

壹佰案例：經過開源React去解決招聘問題？

陳子舜：React在Facebook內部也醞釀漫長時間，甚至有一度中止更新，後來也是有志的程序員拿出來從新改良後推出。其實經過這個案例咱們就能夠看出作開源框架須要長期的投入。你作的React好用，讓更多開發者去用，這些開發者確定都懂得React，招聘後也減小人才培養的成本，同時不少人也會慕名而來，你們會抱着這樣的想法，原來React是Facebook推出的，那我願意去加入這個團隊和他們一塊兒工做。這也造成了必定的人才招聘的氛圍。

---

本文轉自「壹佰案例」公衆號，原文連接