有关android 的Binder机制

android 的binder机制实际来源于Palm. 已经有很多对android 的分析，但是深刻的理解还是要到Palm的文档里去读的。

 

这里摘录一两段我认为比较重要的信息，当然非我原创。原文参见（http://www.angryredplanet.com/~hackbod/openbinder/docs/html/index.html）

 

Why Binder?

The Binder architecture was developed to address specific issues that were encountered while developing BeIA at Be, Inc and then Palm OS Cobalt at PalmSource, Inc. Both of these platforms were designed to run on small handheld or dedicated devices, an environment that imposes some specific requirements on system software that are not an issue in a more traditional desktop environment.

Hardware Scalability

The mobile device world tends to have a much broader range of hardware capabilities, for various reasons. For example, size and battery life are extremely important issues, so a new device may use less powerful hardware than an older device in order to meet these goals. This places a burden on system software, where one would like to be able to run on anything from a 50MHz ARM 7 CPU (without memory protection) up to a 400MHz ARM 9 CPU and beyond.

The Binder helps to address this situation by allowing for the creation of system designs that have much more flexibility in how they use hardware. In particular, memory protection and process communication is a significant overhead in modern operating systems, so the Binder strongly supports system design that is not tied to process organization. Instead, the Binder can assign various parts of the system to processes at run time, depending on the particular speed/size/stability/security trade-offs that make sense.

System Customization

Mobile and dedicated devices are unlike desktop machines in that, instead of the "one size fits all" world of the desktop, their user experience and functionality can vary widely between different devices. Both hardware manufacturers and phone carriers want to deeply customize their behavior, partly to support their branding, but also because these devices need to provide an experience that is more specific to the problems they are trying to solve rather than having a general purpose user interface.

The Binder's component model, applied to system design, makes it much easier to support this kind of customizability in a manageable way. The Palm OS Cobalt system architecture takes advantage of this by including separable components for things like font engines, key input handlers, power management, window management, and even UI focus indication. This has allowed, for example, a hardware vendor to customize how input focus is managed on-screen without having to write fragile code that is deeply tied to the implementation of the system software.

Robust Applications

The display and usage pattern of dedicated and mobile devices is also very different than it is on desktops. Desktop-style window management is generally not practical or, if there is no touch screen, even impossible. Because of the limited amount of space on the screen, the currently active application generally wants to consume as much of the available space as possible, essentially becoming the user experience.

This usage of the screen can become a significant problem for more complicated applications, such as web browsers. Often a web browser will need to rely on various third party code to display rich content such as movies, code that is itself quite complicated and not under complete control of the browser. If that code happens to crash in a traditional system design, it will at the very least take with it the window it is in which on a mobile device usually means the entire user experience goes away.

The Binder helps address this issue by making it easy for one application to sandbox other parts of itself. For example, a web browser using the Binder could decided to create components for displaying movies and other complicated content in another process, so that if those components crash they will not disrupt the containing browser experience. At the same time, the Binder can easily revert back to using a single process (or only a few) depending on the capabilities of the hardware it is running on.

 

Binder Process Issues

There are many things working together to make the traditional process model described above actually happen:

 

• The kernel is responsible for creating and managing the basic process mechanism.
• The runtime is responsible for loading and managing code in a process.
• The shell (graphical or command line) is responsible for making the user action "run an application/command" map to lower-level operation of creating a process and running the associated code there.

Note that the Binder process model is designed to sit on top of standard kernel and runtime process support, such as fork()+exec() on Unix. It does not supplant or modify those in any way, but simply uses them in a different way than is done by traditional shells.

 

Unix actually provides a superset of the traditional process model being discussed. Calling fork() without an exec() will cause a new process to be created that is a complete duplicate of the current process. The Binder does not preclude using this alternative model alongside it, however the semantics of forking a multithreaded program are problematic enough that it is not a process model the Binder needs to support for itself. For example, on Linux a fork() does not duplicate any other threads in the original process, leaving parts the new process in a fairly questionable state.

In the Binder itself, there is no concept of an "application" an application is built on top of the core Binder services, but is not something the Binder itself defines. Instead, the Binder revolves around smaller, more generic components. An application is one specific kind of component you can create with the Binder, but you can just as well create components that represent controls on the screen, file-like data streams, a window manager, etc. To the Binder itself, these are all the same thing.

The goal, then, is to define a process model for the Binder that is independent of an application. Clearly, we can't just treat every single component someone creates as a potential application and give it its own process, so some other approach must be taken.