On the first day of the Qingming Festival holiday, Mozilla and Google announced their new browser engine development plan-servo and blink. In fact, servo has always had messages earlier, and the release of blink is quite sudden. for work reasons, I naturally am more interested in blink (I am not allowed to take a vacation, programmers), and want to know why Google wants to generate a new browser engine (why blink) from WebKit fork ), this will bring about some positive changes (why not blink) to Chrome's future development ).
On the blink official homepage, Google believes that blink's mission is to promote the development of open networks through technological innovation and good Community cooperation (blink's mission: to improve the Open Web through technical innovation and good citizenship ). According to the official developer FAQ, the main reason why Google chooses to develop a new engine instead of following WebKit is:
There are two main reasons why we're re making this change.
- The main reason is that chromium uses a different multi-process architecture than other WebKit-based browsers. so, over the years, supporting multiple ubuntures has led to increasing complexity for both the WebKit and chromium communities, slowing down the collective pace of innovation.
- In addition, this gives us an opportunity to do open-ended investigations into other performance improvement strategies. we want web applications to be as fast as possible. so for example, we want to make as much of the browser's duties run in parallel, so we can keep the main thread free for your application code. we 've already made significant progress here -- for example by grouping the impact JavaScript and layout has on Page scrolling, and making it so an increasing number of CSS animations can run at 60fps even while Javascript is doing some heavy-lifting -- but this is just the start.
We want to do for networking, rendering and layout what V8 did for Javascript. Remember JS engines before V8? We want the same sort of healthy innovation that benefits all users of the web, on all browsers.
In the multi-process architecture, Google developed a sandbox multi-process architecture independently from the very beginning, which is very different from the apple-led webkit2 multi-process architecture, to support the webkit2 architecture, a large amount of WebCore code is added, which is not only useless to Google, but has to spend time dealing with compatibility issues, google needs to modify WebCore to support its own architecture code, and it is difficult to enter the WebKit trunk. It must be careful to avoid affecting other ports. A large amount of code has to be processed externally in a roundabout way, some features that cannot be processed externally and require major changes to WebCore have to be abandoned temporarily.
In addition, due to historical reasons, WebCore itself has no multithreading or multi-process concept at the beginning, and the existing architecture is very difficult to support parallel processing, google also believes that it is necessary to make major changes to the overall architecture of WebCore to better support parallel processing and make full use of the capabilities of multi-core CPUs, avoid the congestion of the main thread (although most of the current WebKit ports are separating the main rendering work from other threads, the main thread still needs to handle HTML parsing, CSS style calculation, matching, and formatting, to prevent a single task from blocking the main thread for a long time, WebCore uses the timer method to split a complex task into multiple parts for sequential execution, this method is not elegant and cannot fully utilize the capabilities of multiple cores ).
In addition, the current modularization of WebCore is chaotic; some legacy code and code used only to support some specific platforms make The WebCore code bloated; there is no unified standard or method for platform-related processing, and there is no good abstraction layer to isolate platform-related and platform-independent parts; webCore causes
Additional performance overhead and impede JS Performance
More improvements; in addition, more secure isolation mechanisms; larger structure optimization for the existing network layer, and so on, are also the main reasons why Google needs to develop its own blink.
In short, Chrome has many radical improvements that require major changes to WebCore. However, the original method of saving the nation by curve is no longer feasible. In order to be able to take the lead in the evolution of the architecture, to avoid mutual interference with other ports, and to ease the troubles and pain of both sides, speed up the development, and separate the WebKit trunk, it is an inevitable choice to develop a new browser engine.
From the perspective of chrome developers, all of them are excited --
"This is so exciting! We should have done this long ago !" "In the future, I will try to change it if I want to change it. If I want to eat sugar, I will eat sugar. If I want to eat vinegar, I will eat vinegar, I don't need to talk to those guys any more. I don't know. "" since I used blink, it's not painful, and the month is easy... so easy! Mom no longer needs to worry about my learning ..."
Http://infrequently.org/2013/04/probably-wrong/ https://plus.google.com/u/0/116560594978217291380/posts/AeCnq76cAXb https://plus.google.com/u/0/105497998876878526147/posts/etnTiaXZEGM https://plus.google.com/u/0/116237864387312784020/posts/d62jMDKXcLb
