Google I/O 2017 Android 相關 Session 摘要 – 下集

部門內總是習慣大家分著看東西，再互相分享，這是我們團隊內保持快速移動的有效方法之一，今年我們也針對 Google I/O 2017 上百部影片中的 Android 相關議題做了分享，算一算這是我們第四年分享懶人包了呢 :P

此篇為下集，若需參考其他 Session 請至 Google I/O 2017 – 上集

What’s New in Google Play at I/O 2017

目前 active 的 Android 裝置有 20 億，付費方式非常多樣，甚至剛開始的 Instant Apps 也能促進使用者的消費，對開發人員來說整個環境變得非常好。從前只有開發人員會使用 Developer Console，後續越來越多的功能上線後，現在 PM、marketing、QA 也都可以使用 Beta testing、pre-launch 報告、消費報表等各種資訊來加強 app 設計，讓使用人數成長。

影片中提到 50% 的一星用戶評價都是在抱怨穩定性，所以想要評價變好的話，第一件事就是讓你的 App 更穩定些。再來你需要注意設計、可用性、速度。Android Vitals 可以讓你在 Play Console 觀察穩定性、電池消耗、畫面 rendering 表現等資訊。

Pre-launch 報告可以在你發布版本之前，在各種 device 上先行測試，並提早發現問題。機器人會自動測試你上傳的 apk 並在五分鐘測試內，自動偵測並報發現的問題。 現在你甚至可以提供測試帳密給測試機器人，用來登入並更完整的測試你的 App。

Google Play Signing 是一個新的 Service 用保管你的 signing key，如此一來你就不必擔心 key 的安全問題。 除了幫你 sign key 之外，這個新的 service 也能最佳化你的 apk 大小，針對不同的 screen size、architecture 將不必要的 library、resource 移除，可以大幅降低儲存用量。從 Device catalog 中，你可以找到各種 device 資訊，輕易地列出使用某個 chip 的機型。

你現在也能針對某機型、使用的 SoC 來排除某些裝置安裝你的 app。新的 Subscription 報告可以告訴你，用戶訂閱、退訂狀況，哪些管道取的的用戶帶來最高的價值。

最常見的退訂原因是付款失敗，新的 Account Hold Service 讓你在用戶付款失敗時收到通知，並且你可以轉告 User 這個資訊。實驗發現這樣做用戶用戶留存率可以提高 25%。

Android Instant Apps Best Practices Fireside Chat

去年 Google IO 發表了 Instant App，現在可以讓所有使用者使用了，這一年中有一些公司參與了 Instant App 的實作開發，這邊邀請五位工程師來分享使用 Instant APP 的心得，分別是：CastBox、Twitter Periscope、vimeo、deliveroo、zillow

• CastBox 為一款電台一音樂，當使用者聽到一段有趣的劇，會想要分享連結，分享給親友，但如果親友沒有裝 CastBox，一般的情況就需下載 CastBox，再進行收聽，但使用 Instant APP，就可以在不下載 APP 的情況下直接使用。 一開始因有完整的行動版網站版，所以 instant app 就直接使用 webview 來開發，後來發現 webview 執行較慢，而且滑動行為不流暢，就改用原生的方式實作，做起來比想像中的簡單，因 APP 已經模組化了，APP 使用 Dagger2 做 Dependency injection，Exoplayer 處理播放，還有 In-app billing，instant APP 都有支援。
• Periscope 花了大概一個多月的時間，從九月開始，拿到很初期的版本，開發除錯，十月底就有一個完整的版本，十一月在 google play time 上 demo 了，因 APP 已經模組化了，開發時就可以專注在 instant APP 上，加上和 google 開發上合作愉快，互相學習，google 提供測試方面的支援。instant APP 因執行在 sandbox 上，一樣的 API 執行在一般的 APP 和在 instant APP 執行會有些許的差別。
• Vimeo 的工程師介紹了怎麼做 refactoring，減少 APK 的大小，因 instant APP 一個功能最大只能有 4MB，
  使用 Android Studio lint tool 來移除用不到的資源檔，用 Gradle dependency tree，確認 import 了什麼資源，是否都需要使用到，並舉例了在一般的 APP 是使用 Fresco 來顯示圖片，因有較好的處理效能，但本身元件的檔案大小較大 (2MB)，不適合使用在 instant APP 上，instant APP 就改使用 Picasso，檔案較小只有幾百 K。
• Deliveroo 工程師介紹介紹了開發 instant APP 對一般的 APP 帶來的影響，因 instant APP 只會讓使用者使用到某部分特定的功能，所以功能需要模組化，所以改變整個專案的結構，讓功能可以分別一般的 APP 和 instant APP 使用，但又不想分別寫兩隻程式來分別維護 instant APP 和一般的 APP。

10 Google Play Console Secrets to Optimize Android Apps for Stellar User Retention

一個高品質的 App 是獲得使用者持續支持的主因，在這邊介紹幾個實用的秘訣及新釋出的功能。

1. 預先發佈測試：藉由 Firebase Test Lab 找出 App 可能會在實體裝置上遇到的問題。
2. 畫面操作測試：一樣可以藉由 Firebase Robot 使用 App，並且佐以截圖，讓你得知實際執行情形。
3. 特定機種測試：我們可以設定要特別在哪些機型執行，另外還能選擇機型的硬體設定，例如至少要 1G RAM 這類要求。
4. 即時監控面板：在這能得到各種實用資訊，包括 crashes, ratings, 安裝情況等各種即時情形，幫助你做對應處理。
5. 完整評論檢視：透過評論可以得到關於 App 優缺的回饋以及改善的方向，現在可以有更完整的評論歷程瀏覽，讓開發者與使用者間的互動更順利。
6. Android Vitals: Play Console 的新區塊，可以提供一些告知建議，讓你的團隊依據這些訊息決定先改善效能或是開發新功能，另外在 App 品質低下時也會有標示提醒你注意。
7. 穩定性監控：透過 Vitals 現在可以檢視 App 的 crash 頻率以及 ANR 頻率，目前只有 Play Console 提供 ANR 頻率這項特別數據，可以幫助開發者關注問題。
8. 繪製速度監控：同時這裡提供了過慢畫面更新率，讓使用者有掉幀感；另外還有長時間(>700ms)繪製一張影格的比率，並且也提供了可能的 root cause 以供參考。
9. 電池使用監控：Vitals 提供了兩個數據，一小時內取得至少一次以上的 wake lock 的比率，以及每小時超過 10 次 wakeup 的比率。
10. Google Play 獎勵機制：優質 App 有可能會獲得推薦搜尋、列入精選特輯、更有機會得到年度 Google Play 獎項。

Speeding Up Your Android Gradle Builds

過去的一年 Google 致力於改善 APK build 的時間問題，除了最新的 gradle plugin 3.0，也統整出一些訣竅可以節省開發時花費在 gradle build 的時間：

1. 使用最新的 grade
2. 避免使用 legacy multidex (Multidex + minSdkVersion < 21)：但在 Android Studio 2.3+ 已經會自動規避該問題
3. 不使用 multi-APK：在 release 版本做就好，debug 版本不需要
4. 使用最少的 resources
   　productFlavors {
   　　　development {
   　　　　　resConfigs (“en”, “xxhdpi”)
   　　　}
   　}
5. 避免使用 png crunching：release 版本需要但 debug 版本不需要
   　android {
   　　　if(project.hasProperty(‘devBuild’)) {
   　　　　　aaptOptions.cruncherEnabled = false
   　　　}
   　}
   ＊或是把所有的 png 用 WebP 轉換為 webp 格式
6. 使用 Instant Run：Instant Run 現在已經跟一開始完全不一樣了，請使用看看
7. 不要在每次 debug build 時變動參數
   ＊bad Example：
   　def buildDateTime = new Date().format(‘yyMMddHHmm’).toInteger();
   　android {
   　　　defaultConfig {
   　　　　　versionCode buildDateTime
   　　　}
   　}
   ＊常見的工具 Crashlytics 也會自動 update build id，記得在 debug 版本關掉它
8. 不使用 dynamic versions
9. 注意 memory 設定
   ＊在 plugin 2.1 後，build grade 中的 javaMaxHeapSize 設定可以拿掉
10. 使用 Gradle Cache 機制

另外在 Gradle plugin 3.0 中，為了避免 multi module 多餘的 recompile，dependency config 對 sub module 從原本的 compile 改為 implementation 或 api 。遇到異常緩慢的 build 時，應該要花時間確認一下是否 3rd-party plugin、build.gradle customization、code 的組織架構或是 memory setting 有誤。
如果開發者有自己寫 plugin，盡量避免用到 doLast() 這個危險的 method (最好也檢查一下第三方 plugin)，用 custom task 去取代他。
另外 Grade 也有提供一些 tools 去觀察 build 的時間都花在哪裡：

• —dry-run
• —info
• —profile
• Gradle profiler

Google Play Awards

Google Play Awards 是 Google I/O 在 2016 開始設立的一個特殊獎項，而今年 KKBOX 入圍了「Best TV Experience」這個項目，也因此受邀在頒獎前先到會場與其他的入圍者及 Googler 互相認識，交流。在輪到我們所入圍的項目時，我們都非常期待得獎後可以上台領獎，但可惜的這個獎項由 Red Bull TV 拿下，雖然很可惜但我們會再接再勵。

Android for Entry-Level Devices

Android Go 目標是印度下一個十億新興市場，要進入到這新興市場就需要先調整 Android 目前遭遇到的三個情況：

1. Device affordability：設備必需先優化 OS 讓系統支援最低的螢幕、內存甚至最低支援 512 RAM，而且不只優化 OS ，更要優化應用程式，讓大家的應用程式可以支援下一個數十億用戶，之後會教導如何編寫支援 Android Go 的應用程式。
2. Data affordability：在印度數據資料對他們而言就像新的貨幣，甚至可以拿來當禮物包，因此 Android Go 必需透明的公開數據資料及讓使用者可以控制自己的數據。
3. Linguistic flexibility：更多的使用者會希望系統裡能有兩種語言，他們希望自己的 OS 是英文，而在特別的應用程式裡出現的是另一個語系的語言(例如西班牙文)，因此正在將此功能套用到新的應用程式去提供給下一個十億用戶。

接下來讓我們深入了解正在做的優化有什麼：我們改善了 kernel 再到第三方應用的一切，首先從 Kernel 開始，這裡整合調整了 Android 的生命週期及 Linux 操作系統，這看起來是容易的事但其實有很多細節要調整，像調整緩存大小的交換、調整各種參數。

要實現內存優先的回收要做的就是內存的重制、主動在後台做回收。也調整了 System UI，調查了解使用者通常只會在最常使用的四個應用程式切換，因此重新設計了 UI ，以實現更快的切換。同時也正在努力的取得更小的空間、較少的內存、並且減少使用網路資源，所以設計了一些全新的 Google 應用程式，例如 YouTube Go，這些大小都盡量小於 10 MB。

再來來談論如何控制使用者的數據，先前提到數據的透明公開，將會提供一個 API 給第三方應用程式，用此 API 可以提供每個數據訊息給用戶。在 Youtube Go 我們做了預覽功能，如此可以花最稀少的數據觀看，而你不能要求這數十億的用戶能有穩定的連線或是平均的頻寬，因此也做了額外的控制讓他們選擇要觀看影片的畫質，另外有些用使可能在辦公室有免費的 WiFi ，因此也讓他們可以下載這些影片供他們乘坐巴士時觀看。

另外也介紹了 Linguistic flexibility 方面 Google 鍵盤提供了自動翻譯的功能，讓語言更靈活的應用在不同的應用程式裡。

What’s New in Notifications, Launcher Icons, and Shortcuts

許多 OEM 製造商會自行更改首頁的 App 圖示為圓形或矩形，不僅改變了品牌標誌有時也會切割到畫面。為此 Google 推出了自適應圖標，將 App 圖示分為前景的主要 icon 與背景顏色，製造商便可在允許的範圍內任意裁切背景的形狀。

去年 Google 推出了可在 App 圖示長按時添加的快捷功能，點擊後可透過 deeplink 執行對應動作。這次新增了創建快捷的方式，也可將快捷鍵建立為 widget，詳細內容可參閱這兩隻 API 說明 ShortcutManager.requestPinShortcut()、requestPinAppWidget()。

在 Notifications 方面新增了通知順序的概念，將訊息依重要性區分為三種層級

• 進行中的主要任務： 高優先級的日常任務，如音樂的通知、導航顯示，並可對這些重要通知設置特別的背景顏色。
• 人對人的訊息: 研究顯示人們最關心此類的溝通訊息，因此特別將訊息類提高優先權顯示。
• 順帶一提的訊息：用戶不需即時確認，此類訊息也不會顯示在鎖定螢幕上。

另外也推出了新的頻道功能讓開發商自定義推播訊息的分類，用戶可以細項控制不想要收到哪些分類的頻道通知。

Boost User Retention with Behavioral Insights

Jeni 透過 Behavioral Economics、Gamification、Product Psychology 觀點歸納出三個有助於提昇使用者回訪率的原則：Simplify、Trigger、Motivate。

在介紹原則前必須先定義的關鍵問題是：你所預期的使用者行為是什麼？
如在 app 內購買產品、獲得更多使用者、增加使用者回訪率…等等。大多企業在談到回訪率時，最重視的都是使用者的動機，但她認為在確認行為後的第一步應為：簡單化，指將使用者在達到預期行為的過程中，所遇到的任何障礙最小化。可透過一些定量或定性的方法確認出行為，像是 Funnel Analysis、User Research 等，再藉由 Default 設定好最簡單或最通用的行為提供給使用者，以降低或排除預期的使用者行為障礙，推薦參考 Just Eat app。

第二個原則：如何加速潛在使用者成為真實的使用者？ 最有說服力的作法就是 Make it scarce，如在常見的 push notification、電子郵件、廣告等文字說明上，運用『稀有』的概念像是限量或限時的標題，去吸引潛在使用者觸發預期行為，推薦參考語言學習 Busuu app。關於 Push Notification 的技巧與相關工具可參考影片 Tools and Tips to Boost User Engagement and Retention。

最後一個原則為如何透過獎勵連結使用者行為與效益，首先談到動機可分為二種類型：內在動機與外在動機。

Jeni 使用 RAMP framework 來解釋 Gamification 的內在動機。
Relatedness：建立社交連結、歸屬感的關係，如線上遊戲可與真實和虛擬的朋友一起完成任務；Autonomy：使用者可以自由選擇與決定，如探索虛擬世界、自定義大頭貼圖像；Mastery：使用者持續改善以提高能力，如玩家為了提升等級或擁有特殊技能，會花大量的時間練習遊戲技能；Purpose：使用者的預期利益。推薦參考 Catch It English app，其 7 天的使用者回訪率高達 45%。

外在動機則可參考遊戲顧問 Gabe Zichermann 所提出的獎勵制度的順序與成本結構圖。最有效但成本最高的方法就是物質，如貨幣、贈品等方式，其可以快速驅使短期的行為改變，但實際上卻忽略了內在動機；真正有意義的策略應納入 RAMP 模式，因為物質獎勵也是最容易取代的，因此考量長期效益之下，成本最低但最能維持忠誠度的是 status，如 VIP 制度，可擁有特殊待遇等。

最後由 Fabulous CEO, Sami 分享與 Jeni 三原則呼應的三個主題與 Fabulous app 的應用討論。

Best Practices to Improve Sign-In, Payments, and Forms in Your Apps

Android Autofill 可讓使用者自動完成輸入密碼、地址、信用卡號…等等已存在 Google account 中資訊的功能。
要使用 Autofill 功能，需要在 layout XML 中加上 android:autofillHints tag 通知 Autofill service 該欄位要 autofill 的資訊為何，在 View.java 中有訂定幾種常用的 autofill constant；android:importantForAutofill tag 可用來通知 Autofill service 是否要 trigger autofill workflow，有些不需要 autofill 的欄位可以將這個 tag 設為 no。
Account Transfer API 可以用來轉移 App 的用戶憑證，主要的流程是由舊手機使用 Account Transfer API send data，透過 Google Play Service，將 App 的用戶憑證傳至新手機，而 App 是由 broadcast 接收由 Google Play Service 來的資訊。
Android Auto Backup API 只要在 manifest 加上 android:allowBackup tag 即可啟用，預設會將 App 的 Shared preferences, Files, Database 都做備份，且每天同步一次，但容量上限是每個 App 25 MB。
Key/Value Backup API 需要實作自己的 backup agent，但可以自訂需要上傳的資料，容量上限是每個 App 5 MB。

Performance and Memory Improvements in Android Run Time (ART)

這篇分成幾個部分來講 Google 如何在 ART 中，讓你的 App 在讀取時速度更快，並用更少的記憶體用量。

首先先從減少使用的記憶體開始說明，當 ART 載入 dex 到裝置上時，同時會包含了許多不必要的資訊，在 Android N 時他們引進了 profile base compilation，利用 JIT profile 的資訊，得知哪些部份對你的裝置來說是重要的。到了 Android O 上，他們利用這個資訊，把相關的部分重新排列放在一起，因此達到讓記憶體用量減少，也同時可以達到減少載入的時間。

接著是 Garbage Collector 的部分，在 Android L 開始能在背景跑 compacting garbage collector。但因為他為非並行，因此在 GC 的整個期間會造成 GC pause，大概會持續數百毫秒，這很有可能會讓前景程式造成 jank。因此在 Android O，ART 會並行壓縮前景與背景使用到的 heaps。這可以解決那些生命週期很長的應用程式，像是 Android system 或是 Google Play Service，他們隨著時間所造成的記憶體碎片化的問題。根據他們的統計，與 Android N 相比，heap 大約平均可減少 32% 的記憶體用量。新的 GC 也讓 GC pause time 大幅平均減少了 85% 左右的時間，在最糟的情況下也能減少約 76% 左右的時間。每個物件被配置記憶體的時間也與 KitKat 相比快了 18 倍。

下一位講者利用 Sheets 來做案例分析，看看 Sheets 的效能在 Android N 與 Android O release 是如何逐月上升的。第一就是剛剛提到的新的 GC，他大約增加了 40% 的效能。再來是利用 inliner，他增加了 20% 的效能。其實在 Android N 已經有 inliner，他是在背景做編譯，且只編譯需要的部分。Android O 則利用這個為基礎，做了更進一步的優化。例如，現在可以跨 dex files 做 inline，可以針對會拋出 exception 的 method 做 inline，而且有更多的 method 可以做 inline。Code sinking 則讓 Sheets 的效能再增加了 15%，他的做法是將指令搬到他實際上會被執行的區塊。例如在有判斷式的情形下，會用到 auto-boxing 的物件，以前的作法是在判斷前就先將物件建立起來，利用 Code sinking，他會把 auto-boxing 這件事情搬到 if 區塊內來做。Class Hierachy Analysis 則幫助找尋那些實際上可以被設為 final 但卻不是標為 final 的 class 或 method，藉此可以做更進一步的 inline，而且也可以在需要的時候取消優化。

最後一位講者講的是在迴圈方面的優化，中心思想是利用 induction variables ，找出規律改變的部分來簡化迴圈。利用 induction variables 也可幫你做消除邊界檢查。最後是利用 SIMD 做迴圈的向量化，例如在切換圖片的時候可以用 crossfade 的方式讓圖片切換看起來更順暢。在 Android O 以前，原本一次只能處理一個 byte 的資料，到了 Android O 之後，透過 SIMD 他可以一次處理多個資料，執行起來更快速。而且這個部分是 JIT 自動幫你做掉的，因此你不需要去寫 NDK，就能達成這個效果。

Best Practices for Android Audio

這場分成四個部分進行，第一部分的講者講述的是由三個面向：Launch Smart、Think Global，以及 Make Money 是如何讓一些領先的音樂應用開發者在 Android 上獲得成功。

第二位講者提供兩個最佳的做法，讓你可以在你的 app 提供驚人的音訊體驗。它們分別是：

1. 取得低延遲 (latency) 的路徑：你可以藉由查詢硬體資訊來看裝置的 latency，例如若查到的 flag 是 audio.pro。那麼這個裝置的 latency 就比 20 毫秒還低。講者分別講了錄音及播放方面可以如何取得低延遲的路徑，錄音方面，可以利用 VOICE_RECOGNITION 這個 preset 來得到低延遲的路徑。播放方面，如果硬體符合一些條件，就能取得低延遲的路徑。預設的路徑是需要經過 resampler、effects、mixer，最後才會餵給 DAC 去播放，但這些東西都會增加 latency，我們可以用另一種方式得到低延遲的路徑。第一個是利用 AudioManagerAPI 先取得音檔的 sample rate 來建立這條快速的通道，須注意不要加上任何 effect。接著資料要送給 DAC 前，一樣可以透過 AudioManagerAPI 來取得最適當的 chunk size 大小。當第一個資料送給 DAC 後，DAC 會有一個具有高優先權的 callback 去跟 App 要下一筆音訊資料進來。
2. Meet your audio deadlines：若去細看 callback 中的做法，每個 callback 都有個 deadline，你需要花多少時間在這個 callback 是根據你的裝置的計算能力及音訊資料的複雜度而來。如果沒能在 deadline 的時間內送資料給 DAC，他就發不出任何聲音。而有什麼會讓你無法在這個 deadline 中處理你的資料呢？首先是 blocking，要避免 blocking，就不能在 callback 中做以下幾件事情：logging、分配記憶體、等待其他的 thread、做檔案讀寫以及呼叫 sleep。接著，必須將 audio thread 利用 thread affinity 的方式綁定在一個 core 上，否則當切換 core 的時候，就會有 penalty time，會產生 audio glitch (音訊突波)。最後是使用固定的時間來處理你的 callback。

第三位講者講的是 Android O 新的 audio API：AAudio。AAudio 是一個 C API，但為什麼要有這個新的 API 呢？第一是他很容易使用，再來就是希望不要動到現有的架構，避免對現有的 App 造成影響，另外也可以藉由這個 API 來提升音訊方面的性能。實作上，AAudio 使用了 builder pattern 來建立 audio stream，可以使用預設值或指定格式給 builder，建完以後可以呼叫 builder 的 open stream。如果建立時未指定格式，這時你必須去查詢你拿到的 sample rate 及格式。另外，也必須取得 frames per burst，這個與前面講到的 chunk size 有關。burst 是餵給 DAC 去播放的單位，而 buffer 則是包含了許多的 burst array。接著，你可以用非同步的方式控制你的 stream，包含 start、pause、flush 及 stop，他也有提供 function 讓你用同步的方式取得 AAudio 的 state machine。如果你的 App 不需要做到低延遲，你可以直接用 blocking write 來輸出聲音。如果你需要低延遲，你就必須寫自己的 callback，這個 callback 會給你 audio stream、user data、audio data 及有多少個 frame，當你收到這些資料後，就可以去 render 這個資料。藉由 AAudio 你也可以將多個 stream 結合在一起，做法是用一個 master stream，然後在 callback 裡面處理其他的 input。最後，你可以藉由動態調整 latency 的方式，來避免 audio glitch。最後，只有在 Android O 以後的版本才有 AAudio API 可以使用，但 Google 也另外寫了一個 C++ wrapper，讓你可以用寫 AAudio 的方式向下相容。但背後其實是他們用 Dynamic Link 的方式，在 Android O 以前的版本會自動幫你切換到 OpenSL ES 去處理。

講題的最後請到了 ROLI 這家公司的 CEO 來介紹他們所做的產品：Seaboard 及 BLOCKS，搭配著他們自家寫的軟體 NOISE，讓你可以建立個人的 DJ studio。他們也請到了在 Keynote 開場前表演的 DJ 來為大家做了點表演，有興趣的可以再看看本篇影片。

Make More Money with Subscriptions on Google Play

講者在這場演講中主要述說三件事情，介紹 android & play 的市場，如何透過工具幫開發商帶來訂閱成長，以及如何透過 Google Play Billing 所提供的報表來做商業決策。

Google Play 訂閱人數(subscription)近年來有顯著的成長，2016 年到 2017 年間， Google Play 的 訂閱人數成長了一倍，在三年間，訂閱人數更成長了十倍， 研究指出，62% 的訂閱者每天只少會使用他們訂閱的服務一次，簡單來說互動率能有效轉換成金錢。在訂閱方面，使用者付款的意願在每個月 5$ ~ 20$。訂閱的好處在於可以讓開發者有固定的利潤，還能讓用戶的黏著度提升。Android 每個月有二十億活躍的裝置，只要透過簡單的整合，就有機會販售你 app 的服務到這些裝置上，不需要再處理惱人的地方稅率換算，退款 … 等在地化商務問題，整合 Google Play Billing 都能輕鬆幫開發者解決這些問題。

當我們提到如何讓訂閱成長，就必須提到兩個因素，獲得率和回訪率，Google Play Billing 提供三個重要的工具幫助你去開發新的使用者：

1. Payment Reach：Google Play Billing 在 130 個以上的國家中開放，但隨著國家的文化或社會經濟形態的不同，會採用不同的方式付費，比如說北美大多使用信用卡付費，在德國或其他歐洲國家則是仰賴 Paypal，中南美洲則是偏好使用 Gift cards，亞太和中東地區則是使用電信商結算的方式付費。透過 Google Play Billing 就能整合這些不同的付費方式，不需要再另外處理這些繁瑣的付費機制。
2. Introductory features：提供免費使用將能帶來訂閱的使用者，報告中指出，約 78% 的訂閱者都是從免費使用的服務來的。此外，打折服務也能吸引用戶來使用訂閱服務。比如說 Anghami 原本訂閱是一個月 5$，他們透過打折優惠，降價成三個月每月 3$ 來吸引用戶使用，在用戶註冊數帶來了 400% 的成長，有趣的是在三個月後，用戶並沒有因此減少，而是繼續用原價續訂該服務
3. Seamless user payment experience：以往的付費機制需要經過很多步驟的驗證才能付費，透過 Google Play Billing 工具只需要兩步就解決。

接著從回訪率來看，去年開放了 Grace Period，可以透過該工具了解用戶在 3 或 7 天付費發生問題的狀況，改善了因為不確定原因導致無法付費的狀況。但講者提到使用者非常的懶，可能不會注意到甚至忽略 Grace Period 發出的警告訊息，因此，Google 推出了 Account Hold 這個新工具來幫助開發者，讓使用者發生付費失效的狀況下，不能存取內容，使用者必須修正他們有問題的付費管道，才能繼續使用該服務。講者提供了一個範例，keepsafe 透過整合 Account Hold，增加了 25% 的續訂率。

Google 提供了更多 dashboard 資訊幫助開發商能夠去觀察訂閱相關資訊來做商業決策。新增了 Subscriptions Dashboard，讓開發商能夠看到訂閱帶來的獲利或取消訂閱的變化，此外還提供一個 cohortized reports 讓開發商了解訂閱用戶的增長率，回訪率以及取消率。

Introduction to Kotlin

Kotlin 精簡了許多在 Java 中的必要的程式碼。開發者不再需要維護 toString, equal, hashCode 這類透過 IDE 自動產生的程式碼，這類的程式碼轉移至 Kotlin 自動維護。宣告變數時不再不需要宣告型別，以 val 代表。另外值得一提的是 Java 一直為人詬病的 Null Pointer Exception，在 Kotlin 也得以緩解，未知的參數值比起 Null Kotlin 更加偏向回傳預設值。

函式宣告也比以往更為彈性，傳入參數可以設定預設值，這節省了處理各種 overloaded function 的時間，函式若只是簡單的運算或邏輯，可以使用 build-in function，例如 filter、sortBy、map，甚至也可以用更精簡的方式表示。另外 Kotlin 也支援 extended function，透過 extended 可以賦予 data class 自定義的 function，讓程式碼更易讀。
fun Int.percentOf(money: Money) = money.amount.multiply(BigDecimal(this)).divide(BigDecimal(100))
fun Int.bd: BidDecimal get() = BigDecimal(this)

為了讓程式碼更為易讀，解構 data class 也是允許的，使用 (member property 1, member property 2, …) 代表解構後的 data class，若當前不需要某個 member property，可以使用 _ 忽略。
val (id, username, _) = users.filter { it.email.endWith(".com")}.sortBy { it.id }.first()

以上都是簡單的介紹 Kotlin，其他 Smart casting, Lazy evaluation 等有趣的特性，更多的教學與文件可以參考 http://kotlinlang.org/ 或 http://kotl.in/android 。

Kotlin 是一個基於 JVM 語言，甚至可以編譯 JavaScript，支援 JVM, Android Dalvik, JavaScript VM，然而 VM 部分平台仍有一些限制，因此近幾年一直致力於開發 Kotlin/Native，目前處於 Preview 階段，開發團隊也重新審思當 Kotlin 可以支援多平台時，Kotlin 的未來是什麼？Multiplatform 會是其中一個重點，不同的平台將可以共享 Common Model 甚至是 Business model，第二個重點 Coroutines 則是讓非同步的程式碼可以用更易讀的方式呈現，並打破以往非同步程式的限制。

Growing Globally with Phone Number Identity

Sign in 對於 App 成長是個非常重要的部分，但有超過 90% 的人曾經在 login 中遇過問題，而 92% 的使用者於 login 中遇到挑戰後會選擇離開。識別用戶 (Identity) 對於 App 的成長是這麼重要的，但為何許多 login 流程會這麼繁瑣難用？講者認為，有兩個因素造成 login 這麼擾人：

1. 一開始註冊就需要使用者輸入一大堆資訊，不一定每個人都有 email 以及 密碼複雜度… 等問題。
2. 第一個畫面就是 login screen 將使用者擋在外面，使用者將對你的內容一無所知。

Google 提供了 Phone Selector + SMS Retriever、 Firebase Phone Auth，幫助各位解決 login 所遇到的種種麻煩問題。

1. Phone Selector + SMS Retriever：有許多需要識別的 App 採用 電話驗證的方式去註冊帳號。不過手動輸入電話號碼是令人痛苦、厭煩的，並且等待 SMS 回復以及輸入驗證碼更是讓人受不了的地方。為了避免手動輸入電話號碼、SMS 驗證碼，自動取得這兩項資訊分別要求兩種不同的系統權限，會使得你的 app 看起來很危險。為了解決這個問題，Google 提供了 API 可以自動讀取電話號碼、自動驗證 SMS驗證碼，並且不需要 Runtime Permission。
2. Firebase Phone Auth：當你支援 Firebase Phone Auth 並使用 API 傳送 SMS 驗證過你的手機後，Play Service 會儲存過你驗證過的資訊，當下次驗證時則完全不需要傳送 SMS 驗證碼，即可直接通過驗證。 並且撰寫起來非常簡單，使用 Android Studio Firebase Plugin 連接後，在複製一小段程式碼就可以完成整個登入功能了！

透過以上兩個機制，電話驗證登入將是一件非常簡單、方便的一件事。

Understanding Color

What is color for human being?
最簡單的定義就是「 以色相 ( hue )、明度 ( brightness )、飽和度 ( colorfulness ) 來描述的視覺感知 」，但色彩只是腦中的一種感知，並不是真實的東西。

光是一種電磁波，眼睛則是一種感知器官，而下圖為電磁波輻射帶，其中人眼能看到的就只有 380nm~ 700nm 的可見光波。人眼是一種由數百萬個錐狀細胞組成的感知器官 ( receptor )，而大多數的人擁有三種錐狀細胞 ( cone )，分別可以感應不同波長，而不同的波長會有不同的輸出功率，以燈泡為例可以看出在紅、橘色的區段功率比較高，當燈泡的燈照進人眼的時候，將燈泡的功率和人眼對於波長的感受性乘起來後得到的結果如下，接著大腦會將此結果轉譯為橘色。而每個物體都有屬於自己的光譜功率分佈 ( Spectral Power Distribution, SPD )，代表著該物體能夠反射的波長，稱為反射比（ Reflectance ），而物體的色彩就由燈泡的功率、物體的反射率及人眼對於波長的感受性相乘。基於以上研究，國際照明委員會（ Commission internationale de l’éclairage, CIE ）在 1931 年發表了 Chromaticity Diagram，代表著人眼可見的色彩範圍，如下圖；外側曲線邊界是光譜光軌跡（ Spectral locus ）代表著波長 380nm~ 700nm 的純色，曲線內的則是不同的波長的混合物，至於馬蹄形以外的則是肉眼看不到的虛色。

What is color for developer?
正式的定義是帶著 color model 和 color space 的一組數值，color model 定義了用哪些數值來代表顏色，舉例來說 RGB 用紅藍綠三個數值來代表色彩，而 CMYK 用青、洋紅、黃、黑四個數值來代表；color space 則定義了一個範圍，能明確的指出 color model 的數值是哪一個顏色。常見的 color space 有 sRGB、AdobeRGB、ProPhotoRGB，同樣的 color module 在不同的 color space 顯示的顏色會不同，而構成 color space 主要有三個元件 3 primaries、white point、transfer function。

• 3 primaries 指的就是不同 RGB 三角形的三個頂點
• white point 就是不同 RGB 三角形中間的點，不同的 color space 會有不同的位子。
• transfer function 主要再處理相機或螢幕的非線性(nonlinear)反應以及人眼的感光曲線為對數曲線的問題，例如 gamma correction

Android O Color Management
相同的圖片會因為不同的裝置上使用的 color space, white point 不同而看起來不一樣，因此 Android O 中把色彩與 color space 關連起來並測量裝置的 primaries 和 white point，再該色彩的 color space 轉換成裝置上的 color space 達到在不同裝置可以看到相同的色彩。
在進行開發前設計師與開發者必須明確的知道所用的 color space，大多好的設計工具都會包含相關資訊，若是真的不知道某個圖片或工具的 color space，那就假設他是 sRGB，這是機率最高且最安全的假設，以下列出一些相關工具：

1. Affinity photo
2. Mac OS Sierra color picker
3. Digital color meter
4. Android: Developer option -> Picture color mode

在 Android O 中新增了幾個新的 API 如下：

1. non-static method 的 Color class 且支援 color space 的設定及轉換。
2. @ColorLong 包含了各 16bit 的 RGB ( 用的是新的 android.util.Half ), 10bit Alpha, 6bit color space。
3. ColorSpace 提供常見的 color space (也能客製)、取得 primaries, white point, transfer function，除此之外還能用 Connector 做 color space 之間的轉換共確保使用相同的 white point，以及用 adapt 改變 white poiont。
4. Bitmap 提供取得 color space 的方法，也能設定 inJustDecodeBounds 在 decode 前取得 color space，以及設定 inPreferredColorSpace 指定 color space；但 16-bit bitmap 的 color space 目前只能是 linear extended sRGB，且無法轉換為其他的 color space。

Android O 在 render 時，系統將會自動的轉換為 extened sRGB，這是一個比可見光譜還大的的 color space，它的值從負數一直到 7.5，有趣的是所有介於 0~1 的剛好符合 sRGB，這個好處是 sRGB contendt 不用做轉換就可以直接 render，只有非 sRGB 的圖需要做轉換 ，但這個過程很耗效能，所以要盡可能的避免使用非 sRGB 的圖片。也因為這個 extened sRGB 及 16-bit bitmap 所以未來也有可能支援 render HDR。

由於現在越來越多的裝置支援 Wide Gamut ( 可見光譜中能畫出的最大三角型 )，若是一樣使用 sRGB 那更廣的色域將無法顯示出來，因此 Android O 也增加了 Wide Gamut 的支援，只要簡單的再 acitivity 設定 android:colorMode=“wideColorGamut” 就可以了，若是在不支援的裝置上使用，將會使用原先的 ARGB_8888，雖然顏色可能會不對，但這只是因為裝置不支援。若是裝置支援將會使用 RGBA_F16 但這也意味著記憶體的用量將會變成兩倍，因此再使用前需考慮清楚是否需要顯示更廣的色域。為此也新增了res/*-widecg 供開發者放置支援 Wide Gamut 的資源；若要查詢裝置是否支援也可以使用 Configuration 的 isScreenWideColorGamut 以及 Display 的 isWideColorGamut。

最後希望大家盡力就好，不同的裝置會有不同 color space，而就算是相同的裝置也會因為製造的過程不同造成 color space 些微的不同，只要確保開發者與設計師使用一樣的顯示器、確保使用 sRGB 輸出、確保圖中帶有 color space 的資訊就 OK 了！

Android Apps for Chromebooks and Large Screen Devices

身為一個 Android 開發者，我們常常需要思考，要如何把既有的 App 延伸變成可以在大螢幕、桌面平台也能操作順暢的 App。有些操作甚至只適合在大螢幕上使用。大部分現有的 Android app 可以直接在 Chrome OS 上面執行，但是當他們看到在 Chrome OS 上的樣子時，都會覺得應該要再最佳化一下。主要的差別有：較大的螢幕，預設橫向，Window，輸入系統。

第一個 建議是，將最小 API 設為 24，因為 24 之前有些螢幕大小的限制。
第二，應該要同時支援直向、橫向螢幕，但是如果你的 App 真的只能支援一個方向，也請 在Manifest 裡面註記 。
第三，利用現有的多重 layout resource 來支援多種螢幕大小。第四，支援鍵盤、滑鼠操作。有些操作在手機上並不太適用，類似自訂游標、滑鼠 hover 或是拖曳之類的動作，但是這些操作在電腦上卻是基本的功能。

另外，在 Desktop 系統上 Activity 會繼承 Root Activity 的屬性，Root activity 若是橫向、Resizable 的話，那其他Activity也會是橫向 Resizable。在 Manifest 中也多了一些屬性可以用來告訴 Window Manager 你希望的 window 大小、方向。在 N 之後也支援在 intent 中帶邊界參數，直接設定開出的 activity 位置。利用設計 tablet layout 常用的 fragment，你同樣可以簡單地為 Desktop 環境增加螢幕上顯示的內容。

因為視窗列在 root view hierarchy，你不應該隨意增加內容到 root view hierarchy，否則可能意外把它弄亂。另外也不該假設window 的左上角一定是 0,0，因為在視窗系統上，最上面一定是視窗列。因為視窗是可以變動的，不要在儲存跟視窗大小有關的任何參數了。

針對 resizing，你必須要複寫 onSaveInstanceState/onRestoreInstanceState。若你不希望支援 resize，必須在 Manifest 註記。

在開發人員選項中也多了一些 debugging 選項。在 layout 中使用 nextFocusXxx 讓你可以指定鍵盤與 UI focus 的關聯。
在結尾也列出你要如何測試對 windowed platform 的支援性。

Notifications UX: What’s New for Android O

介紹 Android O 關於通知列的新功能和設計，通知列對使用者來說在日常使用是很重要的，使用者擔心錯過任何訊息，但大部分的通知是不重要的，只有少部分的通知是必須的，很頻繁的通知，使用者必需要一直檢查，因不想錯過任何重要的通知，所以通知列必須要做個革新：使用者想要一些重要的通知，可以讓使用者設定特定的對象為 VIP (例：家人和工作)，還有重要事項 (例：鬧鐘和提醒事項)，如果通知列不在視線範圍之內，使用者很容易就忘了。綜合以上因素，提出了 Channel 的概念，使用者想要某個 APP 的一些通知而不是全部，可以對 APP 的通知做分類，，分成群組的念。關閉特定的 Channel 通知，長按想要關閉的通知，就可以關閉。系統也可以針對 APP 做個別通知的設定。

還有提出了 Behavior model，因大部分的使用者可能不會自己去調整，必須要更容易使用，在 Android N 通知的等級分為：min, low, default, high, max，由 APP 選來選擇通知的等級，在Android O 通知的等級改為：min, low, default, high，由 APP 來選擇 Channel 的等級，同一個 Channel 內的通知有相同的行為模式。APP 內如果有提供通知列設定，可以連結到系統的設定，系統設定也可以連結到 APP 的設定中，維持通知列設定的一致性。

接著提出了 Visual Hierarchy，通知列下拉時，會對通知列的重要性做排序並且外觀有新的設計，重要性由高到低分為 Major Ongoing, People to people, General, By the way。

• Major Ongoing：有來電通知、鬧鐘通知、導航、音樂播放器，其中在 Android O 對音樂播放器有新的設計，可以用專輯的主題色的來渲染整個通知列的顏色
• People to people：傳送來的訊息，在 Android N 如果訊息的字數太多，通知列會出現摺疊的功能，在 Android O 不會有摺疊的功能，會顯示出所有的文字訊息
• General：在 Android O 並沒有特別的改動。
• By the way：顯示低重要性的訊息，例：天氣通知，獲取特定的點數，在 Android O 對外觀有調整，只有顯示單行的文字。

同時，通知列的通知滑動有新的動畫效果，個別通知會隨著滑動消失和出現，在通知列也提供了 Snooze 的功能，左滑 notification 後，可以選擇一段時候再顯示此通知。

Developing High Performance Games for Android

現今在手機上多半都能執行高畫質的遊戲，但就算有最新的硬體配備，效能仍然是我們需要注意的項目。在 CPU 跟 GPU 之間的合作有時並不一定順利，CPU 普遍會碰到的瓶頸諸如太多的繪製指令、單一執行緒乘載過多工作，利用 Vulkan API 可以改善這些情況；而 GPU 造成低效能的原因在於有可能需要太多時間去繪製一些項目，使 CPU 空等。另外有些狀況也是需要我們注意的，例如過長的載入時間、電池消耗過快。善用分析工具去避免問題的發生，像是 Systrace, Simpleperf, 第三方支援如 Snapdragon Profiler, RenderDoc 等等。

眾所皆知 Samsung 在硬體上表現突出，但目前也跟 Google 合作在軟體方面使遊戲效能可以有更多的進步，而最大的功臣就是 Vulkan API，它不僅跨平台、輕量、且包含多種優化工具。雖然 OpenGL ES 目前仍相當泛用，但我們相信 Vulkan 會是一個更跳躍的變革，諸如指令的緩衝、記憶體的管理等等，未來也陸續將被遊戲引擎以及硬體支援，而不專美於旗艦機種。

Android Performance: UI

在目前的手機上正常流暢的畫面表現約是 60FPS，平均起來就是每 16.67 ms 會做一次View Sync，所謂的 jank 就是當 UI thread 耗時過久造成 View Sync 沒有如預期的運作，當遇到這種狀況時，De-janking 的準備步驟有：

1. 使用 release build：確保不是因為 debug build 造成的狀況
2. 圖像化 app 當時的狀況使其能被觀察：可以使用 Profile GPU Rendering
3. 使用 Systrace：$ SDK/playform-tools/systrace/systrace.py -a

以 RecyclerAdapter 為範例，會發現 RV create view 的時間較長，不過這個問題已經在 support lib v25 以 prefetch view 的方式解決，在 v26 更加改善，但這些改善是基於 Render Thread，有些舊型未內建 Render Thread 的機器就沒辦法支援。

Google 一直在改善 Jank 相關的底層原因

• GC
  ● Gc fo alloc 已經在 L 以 ART 解決
  ● Runtime 仍在改善中
• OS Thread scheduling
  ● 在 N/O 已做大幅改善, 但 Kernel 部分仍在努力
• Rendering
  ● View Alpha
  ● M 已做了Auto-HW 增大, 在 N 再改善
• View Recycling
  ● 在 v25 做了 Prefetch, 之後會更加改善

為了維護 App 的效能，開發者可以：

• 收集用戶的回報
• 加上一些追蹤的 log
• 新增 Jank Test：對較大的 App 和 team 很有用，可以加在 thread 較多的 UI。
  ● app 端：FrameMetricsAggregator
  ● host 端：adb shell dump sys gfxinfo
• 使用 Tools
  ● ProfileGPU Rendering
  ● Android Studio Profilers
  ● CPU Monitor
  ● GPU Monitor

觀察 Frame Metrics 的方式

• Per-frame data：Window.OnFrameMetricsAvailableListener
• Aggregated：FrameMetricsAggregator(SupportLib v26)

順帶一提，Skia Renderer 是 Android O 的新 Render，可以在 O preview 的開發者選單開來體驗

Tools and Tips to Boost User Engagement and Retention

提升用戶參與度不是一項工具、不是一個單一的提示、甚至不是一個單一的練習，他是一個很多東西的組合並且需要不斷優化。所以提供了幾個項目只要做到這些清單功能，就可以很容易的提升用戶參與度。

• Engagement objective：你必需要知道是什麼讓你的應用程式特別突出或是能提供什麼特殊的服務，在這些基礎上如何讓你的應用程式與用戶互動。看一些例子：大家都知道 Airbnb ，他的主張就是讓用戶以獨特的方式體驗外國當地的住處，而每天都對訂單功能做測試。
• Feature testing：在舖設明確的功能目標可以優化應用，通常會有很多想法，但要如何確定那一個可以推動用戶參與度，我們必需要做多種實驗，且大量的測試。
• Smart feature releases：確保發佈新功能時是穩定的，且確保用戶可以注意到新功能，
• Great onboarding：很好的使用引導，新手上路時應該是快速且無縫沒有負擔的，理想的情況下會是在做引導時讓人感覺不出來正在做使用引導。
• Successful content launches：不斷的更新內容、銷售方案及各種活動事項這三種組合已經被證明是非常成功的行為。
• Effective notificationso：有效的通知有幾個要點
  1. relevant 在發送訊息時要考慮到跟用戶的相關性。
  2. actionable 通知有時可以用於通知、更新內容讓用戶有具體的操作動作。
  3. personalized 有效的溝通是需要細分用戶群，建立群組並找到分類方式，然後發送特定群組需要的消息給他們。
  4. timeliness 在正確的時間發送正確的信息，並在合適的時間可以讓用戶參與訊息內容，可以考慮到時區或星期幾發送，也可以加入一項選擇讓用戶稍後讀取的功能。

Android Animations Spring to Life

Doris 首先談到過去新增一個動畫時，需要設定 start value、end value、duration、interpolator，此時要達到根據手勢移動的動畫是相當困難的；新的動畫 API 加入了物理學的概念，可以輕易的處理速度不一致的動畫，如 swipe 或 fling 手勢。

以物理學為基礎來建立動畫，在動畫過程中會持續校正並減少視覺上的震動或中斷，當作用力達到平衡時，動畫就會停止，使得效果更加流暢、自然。在一個動畫的時間內，若要動態變更動畫則需中斷當前動畫，再重啟新動畫，而在新版動畫 API 則有更好的優化。

• ObjectAnimator 在 target value 改變時會停止動畫，並利用最後一個 end value 再開始新動畫，如左上圖可以看到中斷的曲線。
• Physics-based APIs 則是透過 force 去改變速度，如右上圖可以看到曲線是比較連續的，動畫所呈現的效果比較平順、自然。
• FlingAnimation 使用摩擦力的原理，根據使用者的手勢位移而有一個連續的移動效果
• SpringAnimation 使用彈力的原理，其動畫速率會受到 damping ratio 和 stiffness 的影響而產生彈簧效果，damping ratio 是受到彈力後的振盪遞減速率，而 stiffness 則是彈力的強度。
• SpringAnimation 可以結合原生動畫，如 rotation、translation、alpha、scale 等，亦可結合 FlingAnimation；另一個高階的用法則是讓多個 subView 跟隨著 leadView 移動，形成一個依賴的動畫效果：Chained Springs。

新版動畫 API 是從 API 16 開始支援。最後由 Chet 介紹 AnimationSet API 可支援 seeking 與 playing，seeking 可使動畫停在特定的 position，而有支援 reverse 的播放時，playing 則可還原動畫至初始狀態，不需要定義二個獨立的 animation set。

Life is Great and Everything Will Be Ok, Kotlin is Here

這篇主要在介紹開發者如何上手以 Kotlin 來寫 Android code。

以 TextView 為例子，在 Java 中的 getter, setter method 到 Kotlin 則變為
property(Java: textView.getAlpah() -> Kotlin: textView.alpha)

並且可以直接對這個 property 做 read & write。

以 ViewGroup 為例子，若要取得 ViewGroup 的 childView，Java 使用
viewGroup.getChildAt(index)

而 Kotlin 可使用
viewGroup[index]；

要 remove view 時，Java 使用
viewGroup.removeView(child)

而 Kotlin 使用
viewGroup -= child；

能做到這些是因為 Kotlin 有 Operator overloading，可以設定某些運算符號對數據進行操作，如
operator fun ViewGroup.minusAssign(child: View) = removeView(child)

這樣寫是代表讓 viewGroup – view 的結果等同於 viewGroup.removeView(child)。

在寫測試方面，使用 Kotlin 可讓程式更易讀，這裡給的例子是有一個 PaymentRobot class，其中有 amount(value: Long), recipient(value: String), send() 三個 method，則寫測試時可這樣用：

@Test fun sendMoney() {
　PaymentRobot().apply {
　　amount(4_00)
　　recipient("foo@example.com")
　　send()
　}
}

接著講者說明若要將 Kotlin 用在產品上，有三個步驟，第一是自己，自己要多和人討論，多講也可以增加自己的信心；第二是要讓主管認同，不要跟主管說我們要如何做，而是可以讓主管知道使用 Kotlin 之後可以達到的目標 (例如讓 App 更穩定、crash 減少)；最後是團隊，一個 App 是團隊一起寫的，需要整個團隊成員都同意並學會使用 Kotlin，否則就無法將 Kotlin code push 成為產品，因為若團隊中有人不會使用 Kotlin，當有 new feature 或是 bug，就無法交給不會 Kotlin 的成員做，同時也增加了 code 的不穩定性。

How to Enable Contextual App Experiences

在去年 Google 提出了 Awareness API (情境感知)：https://developers.google.com/awareness/
可以藉由 Awareness API 蒐集使用者當下的各種資訊的綜合結果，提供更符合使用者預期得到或需要的資訊與服務

而在前幾年 Google 則提出了 Nearby API：https://developers.google.com/nearby/
Nearby API 提供設備之間可連線與傳輸資料的功能，在離線的狀況下依然可以經由設備的 GPS，Bluetooth 與網路基地台定位。同時 Nearby 也支援 Apple 裝置

Context 團隊認為，使用者應該被告知目前有某項可能需要的服務功能可以使用，而不是事先需要知道應該安裝什麼 app，這樣才是最佳的使用者體驗。
所以同樣地在去年 Google IO 提出了 Nearby Message 的技術：https://developers.google.com/nearby/messages/overview

Nearby Message 可以提供很棒的使用經驗，你可以在當下取得眼前具體事物或場景的詳細資訊，或是應用在有趣的情境提供感興趣的廣告資訊。為此，如何過濾使用者感興趣的資訊而不被過度打擾提供了幾種方法，包括時間，app 安裝與否和與標的物的距離三種條件
在訊息的傳遞部分，應該使用最大不超過 40 個粗體的簡潔文字內容，與點擊訊息後會觸發的事件說明。若需要附加網址訊息，最直接簡單的做法可以給允一個 URL ，或是申請一組對應的廣播 ID 去對應到開啟 app 的 intent

第二位講者針對 Awareness 進行說明，Contextual 支援七種原生種類，根據這些資訊可以訂製出使用者感興趣的資訊內容

1. Location: 位置經緯度
2. Place: 地點 (ex. “星巴克”)
3. Beacons: 有哪些 Beacons 或裝置在附近
4. Time: 當地時間
5. Activity: 奔跑，游泳，騎車，駕駛中等活動狀態
6. Headphones: 耳機是否連接
7. Weather: 現在的溫度與天候狀況

Awareness API 有兩個分類，一個是直接要求使用者當前情境狀態，如目前位置與其天氣狀況的 Snapshot API，與針對使用者所處情境改變成為特定預設狀態時進行反應的 Fence API，Fence API 新功能支援對特定情境的時間作為條件限定，Snapshot API 同樣易於使用。

第三位講者針對 Nearby 進行說明，Nearby 連線將鄰近的裝置建立起宣傳與探索的機制，使用可完全離線點對點大頻寬低延遲的資料傳輸，原理是整合使用藍芽，LTE 與 WIFI 技術彌補各自連線的優缺點。

Android Wear UI Development Best Practice

講題分兩部分進行，第一部份是講 support library for Android Wear 有哪些改變。

第一個部分是他們做了一個 wearable support library，並且會變成 Android Support Libaray 底下的一個 wear module。

首先先介紹裡面的 Widget package，他主要是想提供 round-friendly UI 以及 space-efficient interaction pattern。例如 Android 的 list，以往是垂直捲動，但到了 wear 上是呈曲線狀的捲動，因此能看到更多的資訊。目前開發時程分成三個階段，第一步是把現有為了 wear 而做的元件搬到新的 wear module。

有些部分不只在 wear 上面適用，在手持裝置上一樣適合用的東西，就會把他合併到其他的 module 裡面，而不是放在 wear 中。而有些對於用戶來說不是很成功的設計模式的部分，則是會被 deprecated。這裡特別提幾個會搬移的元件，第一個是 WearableRecyclerView，它可以幫助你做前面所提到的 curved list。接著是 BoxInsetLayout，他可以讓你所有的 UI fit 到螢幕中央的方形區塊，因此你可以支援圓形或方形的螢幕。

最後是 SwipeDismissFrameLayout，他是用來取代手持裝置上的 back button，在 wear 上他們希望你要做 back 的話，就來利用這個元件，而不是做個 back button。幾個會被併到其他 moudle 去的，像是 CircledImageView、DelayedConfirmationView 及 ActionButton。Deprecated 的部分，例如他們把 two-dimensional spatial model 拿掉，轉換成 linear layout。

第二部分則是講 Complication 提供了哪些元件讓開發者使用。第一個 TextRenderer，可以讓你在 Canvas 上畫字串，它提供了像是 short text、long text 與 range-value 讓你依據需求而使用，並且會自動根據範圍大小來調整文字的大小，因此你不用自己去量測螢幕範圍而做調整。第二個，ComplicationDrawable，可以幫你處理所有有關 Complication style 或 layout 相關的事情。第三個則是提供 Setting 的範例，讓你可以設計你的 Complication Setting。最後提供了 Test suite provider，讓你測試你的 UI 看起來是否一切如你所想像。你只需要點擊你的 Complication，他就會循環切換不同的組合來協助你測試。

Android TV: How to Engage More Users and Earn More Revenue

講者在此次演講中，希望開發者能夠透過 Android & Play 增加用戶在電視使用 app 的使用率，打造一個在電視上可以有良好使用者體驗的 app，以及增加 app 與使用者互動性以及收益

今年是 Android TV 成長飛快的一年，Android TV 活躍的用戶相較於一年前已經成長一倍，這些顯著的成長歸功於 OEM 廠商在 TV , Set-top box， Network provider 這三方面的努力，以及 Google Play 的豐富性，目前在 Play 有三千個以上的 Android TV apps，結合 OEM 以及開發者的努力，引領 Android TV 帶往高峰的一年。

Google 在三年前推出了 Android TV 系統後，持續的研究使用者在客廳使用 TV 的使用經驗，例如使用者希望能夠輕鬆的在任何裝置登入帳戶，期望在電視上能夠有高畫質 4K 的內容。2016 年有一份報告顯示，使用者在 TV 上的平均互動時間與行動裝置相比，多了三倍。換句話說，TV 能夠讓使用者有更加深度的互動體驗。Google Play Movies 在 Android TV 上的數據顯示，在 Android TV 上平均使用時間比行動裝置還要多了 2.5 倍，因此可以發現使用者在 TV 上的使用行為有更長時間的互動，更多的購買率。 Netflix 也提供了一份數據參考，用戶原先在 TV 以外的裝置使用率有 80%，但在六個月後，有 2/3 的用戶都轉到 TV 上作為他們主要使用的裝置。根據 Netflix 的研究，在客廳裝置的佈局，可以讓提高他們服務的回訪率。

Google 宣布 Android TV 會加入 Google Assistant 的功能，透過 Google Assitant 能帶給使用者更加方便取得想要看的內容，藉此還能提高使用率，為了要整合 Google Assitant，開發者需要處理兩件事，處理 voice control 來的指令以及提供 metadata 給 Assitant。在 TV 上會有三種 Google Assitant 的使用情境：

1. 探索內容：可以透過 Google Assitant 語音搜尋來探索喜歡的內容，例如 “OK, Google. Show me Sci-Fi shows.”
   這時就會顯示各種不同的 app 所提供的 Sci-Fi shows 內容。
2. 互動性：使用者可以透過確切的指令呼叫 Google Assitant 去播放指定的內容，例如 “OK, Google. Continue watching XXX.”，這時 Assistant 就會透過對應的 app 來播放指定的內容
3. 控制性：使用者可以透過 Google Assitant 去控制電視的操作，例如 “OK, Google. Pause playback.”

在今年夏天 Android O 將會改變 Android TV home page 的使用經驗，改變了什麼呢? 以往 Android TV 的使用情境是 app-centric ，以 App 為中心提供各式各樣的內容給使用者。使用者在找尋內容時，會因為當使用的 app 越來越多，內容的數量暴增而難以找到想要看的內容。為了改善使用者體驗，Android O 推出了 channel-based 的使用者體驗，期望 app 能夠更容易提供使用者想要看的內容，並減少使用者找尋內容的時間。

畫面的最上方是 Google Assistant，讓使用者第一時間可以透過該功能找到想要的內容，接著下方的列表是最愛 app，使用者可以在這列定義最愛的 app，快速地開啟 app 播放內容。接下來一列一列的內容，就是上述所提到的 channel，使用者可以自訂 channel，讓用戶更容易找到想要找的內容，開發者要注意的是，選擇最適當的內容放在 channel，吸引使用者觀看，此外，現在更提供 video 預覽的功能，讓用戶能在 channel 上，就能透過預覽來觀看內容。如果用戶很喜歡 app 的內容，想要再多增加該 app 的 channel 也是可以做到的。新的 Android TV 使用經驗希望用戶能夠在裝置上發現他所想看的內容，以及增加 app 的回訪率，因此， Android TV 又定義了 watch next ，這列放在最愛 app 之下，希望用戶能夠在這列就找到想要繼續觀看的內容。

在改善 TV 使用者經驗的部分，可以分成三個面向來說帳號驗證 (identification)、發現內容 (discovery)、付費 (payment)

1. 帳號驗證：登入一直是 Android TV 的痛點，因為裝置本身的限制，只能使用遙控器做輸入，為了降低使用者帳號驗證輸入的痛苦，使用 Smart Lock 做帳號密碼的串連是一個非常好的用戶體驗，用戶不需要再次輸入帳號，即可以透過該功能登入 app 使用。
2. 發現內容：探索內容是一件非常複雜的工作，有許多內外部因素來決定使用者想看的內容，研究指出，使用者有四種形式去找到想要的內容尋找，選擇，瀏覽，快速瀏覽。估計有 20% 的瀏覽都來自搜尋功能，所以開發者需要確保內容標題， metadata 能夠被搜尋功能正確的搜尋出來。
3. 付費：整合 Google Play billing 能幫助用戶只需要在三個步驟就能完成付費，此外訂閱，免費使用也是一個很好的行銷方式。

Android Fireside Chat

這次的爐邊會議仍然維持一貫輕鬆的話題，擷取兩個較引人注目的話題。
Fuchsia 是 Google 前段時間曝光的新作業系統，目前還在實驗階段，未來還有許多變動的因素，但可以確定的是它將會是一個完全獨立的專案。

Project Treble 解決了 Android 版本更新一直以來面臨著許多問題，版本破碎、更新速度緩慢等，它建立了 Vendor Interface 將裝置商的實作和系統獨立開來，並透過 VTS 測試 Vendor Interface，希望透過這層 Interface 可以加速和簡化裝置商的更新流程。然而雖然 Project Treble 解決了許多問題，但也因架構改變很大，所以此次 IO 並沒有 Project Treble 相關 Session，我們仍然有許多需要改寫的功能尚未完成，因此短期內 Android O 還不會採用 Project Treble 的機制。

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.