Android at Google I/O 2016 上集

Google I/O 2016 結束一段時間了，今年總共放出影片 182 部，其中和 Android 相關的影片有 65 部，為了要快速了解今年本部門的守備範圍內有哪些新東西，大家分著把影片看過一輪後再與彼此分享，順便各自寫了些摘要分享出來給國內的 App 開發者們。

Android at Google I/O 2016 中集
Android at Google I/O 2016 下集

What’s new in Android

Android N 有哪些新功能？

ConstraintLayout 是 Android N 的全新元件，可以在 Android Studio 中透過拖曳的方式排版、對齊任意在 Layout 中的元件，這對開發者來說真是一大福音，不過目前還是 preview 版本，不曉得實際使用的順暢度如何，與在多解析度的裝置下是否能自動調適。

新增的分割畫面功能可以在螢幕上同時設置兩個不同的 App，並可動態的調整分割畫面大小；在 Android TV 上則可在螢幕的一角顯示另一個畫面，稱為 Picture in picture 功能。

過去就有的 Drag and Drop 增加了新功能，可以在不同的 Activity 間透過拖曳手勢傳遞資料，例如拖曳 App 中的圖片至另一個分割畫面的 App。

Notifications 則新增了新的樣式，可以快速在通知欄上回覆訊息、並可以將相同類別的通知群組在一起顯示。

在通知列中則新增了快捷鍵的設置，可以自定義五個超級快捷鍵在通知列表的上方，App 也可以透過 API 定義自己的快捷磚，例如一鍵隨選播歌，人生省下了反覆開啟 App 的時間可以多做好多事呢。

過去 Android 可以在設定中調整字體大小，但有時過大的字體會衝出 Layout，現在可以直接設置畫面顯示的大小，原理是直接縮放 dpi，所以在刻畫 UI 時要避免使用 px 。

現在人普遍能說兩種語言以上，過去系統設置僅能切換單種語系，在 Android N 上則可以同時選擇多種，當 App 不支援第一設定的語系時，會退而尋找你設定的第二、第三…語系顯示。

Android N 也優化了省電模式(Doze)，當螢幕關閉時不會立即進入靜止狀態，而會偵測實際真的未使用了一段時間才會關閉網路，延遲工作等，當螢幕開啟或接上電源時就會恢復工作。

Project Svelte 是為了解決過去收到隱含式的 intent，如網路狀態改變會喚起所有有註冊監聽 CONNECTIVITY_ACTION 的 App，被喚醒後發現沒有自己的事又關閉，造成不必要的記憶體和電力浪費，之後需透過 JobScheduler API 詢問並可大幅改善此狀況。

在設定頁中的 Data Saver 可以讓使用者個別對 App 停止背景網路存取，或是限制在前景時的網路流量及影像品質等，以節省行動數據費用。

Android N 也加快了開機時間；當手機重啟且尚未解鎖螢幕時僅能使用加密的儲存空間與部分功能，如鬧鐘、電話和訊息通知等；在手機解鎖後則可以使用認證加密的儲存空間。

新增了工作模式的設定，可以快速切換不同模式需要禁用哪些 app，比方說非工作模式時不想收到惱人的 email。

對開發人員來說，最大的改變是編譯與安裝的速度加快了；也新增了一些 Runtime Libraries 如 ICU4J、java.util.function、java.util.stream、並提供了 Java 8 的支援，其中包含這四項功能：

• Default & Static Interface Methods
• Lambdas expressions
• Repeatable annotations
• Method References

在 Audio 方面，Android N 降低了 AudioTrack 約 40~70ms 的音頻延遲(Audio Latency)，也新增了 API 當下載的緩衝數據不足時可以動態調整 AudioTrack 的 buffer size。

Support Library 方面在 23.2 版新增了 Night Mode，可以快速在 Dark 和 Light Theme 中切換；Bottom Sheets，從底部擴展的 UI 元件；VectorDrawable/AnimatedVectorDrawable，向下相容的能適應不同分辨率的 drawable，並優化其繪圖效率與減小所佔空間；自動測量 RecyclerView 內容的方法。

還有許多對 Renderscript、OpenGL ES 3.2、Vulkan、adb shell 、NDK、VR 新增及優化的調整，在後面的影片中會再詳細介紹。

 

Image compression for Android developers

圖片壓縮的好處在於可以減少 apk 大小，也可以減少下載圖片流量，不管是減少 apk 大小或是減少流量都可以讓使用者花費更少的時間與金錢來使用你的 app，這對使用來說是一件好事，所以圖片壓縮一直都是很值得關注的議題。

在 Android 裡 常用到的圖片格式可以分為下列四種：

首先是 PNG：
PNG 的壓縮方法是針對每一列的像素做 filter ，將重複的畫素用 0 取代，之後再透過 deflater 演算法將這些無效的值刪除，輸出每一列壓縮後的結果，如果同一列的相同顏色越多則壓縮成果會越好，反之效果會越差。

使用 Android AAPT 可以幫助壓縮 PNG，而 AAPT 最主要做的 3 件事情：
1. 分析 PNG 檔，檢查你的圖檔是否只有使用灰階顏色。
如果你的 RGB channel 都是使用相同的值，那就可以用單一 8-bit alpha channel 灰階 256 色來表示這張圖片，達到壓縮效果。
2. 檢查你的圖片是否有用到 transparency channel。
如果你的圖片是完整的 opaque image，代表沒有用到任何的 transparencys，也可以透過移除 transparency channel 來達到壓縮效果。
3. AAPT 還可以掃描整張圖片來檢查你是否有用到完整的 256 色。
AAPT 會將你的圖片存成 palleted format， 先做出 256 色的索引表來存放真正的 RGB and alpha channel value，之後每個像素都用 256 色的索引值來表示，這樣類似 pointer 的概念讓原本每一像素從 32-bit 減少到只需要 8-bit 的空間即可。

但是 AAPT 能做到的只有上面三件事情，以至於能達到的壓縮效果還是有限，例如有些情況下圖片其實不需要用到完整的 256 色，使用少許顏色即可，AAPT 就沒辦法幫你做到這樣的壓縮效果。因此 AAPT 不適合拿來當 PNG 的主要壓縮工具，網路上 PNG 壓縮工具資源豐富，你可以直接挑選其中一個加入到你的開發流程，都會有更好的效果。

有種情況是，原始檔案在經過壓縮工具放到 res 資料夾，結果 build 完經過 AAPT 反而圖檔變大，這是因為 AAPT 並不知道你有將圖片先用其他工具壓縮過，他只會去做上面提到的三件事情，你可以在 Gradle 把 cruncherEnabled 設定成 false，這樣就可以把 AAPT 關掉。
另外，在視覺差異不大的前提之下，在設計圖片的時候盡可能地減少使用顏色會是很好的選擇 (例如從 32-bit -> 24-bit color)，因為這樣的差異對一般人來說幾乎是無感的，但是檔案大小卻可以相差很多。

第二是 Vector drawable：由於 PNG 是 raster files，你需要為了不同的解析度提供多個檔案，但是如果是用 code programing 的方法去畫這些圖片，不僅使用到的空間很少，還可以同時使用在不同解析度的裝置上，這就是 vector drawable 的概念。

第三是 JPEG：JPEG 的壓縮方法比 PNG 複雜很多，首先將圖片做區塊分割，之後再將 RGB 轉換成 YCBCR，其中 Y 代表亮度訊號，CB、CR 代表色差訊號，這是因為人類對光的敏感度遠大於對顏色的敏感度，再透過 DCT（Discrete Cosine Transfer）將影像的低頻值與高頻值分開，之後再透過量化來減少空間，最後則是編碼。

JPEG 的壓縮工具介面非常簡單，只要選擇壓縮品質就可以完成壓縮，不過應該要選擇怎樣的品質才不會對視覺造成影響？可以利用 Butteraugli open source project 可以比較兩張圖片對人眼視覺的差異程度，1.0 是標準值，如果差異程度小於 1.0 代表人眼無法分辨，大於 1.0 則會有明顯的差異程度，只要透過 Butteraugli 加上 script language 就可以自動選擇每張圖片的壓縮品質。在開發流程方面來說 JPEG 跟 PNG 一樣，壓縮工具資源豐富，也可以選擇其中一個加入到開發流程裡。

最後是 WebP：WebP 的壓縮成果不輸給 JPEG 或是 PNG 但是檔案卻可以更小，最重要的是 WebP natively support Android。

結論：當你的圖片是可以轉換成 Verctor Drawble 的時候，就使用 Verctor Drawble，如果不行的話，就使用 WebP，如果不支援 WebP 就再檢查是否需要透明度，如果需要就使用 PNG，如果不需要，必須依照圖片的複雜度來選擇使用 PNG 或是 JPEG，PNG 對於簡單的圖片可以有較好的壓縮成果，反之則是使用 JPEG，不管是 PNG 還是 JPEG 都不要忘了使用壓縮工具來進行壓縮最佳化。

最重要的原則還是要 profile your code，換句話說就是要根據 app 的使用情境去決定要提供怎樣的圖片品質。
例如：如果你的 app 是要在一些網速不夠快的國家使用，那這時候提供壓縮率較高、畫質較差的圖片反而會是上上策，
因為能夠流暢的使用 app 反而變成當務之急，這比 loading 半天只為了看到那 1 / 3 張精美的背景圖還來得重要多了！

 

Android Pay everywhere: New developments

Google 正積極發展 Android Pay 的付款機制，目標是全球化與各國銀行和銷售通路等達成協定，除了美國之外，英國也已經在稍早上線
下一步是澳洲與新加坡，目前已經與眾多知名 App 服務合作，例如 Fancy 使用 Android Pay 之後在美國相較於其他付款機制的交易轉換率提高了兩倍之多。

傳統網路購物結賬時，需要輸入大量信用卡相關資訊，使用 Android Pay 只需要使用指紋辨識即可快速完成付款，這使得在應用程式中進行付款更加便利、精簡與安全。

開發者在應用程式中加入 Android Pay 機制相當容易，Google 提供的 API 只需 10 行以內的程式碼即可支援 Android Pay 功能
https://developers.google.com/android-pay/

如果使用 Chrome 瀏覽器在網站上進行消費，Android 提供了 PaymentRequest API，讓使用者可以跳過傳統填寫姓名、地址與信用卡資訊等繁瑣流程，在按下付款之後以指紋認證，最終得到與 Android Pay 相同一致的使用者經驗。

另外還公佈了以下訊息
– 倫敦地鐵即將可以通過 Android 裝置直接感應付費，並且記錄進出地鐵站的資訊
– 美國舊金山到矽谷之間的 ATM，也將陸續支援 Android 裝置感應取款機制
– 對於一些優秀的合作公司，將提供 Android Pay 感應裝置
– 未來 Google 將更進一步與商家合作，推廣 Android Pay 與會員卡紅利點數結合

Android Pay 在未來將提供全新的付費體驗，世界各國銀行與商家，正在將 Android Pay 整合進系統或應用程式，讓使用者更便利、簡單與安全地進行消費。

 

Games: The Google advantage

首先講者提供了一系列與遊戲相關的 Talks 列表，Google 提供了 Donation API，他提供開發者與玩家可以透過你的 app 來拯救世界，
可以搜尋及幫助任何美國的非營利組織，也可以使用 Youtube 新推出的 Donation Cards，對 Google 來說，不只是娛樂玩家，同時也可以幫助有需要的人們。

另外 Google 也提供 Google App Ads for Games，幫你尋找最適合你的遊戲的玩家。最後，Google 也提供 Streaming 服務，有別於 Instant Apps，玩家不用真的下載，可以透過串流的方式來試玩你的遊戲。

典型的遊戲開發流程首先先會有 Brainstorming，或是參加 Game jam，或投票表決他們認為好的遊戲玩法，當確認想法可行後，接著會需要做 Beta program 給你的親朋好友們提供一些意見。若你覺得你的遊戲很棒並且可從中賺錢後，結著就是把你的發行你的遊戲並推廣給大家，但發行遊戲只是第一步而已。

Google 透過 Google Player Service，從三個面向來幫助你的遊戲成長：

1. Find the right users：Google 在 Google Play Store 推出 Early Access 區塊，Early Access 是讓你還在開發的遊戲，可以搶先讓大眾體驗的一個功能，並且可以讓使用者給你一些回饋，開發者可以透過這些回饋去進行調整。對於 Indie 來說，官方也提供了 Play Indie Corner 來讓你的 App 有亮相的機會。

2. Tailor game experiences：開發者透過結合 Player Stats API 與 AdMob 的廣告獎勵方式增加收入，並且不會影響到 In-app purchase 的部分，當他們預測使用者會花錢購買商品時，他們就不會跳出廣告，但若發覺使用者不會花錢時，他們就跳出獎勵廣告讓使用者看完後會得到好處。Player Stats API 新增了兩個功能，一個是預測使用者在接下來的 28 天內可能會花費超過 50 美元，另一個是預測使用者是不是會成為一個高消費玩家

3. Engage your user community：最近 Google 推出 Gamer IDs & Avatar，他可以讓你個人化你的 Gamer ID 與 Avatar 以及推出 Video Recording API，讓 User 可以直接在遊戲中錄製他們的 Gameplay，並且可以串流至 Youtube 做直播，或是當錄製完成，編輯後直接上傳到 Youtube，與社群進行分享。

最後介紹 Youtube Gaming 這個平台，透過 Youtube 幫助你成長你的遊戲社群，每個月使用者花了數十億小時在 Youtube 觀看遊戲相關內容，因此 Youtube 特地做了一個 Youtube Gaming，讓玩家有個聚集地。Youtube Gaming App 也提供了 Mobile capture 的功能，你可以選擇任何一個你的遊戲，只需要按下錄製按鈕，他就會開始錄影。你可以加上你的個人頭像，透過麥克風錄製你的聲音，你也可以直接在你的頻道上進行直播。

 

Beyond payments with Android Pay

Android Pay 不單只是個支付系統，而是為了高度提昇店內消費體驗而經過調查，大約只有 45% 的會員卡在申請後被使用
更只有小於 1% 的 coupons 被兌換，這是非常可惜的，因為大家都想要便宜的商品，為什麼會這樣？因為大部分的人都會忘記剪下 coupon、忘記帶、忘記使用… 等。

用戶在意的莫非以下兩點，節省時間、節省金錢，而 Android Pay 如何幫助用戶超越一般支付體驗，又有多簡單去使用它呢？影片中說只要 Tap Tap Done 這簡單的步驟就可以完成付款。

商家所提供的折價卷或是會員卡可以將連結寄給客戶（使用 Deeplink），而客戶收到後只需要點擊 -> 加入 Android Pay -> 確認
就完成了，用戶根本不必去記得任何細節。在付款時 Android Pay 會自動根據你有的會員資格或是 Coupon 去進行折抵，你根本不需要記得任何事情則可以擁有折扣，這真的是太棒了！！

不僅在商店中可以使用，目前也可以用在 搭地鐵、in-Apps 以及 Web線上消費… 等

而目前有哪些國家支援呢？最終目標是希望只要有 Android 的地方就可以支援 Android Pay，不過這個旅程需要一步接著一步慢慢實現，目前只有 US, UK, Australia, Singapore 這幾個國家支援。

 

Lean and Fast: Putting Your App on a Diet

再開始之前先瞭解一下 APK 包含了什麼東西：
App code
– classes.dex : Java bytecode
– libs/ : Native code

Resources
– res/ : drawables, PNGs, JPEGs, layout…
– resources.arsc : styles, identifiers, strings

Misc
– assets/ : 所有不屬於 Android-type resources 的檔案，像是 game data, textures
– META-INF/ : 包含 APK signature
– AndroidManifest.xml

對於 APK 瘦身計劃 Android 也做了一些改善，像是改用 BSDiff algorithm 來優化更新應用程式的大小，在 Play Store 上顯示 Download size 及 Update size，Android Studio build tool 也都了一些優化來減少 APK 的大小，這邊提供了apk-patch-size-estimator 幫助開發者更清楚的知道對於 APK 大小的變化。

除了 Android 本身的改善外，這邊也給開發者一些建議：

Image 的部份
– 使用其他的外部工具優化圖檔，但是要記得關閉 packaging system 中的優化功能 （ disables crunching of images ），因為目前的 build toll 還沒辦法偵測到你是否有另外 preprocess images。
– 使用 Zopfli 或 advpng preprocess PNGs
– 使用 WEBP 格式的圖檔
– 使用 VectorDrawable
– 使用 Shape Drawable

Code 的部份
– 使用 proguard，設定 minifyEnabled = true、useProguard = false 使用內建的 shrinker 清除 classes 但不混淆
– 使用 android-classyshark 來 debug proguard

其他 Resources 的部份：
– 開啟 proguard 後使用 shrinkResources 移除沒用到的 resources
– 加上 resConfigs 用來選擇特地語言, 剩餘的會被移除，要注意 resConfigs 在新版的 gradle 中不能使用在density 上, 除非你只有使用一種density
– 檢查是否有 Sparse resource configs ，以 string 為例, 假設 default config 中有 5 個 string, 其中的一個在 v21 中有再定義一個值, 在這種情況下 v21 的其他 4 個 string 都會是 NULL_ENTRY，如果遇到這種狀況可以使用 android-arscblamer 列出所有包含 NULL_ENTRY 的項目

Native libs 的部份
– 在 Manifest 中加上 extractNativeLibs=”false”, 可以不把 so 檔從 APK 中解壓縮出來, 直接使用 system.loadLibrary 來讀取 so 檔，這樣就不會因為 so 檔被解壓縮出來，使得 user partition 中有兩份 so，造成空間上的浪費，但是使用這個方法的 so 檔不能被壓縮，且需要手動做 page align。

最後在 APK 上能夠依照 解析度, CPU 架構( arm, x86…), Android 版本做 Multi-APK 進一步瘦身。

 

Introducing the Awareness API

Awareness & Location APIs 是現實世界與數位世界的橋樑，讓開發者可以透過 APIs 可以創造對使用者有幫助的 App

講者把 API 分類成三大類

1. Where you are：透過手機上的感應器，可以知道使用者現在在哪裡，提供使用者附近的地理資訊

– Fused Location
結合裝置的 GPS 和 sensors，提供高精確度的地區資訊，像是經緯度的資料
– Geofencing
經緯度加上半徑就形成一個 Fence 的概念，當使用者接近 Fence ，
API 就會利用 callback 通知 App， App 收到後再做對應的應用
– Places API
透過手機的感應器，提供使用者所在位置的相關資訊，他能夠給予語意化的資訊，
比如說你在 Starbuks ，APIs 給使用者的是營業時間資訊

1. What you’re doing：手機就像一個微型的電腦，有著感應器去偵測重力，移動的速度以及在現實世界的方向，透過 API 提供語意化的資訊了解使用者現在在做什麼

– Activity Recognition
透過裝置上的感應器，可以準確的知道使用者現在在做什麼
– Google Fit Platform
讓使用者紀錄運動中的相關資訊
– Sensors API
透過裝置的感應器，提供使用者多樣的 raw data

1. What’s nearby：現在的裝置越來越多，我們期望裝置能夠互相的通訊

– Nearby Messages
讓使用者能夠找到附近的裝置並且分享訊息
– Nearby Connections
發現 local network 的裝置，並且能夠與之建立連線
– Nearby Notifications
可以掃描附近的 becaon 並且提供一個低優先權的通知

這 9 個 API 就像拼圖一樣，可以互相的拼合在一起使用，但會造成電力耗損以及記憶體使用過多的問題，
讓整體的使用者經驗變得很糟，為了解決這些問題，Google 提供了 Awarenesss API 將這些 API 整合在一起。
Awareness API 提供了 7 種 context type 供使用者使用
1. Location：提供經緯度資訊
2. Place：提供語意的地理資訊，比如說在星巴克，咖啡店
3. Beacons：這附近有什麼 Beacons 或什麼裝置
4. Times：現在的當地時間
5. Activity：辨識使用者的狀態，比如說現在正在跑步或是走路
6. Headphones：使用者是否使用耳機
7. Weather：給予現在的溫度 … 等天氣資訊

Awareness API 是由 Fence API 和 Snapshot API 所組成

Fence API 是 callback style 的 API，讓你的 App 可以跟使用者的狀態做互動，比如說使用者是否有插入耳機，使用者是否正在走路 … 等，把這些資訊當作是 Fence，當觸發這些狀態，就能透過 callback 來和使用者互動。講者闡述如何使用 code 來描述一個情境：

AwarenessFence areaAroundStore = LocationFence.in(STORE_LATITUDE,STORE_LONGTITUDE,1000,0L);
AwarenessFence duringDriving = DetectedActivityFence.during(DetectedActivityFence.IN_VEHICLE);
AwarenessFence openHours = TimeFence.inDailyInterval(TimeZone.getDefault(), 10 * HOURS_IN_MILIS, 18 * HOURS_IN_MILLIS);
AwarenessFence drivingNearStore = AwarenessFence.and(areaAroundStore,duringDriving,openHours);

上述的 code 所描寫的情境是，開車經過藥局(給予經緯度和半徑)，並且還在營業時間內(早上 10 點到下午 6 點)

Snapshot API 是 polling style 的 API，目的是讓 App 知道使用者現在的狀態，比如說知道使用者現在的所以在地點以及天氣，
例如：

PlacesResult placesResult = Awareness.SnapshotApi.getPlaces(googleAPiClient).await();
WeatherResult weatherResult = Awareness.SnapshotApi.getWeather(googleApiClient).await();

 

Behind the scenes: What’s new in Android accessibility

Android N 改善了既有的輔助功能(Accessibility)，也提供了一些全新的輔助功能，這些功能讓有殘疾的人士或是某些不方便操作的特殊情況能夠大為改善。美國的殘疾人士高達總人口的 20%，包括了各種障礙，但輔助功能不只是針對這些殘疾人士所設計的，我們每一個人都有機會利用到輔助功能，舉例來說雖然不是瞎子，但是在開車的時候我們也無法看手機畫面，在吵雜環境下，我們沒辦法聽清楚手機發出的聲音，也沒辦法清楚的說話命令手機，我們若是手提重物，也無法輕鬆自由的觸控螢幕，這些都是一般人也能夠利用輔助功能的情境。

目前已經存在的輔助工具有：
– Talk Back (將螢幕上顯示的內容讀出給視覺障礙人士使用)
– Braille Back (將內容顯示在點字機上，並且提供盲人輸入介面)
– Switch Access (提供方法使用很少的實體按鍵來達到螢幕操作)
– Voice Access (用語音的方法來提供低階的操作)

除了這些工具之外，已經提供下列功能：
– 文字放大
– 螢幕放大鏡手勢
– 螢幕顏色反轉
– 螢幕顏色校正
– 高對比度文字顯示
– 字幕顯示

在 Android N 中額外提供了
– 顯示大小設定 (可以放大UI元件比例，類似於launcher中的icon放大)
– 單聲道合併輸出 (讓只聽得到單邊的聽障人士，可以把雙聲道合併後輸出到單邊)
– 觸控事件發送 API (Gesture Dispatch API)
– 語音控制 (Voice Access)

以下針對Gesture Dispatch API介紹：
此 API 提供開法者以程式化的方法送出觸控操作，如此一來便能夠開發螢幕掃描、頭部追蹤、眼睛追蹤等控制方法來提供裝置的操控方式，其中一個 demo 演示了使用螢幕掃描來操作螢幕，所有動作包括點擊、拖移等，都由一個實體按鍵完成，另外一個 demo 是一間叫 Sesame Enable 的公司來示範，他們使用 Guesture Dispatch API 所開發的產品，提供了頭部追蹤控制螢幕上的游標，並且同樣的可以簡單完成螢幕點擊或是拖曳等行為。甚至可以用頭來玩 Candy Crush。

以下針對 Voice Access 介紹：
與語音助理不同，Voice Access 提供了一些低階語音命令，可以協助你用語音完成所有的螢幕操作，他提供了包過點擊、滾動等低階命令，若是操作對象有文字內容的話，可以直接說出要操作的對象，另外在操作對象沒有文字內容的時候，螢幕上也會提供可點擊、操作元件的編號，讓可以應用的範圍更為擴大。

在 Google Accessibility 團隊開發 Voice Access 的時候，我們使用了一套流程來改善 UX。
影片中也分享了他們所使用的方法。此方法分為以下五個步驟：
1. 提出目標 (拿 Voice Access 為案例的話，我們希望達到”易於使用”、”易於學習”)
2. 提出研究與假設
3. 針對這樣的假設提出一些改善的方法
4. 實際上導入這樣的方法，並針對使用者行為作觀察、測試
5. 檢討並跟團隊分享、進一步改善設計
若需要進一步改善的話可重複本流程

除了這個流程外，我們也使用了以下的方法來改善 UX
– 形成性研究 (進入實際應用面來瞭解使用者)
– 內部人員測試 (初期容易快速排除問題)
– 可用性研究 (近距離觀察使用者行為，並對使用者提出問題以了解。容易觀察到目前產品的瓶頸、限制，用影像記錄使用者行為與反應。其限制是在測試空間中，而且觀察時間較短)
– 使用者日記式記錄 (要求測試使用者記錄每天使用上碰到的問題與心得)

以下提供我們進行可用性研究時的一些細節：
– 把開發時遇到與使用者有關的所有問題記錄下來
– 針對這些問題，設計一些方法來讓您的使用者幫助你回答這些問題
– 找朋友或家人測試，並準備一個舒適的環境，備有錄影設備與記錄人員。
– 要求使用者完成您所設計的任務，並且瞭解使用者為何這樣使用與選擇。
– 將影片中有趣、重要的發現剪輯節錄出來分享給您的團隊以討論、進一步改善

 

What’s new in the support library

Spport library 最新版本為 24 alpha 3，除了 bug 的修正之外還包含了需多新功能。

1. 改善 Fragment 的生命週期，Fragment transaction 多了 synchronize commit api commitNow()。
2. 在 Notification 方面，多了對話訊息的新樣式，包含版面變大，可以顯示多條訊息，並且也支援 Android Wear 2.0。除此之外，新增 areNotificationEnable() api 用來 query 用戶是否把 app 通知關掉，不過這只支援 API 19+，API 18 以下的裝置一律都會回 true。getImportance() 則是可以用來 query 通知優先權的設定。
3. 在 Medai frameWork 新增 MediaBrowserService、MediaBrowser 優化跨裝置間的多媒體瀏覽與播放流程。
4. 新增瀏覽 web view 的新介面，Custom tabs 可以自動嵌入 web view，與瀏覽器共享 cache、cookies，preload 功能讓頁面顯示更快，custom tabs 還可以 customize UI，包含 toolbar color、action for buttion or overflow menu、過場動畫。這個新介面只支援 API 15 以上的裝置。
5. VectorDrawable 與 AnimatedVectorDrawable 只支援 API 21 以上的裝置，這一版增加 xml 寫法的彈性，可以直接將 VectorDrawable 合併到 AnimatedVectorDrawable 裡，減少 xml 的檔案數量。Android studio 裡的 Vector Assets Stoudo 可以幫忙將 SVG 轉成 VectorDrawable。API 20 以下的裝置要使用 VectorDrawable 有兩種:
   • Gradle solution：在 build apk 時 gradle 會自動幫你檢查最小 sdk 版本，當版本小於 21，這時 gradle 會依照不同解悉度自動將 VectorDrawable 轉檔成 PNG，不過這個解法不支援 AnimatedVectorDrawable，而且產生的 PNG 檔案會讓 app 檔案變大。
   • VectorDrawableCompat and AnimatedVectorDrawableCompat solution：
     這兩個 new class 是在 subpport lib 23.2 加入的，這個解法單純只需要用到 xml 檔案不需要額外新增任何 PNG。

   在 gradle 設定 vectorDrawbles.useSupportLibrary = true 可以將 gradle solutuon 關掉。

6. 關於 VectorDrawableCompat and AnimatedVectorDrawableCompat 的用法如下：
   • 可以透過 static method creat() 去拿到 drawable。
   • 在 xml 裡如果是用傳統的 set drawable to src 可能會在舊裝置上造成 exception，必須使用 ImageView 的新屬性 srcCompat 來設定 reference vector drawable，在 prgraming code 裡則是可以透過 setImageResource()。
   • 除了 ImageView 之外，其他 view 如果也想 reference VectorDrawable resource 則必須在 Activity 裡宣告 AppCompatDelegate.setCompatVectorFromResourceEnabled(true)，透過這樣的方式讓原本的 DrawableContainer 可以 reference 到 vector resources 與 animated vector resources，不過這個用法還在開發階段，可能會造成 memory leak，不太建議使用。
7. Appcompat 裡新增 Night Mode，可以根據時間轉換 light theme 或是 dark theme。除此之外，Appcompat 也在 ColorTateLists 裡新增了 theme 屬性。
8. 新增 Bottom Sheets dialog，Bottom Sheets dialog 分成兩種樣式，一種是 persistent 需要搭配 coordinator layout 使用，另一種則是 modal，只需要將原本繼承 DialogFragment 改成繼承 BottomSheetsDialogFragment，其他用法都跟普通的 dialog fragment 一樣。
9. 改善 AppBarLayout 的陰影效果，一種是 always elevated，另一種則是在 CollapsingToolbarLayout 收起的時候才會有陰影，
   目前還沒有支援 CollapsingToolbarLayout 不管收起或是展開都有陰影效果。
10. Support library 要放棄支援 API 9 以下的裝置，大概會減少 130 個 methods。
11. 隨著時間的演進，support library 新增了許多功能，為了避免 library 過於肥大，決定將 support library 切割成不同的 module。

 

Raiders of the lost app: Google Play secrets to launching and getting discovered

拯救 app 的攻略: 在 Google Play 發佈和拓展人氣的秘密

本篇在說明如何透過 Google Play Developer Console 提供的工具來快速拓展 app，如 Google Beta Testing 能讓開發商快速部署測試計劃，測試的受眾在 Google Play 上看到測試計劃的入口後可自行決定是否參與，不必擔心因測試的品質而影響整體評分，在過程中對 app 的反饋會以私訊傳遞，評分也不會列入計算，目前在 Google Play 上排名前 1000 的 apps 中，有 60% 都使用過 Beta Test 功能。

另外 Google Play Developer Console 也加入了排程發佈管理，以往上傳 apk 後需要等待一段未知的處理時間使用者才能真正下載到新的版本，對於需對外公布準確更新時間的遊戲開發商是個未知數，現在可以預先上傳 apk 並設定真正能下載檔案的時間了。

在後台也可以依管道或地區查看安裝成效，以評估不同渠道的廣告需要如何調整；在定價方面，你可以使用定價範本選定基準的價格與幣別，會自動以當日匯率與各地的定價習慣換算成其他幣別，如歐洲地區常見加上稅金後以 9 結尾的價格，日幣和印尼盾則習慣以 0 結尾的數字表示。

還有一件好消息是，Google 發佈了 Play Developer Console 的 mobile app，日後可以更即時的回覆使用者的評論和查看資訊了。

Google Play 上面的 app 資訊目前也可以做 A/B 測試了，你可以同時進行五個本地實驗，替換不同的 app icon、截圖、說明文字等，實驗哪種版本最容易吸引使用者下載。例如這是 Angry Birds 實驗不同 icon 帶來的下載量百分比。

影片最後分享如何在 Google Play 上讓你的 app 更容易被用戶看見，app 名稱需簡短有力、設定關鍵字、或是買相關分類的關鍵字廣告等等，在熱門排行榜的各個分類也分享了裁定的標準，整理如下：
熱門免費/付費項目：看的是過去七天內的安裝量，排行每日更新以列出此刻最熱門有趣的 app
最新熱門免費/付費項目：過去 30 天內新上架的 app 中，在過去七天內的安裝量，排行每日更新
竄升速度最快：過去 30 天內安裝數的增長幅度
最高營收：過去七天內的營收(可能不是完全準確，非透過 IAB 付費的就計算不到)，排行每日更新

 

Designing for driving

Android Auto 是 Google 專門為汽車所推出的車用系統，最大的特色是需要連接手機使用，而在 Android Auto 上則不會保存任何數據，包含音樂、聯絡資訊等個人資料都是來自於手機。只要手機保持最新狀態，Android Auto 就能保證正常運作。

現今人們待在車上的時間越來越長，我們發現即使在這段時間裡所有人都還是會想要繼續使用數位產品，這也衍伸出一個重要的安全問題，當你在車上使用手機打字或是觀看訊息都很容易造成危險，因此，如何為 app 設計一個適合在車上使用的 UI 介面就變成一件很重要的事。

針對車用 app，我們可以將介面設計的簡單，把 layout 與 content 變成可預測的，讓它們具有一致性，再透過 UI 不分層的設計讓用戶可以快速完成執行動作。舉例來說，聲控是最好的的工具，它可以讓用戶不需要有視覺或是觸覺轉移就可以直接得到想要的內容。

在車用設計上，UI 的字型一定要清楚，icon 的觸碰範圍要大，色彩對比要高，讓用戶不管是白天還是晚上都能看得清楚。因為希望用戶都能熟悉介面不需要重新學習操作流程進而減少注意力的分心，因此 Andorid Auto 希望每個 app 的操作介面都會是一樣的，這樣的想法反而跟在設計手機 app 上完全相反。例如 Google play music 與 spotify 在 mobile 的 UI 差異很多，但是在 Android Auto 上，除了 icon 或是 button 樣式不同之外，UI 架構幾乎一模一樣。

車用系統最大的困難點在於每台車的螢幕裝置都不相同，不過 Android Auto 可以將 UI 轉換成換成一致的效果，所以不管是開發者或是設計師都不需要擔心 UI 會因為不同的裝置而受到影響。

未來 Android Auto 會繼續往創新領域發展，例如：車子監控系統，就像電動汽車可能會需要監控電池狀況，為了這種特殊需求去設計一套新的 UI 介面。

 

Multi-Window mode

Android N 以上支援 multi-window 功能，支援在裝置螢幕上同時顯示多個應用程式畫面，共分為三種模式
– Split-screen mode: 手機裝置可以分割成上下或是並排兩個畫面
– Picture-in-picture (PiP) mode: 適用於多媒體播放應用程式的子母畫面
– Freeform mode: 可自由調整畫面的大小與位置

multi-window 模式下不會改變原本 Activity 的 lifecycle，使用中的應用程式會進入 resume 狀態，而其他顯示但未使用的應用程式則會進入 pause 狀態，若為影片播放應用程式建議應該把 播放/暫停 影片時機點做在 onStart/onStop 以確保 multi-window 模式下，未被使用但可顯示的影片播放程式不會中斷播放。

當系統記憶體不足時，會根據優先性的分數來刪除 process，在 multi-window 模式下未使用的應用程式位於 z 軸下方 (z-order)，越下方的分數越低，所以正在使用中的應用程式優先性最高最不易被系統刪除。

若 Activity configuration 沒有強制螢幕方向時建議設定 configChanges 參數 screenSize|smallestScreenSize|screenLayout|orientation 否則在 multi-window 模式下，螢幕轉向時 Activity 會重新啟動
耗費時間長，可能導致轉向畫面呈現不流暢。

APIs 略述如下
Resizeable activity attributes
– resizeableActivity: 設定是否能支援 multi-screen，預設為 true
– supportsPictureInPicture: 設定是否支援 PiP 模式，如果 resizeableActivity 為 false 則會忽略

Adjacent：啟動 Activity Intent flag 設定 FLAG_ACTIVTY_LAUNCH_TO_ADJACENT 在 multi-window 下系統將儘量將開啟的 Activity 在貼近呼叫畫面的地方顯示

Layout styleable
– defaultWidth/defaultHeight: 預設畫面寬/高度
– gravity: freeform mode 下預設的位置
– minimalWidth/minimalHeight: 最小畫面寬/高度

Resizing background drawable：multi-window 模式下呈現應用程式畫面因為讀取資料等原因延遲時會顯示背景色，背景可在 style 中屬性 windowBackground 設定或是預設屬性 windowBackgroundFallback

Activity
– inMultiWindow(): 是否為 multi-window 模式
– inPictureInPicture(): 是否為 PiP 模式
– onMultiWindowChanged(): 進入或離開 multi-window 模式 true/false
– onPictureInPictureChanged(): 進入或離開 PiP 模式 true/false
Activity.overlayDecorCaption: 在 freeform 模式下設定顯示畫面的標題
ActivityOptions.setLaunchBounds: 設定顯示畫面的大小與位置

Drag and Drop: 拖放功能可在不同應用程式間拖拉資料
– View.startDragAndDrop()
– View.updateDragShadow()
– View.cancelDragAndDrop()

UX Design: 應注意當應用程式切換為 multi-window 時的畫面大小對使用者的影響

 

Introducing Google Developer Certification: Become an Associate Android Developer

這篇在教你怎麼找工作 (?)、如何縮小面試者與求職者之間認知的差異。

對於面試者來說，要如何知道求職者符合資格，可以勝任這份工作，對於求職者來說，要如何展現自己的能力並且被認可，講者介紹了 UDACITY 的 Nanodegree 與 GENERAL ASSEMBLY 的 Android Immersive 這兩個平台，他們以就業為目的，教你如何開發應用程式。

2 年前在 IO14 提供了第一個在 UDACITY 的 Android Fundamentals 教學課程，有約 300000 人上這門課程。而在去年 IO15 宣布 Android Nanodegree，去年年底有了第一批的畢業生，這些課程大約要花 6~12 個月去完成，這些完成的學生裡面有些甚至不用面試就找到工作，有些也進入 Google 工作，去年也有提供 Android for Beginners 的課程，可從無到有學習，對於 Android Fundamental 與 Android Nanodegree 來說，你需要有兩年左右的程式經驗，因此他們目前補上了從 Android Beginner 到參加 Android Nanodegree 的這段差距，你可以透過參與他們所提供的 16 項課程來補足這段差距。

Google 推出 Google Developer Certification，提供面試者與求職者一些標準，以及幫助全世界的開發者建立高品質的 Apps 以及獲得工作。與一般的考試認證不同的是，他不是考你一些觀念或是做些選擇或問答題，這個認證是基於分析你在工作任務上的績效來給予成績，基本上你需要建立你的 App 以及展現你的技能來通過這個考試。

目前與 Android 相關的 Certificate 是 Associate Android Developer，他是設計給入門開發者的一個 Certificate。
考試將會在七月，所以現在就可以開始準備這個考試。你可以透過上 Android Fundamentals 這門課，可以幫助你準備考試，上課不只是看影片而已，還需要實際動手做，讓你可以更熟悉環境。網站：https://g.co/dev/certification

 

What the Fragment?

不少開發者反映在使用 Fragment 的時候常常會有許多超出預期的行為造成很多困擾、還有人提暢沒有 Fragment 的架構，而到底為什麼要使用 Fragment 這其實是有歷史典故的，最起初 Activity 作為一個平台的進入點，通知你系統的各種情況讓你可以控制 back、restore、destroy… 各種狀態。

接下來 Activity 隨的時間變得越來越大和複雜，你會發現有些部分程式是可以抽出來重複使用的，因此 3.0 前有了 LocalActivityManager 用來讓每個 Tab 切換時，可以讓子頁面的 Activity 進行切換，不過這樣的架構帶來了許多奇怪的程式碼，接著某個版本(3.0)推出，我們就不再繼續使用它了。

接下來大螢幕裝置開始出現，大螢幕也代表著大問題，例如有效率的利用大螢幕顯示原本小螢幕的畫面，所以有個將小畫面變成元件，並可以重複使用的想法，最終造就了 Fragment 的出現，最一開始 Fragment 想要解決以下幾個問題
1. 責任越來越多、複雜度越來越高的 Activity（EX：在不同螢幕大小管理不同的子頁面）
2. 修正掉奇怪的 LocalActivityManager
3. 封裝頁面導向狀態（EX: back 時子頁面切換）
4. 回復狀態 (Restore Back State，EX: DialogFragment 切換直橫屏)
5. 簡化 master/detail 類型的 UI
6. 支援 View Pager、Child Fragment

所以到底什麼是 Fragment 呢？由於在 Layout 當中有 Fragment Tag，所以 Fragment 比較像是一種 View 的集合嗎？我們認為 Fragment 的設計不該只是 View 的集合，抽象概念應該是趨近於 Activity 才對，我們期望在 Android 中擁有不同層級的抽象概念、並擁有不同的責任，譬如在 Android 中 Higher level 到 Lower level 為 app > widget > view > content。

Fragment 如實反映了各種 Activity 的生命週期，概念上應該要高於 View 而去擁有或是實做 onClickListener 介面，來控制 UI 由於 View 沒有 Fragment 擁有的概念和資訊，Fragment 概念上比較趨近於 策略層(policy layer)，而根據這些 lifecycle 去管理 UI，所以別把 Fragment 單做成一般的 ViewGroup 或 Layout Resource 使用。

Fragment 還有一項很重要的功能就是 Save State，雖然演進的過程中修正了很多錯誤，不過現在於 super.onCreate 時已會幫你 restore Fragment 以及 ChildFragment 的各種狀態，讓你不用花心思處理這方面的問題，只需要處理 Fragment 的線性生命週期
以簡化你的程式碼。

 

Make shinier, faster mobile games with Vulkan

Vulkan 與 OpenGL ES 3.1 的 features set 相似，都支援 compute, geometry, tessellation shader，除此之外 Vulkan 有明確的 API ，幾乎所有 rendering pipeline 中的物件都可以讓開發者直接控制，記憶體的管理也是由開發者來負責的。

Vulkan 也帶來了一些新的物件及概念，其中一項令人驚訝的就是 Validation Layers，他是一個跨平台的 API level debugging and error checking tool，大致上的用法就是在專案開始時就開啟，一直使用到發佈前，如果使用的 IDE 有支援中斷點的話，就能用中斷點及 call stack 來查是在哪個位置觸發 validation message 的。

當你從 OpenGL ES 轉換到 Vulkan 時，必須注意以下事項：
1. Vulkan 坐標系是由左上為起點，且包含了 rendering, texture coordinates
2. 大部份的記憶體管理都要用開發者來處理，像是 Buffers, Images, Pools ….
介紹 Vulkan 的元件以及要注意的地方：
1. Command Buffers ： 使用前必須先從 command pool 分配出來，接著就能在 buffer 中記錄 command，submit 時會送到與 command pool 同一個 queue family 的 queue。 以下為使用時應注意的：
– 建議使用一個以上 command buffer 但盡可能的降低數量以逹到最佳效能
– 在 multiple thread 使用同一個 command buffer 會有 thread-safety 的問題，但如果是不同的 thread 用不同的 command buffer 就不會有這個問題
– 可以把多個 command buffer 丟給同一個 submission thread 提交
2. Queues
– 每個 queue 都屬於一個 queue family 且 queue family 裡的 queue 是有數量限制的，不是每個 queue 都是通用的， queue 的功能將由 queue family 決定。由於使用多個 queue 會有同步的問題，如果需要同時進行 graphic 和 compute，那最好找兩個都支援的 queue family，Android 中至少有一個這種 queuefamily。使用時要特別注意 queue 的數量，如果超出了裝置限制，可能會 crash。
3. Pipeline
– pipeline 是一個用來控制整個 rendering process 的資料結構，pipeline 大部份的屬性在編譯後就沒辦法變更了，只有一些像是 viewport, scissors, blend constants… 能夠透過 command 去變更，能擁有的 pipeline 介於 1000 ～10000，且可以被 cache。
4. Descriptor Sets
– descriptor 就是 binding numbers 所以可以稀疏地使用像是 {1, 5, 13…} 但建議不要讓間隔太大，因為沒有用到的號碼還是會佔記憶體的空間，而且 binding number 及 descriptor sets 都有最大值的限制，超過會造成 crash，另外要注意以下兩件事
– 一但 bind descriptor sets 就不能再對他做任何的更新，直到下一次的 command buffer
– vkCmdBindDescriptorSet 中的 firstSet 是對應到 PipelineLayout 中的 pSetLayout 而不是 pDescriptorSets。
5. Framebuffers
– 持有 vkImageViews 的陣列，且每個 vkImageVIews 都有一樣的高度跟寛度，和 OpenGL ES 一樣在使用之前必須將 multi-sample 轉成 single-sample。
6. Render Pass
– 由多個 subpass 組成，subpass 會去 reference 到 framebuffers，使用時必須清楚的知道 subpass 被處理的順序，如果有需要用到已先前的 subpass 記得要先做 preserve 的動作以避免被清掉。（render pass, subpass, framebuffer 的關係可以看圖比較清楚）
7. Image Layouts
– image layouts 的行為會因為 GPU 而不同，只有 VK_IMAGE_LAYOUT_GENERAL 是通用的，但他可能會造成效能的問題，若要確保有最佳的效能，就必須要先預設每個 GPU 都需要特有的 image layout ，並處理好不同的狀況，一但 image layouts 出現錯誤， Validation Layers 會馬上通知你。
8. Pipeline barrier
– 在 render pass 中必須先定義好 subpass 的順序，除此之外 render pass 只接受 vkMemoryBarrier 及 vkImageMemoryBarrier。
9. Memory Management:
– 做好 bound checking
– 如果有做寫入的動作就要記得做清除的動作
– 如果 command buffer 做讀取的動作
– 如果 allocate memory 時帶有 VK_MEMORY_PROPERTY_HOST，就需要做清除
10. Shader
– 使用 shaderc 或 glslang 編譯成 SPRI-V，且同一份 shader 的程式碼可在 desktop, mobile 中使用，除此之外 shader 的變數 uniform 也有以下比較大的改變：
– 必須使用 uniform buffer
– 不能單獨使用 uniform，必須搭配 interface blocks 使用
– interface blocks 中的 layout 必須是 std140

對於 Performance 的建議
– 最小化 host to GPU transfers 特別是行動裝置
– 減少 round trips
– 儘量不要 starve GPU
– 在 Render Loop 使用剛好的 multiple frames，且平均分配 buffers，但這代表你必須自己處理 frame rate throttling，另外要注意的是避免使用 vkQueueWaitIdle。
– 使用 Push Constants 可以快速的更新 shader 的值，不需要 buffers, descriptor，但一次只能 push 128 bytes，且每個 shader 只能有一個 push constants，要注意的是他的 sizes, offsets 都要是4的倍數。

從 Desktop 移植到 Mobile
– Vulkan API 擁有很高的相容性，基本上從 Desktop 移植到 Mobile 需要改變的只有 WSI ( Windows system integration ) 以及 swapchain，但每個 GPU 所支援的 images, buffer 的格式又相當不同，特別要注意一點的是 3 channel 的支援非常有限，所以建議寫個小工具來查詢裝置的 properties。
– 關於 Compressed textures 最好不要假設 OpenGL ES 所支援的 Vulkan 就會支援，在這個部份 Android 有個很棒地方就是所有 Android Vulkan implementations 都會支援 ETC2，也有部份支援 ATSC，但 Desktop 實質上支援的只有 BC，他們可能有些更複雜的名稱。
– 有些 GPU 可能需要 Image layout transitions，所以最好假設他們都需要，這點非常的重要。

 

Android battery and memory optimizations

相信每個使用者都不希望在一天結束之前，手機就因為沒有電力而無法使用，在這場演講中，要探討的是如何最佳化螢幕關閉時電力的使用，螢幕關閉時電力消耗的來源分成兩種 CPU 和網路使用，以 CPU 來說，取決於 wakelock 的次數，而網路方面則是做一些網路傳輸或是同步資料的行為，不管是從暫停到喚醒或者是網路傳輸都會需要一定的電力消耗成本，如果在背景中很頻繁的使用這兩者，勢必會造成一定程度的電力消耗。

為了減少背景使用的電力消耗，提供三個設計原則給開發者做參考
1. Reduce
減少不必要的背景使用
2. Defer
如果有必要在背景執行活動，試著將這個活動延後到充電中執行
3. Coalesce
如果不能使用 defer 方式來做，試著把一群工作集合在一起執行，減少 wakeup 的成本，建議可以使用 JobScheduler 做到 Coalesce，在接下來的內容會提到。

在 Android 上，有兩個系統的機制能夠減少背景電力的使用 Doze & App Standby。
Doze (Mashmallow)
如果處於靜止狀態並且經過一段時間後，Android 就會認為現在沒有使用者在使用該裝置，讓系統進入 Doze mode 減少電力消耗。進入 Doze mode 會限制以下行為
1. 無法使用 Wakelocks
2. 無法使用網路資源
3. 延後 Jobs/Syncs
4. 延後 Alarm
5. 不會啟動掃描 GPS 和 Wifi
不過進入 Doze mode 後，會有一段一段的 maintaince window，讓 App 集中在這短在的時間使用資源，進而減少電力消耗。

Doze (Android N)
和 Mashmallow 不同的是，N 在非靜止的狀態下也可以進入 Doze mode，比如說手機放在口袋裡並且螢幕關閉的狀況，非靜止狀態 Doze 的限制就只會剩下
1. 無法使用網路資源
2. 延後 Jobs/Syncs 的執行
靜止狀態 Doze 的限制跟 Mashmallow 是一樣的，但只有程序上有一點不同，一開始的 Doze 只會限制網路存取和延後 Jobs/Syncs 執行，過了一段時間後，才會進入正常 Doze 全面限制的狀態。

App Standby
若在以下條件並未發生，過了一段時間後會進入 Standby
1. App 有 foreground service
2. App 有 notification ， lock screen
3. App 被使用者明確的啟動
相較於 Doze 模式，Standby 限制的狀況比較少，
1. 網路存取受限
2. 延遲執行 sync/job

在 Doze & App Standby 最佳化 App
講者在此分成三個層面說明
1. Foreground Services
在 Doze 和 Standby 是豁免的
2. Alarm APIs
Alarm 相關的活動會被延後執行，但也有新的 APIs 可以讓你在當下就被執行，請參考
https://developer.android.com/training/monitoring-device-state/doze-standby.html#whitelisting-cases
3. Whitelist
若需要網路或短暫的 wakelock 資源，使用者需要額外在設定中把 App 加入白名單

講者在此提到兩個使用情境，情境一，即時通訊 App 在 Doze 或者是在 Standby 的情況下要怎麼處理訊息或電話？講者提到可以使用 High-priority GCM messages，可以短暫取得 wakelock 和網路存取的資源。

情境二，音樂 App 在 Doze 或是 Standby 模式下會暫停播放嗎？講者回答說，音樂服務他是一個 Foreground Service，在 Doze & Standby 是豁免的，並不會暫停播放。

另外，如果沒有 Google Play Service 的裝置，就會把 Doze & App Standby 關掉，所以白牌手機就沒辦法使用 Doze & App Standby 帶來的省電效益。

Memory Optimizations
在低記憶體的狀況下，這時候如果又收到 implict broadcast 會造成讓系統負擔更為加重，比如說，打開 wifi 的時候，系統會發送 CONNECT_ACTIVITY_CHANGE broadcast，同時間很多 App 聽到這個 broadcast 就會開始在背景做事情，接著你就會感覺到裝置頓時變得很慢。為了減少上述的狀況， Android N 減少三個 broadcast 分別是
1. CONNECTIVITY_CHANGE
即使在 Manifest 定義中要求註冊該 broadcast，Andorid N 也不會發送這個 broadcast，但要注意的是 runtime 註冊的情況下還是可以收到，如果想要在 non-runtime 情況下可以使用，依然可以用 JobScheduler 做到類似的功能
2. NEW_PICTURE
3. NEW_VIDEO
不在收到或傳送這兩個 broadcast，但可以使用 JobScheduler 來替代

JobScheduler APIs
JobScheduler 的目的在於把背景的活動集合起來，減少 wakeup 的成本，他能搭配以下四種方法使用
1. 時間狀態
2. 網路狀態
3. 充電狀態
4. 是否正在使用狀態
來驅動什麼時候該啟動 JobScheduler。另外，因為他的 API Level 是 21，在 21 前建議可以使用 Firebase JobDispatcher 來達到一樣的目的。

Battery Diagnostic Tools
1. Batterystats in bug report
簡述電力使用狀態
2. Battery History
3. Battery Historian (https://developer.android.com/studio/profile/battery-historian-charts.html)
將 Battery 的狀態轉換成 GUI 的方式呈現

 

Google Cast & Android TV: Building connected experiences for the home

現在的電視節目很多都是重播內容，常常因為時間的關係找不到自己想看的東西，Google 希望以 Chromecast 來提供一種隨時都可以輕鬆找到自己喜歡的內容的娛樂方式，目前已經可以很簡單地把行動裝置上的內容延伸到接著 Chromecast 的電視，而行動裝置的多媒體娛樂不會再受到小螢幕的限制，這些內容都是由您可能已經很習慣使用的軟體所提供的，而且對於使用者來說 Chromecast 不會有使用門檻。

Android TV 包含了 Google Cast 的功能，所以除了可以用遙控器來控制外，還能很簡單的從各種移動裝置來控制，它上面跑的不是各家電視商自行客製化的系統，實際上他就類似於一個 Android 系統，所以在更新版本的時候不會造成什麼問題，更新後也能取得 Android TV 最新的功能。

開發者用的 API 都跟在手機上的一樣，工具也都一樣，目前市場上已經有很多電視盒上面跑的就是 Android TV，無論他的內容是從衛星、網路來還是第四台，所以他們都能安裝、相容現有的 app，立即體驗到智慧型電視的功能，越來越多的電視開發商都加入 Android TV 的生態圈，例如小米即將上市的小米盒子，提供了 4k 高畫質的輸出能力，同時也提供了遊戲控制器，讓你可以輕鬆在電視上玩 Android 遊戲。

針對 Android TV 功能，Android N 中強化了在不同 App 間切換的處理，讓切換可以更順利，同時你可能會想要同時觀看不同的內容，使用不同的軟體。Android N 可以支援這樣的 Picture in Picture 模式，要支援這個功能，只需要在 AndroidManifest 中加上這個 capability。

Android N 也支援錄影功能，甚至也可以支援排程錄影，若想要支援錄影功能，只要在你的 App 中利用 Recording API 就能達成。

Android N 支援 HDR (High dynamic range) 可以讓內容的呈現更為真實、色彩更為鮮豔、自然，電視系統開發商將可以支援的 HDR 解碼協定提供給系統，在內容提供商、App 開發人員需要知道的時候，有 API 可以共查詢，來決定要提供哪一種內容格式。

 

Android Auto: The Road Ahead

在 2014 年就發佈的 Android Auto 目前已在 40+ 的車廠總共推出 100+ 種車款上搭載，今年 Android Auto 在 19 個新國家實際推出，但大多數仍是歐美地區。

在去年一整年 Auto team 接到很多 user 的需求建議，統計數量第一名的需求是希望由 OK, Google 達到完全的 Hands free，針對這點 Auto team 設計了一套針對車用情境的新體驗，第二名是 Waze 這個用來看即時路況的 App 支援，當然沒什麼問題的在今年也加入了車用介面的 Waze 支援，第三名是用戶希望連接 Android Auto 時手機是能放在口袋等其他地方的 Wireless 功能，這方面新版的 Auto 加入了在同一個 Wifi 環境下可以達成的功能。

接下來講者 Demo 了仍在試驗性的大螢幕版本 Android Auto，可以在同一個畫面下播放音樂，觀看氣象等，還有簡單的示範如何使用語音訊息回覆，語音導航，因為在車上比較容易聯想到的應用就是音樂播放，講者開始介紹基礎的 Media App 開發知識，例如 Media Session 的使用時機與釋放時機、加入 Voice Support 的方式、如何利用 Metadata 物件包裝歌曲資訊傳送資訊給 Auto 與播放狀態的覽視等。

在 Android Auto 上設計 App 有些特別的 UI 規則必須遵守，例如 Navigation 不可超過三層，當然 Material Design 的觀念也可以使用在 Auto 的 App 設計上，影片中視範了修改 colorAccent、colorPrimary 等值的作用位置等，課程的最後很簡單的介紹了幾個今年推出的新 API 使用方式。

 

Introducing Nearby: Physical proximity within and without apps

介紹 Nearby：偵測附近的 apps

向來我們透過 Wi-Fi、3G、藍芽、超音波(Chromecast 的配對方式) 等技術來傳遞資訊，Google 在去年推出了 Nearby API，讓 Android 裝置能互相或與 iPhone 在短距離互相通訊。原理是當你使用 Nearby API 時，會分配一個短暫的配對碼到設備上，接下來 Nearby API 會透過各種可利用的方式(藍芽、低功耗藍牙(BLE)、超音波)尋找附近相同配對碼的設備，如果找到了，就可以交換資訊，有大小限制不適合傳輸影片、圖片類。

Nearby API 也可用來掃描 Beacons，僅需 Location 的權限不再需要 BLUETOOTH_ADMIN 權限，當掃描到 Beacons 時，即使你的 app 在背景甚至被系統回收都可被喚起。

當 Nearby API 偵測到附近有任何 Beacons 或裝置是你可以前往做些事情的，會透過 notification 通知你，例如偵測到附近有公車站的 Beacons，會提示你是否有搭公車的需求，當點擊通知欄時會自動關聯相關的 app 並喚起，若沒有相關聯的 app 則會連至 web。

 

Making Android sensors and location work for you

透過感應器與定位的應用，可以為使用者帶來更好的 user experence，我們要如何建置具有良好品質的情境體驗 app，可以從以下的四個方向開始說起：

1. 覆蓋率：對於定位，不管是在室內、室外、世界各地都應該要可以找到，而 Google 也一直持續努力的增加地圖資料庫的覆蓋率。
2. 準確性：從宏觀來看，全球定位系統必須非常準確，同時用戶也會希望系統可以準確的紀錄活動，例如：當在車上抖腳的時候不會想被誤會成是在騎腳踏車。
3. 延遲性：定位資訊則應該要立即顯示，並且要可以完整紀錄所有活動。
4. 電力：電力則是跟準確性與延遲息息相關，當電力充足時，我們有更多時間可以做運算來提高準確性，也可以接收更多訊號來來減少延遲性。不過當續航力受到影響時，用戶一定會馬上刪除一些消耗電力的 app，所以如果為這些情境應用 app 來降低使用電力，也是 Google 一直在努力改善的問題。

關於 Android 感應器：
在新增 Android 感應器時來增加覆蓋率時，常常會遇到很多困難，原因是因為開發團隊希望在整個生態系中都可以維持一致的 user expericence。例如：開發中的國家希望 Android 把加速度的 z 軸拔掉，只留下 x、y 軸 來感應直向與橫向，藉此來降低開發成本。相反的，在已開發的國家又希望可以提高加速器的動態範圍，因為這可以幫助開發 safety app，問題是，以上兩個目標是互相矛盾的，感應器如果只支援兩軸是無法提高動態範圍。在增加覆蓋率時，我們必須確保所有的 Android 傳感器可以勉強維持硬體最大可見度，同時確保 app 開發者在整個生態系統中是使用一致的 API。

過去幾年裡，Android 每年都有固定的新增幾種感應器，藉由新增的感應器可以得到更多資訊來增加效率，同樣的，今年在 Android N 裡也增加了一些東西：
1. 6DOF sensor type 讓 app 不僅知道方向還可以知道世界上所有裝置的精確位移。
2. Heart rate sensor 可用來開發一些健身或是健康有關的 app，如：觀測精神與身體壓力、運動或是睡眠分析，等等。
3. 新增 screen orientation sensor type 讓 OEM 廠商實作，當電力不足時可以直接用硬體計算螢幕方向。
4. 可以透過 Sensor API 來探索外部的感應器裝置。

不同的 OEM 與晶片廠商 使得 Android 的生態系統充滿多樣性，為了解決這樣的問題，Google 先制訂出標準規範 Android Compatibility Definition Document (CDD)，再根據 CDD 去讓 OEM 廠商去製造符合標準的 Google Devices。CDD 不止定義了技術細節規範，還提供工具給 OEM 廠商，確保所有開發者的 app 可以執行在裝置上。
關於 Android localtion：
Fused Location Provider (FLP) 是主要用來拿到定位資訊的 API， 結合了多種感應器，包含 GPS、WIFI、Cell、加速度、磁力儀與陀螺儀，Google Map 使用 FLP 來拿到目前所在位置，Google Now 則是用 FLP 來拿到停車資訊。
Android app 負責提供輸入資訊，而 FLP 則決定要來使用到哪些感應器以做到電力管理。

以下開始介紹 FLP 如何使用這些不同的感應器：
1. GPS：最成熟的定位感應器，在戶外可以很準確，但是在高樓或室內則無法發揮作用，非常消耗電力。FLP 只有在 app 要求非常精確的定位資訊時才會開啟 GPS。
2. WIFI：不同於GPS，WIFI 在室內作用良好，準確度雖然不如 GPS，不過還是足以告訴你在樓層的哪一層樓，可以藉由減少定位頻率來降低電力消耗。
3. Cell：覆蓋範圍廣但是準確度很差，只能告訴你大概在哪個城市或是哪一區，但是卻非常省電。

為了解決 GPS 在高樓附近會跳訊號的問題，Android 與晶片開發廠商合作，結合廠商的感應器融合演算法，當 GPS 訊號微弱的時候，晶片可以退回到使用加速器，陀螺儀，磁力儀來提供定位資訊。對 wifi 定位的準確性也有了 40% 的提升，現在 Google maps 可以分辨在你是在個購物商場裡的哪間商店裡。雖然 加速器，陀螺儀，磁力儀 無法準確地拿到定位資訊，但是這些感應器可以告訴你用戶的移動軌跡，利用這些特性與 GPS/WIFI 做結合，藉此來增加定位準確性以及減少電力消耗。

Location Batching 技術是專門應用在電量不足的情況，如果 app 不需要即時的定位資訊，可以透過 FLP 先將定位資料儲存起來，當要用到的時候再更新。例如：運動 app 通常需要紀錄用戶的步數或是距離資料，但是這些資訊只要當用戶需要查看的時候再更新即可。

Geofencing API 結合偵測位置與活動的資訊，讓用戶離開或是進入某個範圍之後收到通知資訊。

 

 

 

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