Chromeium service model

purpose

Move the Chrome code base to a service-oriented model. This will produce reusable and decoupled components while also reducing duplication. It also allows the Chrome team and other teams to try new features without modifying Chrome.

 

background

Chrome's architecture has various problems and limitations:

1. Poor component consistency:
   • Function-specific code is scattered in different modules and processes, such as platform and browser functions, and Blink and [chrome, component, content]/browser+renderer code.
   • It seems that irrelevant functions have direct or indirect dependency entanglement, making it difficult to isolate discrete service codes for reuse, security, and stability (for example, network services).
2. Duplication/unnecessary complexity:
   • Many of the function-specific IPCs of the browser process can be appropriately replaced by a small set of common service APIs. For example, the codes in modules such as pepper, content, extensions, etc. usually have similar codes, which are used to proxy browsers to handle permission requests, notifications, quotas, disk access, resource loading, etc.
   • The function will implement its own binding layer (for example, extension, WebUI).
   • The access to common operations (network, preferences, etc.) depends on the process of calling the code.
3. Poor scalability:
   • The lack of flexible APIs and modularity means that experiments and new features must usually be built directly into the browser, which further increases complexity and bloat (such as Stars, Blimp, PDF) or is completely banned (Flutter, Dart, Cardboard).
   • It is not possible to insert different core services (network, disk) implementations for the special purpose of the Chrome code base (ie, for the Headless Chrome & Blimp project).
4. Leak abstraction:
   • On platforms that do not implement the interface in the same way, code reuse becomes more difficult (for example, WKWebView and WebContents on iOS)
   • Core abstractions such as WebContents assume that the hosted renderer is an instance of Blink, which adds unnecessary overhead to functions such as PDF and Blimp.
   • Due to platform differences (for example, gpu code on Android uses different code paths) or improvements in security and stability (for example, network and profile processes), it is difficult to move services to other processes.

 

There are two main reasons for the above restrictions. The first is that the code base is simply pushed to complete many functions that it is not suitable for. From the beginning, the team consciously chose not to over-design the code and architecture until there was a clear need. The second reason is that in the process of eager to add new features and support new platforms, we did not stop to reconsider layering. With the tools that Mojo now provides us, the lessons learned from Mandoline, and the promise of long-term refactoring of the code base, we have the opportunity to move the architecture to a more modular and flexible architecture.

 

Overview

We recommend moving the code to the service model to solve the various problems listed above. Given that Chrome now hosts many platforms (for example, web platforms, Pepper plug-ins, extensions, NaCl, Mojo Apps, Chrome apps, Android apps), Chrome should be built using the layered model common in many systems (such as OS). The ultimate goal should be to have a set of shared services on which other services and functions can be layered.

 

These services will be exposed through the Mojo interface, which hides detailed information about the location of the caller and implementer. It will allow any party to move to a different process, thereby easily improving the system. The network is an example: after we have a network service, we can choose to run it out of process to improve stability/security. If resources are limited, we can also run it in process. If consumers only communicate with network services through the Mojo interface, then the actual location of the network is transparent to them. Mojo can also allow code reuse by avoiding duplicate implementations (depending on the process, module or language used by the caller). By checking the IPC file of the current system, you can see an initial set of shared services. They include: files, network, preferences, leveldb, synchronization, notifications, permissions, quotas, clipboard, publish/subscribe, etc. The creation of these services should be driven by converting current code to use these new services.

 

Similarly, the browser function should expose its API through the Mojo interface. With proper security checks, they should be accessible from other processes and languages. This avoids multiple APIs supporting a certain function. It will also allow different implementations, such as the Chrome team or other Google teams to explore new browser features. If a function needs to interact with the rendering engine, it should be implemented using the Mojo interface, which is transparently implemented by Blink, iOS, and content handlers (see below) that may be added in the future.

 

Project

• Create "basic" services that are used by multiple functions or based on other services. When we transform functions or simplify code, this should be driven by demand. Refer to this document for a list of recommendations for launcher services and their reasonableness. When we create a service, the goal should be to transform as much code as possible with this common function. The initial setup includes:
  • UI (rendering and input) (music)
  • Network (as an overview, please refer to Mandoline's mojo / services / network / public / interfaces /)
  • File (as a rough sketch, see Mandoline's components/filesystem/public/interfaces/)
  • Level database
  • Synchronization
  • Pub/pub
  • preference
  • allow
  • Clipboard
  • Notice
  • track
  • WebView (navigation, frame tree)
• By using the layered implementation of the core services above, the implementation of the Web platform that spans the browser and the renderer is converted to only implemented in the renderer. Starting set:
  • Local storage: detailed design
  • Session storage
  • Index database
  • File system
• Create Mojo interface for browser functions called from extension API and WebUI. Then, the extended JS filler can call them directly from the renderer process. Also for WebUI, let the page call the functional Mojo interface instead of manually writing the binding.
• Refactor the browser components that span the browser and renderer processes to call the HTML engine through the Mojo interface.
  • Start with all layered components, as this will remove an extra layer to handle iOS/ content.
  • Complete the remaining functions of the browser (that is, Chrome functions that are not shared with iOS).

Code location

The extracted service is located in //services. For more information, see the directory of README.md . The extracted library code should be moved to a meaningful location (such as src/components, src/ui, etc.)

 

Tracking errors

https://bugs.chromium.org/p/chromium/issues/detail?id=598069

 

Scope and non-target

The purpose of service work is not to make all Chrome functions use Mojo to talk to each other, nor to decompose each function or interface into its own process. Basically, we do not intend to replicate the early use of XPCOM in gecko.

 

Instead, you can view the project as an enhancement to Chrome's conversion from Chrome IPC to Mojo in the following ways:

 

• Several common use cases that exist in the implementation of the Chrome IPC interface are exposed as a lower-level, well-designed general interface, allowing code for specific functions to be moved into the client.
• Given the modularity of these interfaces, the implementation can be relocated to another process without updating the calling code.

 

In addition, you should think of Mojo as a tool for use in situations where you may need to isolate a piece of code, rather than using Mojo by default instead of more obvious techniques such as simple function calls and PostTask().

 

Appendix A: Future Projects

The above project can make further improvements to the Chrome architecture we have wanted for years, but so far it has been too complicated to implement. Some examples:

• Run network code in a separate sandbox process. For Windows, since external software connects it via LSP, etc., this will help improve stability. We can also sandbox this code (not as powerful as a renderer, but better than a browser without a sandbox). It can be carried out in stages, each level has its own advantages and eventually reaches a separate process:
  • Gather all the code to make network requests through the same API (ie, regardless of whether the calling code is in the renderer process or the browser process). This will simplify the code and allow projects such as Blimp to easily cover the implementation of HTTP and socket requests, etc.
  • The code that is synchronously hooked to the network layer in the browser process needs to use asynchronous APIs. This will clear the public interface of the network library.
  • Move the network code to a separate process. This will improve stability and security. If all Chrome is not running, it will also allow other functions to make network requests.
• Implement the content handler concept of Mojo Shell in Chrome . This will allow new features / experiments to display their content and get input events without having to change other subsystems in the code to support them. This is likely to depend on Chrome using the Mojo UI service.
• Run each profile file service in a sandboxed process that can only access the profile directory. Therefore, most of the code that accesses the disk will be protected to prevent exploits from reading/writing to other directories. We will need multiple instances of the file service, one of which can access the entire file system to get the code in the browser that needs it. pace:
  • Convert file system access permissions in the child process to use file services
  • Convert file access permissions in the browser (in the code we control) to use file services at the same time
• Run a small part of it after closing the browser. This is currently impossible because all codes are interdependent. Using the service model, you can run only the few services you need. Some examples:
  • ARC runtime (run separately from Chrome) requires Chrome to provide a lot of services. In the first step, we have to manually wrap them using the interface. To run the ARC in the absence of Chrome's case , the second step requires C hrome does not run all these services are available.
  • On desktop devices, if the browser is closed, we want to display a notification.