The latest technical report and future development direction of the Chromium Blink project, chromiumblink

Last Update:2014-11-15 Source: Internet

Author: User

Tags xslt

Developer on Alibaba Coud: Build your first app with APIs, SDKs, and tutorials on the Alibaba Cloud. Read more ＞

The latest technical report and future development direction of the Chromium Blink project, chromiumblink

Abstract: BlinkOn3 was just held in Google's MountainView office in May November. This article selects several topics of BlinkOn3, such as SlimmingPaint, a Blink scheduler with multiple priorities, oilpan garbage collection mechanism, using JavaScript to develop new DOM features, and so on. We will share with you the progress and future development directions of the Blink project.

Original article, reprinted, please indicate the original source as a linkHttp://blog.csdn.net/hongbomin/article/details/41091679.

Latest Blink Technology

Based on the topics discussed at the BlinkOn3 meeting, we can get a general idea of the latest progress of the Blink project and the future development direction. In general, optimizing Blink's image performance and memory consumption on the mobile platform is still the top priority of the current Blink project and the top priority of the whole Chromium project. In addition, webApp User Experience Improvement, code security and robustness improvement, and continuous code reconstruction have always been paid much attention. Here we have selected several topics and try to give a brief analysis of the problems to be solved and their solutions.

Slimming Paint: the Slimming Action of the drawing to the end

Slimming refers to the meaning of losing weight, which is very vivid. Blink projects have been striving to improve the Drawing Performance for a long time. For example, the introduction of enable-impl-side-painting technology will free the page content from the main thread, the Compositor thread schedules heavy drawing tasks in separate threads, while the main thread only needs to record the drawing command of the page content into SkPicture and hand it over to the Compositor thread, the overhead of the recording command is much smaller than that of directly drawing the content into pixels. Although the Implementation drawing can effectively reduce the burden on the main thread, looking at the rendering pipeline of the entire Blink, there are still many problems.

First, the problem of render Layer Management in the Blink page. Blink has always followed the early web kit hardware accelerated page rendering framework. In order to make the page display overlapping, translucent, CSS animation, and other content in the correct order, blink will layer multiple renderlayers on the page to build the RenderLayer tree. Each RenderObject belongs to one RenderLayer, but a RenderLayer may contain multiple renderobjects. From the perspective of page synthesis, for memory considerations, not every RenderLayer needs its own independent backend storage, so there is GraphicsLayer, the relationship between RenderLayer and GraphicsLayer is similar to the relationship between RenderObject and RenderLayer. That is, an RenderLayer must belong to GraphicsLayer, while GraphicsLayer may contain multiple renderlayers. When a page is updated, Blink needs to traverse the entire RenderLayer tree, calculate which renderlayers need to be updated, and then call RenderLayer :: paint draws the updated content to the GraphicsLayer. It is easy to see that Blink not only needs to calculate the updated region, but also maintains the RenderLayer tree and GraphicsLayer tree.

Second, there are potential basic synthesis problems on the page. The following HTML page will get the incorrect merging result:

The correct synthesis result should be a green rectangle superimposed on a red rectangle. But the Blink output is that the red color is always above the green color, because the Red <canvas> element has its own RenderLayer, while the <div> element does not have an independent RenderLayer, instead, it shares the same RenderLayer with <body>. The <div> element itself does not participate in overlap detection.

The goal of Slimming painting isRewrite the rendering pipeline of the entire Blink and ChromiumTo solve the two problems mentioned above and improve the performance of command recording and drawing. This is a big architectural adjustment, and the Blink code has a big change to the drawing logic:

The Paint operation will be executed from the RenderObject to a specialized Painter;
RenderLayer and GraphicsLayer will be deleted and replaced with PaintList;
Compositor uses PaintList to perform layer-based operations;

Shows the general process:

In the new rendering pipeline, Blink no longer needs to maintain the RenderLayer and GraphicsLayer. the only thing to do is to generate PaintList for the entire page content through the Paint of each RenderObject and provide the necessary layered prompt information for Compositor. PaintList is similar to DisplayList and contains information such as drawing order, drawing command, transformation matrix, and Clip region. From this information, Compositor can fully calculate how to layer pages.

Blink sched: task queue with Priority Rotation

Blink Scheduler is an optimization led by the Google London team to solve the "congestion" Problem in the task queue. In short, some high-priority tasks are blocked by tasks with low priority and long execution time, resulting in delayed execution of high-priority tasks, thus affecting the overall smoothness.

The tasks of the Blink main thread come from various modules in the system, as shown in. All these tasks are centrally scheduled by the main message loop. Each time a task is published to a message loop, the task is added to the end of the task queue. The message loop extracts a task from the task queue in the FIFO order, then execute the task until the task queue is empty. Therefore, if a high-priority task reaches the message loop, it must wait until all the tasks have been completed before it can be executed.

Blink Scheduler is trying to solve the above problem by introducing multi-priority task queue. Each task has a priority, and the message loop adds the task to the corresponding Queue according to the priority. If you only specify a priority for each task, A possible problem is how to resolve dependencies between tasks. For this reason, Blink divides tasks into three categories: 1) Compositor; 2) Default; 3) Idle, among them, the Compositor task has the highest priority, the Default task is the second, and the Idle task has the lowest priority. Execute tasks by priority. However, if you specify a Compositor task statically, the page loading performance is reduced by 14%, which is obviously not desirable.

Therefore, Blink sched uses a context-aware Dynamic Priority Policy, for example,

When a user interacts, the Compositor task is more important, and the resource loading task is less important. This increases the priority of the Compositor task to the highest level;
When browsing the page, the resource loading task becomes important, followed by the Compositor task, which increases the Default task priority to the highest;
When a new frame is started, the Compositor task has the same priority as the Default task;

In terms of implementation, Blink schedum will make significant changes to the underlying code of Chromium base/message_loop, as well as the abstraction of BlinkScheduler at the content level, to schedule multi-priority task queues, you can publish tasks to different task queues, select the next task queue to be processed, and dynamically modify priority policies, as shown in:

Oilpan: Blink exclusive automatic garbage collector

The background introduced by the Oilpan project is that Chromium sometimes has an inexplicable Memory leakage problem when Browsing webpages. According to the data provided by the Blink Memory Leak Detector (LeakDetector), after accessing 946 websites, ChromiumWebView has 294 WebCore: Document objects not released.

Before the Oilpan project, Blink and Chromium both use the referencecounting technology to manage the memory. Each object has a reference count, indicating how many times the current object has been referenced, when the reference technology is set to zero, the object will be automatically released. This method has always had A defect, that is, the circular reference problem, where A references, and B References, in the end, both A and B are not released. In addition, there are several other problems in enabling reference count in C ++:

Increase or decrease overhead of the referenced counter;
In C ++, the Raw pointer can be used to easily bypass RefPtr management. improper use may result in use-after-free memory errors and security problems;

Although the reference count has some of the above problems, it is very lightweight and still a widely used automatic memory management count in C ++ programs. The Blink project does not meet this lightweight memory management method. Therefore, the Oilpan project has been put on the agenda and an automatic recovery mechanism for Blink objects must be implemented. Compared with the reference of counting technology, the Oilpan garbage collector is indeed a giant. It implements an advanced feature that is generally only required by virtual machines. However, the Blink project strives to keep improving and pursue the best!

Oilpan implements a tracking mechanism for garbage collection, which has the following features:

All objects in Blink will be allocated to a managed heap. Each object provides a trace method to establish the reachable relationship with other objects in the heap. Therefore, starting from the root node (usually the DOMWindow), the Blink object forms an object graph in the managed heap, and the objects that are not reachable by the root node will be GC, this avoids the issue of circular references.
The GC of Oilpan does not occur at any time. It will be postponed to the message loop, because when the message loop executes the last task in the task queue, the Blink stack is empty at this time, no objects are allocated in the stack.
Once GC is required, Blink first needs to ensure that all running threads reach a "security point" without allocating new objects, and then starts from the root node, calculate the transfer accessibility of all objects in the heap, mark all reachable objects (mark), and then each thread starts to clean up the heap space of its own, reclaim all unlabeled objects and insert them into the space list.
Compared with the GC of the V8 engine, the GC of Oilpan involves all Blink threads, Database threads, and File threads. All threads share the heap space of an Oilpan.
Oilpan provides two super classes GarbageCollected and GarbageCollectedFinalized to ensure that their subclasses are distributed in the heap managed by Oilpan.

Up to now, the basic Oilpan framework has been relatively stable. By default, all objects in modules/have enabled Oilpan, but the Node hierarchy has not yet been officially enabled.

Regarding Oilpan, you may be concerned about its performance and memory overhead. There are three points to evaluate whether Oilpan is successful. First, it is faster than the reference count. Second, it cannot degrade the performance. Third, does not increase the peak memory usage. According to the latest performance and memory usage evaluation results, the execution efficiency and memory usage peak are not problems, but the pause time caused by GC is a problem, especially for some animated benchmark, some GC operations on Nexus7 devices take more than 50 ms, which is obviously unacceptable. the next step is to optimize the time consumed by stop-the-world.

ServiceWorker: greatly improves the offline cache capability of Web apps

ServiceWorker is a relatively new Web technology. After absorbing the Event Page mechanism of the ChromePackaged App and learning from the failure of the HTML5 AppCache standard, the Chromium team proposed a new W3C specification, it aims to improve the offline cache capability of webapps and narrow the gap between webapps and nativeapps.

Currently, the offline cache of Web apps is not perfect. Although HTML5 AppCache allows Web developers to specify a list of files that can be cached by browsers through manifest files, this mechanism is not flexible enough, many Web developers complain about the limitations. ServiceWorker tries to change this situation.

ServiceWorker can be seen as an interesting application of Web Worker specifications. Similar to SharedWorker, ServiceWorker is designed for offline use of webapps. It is a JavaScript code that can be installed on a Web site, it runs in an independent Worker context. When a website is accessed, ServiceWorker listens to network requests, such as resource retrieval and updates, and even receives these events offline, web developers can decide how to handle these events in ServiceWorker code.

A typical application scenario of ServiceWorker is that when a website is accessed, the browser downloads resources from the server and displays the webpage to the user in the case of an available network, however, when the network is unavailable, that is, the offline status, if you access this website again, the browser will report Error 404. With ServiceWorker, the situation will be much better, serviceWorker can listen to network request events. Once it finds that it is offline, ServiceWorker will read some memory from the cache and present it to users, so that users can instantly stay offline, you can also use website services to greatly enhance the offline capabilities of web pages.

A page with ServiceWorker installed is called a "Controlled page". ServiceWorker is an intermediate layer between the browser and the server. It can transfer all network requests, including XMLHttpRequest requests to load resources, you can also create and call up all locally cached data, and send messages between ServiceWorker and controlled pages.

Blink-in-JavaScript: use JavaScript to implement new DOM features

Users who have implemented DOM APIs using C ++ should have some hands-on experience. Adding a DOM feature to Blink is really complicated. to implement a new DOM feature, you need to modify the IDL. The IDL interpreter will generate a bunch of C ++ code, and then you have to use C ++ to compile the implementation code of specific features in a fixed mode. As we all know, C ++ code is hard to write, so you need to carefully consider the lifecycle of each object. If you are not careful about it, memory problems will eventually lead to security problems, which leads to low development efficiency, in addition, the maintenance cost will be high in the future.

Blink-in-JS makes it possible for Blink developers to implement new DOM features using JavaScript. The basic idea is to use C ++ to export a set of JSAPI as the basic library as the core part of DOM implementation, based on these existing javascriptapis, try to use JavaScript to implement other DOM parts, such as XSLT, editingAPI, and DOMWindow. atob/btoa and ScriptRegexp. Taking XSLT as an example, Blink's C ++ implementation is very complicated, but in fact it is not used much, mainly for some enterprise-level users. For such APIs that are not very popular or will soon become obsolete, blink-in-JS can remove Complex C ++ implementations from the Blink code base and use JavaScript to implement such APIs.

Blink-in-JS helps Blink developers improve development efficiency and code maintainability, however, the side effect may be that the performance and memory overhead of the APIS implemented by JS are much higher than that of C ++. Therefore, For APIs with high performance requirements, we recommend that you use C ++ for better implementation. For memory overhead problems, the size of JavaScript code that has been JIT passed is 20 times that of the C ++ binary code. The corresponding solution is to enable delayed compilation of JavaScript code, the app starts to compile its JavaScript code only when it requests to call this feature, and the compiled JS Code is discarded after it is used up. The next request needs to be re-compiled, this is actually a compromise.

Taking DOMWindow. atob as an example, the Blink-in-JS programming model is as follows:

// WindowBase64.idlinterface WindowBase64 { [ImplementedInJS]DOMString atob(DOMString str);};// WindowBase64.jsinstallClass(“WindowBase64”, function() { return {atob:function atob(str) { // Here |this| isequal to |window|. returnbase64Encode(str); }};});

The security model is a critical factor for designing and implementing Blink-in-JS. Blink must ensure that Blink-in-JS and application-layer JavaScript code can operate on the same DOM object, make sure that the JavaScript code of WebApp cannot access JS objects in Blink-in-JS. Blink-in-JS draws on the ChromeExtension Security Model mechanism and uses the "world" in the V8 engine to isolate the runtime environment of Blink-in-JS and the JavaScript code at the application layer. In ChromeExtension, World provides a completely isolated JS runtime environment, but different worlds can share all DOM objects through DOMWrapper, as shown in,

Therefore, Blink-In-JS can theoretically reach the same security level as Chrome Extension.

Current Blink project status

In the past six months, the Blink project has a fast evolution speed. From January July to January September, the number of lines of code increased from 2.64 million to 2.69 million, with an average of 52 commit entries per day, the Blink community received a total of 151 Intents contribution requests, of which Google accounted for 51%, and the rest came from the entire open-source community. This figure shows that Blink has developed quite well, the enthusiasm for community participation is still high.

As of March November, Blink has implemented the following features:

Features that have not yet been implemented include:

Summary

This article briefly introduces several important sub-projects in the Blink project. For example, to further improve the rendering performance, rewrite the entire Blink/Chromium rendering pipeline to slim down the Blink drawing, optimize BlinkScheduler for processing high-priority tasks, Oilpan automatic garbage collector for solving unknown memory leaks, and Blink-in-JS to improve development efficiency and code security, and ServiceWorker can flexibly support WebApp offline capabilities. In addition to the above mentioned, there are some other changes that have not been introduced, but have a great impact on the subsequent evolution of the Blink project, for example, the merging of the Chromium code library does not change much if only the file directory is merged, but if the source code level is merged, the changes will increase, including merging base and WTF base libraries, in addition, the original intention of the Project warden project was to reconstruct the Blink code, simplify the layout and drawing processes, and clear various strange problems in Blink, such as Repaint- After-layout, the RenderTree cannot be modified during the typographical process. These changes have taken place or are happening, allowing the Blink project to evolve rapidly. The next step is to focus on performance, especially for mobile devices, and to build a WebApp platform, gradually narrow the gap with NativeApp. At the same time, through code reconstruction and architecture adjustment, Blink code maintainability, reliability, and security are improved, thus improving development efficiency.

Note: all the images in this article are from the Slides of the BlinkOn meeting and are copyrighted by the original author.

Original article, reproduced in the form of a link to indicate the original source for http://blog.csdn.net/hongbomin/article/details/41091679.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

Get Started for Free

Sales Support

1 on 1 presale consultation

Chat Contact Sales
After-Sales Support

24/7 Technical Support 6 Free Tickets per Quarter Faster Response

Open a Ticket
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.

Learn More