標籤: 台北網頁設計公司

據美國科技部落格 VentureBeat 報導，德國汽車廠商戴姆勒 （Daimler） 將在 2016 年 10 月份舉行的巴黎國際汽車展上，首次推出超長續航距離電動汽車，希望電動 SUV 的市場與特斯拉 Model X 一較高下。   報導中表示，戴姆勒技術研發部門負責人湯瑪斯‧韋伯 （Thomas Weber） 在出席位於德國斯圖加特舉行的記者會時宣布，該公司將會展示續航里程達 500 公里的賓士電動汽車原型車，與特斯拉 Model X 一較高下。不過， Thomas Weber 並未透露這款電動汽車何時上路行駛，只說會在 2020 年前完成這一目標。   目前，戴姆勒和歐洲其他汽車廠商正加緊對電動汽車的投資，以滿足歐盟新的排放標準，並且追趕上美國電動汽車產業的當紅炸子雞──特斯拉 （Tesla） 。另外，戴姆勒在德國本土的競爭對手，福斯旗下子公司包括奧迪與保時捷均已推出續航里程很長的電動汽車原型車，至於 BMW 也正在開發這種車型。   Thomas Weber 表示，戴姆勒將在 2016 年底推出第四代 Smart 電動汽車，包括兩座和四座兩個車型。戴姆勒目前共有 Smart 和 B 系列兩個全電動車型，還有眾多插電式混合動力車，即同時採用電池和汽油引擎驅動的車型。新款混合動力車也在開發之中。據了解，戴姆勒的目標是在 2020 年以前，每年售出超過 10 萬輛電動車。不過，Thomas Weber 拒絕提供 2015 年的銷售資料。   除了長距離續航力的電動車之外，戴姆勒還在開發燃料電池汽車，這種車型使用由氫發的電。該公司原計劃在 2014 年推出燃料電池汽車，但由於價格問題，不得不延遲發表。消息指出，戴姆勒燃料電池汽車 SUV GLC 預計將在 2017 年投產，屆時可能會與豐田 Mirai 展開競爭。   （首圖來源： CC BY 2.0）   （本文授權轉載自《》─〈〉）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!

分享嘉賓：孫宇，百度NLP主任研發架構師、語義計算技術負責人。

本文根據作者在“2019自然語言處理前沿論壇”語義理解主題的特邀報告整理而成。

本報告提綱分為以下3個部分：

·    語義表示

·    語義匹配

·    未來重點工作

語義計算方向在百度NLP成立之初就開始研究，研究如何利用計算機對人類語言的語義進行表示、分析和計算，使機器具備語義理解能力。相關技術包含語義表示、語義匹配、語義分析、多模態計算等。

本文主要介紹百度在語義表示方向的技術發展和最新的研究成果艾尼（ERNIE），同時也會介紹工業應用價值很大、百度積累多年的語義匹配SimNet的相關內容，最後再談談未來的重點工作。

 一、語義表示

 計算機理解語言是一個具有很大挑戰的問題。人類在理解語言的過程中，除了語言符號本身的識別，還包含符號背後的語義和知識。舉個例子，當人看到“計算機”這個符號時，腦子里能迅速浮現出計算機的畫面以及和計算機相關的知識和概念，但是這對於計算機就比較困難。所以如何讓計算機能夠表示語言是研究的重點，讓其既能夠蘊含語義信息又可以計算。

當前主要有兩類方法，一是基於形式化規則的方法，如通過構建語義關係網絡來描述語義的信息；二是基於統計的方法，包括主題模型、Word Embedding等技術。

1、百度早期語義表示技術：基於檢索的表示方法

 

2007年百度便開始語義表示研究，最開始的思路是利用搜索引擎來完成。通過搜索引擎把要表示的句子或者詞語檢索出來，再根據檢索的結果通過Term的分析以及網頁的分析，把相關的詞、信息抽取出來，做成語言符號的表示。但是這個表示實際上停留在原始詞彙空間，表示的空間大小依然是詞表的維度，只是相對於One-Hot的表示來說更精細，這個方法是基於1954年Harris提出來的“上下文相似的詞，其語義也相似”的假設。

2、百度早期語義表示技術：Topic Model

 

此後，百度又研究了Topic Model的語義表示技術，這種方法的核心思路是把文檔詞彙空間降維，將文檔映射到淺層主題的分佈上，而這種主題空間要比詞的分佈空間更小一些。通過降維的方法，可以得到每個詞到主題的映射，通過這種主題的方法做語義的表示。

當時百度主要解決的問題是怎樣做這種新文檔的表示，難點是超大規模語料訓練、Online EM、MPI并行化。此外，百度還將自研的主題模型以及一些主流的主題模型整理為工業應用工具，對外開源了百度NLP主題模型工具包FAMILIA。

3、基於DNN的語義表示技術：Word Embedding

 

深度學習技術興起，基於Word Embedding的表示佔了主流，此類技術在各種NLP任務中也表現出色。從NNLM到現在BERT的技術，取得了很多進展。2013年的Word2vec成為NLP標配性的初始化向量，2018年有了上下文相關的詞向量ELMo等。

 

從2013年到2016年，百度也大力投入到Word Embedding的研究，主要研究工作是在工業界如何用大規模分佈式從海量數據中計算詞向量。比如，怎麼才能高效訓練規模為1T的語料？如何構建大規模分佈式文本計算？此外，算法上我們也有一些研究，比如，如何在一百萬超大規模的詞表裡完成Softmax分類？我們通過一些策略和技術，做成啟髮式Hierarchical Softmax的方法，從而有效地提升分類的效率。2016年，百度把訓練的1T的網頁數據和100萬詞表規模的詞向量對業界進行了開放。

4、多特徵融合的表示模型

 

BERT的核心思路還是大力出奇迹，它利用了大規模的無監督數據，同時藉助Transformer這種高性能的Encoder的能力，在MASK建模任務上做了一些優化，導致這個效果能夠在各個任務上顯著提升。

百度實際在2017年進行了這方面的探索，當時是研究基於對話的口語理解問題，這個問題的核心是做意圖的分類和槽位的標註。難點在於口語理解的問題標註語料非常少。當時想能不能利用海量的搜索語料做Pre-Training，把這個Model作為初始化模型用到下游的SLU任務里。

我們採用20億搜索的Query，通過LSTM模型做單向Language Model的預訓。我們發現在SLU任務上，在各個垂類上樣本數的增加非常顯著，從10個樣本到2000個樣本。但遺憾的是，當時研究的是一個超小規模數據上效果，即2000的數據，在2萬甚至是20萬的數據上的表現並沒有研究，同時在其他應用的通用性上的研究也不夠充分。

5、知識增強的語義表示模型

 BERT提出后，我們發現一個問題，它學習的還是基礎語言單元的Language Model，並沒有充分利用先驗語言知識，這個問題在中文很明顯，它的策略是MASK字，沒有MASK知識或者是短語。在用Transformer預測每個字的時候，很容易根據詞包含字的搭配信息預測出來。比如預測“雪”字，實際上不需要用Global的信息去預測，可以通過“冰”字預測。基於這個假設，我們做了一個簡單的改進，把它做成一個MASK詞和實體的方法，學習這個詞或者實體在句子裏面Global的信號。

 

基於上述思想我們發布了基於知識增強的語義表示ERNIE(1.0)。

 

我們在中文上做了ERNIE（1.0）實驗，找了五個典型的中文公開數據集做對比。不管是詞法分析NER、推理、自動問答、情感分析、相似度計算，ERNIE（1.0）都能夠顯著提升效果。

 

英文上驗證了推廣性，實驗表明ERNIE（1.0）在GLUE和SQuAd1.1上提升也是非常明顯的。為了驗證假設，我們做了一些定性的分析，找了完形填空的數據集，並通過ERNIE和BERT去預測，效果如上圖。

 

我們對比了ERNIE、BERT、CoVe、GPT、ELMo模型，結果如上圖所示。ELMo是早期做上下文相關表示模型的工作，但它沒有用Transformer，用的是LSTM，通過單向語言模型學習。百度的ERNIE與BERT、GPT一樣，都是做網絡上的Transformer，但是ERNIE在建模Task的時候做了一些改進，取得了很不錯的效果。

 

在應用上，ERNIE在百度發布的面向工業應用的中文NLP開源工具集進行了驗證，包括ERNIE與BERT在詞法分析、情感分類這些百度內部的任務上做了對比分析。同時也有一些產品已經落地，在廣告相關性的計算、推薦廣告的觸發、新聞推薦上都有實際應用。目前模型已經開源（

7月31日，百度艾尼（ERNIE） 再升級，發布了持續學習語義理解框架ERNIE 2.0，同時藉助飛槳（PaddlePaddle）多機多卡高效訓練優勢發布了基於此框架的ERNIE 2.0 預訓練模型。該模型在共計16个中英文任務上超越了BERT 和XLNet，取得了SOTA 效果。

二、語義匹配

1、文本語義匹配及挑戰

 

語義匹配在工業界具有非常大的技術價值，它是一個很基礎的問題，很多產品、應用場景都會用到它。很多問題也可以抽象為語義匹配問題，比如，搜索解決的是Query和Document相關性的問題，推薦解決的是User和Item關聯度、興趣匹配度的問題，檢索式問答解決的是問題與答案匹配度，以及檢索對話Query和Response的匹配問題。由於語言比較複雜，匹配靠傳統的方法是比較難的。

 

百度搜索在匹配相似度計算方面做了較多工作，包括挖掘同義詞、詞級別泛化、語義緊密度、對齊資源挖掘、共線關聯計算等。

 

2、神經網絡語義匹配模型：SimNet

2013年百度提出SimNet技術，用於解決語義匹配的問題。這個技術基於DNN框架，沿襲Word Embedding的輸入，基於End-to-End的訓練做表示和匹配，並結合Pairwise訓練。當時，微軟也提出了DSSM，中科院、CMU等研究機構也做了很多語義匹配研究工作。

 

這幾年，百度整體上從語義匹配的框架上做了升級，抽象了三個層次，改進了基礎算法，包括擴展針對不同場景的模型，比如字和語義的匹配模型；在不同的應用場景，針對問題網頁和問題答案的匹配情況分別做了針對性地優化，集成到了匹配框架里。

 

匹配算法主要有兩種範式，一種是基於表示的匹配，首先把自然語言表示成向量，然後再進行相似度計算，這方面也有一些改進，主要是做一些Attention；另一種新匹配範式Interaction-based Model，強調更細的匹配，即一個句子的表示不再是一個向量，而是原來的Term，並把原來的位置信息保留，最後以Attention的方式表示，讓匹配更加充分和精細。

 

關於SimNet技術前瞻性工作，2019年百度在IJCAI上發表了一篇論文“RLTM：An Efficient Neural IR Framework for Long Documents”，其中長文本匹配有一個很大的挑戰，就是讓Document直接做表示，如果文本太長，很多信息會丟失，計算效率也非常低。但如果我們先做一個粗匹配，選擇好相關的句子以後再做精細化的匹配，效果就比較不錯。

3、SimNet的應用

 

SimNet技術在百度應用非常廣泛，包括搜索、資訊推薦、廣告、對話平台都在使用。

 

搜索是百度非常重要的產品，搜索有兩個核心功能，下圖的左側上方是搜索的精準問答，通過問答技術把精準答案直接呈現出來；下方是自然排序，主要採用LTR框架和相關性、權威性、時效性等Features。

SimNet在百度搜索的發展可以分為三個時期。萌芽期，上線了BOW Model，這是業界第一次在搜索引擎上線DNN模型；發展期，做了CNN、RNN，並把知識融合進RNN，在語義相關性計算中，除了標題很多其他文本域在相關性建模中也很重要，所以，我們還做多文本域融合匹配的Model；拓展期，除了相關性，在權威性、點擊模型和搜索問答上都有推廣和使用。

 

在搜索中，SimNet是用超大規模用戶反饋數據訓練。那麼如何依靠海量數據來提升效果？頻次如何選？我們發現模型應用效果並不是靜態的，而是動態變化的，特別是搜索反饋的數據，隨着時間的推移，網民在搜索的時候，Term的分佈、主題的分佈會發生變化，所以數據的時效性影響還是非常大的。

 

除了模型上的融合，我們把Bigram知識也融入了進去。儘管RNN已經很厲害了，但加入知識、模型還是會有很大地提升。

4、新模型：SimNet-QC-MM

 

另外，我們還做了Query和網頁正文的建模，由於Query中每個詞都有一定的用戶意圖，所以在模型建模時，會考慮Query中每個詞被Title和正文覆蓋的情況，並基於Matching Matrix匹配方法計算。此外，搜索架構也做了配合改進，搜索也上線了基於GPU和CPU的異構計算架構。

 

上圖是一個案例，“羋殊出嫁途中遇到危險”，我們後來做了一些分析，發現“危險”和“投毒”有很強的語義關聯，就把這個結果排了上去。

5、語義模型壓縮技術

 

在模型裁減壓縮上，我們也做了很多工作，包括量化的壓縮和哈希技術的壓縮。整個語義的模型基本上已經從依靠一個Embedding 32bits來存，到現在達到Embedding一維僅需4bits，節省線上DNN匹配模型87.5%的內存消耗。這項技術，除了搜索的使用，移動端的使用也有非常大的價值。

 

SimNet技術除了百度搜索，包括Q&A，Query和Answer的匹配等方面都有一些嘗試。

三、未來重點工作

接下來我們會在通用語義表示方面進一步研究與突破，除了如何充分地利用先驗知識，利用一些弱監督信號外，模型方面也會進一步探索創新。技術拓展上，跨語言、多語言表示，面向生成、匹配等任務的表示，面向醫療、法律等領域的表示，多模態表示等都是我們的一些重點方向。

RLTM論文地址：

至此，“2019自然語言處理前沿論壇”語義計算主題《百度語義計算技術及其應用》的分享結束。如果大家想更深入地了解百度持續學習語義理解框架艾尼（ERNIE），歡迎加入ERNIE官方交流群（QQ群號：760439550）。

——————-

划重點！！！

掃碼關注百度NLP官方公眾號，獲取百度NLP技術的第一手資訊！

加入ERNIE官方技術交流群（760439550），百度工程師實時為您答疑解惑！

立即前往GitHub（  ）為ERNIE點亮Star，馬上學習和使用起來吧！ 

 

最強預告！！！

11月23日，艾尼（ERNIE）的巡迴沙龍將在上海加場，乾貨滿滿的現場，行業A級的導師，還有一群志同道合的小夥伴，還在等什麼？感興趣的開發者們趕緊掃描下方“二維碼”或點擊“鏈接”報名參加吧！

 

報名鏈接：

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!

在傳統桌面程序中，對圖標的使用大多是直接嵌入JPG或者PNG的圖片。在祖傳的1366×768分辨率下，並沒有什麼問題。相對於手機硬件的突飛猛進，也側面反映了PC行業的落寞和桌面程序開發的不思進取。用360衛士的群眾並不能倒推PC行業的升級。反倒是水果公司雙高的利潤和口碑讓人很是眼饞。加之某軟跳出來教豬隊友做硬件。現在倒是有些起色，1080p的屏幕已是標配，4k也算常見。那麼傳統桌面程序在升級過程中，就會遇到今天要討論的，如何解決高分辨率下圖標模糊的問題。

一種解決方案是按最高的分辨率提供圖片。這種適合較大的圖片，比如背景啥的。另一種就是今天要討論的，針對當前流行的、扁平化圖標的解決方案。

 從本篇的標題可以看出，我們希望應用SVG矢量圖來適應各種分辨率的情況。以WPF程序為例，首先要面對的問題是，WPF並不支持像嵌入JPG/PNG圖標這樣，直接使用SVG圖標。大動干戈的引用第三方library通過自定義類型來支持SVG並不是本文的目的。這裏我們要介紹如何通過字體文件，進而在WPF或UWP中使用SVG圖標的方式。

雖然WPF不支持直接使用SVG文件，但是Windows是支持矢量字體的。而我們的目的就是要將圖標以字體的形式在WPF程序中显示。具體使用的字體TrueType，則是由微軟和蘋果共同開發的字體類型標準，該字體文件的擴展名是.ttf。

接下來我們依然是通過Sample工程來說明。首先給出GitHub的地址：

首先我們打開WpfAppWithPNGs工程，圖標的使用代碼如下：

        <Image Grid.Row="0" Grid.Column="0"  Width="32" Height="32" Source="Resources/Airplane_Off.png" ></Image>
        <Image Grid.Row="0" Grid.Column="1"  Width="64" Height="64" Source="Resources/Airplane_On.png" ></Image>
        <Image Grid.Row="0" Grid.Column="2"  Width="96" Height="96" Source="Resources/Bluetooth_Off.png"  ></Image>
        <Image Grid.Row="0" Grid.Column="3"  Width="128" Height="128" Source="Resources/Bluetooth_On.png"  ></Image>

 

這裏主要有兩個問題，因為我們默認提供的是32×32的圖標，因此除了第一列Width和Height設置為32的圖標，其他的圖標都存在模糊的問題。第二個問題是針對圖標的每一種顏色，都需要對應提供不同的圖標文件（圖中的例子需要有灰色和藍色兩份文件）。相對的SVG圖標僅僅需要一份文件。即可在程序中動態設定不同的顏色了。

這裏先給出最終WPF項目中，對SVG圖標的引用的代碼，然後我們再進行詳細解釋。對應的工程名為WpfAppWithFontIcons。

        <TextBlock Grid.Row="0" Grid.Column="0" Text="{x:Static local:FontIcons.airplane_mode_circ}"   Foreground="Gray"  FontSize="32" ></TextBlock>
        <TextBlock Grid.Row="0" Grid.Column="1" Text="{x:Static local:FontIcons.airplane_mode_circ}"  Foreground="{StaticResource dellBlue}"  FontSize="64" ></TextBlock>
        <TextBlock Grid.Row="0" Grid.Column="2" Text="{x:Static local:FontIcons.bluetooth_inactive}"   Foreground="Orange"  FontSize="96" ></TextBlock>
        <TextBlock Grid.Row="0" Grid.Column="3" Text="{x:Static local:FontIcons.bluetooth_inactive}"    Foreground="Brown"  FontSize="128" ></TextBlock>

代碼最大的不同應該是由<Image/>標籤更改為<TextBlock/>標籤，這是因為我們是通過ttf字體文件，曲線救國的方式來使用SVG圖標。

具體的步驟如下：

準備SVG圖標文件，將這些文件打包成一整個ttf字體文件。打包的方式有很多種，通常我使用的是IcoMoon的免費解決方案。地址如下：

通過這個網站選擇SVG圖標文件上傳，打包生成一個zip文件。解壓後文件夾結構如下圖：

ttf文件在fonts文件夾中，實際使用時，需要作為資源文件，添加到WPF工程中。點擊圖中的demo.html會打開一個本地網頁，可用於查找ttf文件中包含的SVG圖標，以及對應的unicode。實際我們是通過對unicode的引用來显示SVG圖標的。

完整的project結構如下圖，Fonts文件夾是手動添加用來放置ttf文件。ttf文件名字都是根據項目需要來取，並不固定。

ttf字體文件需要以<FontFamily/>的形式添加到項目的<Resources/>節點中。然後再通過<Style/>指定給<TextBlock/>。當然不在<Resources/>節點定義Style，而是在每個<TextBlock/>中指定FontFamily屬性也是可以的。有關XAML的語法細節，回字的四種寫法什麼的，這裏略過不提。

    <Window.Resources>
        <FontFamily x:Key="Fonticon">/Fonts/rcc-fonticon-ribbon-v2.ttf#rcc-fonticon-ribbon-v2</FontFamily>
        <Style TargetType="TextBlock">
            <Setter Property="FontFamily" Value="{StaticResource Fonticon}" ></Setter>
        </Style>
        <SolidColorBrush x:Key="dellBlue">#007DB8</SolidColorBrush>
    </Window.Resources>

這裏說明一下“/Fonts/rcc-fonticon-ribbon-v2.ttf#rcc-fonticon-ribbon-v2”值的定義，#前面的是文件路徑，#後面的是font name，查看的方法是雙擊ttf文件，參考下圖。

在定義好FontFamily之後，我們並不推薦直接將unicode寫到XAML或.cs文件中。因為在XAML中，你需要如下編寫：

<TextBlock Grid.Row="0" Grid.Column="0" Text="&#xe900;" Foreground="Gray"  FontSize="32" ></TextBlock>

而在C#代碼中，又需要以下面這種格式：

textBlockAirplane.Text = "\ue900"；

兩種不統一的格式會在將來修改時帶來極大的困難，特別是圖標被多處引用時，全局的查找替換根本就是噩夢。此外，毫無意義的unicode值的可讀性根本等於0。正常人類無法將”&#xe900;”，”\ue900″和Airplane的圖標聯繫起來。

我推薦的做法是生成一個FontIcons Class，以string類型屬性的形式暴露出來。這樣可以獲得IDE智能語法提示的支持，更新時也僅需修改這個Class，Find All Reference更是方便無比。同時無論在XAML文件，還是C#代碼中，我們看到的都是統一的“FontIcons.airplane_mode_circ”。

    public static class FontIcons
    {
        public static string airplane_mode_circ { get; } = "\ue900";
        public static string bluetooth_inactive { get; } = "\ue901";
        public static string brightness { get; } = "\ue902";
        public static string brightness_inactive { get; } = "\ue903";
        public static string browse_inactive { get; } = "\ue904";
        public static string camera { get; } = "\ue905";
    }

那麼我們是不是需要手工來編寫FontIcons Class呢？大哥我們是能把午飯（我不愛喝咖啡）轉換成Code的生物啊！當然是寫個小工具來自動生成了。在Sample庫中，參考IcoMoonReader工程，只需將IcoMoon生成的.svg文件（icomoon.zip解壓后的fonts文件夾里）丟在IconMoonReader.exe同級目錄，即可生成相應代碼。

 其實只有一個方法啦，使用時需要注意具體的文件名是否正確。

            using (var stream = new FileStream("rcc-fonticon-ribbon-v2.svg", FileMode.Open))
            {
                using (var reader = new StreamReader(stream))
                {
                    var pattern = "unicode(\\S)*\\sglyph-name(\\S)*\"";
                    var input = reader.ReadToEnd();
                    foreach (Match match in Regex.Matches(input, pattern))
                    {
                        pattern = "\"\\S*\"";
                        var list = new List<string>();
                        foreach (var result in Regex.Matches(match.Value, pattern))
                        {
                            list.Insert(0, result.ToString());
                        }
                        var name = list[0].Replace("\"", "").Replace("-","_");
                        var code = list[1].Replace("&#x", "\\u").Replace(";", "");
                        Console.WriteLine($"public static string {name} {{ get; }} = {code};");
                    }
                }
            }

把生成的C#字符串定義貼到具體工程的FontIcons Class(名字隨意)。

這樣一個優秀的解決方案如果僅支持WPF，那又談何遷移到MS Store呢？實際上這套機制放到UWP工程中也是可以的。雖然UWP可以通過SvgImageSource屬性原生支持SVG了，但我們的這套方案在圖標的應用方面毫不遜色，甚至可以說更為方便。具體的例子可以參考AppWithFontIcon工程。在這個UWP的工程中，除了放ttf文件的位置我換到了現成的Assets文件夾，幾乎沒有改變。

        <TextBlock Grid.Row="0" Grid.Column="0" Text="{x:Bind local:FontIcons.airplane_mode_circ}"   Foreground="Gray"  FontSize="32" ></TextBlock>
        <TextBlock Grid.Row="0" Grid.Column="1" Text="{x:Bind local:FontIcons.airplane_mode_circ}"  Foreground="{StaticResource dellBlue}"  FontSize="64" ></TextBlock>
        <TextBlock Grid.Row="0" Grid.Column="2" Text="{x:Bind local:FontIcons.bluetooth_inactive}"   Foreground="Orange"  FontSize="96" ></TextBlock>
        <TextBlock Grid.Row="0" Grid.Column="3" Text="{x:Bind local:FontIcons.bluetooth_inactive}"    Foreground="Brown"  FontSize="{x:Bind DynamicFontSize(),Mode=OneWay,FallbackValue=128}" ></TextBlock>

因為UWP沒有了x:static關鍵字，所以我換成了x:Bind。換成x:Bind之後甚至可以動態的響應值的變化。比如我在這裏把FontSize做了一個x:bind到DynamicFontSize()方法，讓字體隨着界面改變，動態的變大變小。雖然並沒有什麼卵用……但是Demo的時候可以增加點噱頭……

本篇到此結束，照例貼上Github地址：

感謝耐着性子看到這裏的同學！

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計

※不管是台北網頁設計公司、台中網頁設計公司，全省皆有專員為您服務

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※帶您來看台北網站建置，台北網頁設計，各種案例分享

目錄

示例代碼託管在：

博客園地址：

華為雲社區地址：

附件PPT來自開發文檔。術語里的cc指的是Chromium Compositor

一直以來都想了解瀏覽器合成層的運作機制，但是相關的中文資料大多比較關注框架和開發技術，這方面的資料實在是太少了，後來在chromium官方網站的文檔里找到了項目組成員malaykeshav在 2019年4月的一份關於瀏覽器合成流水線的演講PPT，個人感覺裏面講的非常清楚了，由於沒有找到視頻，有些部分只能自行理解，本文僅對關鍵信息做一些筆記，對此感興趣的讀者可以在文章開頭的github倉庫或附件中拿到這個PPT自行學習。

摘要

1.合成流水線

合成流水線，就是指瀏覽器處理合成層的工作流程，其基本步驟如下：

大致的流程就是說Paint環節會生成一個列表，列表裡登記了頁面元素的繪製指令，接着這個列表需要經過Raster光柵化處理，並在合成幀中處理紋理，最後的Draw環節才是將這些紋理圖展示在瀏覽器內容區。

2. 預定義UI層

chromium中預定義了一些指定類型的UI層，大致分為：

• Not Drawn – 為了處理透明度或濾鏡效果、transform變形或者clip剪裁的非繪製層
• Solid color layer – 固有顏色層
• Painted texture layer – Texture紋理會在這個層執行paint渲染和後續的rasterized光柵化任務
• Transferable resource layer – 共享資源層，可能是GPU裏面的Texture紋理也可能未來會發給GPU的位圖
• Surface layer – 臨時佔位層，因為自頂向下遍歷layer樹時子樹都還沒處理，需要先佔位最後再填充
• Nine patch layer – 用於實現陰影的層

3. paint是什麼意思

每個層layer是由若干個views組成的，所謂paint，就是每個views將自己對應圖形的繪製指令添加到層的可展示元素列表Display Item List里，這個列表會被添加到一個延遲執行的光柵化任務中，並最終生成當前層的texture紋理（可以理解為當前層的繪製結果），考慮到傳輸性能以及未來增量更新的需求，光柵化的結果會以tiles瓦片形式保存。在chrome中也可以看到頁面瓦片化拆分的結果:

4. 分層的優勢和劣勢

分層的優勢和劣勢也在此進行了說明，和之前我們主動思考的答案基本一致（暗爽一下）。

5. 視圖屬性及其處理方式

views中支持的屬性包含Clip剪裁，transform變換,effect效果（如半透明或濾鏡等）,mask遮罩，通常按照後序遍歷的方式自底向上進行遍歷處理。

clip剪裁的處理方式是在父節點和子節點之間插入一個剪裁層，用來將其子樹的渲染結果剪裁到限定的範圍內，然後再向上與父級進行合併；

transform變換直接作用於父節點，處理到這個節點時其子樹都已經處理完畢，直接將整體應用變形即可；

effect效果一般直接作用於當前處理的節點，有時也會產生交叉依賴的場景；

PPT第40頁中在介紹effect效果處理時描述了兩種不同的透明度處理需求，從而引出了一個Render Surface的概念，它相當於一個臨時的層，它的子樹需要先繪製在這個層上，然後再向上與父節點進行合併，屏幕就是是根級的Render Surface。

6. Quads

Layer遍歷處理輸出的結果被稱為Quads（從意思上理解好像就是指輸出了很多個矩形方塊），每個quad都持有它被繪製到目標緩衝區所需要的資源，根據它持有的資源不同可以分為：

• Solid Color-固定顏色型
• Texture– 紋理型
• Tile– 瓦片型
• Surface– 臨時繪圖表面型
• Video – 視頻幀型
• Render Pass – Render Surface類型的佔位區，Render Surface子樹處理完后填充到關聯的Render Pass

7. Compositor Frame

合成層真正的工作要開始了，主角概念Compositor Frame(合成幀)登場，它負責將quads合併繪製在一起，膠片里59-62頁非常清楚地展示了合成的過程，最終輸出的結果就是根節點的紋理。

chromium是多進程架構，Browser Process瀏覽器進程會對菜單欄等等容器部分的畫面生成合成幀來輸出，每個網頁的Render Process渲染進程會對頁面內容生成合成幀來輸出，最終的結果都被共享給GPU ProcessGPU進程進行聚合併生成最終完整的合成表面，接着在Display Compositor環節將最後的位圖展示在屏幕上。

8. 關於光柵化以及渲染方式

膠片里並沒有描述具體的光柵化的處理過程，但是layer輸出的quads看起來應該是光柵化以後的結果，推測應該是處理Display Item List中的繪圖指令時也和WebGL類似，經過頂點着色器和片元着色器的遍歷式處理機制，並在過程中自動完成像素插值。

9.【重要】軟件渲染和硬件渲染的區別

聲明：本節內容是個人理解，僅用作技術交流，不保證對！

軟件渲染和硬件渲染的區別對筆者而言一直非常抽象，只是知道基本概念。後來在（國內可能無法訪問）中《Compositor Thread Architecture》這篇合成器線程架構的文章中找到了一些相關描述，也解開了筆者心中一直以來的疑惑，相關部分摘抄如下：

Texture Upload

One challenge with all these textures is that we rasterize them on the main thread of the renderer process, but need to actually get them into the GPU memory. This requires handing information about these textures (and their contents) to the impl thread, then to the GPU process, and once there, into the GL/D3D driver. Done naively, this causes us to copy a single texture over and over again, something we definitely don’t want to do.

We have two tricks that we use right now to make this a bit faster. To understand them, an aside on “painting” versus “rasterization.”

• Painting is the word we use for telling webkit to dump a part of its RenderObject tree to a GraphicsContext. We can pass the painting routine a GraphicsContext implementation that executes the commands as it receives them, or we can pass it a recording context that simply writes down the commands as it receives them.
• Rasterization is the word we use for actually executing graphics context commands. We typically execute the rasterization commands with the CPU (software rendering) but could also execute them directly with the GPU using Ganesh.
• Upload: this is us actually taking the contents of a rasterized bitmap in main memory and sending it to the GPU as a texture.With these definitions in mind, we deal with texture upload with the following tricks:
• Per-tile painting: we pass WebKit paint a recording context that simply records the GraphicsContext operations into an SkPicture data structure. We can then rasterize several texture tiles from that one picture.
• SHM upload: instead of rasterizing into a void* from the renderer heap, we allocate a shared memory buffer and upload into that instead. The GPU process then issues its glTex* operations using that shared memory, avoiding one texture copy.The holy grail of texture upload is “zero copy” upload. With such a scheme, we manage to get a raw pointer inside the renderer process’ sandbox to GPU memory, which we software-rasterize directly into. We can’t yet do this anywhere, but it is something we fantasize about.

大概翻譯一下，方便英語水平一般的小夥伴理解，GPU處理圖片的方式是按照Texture進行貼圖的，對此不熟悉的小夥伴可以查看筆者以前發的有關Three.js相關的博文。

紋理上傳:
處理紋理的挑戰之一就是它是在渲染進程（可以理解為單個Tab網頁的進程）的主線程里進行的，但是最終需要將其放入GPU內存。這就需要將紋理數據遞交給合成器線程，然後再交給GPU進程（Chromium架構里有專門的GPU進程用來專門處理和GPU之間的協作任務），最後再傳遞給底層的Direct3D或OpenGL（也就是圖形學的底層技術），如果只是按照常規流程來處理，就會需要一次又一次來複制生成的紋理數據，這顯然不是我們想要的。
我們現在使用了兩個小方法來使這個流程變得快一點。它們分別作用於painting（繪製）和rasterization（光柵化）兩個階段。

• 1號知識點！！！Painting我們用來告訴webkit為RenderObject Tree的來生成對應的GraphicsContext。通過給painting routine（繪製流程）傳遞一個GraphicsContext的具體實現來執行這些已經編排好的繪製命令，也可以傳遞一個record context（記錄上下文）只是簡單地把繪圖命令都記錄下來。
• 2號知識點！！！Rasterization（光柵化）是指Graphics context關聯的繪圖命令實際被執行的過程。通常我們使用CPU（也就是軟件渲染的方式）來執行光柵化任務，也可以直接使用GPU來渲染（也就是硬件渲染的方式）。
• 上傳：指在主線程存儲區獲取到光柵化以後的位圖內容然後將它作為紋理上傳給GPU的過程，考慮到上述已經提及的定義，上傳過程是如下來處理的：
  • 瓦片繪製：我們在webkit中使用recording context來簡單地記錄Graphics Context的操作指令，將它存儲為SkPicture類型（直接使用軟件光柵化時生成的是SkBitmap類型），隨後可以從一張picture裏面光柵化處理得到多個紋理瓦片。
  • 共享內存：在軟件渲染的方式中，光柵化的結果會被存儲在renderer進程的堆內存里，現在不這樣搞了，我們重新分配了一塊共享緩衝區，然後通過它來傳遞相關對象，GPU進程隨後在獲取紋理時直接從共享內存中獲取就行了，這樣就避免了數據的拷貝。
    總的來說，紋理上傳的過程幾乎是零拷貝的。利用這樣的結構，我們在renderer進程（也就是網頁的渲染進程）的沙箱環境內也可以獲取到指向GPU 內存的指針，而在軟件光柵化的過程中，是直接將位圖結果放在這裏的。

• Painting: this is the process of asking Layers for their content. This is where we ask webkit to tell us what is on a layer. We might then rasterize that content into a bitmap using software, or we might do something fancier. Painting is a main thread operation.
• Drawing: this is the process of taking the layer tree and smashing it together with OpenGL onto the screen. Drawing is an impl-thread operation.
• painting:表示的過程是向Layers對象查詢層內容，也就是讓webkit告訴我們每一層上面到底有什麼。接下來我們就可以使用軟件光柵化的方式將這些內容處理為位圖，也可以做一些更牛的事情，painting是一個主線程行為。
• drawing：是指將Layer中的內容用OpenGL繪製在屏幕上的過程，它是另一個線程中的操作。

概念比較多沒有基礎的讀者可能理解起來有難度，我嘗試用自己的話複述一下：

【軟件渲染】的模式下，在paint時會直接利用Graphics Context繪圖上下文將結果繪製出來，在一個SkBitmap實例中保存為位圖信息；【硬件渲染】的模式下，在paint時傳入一個SkPicture實例，將需要執行的繪圖命令保存在裏面先不執行，然後通過共享內存將它傳給GPU進程，藉助GPU來最終去執行繪圖命令，生成多個瓦片化的位圖紋理結果（OpenGL中頂點着色器向片元着色器傳遞數據時可以自動進行數據插值，完成光柵化的任務）。 純軟件渲染里嚴格說是沒有合成層概念的，因為最終輸出的只有一張位圖，按照順序從下往上畫，和畫到一個新層上再把新層貼到已有結果上其實是一樣的。

不管使用哪種途徑，paint動作都是得到位圖數據，而最終的draw這個動作是藉助OpenGL和位圖數據最終把圖形显示在显示器上。

所以【硬件渲染】就是渲染進程把要做的事情和需要的數據都寫好，然後打包遞給GPU讓它去幹活。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!

日本松下（Panasonic）、中國北京汽車宣布將共同投資數百億日圓，於中國天津成立合資公司，用於生產純電動車之核心零組件，搶攻中國龐大的電動車市場商機。

《日本經濟新聞》中文版、日本《共同社》等多家媒體報導，松下社長津賀一宏日前曾前往中國，與北汽公司商討成立合資公司一事，並達成協議。北汽旗下兩家汽車零組件廠商將出資54%、松下的中國公司則出資46%，合資公司計畫在2018年左右開始投入量產，主要產品是電動車空調的電動壓縮機，供貨對象則是北汽公司與其他公司。

電動車的空調電力來自蓄電池。為優化電動車的行駛里程，電動車空調壓縮機須能以更好的效率控制冷、暖風，因此性能需求較一般汽油車高。性能佳的空調壓縮機，將有助提高電動車的續航力。

中國市場蓬勃，松下積極搶進

在政府的大力推動下，中國已在2015年成為全球最大電動車市場之一。《日經》指出，日廠豐田決定在2018年起於中國生產插電式混和動力車（PHEV）；而松下與北汽的合作，則象徵松下在中國市場的在地化布局行動。未來預計還會有更多日商在中國展開本土化生產。

松下已宣布退出電視面板製造事業，並轉而提高在住宅、汽車等兩大領域的業務著力。2015財年，松下所生產的車載導航儀與車載電池等零組件銷售額達1.3兆日圓。松下表示，到2018年度時，希望上述零組件銷售額能進一步提高到2兆日圓。

松下在電動車、鋰電池方面的海外投資，包括與美商特斯拉（Tesla）合作在美國內華達州建立的鋰電池工廠Gigafactory，以及中國大連建立的車用鋰電池工廠。大連工廠預計在2017年正式投產。

北汽成立於1953年，為國有企業。在電動車、PHEV領域，北汽是中國僅次於比亞迪（BYD）的第二大業者。北汽計畫到2020年時生產40萬輛電動車。

（照片來源：Wikipedia）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!

電動車龍頭特斯拉（Tesla）股價近期出現戲劇性走勢，3、4 日連續兩天以 2 位數速度暴漲，5 日則受中國交車進度料延遲的消息影響，股價重挫逾 17%。不過，中國官員 8 日表示，將盡全力協助企業復工，特斯拉上海工廠將於 10 日恢復生產。

路透社 8 日報導，中國各地工廠的農曆新年假期停工時間，原定 1 月 30 日結束，但由於新型冠狀病毒肺炎疫情嚴峻，中國政府緊急要求企業及工廠延長停工至 2 月 9 日，以防堵疫情擴散。

2 月 4 日，特斯拉全球副總裁陶琳在個人微博表示，原定春節後 2 月初的交車計畫將會暫緩，疫情好轉後會盡力補上交車進度。受此消息影響，5 日特斯拉股價大跌 17.18%，創公司史上第二高單日跌幅，僅次 2012 年 1 月 13 日的 19.33%。

對此，上海市人民政府新聞發言人徐威表示，針對特斯拉等重點企業在復工過程遇到的實際困難，當局將盡全力協調，幫助企業儘快恢復正常生產。

報導指出，特斯拉上海工廠耗資 20 億美元，是特斯拉旗下首座海外工廠，受中國政府大力支持。工廠去年 10 月開始生產，並於今年 1 月舉辦首批中國製 Model 3 交車儀式。

7 日特斯拉股價下跌 0.12%，收 748.07 美元。3 日及 4 日，特斯拉股價分別飆漲 19.89%、13.73%，使股價衝上 887.06 美元，但隨後回吐漲幅，5 日重挫 17.18% 至 734.70 美元。

光 2020 年初以來，特斯拉股價已瘋狂上漲 78.82%，但也引來泡沫效應的疑慮聲浪。CNBC 8 日報導，據 FactSet 數據，目前約 45% 華爾街分析師給予特斯拉股票「賣出」評級，比率創歷來新高，僅 19% 分析師給予「買進」評級，「持有」評級則佔 36%。

券商 Needham 分析師 Rajvindra Gill 5 日出具研究報告，對特斯拉給出「遜於大盤」評級。他指出，從未見過股價上漲如此快速，投資人對過去基本面或成長紀錄卻鮮少關注的現象，反映特斯拉股票的「非理性繁榮」（Irrational exuberance）達到歷史新高。

（本文內文由  授權使用；首圖來源：）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計

※不管是台北網頁設計公司、台中網頁設計公司，全省皆有專員為您服務

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※帶您來看台北網站建置，台北網頁設計，各種案例分享