那么現(xiàn)在將要深入BrowerProcess和 RenderProces里面去，揭開里面有多少線程，線程間怎樣交互。
考試大提示現(xiàn)有問題：
BrowerProcess中有UI顯示部分，消息接受部分，HTTP頁面下載部分，然后其他一系列讀取COOKIE，寫文件，讀寫數(shù)據(jù)庫，等操作是怎么協(xié)調(diào)？怎么分工的？之間又是怎么交互的？
RenderProces中渲染部分和接收 BrowerProcess消息部分是怎么交互的？
RenderProces是怎么發(fā)送消息的到BrowerProcess中的？
注意為了方便理解這里先還是先拋開PluginProcess和sanbox不講。
按照上面的問題本章打算分三部分介紹:
一：BrowerProcess 中的線程
二：RenderProces中的線程
三：BrowerProcess和RenderProces線程交互流程。
一：BrowerProcess 中的線程
BrowerProcess里面的線程很多，其中最重要的是IO線程和UI線程。除了這兩個(gè)線程，還有管理數(shù)據(jù)庫讀寫的DB線程，管理本地文件讀寫的FILE線程等等。
要研究每個(gè)線程首先我們得了解每個(gè)線程的職能。
UI線程顧名思義，管理UI以及UI的消息循環(huán)，但是IO線程不能太顧名思義了，IO線程主要有兩方面的職能，接收進(jìn)程間消息（包括渲染進(jìn)程和插件進(jìn)程的消息），還有個(gè)職能是接收網(wǎng)絡(luò)消息所有HTTP頁面的下載的消息也由這個(gè)線程處理轉(zhuǎn)發(fā)，不過除了用IO來表示這個(gè)線程也想不出來更好的名字了J。
可以先參看下 How Chromium Displays Web Pages 上面的介紹，先引用一張上面的圖片：
(BrowerProcess基本的線程結(jié)構(gòu))
一個(gè)頁面是怎樣被創(chuàng)建的呢？
先弄清楚下面幾點(diǎn)說明<靜態(tài)數(shù)據(jù)概念>：
1：一個(gè)BrowerProcess里面保存一個(gè)Browser的列表，每個(gè)Browser對象代表著一個(gè)瀏覽器窗口。
2：每個(gè)Browser對象里面保存一個(gè)WebContents列表（這個(gè)列表是用了一個(gè)TabStripModel的對象來封裝），WebContents就是瀏覽器上面的HTML頁面和標(biāo)簽。
3：每個(gè)WebContents中包含了一個(gè)RenderViewHost對象。這里要多介紹一下WebContents和RenderViewHost各自的功能：RenderViewHost主要表現(xiàn)的就是一個(gè)HTML頁面，WebContents不說大家可能也已經(jīng)猜到了，它就是管理標(biāo)簽命令和導(dǎo)航命令的（HTML頁面以外的消息由它處理）。
講一些題外話，GOOGLE聲明說他們會在將來支持其他程序調(diào)用RenderViewHost的功能，這對微軟來說是個(gè)相當(dāng)打的挑戰(zhàn)，雖然說瘦死的駱駝比馬大，但是GOOGLE會一步步地同食微軟的市場，這匹瘦駱駝也無力于健壯的馬來競爭，IE只是他們計(jì)劃中的一個(gè)小計(jì)劃，閑話不多扯了，殺回來繼續(xù)。
4：每個(gè)RenderViewHost被創(chuàng)建的時(shí)候它會創(chuàng)建一個(gè)RenderProcessHost的對象，并且創(chuàng)建一個(gè)Rander進(jìn)程，RenderProcessHost的對象會等待Rander進(jìn)程的連接消息。
5：一個(gè)RenderProcessHost對象會創(chuàng)建一個(gè)ChannelProxy的代理對象（這個(gè)對象將被分配到IO線程里面去運(yùn)行），ChannelProxy對象的職責(zé)是轉(zhuǎn)發(fā)Render進(jìn)程的消息和網(wǎng)絡(luò)消息（HTTP頁面下載），并且把需要網(wǎng)絡(luò)消息轉(zhuǎn)發(fā)給Render進(jìn)程。RenderProcessHost對象還會創(chuàng)建另外一個(gè)過濾消息的對象ResourceMessageFilter的過濾器，該過濾器會被添加到ChannelProxy中，此處也是采用上面重復(fù)提到的委托伎倆，ChannelProxy有個(gè)過濾消息的委托接口類，然后把消息交給由外面派生類（ResourceMessageFilter）來處理，如果處理了那么就不轉(zhuǎn)發(fā)消息給UI線程了，如果沒處理，那么轉(zhuǎn)發(fā)消息。
6：每個(gè)ChannelProxy里面會包含一個(gè)真正的IPC：：Channel對象，如果看過我上一篇文章的同學(xué)肯定還記的這個(gè)IPC：：Channel，不就是進(jìn)行進(jìn)程間通訊的東東嗎。Channel會把接受到的消息轉(zhuǎn)發(fā)給ChannelProxy，由ChannelProxy決定該消息路由到什么地方。另外一點(diǎn)就是ChannelProxy會收到本進(jìn)程的消息(網(wǎng)絡(luò)消息和UI消息和其他的消息)，這些消息會根據(jù)情況被轉(zhuǎn)發(fā)給Render進(jìn)程。
ChannelProxy在IO線程中是怎么把Message轉(zhuǎn)換為Task的呢？
可能很奇怪，Message和Task都都好像在前面見過，考試大提示他們之間有什么關(guān)系呢？
Message是從Render進(jìn)程那兒接受到的消息，TASK是消息循環(huán)中執(zhí)行的一個(gè)任務(wù)，IO線程需要把Message轉(zhuǎn)換為TASK發(fā)送到UI線程中去執(zhí)行,Chrome開發(fā)人員定義了一套NewRunnableMethod 的方法，用來把Message轉(zhuǎn)換為相應(yīng)的TASK，參看base\task.h代碼。ChannelProxy里面保存了UI的消息循環(huán)對象的指針，然后通過該對象PostTask系列函數(shù)來發(fā)送消息到UI線程中。
一個(gè)對BrowerProcess里面的進(jìn)程大概介紹就這樣完成了，對上面的6點(diǎn)我們還可以總結(jié)出 1，2，3是在UI線程環(huán)境中運(yùn)行的，4，5是在IO線程中運(yùn)行的，6是IO和UI線程之間交互方式
考試大提示現(xiàn)有問題：
BrowerProcess中有UI顯示部分，消息接受部分，HTTP頁面下載部分，然后其他一系列讀取COOKIE，寫文件，讀寫數(shù)據(jù)庫，等操作是怎么協(xié)調(diào)？怎么分工的？之間又是怎么交互的？
RenderProces中渲染部分和接收 BrowerProcess消息部分是怎么交互的？
RenderProces是怎么發(fā)送消息的到BrowerProcess中的？
注意為了方便理解這里先還是先拋開PluginProcess和sanbox不講。
按照上面的問題本章打算分三部分介紹:
一：BrowerProcess 中的線程
二：RenderProces中的線程
三：BrowerProcess和RenderProces線程交互流程。
一：BrowerProcess 中的線程
BrowerProcess里面的線程很多，其中最重要的是IO線程和UI線程。除了這兩個(gè)線程，還有管理數(shù)據(jù)庫讀寫的DB線程，管理本地文件讀寫的FILE線程等等。
要研究每個(gè)線程首先我們得了解每個(gè)線程的職能。
UI線程顧名思義，管理UI以及UI的消息循環(huán)，但是IO線程不能太顧名思義了，IO線程主要有兩方面的職能，接收進(jìn)程間消息（包括渲染進(jìn)程和插件進(jìn)程的消息），還有個(gè)職能是接收網(wǎng)絡(luò)消息所有HTTP頁面的下載的消息也由這個(gè)線程處理轉(zhuǎn)發(fā)，不過除了用IO來表示這個(gè)線程也想不出來更好的名字了J。
可以先參看下 How Chromium Displays Web Pages 上面的介紹，先引用一張上面的圖片：
(BrowerProcess基本的線程結(jié)構(gòu))
一個(gè)頁面是怎樣被創(chuàng)建的呢？
先弄清楚下面幾點(diǎn)說明<靜態(tài)數(shù)據(jù)概念>：
1：一個(gè)BrowerProcess里面保存一個(gè)Browser的列表，每個(gè)Browser對象代表著一個(gè)瀏覽器窗口。
2：每個(gè)Browser對象里面保存一個(gè)WebContents列表（這個(gè)列表是用了一個(gè)TabStripModel的對象來封裝），WebContents就是瀏覽器上面的HTML頁面和標(biāo)簽。
3：每個(gè)WebContents中包含了一個(gè)RenderViewHost對象。這里要多介紹一下WebContents和RenderViewHost各自的功能：RenderViewHost主要表現(xiàn)的就是一個(gè)HTML頁面，WebContents不說大家可能也已經(jīng)猜到了，它就是管理標(biāo)簽命令和導(dǎo)航命令的（HTML頁面以外的消息由它處理）。
講一些題外話，GOOGLE聲明說他們會在將來支持其他程序調(diào)用RenderViewHost的功能，這對微軟來說是個(gè)相當(dāng)打的挑戰(zhàn)，雖然說瘦死的駱駝比馬大，但是GOOGLE會一步步地同食微軟的市場，這匹瘦駱駝也無力于健壯的馬來競爭，IE只是他們計(jì)劃中的一個(gè)小計(jì)劃，閑話不多扯了，殺回來繼續(xù)。
4：每個(gè)RenderViewHost被創(chuàng)建的時(shí)候它會創(chuàng)建一個(gè)RenderProcessHost的對象，并且創(chuàng)建一個(gè)Rander進(jìn)程，RenderProcessHost的對象會等待Rander進(jìn)程的連接消息。
5：一個(gè)RenderProcessHost對象會創(chuàng)建一個(gè)ChannelProxy的代理對象（這個(gè)對象將被分配到IO線程里面去運(yùn)行），ChannelProxy對象的職責(zé)是轉(zhuǎn)發(fā)Render進(jìn)程的消息和網(wǎng)絡(luò)消息（HTTP頁面下載），并且把需要網(wǎng)絡(luò)消息轉(zhuǎn)發(fā)給Render進(jìn)程。RenderProcessHost對象還會創(chuàng)建另外一個(gè)過濾消息的對象ResourceMessageFilter的過濾器，該過濾器會被添加到ChannelProxy中，此處也是采用上面重復(fù)提到的委托伎倆，ChannelProxy有個(gè)過濾消息的委托接口類，然后把消息交給由外面派生類（ResourceMessageFilter）來處理，如果處理了那么就不轉(zhuǎn)發(fā)消息給UI線程了，如果沒處理，那么轉(zhuǎn)發(fā)消息。
6：每個(gè)ChannelProxy里面會包含一個(gè)真正的IPC：：Channel對象，如果看過我上一篇文章的同學(xué)肯定還記的這個(gè)IPC：：Channel，不就是進(jìn)行進(jìn)程間通訊的東東嗎。Channel會把接受到的消息轉(zhuǎn)發(fā)給ChannelProxy，由ChannelProxy決定該消息路由到什么地方。另外一點(diǎn)就是ChannelProxy會收到本進(jìn)程的消息(網(wǎng)絡(luò)消息和UI消息和其他的消息)，這些消息會根據(jù)情況被轉(zhuǎn)發(fā)給Render進(jìn)程。
ChannelProxy在IO線程中是怎么把Message轉(zhuǎn)換為Task的呢？
可能很奇怪，Message和Task都都好像在前面見過，考試大提示他們之間有什么關(guān)系呢？
Message是從Render進(jìn)程那兒接受到的消息，TASK是消息循環(huán)中執(zhí)行的一個(gè)任務(wù)，IO線程需要把Message轉(zhuǎn)換為TASK發(fā)送到UI線程中去執(zhí)行,Chrome開發(fā)人員定義了一套NewRunnableMethod 的方法，用來把Message轉(zhuǎn)換為相應(yīng)的TASK，參看base\task.h代碼。ChannelProxy里面保存了UI的消息循環(huán)對象的指針，然后通過該對象PostTask系列函數(shù)來發(fā)送消息到UI線程中。
一個(gè)對BrowerProcess里面的進(jìn)程大概介紹就這樣完成了，對上面的6點(diǎn)我們還可以總結(jié)出 1，2，3是在UI線程環(huán)境中運(yùn)行的，4，5是在IO線程中運(yùn)行的，6是IO和UI線程之間交互方式