回顧 2018 Android 開發的 10 件事
都幾月了還這麼熱？
target SDK Version migrate to Oreo(26)
沒想到 Play Store 也兇起來了，2018 年 8 月以後所有新的應用程式都必須 設定 targetSDK 至 26 版。既有程式則是於 11 月前需要完成 Migrate，否則就有可能無法更新。
targetSDK 版本會影響 App 在 Runtime 中的行為，例如以前將 targetSDK 設定在 23 (Marshmallow) 以下，就無需動態透過 Dialog 來獲取一些手機功能的權限 (例如讀取內部空間、存取相機⋯ 等)，只要在 Play 商店下載程式後，就全部授與了。😅
Target 到 Oreo 之後，所有 Service 皆需要有明顯的 Notification 讓使用者知道有 Service 正在運行，否則在 5 秒內系統會停止這個 Service。更緊縮了一些系統廣播，避免了太多不必要的 Service 在背景執行的問題。
在有 Play 商店的宇宙，這是一個很大的進步。至於其他的平行宇宙，還是自求多福吧。
Android JetPack
Android Support Library 被棄用了，你沒看錯 Support Library is deprecated。它被改名成 Android X Library 與去年發表的 Android Architecture Component 做了整合，現在都成為 Android JetPack 的一員。
這麼做最大的好處是將 Support Library 與 Compile SDK 版本脫鉤，在 Android X Library 之前，升級 Support Library 時，也一併需要升級 Compile SDK 版本，所以 Support Library 版本號總是跟著 Compile SDK 版本走。
但在 Android X 與 Compile SDK 脫鉤後，升級的速度可以比以往更頻繁。更早享受新功能，更早修復問題。也免除了詭異的 Package Name，例如 v4 Support Library 最低支援版本早已不是 v4。Google 也在持續的解耦 Android X Library，開發者只需要引用需要的部分即可。
另外，在 2018 年的 Android Developer Summit，新的 Architecture Component：Navigation 與 Work Manager 進入了 beta，新的 Android Studio 3.2 可以透過 Navigation Editor 來用圖形化的方式編輯 App 的轉場。(Storybo……d?)
最後，因為被 Support Library 被棄用，開發者需要 Migrate 至 Android X Library。雖然 Android Studio 3.2 之中提供了 Migrate to Android X 的選項，但現實世界還是有各種出包，參考各路開發者的經驗還是比較好的。
Kotlin
自 2017 年飛上枝頭之後，從去年熱到現在。今年， Kotlin 也帶來了很多令人興奮的更新。
例如 Kotlin 1.3 的釋出，Coroutines 正式從測試階段畢業。Coroutines 讓多執行緒的處理變的更容易處理，可用像寫同步的方式處理非同步流程。
Kotlin 可以為各個 Class 寫 Extension Function，擴充該 Class 的功能。Android 開發團隊在 2018 Google I/O 年釋出了糖果包 KTX，擴充使用 Kotlin 開發時能用更精簡的程式碼完成功能。
最後，KTX 的開發整合進入了 AOSP，會跟著 Android 系統持續的成長。
另外，Gradle 5.0 正式推出後，正式的支援用 Kotlin DSL 來寫 build script，能夠獲得自動提示、程式碼錯誤提醒⋯ 等額外好處。也就是除了 Groovy 以外多了一個新的選擇，不過 Gradle 5.0 需要 Android Studio 3.4 釋出後才算正式支援，想要嚐鮮的開發者可以下載 3.4 Canary 版來體驗。
Material Design
隨著 Android 9 Pie 的發表，Google 也一併更新了自 2014 年發表的 Material Design。 可以發現整體邊角更為圓潤，更乾淨的背景，往下放置的 App Bar，形狀可以不限定只有正圓形的 Floating Action Button⋯ 等。
同時，自家 App 的字體從 Roboto 換成了 Product Sans。
除了 Android，Google 整理了一套設計資源給 iOS、網頁和 Flutter (下面會提到) 供開發者使用，並整理了一套設計 Guideline 於 Material.io。
上面提到 Support Library 已經被棄用，原來相關的 Material 設計資源本來是放在 Design Support Library 裡頭。現在變成 Material Component 的一部分：
implementation 'com.google.android.material:material:1.0.0'瀏海
自從友商推出自己的無邊框全螢幕手機之後，Android 手機各種前仆後繼的跟上，造成 UI 也需要考慮頭上瀏海的部分。(最近也要判斷下面的瀏海了) 雖然可以完全交由系統去 Handle，把瀏海多出來的像素作為狀態欄處理掉。如果想要做更細部的效果，例如為這些像素上陰影的時候該怎麼做？
之前的文章提過，要偵測瀏海的大小可以使用 ViewCompat.setOnApplyWindowInsetsListener() 這個 API 來取得 WindowInsetCompat 這個物件。
一般來說會透過 getWindowInsetTop() 抓狀態列的高度當作是瀏海的高度，但不是每一台手機都是這個樣子的。有的時候瀏海會比狀態列還低，需要去取得確切的瀏海高度，就需要從 WindowInsetCompat 再取出 DisplayCutoutCompat，透過這個物件去拿瀏海的高度。
最近螢幕打洞的手機也出現了，又要陷入一個瀏海與設計與 DisplayCutout API 更新的三方交戰。最後只能解決自己的強迫症，不要庸人自擾了。
D8 and R8
還記得 Android N 時的全新編譯 Toolchain Jack and Jill 嗎？本來是為了取代由 Javac 編譯為 Java bytecode、dx 編譯成 dalvik bytecode 這段流程。後來，不能與現有開發環境處得很好 (像是不支援 Instant Run，Annotation Processors 不支援，還記得 Dagger 2 不支援 Jack 很長一段時間嗎？)，而被棄用。
Google 為了改善 dx 在 2018 年推出的 Android Studio 3.1，釋出了 D8 編譯器，並且預設啟用。
本來 Java 8 在 Javac 中 desugar，現在則改由 D8 接手 (也就是說 Java bytecode 變成 Java 8 了)。D8 除了讓編譯時間縮短，編譯出來的檔案也更小。
另外，R8 則是 ProGuard 的替代品，用來混淆、最佳化程式碼。R8 支援 ProGuard 的規則，同時也有自己的規則寫法。截至 2018 年 12 月，R8 還在測試的階段，應該會與 Android Studio 3.3 或 3.4 一併釋出。由 ProGuard 開發公司 GuardSquare 的一篇比較文章指出，雖然 R8 支援的最佳化功能比較少，但 R8 支援更多 Kotlin Lambda 最佳化。
想要知道更多這個議題，可以看 Jake Wharton 一系列介紹 D8 和 R8 的文章。
Flutter
Google 的跨平台開發解決方案 Flutter 1.0 也在今年正式釋出，Flutter 可以同時發開發 Android、iOS 與網頁版應用程式，使用的是 Dart 語言。過去跨平台開發比較流行的是 React Native，但發生了一些風風雨雨，導致有退燒之勢。
總之，現在多了一個選擇 —— Flutter。
如果想要看 Flutter Apps 的效果，可以試試 The History of Everything 這個 App。
Android App Bundle
2018 年的 Google I/O，Android 多了一種應用程式打包格式 Android App Bundle (aab)。包成 App Bundle 的好處是每一台手機只需要下載符合自身規格的資源，不用再一整包抓下來安裝。例如一台設定為繁體中文的 Snapdragon 845，螢幕密度是 xxhdpi。
在安裝程式時，只需下載：zh-rTW、ARMv8、xxhdpi 規格的資源檔即可，減低了不少安裝的容量與時間。
不過，也因為這種 Split APK 的方式改由 Google Play 來做，所以需要將簽名的 Key 交給 Google Play，也就是需要設定好 Google Play 應用程式簽署，否則就無法使用 Android App Bundle。
因為 App Bundle 的出現，Google Play Instant (就是之前的 Instant App) 不需要再切割 module，可以只留一個 base module 包成 App Bundle 就能使用。這個新方式應該會配合 Android Studio 3.3 正式版推出後，一併上線。
需要手動測試產生的 aab 檔案，可以參考我之前的文章：手動安裝 aab (Android App Bundle) 檔案。
Prepare for foldables (摺疊手機)
在 2018 年 11 月的 Android Developer Summit，Google 與 Samsung 公布了全新形態的手機—— 折疊式手機 (Foldables)。
在一般折起來的狀態下，會是一個接近目前 4 吋至 5 吋大小的手機。使用者隨時可以將螢幕翻開，將會變成一個 7 吋至 8 吋大小的平板畫面。在將螢幕翻開時，系統會允許使用者可以同時跑多個程式，類似於手機上的視窗分割模式。
折疊式手機 (Foldables) 最多可以同時跑 3 個程式在翻開的畫面上，而且 Activity 都是 onResume() 的狀態。(本來視窗切割時，失去焦點的視窗會進入 onPause())
你可以先在 AndroidManifest 之中加上：
<meta-data android:name="android.allow_multiple_resumed_activities" android:value="true" />靜待 Google 或 Samsung 推出折疊式手機的模擬器時，就能來測試 App 跑在折疊式手機上的效果。
更多資訊可以參考 Android Developer blog 的 Get your app ready for foldable phones。
(Upcoming) In-App Updates API
大家應該都有幫專案的 App 檢查版本是否為最新的經驗，有時為了處理問題需要強制請 User 更新 App。在 2018 年的 Android Developer Summit，Google 發表了 In-App Updates API，它應該是跟 Google Play 服務整合在一起。
主要分為兩種表現形態：一種是整個 App 被更新訊息蓋住。另一個則為顯示於 Menu 之中，有更新時提醒使用者目前已有更新的版本。
更新安裝中使用者不用離開 App，不會轉跳到 Play 商店。安裝完之後重新啟動應用程式 (由示意圖看起來能詢問使用者是否立即重新啟動)，即完成 App 的更新。
雖然已經發表，現在尚在測試階段，只有 Google 和一些廠商搶先測試中。如同之前的 Google Play Instant 剛開始時也是如此，大概需要過個半年到一年才有公開測試。
所以應該是 2019 年，大家才能開始使用到這個服務。
