對于這次內核升級，我們花了很大的精力，也有很多感觸。下面簡單分享一下，希望與同行一起探討。

為什么要基于Chromium做二次開發？

肯定會有很多人好奇，為什么國內的雙核瀏覽器都是無一例外地基于 Chromium 開源項目做二次開發。其實，根本原因在于，以 Google 員工為主的 Chromium 團隊在該項目上做了大量的技術創新。像 DNS Prefetch、SPDY、QUIC、預渲染、多進程架構、PPAPI、v8 JavaScript 引擎等都是很好的技術創新例子。

二次開發的策略使得能借助這些技術創新給用戶帶去更好的上網體驗，同時又避免了“重新發明輪子”這種勞命傷財之事。

即便如此，我們團隊對于二次開發的實施理念與其他廠商有著明顯的差異。有的廠商只考慮國內市場，有的則考慮全球市場，所以我們在二次開發時還需要考慮語言本地化等諸多跨國因素。

為什么要快速跟進 Chromium 項目的發展？

我們團隊將快速跟進 Chromium 項目的發展作為重要的技術開發戰略。從用戶層面來看，Chromium 每一個大版本的出現都會在性能、軟件結構和安全上做優化，且會修復一些嚴重影響穩定性和安全性的缺陷，快速跟進其發展步伐意味著能讓用戶盡早享用到這些益處。從技術層面來看，快速跟進也有極大的益處，在此列舉四點：

***點是能逐步提升軟件的開發效率。由于 Chromium 項目的規模非常龐大，因此不斷提升開發效率是該項目的一個永恒話題。為此，Chromium 團隊一直致力于改善項目的編譯效率問題。比如，在采用 Chromium M32 的時期，我們只能用 Visual Studio 2010 進行編譯，當我們升級到了 Chromium M35，我們就完全采用 ninja 這一更高效的工具完成編譯工作。

還有，現在我們全是采用 gyp 來實現跨平臺的工程源文件管理，按 Chromium 團隊的規劃，今年年底會用更為高效的 gn 取代它，如果我們不能快速跟進就沒有辦法盡早分享這一好處。

第二點是有助于提高解決軟件缺陷的效率。一旦發現 Chromium 的缺陷后，我們除了自己立即著手修復外，還會向 Chromium 社區報告缺陷，通過與開源社區協作的形式加速解決問題。如果內核版本不快速跟進的話，就會因為 Chromium 社區不理會老版本中的缺陷而無法獲得他們的協助。

我們團隊所修復的一些缺陷會通過告知解決方案或直接 upstream 的形式提交給 Chromium 開源社區。這不僅幫助社區解決了問題，更方便了我們下次的內核升級工作，因為如果不將這些代碼提交到 Chromium 的代碼庫，下次升級到新版本做代碼合并時就可能面臨新的沖突點。

第三點有助于持續優化代碼質量。Chromium 項目的每個新版本較前一個版本的代碼變更量都很大，其中很重要的內容是對代碼質量持續改善。假設一開始我們的軟件設計是基于 Chromium 老版本中的技術方案的，當 Chromium 在新版本中對該技術方案進行了優化后，升級上去就意味著我們得調整原始設計以適應新的技術方案。這就迫使我們跟著 Chromium 的腳步對自身代碼持續改善，一定程度上有助于避免“技術債”高筑。

第四點好處在于，通過快速跟進有助于幫助網站的建議者在他們的網站中盡早運用上新的技術。某種程度上這也是幫助推進新技術的普及。

盡管快速跟進 Chromium 的發展步伐能帶來諸多好處，但并非每個廠商都能很好地實施這一技術開發戰略。原因在于，快速跟進是需要從技術層面以出色的軟件設計做保障。

比如，我們在 Chromium 的原生代碼中做了超過 3600 處改動、增加了超過 2500 個文件，如果不通過出色的軟件設計將這些變更與 Chromium 的原生代碼做很好的解耦的話，那每一次內核升級對開發團隊都會是一次災難，因為工作量實在是太大了。

Chromium 35 的另一大飛躍是實現了圖形界面的全面 Aura 化。Aura 是一個窗口管理框架，用于實現界面上的像按鈕、滾動條和對話框等界面控件。在沒有 Aura 之前， Chromium 針對每個操作系統都做了封裝，然后上層應用直接建立在這個封裝之上去構建，以便實現跨操作系統的功能。

有了 Aura 之后，Aura 被設計成跨操作系統的，上面的應用轉而構建于 Aura 之上。更為重要的是 Aura 在軟件設計上做了很大的簡化，且實現了使用顯卡的 GPU 對界面進行繪制。利用 GPU 進行繪制所帶來的好處在于，我們可以在界面上高效地實現一些更炫的效果。

在快速跟進 Chromium 項目中我們走過的一些彎路

其實，在從事瀏覽器電腦版的開發歷程中，我們也走了一些技術彎路。這些彎路，使我們非常苦逼的停留了一段時間，但也讓我們實現了質的突破。在此我想分享幾則：

首先，***的一個彎路在于忽視 Chromium 的軟件架構。結果使得工程師在修改代碼和增加文件時很混亂，程序的可維護性很差。這一痛苦經歷讓團隊深刻地認識到維護清晰的軟件架構有多重要。目前整個團隊在日常工作中都非常重視這一點，對這類問題的敏感度很高。

另一個彎路體現在我們之前的做事方法上。在進行軟件功能開發時，工程師以前很容易一拿到需求就根據自己的理解立馬上手開干，以至于做了不少“重新發明輪子”的事。后來我們發現，開發新功能所需的不少基礎模塊 Chromium 中已有，于是我們在 UC 瀏覽器電腦版 1.0 版的開發過程中不斷地將“自己發明的輪子”給去除，用 Chromium 項目中現成的取而代之。

我們團隊現在養成的習慣是先看一看 Chromium 中是否存在可復用的部分，之后再干。這種做事方法表面上看起來慢了，因為要花時間去學習和研究，但長遠看來利大于弊，除了通過該方法能不斷加深對 Chromium 項目的熟悉外，所編寫出的代碼更容易升級至新內核。

***我想分享的一個彎路是軟件設計的解耦方法。我們以前所采用的解耦方法一是很難規范化，二是難以與 Chromium 的新內核進行合并。現在的解耦方法除了規范化很容易做到外，使得在合并代碼過程中對于各沖突點總是存在“明亮的燈塔”在指引。

實際上，我們所采用的解耦方法很簡單，用一句話總結是“無論在 Chromium 之上是增加、調整或去除功能，我們在代碼層面總是做加法”。這句話不好理解，但我也只能透露到這個層面。

我的角色轉變及對技術管理的一些看法

過去的日子，我個人也在這個項目上也完成了一些角色轉變。我當初應聘阿里巴巴時，在簡歷上寫的是希望將來成為互聯網行業的技術專家，當時楊過面試我時問了一個問題——“如果需要你做管理怎么辦？”我當時回答說：“只要能更大程度地發揮自己的作用就會考慮”。

加入淘寶瀏覽器團隊之初，雖沒有定義我的管理角色，但一開始我就有意識主動承擔部分技術管理工作，只是當時給自己的定位是架構師。如今，我在團隊中官方地正式承擔管理責任，這完全是因為團隊的需要，因為這能從更大層面發揮我的影響力。

技術管理工作有不少瑣碎的事，使得工作時間被更多地碎片化了。在我看來，要做好基層技術管理工作必須對技術細節有很好的掌握，否則難以發揮管理效能。另外，只有了解技術細節，才能更好地理解工程師的開發工作，否則很容易犯那種一談技術就說“這個實現起來很簡單”的毛病。

對于我來說，掌握技術細節是了解和欣賞工程師的關鍵途徑。最近我在做 Chromium M36 的內核升級工作時碰到一個問題，在解決它的過程中發現我們團隊的小盤同學在之前己解決，而且他實現的技術方案極其簡單，簡單到只需注釋掉 grit 工具中的一行代碼就實現了一個很重要的功能。我一了解這一細節后，立馬起身走到他的工位上，告訴他這個技術方案真的很精彩！

如果不是因為我關注技術細節，光從他最終只改了一行代碼就很可能得出“這個實現很簡單”這一結論，這種片面結論除了抹殺他在被后可能花了數小時研究***方案的努力外，更讓我失去了一次欣賞他的機會。

作為一名還算資深的工程師，我深深地知道真正能培養出好工程師的方法不是采用股票、工資就能實現，也不是給他們“打雞血”，而是讓他們在工作中體會到成就感、在專業水準上不斷有進步，從管理層面理解和欣賞他們是非常關鍵的一環。正因如此，我在整個開發團隊中明確規定，基層技術管理者必須在工作中持續地有技術貢獻。

做技術管理***的樂趣在于看到團隊在不斷地進步、感受到大家對自己的信任、聽到自己的理念被他們用于討論問題、看到自己的工作方法在發揮作用，這種感覺真的很棒、很享受，一點都不比解決技術難題所帶來的“爽”遜色。當然，過程中也會碰到困難和壓力，但在這種相互欣賞與理解的團隊氛圍中能得到克服。

作為技術管理者，我認為身上最重的擔子是責任。我衷心地希望工程師在這個團隊中能不斷地進步，這樣在以后職業生涯中無論他們在哪一個團隊都更具競爭力。要實現這樣的目標，一定需要技術管理者在工作中不斷地為他們的成長提供環境和給予幫助，這也促使我在工作中不斷地有所作為。

本文鏈接：http://www.36kr.com/p/214068.html