Chrome的表情符號

各種表情符號的圖像。
各種表情符號的圖像。

我們經常談論最常用的表情符號——、、❤️……但是呢?誰來為發言?擁有超過 3,521 個表情符號,您必須滾動瀏覽很多內容才能找到。在家工作時,再加上 Unicode下一個表情符號發布的延遲,我們有一些時間來反思和回答去年看似反問的問題:如果沒有新的表情符號,世界表情符號日會是什么樣子?

好吧,這看起來像是對你鍵盤上已有的數百個表情符號給予了一些愛——專注于讓它們更通用、更易于訪問和更真實——這樣你就可以找到一個全新的最愛表情符號(我喜歡)。而且,您可以在包括 Android、Gmail、Chat、Chrome OS 和 YouTube 在內的更多 Google 平臺上找到所有這些表情符號(是的,包括國王,)。

適合所有人的表情符號

Emoji 的受眾遍及全球,對它們而言,具有全球相關性非常重要。派表情符號是一個奇怪的表情——它以前看起來像一個非常特殊的美國南瓜派(家庭的最愛?。,F在這是每個人都認可的事情。我可以開個玩笑,說有更多的食物可以吃,但這并不是一個真正的玩笑:這個微小的變化意味著這個表情符號可以代表一大堆餡餅——蘋果派、藍莓派、草莓派、櫻桃派、雞肉餡餅、牛肉和蘑菇……不勝枚舉。

餡餅表情符號的動畫從整個餡餅的切片變化

你有沒有想過為什么表情符號看起來像它的樣子?就像,比基尼表情符號——真的需要一個隱形的幽靈穿著它嗎?現在,任何身體都是比基尼身體。

比基尼表情符號的動畫更改為新設計

其他表情符號的變化早就應該發生了。今年令人大開眼界,現在,面膜表情符號也是如此。這個表情符號起源于日本,人們甚至在 COVID-19 大流行之前就經常戴口罩。今天,蒙面是向他人表示善意的普遍方式。

面具表情符號睜開眼睛和眨眼的動畫

你不能錯過的表情包

在設計表情符號時,您經常不得不夸大尺寸。我們的交通表情符號現在更容易看到,因為新設計允許他們利用他們占用的小空間。

表情符號汽車的動畫更改為新設計

完成工作的表情符號

然而,有時偏離現實太遠意味著一個表情符號出現并嘲弄你,困擾你的夢想。哦,這不會發生在你身上嗎?只有我?好吧,當我閉上眼睛時,我看到了剪刀表情符號 (✂️)。我知道這只是一個表情符號,并不需要能夠實際切割東西……但新的可以!

剪刀表情符號的動畫更改為新設計和閉合刀片

這份工作的好處之一是我可以學習各種各樣的東西——比如手風琴設計的歷史、章魚的解剖結構、降落傘的工作原理!作為一個從來沒有學過開車的人,設計表情符號才知道馬路上的黃色畫線告訴你要留在黃線的右邊。但是,如果道路兩側是黃線,你怎么能留在黃線的右邊呢?好吧,我們新設計的高速公路️ 將通過下一次駕駛考試。

高速公路更改為新設計的動畫

其他表情符號只需要煮久一點(或者在某些情況下,放入油炸鍋中)。

食物表情符號(羊角面包、米飯、培根、甜面包)的動畫更改為新設計

讓你在晚上陪伴的表情符號

如果您看得足夠近,當您在一些新設計中切換到深色主題時,您可能還會注意到一些新增內容。

露營 emoji 的動畫變成了用新星星變暗的動畫

出現在比以往更多地方的表情符號

Android 12 將在今年秋季推出時包含所有這些表情符號。為了讓每個人都能更輕松地看到表情符號,無論您的手機有多舊,或者您最喜歡的消息應用程序何時更新,從 Android 12 開始,所有支持 Appcompat 的應用程序都將自動獲得最新最好的表情符號。?

不能等到秋天嗎?從本月開始,您將可以在 Gmail 和 Chat 中發送 和接收 表情符號,而不必擔心它們會損壞 。有 Chromebook 嗎?我們已經為您提供了 ☔ 本月即將推出的閃亮的新表情符號選擇器。在 YouTube 上觀看您最喜歡的創作者并在實時聊天中聊天 ?今年晚些時候發送盡可能多的 表情符號。

Chrome的隱私沙盒承諾更新

自從我們今年早些時候宣布我們的隱私沙盒承諾以來,我們繼續與英國競爭和市場管理局 (CMA) 合作,以解決作為其公眾咨詢過程的一部分提出的反饋。我們還繼續更新并尋求市場和英國信息專員辦公室 (ICO) 對我們的建議的反饋。

我們決心確保以適用于整個生態系統的方式開發隱私沙盒,作為此過程的一部分,我們現在提供了修訂后的承諾,可以在CMA 的網站上找到完整的承諾。

這些修訂強調了我們的承諾,即確保我們在 Chrome 中所做的更改將以與任何第三方相同的方式適用于 Google 的廣告技術產品,并且隱私沙盒 API 的設計、開發和實施將受到監管監督和來自CMA 和 ICO。我們還支持昨天在 ICO 關于在線廣告提案的數據保護和隱私期望的意見中提出的目標,包括支持和開發保護人們隱私和防止秘密跟蹤的隱私安全廣告工具的重要性。

修訂后的承諾包含許多變化,包括:

  1. 監測和報告。我們已提議任命一名獨立的監控受托人,他將擁有確保合規所需的訪問權限和技術專長。
  2. 測試和咨詢。我們向 CMA 提供了更廣泛的測試承諾,以及更透明的流程來獲取市場對隱私沙盒提案的反饋。
  3. 進一步明確我們對數據的使用。我們強調我們不會使用 Google 第一方個人數據來跟蹤用戶以定位和衡量在非 Google 網站上展示的廣告的承諾。我們的承諾還將限制在 Google 或非 Google 網站上使用 Chrome 瀏覽歷史記錄和分析數據來執行此操作。

如果 CMA 接受這些承諾,我們將在全球范圍內實施這些承諾。

在我們制定隱私沙盒提案時,我們繼續感謝 CMA 和 ICO 的周到方法和參與。我們歡迎并將仔細考慮人們在咨詢過程中提供的任何意見。

使用 Chrome 完成假日購物的 5 個技巧

文章的英雄媒體
文章的英雄媒體

我們正忙于假日購物,我們中的許多人都在網上瘋狂地搜索最后一分鐘的庫存填充物。幸運的是,Chrome 即將推出一些新功能,這將使最后幾輪購物變得更容易——幫助您跟蹤想要購買的商品并最終點擊“訂購”。

以下是使用 Chrome 獲得無壓力購物體驗的五種方法。

1. 跟蹤降價:您是否正在等待那副耳機的優惠,但沒有時間不斷刷新頁面?本周在美國的 Android 版 Chrome 上推出了一項新的移動功能,它將在您打開的標簽網格中顯示商品的更新價格,以便您輕松查看價格是否以及何時下降。同樣的功能將在未來幾周內在 iOS 上推出。

屏幕截圖顯示了 Chrome 中四個選項卡的網格。 兩個標簽是產品頁面,并在標簽預覽頂部顯示價格下降,以綠色突出顯示。

2. 使用地址欄中的快照進行搜索:如果您在外出購物時有什么東西引起了您的注意,您現在可以使用 Android 版 Chrome 中的 Google Lens 搜索您的周圍環境。在地址欄中,點擊鏡頭圖標并開始使用您的相機進行搜索。

即將推出,您還可以在桌面上的 Chrome 瀏覽器中使用智能鏡頭。如果您在圖像中看到產品并想了解它是什么,只需右鍵單擊并選擇“使用 Google 鏡頭搜索圖像”選項。

3. 重新發現你的購物車里有什么:你知道你的購物車里有物品,但你不記得具體在哪里。無需重新搜索。從美國的 Windows 和 Mac 上的 Chrome 開始,您現在可以打開一個新標簽并滾動到“您的購物車”卡片,以快速查看您已將商品添加到購物車的任何網站。一些零售商,如 Zazzle、iHerb、Electronic Express 和 Homesquare,甚至可能會在您回來結賬時提供折扣。

4. 從您的盤子中獲取密碼:不必擔心為您最喜歡的購物網站設置和記住您的帳戶詳細信息。Chrome 可以幫助創建唯一、安全的密碼并保存您的登錄詳細信息以供將來訪問。

5. 簡化結帳流程:通過使用 Autofill 保存您的地址和付款信息,Chrome 可以自動填寫您的帳單和送貨詳細信息。當您在新表單中輸入信息時,Chrome 會詢問您是否要保存它。

2021 年最受歡迎的 Chrome 擴展程序

深藍色背景,帶有藍色、紅色、橙色和綠色的幾個輪廓形狀。 中間是一個金色的抽象獎杯,上面覆蓋著一顆心和鍍鉻的標志輪廓。
深藍色背景,帶有藍色、紅色、橙色和綠色的幾個輪廓形狀。 中間是一個金色的抽象獎杯,上面覆蓋著一顆心和鍍鉻的標志輪廓。

全年,來自世界各地的開發人員都在構建 Chrome 擴展程序,使瀏覽變得更輕松、更高效和更個性化——無論您是在網絡上工作、學習、娛樂還是以上所有目的。今天,我們將分享我們今年最喜歡的擴展,幫助人們繼續保持虛擬聯系、完成工作并在此過程中獲得一些樂趣。讓我們仔細看看它們。

溝通和協作

無論您是在辦公室、沙發上還是兩者兼而有之,擴展都可以幫助您與隊友保持聯系。Loom可讓您更輕松地捕捉視頻并與他人分享,而Mote可讓您通過語音評論和轉錄提供快速反饋。Wordtune還可以通過改寫句子和捕捉電子郵件和文檔中的拼寫錯誤來幫助您進行清晰的交流。

Loom、Mote 和 Wordtune 的三個圖標并排。 最左邊的圖標有一個藍色的方形背景,中間有一個白色的星芒,下面標有“Loom”。 中間的圖標有一個紫色的圓形背景,中間有一個草書“M”,下方標有“Mote”。 最右邊的圖標有一個深紫色的圓形背景,帶有草書“W”,下方標有“Wordtune”。

保持生產力

其他擴展提供了保持專注和高效的新方法。Forest通過虛擬植樹和獎勵來提高生產力,而Dark Reader在漫長的工作日中保護您的眼睛(和睡眠時間)。Tab Manager Plus還可讓您免于淹沒在無盡的標簽海洋中,而Nimbus 屏幕截圖和屏幕錄像機可以更輕松地快速截屏和錄制內容以跨平臺共享。

Forest、Dark Reader、Tab Manager Plus 和 Nimbus Screenshot & Screen Video Recorder 的四個圖標并排排列。 最左邊的圖標有綠色背景,前景是土壤和樹葉,下面標有“森林”。 右邊的圖標有一個透明的背景,前景是一個帶有發光眼鏡的黑頭,下面標有“Dark Reader”。 其右側的圖標具有透明背景,三個瀏覽器窗口重疊,顏色為黃色、綠色和橙色,在其下方標有“Tab Manager Plus”。 最右邊的圖標有一個透明的背景,帶有一個虛線的藍色方形輪廓,中間有一個藍色的“N”,右下角有一個藍色的加號。 在下面,它被標記為“Nimbus Screenshot & Screen Video Recorder”。

虛擬學習

隨著在線教育比以往任何時候都多,學生和教師需要有用的虛擬課堂工具。Kami為學生和教師創建了一個交互式在線學習空間,InsertLearning可幫助您輕松記筆記并與 Google Classroom 集成。同時,Toucan讓學習新語言變得有趣和身臨其境,Rememberry將詞匯組織成抽認卡組,以便全天快速學習。

Kami、InsertLearning、Toucan 和 Rememberry 的四個圖標并排。 最左邊的圖標有一個圓形的藍色背景,中間有一個白色的粗體“K”,下面標有“Kami”。 其右側的圖標為深紫色方形背景,中間有一個粗體“IL”,下方標有“InsertLearning”。 其右側的圖標有綠色背景,前景是一只巨嘴鳥,在其下方標有“巨嘴鳥”。 最右邊的圖標有一個透明的背景,一個人頭輪廓朝左,一個圓圈,一端有一個箭頭,指向逆時針方向。 在下面,它被標記為“記憶”。

進行(并保存)一些更改

為了給您的瀏覽體驗帶來個性化的體驗,Stylus可幫助您為您喜愛的網站構建和安裝自定義主題和皮膚。樂天通過在網絡上自動查找優惠券和交易,將現金返還到您的口袋里——在網上購物最繁忙的一年中尤其有用。

Stylus 和 Rakuten 的兩個圖標并排。 左邊的圖標有一個深藍色的方形背景,有一個淺藍色的輪廓,中間有一個淺藍色的“S”,下面標有“手寫筆”。 右邊的圖標有一個透明的背景,中間有一個紫色的“R”并帶有下劃線,下面標有“Rakuten”。

要安裝和了解有關這些擴展程序的更多信息,請訪問我們的 2021 年 Chrome 網上應用店收藏夾系列。如果您是一名開發人員,正在尋找設計高質量 Chrome 擴展程序的技巧,請查看我們的最佳實踐。

Chrome 中的新變化

Chrome 瀏覽器界面:顯示了針對“youtube”一詞執行的標簽頁搜索。

Chrome 的速度和易用性隨著一次次的更新不斷提升。試試新功能:更好的鏈接發送方式,以及更快速地找到所需標簽頁。

工作效率

正在分享鏈接?那就讓鏈接直接跳到要分享的確切部分吧。

在分享鏈接時嘗試使用“復制指向突出顯示的內容的鏈接”選項。當收件人打開您分享的鏈接時,會直接看到相應頁面中您選中的那部分內容(而非此頁的頁首)。

  1. 突出顯示您想分享的文本。
  2. 右鍵點擊所選內容,然后選擇復制指向突出顯示的內容的鏈接。
  3. 將鏈接粘貼到任意位置,例如電子郵件或會話集內。
Chrome 瀏覽器界面:顯示了針對“youtube”一詞執行的標簽頁搜索。

工作效率

使用“標簽頁搜索”功能更快速地找到所需標簽頁

打開了很多標簽頁?如果您無法快速找到自己所需的標簽頁,不妨試試 Chrome 的“標簽頁搜索”功能。

在您的 Chrome 窗口頂部,點擊“標簽頁搜索”圖標?,即可查看您已打開的所有 Chrome 標簽頁的列表。

Chrome 瀏覽器界面:顯示了在個人資料選擇屏幕“誰在使用 Chrome?”中,一個名為“Elisa Beckett”的用戶名下有 2 份不同的個人資料。

CHROME 小竅門

為 Chrome 選擇一個新的背景和配色

想讓您的瀏覽器舊貌換新顏?不妨試試 Chrome 的背景和顏色選項。如果您有多份 Chrome 個人資料,甚至能為每份個人資料采用不同的背景。

  1. 打開新標簽頁。
  2. 在右下角,點擊??自定義 Chrome。

Chrome為何不再支持Flash

自 2021 年起,Adobe 已停止為 Flash Player 插件提供支持。在任何版本的 Chrome 中,Flash 內容(包括音頻和視頻)都將無法再正常播放。只有ie內核瀏覽器(ie、MyIE)才能播放flash。
chrome為什么不再支持flash呢?

Adobe 宣布計劃在 2020 年底停止支持 Flash。

20 年來,Flash 幫助塑造了您在網絡上玩游戲、觀看視頻和運行應用程序的方式。但在過去的幾年里,Flash 變得不那么普遍了。三年前,80% 的桌面Chrome用戶每天都使用 Flash 訪問網站。今天的使用率只有17%,而且還在繼續下降。

這一趨勢表明,網站正在向開放網絡技術遷移,這些技術比 Flash 更快、更節能。它們也更安全,因此您在購物、銀行業務或閱讀敏感文件時可以更加安全。它們還適用于移動設備和桌面設備,因此您可以在任何地方訪問您最喜愛的網站。

去年底,當網站開始需要征得您的許可才能運行 Flash 時,這些開放的網絡技術成為 Chrome 的默認體驗。在接下來的幾年里,Chrome 將繼續逐步淘汰 Flash,首先要求您允許在更多情況下運行 Flash,并最終默認禁用它。到 2020 年底,我們將從 Chrome 中徹底移除 Flash。

如果您現在經常訪問使用 Flash 的網站,您可能想知道這對您有何影響。如果該站點遷移到開放 Web 標準,您應該不會注意到太大的不同,只是您將不再看到在該站點上運行 Flash 的提示。如果該站點繼續使用 Flash,并且您授予該站點運行 Flash 的權限,則它將持續到 2020 年底。

與 Adob??e、其他瀏覽器和主要出版商進行了大量密切合作,以確保 Web 已準備好實現無 Flash。我們支持 Adob??e 今天的聲明,我們期待與大家合作,讓網絡變得更好。

Chrome如何啟用Flash

1.點擊地址欄頭部位置

2. 點擊網站設置。

(如果已經有flash,則點擊允許即可)

3. 找到flash,點擊允許。

說明:

再打開Chrome時,每次都得這么設置。

可以安裝MyIE瀏覽器,對需要flash的網站,直接用MyIE打開即可。

chrome多進程架構

問題

構建幾乎不會崩潰或掛起的渲染引擎幾乎是不可能的。構建完全安全的渲染引擎幾乎也是不可能的。

在某種程度上,2006年左右的網絡瀏覽器的狀態類似于過去的單用戶,協作多任務操作系統。由于此類操作系統中的行為異常的應用程序可能會破壞整個系統,因此Web瀏覽器中的行為異常的網頁也可能因此而崩潰。它只需要一個瀏覽器或插件錯誤即可關閉整個瀏覽器和所有當前運行的選項卡。

現代操作系統更強大,因為它們將應用程序置于相互隔離的單獨進程中。一個應用程序中的崩潰通常不會損害其他應用程序或操作系統的完整性,并且每個用戶對其他用戶數據的訪問受到限制。

建筑概述

我們對瀏覽器選項卡使用單獨的過程,以保護整個應用程序免受渲染引擎中的錯誤和干擾。我們還限制了每個渲染引擎進程對其他進程以及系統其余部分的訪問。在某些方面,這為Web瀏覽帶來了內存保護和訪問控制帶給操作系統的好處。

我們將運行UI并管理選項卡和插件過程的主要過程稱為“瀏覽器過程”或“瀏覽器”。同樣,特定于選項卡的過程稱為“渲染過程”或“渲染器”。渲染器使用Blink開源布局引擎來解釋和布局HTML。

管理渲染過程

每個渲染進程都有一個全局RenderProcess對象,該對象管理與父瀏覽器進程的通信并維護全局狀態。瀏覽器RenderProcessHost?為每個渲染進程維護一個對應項,該進程管理瀏覽器狀態和渲染器的通信。瀏覽器和渲染器使用Chromium的IPC系統進行通信。

管理視圖

每個渲染過程都有一個或多個RenderView對象,由管理RenderProcess,這些對象對應于內容的選項卡。對應項?在渲染器中RenderProcessHost維護RenderViewHost與每個視圖對應的內容。每個視圖都有一個視圖ID,該ID用于區分同一渲染器中的多個視圖。這些ID在一個渲染器中是唯一的,但在瀏覽器中不是唯一的,因此要識別視圖,需要一個RenderProcessHostID和一個View ID。通過這些RenderViewHost對象可以完成從瀏覽器到特定內容選項卡的通信,這些對象知道如何將消息通過它們發送RenderProcessHostRenderProcessRenderView。

組件和接口

在渲染過程中:

  • 在瀏覽器中RenderProcess使用相應的句柄處理IPC?RenderProcessHost。RenderProcess每個渲染過程只有一個對象。這就是所有瀏覽器↔渲染器通信的發生方式。
  • RenderView對象RenderViewHost在瀏覽器進程中(通過RenderProcess)和我們的WebKit嵌入層與其對應的對象通信。此對象表示選項卡或彈出窗口中一個網頁的內容

在瀏覽器過程中:

  • Browser對象表示頂級瀏覽器窗口。
  • RenderProcessHost對象表示單個瀏覽器↔渲染器IPC連接的瀏覽器端。有一個RenderProcessHost在每個渲染過程中的瀏覽器進程。
  • RenderViewHost對象封裝的通信與遠程RenderViewRenderWidgetHost處理用于輸入和繪畫RenderWidget在瀏覽器中。

有關此嵌入的工作方式的更多詳細信息,請參閱Chromium如何顯示網頁??設計文檔。

共享渲染過程

通常,每個新窗口或選項卡都會在新過程中打開。瀏覽器將產生一個新進程,并指示它創建一個RenderView。

有時有必要或希望在選項卡或窗口之間共享渲染過程。Web應用程序會打開一個新窗口,希望與之進行同步通信,例如,使用??JavaScript中的window.open。在這種情況下,當我們創建新的窗口或選項卡時,我們需要重用打開窗口的過程。如果進程總數太大,或者用戶已經打開一個導航到該域的進程,我們還可以為新進程分配新選項卡的策略。這些策略在過程模型中進行了描述。

檢測崩潰或行為異常的渲染器

與瀏覽器進程的每個IPC連接都會監視進程句柄。如果發出了這些句柄的信號,則表示渲染過程已崩潰,并且向選項卡通知了崩潰?,F在,我們顯示一個“悲傷的標簽”屏幕,通知用戶渲染器崩潰了??梢酝ㄟ^按下重新加載按鈕或開始新的導航來重新加載頁面。發生這種情況時,我們注意到沒有任何流程,而是創建一個新的流程。

沙盒渲染器

鑒于渲染器在單獨的進程中運行,我們有機會通過sandboxing限制其對系統資源的訪問。例如,我們可以確保渲染器對網絡的唯一訪問是通過其父瀏覽器進程進行的。同樣,我們可以使用主機操作系統的內置權限來限制其對文件系統的訪問。

除了限制渲染器對文件系統和網絡的訪問之外,我們還可以限制對渲染器對用戶的顯示和相關對象的訪問。我們在用戶看不見的單獨Windows“?桌面?”?上運行每個渲染過程。這樣可以防止受損的渲染器打開新窗口或捕獲擊鍵。

回饋記憶

給定渲染器在單獨的進程中運行,將隱藏的選項卡視為較低優先級就變得很簡單。通常,Windows上最小化的進程會將其內存自動放入“可用內存”池中。在低內存情況下,Windows將在交換出更高優先級的內存之前將該內存交換到磁盤上,從而有助于使用戶可見的程序具有更高的響應速度。我們可以將相同的原理應用于隱藏的標簽。當渲染進程沒有頂級選項卡時,我們可以釋放該進程的“工作集”大小,以提示系統在必要時先將該內存換出到磁盤。因為我們發現減小工作集大小也會降低用戶在兩個選項卡之間切換時的選項卡切換性能,所以我們逐漸釋放此內存。這意味著,如果用戶切換回最近使用的選項卡,則與最近使用的選項卡相比,該選項卡的內存更有可能被分頁。具有足夠內存來運行所有程序的用戶根本不會注意到此過程:Windows僅會在需要時才真正回收這些數據,因此,如果有足夠的內存,則不會對性能造成任何影響。

這有助于我們在低內存情況下獲得更好的內存占用。與很少使用的背景標簽相關聯的內存可以完全換出,而前景標簽的數據可以完全加載到內存中。相比之下,單進程瀏覽器會將所有選項卡的數據隨機分布在其內存中,并且不可能如此干凈地分離使用和未使用的數據,從而浪費內存和性能。

插件和擴展

Firefox風格的NPAPI插件在其自身的進程中運行,與渲染器分開。插件體系結構中對此進行了詳細描述。?

“?網站隔離”項目旨在提供渲染器之間的更多隔離,該項目的早期交付成果包括在隔離的進程中運行Chrome的HTML / JavaScript內容擴展。

chrome渲染引擎blink如何工作

眨眼的工作原理

bit.ly/how-blink-works

作者:haraken @

最后更新:2018年8月14日

狀態:PUBLIC

 

在眨眼上工作并不容易。對于新的Blink開發人員而言,這并不容易,因為已經引入了許多特定于Blink的概念和編碼約定來實現非??焖俚匿秩疽?。即使對于有經驗的Blink開發人員來說,這也不容易,因為Blink龐大且對性能,內存和安全性極為敏感。

 

本文檔旨在提供1?萬英尺的“ Blink的工作原理”概述,我希望它將有助于Blink開發人員快速熟悉該體系結構:

 

  • 該文檔不是有關Blink詳細架構和編碼規則(可能會更改和過時)的詳盡教程。相反,該文檔簡明扼要地描述了Blink的基本原理(短期內不太可能改變),并指出了您想了解更多信息時可以閱讀的資源。
  • 該文檔未解釋特定功能(例如ServiceWorkers,編輯)。而是該文檔解釋了廣泛的代碼庫所使用的基本功能(例如,內存管理,V8 API)。

 

有關Blink開發的更多常規信息,請參閱Chromium Wiki頁面。

 

眨眼做什么

流程/線程架構

工藝流程

線程數

閃爍的初始化

目錄結構

內容公共API和Blink公共API

目錄結構和依賴性

WTF

內存管理

任務調度

頁面,框架,文檔,DOMWindow等

概念

OOPIF

分離的框架/文件

Web IDL綁定

V8和閃爍

隔離,上下文,世界

V8 API

V8包裝器

渲染管線

有什么問題嗎

 

眨眼做什么

Blink是Web平臺的渲染引擎。粗略地說,Blink實現了所有在瀏覽器選項卡中呈現內容的內容:

 

  • 實施Web平臺的規范(例如HTML標準),包括DOM,CSS和Web IDL
  • 嵌入V8并運行JavaScript
  • 從基礎網絡堆棧請求資源
  • 建立DOM樹
  • 計算樣式和布局
  • 嵌入Chrome合成器并繪制圖形

 

許多用戶(例如Chromium,Android WebView和Opera)通過內容公開API嵌入了Blink?。

 

從代碼庫的角度來看,“閃爍”通常是指// third_party / blink /。從項目角度來看,“閃爍”通常表示實現Web平臺功能的項目。實現Web平臺功能的代碼跨越// third_party / blink /,// content / renderer /,// content /瀏覽器/和其他地方。

流程/線程架構

工藝流程

鉻具有多工藝體系結構。Chromium具有一個瀏覽器進程和N個沙盒渲染器進程。閃爍在渲染器進程中運行。

 

創建了多少個渲染器進程?出于安全原因,隔離跨站點文檔之間的內存地址區域非常重要(這稱為Site Isolation)。從概念上講,每個渲染器過程最多應專用于一個站點。但是實際上,當用戶打開太多標簽頁或設備沒有足夠的RAM時,有時將每個渲染器進程限制在一個站點上有時會很繁瑣。然后,渲染器進程可以由從不同站點加載的多個iframe或標簽共享。這意味著一個選項卡中的iframe可以由不同的渲染器進程托管,而不同選項卡中的iframe可以由相同的渲染器進程托管。渲染器進程,iframe和Tab之間沒有1:1映射。

 

假定渲染器進程在沙箱中運行,則Blink需要要求瀏覽器進程調度系統調用(例如,文件訪問,播放音頻)并訪問用戶配置文件數據(例如Cookie,密碼)。這種瀏覽器-渲染器過程通信是由Mojo實現的。(注意:過去我們使用的是Chromium IPC,但仍然有很多地方在使用它。但是,它已被棄用,并在后臺使用Mojo。)在Chromium方面,服務化正在進行中,并將瀏覽器過程抽象為一組“服務。從Blink角度來看,Blink可以僅使用Mojo與服務和瀏覽器進程進行交互。

 

如果您想了解更多信息:

 

  • 多進程架構
  • Blink中的Mojo編程:platform / mojo / MojoProgrammingInBlink.md

線程數

在渲染器進程中創建了多少個線程?

 

眨眼有一個主線程,N個工作線程和幾個內部線程。

 

幾乎所有重要的事情都在主線程上發生。所有JavaScript(工人除外),DOM,CSS,樣式和布局計算都在主線程上運行。假設主要是單線程體系結構,Blink進行了高度優化以最大化主線程的性能。

 

眨眼可能會創建多個工作線程來運行Web Workers,ServiceWorkerWorklets。

 

Blink和V8可能會創建幾個內部線程來處理webaudio,數據庫,GC等。

 

對于跨線程通信,必須使用通過PostTask API傳遞消息。不建議使用共享內存編程,除了出于性能原因確實需要使用它的幾個地方。這就是為什么您在Blink代碼庫中看不到很多MutexLocks的原因。

 

如果您想了解更多信息:

 

閃爍的初始化和完成

眨眼由BlinkInitializer :: Initialize()初始化。在執行任何Blink代碼之前必須調用此方法。

 

另一方面,Blink從未完成。也就是說,渲染器進程被強制退出而不進行清理。原因之一是性能。另一個原因是,通常很難以一種有序的方式清理渲染器進程中的所有內容(這是不值得的工作)。

目錄結構

內容公共API和Blink公共API

內容公共API是使嵌入程序嵌入呈現引擎的API層。內容公共API必須小心維護,因為它們會暴露在嵌入程序中。

 

眨眼公共API是將// // third_party / blink /的功能公開給Chromium的API層。該API層只是從WebKit繼承的歷史工件。在WebKit時代,Chromium和Safari共享WebKit的實現,因此需要API層才能將WebKit的功能公開給Chromium和Safari。既然Chromium是// third_party / blink /的唯一嵌入者,那么API層就沒有意義了。通過將網絡平臺代碼從Chromium移到Blink(該項目稱為Onion Soup),我們正在積極減少Blink公共API的數量。

 

目錄結構和依賴性

// third_party / blink /具有以下目錄。有關這些目錄的更詳細定義,請參閱此文檔

 

  • 平臺/
    • Blink的較低級功能的集合,這些功能是從整體內核中剔除的。例如,幾何和圖形工具。
  • 核心/和模塊/
    • 規范中定義的所有Web平臺功能的實現。core /實現與DOM緊密結合的功能。模塊/實現更多獨立功能。例如webaudio,indexeddb。
  • 綁定/核心/和綁定/模塊/
    • 從概念上講,bindings / core /是core /的一部分,而bindings / modules /是modules /的一部分。大量使用V8 API的文件被放在bindings / {core,modules}中。
  • 控制器/
    • 一組使用core /和modules /的高級庫。例如devtools前端。

 

依存關系按以下順序流動:

 

  • 鉻=>控制器/ =>模塊/和綁定/模塊/ =>核心/和綁定/核心/ =>平臺/ =>底層基元,例如// base,// v8和// cc

 

Blink仔細維護暴露于// third_party / blink /的低級基元列表。

 

如果您想了解更多信息:

 

WTF

WTF是一個“特定于眨眼的基礎”庫,位于platform / wtf /。我們正在嘗試盡可能多地統一Chromium和Blink之間的編碼原語,因此WTF應該很小。需要此庫是因為確實需要針對Blink的工作量和Oilpan(Blink GC)優化許多類型,容器和宏。如果類型是在WTF中定義的,則Blink必須使用WTF類型而不是// base或std庫中定義的類型。最受歡迎的是矢量,哈希集,哈希圖和字符串。眨眼應該使用WTF :: Vector,WTF :: HashSet,WTF :: HashMap,WTF :: String和WTF :: AtomicString而不是std :: vector,std :: * set,std :: * map和std :: string 。

 

如果您想了解更多信息:

 

內存管理

就Blink而言,您需要關心三個內存分配器:

 

 

您可以使用USING_FAST_MALLOC()在PartitionAlloc的堆上分配一個對象:

 

類SomeObject {

??USING_FAST_MALLOC(SomeObject);

??靜態std :: unique_ptr <SomeObject> Create(){

????返回std :: make_unique <SomeObject>();?//分配在PartitionAlloc的堆上。

}

};

 

由PartitionAlloc分配的對象的生存期應由scoped_refptr <>或std :: unique_ptr <>管理。強烈建議不要手動管理生命周期。閃爍禁止手動刪除。

 

您可以使用GarbageCollected在Oilpan的堆上分配一個對象:

 

類SomeObject:公共GarbageCollected <SomeObject> {

??靜態SomeObject * Create(){

????返回新的SomeObject;?//分配在Oilpan的堆上。

??}

};

 

Oilpan分配的對象的生存期由垃圾收集自動管理。您必須使用特殊的指針(例如Member <>,Persistent <>)將對象保存在Oilpan的堆上。請參閱此API參考以熟悉有關Oilpan的編程限制。最重要的限制是不允許您在油鍋對象的析構函數中觸摸任何其他油鍋對象(因為無法保證銷毀順序)。

 

如果您既不使用USING_FAST_MALLOC()也不使用GarbageCollected,則在系統malloc的堆上分配對象。在眨眼中強烈建議不要這樣做。所有Blink對象應由PartitionAlloc或Oilpan分配,如下所示:

 

  • 默認情況下使用Oilpan。
  • 僅在以下情況下才使用PartitionAlloc:1)對象的生存期非常明確并且std :: unique_ptr <>或scoped_refptr <>足夠,2)在Oilpan上分配對象會帶來很多復雜性,或者3)在Oilpan上分配對象會導致給垃圾收集運行時帶來了不必要的壓力。

 

無論使用PartitionAlloc還是Oilpan,都必須非常小心,不要創建懸空的指針(注意:強烈建議不要使用原始指針)或內存泄漏。

 

如果您想了解更多信息:

 

任務調度

為了提高渲染引擎的響應速度,Blink中的任務應盡可能異步執行。不鼓勵同步IPC / Mojo和任何其他可能花費幾毫秒的操作(盡管某些操作是不可避免的,例如用戶的JavaScript執行)。

 

呈現器進程中的所有任務都應使用正確的任務類型發布到Blink Scheduler,如下所示:

 

//使用kNetworking的任務類型將任務發布到框架的調度程序

frame-> GetTaskRunner(TaskType :: kNetworking)-> PostTask(…,WTF :: Bind(&Function));

 

Blink Scheduler維護多個任務隊列,并巧妙地對任務進行優先級排序,以最大化用戶感知的性能。重要的是要指定適當的任務類型,以使Blink Scheduler能夠正確,智能地調度任務。

 

如果您想了解更多信息:

 

  • 如何發布任務:platform / scheduler / PostTask.md

頁面,框架,文檔,DOMWindow等

概念

頁面,框架,文檔,ExecutionContext和DOMWindow是以下概念:

 

  • 頁面與選項卡的概念相對應(如果未啟用下面說明的OOPIF)。每個渲染器進程可能包含多個選項卡。
  • 框架對應于框架(主框架或iframe)的概念。每個頁面可以包含一個或多個以樹狀層次結構排列的框架。
  • DOMWindow對應于JavaScript中的窗口對象。每個框架都有一個DOMWindow。
  • Document對應于JavaScript中的window.document?對象。每個框架都有一個文檔。
  • ExecutionContext是一個抽象文檔(用于主線程)和WorkerGlobalScope(用于工作線程)的概念。

 

渲染過程:頁面= 1:N

 

頁:框架= 1:M.

 

框架:DOMWindow:文檔(或ExecutionContext)= 1:1:1在任何時間點,但映射可能隨時間而變化。例如,考慮以下代碼:

 

iframe.contentWindow.location.href =“ https://example.com”;

 

在這種情況下,將為https://example.com創建一個新的DOMWindow和一個新的Document?。但是,可以重復使用該框架。

 

(注意:確切地說,在某些情況下會創建一個新的Document,但是DOMWindow和Frame會被重用。甚至還有一些更復雜的情況。)

 

如果您想了解更多信息:

 

  • 核心/框架/FrameLifecycle.md

進程外iframe(OOPIF)

站點隔離使事情變得更加安全,但更加復雜。🙂站點隔離的想法是為每個站點創建一個渲染器進程。(網站是頁面的可注冊域+ 1標簽及其URL方案。例如,https://mail.example.comhttps://chat.example.com在同一網站中,但https:// noodles.comhttps://pumpkins.com都沒有。)如果一個頁面包含一個跨站點IFRAME,該頁面可以由兩個渲染過程托管??紤]以下頁面:

 

<!– https://example.com –>

<身體>

<iframe src =” https://example2.com”> </ iframe>

</ body>

 

主框架和<iframe>可以由不同的渲染器進程托管。渲染器進程本地的幀由LocalFrame表示,而不是渲染器進程本地的幀由RemoteFrame表示。

 

從主框架的角度來看,主框架是LocalFrame,而<iframe>是RemoteFrame。從<iframe>的角度來看,主框架是RemoteFrame,而<iframe>是LocalFrame。

 

本地框架和遠程框架(可能存在于不同的渲染器進程中)之間的通信是通過瀏覽器進程進行處理的。

 

如果您想了解更多信息:

 

分離的框架/文件

相框/文檔可能處于分離狀態??紤]以下情況:

 

doc = iframe.contentDocument;

iframe.remove();?//將iframe與DOM樹分離。

doc.createElement(“ div”);?//但是您仍然可以在分離的框架上運行腳本。

 

棘手的事實是,您仍然可以在分離的框架上運行腳本或DOM操作。由于框架已經分離,大多數DOM操作將失敗并引發錯誤。不幸的是,分離框架上的行為在瀏覽器之間并不能真正實現互操作,在規范中也沒有明確定義?;旧?,人們期望JavaScript可以繼續運行,但是大多數DOM操作應該會因某些適當的異常而失敗,例如:

 

無效someDOMOperation(…){

??if(!script_state _-> ContextIsValid()){//框架已經分離

????…;//設置例外等

????返回;

}

}

 

這意味著在通常情況下,當框架分離時,Blink需要執行一系列清理操作。您可以通過從ContextLifecycleObserver繼承來做到這一點,如下所示:

 

類SomeObject:公共GarbageCollected <SomeObject>,公共ContextLifecycleObserver {

??void ContextDestroyed()覆蓋{

????//在此進行清理操作。

}

???SomeObject(){

????//在這里進行清理操作不是一個好主意,因為現在進行清理已經太遲了。此外,不允許析構函數接觸Oilpan堆上的任何其他對象。

??}

};

Web IDL綁定

當JavaScript訪問node.firstChild時,將調用node.h?中的Node :: firstChild()。它是如何工作的?讓我們看一下node.firstChild的工作方式。

 

首先,您需要根據規范定義一個IDL文件:

 

// node.idl

接口Node:EventTarget {

??[…]只讀屬性Node?第一個孩子;

};

 

Web IDL的語法在Web IDL規范中定義。[…]?稱為IDL擴展屬性。一些IDL擴展屬性是在Web IDL規范中定義的,而另一些是特定于Blink的IDL擴展屬性。除了特定于閃爍的IDL擴展屬性外,IDL文件應以符合規范的方式編寫(即,僅從規范中復制并粘貼)。

 

其次,您需要為Node定義一個C ++類,并為firstChild實現一個C ++ getter:

 

class EventTarget:public Sc??riptWrappable {//所有暴露給JavaScript的類都必須從ScriptWrappable繼承。

…;

};

 

類Node:public EventTarget {

??DEFINE_WRAPPERTYPEINFO();?//所有具有IDL文件的類都必須具有此宏。

??節點* firstChild()const {return first_child_;?}

};

 

在通常情況下,就是這樣。生成node.idl時,IDL編譯器會自動為Node接口和Node.firstChild生成Blink-V8綁定。自動生成的綁定是在//src/out/{Debug,Release}/gen/third_party/blink/renderer/bindings/core/v8/v8_node.h中生成的。當JavaScript調用node.firstChild時,V8會調用v8_node.h中的V8Node :: firstChildAttributeGetterCallback(),然后會調用您在上面定義的Node :: firstChild()。

 

如果您想了解更多信息:

 

V8和閃爍

隔離,上下文,世界

當您編寫涉及V8 API的代碼時,了解隔離,上下文和世界的概念很重要。它們分別在代碼庫中由v8 :: Isolate,v8 :: Context和DOMWrapperWorld表示。

 

隔離對應于物理線程。隔離:閃爍中的物理線程= 1:1。主線程具有自己的隔離。輔助線程具有其自己的隔離。

 

上下文對應于全局對象(在使用框架的情況下,它是框架的窗口對象)。由于每個框架都有其自己的窗口對象,因此渲染器進程中存在多個上下文。調用V8 API時,必須確保您使用的是正確的上下文。否則,v8 :: Isolate :: GetCurrentContext()將返回錯誤的上下文,在最壞的情況下,它將最終導致對象泄漏并導致安全問題。

 

World是支持Chrome擴展程序的內容腳本的概念。世界與Web標準中的任何內容都不對應。內容腳本希望與網頁共享DOM,但是出于安全原因,必須將內容腳本的JavaScript對象與網頁的JavaScript堆隔離。(還必須將一個內容腳本的JavaScript堆與另一個內容腳本的JavaScript堆隔離。)為了實現隔離,主線程為網頁創建了一個主世界,為每個內容腳本創建了一個隔離世界。主世界和孤立世界可以訪問相同的C ++ DOM對象,但是它們的JavaScript對象是孤立的。通過為一個C ++ DOM對象創建多個V8包裝器來實現這種隔離。也就是說,每個世界一個V8包裝器。

 

上下文,世界和框架之間有什么關系?

 

想象一下,在主線程上有N個世界(一個主世界+(N – 1)個孤立世界)。然后,一個框架應具有N個窗口對象,每個窗口對象用于一個世界。上下文是與窗口對象相對應的概念。這意味著,當我們有M個框架和N個世界時,我們有M * N個上下文(但是這些上下文是惰性創建的)。

 

如果是工人,則只有一個世界和一個全局對象。因此,只有一個上下文。

 

同樣,當您使用V8 API時,應該非常小心使用正確的上下文。否則,您最終將在孤立的世界之間泄漏JavaScript對象并造成安全災難(例如,來自A.com的擴展程序可以操縱來自B.com的擴展程序)。

 

如果您想了解更多信息:

 

V8 API

//v8/include/v8.h中定義了許多V8 API?。由于V8 API是低級的并且難以正確使用,因此platform / bindings /提供了一堆包裝V8 API的幫助程序類。您應該考慮盡可能使用助手類。如果您的代碼必須大量使用V8 API,則應將文件放在bindings / {core,modules}中。

 

V8使用句柄指向V8對象。最常見的句柄是v8 :: Local <>,用于從計算機堆棧指向V8對象。在計算機堆棧上分配v8 :: HandleScope之后,必須使用v8 :: Local <>。v8 :: Local <>不應在機器堆棧之外使用:

 

void function(){

??v8 :: HandleScope范圍;

??v8 :: Local <v8 :: Object> object =…;?// 這是對的。

}

 

類SomeObject:公共GarbageCollected <SomeObject> {

??v8 :: Local <v8 :: Object> object_;?//這是錯誤的。

};

 

如果要從計算機堆棧外部指向V8對象,則需要使用包裝器跟蹤。但是,您必須非常小心,不要用它創建參考循環。通常,V8 API很難使用。如果您不確定自己在做什么,請詢問blink-review-bindings @。

 

如果您想了解更多信息:

 

  • 如何使用V8 API和幫助程序類:platform / bindings / HowToUseV8FromBlink.md

V8包裝器

每個C ++ DOM對象(例如Node)都有其對應的V8包裝器。確切地說,每個C ++ DOM對象每個世界都有其對應的V8包裝器。

 

V8包裝器對其相應的C ++ DOM對象有很強的引用。但是,C ++ DOM對象僅對V8包裝程序具有弱引用。因此,如果您想讓V8包裝器存活一段時間,則必須明確地做到這一點。否則,將過早收集V8包裝器,并且V8包裝器上的JS屬性將丟失。

 

div = document.getElementbyId(“ div”);

child = div.firstChild;

child.foo =“酒吧”;

child = null;

GC();?//如果不執行任何操作,則| firstChild |的V8包裝器?由GC收集。

assert(div.firstChild.foo ===“ bar”);?// …這將失敗。

 

如果我們什么都不做,GC會收集child?,因此child.foo?會丟失。為了使div.firstChild?的V8包裝器保持活動狀態,我們必須添加一種機制,“?只要div?所屬的DOM樹可以從V8到達,則使div.firstChild?的V8包裝器保持活動狀態”。

 

有兩種方法可以使V8包裝器保持活動狀態:ActiveScriptWrappable包裝器跟蹤。

 

如果您想了解更多信息:

 

渲染管線

從將HTML文件發送到Blink到在屏幕上顯示像素還有很長的一段路要走。渲染管道的結構如下。

 

閱讀這個出色的資料,以了解渲染管線的每個階段的功能。(我認為我能寫出比甲板更好的解釋🙂

 

如果您想了解更多信息,請聯系:GC收集。

 

assert(div.firstChild.foo ===“ bar”);?// …這將失敗。

 

如果我們什么都不做,GC會收集child,因此child.foo會丟失。為了使div.firstChild的V8包裝器保持活動狀態,我們必須添加一種機制,“只要div所屬的DOM樹可以從V8到達,則使div.firstChild的V8包裝器保持活動狀態”。

 

有兩種方法可以使V8包裝器保持活動狀態:ActiveScriptWrappable和包裝器跟蹤。

 

如果您想了解更多信息:

 

如何管理V8包裝器的生命周期:bindings / core / v8 / V8Wrapper.md

 

如何使用包裝程序跟蹤:platform / bindings / TraceWrapperReference.md

 

渲染管線

從將HTML文件發送到Blink到在屏幕上顯示像素還有很長的一段路要走。渲染管道的結構如下。