[5] chrome plug-in Model 1. npapi in order to closely unite with various open-source browsers and jointly combat ie monopoly, chrome plug-ins also follow
Npapi (Netscape plugin Application Programming Interface) standard. To support this standard browser, you must implement a set of specified APIs for the plug-in to call.
Npn_xxx For example, the npn_geturl plug-in can use these APIs for secondary development. The npapi plug-in is provided with a DLL and the like as a physical carrier (DLL in windows and so in Linux), which also implements a set of specified APIs. Format includes
Np_xxx And
Npp_xxx Np_xxx is the method that the system needs to call by default. It is used to recognize this plug-in, such as np_initialize, and npp_xxx is used for the plug-in to complete some practical functions, such as npp_new... All plug-in DLL files must be placed in the specified directory (different depending on the operating system ...), each plug-in can process data in one or more mime formats, such as application/pdf, indicating that the plug-in can process PDF-related documents. In Chrome, type "about: plugins" to view the plug-in information in chrome... Npapi is a classic plug-in solution,
Inject with DLL, communicate with protocol APIs, and describe plug-in capabilities with strings . The plug-in host (in this case, the browser...) dynamically loads the plug-in based on the Capability Description and manages the process and lifecycle of plug-in calls. In the plug-in, the plug-in is responsible for processing the real logic and can construct the UI to communicate with users. The plug-in system implemented in this way is usually a relatively fixed range of processing logic (the logic is written to death using Apis ...), but the scalability is good (the ability to describe using strings can be infinitely expanded ...)... In ChromeNphostapi. h Defines all the function pointers and structures related to the npapi. This file is placed in the glue directory. Article As you can see, there must be a set of identical things in WebKit. Npapi. h/. CC The npn_xxx series functions of the Chrome browser are provided. Each physical instance of the plug-in is Pluginlib Class. Plugininstance Class. This concept is far-fetched and can be analogous to Windows handles. When you want to operate a kernel object, you need to obtain a kernel object handle. The handles in each process must be different, however, the following kernel objects are the same. the lifecycle of the kernel objects is controlled by the handle count. If one uses or, if no one uses it, it will die. (Of course, this analogy is far-fetched, it mainly describes the relationship between the reference count and the logic and the physical, but a key difference lies in, Both pluginlib and plugininstance are in the same process. , Cannot span process boundaries ...). In Chrome, pluginlib is responsible for loading and destroying a DLL and getting the function pointers of all exported functions. plugininstance encapsulates these things and can be called better... Chrome does not provide any documentation for more details about the npapi, but the browser of each pioneer provides a lot of rich documentation. For example, you can go here to view the npapi documentation in Firefox, which is basically common... 2. Chrome's multi-process plug-in model chrome plug-in model, the biggest difference from earlier browsers is that it uses Multi-Process Every plug-in has a separate process to carry (SHIFT + ESC open chrome Process Manager, you can see that the current loaded plug-in process ...). When WebKit discovers unknown mime-type data during page rendering, it will inform the browser process and summon it to provide a plug-in for parsing. If the plug-in has not been loaded, browser will search for plug-ins with this strength in the specified directory (if there is no such talent, you can only do it ...), create a process for it to take charge of all the tasks related to the plug-in, and then establish an IPC path to "keep the call" with it ". This process will not be too unfamiliar, because it is similar to the creation of the render process... The biggest difference between the plug-in process and the render process is that the render needs to communicate a lot with the browser process, because its hwnd is under the control of the browser boss, and all relevant content needs to be communicated. However, plugin does not need to be frequently associated with the browser. Most of its communication occurs with the render process. If the communication between plugin and render needs to go through the browser for a while, it seems that some pants are running. Although browser is a big data, it is not a big data, it won't do this thankless thing. He just made a matchmaker between render and plugin. After the plug-in and browser have established the IPC path, it will allow render to establish a new IPC path to communicate with the plug-in. The famous pipe name of the IPC is notified to the plug-in through browser. After name negotiation, the communication between render and plugin is established, and the communication between them can be directly performed... The entire communication mode can be viewed here. This is a very standard proxy mode application. If you have a little understanding of it, you can skip the long-winded description that I will make later. You will be able to see the diagram in the official document. On the render process side, Webpluginimpl Yes Webplugin A subclass of. webplugin is an interface for WebKit to call. It is extended using Dependency inversion. On the plugin process side,Webplugindelegateimpl Class, which calls the interface of plugininstance to implement the real plug-in function. In this case, you only need webpluginimpl to call the corresponding method in webplugindelegateimpl to implement the function. But the problem is that webpluginimpl and webplugindelegateimpl are in one process each day. Obviously, a proxy mode is required. Here we use the com architecture, delegate + stub + proxy. Webpluginimpl call proxy Webplugindelegateproxy The proxy converts a call to a message and sends it to the plugin process through IPC. Webplugindelegatestub Listen to messages and convert them into real webplugindelegateimpl calls. This completes a cross-process call, and vice versa... 3. Chrome's overall scalability mechanism. Firefox can be customized in three ways, including plug-ins, extensions, and skins. Plug-ins are used by Browsers without a large area that cannot be displayed. Extensions make browsers easy to use and allow users to customize functions and customize configurations conveniently; skin is to help the browser become good-looking. After all, luobo cabbage, give some love... In comparison, let's look at chrome. Chrome has plug-ins, skin, but no extensions. This means that it is difficult for you to customize some special features for chrome. Currently, all chrome function extensions are implemented through bookmarks or modifications to the kernel. The former is too weak, and the latter is too difficult to develop, so it is easy to make mistakes. It must keep up with the times, keep up with version changes, and cannot be freely selected or disabled. Therefore, this is not a long journey. Chrome provides a set of extension mechanisms similar to Firefox, which may be the right way. According to the legend, the Chrome team is pondering this issue. I don't know what the result will be. Is it to try to approach Firefox to reduce the transplant cost or establish a separate portal, I 'd like to wait and see... In multi-process mode, there is another problem with chrome plug-ins. As mentioned above, it is about UI controls. According to the npapi standard, the plug-in is allowed to create the hwnd window, which causes the main process to be suspended when the plug-in is busy and the browser process initiates the hwnd synchronization, And the browser is stuck. In the render process, the idea to solve this problem is to control permissions. Otherwise, render creates hwnd and goes to plugin. This action cannot be used. It can only use another action, that is, supervision. Check whether the plug-in is too busy to respond. Once detected, the plug-in and its page are killed immediately. This is like you want to solve the problem of melamine in milk, or control the milk source, do not buy all from the milk station to use their own, or strengthen supervision, improve inspection efforts to prevent risks. The advantages and disadvantages of the two policies can be easily understood at a glance, and different policies can be taken according to different environments... In general, Chrome's scalability is really general, but Chrome is still in Beta, and we can continue to look forward to it...
