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

今年 2018 我們也針對 Google I/O 影片中的 Android 相關議題做了懶人包分享，雖然說是各影片的摘要，但篇幅還是有點長，不過還是建議從事 Android App 開發工作的朋友們讀讀，對於了解這一年過去及未來即將發生的事會很有概念。

此為後半部，若需要 上集連結請到這裡

Frictionless Android testing: write once, run everywhere

為程式編寫測試是目前軟體開發者的共識，但編寫測試並非一蹴可幾，測試中存在一個金字塔的概念，由 Unit Tests, Integration Tests, End-to-End Test 組成，原則上保持 70/20/10 的比例是較為適當的，越上層越符合真實情況，相對來說測試與維護的成本也越高。

然而過去幾年編寫 Android Test 開發者必須依賴於各種 Library (Mockito, Robolectric, Android Testing Support Library…)，這不僅提高編寫測試的門檻，導致 Flaky Test 的產生，也因為金字塔中不同層級的測試使用不同的 Library 造成更難以維護。因此 Google 整合了 Testing Library，Jetpack Android Test 包含了既有 Testing Librabry、支援 Kotlin，以往只限於在實體或虛擬裝置上使用的 API，現在也可以 Offline 使用了，開發者現在可以透過 Jetpack Android Test 更專注於編寫高品質的測試。

除了 Testing Library 的整合，Google 也推出了 Project Nitrogen 整合測試的運行流程，Nitrogen 涵蓋了測試的整個生命週期，Setup 階段，它可以幫助測試在任何環境下都能運行，也可以自訂測試的 Script；執行階段，透過 Orchestrator 獨立運行每個測試；最後透過 Streaming 的方式從裝置取得測試結果，並將結果彙整成報告。目前在 Gmail、Google Map、Photo、Youtube 已經使用了 Nitrogen 測試，預計今年稍晚就會開放。

Electronic design for Android Things System on Modules

Android Things 是一套可應用在 IoT 上的系統，基於 Android Framework，所以可以用車機、電視、手錶、手機…等來建構 IoT 設備，在家庭方面可以結合安全系統、喇叭、門鈴…，在企業方面可以結合門市的互動廣告、自動販賣機等。

在硬體設計方面，第一步是規劃，先確認需要的核心組件和功能，並在紙上畫出他們是如何連接的；第二步是 Prototype，實際去買現成的硬體，並嘗試去實作；第三步才真的開始設計，最後做品質的驗證，這幾個步驟在生產階段必須不斷重複執行，以確保產品不會有重大的問題。

Best practices using compilers in Android Studio

先簡介一下影片中會提到的幾個工具，DX 是將 Java code 轉為 dex 檔案的 dexer，D8 則是新版的 dexer，而 R8 是針對編譯過程最佳化的工具。

Android studio 3.0 以上的新版本增加 Incremental Dexing ，編譯過程中 DX 分為兩個步驟，第一步驟將每一個 class 檔的 Java bytecode 編譯成 Dalvik bytecode，所以每一個 class 檔都會產生一個 dex 檔，之後看需求可以將所有的 dex 檔合併起來成 1 個或是多個 dex 檔，在 debug 環境中這個設定預設是開啟的，初始建構時候需要花費一些成本產生更多的文件，但之後的每一次 Incremental 都會越來越快。

當我們想要使用最新的 Java 編寫 Android 時，像是 lambdas、default methods 等等這些功能，卻不被低階設備支援時，編譯過程中 desugar 會讀取 Java bytecode 找出不支援的 functions 發出新的 bytecode 然後傳遞給 DX，這時候就可以使用新的 Java 8 功能。

D8 是新版的 Dexer，可以更快的發佈，產生更小的代碼，且執行編譯器時得到更好的 debug 資訊，讓你知道現在正在進行什麼。Android studio 3.2 也將 Desugaring 加入到 D8 增加 class 讀和寫的速度，這也意味著你可以使用 Java 8 功能，D8 目前已經使用在 Android P beta、Google Docs 和 Google Photos (in canary)。

R8 是新版的 shrinker，App 通常會使用很多的 libraries ，但通常又不會使用完整的 library，這時候就會增加 App 的 size，也會增加執行 ProGuard 的時間。Android studio 3.2 可以在 gradle.properties 啟用 R8 (android.enableR8 = true)，預計可節省了 25% 的編譯時間和減少了 25% 的 dex 文件大小，R8 也為 Kotlin 持續加入 lambda merging、no analysis 等新的優化讓 kotlin 代碼更輕量化。

Android Jetpack: easy background processing with WorkManager

為了最佳化 Android 電量消耗的問題，在 Android M 之後的版本陸續推出一系列電力最佳化的方法，其中在 Android O & Android P 更是大幅限制 App 在背景執行運算，為了讓開發者依然能夠在背景執行處理，Android O 提出 JobScheduler 來處理背景運算的工作，但 JobScheduler 所支援的 API level 並不是那麼全面，JobScheduler 只支援 API level 23 以上並且要有 Google Play service 的裝置，如果低於 API level 23，而且有 Google Play service ，可以使用 Firebase 出的 firebase JobDispatcher 來處理，但如果連 Google Play service 都沒有的裝置，就必須使用 AlarmManager 和 BoradcastReciver 來完成這件事了，為了消彌 API 相容的支援性以及需要擁有 Google Play service 的相依性，推出了 WorkManager 來處理背景運算的工作。

WorkManager 最基礎的元件是 Worker 以及 WorkRequest，開發者可以將想要執行的商業邏輯封裝在 Worker 元件中，然後將 Worker 傳送給 WorkRequest，接著把 WorkRequest 送入 WorkManger 的 queue 當中等待執行。WorkRequest 有兩種特性，一次性執行與定期執行，開發者可以使用 OneTimeWorkRequest 來執行一次性的任務，也可以使用 PriodicWorkRequest 來去處理定期執行的任務。開發者可以使用 Constraints.Builder()，在 WorkRequest 加上一些執行任務的條件，例如，在有網路的狀態下才去執行上傳圖片的任務，開發者只需要把 Constraints.Builder() 設定成網路連結的條件，並且設定到 WorkRequest.setContraints() 裡，就可以達到此功能。WorkManager 可以依序執行任務，比如說圖片上傳到 Server 前，需要做壓縮的功能，就可以使用WorkManger.beginWith(compressWorkRequest).then(uploadWorkRequest).enque()
將想要依序執行的 Work 透過 beginWith() , then() 來處理。WorkManger 也能處理多個 Worker 同時間執行的狀況，使用 WorkManger.enque(WorkRequest1,WorkRequest2,WorkRequest3 , …) 來處理。

Worker 之間有資料需要傳遞，可以使用 Data 這個物件來傳遞資訊，如果想要統整各個 Worker 的 Data 可以使用 InputMerger 來幫忙處理這項工作。要取消 WorkerRequest ，可以將 WorkReqeust 的 id，送至 WorkManger.cancelWorkById(request.id) 來取消 WorkerRequest 的執行。WorkRequest 還有一個方便的功能，可以為 WorkRequest 打上特定的 Tag，因為 request id 是給機器看的，開發者是看不懂的，為了增加 WorkManger 的閱讀性以及可操作性，開發者可以在 WorkRequest 打上一個以上的 Tag，方便開發者來取消，查詢 WorkRequest。另一個 WorkManger 特別的功能是 Unique Work，Unique Work 都會有一個特別的名字來識別， WorkManger 會根據 Unique Work 的名字來決定是否要取消現在正在執行同名的 Unique Work，或是保留 Unique Work，又或者是接續執行 Unique Work。

WorkManager 在測試的部分，可以使用 TestDriver 來去協助驗證 WorkManger。

整體看起來，WorkManger 是 JobScheduler 的後繼者， WorkManger 較 JobScheduler 擁有比較好的相容性，也不需要 Google Player Service 支援，在操作上也算方便，目前正在 alpha 階段，有蠻大機會可以取代 JobScheduler。

Understanding Android memory usage

這 session 在說在記憶體不足時會發生些什麼事，其中的提到三個要點

• How memory use impacts a device
  首先談到如何在設備上使用更多的記憶體及不足時會發生什麼事，當在記憶體不足時會去 Kill 目前在背景的應用程式，這有可能會引起用戶不好的操作體驗上。也有可能會引起 OEM 廠商不願意開發入門款的行動設備，然後流失掉部份只能購買使用入門款的用戶。

• Evaluating application memory impact
  要評估應用程式目前在記憶體的影響可以使用 PSS (Proportional Set Size) ，可以做一些事情來提高良好的記憶體效率。

• Reducing your application’s memory impact
  為了減少應用程式的記憶體使用量可以使用 Android Studio 的記憶體分析器來判斷當下記憶體使用了多少空間，有多少物件沒有被回收等等的。

最後提到要如何減小 APK 的大小，可以參考 2017年 Google I/O 的 session 「Best Practices to Slim Down Your App Size」

What’s new with the Android build system

影片一開始先解答了一些 Variant Aware Dependency Management release 3.0 build 時使用者常遇到的各種問題，

接下來進入編譯器的調整介紹，aapt2、Desuger、D8、R8，而有些舊機制 aapt1、Separate process version、dx 很快會被淘汰，因此儘速升級，在升級為 aapt2 時可能會有些狀況，需要調整 project 來解決。

新的 version 為 full build 節省了很多效能，對 Incremental build 也是，如果開發者客製了 Annotation processors，使用新的 Incremental Annotation processors 也會再節省一些效能。

如果想將 project 升級為 androidx，但使用的 libraries 不一定都升級了，使用 android.useAndroidX=true 協助調整 libraries 的 reference。

Building App Bundle 能有效減少使用者下載到的 apk 大小，若有針對不同 target device 使用的 features，還能使用 dynamic feature 將其拆分成 sub-project，進一步縮減 apk，講者也說明了詳細的原理及注意事項以及 multi-Dex 和 Resources 獨立的處理。

最後講到 gradle 的 public api，目前 Api 不是很完善，文件不完整，但 Google 還是針對開發者的需求持續調整，講者舉例現在在 AGP configuration 的前期流程中可以動態改寫參數。

What’s new in Wear OS by Google

Android Wear 正式更名為「Wear OS by Google」，原因是為了讓更多手錶製造商搭載 Android 系統，而非定位在生產 Android 手錶的概念而做的命名改變。

Google 研究終於發現人們穿戴式裝置的使用習慣往往只會是很短暫的一瞥，在不方便攜帶手機的情境下，往往才是穿戴裝置最可能被選擇使用的時機。例如當你在需要心靈平靜不被手機打擾的情況下，又想要保持能接收到你在乎資訊的情境。生活中最常見的是運動的時候，所以未來重點會放在發展 Health ＆ Fitness 並結合 Google Assistant 提供更好的穿戴式裝置體驗。

根據使用者習慣的研究結果下，將採用更大的字體與更合適閱讀的字型，並且加深背景色的設計來提高訊息的可讀性。

Health ＆ Fitness 是穿戴式裝置的核心價值，在未來幾個月將以此為重點作出調整，包括 Google Assistant 與 Actions on Google 等。最後再次強調優化電池耗電量的重要性，並提出開發錶面的新工具 Kotlin DSL。

Building AR apps with the Sceneform SDK

Google 為了讓開發者在開發 AR 時可以免除寫很多複雜數學運算或寫 OpenGL 而推出了 Sceneform SDK，他是一個 3D framework，也提供了 plugin 可以讓你在 Android Studio 編輯 3D 物件。透過 Sceneform SDK，他可直接跟你現有的 App 做結合。Sceneform API 包含兩個概念，Scene 和 View。Scene 代表增加到環境的 3D models，View 則代表你放置的位置。Sceneform 提供了 SceneGraph API 來定義物件的階層以及在空間中的關係為何。除了可以建立 3D 物件外，也可以利用 ViewRenderable 建立 2D 的物件。利用 TransformableNode 可以針對物件作縮放及旋轉。你也可以利用他的 Material 相關的功能，讓你製作出來的 3D 模型融入你的環境之中。

Best practices for text on Android

講者從 TextView 開始往底層介紹，包括 Layout、Paint、Canvas 等 Java 層，到更底層以 C++/C 編寫文字測量、斷行、連接符號的 Minikin 等工具，處理 Unicode 的 ICU、處理 FreeType 的HarfBuzz，處理繪圖的 Skia 等。再介紹如何優化文字。

其中最需要有的概念就是 Span 這個名詞：
SpannedString 是不可再設定 Span 樣式 且不可變化的字串
SpannableString 是可再設定 Span 樣式，但不可變化的字串。
SpannableStringBuilder 是可再設定 Span 樣式，且可變化的字串。

不同的 Span 可以只影響外觀跟影響測量兩種，如果使用的 Span 只會影響到字的顏色或底色等外觀，該 Span 只會重繪，但如果使用的 Span 會影響到字的 layout、大小、字體、間距、語言等，那麼該 Span 就會重新測量和重繪。在大量使用Span的情境下，建議使用 SpannableStringBuilder 來達到更好的效能。

接著講者提到一些技巧：

• 對 TextView 使用 setTextLocale 指定地區或語言，Minikin 才能準確處理斷行、連接符號、字型選擇
• 而當一字串中有多種語言時，就需要加上 LocaleSpan 來指定某些文字的語言
• 可以使用 annotation 在 strings.xml 中修改字型
• 如果需要載入的文章內容很長，假設是一本書的內容，一次全部塞進 TextView 是很耗效能的，而且使用者也不一定會滑到後面，這時建議以 RecyclerView 做分段
• 如果需要畫出帶有 Span 或換行等文字，無法使用 Canvas.drawText()，這時必須使用 Layout.draw()。

在最後提到 Android P 上的新東西

• Android P 修正了有上下標的文字的上下行會重疊的問題，系統會根據超出範圍的字增加間距，並套用在整個段落上
• Smart Linkify，比起過去的 Linkify，導入了機器學習，所以它能從文字中更準確的找出電話、地址等訊息
• Magnifier 放大鏡，在選取文字的時候，上方會出現放大的文字，這是預設功能，不需額外加入。

Google Play Instant: how app developers are finding success

第一位講者的重點：

現在遊戲開發者可以開發 Native Instant 給使用者使用了，但 Instant App 只支援 Lollipop 以上的版本。

根據統計，使用者花在手機上的時間有 87% 是用在 App 上面，只有 13% 在網頁上，但同時，也有超過一半的使用者在一個月內沒有安裝任何 App，主要因為探索新的 App 太困難與安裝過程太瑣碎。

在試著改善使用者探索新的 App 的體驗方面，講者建議分享 Instant App 的 URL 在 Google Search 上面，或使用 Google Ads 也可以快速讓使用者看到這些資訊。

在試著改善使用者安裝 App 的體驗方面，當開發者發布 Instant App 在 Google Play 上面，現在會出現一個 Try Now 按鈕讓使用者體驗，根據統計，這樣的做法提升了近 19% 的安裝率。開發者也可以使用 Web To Instant App Banner，讓使用者快速體驗 App。

Google 也希望可以透過通知來提升使用者安裝體驗，所以推出了 Notifications Beta，這目前還在測試中，有興趣的人可以透過 http://g.co/instantapps/notifications 獲得更多資訊。

第二位講者重點：

根據統計，在使用了 Instant App 後，有許多 App 獲得不錯的成效。

• NOS & Realtor 安裝率分別提升了 30% & 13%。
• Wego & hollar 轉換率分別提升了 27% & 20%。
• Viki Video App 的使用者觀看時間提升四倍。
• Vimeo Video App 訂閱率提升了 130%。

第三位講者重點：

要開發一個 Instant App 之前要先降低 Apk 的大小, 但許多開發者反應，這點其實很難做到, 這裡提供幾個方法幫助你去做到這件事：

• 嘗試去減少提供的 Binary File 大小。
• 嘗試讓一些資源及 Native Code 橫跨所有 Locale & ABI & Density。
• Google Play Core Library
• 可以在 Runtime 時動態下載需要的模組。

還有 10MB Beta Program 可以幫助你開發一個只要 10MB 的 Instant App，但還在開發階段，有興趣的可以透過 http://g.co/instantapps/10MB 獲得更多資訊。

Android Jetpack: manage UI navigation with Navigation Controller

頁面切換一直以來是 Android 開發的難關，開發者需要自行處 Fragment Transaction、Testing、Deep Links、Passing Arguments、Up and Back… 等的問題，舉例來說，原先 App 的瀏覽過程為 Home -> Category -> Item，而使用者透過了 Deep Links 開啟了 Item 頁面，這個時候開發者必須自己建造前兩個頁面並把他加到 Back stack 中，而 Navigation 就是為了解決這個問題而出現的，開發者能夠輕鬆的在 Navigation Editor 中定義整個 navigation graph（ 裡面包含了切換的目標頁面、動畫、Pop 時的行為…等 ）。

而在這整個 Navigation 的概念中，Activity 是一個 App 的入口，管理了所有的 global navigation ( bottom nav, navigation drawer, etc )，而內容則是交由 NavHost 也就是 Fragment 提供，使用時只需要在 activity_main.xml 中放置 fragment 的 layout 中設定 app:navGraph ，並且設定 app:defaultNavHost 來處理像是 Back pressed 之類的行為，接著在程式中 findNavController 取得 Navigation controller 並執行 navigateUp() 或 navigate( id ) 就能依照 navigation graph 導到相應的頁面；Navigation controller 也能跟 navigation drawer、bottom nav 做關聯，用 setupActionBarWithNavController 或 setupWithNavController 設定後，Navigation controller 會更新 selected item 的 UI、用 Navigation graph 中的 label 來更新 Action bar 標題… 等。

除了簡單的畫面切換及以 UI 更新外，也提供了 safe-args Gradle plugin 來自動產生傳進 type-safe 的參數物件、NavDeepLinkBuilder 處理 Explicit deep link ( Notification, shortcut, widgets… ) 、在 Android manifest 定義 處理 Implicit deep link ( web url, custom scheme ) ； 也因為實作細節都做了封裝，因此可測試也提高了，可以直接在 Navigation Controller Level 做測試。

Women Techmakers panel: experiences developing on Android Things

女性開發者社群分享了一些她們在 Android Things 上的實現

• Steve
  一棵巨大的 LED 樹，可以與人簡單的招手互動
• Rosie
  一個用垃圾桶、蛋糕盒蓋及輪子組成的小綠人，可以移動、偵測微笑、與人握手

她們分享從 Github 及 Android Things 的 codelab 上都能獲取很多足夠利用的知識，甚至很多複雜的驅動程序都被妥善處理在乾淨的 API 之後，不用自己再重寫。

How to get one-meter location-accuracy from Android devices

現在對位置應用程式來說是很好的機會，因為科技、硬體、定位標準和 Android API 都可以幫助提升定位的精準度。但不只是應用而已，也要讓大家了解定位的原理，需要尊重和保護使用者，越多人使用定位服務，越多事需要被注意，什麼時候需要要求權限，並遵循開發指南，達成優良的定位 App。

在室內地位，你可能有注意到在購物中心買東西時，定位變精準了，因為有了 Fused Location provider，Android 定位演算法和機器學習來穩定提升 Wi-Fi 定位，使用者可以感受到室內定位誤差可以小於 10m。

GPS 在無雲的情況下，這幾年精準度是差不多的，大概為五公尺，但 Wi-Fi Round Trip Time (RTT) 可以讓誤差到到達一公尺的等級，這可以有效的幫助開發者得到更精準的精準度，室內導航 App 對比戶外導航需要更精準的精準度，可能要知道離走道的距離，如果沒有一公尺誤差的精準度的定位，在重新繪製路徑時，路線可能會亂跳，這是很糟的使用者體驗。

介紹 RTT 前，先介紹室內定位的原理，使用 Wi-Fi RSSI，代表收到的訊號強度，基本上可以用這個訊號強度來計算距離，但在強弱訊號的交界，兩支手機有同樣的訊號，但實際的距離是有差別的，很難得到精準的距離，因此 Wi-Fi RTT 就出現了，使用了訊號的傳輸時間，而非訊號的強度，發送一個 Wi-Fi RF 封包，從 AP 到手機然後再回傳，訊號傳輸的速度和光速一樣，如果把來回時間加總乘以光速，然後除以 2 為單趟距離，就是手機到 AP 的距離。如果要計算位置，就必須使用 multilateration (多點)，得到較多的範圍和較多的約束，也因此有較準確的位置，如果能得到四個的範圍，就會有較高的精準度。

接著講者很詳細的介紹了 Wifi 與 GPS 定位的原理與 Google 加強準確性所用到的方法，目前室內和戶外定位都有新的技術，且 Android P 的版本就可以使用了。講者也提到，要達成一個好的定位 App 必須要對使用者有透明度，要取得 access_fine_location 權限，對使用者說明有什麼好處，為什麼要這麼做。

How to Kotlin – from the Lead Kotlin Language Designer

講者以 Java 與 Kotlin 程式碼的對照說明如何移除撰寫 Java 的習慣，並且說明撰寫 Kotlin 時有很多部份可以刪除，例如講者將 Java code 貼到 Kotlin 文件上時，編輯器自動轉換為 Kotlin 的程式碼且只需要一行即可完成純資料類型的宣告。

接著講者示範了大量 Kotlin 的語法，包括 null 判斷式使用 Lazy library function 寫法來取代、smart casts 和可以讓程式碼更簡潔的 sealed、with、是否為 null 物件的檢查及預設值、不干擾程式寫作流程的 also 等實用語法。另外在 Thread 方面 Kotlin 還提供了 Coroutines 這種非同步的操作方式。

Autonomous and customized pre-launch testing in the Google Play Console

Play Console 的 Pre-Launch Report 與 Firebase Test Lab 提供大規模測試以及快速創建 Testing 的 Solution。

• Pre-Launch Report
  Goole 會在開發者發佈 APP 至 Play 後，將其自動安裝至一批 (約10種) 性能高低不一的裝置 上，並以爬蟲模擬用戶行為。，Pre-Launch Report 提供了 Crash Info (Stack Tree、Log、Screenshot)、Usability & Accessibility (Coming soon)、Performance (Network, Memory, CPU)，據 Google 統計，Pre-Launch Report 可以找出大約 75% 的問題。
• Test Lab
  提供與 Pre-Launch Report 相似的功能，並可整合進入 Android Studio、fastlane、gcloud SDK、Firebase Console，讓開發者可以在 APP 開發階段利用大量的裝置進行測試，也可手動設定參數(Screen Size, Android API version, OEM, Chipsets, Locale…等)。
• Pre-Launch Report 以及 Test Lab
  提供開發者於 Manifest 中撰寫 Demo Loop (自訂爬蟲規則)，或由爬蟲自行進行 Monkey Action (隨機測試)。此外還有 Auto login 機制(包含 Custom Login 以及 Goole Sign in)、Deep links Testing 以及 Robo Script (可使用 Android Studio 錄製的爬蟲操作指令，用來避過 APP 中的複雜操作)，Test Lab 另外提供由中國的遊戲開發商 NetEase Open Source 的測試 Framework AirTest (For OpenGL Game)，可以利用畫面元件撰寫測試。

另外，Google 在 Android Studio 中提供 Espresso Test Recorder，用來創建 UI Test，用法類似按鍵精靈，Android 會將其轉譯成 Java 或 Kotlin，但只能處理非 OpenGL 的東西。

What’s new in Android apps for Chrome OS

去年的會議上就有提到可以在 Chrome OS 上開發 Android apps，今年沿續這個主題來談一些基礎知識與新的功能及原有功能優化簡介。

在 Chrome OS 裡有一個 Android container，因此可以在 chrome books 上執行 Linux 與 App。Chromebooks 與 phones 的四大差別：較寬的螢幕、預設橫向、視窗管理、主要輸入設備。

在 Chrome OS 新功能主要有 tablet mode、Split-screen、Picture-in-picture、Android IME virtual keyboard、Notifications、Pro audio。

功能優化部份則有 Become desktop native、Menu accelerators、Shelf integration、App shortcuts、Back button、Lifetime management、Share data without boundaries、Resizing、Zero-latency Ink、Multi-display、Presentation API、3D & gaming、Vulkan support。

Developer tools 則包含 OS emulator in Android Studio、ADB debugging over USB (Pixelbook and HP Chromebook X2)、Terminal。

Android Jetpack: sweetening Kotlin development with Android KTX

Kotlin 的 extension function 允許我們在不用修改原本 class 的情況下為一個 class 加上 function。

Android KTX 是用於 Android 開發時的 Kotlin extension function 集合，KTX 有幾項原則：

• 調整已存在的功能並重新導向,
• extension function 預設是使用 inline 寫法(只適合 KTX 的風格，在正常的 kotlin code 上不建議這樣做),
• KTX 不想做 Code golf(讓 code 越短越好), 4. KTX 不想為了只使用一次或特例來寫 extension function，否則當情況變複雜時，就必須用回原來的寫法。

接著在影片中舉了一些例子介紹如何用 Java 寫出 Kotlin-friendly 的 code，接著再使用 Kotlin 寫一次在 Kotlin 中慣用的寫法。

Integrating your Android apps with the Google Assistant

講者首先說明為什麼要做整合 Google Assistant 的工作，每個人的手機上都安裝了許多 App，如果你想查詢某個問題，例如魚的料理，這時市面上會有極多的 App 可能有答案，因此一個簡單的問題可能會延伸出更多的問題讓你難以開始做一件事。又或者你今天在 App 裡面做了超酷的功能，但是用戶安裝了 App 之後就不再開啟，也不知道 App 裡面有很酷的功能可能對他有幫助時該怎麼辦，這時 App Actions 可以幫得上忙。

例如用戶透過 Google Assistant 輸入「記帳」就可以開啟記帳 App，也可以用於內容查詢，當使用者開啟 Google Assistant 並輸入「請告訴我 Lady gaga 本名？」時 Google Assistant 會預測使用者的下一步可能想聽 Lady gaga 的音樂或是觀看影片或是購買 Lady gaga 演唱會門票，而顯示 suggestion chlips 在下方，並透過點擊 chlip 開啟 App，在 Google search 中搜尋也會推薦適合的 App。當你在 email 或是瀏覽器選取了一段文字，像是餐廳的名稱，就會開啟餐廳的 App，這些都是 App Actions 可以幫助服務開發商的表現。

在 Android device 上建立 App Actions 的步驟很簡單，首先建立一個 actions.xml 並定義 intent 與 fulfillment 表示 action。至於 Android Auto 或 Google Home 則是要用建立 Conversational Actions 與 Dialogflow Build & Test 的方式。

Build reactive mobile apps with Flutter

Google 在去年推出了 Flutter ，為了讓開發者能夠更快速的開發 Android & iOS App，Flutter 的優點是只需要一套 codebase 即可在 Android & iOS 建立 App，並且在 UI 重新部署上的速度極快，加速方便開發者的實作。

Flutter 的核心是所有的 UI 都是互動模型 (reactive model)，總體來說可以簡述成下述三點

• 所有的 UI 都是 component widget，
• 可以結合這些 UI 組合成複雜的 UI 元件
• Flutter Manager 管理 UI 與狀態之間的關聯，當狀態改變時，來去更改 UI ，例如去呼叫 Widget 的 setState()，元件就會因為狀態改變進而重繪。

Flutter 有許多 UI 的模版可以參考，建議開發者可以上 Flutter.io 去查詢，這場 Session 主要會關注的地方是 Flutter 和狀態 (State) 之間的關係， 如果要串起 UI Widget 與狀態上的連動，有一點非常重要的是，必須要在想要改變的 UI Widget 上呼叫 setState()，讓 UI Widget 知道現在有狀態變更了，讓 Flutter 去 Rebuild 需要改變的 UI Widget。在複雜的 UI 上，UI 就像是一顆 UI tree，狀態需要逐步的往子節點傳送，才能讓子節點知道現在狀態變更了，需要做 UI rebuild 的工作，這邊可以使用 InferitedWidget & ScopedModel 來做到這件事，將母節點的狀態資訊往下傳遞給子節點。Flutter 也可以接收各種外部來的資料，Flutter 使用 Streams 來處理這件事，簡單說 Streams 很類似於 Obserables，負責去接收資訊，並傳遞給商業邏輯元件去做運算，運算完畢後再傳遞給 UI 做重繪。

What’s new in Android security

這 Session 提到 Android 一些新的保護機制及運作方式。開發者可以使用 Protected Confirmation API 這個新的 API 向用戶顯示請求，要求用戶批准臨時性的請求完成比較敏感的交易，比如付款，目前有不少合作夥伴已經開始使用這個新的 API 了。

StrongBox 能抵禦各種各樣的攻擊，它非常適合保護你的私鑰，但這需要新的硬體支援所以只會跟 Android P 一起發佈在新的設備上，要用 StrongBox 很簡單，只要產生 KeyStore 金鑰時設置一個設定要求該金鑰支持 StrongBox ，如果設備支援 StrongBox ，就會正常運行但如果不支援就會收到 StrongBox 無法使用的異常，除了設定金鑰外，另外比較重要的安全性問題就是要確認操作的人是本人，為了防止非本人操作螢幕的鎖屏相對的就變的很重要了。另外如果螢幕已經被解鎖了，然後在操作部份敏感資訊時會需要再次做驗證是否為本人，BiometricPrompt 就能做這方面的處理像指紋、虹膜、臉部辦識等的並且取代舊版本的 FingerpringManager。

Google Pay best practices for great payment experiences

經過多年研究，大部分的使用者在網路購買流程時，時常因為冗長而不親切的錯誤提示流程而讓使用者卻步。
Google Pay 可以讓使用者簡單的購買，也讓開發者簡單的引進自己的購物流程中，AirBnb 更新了最新含有 Google Pay 的版本後，traction 數據成長了 11 倍。

Google Pay 的設計主要基於快速及可擴展性，而安全性也非常受重視，開發人員多方面的加了防護及加密驗證措施，也可以使用指紋辨識。

Goodle Pay 是一個整合統一性的平台，在各種裝置都能操作，協助匯入整裡各項已購票卷資訊，並且會有所有消費紀錄可供檢閱。

在 Chrome 遇到信用卡資訊輸入頁面時，Google Pay 支援自動填入項目，但也希望網頁端的欄位設置是符合規範的。

最後介紹了在 Smart speaker 搭載 Google Pay 的使用情境。

Building feature-rich media apps with ExoPlayer

這 Sesssion 利用了兩個 app 去說明如何用 ExoPlayer 開發一個播放 MP4 stream 的 video player 然後也會說明如何在播放 video 之前插入廣告影片，再來會說明如何 build 一個可以在背景播放的 audio player 及實作下載音檔的流程。

ExoPlayer 是一個應用層的 media player，最低支援 API 16 且他是開源的 player 在 GitHub 上可以找到，目前大約有 20 萬個 APP 在 Google play 上使用 ExoPlayer。

影片中 live demo 了如何從頭開始 build 一個 video 的 ExoPlayer ，首先在 Gradle 裡的 dependencies 裡加入 exoplayer-core 及 exoplayer-ui，如此就可以在你的 layout xml 裡加入 exoplayer PlayerView 並且在 Activity 裡的 onStart 加入 newSimpleInstance 產生一個 SimpleExoPlayer，再將產生的 player 丟進 playerView，這樣就產生了一個 video 的 player ，接下來要設定 DataSource ，所以 new 一個 DefaultDataSourceFatory 並建立一個 ExtractionMediaSource 把 DataSource 及 MP4 url 丟進去，最後將 mediaSource 丟進 player 的 prepare 及設定 playWhenReady 為 true 如此就可以正常播放 MP4 stream，記得要在 onStop 時把 playerView 及 player 做 release。

如果你的 video 需要加入廣告影片，那就需要在 Gradle 的 dependencies 再加入 extension-ima ，然後在 Activity 裡加入 ImaAdsLoader 及設定你的 AD url，然後修改 onStart 加入一個 AdsMediaSource 把原本的 mediaSource 丟進 AdsMediaSource ，而 player 的 prepare 改丟入 adsMediaSource，此外在 onDestroy 中必需要把 adsLoader 做 release，這樣在播放 video 之前就會先播放廣告影片。

Audio player 的特性是他需要可以在背景播放，且同時操作其他的應用程式不會影響 Audio player，所以在這 demo 會需要使用到 foreground service 讓 notification 可以顯示 player 資訊，如果沒有使用 foreground service 系統有可能會 kill 掉你的 player 造成 crash。

所以在 demo 首先建立了一個 AudioPlayerService 裡面初使化了 SimpleExoPlayer ， 跟 video player 的流程一樣只差在沒有放入 playerView ，並在 Activity 裡產生 server 且設定為 foreground service，如果是要播放一個 playlist 可以使用 ConCatenatingMediaSource ，將你的 mediaSource 丟入 ConCatenatingMediaSource 再讓 player 的 prepare 載入 conCatenatingMediaSource，這時在 notfifcation 中要顯示 player 資訊就用 PlayerNotificationManager 來產生並代入正確的 MediaDescription。

如果你的 player 要讓 Google Assistant 或其他 app 可以控制，那你需要加入 MediasSession 及 MediaSessionConnector 讓這兩端可以溝通，在 AudioPlayerService 先建立 MediaSessionCompat ，然後 PlayerNotificationManager 設定 MediaSession token ，最後建立 MediaSessionConnector 及設定 QueueNavigator 回傳 mediaDescription 。

最後一個 demo 是關於 download 音檔的部份，下面圖片的流程在一般播歌流程是 mp3 進入 DataSource 然後丟給 cache 再進到 MediaSource 最後 Player 播出，而 download 流程會在 cache 那層把音檔存下來。

在 demo 裡 AudioPlayerService 建立了一個 CacheDataSourceFactory 並設定 cache 的 path ，然後把 dataSource 丟進 cache ，此外需要另外再建立 AudioDownloadService 來處理下載歌曲並且 extend DownloadService，這 service 裡提供了 getForegroundNotification method 可以設定下載歌曲時 notification 顯示進度條，然後在 Activity 中設定 click item 時建立 AudioDownloadService 讓歌曲下載。

以上這個 ExoPlayer 影片講述了整個建立流程及幾個常用的方法 demo。

Build a universal camera app

這是一部從頭到尾只能遠眺 slide 的影片…分成三個部分，分別由三位不同的講者進行

第一個部分，主要是介紹在底層的部分，Android 是怎麼去操作 Camera Module。處理時分為 Preview、Photo 與 Record 來看，在處理 Preview 時，會為了降低 latency，讓 User 能更即時的看到 Camera 所看到的東西，而對畫質或其他的部分做調整。在處理 Photo 時，畫質則是最重要的因素，這時則是犧牲 latency 來呈現更好的畫質。對 Video 來說，畫質與成像速度皆很重要，因此必須針對這兩個部分取得一個平衡，來找到最佳的結果。

第二個部分，由 Snapchat 的工程師來講述怎麼利用第一部分提到的東西來建立你的 app，在設計上會有什麼樣的取捨需要注意，以及在實務上遇到了什麼樣的挑戰。講者講了 Snapchat 的 4 個模式，在這 4 個模式下分別做了哪些取捨，讓這 4 個模式下呈現最好的效果。而在實作方面，由於 Android Camera API 分為 Camera1 與 Camera2，即使系統回應支援 Camera2，他們發現底層可能還是用 Camera1 的方式在處理，因此他們從 2016 年開始就同時支援 Camera1 與 Camera2，並在上層用統一的介面來操作這兩個 API。

第三個部分，由 Android Camera Platform PM 出來介紹新的 multi-camera API，並且已跟部分開發商合作，如華為、小米，新的機種將會能支援此 API，以及部分現有機種升級後能夠支援。與 Android One Team 的合作則是確保新的 API 可以不只是在高階機種可使用，而是讓所有的機種都支援此 API。

Effective ProGuard keep rules for smaller applications

Google 提出的 Next Billion Users 計畫，預計在巴西、中國、印度、印尼會有非常大量的使用者，但這其中包含非常大量的低階手機甚至是有限的網路，但根據圖表，從 Android 早期的 app，平均大小只有 1MB，到了現在，平均為 32MB，這對低階手機來說是沈重的負擔，所以我們必須減少 App 的大小，以節省下載、安裝、啟動的成本。

apk 之所以越來越大，是因為我們有越來越多的套件可以使用，雖然這些套件的功能很多，對不同裝置的支援度也很好，也為我們省下開發時間。

首先介紹兩個名詞：

• D8
  這是將 java code 轉為 dex 的工具，用來取代 DX dexer。
• R8
  這是將 apk 縮小的工具，從 Android Studio 3.2 Canary 開始使用 R8 取代 ProGuard。若要試用 R8，請將 android.enableR8 = true 加到 gradle.properties 中。R8 還屬於測試階段，所以不建議使用 R8 發佈你的 App。

AAPT 會在 build 的時候，自動為我們在 Manifest 裡的 class 做 keep，而他也會自動找尋相依的套件、resource id 做 keep。

有些情況 ProGuard、R8 無法判別，但執行起來是正確的，像是一些 annotations、特殊的寫法等等，這時候我們就要下 dontwarn 在執行時強制關閉警告。

有很多時候，我們在引用第三方套件時，套件的文件上雖然寫了 -keep 套件 package name，通常是為了讓所有情況都能夠使用，但我們可以根據不同的使用狀況去 keep 甚至 dontwarn 我們需要的東西。即使當我們需要用到 -keep 時，也有很多種 keep 方式供我們選擇例如 -keep, allowshrinking、-keepclassmembers 等等，而不需要 keep 所有東西。

Improve app performance with Android Studio Profilers

這部影片介紹了如何使用 Android Studio Profilers 幫助開發者調整 App 的效能，過程環境是使用 Andorid Studio 3.2 Canary，以下是 Android 3.1 與 3.2 新增的一些工具。

• Network Profiler
  • 可以看到 Http Request 的傳送細節，像是收到的資料，使用的 Custom Header 等等。
  • 新增 Thread View，可以觀察 Http Request 是在哪個 Thread 上建立的。
• Memory Profiler
  • Event Timeline
  • Live Memory Allocation
  • 可以看 Alloocated Objects 的數量。
  • 可以看 JNI Global Reference，方便開發者尋找 JNI Memory Leak。
• CPU Profiler
  • 新增 C++ Profiling 幫助開發者了解 C++ Native Method 的使用狀況。
  • 在 Run/Debug Configurations 的 Profiling Tab 裡新增 Auto Recording for Method Trace 選項.
  • 新增 System Trace 去紀錄 App 與系統資源間的使用狀況，也可以透過 Debug.startMethodTracing & Debug.stopMethodTracing 從程式中控制紀錄時程。

Don’t let your app drain your users’ battery

今年的新功能 Adaptive Battery 將所有的 App 分類到 Standby Buckets，每個 bucket 對於背景活動的限制不同，從完全沒限制到完全限制總共分成以下四個 buckets: Active, Working Set, Frequent, Rare，而 App 的分類則是利用 Machine learning 對於 App 的使用行為進行預測後放到對應的位置，每個 App 都會是平等的，分析的 model 也不包含任何的個人隱私；除此之外在 Battery saver 方面也做了一些改進：移除快沒電時的紅色狀態條以及動畫、關螢幕時關閉 location service… 等；另外當使用者進入 Battery Settings 頁面時，通常都是遇到了電量的問題，因此在這個頁面的設計變得更簡單，讓使用者能更直覺的對 app 進行限制等操作。除了以上的更新外，也建議使用暗色系的主題，因為研究顯示這樣比較省電。

然而背景限制的部份也做了一些小調整，為了防止 legacy app 被忽略，繼續使用 background service 的 pre-Oreo app 以及用了超過一小時 wake lock 的 app 將直接進入背景限制的名單，被限制的 app 將不能執行 Background job、Alarms、Services、Network access 等… ，也不能使用 foreground service 及接收 explicit intent。

以上的 Adaptive Battery、Battery Saver、Background Restrictions 都能用 adb 進行測試，可以查看及設定 App 的 bucket、開啟 low power mode、打開或關閉 restriction。

Product design: how to build better products with Android Things

硬體設計需要很長的流程，可能要花上二到五年，才能把想法轉變成實際的產品。從點子開始，開始做 prototype，然後選擇硬體，接著設計軟體，再送到工廠，最後得到產品，然後還要再做更新。但現今的世界是變化很快的，在製作產品的過程中，科技也在跟著改變，那在整個設計過程中要如何跟上呢？ 因此我們設計了 Android Thing，在快速改變的世界中可以透過點子一路開發。

System on Module 也稱作 carrier board，SOM 可以使用在 prototype 上，也可以放在自己的 PCB 上，在 carrier board上 可使用配件，網路線，電源，耳機孔都是配件。carrier board 拿來做 prototype 是很有用的，因為已經很多的工具可以使用，如果需要其他周圍設備，可以用傳統的方式，使用 pin, 麵包板, 電阻。Android thing 提供了方便開發的tool，並提供程式碼，範例，專案，社群，相關網址：https://androidthings.withgoogle.com/

Android Thing 提供了端到端的解决方案，從 prototype 到產品，SOM 藉由模組化硬體的解決方式讓硬體的選擇更為簡單．Android Thing Kit 的週邊設備有顯示器，相機，七段顯示器，天線讓裝置可以連接到 wifi。最後如果要生生產產品了，開者控制台可以幫助使用者設定設定檔，韌體，發佈執行檔到裝置，對建立實體的商品來說，比以前容易了 Android Thing 提供了工具來加速開發 prototype，就可以開始時執行你的點子，有很多的圖像化介面和結合硬體，可以透過 Android thing 實作更好的產品。

What’s new with ConstraintLayout and Android Studio design tools

Layout Editor 增加了一些新功能幫助開發者更方便的去調整 UI，像是可以在 Layout Editor 看到 Cutsom View 的狀態。透過 Convert view 的功能，把想要改變的 View 透過 IDE 介面轉換成另一個 View，可以在 Compoent Tree 去瀏覽 include tag 裡的子頁面內容。Layout Editor 對 ContraintLayout 的支援性更加提升，可以在 editor 上操作 CostraintLayout 的屬性。

為了讓 UI 調整在預覽時更貼近開發者所期望的真實狀態，最常見的方式，是使用 tools 屬性，將 sample data 和 Layout Editor 做結合，在預覽時就可以知道有資料的狀態下，畫面是如何呈現的。關於 Sample data 的部分，可以在專案下產生一個 sample data 的目錄，並將預覽的資料都放在此資料夾底下，可以放置一般資料，列表型的資料，圖片，甚至是 JSON file。

Android Studio 3.2 支援了更多調整 Sample data 的方法，例如可以在 IDE 上直接選取一組資料集餵給 Recycler View，直接在 UI 上調整文字的 sample data 以及直接在 UI 上調整 imageView 的資料集合。

ConstraintLayout 1.1 有兩種 Helper ，Guideline & Barrier，然而在 ContraintLayout 2.0，開發者可以使用 ConstraintHelper 來自定義所需的 Helper。ContraintLayout 2.0，推出 Linear Helper 讓開發者可以在 ConstraintLyaout 使用類似 LinearLayout 的功能，另一個 Flow Helper 則是可以做到類似 FlexboxLayout 的功能。

Layer 讓開發者可以在 editor 去鎖定，隱藏，鎖住所定義集合的 view，並藉由圖像化的方式去操作這些物件。Circular Reveal ，讓開發者不需要寫任何動畫計算，就可以簡單繪製圓形顯現動畫。

Decorators 是一種用來繪製畫面的 Helper，有兩種 Decorator， Lava Decorator 和 Bottom Pannel Decorator 來幫助開發者繪製畫面。

在 ConstraintLayout 2.0 管理狀態變得更加方便，以往需要搭配 ConstraintSet 才能處理狀態變更，現在則是把狀態的部分劃分到 xml 去，讓權責更加分明。

MotionLayout 是 ConstraintLayout 2.0 非常特別的一個功能，開發者可以去定義 key frame ，IDE 會自動幫開發者把 key frame 之間的動畫補上，非常的方便。

Device provisioning and authentication with Android Things

使用 Android Thing SoM 讓建構 IoT 變得更簡單，不需要在雲端處理運算，就可以做到聲音、影像甚至機器學習，因為它有手機等級的規格，也有來自 Google 的更新和安全性，它基於 Android，所以也可以繼續使用原本的開發工具。

• 認證 (Authentication)
  確認連線是真的或是有效的。可以使用 HTTPS 或是 TLS 等方式連線手機和 IoT 裝置，認證並不表示身分驗證，也可以是匿名身分認證，另外也可以做綁定認證，像是藍牙配對。
• 授權 (Authorization)
  檢查操作是否被允許，需要考慮到誰可以訪問、命令 IoT 裝置或是讀取資料。
  使用上，以最小授權為原則，盡量避免不必要的授權。另外，要謹慎發送 token，token 除了要有到期時間，也要先經過可信任的驗證後再發送。(範例中透過 Firebase 存取 token)
• 識別證明 (Attestation)
  檢查 IoT 裝置資訊、是否為一個 Android Things、狀態、識別等等與 IoT 裝置相關的資訊。
• Nearby Connections
  用來找尋附近的設備，並提供加密的 BLE、Wi-Fi 等連線機制。

Update production devices in the field with the Android Things Console

過去因為物聯網沒有一定標準，使得開發者在開發過常常碰到不好的開發者體驗、裝置建置速度過慢與未受到重視的物聯網產品資安防護，而 Android Things 1.0 版本目的就是希望打造一個簡單、確認系統可以進行長期、安全更新的管理平台，並提供三年的免費穩定性修補程序和安全修補程序。
如下圖，開發者可以專注於軟、硬體設計，其他全部都可以交給 Android Things Console 來處理。

影片中有簡介一些 APP 的 configure 與 build 欄位設定，而在 product settings 頁面的 sharing 欄位裡，可以設定多位共同開發者的建置與上傳權限。

一般更新流程如下：
Update Engine Client 會向 OTA Server 確認是否有更新，當 app listener 收到已有可用的更新時，就會開始執行下載，直到下載完畢，這期間使用者仍然可以繼續使用他們的設備，只有等到觸發重開機的時候，才會從寫入更新的區塊開始，又會再次檢查更新，若已經更新就會回到 idle 狀態，直到下一次更新流程。其更新頻率可透過 UpdateManager API 設定。

Delta updates 目的是為了讓設備可以接收較小的有效封包，不需要等到完整的完全下載更新後，才能使用新功能。
版號的定義包含 Major Version, Minor Version 與 Security Release,。以版號 1.2.180321 為例，Major Version 為 1，其為較大的改動，包含 Android API Framework 變動，且沒有提供自動更新，Minor Version 為 2，此為較低風險的更新，且不包含 Android API Framework 變動，提供自動更新，包含 Android things API，180321 則是 Security Release 版本，更新週期為一個月一次，提供自動更新，完全不包含 API 變動。

Google Play Instant: how game developers are finding success

Instant App 現在也適用所有遊戲，最明顯的入口是在 Google Play 頁面上的 try now 按鈕，透過統計發現，有支援 Instant App 的遊戲，增加了 20% 的使用者。

現在 Instant App 也加入了 Pre-registration，當你 Pre-registration 後，透過社群媒體、e-mail 等，使用者可以從任何 Android 設備即時玩該遊戲。

Instant App framework 也做了一些調整：

• 將遊戲容量限制提高到 10MB
• 提供漸近式下載
• 整合遊戲引擎，並支援 NDK 和 OpenGL ES

第三點最為重要，因為你就可以使用完整遊戲的程式碼為基礎來製作 Instant App；在 Unity 方面也新增了 Unity plug-in，而 Cocos 也在他們的 IDE(Cocos Creator) 中提供了 Instant 支援。

Migrate your existing app to target Android Oreo and above

為了優化耗電量及讓使用者有更流暢的設備體驗，Google 希望開發者能在今年底前讓 App target SDK 支援到 26 以上，否則在上架或更新部份將受到限制。

開發者在升級過程中會遇到的改變有以下這些：Runtime Permissions 的檢查及操作，Alarms 就不再精確，Broadcast Receivers 不再使用 manifest 註冊，而是透過 PackageManager.setComponentEnabledSetting 來開啟 receiver，但是在某些特定情況下目前還沒有替代方案像是 USB 配件。還有 ACTION_MY_PACKAGE_REPLACED 可以使用 PackageManager.getChangedPackages 的 API 代替。

當設備升級到 Android O 之後如果 starting a service from the background 會拋出 Exception，如果想在背景執行一些程序，例如：地圖定位、跑步軌跡或是聽音樂，建議使用 WorkManager 和 JobIntentService。在 Android O 以上必須增加 Notification Channels 通知才能正常顯示。

最後還要針對目前有瀏海的手機進行顯示優化，像是不要假定狀態列有多高、不要想像畫面能夠完整的顯示在螢幕上，處理 MotionEvent 時，請使用 MotionEvent.getX() 和 MotionEvent.getY()，而不要使用 MotionEvent.getRawX()，MotionEvent.getRawY()，並且支援 multi-diaplay 讓你的 App 不管在什麼長寬比例尺寸的螢幕都身如其境。

最後，開發過程中如果有需要測試睡眠或是待機的狀態，可以使用 adb 提供的工具。

Sound Amplifier and the new Dynamics Processing Effect

在 Android P 提供了新的聲音放大器 (sound Amplifier) 及動態處理效果 (Dynamic Processing Effect)，這個 session 主要在探討這兩個新功能，而目前 Dynamic Processing Effect 已加入到 AOSP (Android Open Source Project) 中供給 OEM 及每個應用程式開發員使用，讓每個製造商更有能力及意願去使用調整內部的音頻增強技術。

在日常生活裡環境噪音是最不需要的聲音之一，常常會干擾與朋友的交談，目前 Google 增強了手機上的訊號引入了 Sound Amplifier幫助用戶可以專注於對話。

目前在 APP 裡音量增強使用了兩個拉動選項，一個是可以拉動調整聽到的音量，另一個拉動是可以調整瀘波器的強度以過瀘背景不需要的聲音。因此用戶可以從背景噪音中分辨出說話者的聲音。

Dynamic Processing Effect 分了四個階段的信號處理 :

• Pre-EQ 允語開發人員設置頻寬的數量及寬度。
• Multi-Band Compressor 壓縮器可以平穩的降低音量以獲得比較好的聲音而擴音器則可以轉換並增強安靜聲音的幅度，因為是不同的頻率通過不同數量的壓縮或擴展，所以這是可以非常方便的處理背景噪音。
• Post-EQ 這階段是微調輸出的訊號。跟 Pre-EQ 工作方式一樣，開發人員可以控製過濾器。
• Limiter 這主要防止過於大聲的聲音並保護輸出的裝置。

Top 5 Android announcements at Google I/O 2018

影片只有幾分鐘，說明這次 Android I/O 左五大重點宣傳，就醬

• Android App Bundle
• Android Jetpack
• Kotlin
• Slices
• App Actions

Upgrade to Firebase Cloud Messaging

FCM 相較於 GCM 有更多優點，像是 Analytics、A/B Test、Predictions 等，強烈建議還在使用 GCM 的開發者改用 FCM，GCM 轉換到 FCM 的步驟很簡單

• 在 Firebase 設定頁面新增你的 app
• build.gradle 變更 play service GCM dependencies 為 Firebase Messaging
• 移除 GCM 相關 Receiver 程式碼
• server side GCM endpoint 改為 FCM endpoint
• 改用 Firebase Messaging Service 與 FirebaseInstanceIdService
• 搬移 GCM 處理收到訊息的程式碼到 receiver 與同名 method 中

幾項 FCM 的注意事項

• 支援自動重試（auto retry）機制
• 不要在同一個 app 同時使用 FCM 與 GCM
• 每個 app 僅儲存一個最新的有效 token
• 定期性更新 token 保持有效性

最後提到了 FCM 針對耗電量的優化項目與 PM、RD 的 Q&A 時間

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