標籤：

GDD 2018@Shanghai 兩日遊記

10-16
GDD 2018@Shanghai 兩日遊記

來自專欄 lavas5 人贊了文章

內容分級

限於無法分身，我只參加了部分的演講。作為一個前端開發者，我把內容分為 3 個等級，分別是：

1. 核心：和 WEB 相關的核心內容，以後的工作會使用到的內容。

2. 擴展：和 WEB 有一些關係，或者至少和前端，大前端有一些關係的內容。就算平時工作不直接用到，也值得了解的內容。

3. 亂入：和 WEB 甚至技術都沒啥關係，純粹當了解一下，不看也無所謂的內容。（我是空檔期閑著沒事或者純粹興趣愛好亂入的）

長求總

因為兩天參加了大概十幾個講座，不管我聽得懂還是聽不懂，我都盡量記錄，因此每個講座的內容都不少。我先在這裡做一個高度的概括，下面的「詳細內容」再逐個記錄每個講座的實際內容。

WEB 相關

  • 對比了 WEB 和 APP，強推 PWA。並且今年加入了桌面 PWA （支持 ChromeOS，之後會陸續支持 Windows, Linux, MacOS）
  • 瀏覽器事件循環 整理後的內容
  • 介紹了眾多瀏覽器的最新 API，例如人臉識別，藍牙，本地分享，多媒體等等
  • 介紹了 Google 推出的 2 個好用的工具：lighthouse（提供網站評分 & 改進意見）和 puppeteer（輕量小型瀏覽器內核）。
  • 介紹了 AMP 的大體結構和效果

Flutter

雖然和 WEB 無關，但安卓和 IOS 這些「端」也被稱為大前端，算是小有關係吧。

  • 介紹了 Flutter：一套代碼，兩處運行。由 Flutter 來屏蔽安卓和 IOS 的區別。
  • Flutter 的特點：美麗，快速(渲染和更新速度)，高效(stateful hotreload)，開放(open source)。
  • 以閑魚作為線上示例進行安利
  • Flutter 的內部繪製流程 (build -> render -> paint)
  • Flutter 的詳細繪製結構：(widget tree -> element tree -> render tree -> layer)
  • 內部使用 dart 作為編程語言。和 RN 最大的區別在於：RN 最終調用本地的介面進行繪製，而 Flutter 是自行繪製每個像素點，因此自由度更高。另外 dart:html 支持 WEB，因此和 React 相比在功能上並沒有缺失。

其他內容

其他內容和 WEB，或者說和技術關係不大，權當了解了解。

  • 機器學習的 7 個步驟
  • Google 統一廣告系統 UAC
  • 電子商務網站的設計和性能要求
  • Android Things：可以裝在設備上，讓它變成一個智能設備，從而實現 IoT。

詳細內容

主演講（擴展）

主要是介紹 GOOGLE 的各個技術和產品，為接下來 2 天這些方向的詳細講座做一個整體的了解。

tenserflow

機器學習和 AI 的開發平台，很多公司有使用，例如美團。 開設了機器學習入門課程，免費視頻。 （演講者是一個金髮外國萌妹子，全程中文。雖然發音有點奇怪，但兒化音非常有特點，例如「畫面上的【藍點兒】就是 tensorflow 的使用區域。可以看到它已經覆蓋了下至【南極圈兒】……）

android

推出新版本 android 9 pie，比較新的功能包括：

  • 自適應電池 使用機器學習，根據用戶使用習慣把 APP 分為四類，如常用的，不常用的，後台運行的等等。給他們分配不同的運行資源，最終使得 CPU 喚醒時間下降30%，增加電池使用時間

  • android jetpack

  • kotlin 一種全新的安卓開發語言，有更好的錯誤處理，增加代碼的穩定性。目前已有40%的開發者在使用 kotlin 開發安卓，還有配套的 extensions (KTX)

  • android bundle 為了解決 APK 越來越大的問題。一般的 APK 會把所有的內容打包，例如支持的各種語言，支持的各類手機底層環境等等。而通過這個技術，可以把 APK 中分解為不同的小單位。在 google play 下載時根據使用者手機的特性，只下載需要的包，大大縮小需要下載的 APK 的體積。

用前端的思路來理解，就是 bable 的 env preset 了。

wearOS

主要聚焦於手錶，內置了非常多的便捷功能，例如運動數據，天氣預報，微信，郵箱，支付寶的支付碼等等。有點類似於 apple watch。也給 APP 的開發人員提供了新的開發設備和入口。

firebase

是一個開發 APP 的應用平台，為了減少開發 APP 之前需要搭建環境的麻煩。它把本地伺服器移動到雲，即開發時直接請求雲端的數據。另外提供了 WEB 界面去修改或者監控雲上的數據。最核心的點在於這個數據的更新非常實時，所以才能成功取代本地伺服器。

也可以使用 API 訪問到雲端的數據，和訪問本地文件的複雜度和時間是類似的（據說）。

WEB 的形式 現在 & 未來 （核心）

算是對接下來 2 天 WEB 相關的課題的一個預告。闡述當前的問題，提出解決方案（主要是 PWA）

WEB 是可以通過鏈接訪問且可以在大多數設備上使用的內容集，網頁的內容可以自行更新，不需要安裝補丁或者更新軟體版本，因此是更優秀的形式。

體驗和用戶方面

對比全球前 1000 的手機 APP 和前 1000 的手機網頁，發現：

  • 每個用戶的月均花費時間：APP 大幅領先網頁
  • 每個月不同的用戶數量（UV）：網頁 1140 萬，APP 400 萬。網頁大幅領先。
  • 78% 的用戶時間放在了前五名的 APP

結論：

1. 沉浸式的 APP 體驗優於傳統網頁，因此更能吸引用戶留存

2. APP 吸引用戶的能力不如普通網頁，因為 APP 有需要安裝的先天問題。

3. 非 TOP APP 能分到的蛋糕其實不大

因此我們如果能把網頁的體驗做到和 APP 類似的話，PWA 應用就應運而生了。 PWA：快速，集成，可靠，有吸引力。

Google 的兩個比較有代表性的例子：

  1. Google Maps Go 谷歌最大的 PWA，已經被預裝在 Android Go 設備上，但本質只是一個常規的網站，非 APP。 google.com/maps/
  2. Offline GMail: 使用 Service Worker 來實現保存和閱讀離線郵件。

總體來看：

1. PWA 應用的各項指標（廣告點擊率，用戶花費時間等）均不輸給 APP

2. PWA 在更新時需要的流量大小也遠遠小於 APP。（因為僅僅需要更新網頁，而 APP 需要打補丁或者重新安裝）

3. 平均一天有 10 個 PWA APP 被安裝（瀏覽 OR 添加到桌面）。

未來的方向上，谷歌正在考慮桌面上的 PWA 應用（即不運行在瀏覽器內，而是直接運行在設備本身，和瀏覽器平級）。三星，微軟的EDGE 分別引入了桌面 PWA APP。CHROME OS 也引入了 PWA APP。打開網頁後會彈出提示是否添加 APP，添加後即可以快捷訪問，和APP基本是一致的。WINDOWS 7,8,10 CHROME 70 以後會包含這些功能。MAC & LINUX 在明年早些時間。

運行速度方面

高端和低端手機在運行相同的JS上時間相差非常非常大。 平均每個頁面運用 360K 的 JS 文件，和8年前相比基本是6倍大小。

解決方案： 1. 推薦兩個工具：puppeteer & lighthouse （具體在後面有轉場演講）

  1. 從 AMP 學到的 web packaging。把網頁內容存到離用戶更近的位置。把網頁內容類似鏡像的概念，從遠處的原伺服器複製到鏡像伺服器，由遊覽器識別出來。（國內可能沒戲？）

  2. web assembly 用來解決 JS 的性能問題，創造一個執行環境，提升處理性能，額外使用 30% - 40% 的CPU能力。例如網頁版的繪圖軟體，CAD。

網頁包含了越來越多的新功能，會解決網頁的性能就是不如 APP 這個問題。

瀏覽器的 event loop （核心）

已經整理到知乎

打造跨平台的 WEB 站點 （核心）

先強推 PWA，再強推桌面 PWA

PWA：能夠在瀏覽器和在桌面同時使用的站點。

一些優秀體驗的移動站的建議

  • 在需要時才請求許可權，而不是在用戶打開應用程序的時候就請求。（這點和之前不一樣了，Chrome 已經支持了）
  • 自動登錄，流暢的使用流程
  • request payment API （W3C標準）能夠集成 GOOGLE PAY。（國內懸）
  • 有 42% 的站點沒有為輸入框 (input) 指定類型 (type)，因此體驗欠佳
  • 谷歌列出了一些最佳實踐，來指導用戶如何去把自己的移動站點做得更好。

Service Worker 已經可以安裝在幾乎全部的瀏覽器上。 騰訊新聞接入了 Service Worker 之後，性能提升，瀏覽次數，轉化率均有提升

演示了 Starbucks PWA，通過 PWA 下達的訂單增長超過 12%，每日和每月的活躍用戶幾乎翻倍。桌面用戶無需使用移動設備即可下單。

53% 的用戶會放棄載入時間超過3秒的網站。

PWA 應用的特點

四個特點：速度快，可安裝，可依賴，體驗好。

  • 速度快

    • 使用 placeholder content 控制項（類似於 skeleton，也可以是低精度的站點陣圖片）
    • 預緩存內容
  • 可安裝

    • 外觀和行為與其他本地 APP 類似。（添加到桌面並從桌面打開，沒有瀏覽器樣式）
    • Web APK：PWA 可以像普通 APP 一樣出現在引用程序中。（例如使用某程序打開的列表，分享的列表等均可以出現。目前安卓已經實現）
    • CHROME 顯示添加到主屏的條件，還包括 「必須包含一個監聽 fetch 事件的 Service Worker」
    • 避免一進入 APP 就彈出添加到首屏的提示。
      • 監聽 beforeinstallprompt 保存 event
      • 之後調用 event.prompt() 彈出添加到主屏的提示
      • 安裝成功後有 appinstalled 事件發射出來
  • 可信賴

    • 使用 workbox (一個快速生成 Service Worker 的工具，也由 Google 開發)
    • 預緩存內容 (precache)
    • 運行時緩存 (runningCache)
    • 使用 indexDB 緩存內容
  • 體驗好

    • 恰當的後退導航按鈕（不要一下子退到最外面，要一步一步）
    • 使用 toast 最小化影響主體內容。

GOOGLE 的 PWA

  • GOOGLE 搜索：

    • 外部的 JS 請求減少 50%
    • 由載入 JS 引起的用戶延遲減少 6%
  • Bulletin

    • 體積比 APP 更小
    • 支持包括照片和視頻在內的多媒體捕獲（拍照，拍視頻）
  • GOOGLE 地圖

    • 從根本上改善低端設備或有限網路環境中的體驗
    • 核心用戶應用場景：
  1. 找到自己的位置
  2. 尋找一個位置
  3. 尋找附近的位置
  4. 尋找路線&導航
  • 頁面載入成功率提升 20%

  • 緩存策略：（多種緩存配合）

    • 瀏覽器緩存 maps tiles
    • indexDB 記錄用戶搜索和 map files 版本等。

桌面 PWA

根據統計：白天10點到7點，desktop 的使用時間超過 phone 或者 tablet。

在桌面應用上，常規的做法是自定義構建一個簡易的瀏覽器內核，並使用它容納網頁。但實際上用戶的 PC 上可能已經有不止一個瀏覽器。因此我們實際上應該聚焦在應用的內容本身，而不需要那個瀏覽器外殼。

因此我們需要跨瀏覽器，跨操作系統的 PWA APP。（WINDOWS 和 MacOS 都可以運行的）

實現方面，同樣使用 manifest.json，重要的是 scope 屬性（和 Service Worker 的 scope 類似）

在桌面應用也需要使用響應式設計，根據寬度和大小的不同，顯示不同的內容。（例如天氣預報，可以分7天，5天，3天，小圖標等等）

更多詳情可以參閱

  • Chromium Blog
  • 網路應用安裝橫幅
  • Progressive Web Apps on the Desktop
  • Scope in Manifest.json

Google AMP （核心）

對 AMP 進行了大概的介紹

原因

需要使用 AMP 的原因主要是因為傳統網頁載入太慢，loading 時間太長。以下是一些統計數據：

  • 53% 的用戶放棄載入用時超過3秒的網頁
  • 3g 下的平均載入頁面用時 19 秒
  • 60% 的全球移動網路用的是 2g

組成部分

AMP 是由幾個部分組成的：

  • html (普通 HTML + AMP 組件)
  • js (內聯的腳本或者綁定屬性)
  • cache (Google AMP cache 自動抓取)

做法

AMP 的做法包括

  • 阻止載入耗時的內容
  • 待載入完後才顯示內容
  • 嚴禁投放令用戶分神的廣告
  • 直到用戶需要才載入相關內容 (lazy loading)

amp-bind

根據用戶的交互，使用數據綁定 (data binding) 和表達式 (expressions) 來動態變化頁面的顯示內容。

通過 3 個步驟實現這個過程：

  • state （設定初始狀態，例子如下）

<amp-state id="team"> <script type="application/json"> {"star": "Yao Ming"} </script></amp-state>

  • bind （在頁面某個位置將顯示和狀態關聯起來，如下）

<p [text]="team.star + is tall!">

  • mutation (通過 AMP.setState 來更新狀態，如下）

<button on="tap:AMP.setState({team: {star: 姚明}})">

AliExpress 遷移到 AMP 的優缺點分析

AliExpress （海外的阿里） 使用了 AMP，因此 Google 以他們為範例，闡述了 AMP 的得失

  • 劣勢
  1. 只能使用 AMP 組件
  2. 不能使用 cookies 和 localStorage
  3. 無法直接支持 touch 事件
  • 優勢
  1. 重點關注在業務邏輯上，花更少的精力在性能方面，開發效率更高
  2. 能夠給開源項目輸出代碼 （例如 <amp-date-countdown> 組件）
  3. 依靠 AMP 獲得了更好的性能
  4. SEO 效果更好

更多信息

最後是 3 個參考網站

  • ampproject.org
  • ampbyexample.com
  • ampstart.com

Google 的兩款工具推薦：lighthouse & puppeteer (核心)

lighthouse & puppeteer，值得使用和學習

lighthouse

網站評分工具，目前是 3.0 版本。它能夠衡量一個移動戰的各類指標，並指出網站提升的方向。它的審查內容包括：

  • PWA 功能
  • 最佳範例
  • 可訪問性
  • SEO
  • 性能

使用方法：(任選其一)

  • Chrome Dev Tools (F12)
  • Chrome Extensions
  • npm (使用 nodejs 線下跑分)
  • web (直接去 lighthouse 官網輸入網址在線測試)
  • github + travis 可以作為 PR 的 task （類似於自動化測試那樣，每次發起 PR 都運行一下，給出分數變化趨勢）。具體使用方法可以參考 lighthouse-ci，可以設置及格線，站點 URL 等等。

衡量頁面的一些指標

  • FP - 第一次頁面顯示
  • FCP - 第一次有內容的頁面顯示
  • FMP - 第一次有意義的頁面顯示
  • TTI - 可以開始用戶交互

這部分還可以參閱一篇微博：以用戶為中心的性能指標

puppeteer

首先講一個概念，叫做 headless chrome。簡單來說就是沒有頭尾的瀏覽器，也就是瀏覽器內核。它的特點是：

  • 內核與最新的 Chrome 保持一致
  • 可以使用最新的功能和介面，例如 streams, cssgrid, service worker 等等
  • 能夠通過代碼操作 Dev Tools 的功能和數據，例如模擬網路延時，模擬設備等等

puppeteer 基於這樣一個內核，給開發者提供一套介面，來做一些事情，簡單結構如下：

利用這個可以做哪些事情呢？下面舉幾個例子：

  • 截屏

puppeteer.launch().then(async browser => { const page = await browser.newPage() await page.goto(https://example.com) await page.screenshot({path: example.png}) await browser.close()})

  • 獲取頁面數據

const metrics = await page.metrics()// metrics.ScriptDuration// metrics.LayoutDuration// metrics.RecalcStyleDuration// metrics.JSHeapUsedSize// metrics.NodeCount

  • 攔截網路請求

await page.setRequestInterception(true)page.on(request, req => { if (req.resourceType === image) { req.abort() } req.continue()})await page.goto(https://www.youtube.com/)

  • 生成 PDF

const page = await browser.newPage()await page.setContent(` <!doctype html> <h1>Some Report in PDF</h1> ...`)await page.setViewPort({ width: 1280, height: 1024, deviceScaleFactor: 2})await page.pdf({ path: report.pdf, margin: {top: 16px, ...}})

  • 驗證每個請求是否可以離線訪問

const resp = request.response().fromServiceWorker()console.log(url, resp ? √ : ×)

更多的例子可以參考 puppeteer-examples 和 pptraas.com

最後，還額外推薦了兩個開發工具： ndb - an improved debugging experience for Node.js, enabled by Chrome DevTools page speed insights

深入探討 WEB 上的新功能 (核心)

海量最新 API 正在襲來！

先介紹了 PWA 和 Service Worker。 OFO 把 PWA 應用於共享單車，在美國上線了。

隨後是一大堆最新的 API。這些 API 有些剛剛加入標準，有些尚未加入標準。但均已經在 Google Chrome 上實現了。

因為 API 和代碼太多，我也沒能全部記住 & 查閱，因此這裡僅列出大致內容和關鍵詞。

操作系統整合

  • 其實就是添加到桌面，manifest.json，但是增加了安裝成功的事件。

window.addEventListener(appinstalled, e => app.logEvent(a2hs, installed))

  • <input type="file" accept="image/*"> 像 APP 那樣選擇圖片。其中 accept = image 是新增的選項

  • navigator.share 分享功能

let result = await navigator.share({ title: Paul Rocks, text: He really does!, url: https://paul.kinlan.me/})

  • Share Receiver。 能夠像本地 APP 一樣，在其他網頁分享時，顯示在分享程序的列表中。通過在 manifest.json 中增加 share_target 對象來實現這個功能。

// manifest.json"share_target": { "action": "compose/tweet", "params": { title, text, url }}

  • download manager 後台下載，斷點續傳，完成後的通知等等。

  • navigator.mediaSession 控制媒體（視頻，音頻等）能夠控制播放的標題，圖片，進度，控制前進後退等等。

  • document.pictureInPictureElement 允許瀏覽器退到後台時，畫面依然在設備的桌面上（類似懸浮窗口）。

高級多媒體

統計數據：有 70% 的網路流量來自視頻

  • navigator.mediaDevices.enumerateDevices：獲取系統上可用的多媒體輸入和輸出設備的信息，如麥克風，攝像頭等

  • new ImageCapture：截圖

  • navigator.mediaDevices.getUserMedia：向用戶請求許可權獲取音頻或者視頻流等。

let stream = await navigator.mediaDevices.getUserMedia({video: true})let video = document.querySelector(video);video.srcObject = stream;video.onloadedmetadata = function(e) { video.play();};

  • canvas.captureStream(25)：實時捕獲 canvas 畫布上的內容，輸出為流，參數為幀率。

識別相關

  • 識別二維碼

let detector = new BarcodeDetector()let codes = await detctor.detect(image)

  • new FaceDetector() 識別人臉

  • new TextDetector() 識別文字

硬體

  • Web BlueTooth

const device = await navigator.bluetooth.requestDevice(...)

  • Web USB

let device = await navigator.usb.requestDevice(...)

  • Ambient Light Sensor (環境光感測器)

let als = new AmbientLightSensor({frequency: 10})

  • Presentation API

const pr = new PresentationRequest(https://airhorner.com/)

developers.google.cn/we 有列出更多的信息

WEB 電子商務 （擴展）

列出一些優秀的電子商務網站，分析他們的共性和優化點

在全球在線購物中有 66% 的用戶通過 WEB 購物 （34% 通過 APP）。但是轉化率上 WEB 要比 APP 低得多。

現存 WEB 的劣勢：手動，繁瑣，速度慢，多次點擊

完善電子商務網站的幾種方式

性能目標

性能目標必須要和商業價值掛鉤，否則毫無意義。

性能目標可以包括： 網頁載入時間 首次有效呈現時間 可交互時間 可連續交互時間 * 頁面重量

有幾個簡單的原則：

1. 不要為了性能優化而刪減核心功能（正常的公司我覺得不太可能會這樣）

2. 要首先顯示重要的內容。例如側邊欄看可以放後面，確保主體內容先渲染。

產品展示

熱烈推薦 Google AMP

DHgate 一個來自中國的B2B電商網站，採用了 AMP。

圖片

圖片需要優化 1. 格式：png -> jpg。 2. 根據屏幕尺寸選擇正確的圖片尺寸 3. 盡量避免用戶等待圖片載入的時間（例如提前載入） 4. 使用低像素圖片佔位（和skeleton類似）

lighthouse 可以測試和提供優化建議

查找產品 - 瀏覽和搜索

多使用 prefetch 進行預載入

網站內部的搜索需要處理：

  • 拼寫錯誤
  • 同義詞
  • 自動填充
  • 縮寫
  • 分面搜索。

購物車和結算

這是電子商務中最重要的環節。56%的美國消費者因為結算問題放棄在移動端的購物。可能因為速度慢，或者要填太多的信息等等。

chrome 自動填充功能可以幫助用戶登錄。每年幫助80億用戶登錄。

跨平台：例如手機上瀏覽商品，到PC上進行付款。 順暢的跨平台付款 payment request API 順暢的跨平台身份驗證 credential management API （這兩個都是瀏覽器包含的 API 功能）

可以利用 PWA 增加更好的體驗。

好的例子 ecer.com, m.jd.id ( JD 的印度尼西亞版本)

Flutter (擴展)

開發一套代碼，同時在安卓和 IOS 上運行，構建 APP 的簡便方式。

APP 的現狀

新的 APP 要儘快上市的重要性不言而喻，即便是已有的 APP 的更新速度其實也至關重要。數據顯示，僅有 3% 的移動 APP 新用戶在 30 天后仍然保持活躍狀態。因此，如何提升用戶粘性，如何通過持續的更新來吸引 & 留存用戶，是移動 APP 成功與否的關鍵。

移動 APP 目前面臨的最主要挑戰是：

  • 業務挑戰方面

    • 上市期 （越短越好）
    • 碎片化
    • 靈活性
    • 招聘
    • 互動
    • 測試新想法/原型開發
    • 高昂的開發費用
  • 技術原因方面

    • 同時面向 IOS 和安卓平台構建和發布應用
    • 招聘人員拆分代碼庫
    • 設計/開發協調方面的挑戰
    • 同步版本
    • 更新和刷新應用
    • 快速發布和迭代

說到底，核心就是一句話：APP 需要開發 IOS 和安卓兩個版本，因此需要兩個代碼庫，需要兩套開發人員，需要兩批設計（適應不同的屏幕尺寸 OR 屏幕特點，例如 IOS 的劉海）。而這兩套又不能完全隔離，因為它們是同一個產品，因此還需要在保持特性的前提下擁有相當的一致性，例如體驗，樣式等等。

現有的技術也有致力於解決這方面問題的，比較著名(且早期的)的是 Phonegap, Adobe Air, Appcelerator 等 (React Native 後面再說)，但都存在一個共同的缺點：比較簡陋，無論從樣式上，體驗上還是從功能上，全方位的不如原生開發。因此為了造就理想中的城堡，獲得最優的效果，公司和開發者依然不惜耗費巨大的成本走迷宮。

Flutter 的特點

主要有 4 個特點：美麗，快速，高效，開放。

  • 美麗

    可以畫頁面上的每個像素（這也是和 RN 最大的區別），以精美界面獲獎。可以理解為高性能的渲染引擎。

  • 快速

    能夠保證 60fps 的幀率，可以調用 GPU 加速。因為高層代碼被編譯為機器代碼，因此在低端手機上也能取得相當好的效果。

  • 高效

    高效指的更多的是開發體驗。其中最具特色的是 stateful hotreload （修改代碼熱載入時組件狀態能夠保持住，而不是從初始狀態重新開始）。

  • 開放

    Flutter 是開源 & 免費的，可以在 Github 上看到代碼並參與。另外還有中文官網和中國鏡像，訪問容易。

渲染機制方面，它總共有 3 個階段：

build -> render -> paint

而實際渲染，它通過構造以下幾個內容來進行：

widget tree -> element tree -> render tree -> layer

使用 Flutter 的四種方法

  1. 從無到有構建全新 APP 在 Flutter 中實現新偶像，並同時落實到 IOS 和安卓 APP 中。

  2. 針對新的 APP 構想進行原型設計 使用 Flutter 在前所未有的短時間內測試 APP 構思或者想法

  3. 針對另一個平台構建 APP 如果已經有了 IOS 和安卓 APP 的其中之一，使用 Flutter 針對另外一個平台構建 APP。驗證無誤後再擴展併合並代碼庫。

  4. 將 Flutter 用於 APP 的某一部分 （線上演示的閑魚就是這種） 在生產環境中使用 Flutter 測試現有 APP 中的一個或者幾個頁面

APP 營銷最佳實踐 (亂入)

主要聚焦在如何利用 google 的各條產品線和合作品牌來提升自身 APP 的廣告效果。但我覺得多數是針對出海的 APP，因為搜索，youtube，google play 等國內使用並不十分廣泛。

Google Play 是用戶獲取遊戲/應用的最主要渠道。廣告吸引的安裝次數超過60億次。

本次介紹主題：UAC 通用應用廣告系列

解決的問題

  • 如果投放搜索廣告，要設置關鍵詞，並且為每個關鍵詞設置點擊成本。
  • 如果投放到 YOUTUBE，要投放到特定的頻道。
  • 等等。

UAC 可以免去這些設置工作，在搜索，play store, emails. web, youtube等，使用機器學習來投放廣告。 例如如果用戶看完遊戲視頻後下載遊戲的數量非常多，那 UAC 就會增加這條路徑的權重。

這裡又學到了兩個概念： CPI 單次安裝成本 安裝，推廣。主要目標是下載/激活。 CPA 單次事件成本 留存，活躍，營收。主要目標是用戶質量。

優秀的視頻廣告特點

  1. 15-30S
  2. 加入音樂和字幕
  3. 儘早的抓住眼球，顯示出品牌。最好在1/4時長之前更容易獲得更高的轉化率
  4. 結尾處（最後一幀）加入號召文字或者按鈕圖案。（馬上下載，馬上遊玩等等）

H5 廣告：

  1. 有清晰的號召按鈕
  2. 增加激勵性，如折扣優惠等。

谷歌擁有豐富多樣的用戶行為數據

  • 瀏覽記錄
  • 應用內的購買頻率
  • 玩過的遊戲類型
  • 搜索詞條
  • 位置 （考慮時差）
  • 時段 （例如工作日推遊戲就不是很有效）
  • 設備類型 （例如有沒有買最新的 iphone）
  • 從 youtube 看過什麼視頻（有73%的玩家喜歡看別人打遊戲，48%的玩家喜歡看別人打遊戲超過自己打遊戲，61%玩家會在購買遊戲之前看 youtube 視頻）

根據這些行為數據，能夠猜測用戶畫像，從而有針對性地去對這類用戶製作視頻，精準投放。舉了網易的荒野行動進軍日本的例子，有針對性的轉化率為4倍。


推薦閱讀：

TAG:Google開發者大會 | Web開發 | 前端開發 |