2018 谷歌開發者大會上有哪些值得關注的信息？

12-30

本問題已加入專題 Google 開發者大會到底會揭曉哪些黑科技？歡迎點擊關注了解更多有關機器學習、ARCore、Android、移動網路、Firebase、Assistant、物聯網、Flutter 的內容。
不一定能親赴現場，畢竟也是個可以看直播的，去年的重磅很多，不知道今年有哪些產品和技術上的利好？
大家一起來交流。

9 月 20 日上午 9 點 20 分，谷歌大中華區總裁 Scott Beaumont、谷歌產品總監 Andrew Bowers 以及眾多來自全球各地的谷歌工程師將在現場與大家直面交流，與中國的開發者們分享重磅消息和最新科技。

為期兩天的 2018 谷歌開發者大會，直播主題將涵蓋機器學習、ARCore、Android、移動網路、Firebase、Assistant、物聯網、Flutter等等。

科技很酷，未來很近，直達2018 Google開發者大會現場

-- update: 21號內容已更新 --

謝邀，今天去參與了9月20的第一天，作為一名web開發者，說說參會體驗和值得web開發者關注的信息。

— 21號的今晚更新（web主題超多）點贊不迷路哦—

首先20號的日程是這樣的：

簽到，拿禮包（禮品+廣告宣傳單等），進入主會場聽開幕。

開始開幕之前先玩了2輪微信小程序遊戲，千人同玩的谷歌猜畫小歌。

可惜沒能拿到獎品，最好成績是200多名。。

然後開始一天正式議題：

我在日程表上畫了一下我要去趕的會場和主題，可能看不太清楚，我下面寫一下：

1，主會場的議題是必選項，Google Developer Days 開幕主題演講，其中包含了，TensorFlow 簡介，Wear OS 簡介，Flutter簡介，AMP介紹等大會的主要議題的概括等。

2，web的現狀和未來發展趨勢。

3，遊戲廣告激勵視頻的創新和如何變現。（沒得聽了，就去了）

4，藉助Firebase發展你的App業務。

5，不斷改進電子商務。

6，倍道而進，AMP最佳商業實踐。

7，剖析你的Flutter App（只聽了最後5分鐘）

8，深入介紹Flutter Graphics 性能。

我參與的主要是和web開發者相關的議題，下面簡單說說體會和一些自己的感受。

主會場到10點多都是開幕演講，分了好幾輪，主要是介紹TensorFlow的應用場景和落地項目，規模等。然後就是Wear OS的介紹和產品演示，Flutter的介紹和閑魚的產品演示，AR Core的介紹宣講，AMP，PWA等web開發技術介紹和宣傳等，大多是技術概念科普，如果你之前關注過這些技術，這裡就是重複再給你說一遍，外加舉一些實際的場景例子和落地的廠商。

到了十點50，結束了開幕式，中間是休息時間，因為要聽12點15的web主題，所以直接奔去餐廳吃午飯了。

午飯過後就直接去了web的現狀和未來趨勢這一場，整體來說還是以google PWA為開場，介紹什麼是PWA，PWA的優勢和特性，以及和app native的對比，統計到的安裝量，PC端的PWA應用，然後開始說JavaScript性能在android低端機的表現，JavaScript的種種問題所以引出AMP（加速移動頁面，針對google搜索引擎），Web Packagin（瀏覽器可自己尋找最近的Pack鏡像），webassembly（解決低端機JavaScript的性能問題，在PC端可以引入複雜的交互應用）。最後再加一張圖，更多的新功能，很讓人激動：

然後後邊聽的是遊戲激勵視頻那一場，因為不是遊戲行業的，所以大概聽到的點就是激勵視頻可以增加遊戲用戶停留和付費轉換，增加除了內購之外的盈利途徑等，還有就是激勵視頻的設計要素，主要是要給用戶創造驚喜，和遊戲融合為一體，增加激勵的機制。最後還請到了幾位遊戲髮型公司的老總，主要是國內對國外的遊戲髮型出版和引流變現公司，說了一下目前遊戲市場國內的行情不好，而未來對國外市場的競爭會越來越激烈等，要大家內地的遊戲公司做好市場變化的準備。

之後是Firebase的具體使用，我聽了後半場，因為不是android開發，我理解就是提供了一套雲端的nosql存儲，bug監控，埋點服務，用戶大數據分析，幫你對用戶的商業特徵分類，比如有付費傾向的等緯度，然後就是Firebase的一些落地公司的舉例，提升了多少數據指標等。

接下來是web的不斷改進電子商務，和技術相關的點就是2個API：Payment Request API和Credential Management API，幫助用戶在下單之後快速完成登錄和支付，提升轉化率。還說了目前國外的電子商務網站獲客主要靠移動web，但是轉化低於PC的問題，主要也是因為網站的性能和支付的流程導致的轉化率流失，如果使用PWA技術可以提升用戶體驗和轉化，使用圖片預載入技術可以提高網站打開速度，並且提到了Intersection Observer API。

然後是AMP的最佳商業實踐，前半部分對AMP做了簡單的一個介紹，比如已經有多少AMP頁面，億級，這些頁面的中位數首交性能在1s以下，提高轉化率20%+等，還有AMP支持越來越多的AMP組件，在18年2月份還出了AMP Stories，在我看來就是個易企秀…然後就是國外已經在用的公司LOGO大全，讓人值得關注的是未來AMP會增加PWA的支持，只需要一行代碼就可以讓AMP頁面變成PWA應用，很讓人期待。後邊半場就是行業大咖的交流，請了4個公司的代表，CGTN，京東，歐萊雅，米蘭網。分別說了他們公司的AMP落地實踐，主要問題在於2點，大量的JavaScript組件轉換為AMP組件有一定的難度，數據的交互有一定的改造成本，其他的都是優點。和官方說的基本一致，主要是速度性能的提高，SEO的提高，轉化的提高，搜索引擎排名的提高等，這幾家都是和google深入合作的AMP廠商，他們都是面對海外市場的時候使用了AMP技術。（國內你也用不上。。）

然後我聽完這個再去Flutter的剖析，只聽到了最後一場，就是Flutter有點像web渲染，是有重繪和重排概念的，如果你局部刷新一個視圖的元素可以單獨創建一個層來展示這個元素，讓繪製變成局部繪製，增加性能體驗（大概這個意思，前面的都沒聽到，就結束了）

然後後邊那場是講Flutter的底層渲染機制的，有幾張比較直觀的圖發一下：

第一張簡單的介紹了一下什麼是Flutter，這個可以從官網自己獲取信息。圖二說了為什麼Flutter可以媲美原生渲染，為什麼比RN等其他多端統一框架性能好。圖片很直觀了，因為RN類框架會多一層交互再到Skia，而原生和Flutter都是直接操作Skia的。Skia也是google的一個開源圖形引擎，chrome，Android，firefox，sublime等都是基於這個來繪製的，分享者原來也是Skia工作組的成員，然後開始講解了針對Skia層面的繪製優化技巧，主要是減少繪製針和去除無用渲染，盡量少的用saveLayer和clipPath，還有在開發者工具中展示了如何對渲染進行調試的演示，比如使用SKPicture分析繪圖指令，使用trace-skia命令等。

總結如下：

到這裡基本就結束一天的分享了，然後是晚餐的google party和中間茶歇去逛了一下2樓的演示大廳。

比如我們公司就用到了TensorFlow實現了移動端圖像去重：

然後還看到了知乎的娃娃機：

大概一天的行程就是這樣，流水賬記得可能有不對的地方歡迎指出。

9月21的明天參加完再來更新。

------ 9月21日 update ------

9月21號的日程安排比較放鬆，因為沒有開幕和簽到的環節，所以今天9點10分才到會場，先說一下今天的日程安排：

1，打造跨平台web。

2，掌握瀏覽器的Event Loop。

3，深入探討web上的新功能。

4，AMP如何讓網站更快，更簡單？

5，web開發者工具，LightHouse，Puppeteer以及新發展。

6，閑魚基於TensorFlow Lite的端計算應用實踐。（時間問題，就聽了最後一個例子）

7，TensorFlow在網易有道產品中的應用。

今天明顯人比昨天要少，今天的主題也比昨天要硬了一些，下面簡單作為web開發者需要關注的一些技術點。

第一個，打造跨平台的web，還是以pwa開篇，說了除了昨天說的2個新API，支付和登錄之外，還提了一下表單的autocomplete屬性和自動糾正輸入功能，很多移動端網站42%，沒有設置正確的鍵盤類型導致用戶體驗不好，然後依舊是service worker很重要，是最重要的改善用戶體驗和性能的API，舉例了騰訊新聞和rosegal應用了pwa後的數據上升以及性能提升（使用lighthouse做性能評分），然後開始演示星巴克的PWA應用，PWA在android平台上的PWA應用可以快速便捷的完成商品的訂單訂購，用戶登錄支付，使用placeholder content來進行佔位載入，其實就是我們平時說的骨架圖，使用預緩存提高打開速度，星巴克PWA應用在安裝之後和android原生應用的級別一樣高，會有web apk生成，下面是添加到主屏幕的前置條件，以及如何顯示添加到主屏幕對話框。

主要是2個事件的實踐，beroreinstallprompt，appinstalled。

然後預存儲是使用的workbox實現，workbox主要是集合使用了servicework 的 fetch event 和cache的一個google提供的庫，可以從http://workboxjs.org來了解更多，然後付款和訂單信息可以使用indexDB在本地做存儲，同時也可以實現離線應用的特性。星巴克的PWA應用推薦大家去試用一下，整個應用完全是沉浸式的體驗和web體驗完全不同。

然後開始說google本身自己如何使用pwa來改善web體驗的：

除了搜索，還列舉了bullerin使用了媒體捕獲來完成更快速的內容產出，google map的離線使用體驗等。

上面這個slide是展示了google map核心的PWA離線使用場景需求。

同時pwa還給google map提升了靜態資源載入速度，並展示了google map的緩存策略（使用indexdb）以及使用pwa的渲染優化，比如在低端手機上消除陰影和透明度，消除過度拉伸等特性。

然後就開始介紹大家在mobile 和 pc上的用戶操作時長對比數據，發現在PC端使用web的時間佔比更分布更穩定，說明PC端的用戶體驗也十分重要，由此引出PC端的PWA介紹。

同樣PC端的PWA一樣是跨操作系統的，比如mac os和windows系統上PWA應用可以有一樣的跨端體驗。然後介紹了一些pc端的pwa特性配置，比如app window elements，還有mainfest里的scope屬性，app menu，responsive設計（pc上尤其重要，pwa可以跨pc和mobile，responsive的實現也很關鍵）。

最後扔了一個未來要支持的特性：

最後總結了這次分享最重要的3點，beforeinstallprompt handler，desktop的PWA，還有manifest理的scope屬性。

接下來是第二個分享，也很硬，但是對於前端來說並不陌生，就是瀏覽器里的event loop詳解（事件循環），關於event loop我這裡給不是前端的同學科普一下吧，其實不看這次分享主題，event loop用白話說就是在瀏覽器里，js是單線程的（因為瀏覽器特性，如果引入多線程，在js中更新操作UI，會產生非常複雜的多線程同步問題，導致js在瀏覽器被設計成單線程），在同一個時間點裡只允許做一件事（分享者舉例子，一個人不能在說話的同時打噴嚏，如果你停止了打噴嚏那麼你就不能說話了，但是你可以同時舉手和動腳這是2個並行的任務），那麼既然是單線程的就要引入任務隊列，解決同步任務和非同步任務的問題。作者舉了一個非常形象的圖：

這裡的中間的圈裡面的方塊不斷的轉動，代表瀏覽器的事件循環，瀏覽器在不斷的執行任務，比如js的腳本，而當我們用了setTimeout之後，會把setTimeout的回掉函數扔到左邊方塊進行排隊（queue task），當我們的主線程任務都執行完畢之後，我們開啟下面那個閥門，讓方塊走到左邊圈的空缺處，如果setTimeout倒計時結束已經在那裡等待了，js就會拿到這個非同步任務進行執行，執行完畢後繼續回到中間的圈裡進行循環，直到主線程空閑再進行下一次消費。下面這個張圖展示了這個執行機制對渲染的影響：

這張圖增加右邊的半個圈，裡面的幾個塊代表了更新渲染的操作，當我們的主線程任務都執行完畢，如果主任務或者非同步任務里導致ui有更新，那麼我們的事件循環會進入右邊的圈進行任務執行，執行完畢後再回到中心（這個操作並不是每一次事件循環都會進入，瀏覽器會進行積攢調度，再統一刷新）。

下面開始引入了requestAnimationFrame這個API，思考下面的代碼：

我們使用了setTimeout遞歸改變元素的偏移像素，讓方塊動起來，setTimeout的ms設置為0，那麼其實我們這裡就是一直在往非同步隊列里插入排隊的任務，但是，這裡的順序其實就是當前主任務隊列全部搞定，我們執行非同步隊列里的任務，但是並不一定會立刻進入UI更新部分，瀏覽器會對渲染頻率做變化，如果你的非同步任務里的耗時太多或者主任務過多都會影響渲染幀率，動畫就會變得不穩定，如何做這個優化呢，就是使用requestAnimationFrame來解決，它會告訴瀏覽器希望執行動畫並請求瀏覽器在下一次重繪之前調用指定的函數來更新動畫，W3C 所建議的刷新頻率是每秒60次。

還有一段代碼是來解釋requestAnimationFrame調用時機的，我們在click里調用一次transformX1000，然後想再進行一次transformX500，因為上面的event loop機制，瀏覽器會把這些操作進行一次整合，導致動畫直接變成了transformX500，1000那一次移動丟掉了。那麼我們怎麼處理呢。

在x1000之後強行區獲取一下元素的transformX屬性，讓瀏覽器強行執行一次渲染重排，那麼這個任務下面的x500的任務就會被放在下一次的渲染執行了，也可以使用2次requestAnimationFrame解決。

最後到了介紹Microtasks的時候了，簡單來說就是主任務執行完，進入非同步任務隊列之前，會執行Microtasks任務，比如promise的回調就是Microtasks。

比較經典的一道題目是結尾，思考下面2個ppt的代碼執行log順序：

圖1是不用button.click調用的執行結果，圖二是使用button.click的調用結果。主要區別在於調用.click() ，使得事件監聽器的回調函數和當前運行的腳本同步執行而不是非同步執行導致的，因為變成同步執行所以第二張圖裡的執行順序變了。圖一結果因為非同步handle，進入非同步隊列，拿到第一個handle，列印listen1，microtask1，再進入第二個handle，列印listen2，microtask2，而第二張圖因為同步執行handle，2個promise進入一個microtask，列印順序變成listen1，listen2，然後microtask里的microtask1和microtask2。

以上基本就是event loop這一場的內容了，以上加入了我個人的理解，主要是因為主講者語速太快了，翻譯也翻譯的不給力，我自己聽到結合以前自己對event loop的理解說的，如果有不對的還是希望大家見諒，可以自己再去查閱event loop相關的文檔和文章自己學習。

後邊這一場是web新特性，先來一張圖壓壓驚：

很多吧，如何給他們分類呢，作者在介紹完一堆案例後，把這些新的api能力按3個緯度劃分：

操作系統整合，多媒體兼容（音頻視頻），硬體操作能力，那麼下面我們看下都有哪些激動人心的api。

圖太多可能大家沒心情看，我直接用文字列表吧：

操作系統整合類：

1，add to homescreen

2，native picker。

3，native share。

4，share receiver。

5，serviceworker的download manager。

6，navigator.mediaSession

7，picture in picture

高級多媒體：

1，camera stream

2，image capture

3，camera settings

4，screen share

5，barcode detector

6，face detector

7，text detector+speechSynthesis.speak

8，media recorder

硬體：

1，web bluetooth

2，web usb

3，ambient light sensor

4，presetation api

總結一下我的體驗，比較看好的是分享類能力和detector能力，硬體控制可能物聯網同學需要關注，其他的基本都是老API了，結合web RTC可以好好玩玩。

然後繼續下一場是AMP如何讓網站更快，更簡單。

依舊是開場先來了一遍車軲轆話，說了一下什麼是AMP，為什麼要用AMP，網站性能的重要性以及世界級的網路大難題依然存在，比如2G，3G下的用戶在世界範圍內還很多，出海一定要用AMP哦。

然後開始說AMP的組成：

實現原理就是自定義html tag + AMP js + AMP的server cache，以及AMP的設計應用原則：

然後開始介紹了一下AMP里的標籤，如何讓開發更簡單，比如amp-youtube可以直接生成一個youtube視頻播放器，amp-carousel輪播圖，amp-sidebar導航條，amp-img進行懶載入裁切自適應等，amp-bind實現數據綁定和視圖更新：

然後是aliexpress團隊的amp實踐分享：

核心是這一頁，如何實現的pv，uv統計，如何統計用戶行為，鏈接的全局狀態傳遞等，阿里的同學有google加持就是不一樣。還有就是反哺AMP社區，提供了一個電商AMP組件，倒計時……

然後又說了一下AMP和PWA的關係以及如何關聯提升用戶體驗，如果想試試AMP可以訪問下面的鏈接：

反正一場下來就是出海必備AMP的意思，google幫你加持。

終於到了最後一場，lighthouse和Puppeteer的分享：

因為lighthouse大家都太熟悉了，我們團隊對廣告，以及我們的端內頁面性能打分都是用的lighthouse的命令行版實現的，這裡就不多說了，上一下打分的緯度圖，這個我的live里也講爛了：

記住這個，chrome已經內置了lighthouse，直接打分就ok啦，然後lighthouse團隊和github 還有travis繼承了自動化任務可以嘗試下。

後邊就是Puppeteer，由於Puppeteer大家做前端的也很熟悉了，我們的很多爬蟲也是基於這個做的，包括截圖等服務，下面主要來一張原理圖吧：

puppteer就是無頭瀏覽器+CDP調試指令+puppeter封裝的api+你的調用腳本一個金字塔的結構。

然後介紹了一堆用法比如截圖，生成pdf，爬蟲，監控，ssr等，我不知道的只有代碼覆蓋率和上線前的離線資源檢查，我特別放2個圖吧。

基本這個就沒了，然後順帶介紹了2個新工具，nodejs調試工具node debugger還有一個page speed insights：

基本一句話帶過，讓你自己去看文檔的意思，最後附帶資源參考鏈接，這場因為大家都知道就不細說了。

然後web的專場基本就結束了，跑去開始聽tensorflow的2個，第一個是閑魚的tensorflow應用，就聽到了最後再租房照片識別上給房屋打分的一個case，其他的沒聽上。

第二個是網易有道的一個端測AI實踐，主要的圖是這個：

使用了tensorflow lite之後模型減小，計算速度提升，運行存儲空間變小，內存佔用變小，可以在支持NNAPI的android機器上做硬體加速，讓有道團隊的計算模型可以共享統一等，這裡我也不太懂，感覺就是很屌的樣子。。

基本9月21的web專場總結就到這裡，熬夜寫的，東西比較多，希望能夠幫助到看的人，如果有錯誤的地方，歡迎評論提醒我修改，內容不一定涵蓋全，web專場都是老外的分享，我聽力水平有限。。。

感謝。

我的回答總結下來就是下面這句話：

Google高逼格活動場地布置方面表現出了哪些不一般的細節！

當天聽完Google上午的演講，下午我又去了另外一場微信小程序方面的活動。晚上回去整理手機拍攝的照片時，我發現了一個問題，為什麼同一步手機拍出來的照片風格（逼格）差別如此大？

這是谷歌開發者大會拍攝

這是有贊百萬小程序峰會拍攝

我相信你們已經感受到差別了！雖然有贊也是一家令人尊敬的互聯網公司，但這個現場照片與谷歌的反差也忒大了！谷歌的照片清晰細膩，深藍的色調充分彰顯了高科技公司的高逼格。而有贊的照片，排除ppt本身配色和拍照取景的差異，就整體風格來講，偏灰偏暗，完全沒有氣勢。

作為一名理工男，必須要發揮打破砂鍋問到底的精神，谷歌的會場布置到底有什麼牛X地方？仔細研究了一番，我觀察到了幾個細節。

1 燈光

谷歌大會整個會場頂部布滿了藍顏色的燈，豎直往下照，這種燈肉眼看起來亮度一般，但當我現場用手機掃一張帶有二維碼的宣傳頁時，發現攝像頭看到一片藍色，二維碼根本無法識別，可是我肉眼看這張宣傳冊，二維碼很清晰的。

我認為正是因為這藍色的光照射下，手機攝像頭才能拍攝出這種特別的深藍色，烘托出十足科技感的氣氛。

晚上或在暗光下拍過照片的人一定知道，照片會有一種模糊甚至骯髒的感覺，這是因為暗光下攝像頭感光晶元不能獲得足夠的曝光量，所以只能調大ISO值。有贊活動現場的照片就是這種現象的代表。

谷歌會場一方面用肉眼不敏感的強藍光把觀眾席壓住，另一面他們想要突出的大屏幕，屏幕底色亮白，亮度很高，保證攝像頭拍攝時能獲得最佳的曝光效果，你看下面的照片曝光很好，幾乎看不到噪點。

2 舞台

現場的演講台效果如上圖，超大的LED屏幕並不是落地的，而是距離演講台平面2米左右高，這2米高的區域是靜態的印刷品牆面。這樣設置帶來了兩個好處：

好處一

是屏幕位置足夠高，這樣即使觀眾席是水平的，也不會有前排個人高等原因擋住後排的視線。

好處二

大會場大演講台配超級LED屏幕，演講者站在台上顯得太小，不害怕，咱屏幕大，分幾塊出來把演講者放大投到屏幕上，方便和觀眾更好交互。

人在台上的效果，下面的觀眾根本看不清演講者的表情和動作，甚至人在哪兒都看不到。投到大屏幕的效果，怎麼樣？融合的很好吧！你們看到好處了嗎？背景簡潔乾淨！

再放一段現場手機拍攝的視頻，你們感受一下。

你們有沒有發現演講者的中文說得還可以，再告訴你們一個有意思的現象，現場的歪果仁嘉賓演講，差不多有三分之二用得是中文。

如上就是本次大會讓我個人感受深刻的幾個細節，分享給大家，請行內人士指導指正！

又找了兩張別的大會的照片，你們應該知道是誰，放一起對比對比看看（咳咳）。

（完）

相關的議程別的答案中都普及的差不多了，我來說一下我比較關注的幾個點的具體細節吧，總覺得有這方面還是有待提升的

flutter，官方的解釋是說功能和解決的問題是類似於RN的，也就是應用場景和RN差不多，但是機制是類似於unity的，所以在性能方面會比RN出色很多，可以媲美原生，但是我個人的實踐是，flutter的應用相比於iOS來說打出來的包相比於原生的包大很多，內存佔用也很大（我只用過幾個月前的版本，最新版的flutter有待嘗試）

第二點是firebase，這個google的官方說法是可以在移動端後台開發，數據分析，crush收集，資料庫調用，數據存儲的開發工具，但是國內現在只能用數據分析和crush收集的工具（那跟友盟統計沒啥區別了啊……）

amp方面可以提升頁面響應速度，但是據稱開發成本會提升很多，而且跟js方面有不少兼容性問題（不是web開發，具體沒怎麼關注）

ware OS個人感覺沒什麼亮點

ARCore，這個……簡單的看了一點，也不是太清楚，不過ARCore同時兼容安卓和iOS平台還是挺令人驚喜的

（知乎慣例上個圖）

TensorFlow，TensorFlow明天才是重頭戲，一天的專場，明天具體了解一下再過來回答

P.S：TensorFlow今年冬天會有谷歌的冬令營，只面向在校大學生，有興趣的同學可以關注一下

關於TensorFlow的相關信息，TensorFlow新增了兩門語言的支持，swift和js，這對web端和iOS開發是好事，（沒有OC，如果想在OC中調用還是需要用C++，但是TensorFlow lite的訓練模型可以導出為蘋果的ML core的格式）

以及一些新模塊和新介面的更新，有的還不成熟，只是預覽版

機器學習小白，聽了一天的TensorFlow專場聽的雲里霧裡的……（）

有蠻多的，今天正好也在。混合開發flutter，安卓wear os，還有ARCore，還有機器學習tensorflow，還有firebase。現在都逐漸在商業項目落實。這些技術為推進生產效率以及降低開發成本提供一種新的方式。

最重要還是谷歌關於web未來和趨勢，還有lighthouse, poputter等等。靜在明天。

ps: 前端開發者一枚

一直想說為毛在現場千人同畫，我的猜畫小歌總是這樣？？？why？移動聯通都換了

剛參加完大會，做個分享吧（圖片很多，流量黨慎入）

第一天

當天很早就來到現場，因為來得早，所以現場人還不多，暢通無阻的就進去了，並在主會場坐到了第一排，然後就有幾個朋友說在網路直播和大屏幕上看到我了（囧）。

會場外擺著大大的 Google Developer Days 2018 的標識，兩側還有各種樣子的 Android Logo。

Google Developer Days China 2018

Android Logo

進會場很嚴格，最外層有保安檢查受邀郵件，進樓前需要安檢。

辦完嘉賓卡後贈送了一個禮品袋，袋子里有一個魯班鎖和 Google 各種產品的介紹。比較有趣的是猜畫小歌，給了每個人一個專屬的帶有唯一 ID 的二維碼。除此之外還有一個有 Google 各開發者產品貼紙 Logo 的小冊子。

嘉賓卡

魯班鎖

另一個角度，可拆卸的魯班鎖（還沒來得及研究）

會場一樓貼著橫幅，上面有 Google 遊樂園的指引和各分會場的介紹。

在開幕演講之前，有一個千人同玩猜畫小歌的活動，前三名會有 Google 的神秘重量級大禮，這裡有個小彩蛋，就是掘金的創始人陰明在第二輪得到了並列第二的成績。

在每輪結束後，主持人會挑選比較難畫的關鍵詞，我覺得比較難的有挖土機和動物遷徙。

雖然有的關鍵詞很難，但是很多人畫的真的不錯。

活動結束後就是開幕演講了，由 Google 大中華區的各個高管負責，還有一個講中文的美國工程師妹子（金安娜），感覺是和前面一位的中文形成了鮮明對比，所以獲得了經久不衰的熱烈掌聲。

順便吐槽一下，Google 大中華區的高管沒有中國人，聽口音感覺是日本人和台灣人比較多。

首先是石博盟（Google 大中華區總裁）的演講，說了很多 Google 在中國取得的成就。最後還和 VR 合影，向我們傳遞了「中秋快樂」的祝福，中文不太行。

很喜歡金安娜的中文演講（233，說著一口很吃力但是很萌的中文），主要是 Tesorflow 的內容，提到了 Tensorflow 開源社區的進展。

金安娜 —— 擁有可愛中文口音的程序媛

開源社區進展

Firebase 也是一個重點，現場演示了用 Firebase 實現一個銀行轉賬。此外還提到了用 Firebase 提升用戶體驗，穩定性和錯誤率降低了 42%，速度、設計和易用性提高了 73% 。

接下來就是 Flutter 了，因為不做移動開發，所以沒認真聽。不過提到了 Flutter 在 Github 上的排名，在穩步上升。感覺是類似 Vue 或 React 的生產力框架（提到了很多新 Feature，比如 Web 和 Native 更強大的融合交互）。

至於 AR/VR，Google 自然是不會錯過的，請來了全球戰略負責人演講，主要內容是 ARCore。

開幕式的最後一個演講是 Tensorflow，講了人類對技術變革的態度變化。

總結一下，開幕式演講涵蓋了 GDD 兩天的所有內容，主要是人工智慧（主推 Tensorflow）；其次的重點是 Web，Google 探討了很多關於 Web 的內容（花大篇幅介紹了 PWA 、Firebase 和 Web 新特性），這塊也是我比較感興趣的。

除了技術內容外，Google 的營銷主題也是一個亮點。我參加了「機器學習在中國市場掀起的營銷革命」這個主題。Google 的營銷能力在國內一直是被大眾低估的，從這個主題中我又感受到了 Google 作為一家國際頂尖互聯網公司的實力。大眾對 Google 的印象一般都是面向 C 端用戶的公司，但 Google 真正賺錢的項目其實是 ToB 的網路營銷（大會上還發布了 Google 成長指南，就是專門講營銷的），所以說 Google 是一家 ToB 的公司一點都不過分。

他們的網路營銷強大到用機器學習預測用戶什麼時候的轉化率最高，然後在合適時機將合適產品推給合適用戶。Google 不是廣撒網式的投放廣告，不僅分析用戶數據，還會分析廣告數據。而廣告主如果要將廣告的效果提到最佳，必須遵循 Google 的廣告規範。Google 的機器學習會學習這些規範，從而覆蓋更多人群。

這些規範包括：文字、圖片、視頻（不同規格）和 HTML5。

然後講了兩個案例，主要是遊戲。

我就記得列王的紛爭這款遊戲了，據主講人說，該遊戲有 50% 的付費轉化率來自 Google，和機器學習結合起來的 Google 營銷，不僅降低了用戶獲取成本，還提升了用戶付費總額。

這段有幾個 PPT，沒拍。總之就是很強大，可以非常精準的匹配到目標用戶，然後可以實現付費轉化。

Google 為了能做到這些事情，獲取了大量用戶隱私。包括但不限於，瀏覽記錄、應用內購買頻率、玩過的遊戲類型、郵件內容、安裝的遊戲數量、應用內購支出、搜索詞條、位置、時段、設備類型、年齡+性別和 Youtube 的觀看影片。

據主講人所說，以上數據只是冰山一角，Google 還擁有成千上萬的用戶數據，比如你喜歡什麼樣的動漫人物。

當天還有一個營銷的主題，叫「利用機器學習預測用戶終身價值」，預測用戶價值的目的是幫助應用找到最理想的用戶。Google 把用戶分為三種，分別是核心用戶、應用內用戶和感興趣的用戶。用戶價值是指有付費價值和願意加入社區和進行網路分享的人（比如我現在在寫這篇文章，那麼我對這次 GDD 來說就有社交價值）。

Google 能做到這些也是因為 Google 有全球性平台幫助他們收集數據。我相信我看的這兩個主題還只是 Google 營銷的一小部分，畢竟 ToB 的營銷離普通人太遠，一般很難體會到。當然，也讓我更加深刻的了解到了 Google 的業務，這樣一個包含 Web 和移動端的巨大生態，是一個強大有力無法突破的護城河，局外人只能看到滔滔的護城河，對城裡的一切一無所知，但是卻能看到城內的一座座大樓拔地而起。

展區就是 Google 的各大產品線和開發者社區（掘金、知乎等），我還抓到了知乎的劉看山（只用了一個幣，超幸運，這裡要 @劉看山）。