自主研发一款浏览器内核的难度到底有多大？ 第1页

来来来， 让写过内核的人给你们聊一聊 ^^

其实内核分类啥的，真的没有那么复杂。 要了解难度啥的， 看看浏览器本身发展的历史会清楚很多。

浏览器的内核从头开看的话， 其实并没有那么多。 Google 的 Blink 来源于 苹果开源的 Webkit，而苹果的开源的 Webkit 来源于 KTHML, 属于 KDE 的一部分, 而 KDE 基于的 QT, 是 Trolltech 开发的， 很多 KHTML 的贡献者其实是来自于 Trolltech.

因此，Google Chrome 和 Safari 这个分支其实是来自于 Trolltech .

很多人不知道的是， Trolltech 也是一家挪威公司, 而且就在 Opera 的楼下。 他们是四楼， 我们是五楼。 我刚加入 Opera 的时候， 他们还和我们共享食堂。很多员工彼此都是好朋友，连代码都是部分共享的. 因此 KTHML 和 Opera 的自有引擎 Presto 架构非常类似。

现在你看到了吧， 内核架构其实就三个分支

• KTHML, Opera -> Webkit -> Blink (Chome, Opera, Safari)
• Netscape -> Firefox
• Trident or whatever -> IE

两个系列是美国的，一个系列是挪威的。

然后有人就要问， 美国做这些东西很正常， 毕竟 IT 起步早，发展快。为啥挪威这种莫名其妙的国家也做浏览器， 还做得风生水起的。。

很大程度上和这个兄弟有关系。这个兄弟叫 Haakon Wium Lie, 也是个挪威人, 发明了 CSS. 然后做了 Opera 的 CTO.

Haakon 在 W3C 的影响力非常大， 毕竟 CSS 之父。 于是带了一大票挪威人在 W3C 里面制定标准。 当年我旁边办公室里面随便拎一个出来，都是 W3C 某个讨论组的主席啥的. 然后事情就比较有意思了。 CSS 规范里面其实非常多的地方定得非常的绕。 如果你去看 Opera 里面的一些 CSS 实现方法， 你会发现实现的非常优雅。而其他浏览器就更像七拼八凑出来的。这让我非常怀疑，其中这些规范是 Opera 实现好了， 再提出来的 ...

现在看清楚了吧。从历史原因来说，美国有资本优势，毕竟互联网泡沫还在, 而挪威有标准影响力。其他任何一个国家研发浏览器在那个时候来说， 都是费力不讨好的事情。

从技术上来说，浏览器研发的难度更多的像是一个系统工程。浏览器的各个组件研发难度其实都不大。

包括很多人认为的 Javascript engine。 其实除非像 V8 那样子往死里面优化，单纯的 javascript engine 其实相当独立且并不复杂

Opera 里面很长一段时间做 javascript engine 就一个人。javascript engine 和浏览器之间的耦合非常标准， 所以做 javascript engine 和 浏览器其他部分的人几乎没有交集。于是这个哥们长达数年时间， 自己跟自己开会，自己跟自己汇报，自己定计划。 最后离职的理由是和其他部门交流太少，实在是太孤独。。

做为系统工程，浏览器最大的挑战的是浏览器承载的网页是不确定的，虽然标准还在， 但是扛不住无限种可能。

比如你并不知道在明天在世界某个角落的人会不会发精神病在页面里面写上一万个 canvas. Opera 当年为了追求小巧， 解析器用的是简单的递归下降。 于是你也不知道是不是有一个精神病会写上一万层标签嵌套搞挂你的栈。

而无限可能带来的另外一个问题是： 你在解决一个新的可能时。你怎么知道没有搞挂另外一个已经解决过的可能呢？

如果是非主流浏览器， 解决这问题事情都需要靠暴力的， Opera 因为做得早，积累了非常多的回归测试。我记得放弃掉 presto 的时候， 大概 14 万个测试用例， 有一个服务器集群每天晚上都跑。 新的提交要是出现了回归，集群马上把报告用邮件自动发给提交者。

如果是主流浏览器，那就好办多了，只需要保证满足标准就行（比如 chrome)， 或者不要自己砸自己老版本的浏览器（比如 IE). 因为网页反过来， 会来适配你，

于是如果你要研发一个浏览器内核，那你肯定是从 “非主流浏览器” 浏览器开始，要不然你像 Google 一样，找一个 “主流浏览器” 的内核二次开发，然后强行推广成为一个主流浏览器。

要不然就像 Opera 一样暴力解决。。

而技术本身，相对于系统工程本身，并不是很大问题。从某种意义上面，这和操作系统蛮类似的，不同的仅仅在于，浏览器需要适应无限可能的页面，而操作系统需要适应无限可能的硬件。

而我非常怀疑国内有任何厂商有耐心来做这个事情 。。。

[1] WebKit - Wikipedia

[2]The Qt Company - Wikipedia

泻药

第一个，补充点内容

blink 基于 webkit，讲道理，两者大体一致，无非前者把 webkit 中相关类换成 chromium 与 v8 相关的，并在此之上扩充。

trident 太老了，现在是 edge 了，甚至微软当年还有个 tasman 呢。

这是渲染引擎，还得配上脚本引擎，浏览器上用的，现在大致上是 v8、jsc 、spider monkey（各种猴子就是）、chakra 这几个。

其实脚本引擎实现也不少，比如古老的 rhino，adobe 给 AS 用的 tamarin 什么的。

之前 Opera 自主研发内核时候，还有 presto 配 futhark carakan 啥的。

可见，这么多种，绝对不是蝎子拉屎独一份的，最起码不是难上天儿的。

但，关键就是在你词儿上 “在保证兼容性的情况下”，为它付出的代价可能就比较大了。

甚至大到不仅现在乱七八糟的不断变更推进的规范得烂熟，还得历史情况也门清儿。

相当于接手了一堆不断变更的开发需求不说，还得把几乎在没文档、没源码的情况下，把祖传20年功能连带 Bug (还是叫特性得了)全都开发出来。

着玩意是个巨大门槛啊。

连 Chrome Firefox 当年都没完全这么干，他们是扯着规范的虎皮，几乎不管 IE 祖传的那点玩意，把 IE 给弄残了才起来的。相当于另起炉灶了，等占有率差不多了，再慢慢的搞兼容 IE 常见的那点祖传玩意。

反观当时的 Opera，跟着规范，跟着 IE 的祖传走，最后是在弄不动了，市场占有率也不行，终于扛不住切成 chromium 核了。

所以内，第二个问题就看这个好了 国内三大巨头BAT为何不开发一个浏览器内核？

主要是费力不讨好，

事实上浏览器的内核的各个模块都有开源或者替代项目。

粗略来讲，一个浏览器内核可以由以下模块组成：

1、HTML和CSS解析器和DOM

2、排版引擎

3、JavaScript脚本引擎

4、HTTP协议引擎

其中1、3、4的个人开源项目一大把，所以说，给一个团队足够的资源做出来不存在难度，当然性能什么的那就另说了，尤其是现在对JavaScript这门坑语言各种黑科技的优化策略。

排版引擎涉及的坑略多，但非要说，金山就有一个排版引擎，改改也不存在难度。

但是做这个东西的好处则几乎没有，如果现在还是2G时代，移动端有带宽硬限制需要定制浏览器，还有UC之类的东西的市场。

更何况，这东西不是做完了就完了的，还要养一个可观的团队持续不断地改进和升级维护。如果不这么干，想想IE当年95%的市场份额是怎么崩溃的？

现在浏览器内核只有三家，Trident/Edge，Mozilla/Gecko，WebKit/Blink，原因也很简单，微软和苹果是因为自己做GUI操作系统，排版引擎不在话下，浏览器内核作为基础服务也必须提供。Mozilla/Gecko本来是要死的，谷爹一看不行，哪天软软果果联合起来一脚把我踢出Web标准委员会（W3C/WHATWG之类的组织），我特么一个做互联网内容的还不被他们俩玩死？就像后IE时代这些年前端被浏览器大佬们玩的欲仙欲死一样。所以硬是搞成了现在的三足鼎立，当然谷爹后来亲自下山撸袖子，那已经是后话了。

技术难度是其一，既然是商品，市场生存才是最难的。

前段时间不是风风火火的说三体降维吗。其实还有一种是黑域，就是降低本产业的利润率，影响其他外部竞争对手，导致其对本领域视角是食之无味弃之可惜。目的：一方面大幅降低产业外来冲击，但同时另外一方面，还会吸引周边资本考虑如何利用好此低成本商品，形成大量的交换活动，这样商品才具备了更高的价值。