For knowing the Render Process life cycle, we need to know the Frame Tree cycle. Because the Render Process is created during a Frame Tree is constructing, and also is destroyed during the Frame tree is collapsing.
So, I will explain the Render Process life cycle with the Frame Tree.
== Creating the Frame Tree ==
When the eweb_view is created by ewk api "ewk_view_add", it causes the Frame Tree is began to create. The Frame Tree is a member of the "WebContents", and it manages all Frame Tree Nodes. Each Frame Tree Node has the Render Frame Host Manager and the Render Frame Host. The Frame Tree has the Render View Host and the Render Frame Host Manager reference the Render View Host via the Frame Tree. In fact the Frame Tree has the Render View Host map and it manages Render View Hosts. But most case in EFL each Frame Tree only create one Render View Host. Meanwhile during the Render Frame Host is being created, the Render Process Host is also created by the Site Instance. As you know the Render Process Host is a kind of tunnel to communicate with the Render Process. The Site Instance is alive during an application is alive. When the browser re-access some previous sites, if the Site Instance has a url about that sites, then matched the Site Instance would be reused. In other words when the Browser Process need to use the Site Instance, they search a matched Site Instace with an url in a Site Instance map. If some Site Instance matched with an inputted url, the navigator use that Site Instance. But even the Site Instance is reused, the Render Process will be recreated with new url. Anyway The Frame Tree is handled by the Browser Process (in the "WebContents"). When the Render Process is killed, all contents of the Frame tree will also be destroyed except the Frame Tree instance itself. In conclusion when the Frame Tree finish to create the main Render Frame Host (finishing "ewk_view_add"), the Frame tree would be created like below picture.
== When a web page is loading, how to create frames ==
An upper picture is a summary how to create frames when a web page is loading. The main point is a web load trigger is from the Browser Process but a loading progress is managed by the Render Process.
A main Render Frame is created by the Browser Process, but child frames (like inline frames) are created by the Render Process during a web loading. Upper picture also shows a relation between the Render Frame and the WebLocalFrame. The Render Frame is the Chromium side but the WebLocalFrame is the Blink side. But They have 1:1 relationship. If new child frame is needed, the Blink (frame loader) call a "createChildFrame" api in the Render Frame class. Then the Render Frame receives new routing id from the Render Frame Host, and create a new WebLocalFrame to connect with the Blink.
== Change a wep url through new url set ==
When new url is input through "ewk_view_url_set", the Browser Process creates new Render Process. I will explain with a below picture.
Assume the Browser Process already loads some web page like "www.naver.com". Cause "www.naver.com" has several inline frames, the Frame Tree also has matched the Render Frame Host. The Render Frame Host exists in the Render Frame Host Manager, and the Render Frame Host Manager exists in the Frame Tree Node. Set of the Frame Tree Nodes is the Frame Tree. the Frame Tree has root node and the root node number is 1. But when user inputs new url, new Render Process will be created and previous the Frame Tree contents will be collapsed. But root node is never destroyed while "WebContents" is living. As member instance of root node, a main Render Frame Host and the Render View Host will destructed. In other words, the Frame Tree will be existed even the Render Process is killed. And the Frame Tree`s root node is also exist. But the Render Frame Host and the Render View Host will be destructed, when the Render Process is killed. All Frame Tree Nodes except root node will also be destructed when the Render Process is died. In upper picture green boxes will be destructed when the Render Process is died. But it would be delayed till the Blink has succeed to commit load new URL. When new URL is setting the Render Frame Host Manager in root node, create new Render Process through the Site Instance. And After creating new Render Process, the Render Frame Host Manager will create new main Render Frame Host. This new main Render Frame Host is marked as pending. This pending is important. Till "didCommit" signal from the Render Process, the Frame Tree has two main Render Frame Hosts and Render View Host. But they share one root node and the Render Frame Host Manager. The Render Process will send message "FrameHostMsg_DidCommitProvisionalLoad" after the navigation request has been commit. Then the Render Frame Host begin to remove old frames. About that sequence is below picture.
Upper sequence is removing a old Render Frame Hosts process. Frame Tree Nodes are removed by root node`s "ResetForNewProcess" API. Through this API the Render Frame Host Manger and the Render Frame Host in each nodes are removed. But the Render Frame Host in a root node is still alive. And also the Render View Host in the Frame Tree is still alive. They are removed after the Render Process swap out. "FrameMsg_SwapOut" is a message to remove the Render Frames in the Render Process. After removing all frames in the Render Process, it sends a callback message "FrameHostMsg_SwapOut_ACK". In conclusion this message triggers to kill the Render Process. At this time both the main Render Frame Host and the Render View Host are also killed. The Render Process Host has the Child Process Launcher as a member instance. The Child Process Launcher communicate with the Zygote Process about a process life cycle. So through the Child Process Launcher, the Render Process can be died. You can check the Render Process kill command in "ChildProcessLauncher::Context::Terminate()". Before the Render Process is killed, many kinds of stuff must be released. You can check some behavior like IPC channel reset, GPU observer released and so on in "RenderProcessHostImpl::Cleanup()" and "RenderProcessHostImpl::~RenderProcessHostImpl()". Below picture is a simple sequence from "FrameHostMsg_SwapOut_ACK" to the Zygote terminating.
Through the Zygote, the real PID will be killed.
댓글 없음:
댓글 쓰기