转载

100 Days of Google Dev 上集

Google I/O 2015 已經結束蠻久了，但是隨著 Google I/O 2015 落幕而開始的 100 Days of Google Dev 卻才剛結束 2 天，去年在 YouTube 上大概在 2、3 週內就將 I/O Bytes 的影片全數釋出了，今年改為 1 天 1 部影片，弄得人家心癢癢的不太舒服。

參考連結： Google I/O 2015 – 100 Days of Google Dev

無論如何，我們部門內的成員平時就有在追 YouTube 上的 Google Developers 頻道，所以眾人也順便將 100 Days of Google Dev 的影片做了每篇 2~300 字的中文摘要貢獻給台灣的 Google 相關技術開發人員嘍。因為 100 部影片摘要這個量不算少，將會拆成上、中、下三集。

01 Android Design Support Library

Design Library 提供了許多進階的 UI 元件幫助實現 Material Design

TextInputLayout：可在 EditText 中加入浮動標籤和錯誤訊息

FloatingActionButton：適合做為頁面中的主要動作

Snackbar：提供快速的訊息回饋，並且具有互動性

TabLayout：提供分頁導覽的框架，有固定分頁與可捲動分頁兩種呈現方式，另外還可以與 ViewPager 搭配

NavigationView：利用來做 Drawer 的內容設計，可以透過程式碼或 menu.xml 來自訂項目

CoordinatorLayout：提供動態效果給依附的子項目，建立互動關係；另外可以配置 AppBarLayout 與主要內容，為這些元件標上定義的捲動 flag，使其在捲動時達到互動效果

CollapsingToolbarLayout：可以在 CoordinatorLayout 提供的互動關係下，調整 Toolbar 的各種視覺效果，例如標題大小、圖片收合方式

導入方式：在 gradle dependencies 中加入 compile ‘com.android.support:design:22.2.0’ 即可

02 The Magic of LRU Cache

若把 Bitmap 存放在記憶體當作是快取，當你需要使用某個 Bitmap 就只需產生一次，之後如果再使用就可以直接快速從記憶體中取得，不需要再從磁碟或是網路讀取，這樣就能按照需求不斷重複使用。但是快取越存越多，最後還是得移除某些物件避免記憶體不足的窘境。

LRU 這個快取類別紀錄了存放的清單，一旦系統用到的物件就會跳到清單的前面，這樣當記憶體容量不足的時候，就會自動移除排在清單後面的物件，並且釋放記憶體來增加記憶體空間，這種替換演算法稱之為 LRU (Least Recently Used)

LRU 屬於封閉型容器，有容量大小的上限，避免佔用過大的記憶體導致影響系統的正常運作，並使用 key value 的方式宣告:

LruCache bitmapCache = new LruCach<String, Bitmap>();

所以初始化 LRU 時必須給予一個容量大小，建議的方法是根據應用程式能使用的記憶體大小為基礎來設置，例如:

int availableMemInBytes = activityManager.getMemoryClass() * 1024 * 1024;

LruCache bitmapCache = new LruCach<String, Bitmap>(availableMemInBytes / 8);

另外，繼承 LRU 類別可以覆寫 sizeOf(String key, Bitmap value) 回傳指定 Bitmap 的大小。

而取得物件的方式與 Hash Table 相同，get(String key) 可取得 LRU 快取中的 Bitmap，若該物件不存在或是被清除則會回傳 null，我們可以以此判斷甚麼時候才需要再次去記憶體以外的地方讀取。

03 Google Play Services 7.5

Google Play Service 7.5 帶來更方便的 API，讓你能建造更好的 Apps。

像是用來讓 server 與 App 傳遞訊息的 Google Cloud Messaging 新增了訊息訂閱功能，App 端可向 GCM server 指定想訂閱的主題，GCM 可藉此篩選只傳送訊息給有訂閱某主題的用戶，開發者也不需要自行處理傳送特定對象部分。

此外也新增了 GcmNetworkManager，App 端可自訂與 GCM 接收訊息的週期、特定條件，例如限定只有透過 wifi 連線下才接收、只有在電量大於最小值時才接收等，聰明地節省了頻寬與耗電量。

App invites API 則是讓使用者可以透過 deep links 直接邀請朋友們來下載你推薦的 App，比起撒網式的廣告，朋友推薦更容易提高下載轉換率。

Remote Display API 讓手機端可以單純的將畫面顯示在另一個接收裝置上，例如 ChromeCast，意味著你可以寫一個在大螢幕上玩的手機遊戲了。

Google Map 現在也支援直接安裝在原生的 Android wear 上了，可以直接在手錶上滾動、縮放、查看街景、標示當前位置等地圖功能。

Smart Lock for Password 則是投過雲端儲存密碼，提供了方便的智能鎖，例如你在有登入 Google account 的 Chrome 瀏覽器上登入了某個服務並儲存密碼，那麼在 Android 裝置上的同個服務的 App 則可以直接取得同組密碼來登入，前提是要登入相同的 Google account。

Google Fit 現在提供了更多運動類型的 API，可以更多元化的判斷使用者在做什麼運動，包含了令我匪夷所思的二頭肌訓練都判斷的出來。

04 Push Notifications on the Open Web to increase engagement

這篇在推廣除了 Android 的 GCM 也可以使用在 Chrome 上，影片內容介紹五個要點

一、新增 GCM 的 project

二、將 GCM id 塞進 web manifest.json 的 gcm_sender_id 中，而 manifest.json 寫在 head 中是以

方式載入

三、在 main.ja 中註冊 sw.js (Sevice Worker)，在 UI 中可以增加 push notifications 的開關，來處理是否註冊 sw.js

四、從 server 傳送 message 到 Push Service, 影片中是使用 cURL 做測試，在 Push Service 收到 message 後會轉送到 sw.js

五、最後在 sw.js 中產生 unsubscribe 做退訂的動作

05 Use low power sensors to detect user activity

ActivityRecognition 可以讓用戶透過單一 Android API 檢測用戶目前的活動狀態是在走路、跑步、騎自行車還是交通工具中，使用 ActivityRecognition 只需要連接 GoogleApiClient 與 ActivityRecognitionApi.requestActivityUpdates 即可在我們自己提供的 callback function 中收到 DetectedActivity 中所列舉的活動狀態，這個 API 被設計成在活動改變時透過 callback 通知開發者，需要的電量是很低的，開發者可以用來詢問用戶是否切換為跑步模式，或記錄下用戶平均花多少時間騎車、坐車。

06 Introduction to Maps API on Android Wear

對於想使用 Android Wear Map API 的開發者來說是很方便的，因為它的 API 設計跟手機的 API 是相同的。在使用時第一個會面臨到的是 Wear 特殊關閉手勢的問題，在一般的 App 上我們使用由左至右滑動來關閉 App，但在 Map 上，這個動作會跟地圖拖動有所干擾，所以必須使用長按彈出關閉鍵的方式來關閉App，在這裡我們使用 DismissOverlayView，並且透過 onCameraCange 來監聽使用者拖動 Map 的位置，更多 Map API 的細節可以參考 http://developers.google.com/maps/documentation/android/wear

07 Introduction to Voice Interaction API

在 Android M 裡新增的 Voice interaction API 可以讓 App 與用戶間進行口語化的交談，對於某些語音指令，App 該做些什麼是很明確的，但是如果用戶的指令不明確，而且你的 App 也不知道該做些什麼，你的 App 可以選擇詢問用戶問題，來確定接下來做的事情是用戶想要的。

Voice interaction API 就是讓你的 App 在不知道該做些什麼的情況下可以詢問用戶一些有幫助的問題。例如，當 App 想要開始播放未成年不適合觀看的影片之前，會先詢問用戶要不要繼續播放？這時候你可以用 getVoriceInteractor.submitRequest(new Confirm(“Are you sure? ”)) 來確認用戶是不是要繼續播放，Google 應用助手可以辨認許多表示確認的方式，比如人們經常說的 “是的” “請這麼做” “繼續” 或者 “就是這樣”，如果你希望用戶在一個列表中選擇，你可以在你提交語音交互請求時創建一個存放選項的數組，如果用戶說出了不存在列表中的選項，Google 應用助手會再次提醒你。

例如搜索，播放音樂，設置鬧鐘，以上的這些事情都可以使用系統語音指令，Google 應用助手能夠識別用戶發出的這些指令並且 trigger intent。如果系統指令不能滿足你的應用需求，Google 最近有引入了自定義指令，可以參考影片中提到的網址瞭解更多內容。最後則提到語音交互功能是提高應用下載量以及吸引用戶的一個很棒的方式。

08 MapsZen – Seeing the Lite

Maps API lite mode，提供一個靜態的地圖，這個地圖只是一張 image，無法像一般地圖可以 scroll 或 zoom，但優點是非常快速，消耗很少的記憶體，且還是保留 click listener、標記點、路線。設定 lite mode 很簡單，只要將 GoogleMapOptions 的 liteMode 設為 true 即可，可以在 class 中設定，也可以在 xml 的 property 設定。

09 Using LINT for Performance Tips

使用靜態分析的方法檢查出 Android Project 淺藏的錯誤，將程式的效能，安全性達到最佳化，有三種啟動 Lint 做靜態分析掃描的方法

release builds : 每次建置 release builds 時，會自動啟動 lint 做靜態掃描

Command Line : 可以透過 command 方式來啟動

manually : 透過 Analyze -> Inspect Code 手動啟動 lint

可在此選擇想要檢測的項目 Android Studio 的 File -> Open Settings -> Default Settings -> Inspections，影片中建議設定檢查 Lint 的項目有三項

memory allocation : 針對 memory leak, memory churn 做掃描

layout hierarchy is too deep : 針對 UI performance

overdraw : 針對 UI performance

10 Supercharging page load

如何有效率的在 web App 上顯示網頁

1. 畫面的初始化使用純 HTML 會比 JS 初始化還要有效率

2. 在 Server 先將資料轉成純 HTML，以影片的例子來說，在 Server 端取得維基百科的資料並轉成純 HTML 才回傳給 Client

3. 利用 Chunked Encoding 加速畫面初始化的時間

4. 利用 ServiceWorker 處理 Cache 使只有第一次載入花最多的時間，往後的同樣的頁面載入更加迅速，在網路連線不穩定時，也可以呈現內容。

5. 明年即將推出的 StreamAPI 可以解決第五點最後提到的問題，StreamAPI 會提供 Response Reader，透過 Reader 可以片段的處理 Response，若再搭配 ServiceWorker Cache網頁內容與局部更新內容可以更加速第一次

後的瀏覽速度，範例程式碼https://github.com/jakearchibald/offline-wikipedia

11 Fingerprint and payments APIs

提供指紋辨識系統 API FingerprintManager，可以用在線上付款和登入控制，且App 能有完整的 UI 控制權。KeyguardManager 讓用戶可以利用螢幕鎖定畫面去當作交易前的步驟，或者是定義鎖定 timeout 條件以保護訊息敏感的 App，可以跨 App 同步 timeout 狀態。

12 Store Listing Experiments for Google Play

在 Google Play Store 上架，你可以提供多個版本的 icon ，提供給不同族群的用戶，藉以找出最受歡迎的 icon ，亦或是根據不同的地區，提供不同的圖示及敘述的文字。並且可以根據 Google Play 上為你分析的數據中找到最好的方案。如何讓 App 上架最有效率？我們發現：

1. 你的 App 需要有個清楚、明顯的核心價值給使用者。

2. 選擇一個面向給予使用者深刻的體驗，如：畫面很棒、很刺激…等。

3. 設計出一個漂亮的 icon 很重要

4. 介紹影片也很重要

5. 勇於大膽嘗試鮮豔且有設計感的 icon

結論：最佳化你的 Play Store 頁面對你的 App 是一件最重要的事情！

13 Get your App found on Google

使用 Search Console 可確保 Google 能搜尋到開發者的網站，每當建立新的網站，也能查詢用戶是使用哪些關鍵字搜尋產品。

在 Google 讀取網站內容和 App 發現錯誤時，也會發出通知，藉以提昇 App performance。

SC 能分析 user 對於 App indexing 的回應，主要是記錄用戶在開啟 App 前的事件。

GA 則是著重於使用者在 App 內的行為記錄。

因此，藉由 search console 得到的資料可分析出受歡迎的網頁和產品，

將能提供開發者將開發重點放在核心內容，提高網站與 App 使用率。

14 Building an enterprise ready App with Android for Work

Google Play for Work 提供一個專門的頁面給使用 Android for Work 的企業，當 Google Play for Work 和 Android for Work device 結合，可提供 IT Admins 完善的控制及安裝選項，如此可以增加 App 在企業客戶上的曝光率。現在 IT Admin 可一次購買多種 license 並分發給有使用 Android for Work 的員工，且這些 license 是屬於公司的，若員工離職，企業可將該離職員工的 license 轉讓給其他員工，建議使用 Google Play Licensing API 定期檢查 license 所有權。

15 MapsZen Framing your shots

在拍攝影片時，運鏡手法有很多種，也會隨著導演腦內的想法實現，MapAPI 在此經驗下設計了一些複雜的 Camera，使你可以在三維空間架構地圖，包含了傳統的投影、縮放和平移的功能，也可以旋轉、傾斜和執行鏡頭動畫，讓使用者在平面地圖上可以感受從空中俯瞰並有深度及探索的感覺，使用經驗更為提升。

Camera API 提供了取得軸承和傾斜程度的方法，可以指定 Camera 從某一點的位置移到另一個點，中間透過動畫漸變至結束位置。

16 Hidden Cost of Transparency

繪製透明效果經常被用於程式的開發之中，但是也伴隨著效能使用的提升，本篇介紹了如何更有效率的進行透明繪圖。

首先若繪製具有透明度的圖象必須繪製兩次，一次是背景的圖像，第二次再繪製混合背景顏色的透明像素，因此更加耗費效能。而 GPU 硬體繪製能在硬體層直接處理像素的呈現與變更縮放、旋轉與透明度等效果，之後重複使用便能省下繪圖運算時間 (Copy)。

但並非所有狀況使用 GPU 都能達到預期有效率的處理。例如，當我們需要繪製一個透明度漸變的動畫效果，由於硬體層處理初期會比較耗費效能，隨著時間效能損耗會越來越低，而動畫每一偵繪製結束就會銷毀硬體層處理再重新計算，這樣反而比起直接繪製更加耗費時間，因此我們需要告訴系統更詳細的處理方式:

指定轉譯器暫時儲存硬體層，重複使用指定的圖層，繪圖速度將會快上 2 倍

setLayerType(View.LAYER_TYPE_HARDWARE, null);

繪製結束關閉硬體繪圖處理

setLayerType(View.LAYER_TYPE_NONE, null);

而在 API 16+ 可以使用 ViewPropertyAnimator.withLayer();

動畫系統會自動判斷處理圖層類型而達到更好的效能。

另外一個技巧，當繪製透明區塊底部沒有重疊的畫面，所以沒必要有繪製的先後順序 (不需計算透明混合背景顏色)，這時可以覆寫 View 的 hasOverlAppingRendering()

指定回傳 false: 不會建立硬體緩衝區。單一步驟繪圖，大幅增加效能。

若是畫面有重疊的部分也可以回傳 false 給系統，只不過繪製透明度的效果會有些許誤差。兩者的選擇端看您應用程式的需求來決定。

17 Analyzing your App with Google Analytics

通常在用 Google Analytics 的開發商第一個想知道的就是有多少使用者在使用自己的 App ，所以可以從新用戶的報告裡查看出來，而在分析裡也可以查看出使用者在什麼情況下會關閉使用 App ，可能是在某一個畫面或行為，只要 Google Analytics 記錄愈深入，這些資料就可以改善 App 的問題，將 App 國際化是一個很好的選項，在分析資料時開發商可以得知自己的 App 在那個國家特別活躍，如此就可以特別為那國家新增在地化的語系，而 Google play 的評論也可以得知用戶的使用回饋，例如某個功能可能很難使用或是程式裡的購買功能是無法運作的，這些都可以幫助開發商更了解用戶

18 Supercharge your App business in 5 minutes with AdMob

如何在 App 裡面賺到錢？目前 Admob 有超過 65,000 Apps 在使用，有 35 billion 的營業額，您還不加入？如何在 App 中獲得高收益？不外乎有二個要點，擁有 High fill rate (高廣告填充率) 以及 High CPMs (高點擊率)。Admob 提供多種廣告版位供使用者來挑選，影片廣告、Interstitials (滿版廣告)還有Banners(橫幅廣告)。當然IAP也是很重要的，統計指出約有98%的App有使用IAP，如果你做了一個遊戲，使用者不想等待遊戲升級的話，可以使用IAP做購買，讓使用者開心。另外 Admob 也提供 AdMob Reservations (目前仍在beta)，您可以使用 Ad mediation 與 Ad Networks optimization 來整合其他廣告商的廣告，您可以設定指定的價格，高於您指定的價格，才會出現該廣告商的廣告，如果沒有該價格，會退求其次顯示別家廣告商的廣告，有效加強高收益的廣告以及滿足廣告填充率。最後，Admob 也整合了 Google Analytics 讓您在數據分析之中，找出有效率的廣告版位。點此來詳細了解 http://www.google.com/admob/

19 Designing For Drivers

對使用者而言，在車上最主要的工作就是駕駛，而 Android Auto 只是次要的。因此這項設計最主要的目標就是極度簡化各種互動項目，而在這概念下，我們認為任何行為都必須在最多 6 個操作步驟內完成。以通話功能為例，我們習慣利用通話紀錄快速撥打給常聯絡的對象，但是最多只提供到四面，因為在你駕駛中真的不需要這麼多的資訊。另外可以使用語音指令取代複雜的操作，例如想撥打給未在近期聯絡人清單的對象。再來以 Google Play Music 為例，我們發現對駕駛而言最實用的功能就是立即聆聽、最近聆聽歌單、電台，因此只在功能清單放入這些功能，而其他複雜的分類項目，便都交給語音指令取代。

我們建議可以從以下的步驟來思考設計方向：

1. 只列入駕駛在行車中真的需要的功能

2. 在最上層的功能導覽頁限制在 1~2 面內

3. 通盤掌握每個功能需要的操作步數，包括點選及捲動

20 New APIs in M for Android for Work

Android for work 提倡的是帶你自己的手機到公司使用 (Bring Your Own Device)，在 android 5.0 IT 可以在每個人的手機上設置一個 work profile，work profile 包含了工作上要用到的 App 與資料。

新增的 API 如下：

1. Network usage API 專門用來管理 work profile，現在 IT 可以透過裝置上的 App 中斷裝置上的資料使用。

2. Certificate API，現在如果是 IT 准許的 App 可以直接安裝 certificates 不需要透過員工確認。

3. Read-only wifi config，可以確保員工使用的網路是沒有問題的。

新版的 Android for work 改善了 BYOD 的 user experience，不管是私人使用或是工作上使用的 App 都可以裝在同一裝置上，使用者可以在 status bar 上看到自己現在使用的 App 是屬於私人的還是工作上的。現在也可以在設定的 control pannel 直接選擇要用到的 VPN App ，除此之外還改善了 contacts provider，如果現在你的老闆打電話給你，你不會只看到數字也可以看到他的名字。

最後則提到了 Corporate-Owned, Single-Use device，當你在旅館想要叫 room service 的時候，如果只需要用一台有安全管理的 Android device 就可以辦到這件事豈不是很方便？現在的 Android for work 可以讓 IT 使用新的 API 來管理裝置上的 App，讓這些裝置可以安全的在公眾場合使用。

21 Google Search for Developers

Google Search 提供了 2 組 API，其中一個可以用來使 App 的用戶回訪率增加，一個可以用來使 App 的新用戶增加。其中使用戶回訪率增加的 API 稱為 App Indexing，這組 API 可以讓開發者將 App 的內容添加到 mobile 的 Google Search 中，使用方式只需要提供圖片、文字、URL Schema 即可讓用戶在 mobile Google Search 中輸入關鍵字時一併將你 App 內符合的內容列出來，進而提高用戶回來使用 App 的機率，另一組是為你的 Website 加入 Schema.org 的 Actions 讓 Google Search 可以知道你的每個 Page 各是哪種活動類型，再加上 Website-App 的連結功能，這可以做到在用戶搜尋某些關鍵字而獲得結果時，讓 Google Search 在搜尋結果頁上自動推薦用戶安裝你的 App，即便他沒有安裝你的 App。

22 MapsZen – Visualize

目的:希望解決在 map 上 information overloading 的情況，例如: 要找一家好吃的餐廳，map 上卻把所有的餐廳的標示出來，讓使用者需要花費時間，一個一個點開 map 上的 marker 來看評價，這並非使用者所想要的，我們要的是能夠透過 data visualization 快速定位出我們所需要得資訊。

方法:

Goolge map API 提出三種方法來解決

1. marker : 把重要的資訊 highlight 出來

2. cluster : 把過多的資訊集中，當地圖 zoom in 的時候再展開詳細資訊， zoom out 的時候將資訊縮小

3. heat map : 把資訊用 heat map 方式呈現，例如熱門的地方標示紅色，rating 較低的地方標示綠色

使用這三種 data visulization 方法來簡化 information overloading on map ，讓資訊更容易被使用者運用。

23 Avoiding Allocations in onDraw()

雖然記憶體配置在平常是件很容易的事，但是仍然會有堵塞的情形，例如像是在記憶體不足的時候進行記憶體配置更有可能造成堵塞，而 onDraw 是個在 UI Thread 上運行的方法，在UI Thread 呼叫一個可能造成堵塞的方法並不是件好事，而且 onDraw 在系統中會被頻繁地呼叫，因次如果在onDraw進行記憶體配置，頻繁的配置會快速地導致記憶體不足，而必須花更多的時間回收記憶體。而通常在 onDraw 使用的物件都屬於 android.graph 類，這類的物件大多是原生的 C++ 實作，回收物件必須執行 Destructor，Destructor又必須和 Heap 同步，於是就開始卡 UI Thread了，怎麼改善：

1. 將記憶體配置的行為從 onDraw 移出，Android Studio 可以幫助你重構，在記憶配置的位置右鍵 -> Refactor -> Extract，可以快速地將物件記憶體配置移出 onDraw

2. 盡量將物件宣告成 Static

24 Single Use Devices

雖然記憶體配置在平常是件很容易的事，但是仍然會有堵塞的情形，例如像是在記

憶體不足的時候進行記憶體配置更有可能造成堵塞，而 onDraw 是個在 UI Thread

上運行的方法，在UI Thread 呼叫一個可能造成堵塞的方法並不是件好事，而且

onDraw 在系統中會被頻繁地呼叫，因次如果在onDraw進行記憶體配置，頻繁的配

置會快速地導致記憶體不足，而必須花更多的時間回收記憶體。而通常在 onDraw

使用的物件都屬於 android.graph 類，這類的物件大多是原生的 C++ 實作，回收物

件必須執行 Destructor，Destructor又必須和 Heap 同步，於是就開始卡 UI Thread

了，怎麼改善：

1. 將記憶體配置的行為從 onDraw 移出，Android Studio 可以幫助你重構，在記憶

配置的位置右鍵 -> Refactor -> Extract，可以快速地將物件記憶體配置移出 onDraw

2. 盡量將物件宣告成 Static

25 Android M Developer Preview

教你如何更新的你的 SDK 以及升級你的裝置至 Android M Preview 。

( 請參閱 http://developer.android.com/preview/index.html )

新版的 SDK 提供了即時請求權限的功能，此功能會影響所有在新裝置上運行的 App (即使 Target 不到 23 也一樣)，新版本只對舊方法進行『有限度』的兼容，官方建議請儘早規劃實作即時請求權限功能。

( 請參閱 http://developer.android.com/preview/features/runtime-permissions.html )

並提供了 App Auto Backout 的功能，幫助使用者去完整備份、還原 App 資料，每個 App 有 25MB 的雲端空間去備份你 App 的重要資料。

( 請參閱 https://youtu.be/HXacyy0HSW0 )

提供了指紋辨識 API 以及去指紋 adb 命令去幫助你進行測試。

( 請參閱 https://youtu.be/VOn7VrTRlA4 )

官方釋出規劃於五月釋出 Preview one , 六月釋出 two, 七月釋出 three, 以及於 Q3 進行 Release。歡迎及早進行測試、加入 Community 並持續關注M的動態。

26 Installable Web Apps

透過一個 json 檔案，在使用者的裝置桌面上新增 web App，並可設定開啟方式與頁面。

原理是在每個頁面設定一個對應到此 json 檔案的 href tag，且也可使用 meta tag 去設定 theme color。

在 json 檔案裡，分別定義了開啟的頁面、方向與方式，可分為 display：standalone 與 display：browser。

standalone 可以讓 web App 隱藏瀏覽器的 UI，看起來就會跟 native App 一模一樣。

Chrome 42 (March 2015) 發佈 App Install Banners 的功能。

Chrome 43 (June 2015) 能偵測使用者安裝或是取消了 App。

Chrome 45 (Beta on July 21 2015) 可以透過儲存觸發事件，在自定義的時機點再呼叫 prompt() 顯示 banner。

支援 service worker (在可離線模式下運作的服務)尚未支援 iOS 的 Chrome

27 Designing for Google Cast enabled Applications

如果你已經在 App 跟隨 Cast 的設計概念，你便能為使用者帶來親切的操作體驗。Cast 的核心就是遙控事物，而對使用者來說，操作手機或平板已經是直覺且容易的，於是他們可以更愉快的透過遙控來分享自己手中的事物。

我們提供了清楚的設計概念給開發者：

developers.google.com/cast/docs/ux_guidelines

developers.google.com/cast/docs/design_checklist

這些可以幫助你完整照顧到 Cast 過程中所有的使用者體驗，包括想 Cast 的內容、可以 Cast 的裝置清單、正在 Cast 的內容資訊、每個 Cast 需求佇列等等，讓使用者不會對目前該將眼光專注於哪個裝置感到困惑。

28 Simplifying sign-ins

Smart Lock 是一個讓你在登入裝置、App 或網站驗證更快且更安全的認證流程。舉例來說，你在 Chrome 上登入某個網站服務，選擇了儲存密碼後，Google 會將密碼儲存在雲端上，此時若你至另一台裝置使用，便可以在 Chrome 登入同一個帳號來取回密碼登入，這樣的機制目前也實作在 Android 上，只要裝置和 Chrome 登入的是同一個 Google 帳戶，那麼就可以取得已登入的授權自動登入。若要提供方便的登入驗證，別忘了要在 Google Play Console 後台設定你的網站和 App 關聯。

29 MapsZen Not Lost

Directions API Web Service: 計算兩個位置之間的路線，可支援各種常用的交通工具，並且可用動畫顯示路線行進過程

Maps API: 可提供街景服務，顯示地圖實際街道景象，兩者搭配可以很好的引導使用者找到他們需要的地圖路線

但是請注意，街景服務不應該完全覆蓋原本顯示的地圖，要使用 sliding 動畫將街景服務畫面顯示/隱藏，覆蓋部分地圖並且保持能顯示完整 Google logo 的距離

30 Strict Mode

影片中一開始就出現一個煩人的 ANR dialog ，這篇在討論如何檢測 ANR 的問題，所謂的 ANR 就是當 App 超過 5 秒未回應時就會跳出一個 ANR 的 dialog，告知 App 無回應，會發生這問題的原因是主執行緒的負擔過重在等應用程式回應造成的，而主執行緒是唯一可以處理輸入及繪圖作業的執行緒，所以只要主執行緒停止運作時 App 也就會無法運作。

但又為什麼主執行緒會停止運作? 主要是因為磁碟或網路存取呼叫遇到無限期的擱置，所以接下來會教在發生 ANR 前搶先找出可能產生問題的地方。

首先要到開發人員選項中啟用「高安全性模式」，再 App 的主執行緒被擱置時畫面的邊緣會閃爍紅光，這就是高安全性模式的警式，表示目前可能發生 ANR ，例如，如果 App 在做捲動事件時突然載入 90 張點陣圖，如果有開高安全性模式，畫面上就會閃爍紅光，如此就可以檢視 ANR 的問題點了。

31 Designing Games for Google Cast

如何使用 Google Cast 來設計多人遊戲。多人手機遊戲不外乎就是找尋與加入。一般來說我們把它分成二類，其一是 CastEnabled Game 也就是可以同步畫面到 Chromecast 的遊戲，通常只是把手機螢幕畫面鏡像到電視上，第二是 CastRequire Game，也就是必須要有 Chromecast 才能玩的遊戲。控制器的設計也很重要，我們可以用三軸感測器來當做手勢搖桿，或者利用觸控做成遊戲搖桿來控制電視螢幕上的人物或角色。另外，可以顯示使用者私人的訊息，而不顯示在電視大螢幕上，這在解疑遊戲特別有用。有一個重點是，盡量不讓使用者同時上下擺頭，同時去注意電視與手機，這會讓使用者的體驗不佳。接下來介紹 Receiver Cast 的原理與設計，手機，也就是 Sender 會和 Chromecast 也就是 Receiver 做溝通，手機會將 App 的 ID 傳給 Chromecast，Chromecast 會採用手機傳來的AppID來顯示對應的畫面，這裡顯示的畫面是在後台設定好，採用 HTML 和 JavaScript 來設計的網頁，在這裡我們使用了 GameManager API 來做多人遊戲加入、開房間的動作，當然這個API也支援 iOS。手機日新月異，每台都有強大的CPU&GPU為何不能拿它來算圖呢？這裡介紹了 RemoteDisplay API for Google cast，由從手機做各種算圖，然後再透過 API 直接把畫面傳給 Chromecast，例如 Just Dance Now、Big web quiz、SCRABBLE Blitz 以及 Google的範例檔案都是不錯的參考。