Abstract The goal of this project is defining and understanding a conceptual architecture for the Google Chrome browser. Our team developed a conceptual architecture through research of developer documentation, video documentation/developer interviews, and observation of reference architectures of other browsers. Through research and analysis, our team has come to an agreement that Chromium’s architecture consists of a semi-strict layered design at the high level, and an object-oriented style at the lower level. Chromium’s architecture consists of different subsystems and subcomponents, which are defined in the report, as well as their interactions with each other and their purpose. Three use-case scenarios are also depicted to further characterize their interactions in standard browser use scenarios. The research and understanding developed through visualizing a conceptual architecture for Google Chrome will help pave the way to establishing a final concrete architecture for the popular web browser.

Derivation Process Through the derivation process it was decided to work with the Mozilla Firefox architecture as it closest resembles the chromium architecture. Reading through the chromium developer documentation our team was able to get a thorough understanding of the material. The google developer videos were an excellent supplement to the documentation which bridged the gap with visual explanations and demonstrations. Bellow you can find a sample Mozilla FireFox conceptual architecture.

Alternative Architecture

As part of our derivation process, we decided to come up with a simplistic alternative architecture to expand on. To do this, we imagined the simplest way chrome could lay out a web page, so we could essentially figure out which dependencies are set in stone and likely to be present in our final architecture. Using this thinking, we came up with a strict layered architecture as shown in the figure below:

This architecture uses many ideas from Chromium source documentation1 , but more importantly, makes sense intuitively.

Browser: If you imagine the physical chrome browser itself, it’s easy to imagine it in a top down manner. At the very top is the Browser layer, which is responsible for any function that essentially can’t be handled by a tab, such as switching tabs. Due to this, the browser directly depends on tabs, which we have real evidence of: if you close your last open tab in chrome, your browser will close too.

Web Contents: The tabs would be kept in in the Web Contents layer, which would control things such as navigation, and as well have the ability to talk up to browser to find out thing such as search 2 2 history . Due to this, the browser would implement a delegate to allow Web Contents to 1 http://dev.chromium.org/developers/design-documents/displaying-a-web-page-in-chrome 2 https://www.youtube.com/watch?v=IiN9fxwjcL0&t=400s

communicate with it, but Web Contents itself is not dependent on Browser, e.g you don't necessarily need a browser window to have a tab. The web contents layer is also responsible for sending messages to render host when something needs to be rendered.

Render Host/Renderer: At this layer we start to see evidence of Chrome’s multi-process architecture. The Render Host lives in the browser process(along with Browser and Web Contents), where as the Renderer(s) would reside in the renderer process ( along with Blink wrapper and Blink). The Render Host receives messages from Web Contents and is responsible for identifying the right Renderer to send it to, as well as relaying the relevant rendering information3. These layers should know nothing about the Web contents or Browser, e.g you could detach theses layers 2 and re attach them to any browser that supports multiprocessing .

Blink wrapper/blink: At the bottom layers we have the Blink Wrapper and Blink itself. Blink has its own abstract platform4 and thus would not have any dependencies within chrome, so in a strict layered architecture it must be at the bottom. It receives rendering messages from Render Host with help of the blink wrapper, which aids in communication and things such as type conversion 2 .

Using this is a basis for component interaction within Chrome, we were able to come up with our final conceptual architecture

3 https://medium.com/@zicodeng/explore-the-magic-behind-google-chrome-c3563dbd2739 4 https://www.chromium.org/blink

Conceptual Architecture:

Sub-Components

Blink:

Blink is the rendering engine of google chrome, it is responsible for rendering almost all content inside a browser tab. It has the responsibility for implementing the HTML standard specs, including DOM, CSS and WebIDL. It is Since it does not render JavaScript by itself; it is embedded within V8 allowing it to render and process JavaScript pages. Due to its layered architecture, Blink is also responsible for requesting resources from the network stack. Relying on a multi-process architecture chrome has one dowser process which sandboxed rendered processes, where a certain number of memory addresses are reserved for the single process. Blink being a sub-process has to rely on the browser process for system calls and accessing user data.

V8:

Is a high-performance JavaScript and WebAssembly engine used for chrome which is entirely written in C++. Due to the nature of its architecture it can support multiple platforms from windows, OSX and Linux systems, implementing ECMAScript and WebAssembly. Its main responsibility is to compile and execute JavaScript code, ensuring memory allocation of objects, maximising performance.

LibXML:

Lib xml is a general XML parsing tool which helps compile and execute XML documents; written in C.

Skia:

Skia is a opensource graphics engine which works in conjunction with Blink in order to implement backend graphics for google chrome’s browser. It enables graphic rendering both using a given computer’s GPU or CPU; whichever is more efficient.

Network Stack:

Google chrome has a single-threaded network stack which ahs the main responsibility to interface URL requests and storing all the necessary information to fulfill URL requests such as cookies and cache. This architecture enables for cross platform abstractions; windows, OSX and Linux.

Dependencies

The user interface, or UI, is what the user directly sees and interacts with. The UI depends on two major components; the browser and the display backend. It depends on the Views subsystem (in the display backend) to acquire the general layout and interface of the current webpage. This subsystem depends on Skia, the graphics engine, to load in images, graphical objects, text, font, etc. to give the UI the visual content the user wants to see. The user interface also depends on the browser to be able to function. The browser engine enables the actual functionality of the web page, which is why it depends on the rendering engine, Blink. Within the browser we also have plugins and data persistence, which is information that is saved at the user’s permission to be accessed later (such as saved passwords and personal information, cookies, and history). The browser depends on the network component as well, because it communicates with the network stack to access information specific to the current webpage/website that the user is on. The rendering component contains the XML parser (libXML), and JavaScript Interpreter (V8). The rendering engine, Blink depends on these to be able to convert code into information that the browser engine information can intake, and then pass onto the UI to render and add functionality to the webpage. Blink is also dependant on Skia so that it can render content onto the webpage (using a bitmap). Blink also depends on the network, to communicate with the network stack to fetch page information and for general page loading.

Use Cases

Figure 1: Use case scenario for user successfully logging in to a website

The user inputs a URL into the user interface. A URL request is sent to the browser, where it checks if the user-inputter URL is stored in the cache. In this situation, it is not, so the browser fetches the URL data from the network stack, and saves it in the cache.

This URL data is then passed to the rendering engine, which then sends a call to render the page bitmap to the display backend subsystem. The display backend then proceeds to render any text, graphics, and layout information of the page, passes back a bitmap to the rendering engine, which then sends this to the browser.

The browser subsystem sees a password text field, and checks the password database to see if any password is stored for this URL. In this scenario, a password is not saved in the browser database, so the UI displays the page to the user and prompts them to enter a password. Once the user inputs a password, the browser sends this password to the network stack to confirm that the user-inputted password is valid. The response is then sent back to the browser, which saves the inputted password in a database, and displays a successful password attempt message to the user.

Figure 2: Use case scenario of Chrome rendering a page that contains JavaScript

In this use-case example, a closer view of the rendering component is displayed, in order to conceptualize the process of displaying a page with embedded JavaScript. Much like the previous use-case scenario, the user enters a URL into the UI. This is passed to the browser, which checks to see if there is a saved version in the cache, which there is not. The browser retrieves the page information from the network stack, and sends this data back to the browser. The browser then forwards this page data to the blink subcomponent, which sends a request to the display backend, to render text, graphics, etc. The blink subcomponent then receives the bitmap, which it passes to the JavaScript Interpreter, which interprets any JavaScript embedded in the page, before sending it back to blink, where the URL bitmap is passed to the browser engine and is displayed to the user.

Chromium Team Issues

Throughout the development of Chrome, much like with all other software and projects of the like, many roadblocks for the developers to overcome were encountered. From issues as small as having interfering processes to having to entirely rebuild the software for compatibility, the Chrome developer team went through quite the suite of problems. In the following paragraphs, we will dive into a few of these issues.

In the early stages of development, the developers set out with plenty of goals and ideas in mind. One of the most notable being tackling the early 2000s “best view in browser x” issue that was ever prominent. At this stage in the world of online web browsing, with a slew of content types and browsers tailored to view these types of content spawning into existence, users were beginning to find it more and more difficult to appreciate their content in one simple browser. Many webpages would show this “best viewed in browser x” banner as a warning to users that the content may not load appropriately on their current browser. Thus, Google embarked on a mission to overcome this dreaded message. To do so, they’ve worked closely with other browser distributors, the World Wide Web Consortium Committee and web developers to ensure content can be viewed easily and pleasantly on Chrome.

Originally, Chrome was built to run solely on the Microsoft Windows operating system. This may have seemed like a decent idea at the time, as Windows was the most prevalent operating system of the time and few signs were showing that changing in the foreseeable future. Of course, this had it’s benefits as it helped the team focus its efforts on the real-world use of Chrome and ensuring they met their goals of simplicity, speed, security, and stability, without the overhead of worrying about cross-platform issues. However, this (obviously) came at the cost of having to rebuild their entire program in order to branch out to other operating systems and platforms such as MacOS, Linux, and mobile. Having to do so definitely held up progress for updating Chrome and its features as the team had to focus its attention on redeveloping Chrome for cross-platform compatibility. With the attempt of providing cross-platform compatibility came plenty of other issues specific to each platform. For instance, porting to iOS came with the added issues of adapting to iOS changes such as the shift from UIWebView to WKWebView to display web content.

For a more known and persistent issue, Chrome has been known to consume a substantial amount of RAM when compared to its competitor’s browsers. Over the years, the Chromium team has come out with multiple reasons as to why memory consumption has been an ongoing issue for Chrome. Some of theses have been lack of garbage collections measures to properly tackle memory management, added features to the browser experience, extensions running in the background even when not in use, and for added security. Though these issues have been addressed over the years, Chrome still maintains being a heavy memory consumer - offering plenty of great features, but at a high cost.

Lessons Learned

Throughout the research, collaboration, delegation and all of the rest of the work that went into completing this paper, we’ve learned a great deal about the development process for software and the importance of the architecture and design that aids development. To begin, we learned that there’s an abundance of resources and information on Google Chrome. Whether it be info on the development, the conceptual architectures driving browsers, or even the most minute detail that went into Chrome, its well documented and available for consumption.

Due to this surplus of documentation, we had to learn the skill and importance of narrowing our research scope to focus on those pieces of information relevant to us. Without this, we would’ve spent countless wasted hours mulling over every fine detail of Chrome and its development, without properly grasping the information most pertinent to conceptual architectures. With this, we also had to ensure we were doing all we could to find the most current information on the topics we were covering. Though older information may still be fairly helpful when attempting to understand the inner workings of Chrome’s development and the changes to its individual components that have occured over the years.

Overall, we found that there is much more that goes into developing a piece software, which we may not have originally thought would be part of the process. As well, we learned that research (for both us and the developers) is an incredibly taxing task, but also a task whose value should not be underrated nor overlooked.

Conclusion

In conclusion, through extensive research and analysis, we have derived a conceptual architecture for the Google Chrome browser. Our derived architecture consists of five major components, each with their own subcomponents and subsystems. An investigation has been conducted on what the purposes of these components/subsystems are, and how they interact with each other. We have established that the browsers architecture is a semi-strict layered style at the high level, with an object-oriented style at a lower level within the subsystems.

Due to Chrome being open source, modular, and having a strong focus on code reuse, it is evident how Chrome has set a new standard for web browsers, and why so many browsers have taken after its design. The information gained throughout this report will prove to be substantial in deriving the concrete architecture of the browser, and it will be interesting to see how our derived conceptual architecture will correlate with the final concrete architecture.

Sources

Chromium Team Issues

● https://blog.chromium.org/2016/01/a-faster-more-stable-chrome-on-ios.html ● https://blog.chromium.org/2018/09/how-we-designed-chrome-10-years-ago.html ● https://www.forbes.com/sites/gordonkelly/2018/07/14/google-chrome-ram-memory-cons umption-spectre-security-upgrade-windows-mac-linux-chromeos/#3c1fa6e61777 ● https://www.macrumors.com/2016/01/27/google-chrome-ios-reducing-crashes/ ● https://blog.chromium.org/2015/12/smarter-garbage-collection-for-smoother.html ● https://blog.chromium.org/2008/10/responsiveness-for-plugins-and-renderer.html