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 下集

Android themes & styles demystified

本篇介紹 Android theme 與 style，兩者在技術上都是使用 <style> 標籤，差異之處在於如何去使用它們

兩者相同都是 “key/value” (屬性/實體) 的組合，屬性不止是 key，同時也定義了 value 的 type 讓系統可以正確的轉換成指定的形態
resource types:
[fraction] [float] [boolean] [color] [string] [dimension] [integer]
special types
[flag] [emun] [reference]

定義一個屬性的方法:
宣告屬性 名稱[name] 格式[format]
<attr name=”background” format=”color|reference” />

使用 Android 定義好的屬性需要宣告 Android namespace
<xmlns:android=”http://schemas.android.com/apk/res/android” background=”…”>
也可以自定義屬性 (但 namespace schema 不能與 Android 或其他自定義相同)
ex. <xmlns:app=”http://schemas.android.com/apk/res-auto” app:customAttr=”…”>
自定義 namespace 最後的 “res-auto” 實際是指向專案的 package name

在 AndroidStudio 當中提供了一個很棒的功能在 Layout 模式下> Refactor> Extractor Style … 可以將該 View 的各個屬性抽換成 style 並且找出在其他 Layout 裡的 View 是否有相同屬性組合並自動使用 style 替換

Material Themes
通常以 “Theme.Material” 開頭 (Theme.Material.)
Added in Android 5.0 (L):
– ThemeOverlay.Material.: 繼承 Theme.Material 並且 override 亮色與暗色主題的相關屬性
ex. “ThemeOverlay.Material.Light”、”ThemeOverlay.Material.Dark”
– TextAppearance.Material.*: Material 文字相關屬性
ex. “TextAppearance.Material.Title”、”TextAppearance.Material.Button”

Added in Android 6.0 (M):
ThemeOverlay.Material.Dialog: Material Dialog 樣式屬性

Added in Android N:
– Widget.Material.*: Material Widget 相關屬性
ex. “Widget.Material.SeekBar.Discrete”

從 API level 21 開始，可以使用 ColorStateLists 和 theme 在 xml 中作為屬性去定義 drawables。theme 屬性支援 ColorStatesLists 則是從 API Level 22 開始，另外，Support Library v24.0 的 AppCompat 也開始支援 ColorStateLists 操作 ex. “AppCompatResources.getColorStateList()”

Android N 新功能 夜間模式 (Night Mode)，使用 “-night” 修飾詞 (qualifier) 可以定義夜間模式的樣式屬性 ex. “res/values-night/styles.xml” 此功能也已經加回 API 14 當中

如果你想在一個 App 中定義 ActionBar 與 Content 的樣式亮暗不同 (Light/Dark)，單純透過繼承 “Theme.Material.Light” 或 “Theme.AppCompat.Light” 是相當難做到的，定義 ActionBar 樣式現在可以使用 “Theme.Material.Light.DarkActionBar” 或 “Theme.AppCompat.Light.DarkActionBar”

最後提醒開發者常發生的錯誤，在定義一個 style 時，要注意是否要被特定的 Widget 所使用，如果是，應該要繼承該 Widget 的 style 來保持特有的相關屬性 ex. EditView 定義 style 時應加上 <style name=”…” parent=”android:Widget.Material.EditText”>

 

What’s new in Android security (M and N Version)

本篇主要在講有關 Android 安全性的問題，講者先點出在 Android N 主要的改變有：

• File Based Encryption
• Media Server Hardening
• Automatic Updates

每天有 10 億以上的裝置掃描安全性，另外每天有 80 億以上的 apps 檢查安全性

另外分成七個主題來探討安全性問題：

1. Runtime Permission
   在 Android M 時加入，App 會在 runtime 時才去要求權限，且使用者可以獨立控制各個權限。透過這個權限，可以讓你簡化你的安裝流程，因為不需要一開始就要求各種權限，也使得升級更加容易。使用者更能清楚瞭解到發生了什麼事情。Google 也提供了一些 Best practice 在網站上供大家參考，以提升使用者給予權限的機會

2. Android Keystore
   Hardware-backed key storage 硬體支援的金鑰存放區為 Android 裝置上密碼編譯金鑰的建立、儲存及使用提供更安全的方法。App 可以安全地建立與儲存 RSA, ECDSA, AES 與 HMAC keys。在 Android M 作業系統的以上幾種，可以設定成只允許在使用者授權的某給時間內才可以使用 key。在 Android N 引進了 Key Attestation 的功能，他讓金鑰在出廠時就已內嵌到其中的硬體支援金鑰存放區，這可以讓你驗證這是一個合法的機器。

3. Authentication
   他們發現太多人不使用安全鎖螢幕，因為很多人覺得這件事情有點煩躁及太常出現，因此他們提供了一個更簡單的方式，使用指紋 (Android M+)。另外他們讓 App 的某些功能只在加上安全鎖，並且授權後才能使用。Credential verification in hardware 以及將 authentication 移至 Trustzone，即使系統被入侵都無法取得像是指紋或密碼等機密訊息。另外在 Android M 也提供了 Fingerprint API。

4. Secure Networking
   在 Android M 以後多了 android:usesCleartextTraffic，在 AndroidManifest 裡面的 application tag 加上這個屬性，
   可阻擋/開放 insecure traffic，在 Android N，可以設定 domain level rules 來控制各網域的設定，另外也可在設定 debug-only CA，讓你可以用在 debug 環境中

5. Storage Encryption
   Android Marshmallow 以上的裝置都會要求 Encryption。Android N 以上的裝置從硬體方面來支援這項需求
   在 Storage 這塊也支援 Direct Boot，重新開機後，在解鎖之前，電話、簡訊、TalkBack 以及鬧鐘可以正常使用，為支援 Direct Boot，系統為資料提供兩個儲存位置，預設情況下應用程式不會在 Direct Boot 下執行，需要使用這個 feature，可以在 AndroidManifest 的各個 component 加上 android:directBootAware

– 認證加密的儲存空間：預設的儲存位置，只有使用者解鎖裝置後才可使用
– 裝置加密的儲存空間：Direct Boot 模式期間與解鎖後都可使用的位置

1. Verified Boot
   在 Android M，開機時系統會警告使用者系統被修改，但到了 Android N 將會無法開機，Android N+ 也在 Verified Boot 加入了 Error correction，他可以修正一些狀況，例如他會讓 Root 的功能無法使用。透過呼叫 SatetyNet API，可以讓開發人員了解你的 App 運行裝置的情況，例如是否為實體機器，或是未通過 CTS compatability check。另外，官方推薦做離線驗證，檢查 nonce 是不是由你的 server 所發出來的，其他還有一些欄位，可以照你的需求來進行驗證。透過檢查 Android Security Patch Level，可以知道最後一次做安全性升級的時間，Android K+ 以上即可透過 android.os.Build.VERSION.SECURITY_PATCH 來查看

2. Sandboxing
   Google 使用 SELinux 與 Seccomp 這兩個工具在 Android N+ 做了許多與 MediaServer Hardening 相關的事情。Seccomp 是一個 Attack surface reduction 的工具，利用減少 Attack surface，他可以用來保護系統避免受到你的 app 的影響。
   Google 目前已使用在 MediaServer，他將 MediaServer 拆成很多個部分，像是 AudioServer, CameraServer, ExtractorService, MediaCodecService, MediaDrmSErver, MediaServer等等，Google 使用了 SELinux 在 Android 上，現在開發者也可以在自己的 app 中利用 Seccomp 來保護系統。

另外他們也對 Device Admin API 做了一些限制，以避免一些像是勒索軟體的行為，像是除了在 Profile Owner Mode 或 Device Owner Mode 之外，不能改變已存在的密碼，以及目前所有的 Device Admin Apps 都可以被移除。

 

What’s new in Android development tools

這次更新分成四大方向：Design、Develop、Build、Test

在 Design 方面
Android Studio 2.2 提供了全新 Layout GUI 設計功能，Layout Editor，將幫助不懂的 XML 開發的設計人員也可以輕易的拉出 UI
並且， Google 提供了一個全新的 Constraint Layout，有如 Relative Layout 的威力增強版，可以根據不同的點或 View 當定錨點、設定與螢幕的邊寬、百分比設定，幫助降低 Layout 層級，配合 Layout Editor，非常強大。別因為拖拉出的 UI 而擔心效能不好，Google 還提供了 Layout Inspector 幫助你檢查效能不好的地方並自動修復。
Develop 方面
Google 加入了 Firebase 的支援，幫助你在撰寫 Firebase 時可以更方便解決問題，而當使用 Android API 遇到問題怎麼辦？沒問題，Sample Code Search 功能能快速幫你找到此 API 的 Sample Code 而在釋出時將會增強 Lint Analysis 、更新成 IntelliJ 2016.1 以及加上幫助撰寫 Accessibility 的功能增強了 Debug 功能，使得 C++ 也可以使用 breakpoint 了 IDE 也全面支援 C++ 的開發，使得開發 NDK 更加方便

Build 方面
首先，IDE 更新 SDK 可以在背景執行了，並且 Gradle 可以在 grade.properties 中設置 Build 當有新版時即可自動更新 Android sdk 套件 幫助 CI Server 不用每次手動更新，Google 明白 Build 時間是 每位開發者最在乎的事情，因此 持續努力 Instant Run 的效能，當 Hot Swap 能快達到 10x 的效能，而 Cold Swap 也能快將近 ４x，請大家多多試用給他們多點 Feedback 去改善。在過去AAPT，每次新增 resource 就會會重新計算一次 id 造成 code swap， 2.2 將讓所有 id 為 constant 這樣就會促使更多的 hot swap，而在 Android 6.0 加入的 Jack Compiler 將支援 Java 8 Annotation 將可讓 Jack 客製化各種 pre post processing for class，還有個重點是是整合了C++ 的 NDK、CMake Build 讓整個流程更有效率。

最後 Test 方面
最重要也最讓人心份的地方就是 Espresso 將支援 Record 了！！不必會撰寫程式就可以寫出許多測試腳本，這絕對是測試人員的福音
還供了雲端測試功能，不過現場因時間的關係沒有 Demo。另外也大幅增加 Android Emulator 效能，官方宣稱新的模擬器快過 Device、ADB 將會快 10x，並提供新的 UI介面、 Sensor Controls 功能，整合 Firebase 工具幫住更容易去測試，以及提供了 APK Analyzer 讓你可以看 APK 結構想辦法瘦身。這次的 Android Studio 更新功能全面性大幅提升，令人非常期待

 

Best practices in media playback

本篇的目地在於告訴大家在正確的時間點使用正確的 API 來創造最好的影音播放 APP，主要分為兩個部份， Android lifecycle 和 User interactions.

Android life : 隨著 Android lifecycle 去改變 media playback 的狀態 ：
Android N 以前的版本，進入 onPause() 就是不可見的狀態了，但不一定會馬上進入 onStop()，而開發者不會希望自己的 Video 在背影還在播放聲音跟影像，所以在 onPause() 就停止播放是最好的選擇。
而 Android N 新增了 Multi-windows 使得 APP 能並存在畫面上，只有在 APP 進入 onStop() 變成不可見的狀態時才去停止播放。

User interactions : 與使用者互動的變化又分為以下四種

1. Audio Focus：

– 開始播放前必須先 request audio focus，得到結果為 AUDIOFOCUS_REQUEST_GRANTED 時播放，但在少數的情況下沒辦法取得 audio focus，像是當你正在講電話時，最後要記得在停止播放音樂時 abandon audio focus。
– 使用 OnAudioFocusChangeListener 監聽 audio focus 的變化，若接收到 AUDIOFOCUS_LOSS 停止播放、AUDIOFOCUS_LOSS_TRANSIENT 暫停播放、AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK 降低音量播放。

1. ACTION_BECOMING_NOISY

– 當你插著耳機播音樂時，拔掉耳機，接著音樂會從喇叭播出，像這種突然切換成從喇叭播出的情況下，很可能會嚇到使用者，我們需要註冊一個 Broadcast Receiver 接收 ACTION_BECOMING_NOICY 事件來暫停音樂，並且在暫停音樂時反註冊這個 receiver。

1. MediaSession

– MediaSession 生成一個 token 能夠讓 Android system, Android wear, Android auto…等不同的 process 透過這個 token 創造 MediaController 來對 MediaSession 做控制或取得 metadata, playback state.
– 當你創建一個 MediaSessionCompat 後必須使用setFlag 來設定所要接收的事件， 並且使用 setActive 開始接受 command，接著再用 PlaybackState 設定目前的播放狀態，以及 MediaMetadata 儲存音樂的 metadata. 要注意的是在 Lollipop 以前的版本中使用 MediaSessionCompat 必須要先在 Manifest 中加上 MediaButtonReceiver 來接收 MEDIA_BUTTON action , 若是在 Lollipop 之後的版本可以用來 restart playback.
– 對於播放音樂的 background service 可以用 MediaBrowserServiceCompat 再呼叫 setSessionToken 來設定 token, 除此之外還有 onGetRoot, onLoadChildren 兩個對 Android Auto 很重要的 method, 但對目前的主題來說只需要知道成功連上會回傳不是 null 的東西. 接著再使用 MediaBrowserCompat 連上 service, 當成功連上時就可以使用 getSessionToken 取得所需要資訊
– 當音樂正在播放時, 我們希望他持續播放的話, 就可以使用 foreground service 搭配 notification , 但這個 notification 是無法被滑掉的, 在 Lollipop 之前的版本就算 foreground service 已經停止了, notification 還是沒辦法被滑掉, 因此我們 用 MediaStyle 解決這個問題, 基本上就是在 notification 的角落上加上叉叉.

1. Media Notification

– 講者提供了自己寫的 MediaHelper, 只要傳進 context 和 MediaSession 就會幫你建好 Notification 所需要的東西, 當建好 Notification 後就可以從 MediaMetadata 中旳 getDescription 取得 MediaSession 所儲存的 metadata 並顯示這些資訊. 除此之外還能再重複利用 MediaButtonReceiver 來接收 notification 上的 action.

 

What’s new in Android Wear 2.0?

在過去，Android Wear 1.0 需要和手機連動才能使用，必須要透過藍芽跟手機串連，透過手機才能和雲端服務溝通然而 Android Wear 2.0 時，Wear 裝置不在需要和手機綁在一起，可以單獨使用，當然原先透過藍芽連接手機的方法還是存在的。

錶面依然是大家喜愛的一個項目，但過去只能更換錶面的 UI，更多時候，使用者更想把一些資訊也放在表面上，新的 Android Wear 2.0 就可以做到這件事情。使用者在使用 Android Wear Message，更多時候是會想快速回應這個 Message，Android Wear 2.0 也考慮到這件事情。

講者將 Android Wear 2.0 的特徵分成五個項目一一解釋

1. New User Interface
   Quick Setting (由上往下滑)方便使用者快速設定亮度，連線，音量，鈴聲等設定。
   Hardware button，會產生一個弧形的 App 瀏覽畫面，也能當返回鍵。
   在 Material design for wearables 的議題中，講者提到在 Wear 1.0，滑動的方向太多了，讓使用者非常困惑，於是在 Wear 2.0，把滑動方向改成單一化，讓使用者更加方便操作，另外增加 Action Drawer 和 Navigation Drawer 方便使用者瀏覽。在 Expanded notifications 的單元，則是提到使用 Expanded Notifications 讓對話過程更加順暢。在 Android Wear 2.0 官方推薦使用 darker UI，好處是能減少電力消耗，更適合於社交場合使用，比如說在看電影的場合

2. Standalone Apps
   Wear 裝置本來都需要透過 phone app 當中介點才能和 cloud 溝通，Android Wear 2.0 則希望消弭這一點限制存取資料的部分，Wear 可以直接的存取網路上的資料，不需要透過手機才能夠存取網路。Authentication，Wear 將會獨自管理自己的 Authentication。不再依賴手機幫忙處理 Notification 的部分，原先 Wear 需要和 Phone 建立 bridge 才可以顯示 Notification 的功能，在 Android Wear 2.0，因為本身可以是一個獨立的 App ，就可以不需要 bridge 的功能，開發者可以自行將 bridge 的功能關閉，並且直接使用 FCM/GCM 的功能。App downoload 的部分， Wear 可以獨自去 Google Play 下載 Wear 所需的 App

3. Watch Face
   新的 Complications API: 可以在表面顯示 complication 資料，API 的流程如下：OS 發送取得資料需求給 Data provider， Data provider 回送 Complication data 給 OS 後 OS 再將資料回傳給 Watch face

4. Messaging
   使用 Expanded notifications 讓 messages 回應的流程更加流暢。New input methods:handwriting, keyboard, Smart Reply, and 3rd party IMEs

5. Fitness
   Google Fit platform 可以自動辨識使用者在做什麼樣的活動，比如說跑步，或是在體育館做運動並且收集這些運動的紀錄。

 

What’s new in Google Play for developers

無論對於使用者或是開發人員，Google Play 都是一個簡易操作的Android軟體發佈平臺，從以前到現在，我們也在上面看到了很多極為成功的案例，新創公司成功的在 Google Play 上崛起並發展。

在 Google 發展各式產品的時候，他們成功的以用戶的回報來打造出適合每個人的產品，他們希望將這樣的方法提供給每個開發者，所以在Google Play上加入了回報的功能，讓開發者可以輕易接觸到全世界的用戶。

Firebase 是一個使用真實裝置測試的雲端測試實驗室，他可以與 Android Studio 整合，或由Firebase控制台來執行測試，他可以協助您在許多的機台上做 Alpha 與 Beta 測試，並針對發生的問題提供一份報告，測試的過程中，也能產生一些螢幕擷取，這可以讓您瞭解在不同螢幕尺寸、不同 Android 版本、不同語言下，你的設計排版是否恰當，另外現在也提供了測試階段的 APK 的安全性分析，以前我們只提供上線後的版本的分析。

目前前 1000 名在 Google Play 上的軟體有 60% 有進行 beta 測試，他們發現 Beta test 通常可以改善很多用戶體驗，測試用戶可以簡單的私訊回報使用上的問題，這些為報並不會造成軟體評分下降，現在他們提供了一個新的開放式早期體驗測試，在軟體上線之前讓你可以得到各種測試回報。

之前他們在 Google Play 上實驗一種讓使用者更容易找到他需要的軟體的新方法，這個方法透過時間與目的來尋找在當下使用者可能需要的軟體，他們研究發現大部分的下載都是在當下需要的時候發生，舉例來說，當使用者搜尋背景桌布相關程式的時候，不只提供桌布相關軟體，而是一併提供其他個性化軟體，他們會針對使用者看了哪些軟體、使用者的興趣與使用者目前可能的狀態來決定要提供什麼樣的內容，不只在搜尋的時候會出現這些相關軟體，當使用者到某處旅行的時候，我們也能在首頁提供當地旅遊相關的軟體。

在 Google Play 後台中，目前提供了一些新的分析數據，其中 Topic 可以讓你知道在所有評論中較常出現的關鍵字、他們出現的數量與趨勢，與這些關鍵字對你的軟體評分所造成的影響是什麼，Benchmark 則提供了固定幾個關鍵字的分析，如設計、穩定性、速度、資源使用等等，從這些分析中，你可以快速知道要改善評分最需要努力的方向是什麼。
目前這些分析指提供英文版本，並且需要足夠數量的評論才有辦法產生，現在他們也提供了 review api 可以得到 review 的資料。

在發展中國家的新興市場上，他們發現使用者擁有的網路連線能力、花費與手機規格都是對於 Googe Play 的一個很大挑戰，他們想要提供一個快速、可靠、低資料用量的商店環境，他們所帶入的一些改變，也確實的改善了使用者經驗，不同區域、不同連線能力的使用者，他們也提供了不同的樣式與內容策略，讓使用者更容易找到他們所需要的程式也更順利的使用，針對網路限制，他們設計了離線使用、內容快取、讀圖 Library，來提升使用經驗。

針對裝置限制，建議做 Layout 設計時使用 Density-Independent Pixels (dp) 並特別針對 ldpi, mdpi 螢幕做測試，盡量優化記憶體用量與減少長時運算工作，針對連線花費，他們建議減少圖檔、使用 SVG 與 WebP，用 Proguard 來減少 apk 大小，並考慮使用多個 apk。另外 Google Play 開發人員後台終於有自己的 app 了，大部分網頁版的內容都可以在手機版上使用，也能收到很多事件的通知。

在 Android Jelly Bean 以後，Android Instant App 可以讓使用者不必安裝，直接點擊連結就能迅速開始使用您的程式，以下步驟可以使您的app支援 Instant App
– 增加 Deep Link
– 如果程式規模較大，建議把程式分成模組
– 畢竟只是部分程式，所以使用者可能沒預期到某些功能無法使用。所以建議處理這些狀況。
– 另外 Instant Apps 也提供了一些全新的功能，例如運行中權限處理

 

The experts’ guide to Android development tools

這是一場由 5 位 Android Studio engineers 共同分享的課程，除了 Tor Norbye 是 Studio Tech Lead 之外，其他 4 位各是不同工具的開發人員，例如 debugger、Build system、Profiling 等。這幾位大神分別上台介紹 Android Studio 中他們各自最喜歡的開發小技巧，依序如下

開發小技巧：
在 Tools/Create command line launcher 可以輸入自訂的字串，完成後這個字串就可以做為之後在 terminal 中使用或啟動 Android Studio 的 command，你還可以使用 —-help 或 diff 等指令 terminal 下操作各式 Android Studio 內的 tool。

使用 Control + Shift + J 可以將多行程式碼，甚至分割開的字串自動結合。

在使用 + 串上常數或 resource string 的程式碼使用右鍵中 Copy Stringconcatenation text 可以複製結合完成的字串。

在置換掉 method 時例如把 a.contains() 換成 a.equals 時若按 enter 會發生 equals 被貼在 contains 前面的狀況，這時後可以改用 tab 來取代 enter 達到置換 method。

在 if (o instance of IO) 的範圍內使用 option + enter 可以快速加入將 o 轉型為 IO 的物件宣告程式碼。

影片大約在 7:26 時介紹了一個叫 Multicursor 的技巧，這是一個在多行之間利用 Control + G 選取相同字串，再搭 Option + 右鍵選取不同長度的字串快速將多行修改為同樣流程的技巧，雖然 Option 加上滑鼠選取也可以做到多行選取，但 Control + G 方便之處在於多行間的起點不必相同，極方便，建議親眼看看。

使用 Cmd + F12 列出類別內所有 functions 且可以加上 enter 快速跳至該 function，或是利用 Ctrol + Shift + 數字做 Bookmark 並使用 Ctrl + 數字快速捲至該書籤。

如果你想要把一段流程抽成另一個 function 時，可以利用 Option + 上、下鍵來移動，Android Studio 會自動幫你選取合乎邏輯的片段。

接下來是像 ints.forr 或 o.nn 等很常用的 code snippet。

在複雜的 if 判斷式內，如果你想將某個 || 換成 && 其實是件危險的事，這時可以按右鍵讓 Android Studio 幫你做，在影片的 13:00 處，相當方便。

使用 Cmd + Shift + A 輸入 Local History 可列出 File History。

除錯小技巧
在 function 中使用 Debug.waitForDebugger() 指令可以在 Debugger 啟動時才開始執行之後的指令，避免流程在另一個 process 中被呼叫失去偵錯的機會。

在中斷點按右鍵可以加入 Condition 讓特定條件時才中斷，對於非中斷的條件時也可以自訂輸出 log，對於想查看特定列表式元件的 Adapter 或迴圈裡面的資料時相當有幫助。

在 Deubgger 的 Watch 視窗中觀看變數時，可以從右鍵的 View as 選擇想依什麼格式看這筆資料，影片中舉了 long 變數但選擇 view as timestamp 的例子。

在 NDK 方面可以一鍵產生 JNI function 也可以下中斷點，同時已支援 STL 所以可以使用 vector 等更方便的容器，且 STL 的 object 在 Watch 視窗中也是可以觀看的。

Gradle
現場 demo 了在 API 21 以上及以下針對 multiDexEnabled 的 App 在編譯時的速度差異，在 API 21 以上因為有新的 multiDex 技術所以快了非常多，如果搭配 gradle 2.2.0 可以再更快，若再 enable instant run 後還可以再更快，但若是修改 AndroidManifest 等內容，因為必須重新編譯整個 App 故仍無法享受到新的加速功能。

 

Building rich fitness experiences with Google Fit platform and Android Wear

影片在介紹透過 Google Fit 平台與 Android Wear 建立豐富的健身體驗，Google Fit 平台解決了手機與手錶間要傳遞與紀錄資料的問題，Google Fit Platform 透過一組共享的 API 訪問、記錄和儲存各 Sensor 傳來的資料。

手錶比起手機更適合搭配健身使用，帶有 GPS Sensor、心臟監測儀等，因為戴在手上，所以更容易測量，相較起來手機就顯得笨重些，在手錶上傳數據至 Google Fit 平台後，可同步至 mobile 與 web， Google Fit 並提供了這四個 API 可供使用 SensorsAPI、RecordingAPI、HistoryAPI、SessionsAPI。

在新的 Google Fitness 也優化了一些數據的計算，如距離、熱量、從 mobiel 銜接數據至 Wear 上時的落差，以及穿戴者的活動，透過融合步數、位置及速度來優化。透過步伐跨度的計算，在 Wear 上不需要 GPS 也可以測量距離。在活動的偵測上，目前也可以從使用者的行為自動判定你在做何種運動，並提醒你運動的姿勢可能不準確。

目前 Google Fit 平台上收集到的資料是即時的，這在各個 app 間要取得數據時才會是準確的。其他還有新增一些好用的 API，如偵測心跳頻率的 Beat to Beat API，可用來計算 BPM； 可以取得用戶年齡、性別、身高和體重資訊的 ProfileAPI；可以設定步數、活動時間、距離和熱量消耗的目標與進展的 GoalsAPI。

 

Advanced Espresso

Espresso 是 Google 官方提供的 Android UI testing framework，Espresso 的寫法大概可以分成以下幾個步驟：

1. viewMatchers，找到要執行的 UI 元件。
2. viewAction，加入該元件要執行的動作。
3. viewAssertions，驗證元件執行的結果。

從以上流程可以看出 Espresso 最大的優點就是寫法簡單，即使在測試過程中有切換頁面的動作，我們也不需要為此多寫一些 callback。

Espresso viewAction 一定要 run 在 main thread，從 doPerform() source code 可以看到裡面的 uiController.loopMainThreadUntilIdle() 會等到 main thread 沒事做的時候才會去執行 viewAcition，這也就是為什麼我們不需要多去寫一些 UI callback 的原因。

uiController.loopMainThreadUntilIdle()
uiController 會先去檢查有沒有 async tasks in your app and support lib，再檢查所有 idling resource 告訴 Espresso 你的 app 是否閒置中。當以上條件滿足時，uiController 會 loop a thread 去看 main looper 裡面的 message queue 有沒有 pending event，只要 message queue 是空的或者 event pending 的時間大於 15 ms，這時候 Espresso 就可以開始執行。

除此之外， uiController 還提供了 loopMainThreadForAtLeast(millis) method 可以用來實作 custom viewAction 需要 thread sleep 的功能。

Tips / Recipes

1. 在每個測試案例之間如果需要用到相同的 code，盡可能的先做抽象化而不要使用複製貼上，以減少後續維護的負擔。
2. 如非必要情況，盡量只使用 Esspresso 現成的 api。
3. 與其自己寫 custom idling resource 不如直接使用 CountingIdlingResources，在執行長時間動作之前先 call increament() 執行結束實再 call decrement()，
   這樣當 counter 等於 0 時，Espresso 就可以知道現在 app 已經處於 idle 狀態。
4. 測試案例盡量專注在測試行為而非 layout 屬性，否則當設計師改動畫面時，你的測試程式也要跟著到處更改。
5. 用多個小的測試案例去取代一個完整的測試流程，盡量去做到可以測試每一個頁面的每一個步驟。
6. 大部分的 UI 測試都要盡量封閉，Espresso 就只針對 View level 測試，mocking 可以使用 mockito，在開發過程中把測試分層，避免互相干擾的狀況。
7. 當測試案例如果需要傳送 intent 到其他 app 時，請使用 Espresso intents。
8. 大部分的人在使用 Espresso 都會遇到測試案例會卡在 UI 動畫，最好的解決方法是在 Espresso 執行之前先把動畫關掉。
   Developer tools 裡的 Show surface updates 可以幫你檢查 app 裡有哪些 UI 動畫會讓 Espresso 卡住。
9. 當 test fail 的時候 ，Espresso 提供詳細的 error message，告知錯誤的地方與修正的方法，當資訊不夠時，
   也可以自己寫一個 FalureHandler 來提供更多的 debug info，同樣的，如果當 Espresso 提供的 error message 太詳細，
   也可以透過 FalureHandler 來精簡 debug info。
10. 當你希望開發完的 app 是可以給全部人都使用的話，可以透過 Espresso 提供的 AccessibilityValidator.enable(）來為無障礙情境做測試。

 

Android Wear 2.0: Making Watch Apps more Standalone

在 Android Wear 2.0 相較於 1.0 版本加強了對於獨立運作應用程式的支援，讓我們首先來談談，為何需要能在 Wear 上獨立運作的應用程式

1. 使用更加便利：像是當你外出跑步運動，可能不希望把手機帶在身上，或是手機放在包包裡面要拿出來使用不方便或是當手機沒電甚至故障無法使用

2. 開發更加快速：由於 Android Wear 的程式開發與手機裝置非常相似，所以如果應用程式已經有開發過手機版本就能以手機版為基礎，快速簡單的開發出 Android Wear 版本

3. 支援 Android & iOS 裝置：Android 手錶 (wearable) 可能會連線到 Android 或是 iOS 系統的裝置，如果能獨立運作，就可以做到支援多系統但 UI 顯示一致

在 Android Wear 2.0 的改變
– 可以支援連線 Android & iOS 兩種系統裝置
– 更好地支援獨立應用程式的開發，2.0 可以直接網路連線，所以往後可以不透過手機直接存取雲端資源，資料可以經由 Shared Preferences、SQLite 或 Internal Storage 等直接儲存在手錶。補充說明，當手錶使用藍芽連線到手機裝置，就會透過手機進行網路連線，如果手錶裝置超出連線範圍，將會使用手錶硬體層進行網路連線
– 支援 Doze 功能，延長電池使用時間的一種機制，Android 6.0 以上支援，裝置在閒置一段時間之後會啟動 Doze 模式，背景執行的應用程式會停止網路功能 （除了某些特定程式 ex. 鬧鐘），直到 maintenance window 階段才會允許等待中的背景程式可以短暫執行網路，然後再度進入 Doze 階段，以節省電池電量的消耗，搭配 JobScheduler API 可以排定進入休眠的工作，系統會自動判斷喚醒的時機，達到省電的效果
– Auth，手錶裝置上若需要認證應注意以下事項:
– 在真的需要認證資料的時候才去要求使用者進行認證
– 可以考慮保存認證的資料在本地端
– 使用簡單容易的認證流程

認證方式整理:

[已支援]
● Token Over Data Layer: 透過手機開啟登入畫面，輸入帳號密碼等資訊認證後，經由資料層 (Data Layer) 回傳 token 給 wearable，目前不支援 iOS
● Activity on Watch: 直接在手錶上開啟登入畫面，缺點是輸入資訊所使用的虛擬鍵盤不好操作

[即將支援]
● Google Sign-in: 使用 Google 綁定帳號登入，方便快速並且支援 iOS
● SmartLock for passwords: 經由 Google 帳號在各個裝置間同步認證密碼
● OAuth for URL: OAuth 2.0 透過手機經由打開 OAuth URL 跟 Server 進行認證
發送認證 token 通知 Wear 裝置，並且支援 iOS

Notify 方面有 Firebase Cloud Messaging (FCM) 可以直接從雲端發送訊息給 Wear 裝置，支援 Doze 模式並且可跨平台，如果同時開發了手機與手錶獨立運行版本的 app 並且俱有支援 FCM 的功能，這會使得手錶與手機裝置發生收到重複訊息的問題，Wear 2.0 提供了以下兩個解決方案
– 手錶端不顯示手機已經收到的訊息，設定取消 bridging
在 wearable app AndroidManifest.xml 設定
<meta-data
android:name=”com.google.android.wearable.notificationBridgeMode”
android:value=”NO_BRIDGING” />
– 手機與手錶裝置，不顯示已關閉的相同訊息 NotificationCompat.WearableExtender 提供了 setDismissalId() 當相同 id 中，其中一則通知已被閱讀或關閉，其他訊息系統會自動關閉

Distribution and Installation
Google Play 現在可以單獨安裝獨立運行的 wearable app 不再需要手機端安裝 bundles APK，可以像是手機或平板獨立針對裝置 feature 直接下載 APK 安裝 <uses-feature android:name=”android.hardware.type.watch” />

 

Material improvements

這場要講的是 Material Design 的原則及如何應用到你的應用程式，講者先提供了他所做的 App 叫做 plaidapp.io
以及它的程式碼，並從其中教你 Material Design 的原則，網址：github.com/nickbutcher/plaid

1. Material Surface：所有的 UI 都存在於 Surface 上，這些 Surface 可以有不同的大小、形狀與高度，所以他可以幫助你建立分層的概念

2. 使用 Color, Typography, Space & Imagery 來呈現事物，可以使用 Palette 來得到影像的調色盤，藉由 RippleDrawable 來建立按圖片按鈕時的波紋效果，或是用 Palette 來改變 Status bar 的顏色，假設圖片是放在 HeaderView 上，你可能不需要整張圖的顏色，而是設定圖片上方的一部份，來抓取調色盤以供設定 Status bar 的顏色。另外，可以根據 ColorUtils.colorToHSL 決定 status bar 的色調，如果是屬於偏亮的色系，可以使用 View.SYSTEM_UI_FLAG_LIGHT_STATUS_BAR 讓 wifi、電池、時間等變成黑色，所有的元件都會對齊8dp的方形基線網格，單字則對齊4dp的基線網格。工具列的圖像則對齊 4dp 的方形基線網格。

3. 有意義的動畫：這邊講者講了兩個範例，一個是顯示 List item，當點擊後先提升層級，接者展開背景，然後移動圖片，最後內容才進入畫面中。另一個是 Search View，會先做漸變並移動 icon，接著顯示 Search View，最後呈現結果。透過這些動畫能讓你知道下一步需要做些什麼事情，吸引你的眼球下一步該往哪走。

 

Your Apps at work

全球的商用軟體去年一年就花費 1430 億，是個很大的商機，而 Android 可以滿足大部分的功能需求及不同設備需求。依據不同需求，公司可以讓員工在自己的設備上安裝使用 (BYOD)，也可以由公司統一提供僅有 IT 允許應用程式的設備 (DO)，可以保證工作相關的資訊不會流出。

另外還有一種是提供給使用者 (不限定員工) 使用的，僅有單一或少量指定功能的設備 (COSU)，IT 可以簡單做好工作機設定，也可以遠端設定安裝軟體或下載資訊及資訊清理，針對 BYOD 的設備也可以僅對 for work 的 app 及資料做密碼需求，另外為了更好的用戶體驗提供了 always on VPN 和手機的 “工作模式” 開關。

針對企業的自訂外觀和參數已經可以經由下載參數包解決，RestrictionManager 可以幫助你取得參數包，另外還解決了 single sign-on 的需求；實作 single sign-on 的第一步，是在參數包裡加上 login_hint 以得知 SSO 的類型，並且也可以預先得到 username，第二步是使用新開的 API: Chrome Custom Tabs 配合 AppAuth lib 來讓各個 App 之間可以同步登入狀態，在 github.com/openid 有提供寫好的 library 支援 Android & iOS，並且支援 maven。

講者 demo 在貨物配送的情境 COSU 配合 NFC 的使用狀況，以及相關 NFC 的 data 寫法。注意在實作 single used app (COSU 用) 時，需要使用 startLockTask\stopLockTask 並在 manifest 中設定 lockTaskMode。

 

Bring Your Android App to Chrome OS

兩年前 ChromeOS team 開發了 APP Runtime for Chrome 讓 Android APP 能夠在 ChromeOS 上執行，但不幸的是這對開發者再開發上造成一定的難度，所以這次做了很大的改善，棄用 Native client，改用全新的 sandboxing mechanism
– sandboxing mechanism 特點：
– 使用現有的 Linux namespace 連結 Android 和 ChromeOS, 像是 mount, process, user, network, IPC
– 開發新的方式去新增 alternate sys call tables, 以增進系統安全性
– 同時有 Android 與 ChromeOS 做 compositing 會讓整個系統變慢, 因此有了 shared compositing model 來處理整個系統的 compositing
– 提供了 just-in-time binary translation 讓 ARM 架構的應用程式能執行在 x86平台的裝置上面

這次改善保留了 ChromeOS 與 Android 的安全性, 效能上因為沒有使用虛擬機或模擬器所以跟原生的一樣, 至於兼容性方面, 由於執行了整個 Android system 所以 Android Marshmallow 的應用程式(包含 Google Play Store )都可以在 ChromeOS 中使用的.

Android APP 與 ChromeOS 的整合中，有些部份像 ChromeOS, 如下
– Windows Management
– 每個 APP 都有獨立的視窗，像是 Windows
– 可在 ChromeOS 中接收 Android notification
– 只有一個 APP launcher
– 登入資訊是兩邊共用的，所以只需登入一次
– 能夠在 Download 資料夾中分享文件
– 硬體整合的部份，下列都是能夠使用的
– Wi-Fi, Bluetooth, Camera, microphone, audio, video
– 鍵盤、觸控版都是可以使用的，觸控的部份則要看 Chromebook 有沒有支援

除此之外還是有些功能是像 Android 的
– Marshmallow API 都是可以使用的，像是： permission, application lifecycle, Google Play Services… 除了這些以外沒有新增其他的 API
– System Service, Package Manager, Activity Manager … 也都正常運作
– 硬體的部份一樣用 HAL

最後，讓 Android APP 執行在 ChromeOS 上的這個功能是可以由使用者自行在設定中決定是否開啟！

 

Building for billions on Android

新興市場在 2019 年將會有 80% 的成長，我們必須要面臨三種挑戰
1. 在 2020 年，還是有 10 億的用戶使用的 2G 網路
2. 面臨各式各樣的網路速度以及連線的品質
3. 幫助使用者去管理他們的資料傳輸成本

為了要讓 App 解決這三個問題，講者從以下六個面向來討論該如何最佳化 App 分別為 Connectivity、Device Capability、Data Cost、Battery Consumption、Content、Commerce

1. Connectivity
   先前有提到還是有很多新興國家的使用者使用的是 2G 網路，因此 App 需要針對網路速度緩慢的情況下做最佳化的調整，這邊分成三個面向來討論：

– 最佳化網路資源
– 網路資源需要有優先權存取，先取得高度相關性的資料(文)，在取得需要比較高頻寬資源的資料(圖)。
– 不要做重複的事情，降低網路存取資源的量
– 根據網路調整行為，講者建議可以使用 connectivity manager & telephone manager 去偵測網路的頻寬，根據網路頻寬做最適當的調整
– 最佳化圖檔資源
– WebP 能減少網路讀取時間，節省網路使用量，並且使用比 JPG 和 PNG 更小的儲存空間
– 根據網路的頻寬和螢幕的大小去取得最適當的圖片
– 離線狀態下的使用者經驗
– 使用 Cache，即使在網路不佳的狀態下，也能使用先前 Cache 檔案來使用
– Image loading library，講者建議可以使用 Glide or Picaso 來做圖檔處理的 Library。

1. Device capability
   新興市場的使用者有各種不同 Android 版本，不同螢幕大小的機器，這邊提到如何最佳化記憶體使用和針對不同螢幕大小做最適當的調整，來增加使用者經驗的方法。

– Screen Sizes
– 為小螢幕裝置製造一個版本
– 最佳化 ldpi 和 mdpi
– 用模擬器模擬測試各種不同解析度的手機
– 有效率地使用記憶體
– 根據裝置的記憶體，App 必須要調整一些記憶體的使用，比如說使用 isLowRamDevice() 和 getMemoryClass() 幫助你瞭解這個裝置的記憶體限制進而調整 App 使用記憶體的方式
– 在 Android Studio 可以使用 memory monitor 去檢驗 App Memory 使用量。
– 有效的儲存空間使用
– cache 資料皆由 getCacheDir() API 來存取
– 讓使用者可以安裝 App 在 SD card
– 使用設定來測量你 App 的儲存空間使用量
– 兼容性
– 建議 targetSdkVersion 使用 23
– minSdkVerson 使用 14，目前 Android 版本的大宗是 14 和 16 的版本，開發者還是需要對這兩個版本做兼容性的開發
– Android Support libraries，提供兼容性的元件，讓舊版本 Android 也能使用新版本 Android 的功能
– Google Play services，提供一些有用的 API，像是 GcmNetworkManager

1. Data cost
   APK 檔案大小

– 減少圖檔的大小，除了之前所建議的 WebP 外，使用 SVG (Scalable Vector Graphics) 也能減少圖檔的大小，因為他使用的向量計算的方式，只需要提供一個檔案，SVG 就能針對各種不同解析度來產生圖檔
– 使用 ProGuard 減少 code size，ProGuard 可以減少不必要的資源，使用的方式是在 build.gradle 加上 minigyEnable = true 以及 shrinkResource = true
– 考慮使用解析度來分割 Milti-APK，減少 LDPI MDPI APK 的檔案大小。

1. Battery Consimption
   我們都不希望我們要使用手機的時候，電力卻已經消耗殆盡，開發者可以透過以下的三個方法來最佳化電力消耗

– 減少不必要的 wakeups：每一次 wakelock 都會需要消耗一定的電力成本，減少不必要的消耗就能降低電力耗損
– 將網路需求集合在一起執行：網路連結也需要消耗一定的電力，將需求集合在一起處理，減少電力消耗
– 使用 GcmNetworkManager API：可以用來安排任務的執行，讓這些任務集中起來一次處理進而達到省電的功效。
此外，也可以根據網路狀態，是否充電 … 等狀態來決定這些任務是否要執行。

1. Content

– 建立快速且有互動性的 UI
– 特別注重觸控回饋，讓使用者瞭解他們所觸控的元件是否有回應
– 互動性的 UI
– UI 的流暢度必須在 60 fps
– 考慮建立開頭頁面
– UI 最佳的行為
– 遵守 Material Design
– 使用 Design Library 讓 App 整體的使用者經驗一致化
– 本地化
– 支援當地的使用者
– App 因為要支援多國語言，常會造成文字在 UI 上有過長或過短的問題，開發者需要多注意這方面的狀況。此外，還需要注意
– 使用適當的字型
– 在低解析度的手機上，如果使用 14 or 16 sp 的字體可能會有模糊的狀況，為了解決這樣的情形，Google 提供了 Noto 字型解決這方面的疑慮

1. Commerce
   使用者對價錢是相當敏感的，根據不同國家，在地化不同的價錢是相當重要的，講者舉了 Kingdom Rush 的例子來說明他們因為在地化各個國家的價錢，在新興國家的月收益增加了 50% 到 200%

 

Android Wear 2.0: Building Apps with Material Design

材料設計是 Google 提供，用以統一介面的一種設計方法，從電視到手錶，在不同尺寸的裝置上，材料設計都可以提供很適合的呈現，針對手錶的材料設計主要有三個特點
– 垂直 Layout
– 較暗的顏色
– 設計元件、設計模式 (讓開發者較為輕鬆、使用者經驗較為一致)

垂直設計的程式使用起來簡單、操作容易，如果有橫向的視圖容器也沒有關係，只要內容主軸是垂直的就好，較暗的顏色可以讓裝置比較省電，另外過於明亮的顏色，在需要專注、較為暗的環境之中，都比較容易造成干擾，例如電影院中，可能突然亮起來，會影響到別的觀眾，顏色的使用上，他們使用HSB色域來做設計，選定色相與飽和度以後，以明度來分成以下幾種使用
– 強調 (100%)
– 較亮的UI元件 (65%)
– 一般UI元件 (40%)
– 較亮背景 (30%)
– 較暗背景 (15%)

他們在影片中以 Wearable Action Drawer 和 Wearable Navigation Drawer 當作設計元件、模式的說明穿戴裝置的材料設計 library 遠不止影片中 demo 的內容，建議可以到開發人員網頁去詳細了解。

因為螢幕的大小，設計模式變成一個更重要的工作，有時也許你也必須要提醒使用者，在螢幕看不到的位置，有新的訊息或是變化，這些元件的使用非常簡單，與手機上的設計經驗一致，詳細的設計案例可以在影片中查看，他們提供了一些很實用的設計經驗，來讓你的設計變得更容易操作，例如你應該要盡力簡化使用者可以做的事情，並強調 app 所提供的主要功能。

因為有圓形跟方形的錶面，所以要盡量以較小的圓形表面來做為考量，把重要的資訊集中在中間的位置，針對圓形、方形表面，你可以用 values-round 和 values-notround 來區分使用的 Resource

 

Android high-performance audio

課程前半段在講 App 端開發者該注意的事以避免 Audio latency 例如，宣告 SampleRate 時不要寫 44100 等固定值，應該要用 AudioManager..getProperty(AudioManager.PROPERTY_OUTPUT_SAMPLE_RATE); 而建立 Buffer 時也不要寫死太大的數字影響效率，應該使用 AudioManager.getProperty(AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER); 來取得每個 Device 不同的建議值，不過是以使用 OpenSL 為例，不一定適合所有層次的播放邏輯。

講者接下來提到一個 App 能獲得多少 CPU 資源除了在前景、背景之外，還會受到有沒有正在使用而影響，所謂的正在使用不僅僅是在前景加播歌，而是有事件產生，所以講者提到如果真的很有需加高 App 使用資源的優先權，可以每秒發出一個假的 touch 事件。

接著講者介紹了播放聲音時如果發生斷續的原因大致上就是沒有即時給出資料，而無法即時給出資料除了邏輯問題之外，在效能方便可以注意的點是儘可能少使用 JNI Call、Memory allocation、System call 因為這些動作都會對效能造成明顯的影響，在系統和 App 討資料的 callback 中，也應該把產生音訊的時間縮到 callback 頻率的 20% 內才可以避免產生斷續問題。

接下來主持人介紹了 Qualcomm、NVIDIA 與 Samsung 三家也花了很多力氣在減少 Audio latency 與開發 ProAudio SDK 的廠商，並邀請 Samsung 上來分享。

ProAudio SDK 專案頁：https://googlesamples.github.io/android-audio-high-performance/
NVIDIA 的專案在這裡：https://developer.nvidia.com/shield-pro-audio-developer-preview-image
Samsung 的專案在這裡：http://developer.samsung.com/galaxy#professional-audio

 

Android Wear 2.0: Watch faces and Complications

在 Android Wear 上有許多替換錶面的應用，你可以在上面顯示日期、鬧鐘等等資訊，現在提供了 Complications API 協助你打造 Wear 的錶面應用，當有任一 app 提供了某種類型內容，你的錶面應用可以透過該 API 提取其中的資料來顯示，例如在錶面上顯示天氣、股票價格，或從日曆中取得事件等，使用者可以選擇在錶面顯示的資訊種類，並能直接從錶面開啟 app。

在設計上面有幾個原則需要遵守，一是確保錶面上的元件或按鈕都是清晰易懂的，不要讓使用者需要猜測按鈕的作用是什麼；二是節省時間，讓使用者在 Wear 上可以快速到達目標，不要跳轉太多頁面；三是一致的設計風格，不要有過多複雜地設計。

Android Wear 也推出了新的 SDK，目前還是 Preview 版本，你可以至 https://g.co/wearpreview 下載與查閱更多資訊。

如果要加入 Complications 至你錶面應用，可以參照 https://codelabs.developers.google.com/codelabs/complications/index.html ，裡面有詳細的教學。

 

Android NDK performance in an ART world

開會者會去使用 NDK 的原因大致規類為三種，第一種是為了保密，第二種是為了跨平台，第三種是為了效能，第一、二種都沒有其他取代方案，例如 Java 就是容易被反組譯，而要使用 OpenCV 等 Library 就必須操作 C/C++，所以這部影片主要在探討撰寫 native code 時，在新的 ART (Android Runtime) 上針對 performance 該注意的事項。

因為 ART 的效能比 Dalvik 還要好，而 GC 等流程也相對複雜，所以在 native code 操作 Android API 在 ART 上運行是比較慢的，所以要 cache 住 object 不要一直操作 GetFieldID, GetObjectField 等 function。

如果你在 NDK 中操作 Java 傳入的 String 時，使用 GetStringUTFChars 會比使用 GetStringChars 快許多，原因是不需要轉型，如果要複製 Java 字串至 Native 中處理，則建議使用 GetStringRegion 會快許多，但有個代價是必須多傳入字串的長度給 native function。

新版的 NDK 中加入了數個以 ATrack 開頭的 API 可以用來 trace code 且計劃將編譯器由 GCC 換為 Clang，原因是 Clang 編譯器產生的結果在部份 CPU 上快很多，記憶體的用量也比較少，這兩點對於手機這種電池容量不高的設備來說非常重要。

 

Android Layouts: a new world

Android Studio 2.2 preview 版本將提供新的 UI Builder 工具 alpha 版，適用於 API Level 9+ 並且支援絕大多數的裝置
特色是可減低 Layout 的巢狀排列，簡單易於操作。使用 GUI 界面直覺的排列 UI，自動在 layout xml 產生 ContraintLayout 在視圖 (Inspector) 編輯畫面可放置各種 Widget 並使用拖拉可改變大小，調整與整個螢幕畫面的相對位置，各個 ConstraintLayout 之間，可經由拉動 constraints 線條連接定義相對位置，對於較複雜的 Layout 像是 ListView 與 Dialog 等，也可以直接在放置調整 ListView (Dialog) 之後，再來排列 row (content) layout 的樣子，未來發展的目標：
– 提升效能
– 自動化校正調整
– 新增指南

目前 alpha 版本仍然存在許多 bug，需要開發者協助回報問題，在以下 Google codelabs 有更詳細的說明與範例：https://codelabs.developers.google.com/codelabs/constraint-layout

 

Android application architecture: Get ready for the next billion!

一開始先說明不要過度設計架構，好的架構的確讓我們開發者易於擴充及測試，但使用者並不會知道這些細節，唯一能讓他們感受到的只有使用者體驗。

在這提供兩個著眼點：
1. 讓 App 在離線時也能 work
2. 對網路不穩時的體驗最佳化

關於第一點，主要的想法是我們可以提供一個 local 的 model 讓他能隨時響應使用者的行為去變化，而不需要等到與 server 端的互動結束才行動，這樣子無論何時完成 sync data 都不會對體驗造成壓力。

而第二點有不少地方可以多些巧思，例如圖片若是沒有高品質需求，其實可以使用較低品質的圖片，因為低品質總比空白的結果好多了；若總是在特定時段內需要資料，可以使用 JobScheduler 為這項工作排程，可以避免在網路不穩但又需要時一直卡在 loading；若有更新的資料出現時，可以先在背後 prefetch 完再通知使用者，並且讓使用者決定是否 refresh UI，但要權衡 prefetch 可能會遇到的風險，諸如數據用量可能過大。

這邊也總結了一些對於下一代好的 App 設計概念，

網路方面：
1. 以 Client 的觀點去設計 API
2. 如果可以讓 Server 幫忙運算的工作就盡量交給 Server
3. 批次處理我們的 request
4. 安排 JobScheduler

設計方面：
1. 為了使用者體驗來設計架構
2. 能有個即時操作的 local model
3. 思考 sync data，而不是單純的 request 和 response
4. 物件設計合理，耦合度低
5. 有好的 idea 就盡早行動

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