对于这次内核升级，我们花了很大的精力，也有很多感触。下面简单分享一下，希望与同行一起探讨。 为什么要基于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 进行绘制所带来的好处在于，我们可以在界面上高效地实现一些更炫的效果。 |
