Android Weekly Issue #227

本期內容包括: Google的Mobile Vision API 人臉檢測; Firebase的Remote Config; 與HashMap有關的優化; 提高RecyclerView幀率的優化; 使用AutoValue生成model程式碼; 開源庫中抽象類和介面的使用討論; Bottom Sheet的使用; Android Studio中的版本控制系統; ConstraintLayout的使用; 應用換Bottom Navigation; Nougat的Messaging Style Notification; 自定義字型; Reductor的使用等.

ARTICLES & TUTORIALS

這篇文章來自Mobile Vision, 講人臉檢測及相關概念.
API使用Tutorial.
Sample.

Remote config是Firebase提供的一個feature, 讓我們可以定義引數, 在firebase的console管理, 從而在server端控制應用的UI或者行為, 並且可以選擇生效的使用者範圍.

本篇文章介紹了Firebase的Remote Config可以幹什麼, 以及怎麼做, 解說很詳細.

引數
我們用Remote Config定義的鍵值對叫引數(parameters). 它提供了這個引數相關的what資訊(key, the identifier), 和how資訊(value, the configuration).

條件
條件值(conditional value)也是一個鍵值對, 其中condition指定了需要滿足的條件, value指定了滿足條件時需要返回的值.

優先順序
如果單個條件被滿足, 那麼返回對應的值; 如果多個條件都被滿足, 那麼返回主導條件(list上方的條件)對應的值; 如果沒有條件滿足, 則返回預設值; 如果沒有定義預設值, 則什麼也不返回.

文中還詳細介紹了Android和iOS端的實現, 以及console的配置.

當我們需要儲存鍵值對的時候, 我們總是首先想到用HashMap, 然而IDE(Android Studio)有時候會警告提醒你, 應該用ArrayMap或SparseArray

HashMap vs ArrayMap

ArrayMap比傳統的HashMap更節省記憶體, 因為它把自己的對映放在陣列結構中: 一個整型陣列放每一個item的hash code, 一個Object陣列放key/value對. 這樣避免了為每一個entry建立額外的物件, 而且陣列增長也好控制.

注意ArrayMap並不是為很大的資料集設計的, 並且它會比HashMap慢一些, 以為查詢需要二分查詢, 增刪需要在陣列中操作.

HashMap

HashMap是一個HashMap.Entry的陣列, 其組成是key, value, HashCode, 還有一個指標.

當進行插入時: 首先計算出key的HashCode, 然後用這個hashCode找到對應的bucket, 如果已經存了元素, 則把舊元素的指標指向新元素, 即把bucket變為一個LinkedList.

當進行查詢時: 複雜度為O(1), 但是這樣是犧牲了更多的空間複雜度得到的.

HashMap的缺點:

• 因為key和value都不能是原生型別, 所以插入時可能會有自動裝箱, 導致建立額外的物件.
• HashMap.Entry本身就是一層額外的物件.
• 每次HashMap的收縮或者擴張, Buckets都要重新排列, 隨著物件變多, 這個操作變得越發昂貴.

ArrayMap

ArrayMap使用兩個陣列:
int[] mHashes用來存雜湊值; Object[] mArray來存物件.

當插入鍵值對時: Key/Value被自動裝箱, Key被插入到mArray[]陣列的下一個位置, Value也被插入到mArray[], 在Key的下一個位置.
計算出的雜湊值被放在mHashes[]的下一個位置.

當查詢一個Key時: 首先計算出Key的雜湊值, 在mHashes中二分查詢這個hashCode(時間複雜度(logN)), 當得到hash的index之後, 我們就知道mArray中2*index和2*index+1的位置對應的是查詢的key和value.

雖然時間複雜度提升了, 但是這樣卻更省空間.

推薦的資料結構:

• ArrayMap<K,V> in place of HashMap<K,V>
• ArraySet<K,V> in place of HashSet<K,V>
• SparseArray<V> in place of HashMap<Integer,V>
• SparseBooleanArray in place of HashMap<Integer,Boolean>
• SparseIntArray in place of HashMap<Integer,Integer>
• SparseLongArray in place of HashMap<Integer,Long>
• LongSparseArray<V> in place of HashMap<Long,V>

我們經常會用RecyclerView來顯示一個list的資料.
作者他們做的是一個招聘應用: Workable, 其中會用list來顯示candidates.
他們還使用了DataBinding.
本文是作者他們關於RecyclerView的幀率所做的一些優化.

首先他們使用了Android Studio的Allocation Tracking, 然後上下滾動, 從報告發現, 他們佈局中使用的TableLayout花費了很多資源, 於是後來他們改為LinearLayout加權重的方式來解決, 擺脫了耗費資源的TableLayout.

另一個引起很多資源分配的問題是, 對於需要大寫的文字, xml中的:

<TextView
          ...
  android:textAllCaps="true"
          ...
/>

TextView的程式碼中會為此生成一個物件:

  if (allCaps) {
      setTransformationMethod(new AllCapsTransformationMethod(getContext()));
  }

這個在靜態的佈局中可能沒有問題, 但是在一個滾動的list中可能會有些影響.

改進方法是改為用java String的.toUpperCase().

然後他們使用了RecyclerView的.onViewRecycled()方法. 這個方法讓我們知道了RecyclerView中的一行何時被回收, 這樣我們就可以釋放一些不需要的資源.
他們使用了DataBinding, 所以這是一個合適的時機來刪除ViewModel中的OnPropertyChangedCallbacks, 然後清理ViewModel自身, 我們還可以清理之前用Glide load到ImageView中的圖片.

@Override
public void onViewRecycled(Candidates holder) {
    if(holder != null) {
        holder.binding.getCandidateVM().removePropertyChangedCallback();
        holder.binding.setCandidateVM(null);
        holder.binding.setHighlightTerm(null);
        holder.binding.setShowJobTitle(false);
        holder.binding.setShowStage(false);
        holder.binding.executePendingBindings();
        Glide.clear(holder.binding.candidateBrowserAvatar);
        holder.binding.candidateBrowserAvatar.setImageDrawable(null);
    }

    super.onViewRecycled(holder);
}

作者他們的應用還有一些cache設定:

binding.fragmentCandidateBrowseList.setItemViewCacheSize(30);
binding.fragmentCandidateBrowseList.setDrawingCacheEnabled(true);
binding.fragmentCandidateBrowseList.setDrawingCacheQuality(View.DRAWING_CACHE_QUALITY_HIGH);

之後作者測量了他們的FPS, 顯示是60 FPS, 並且發現去掉這些cache設定仍然是60.

在Java/Android程式設計中經常需要寫model物件來存放一些資料, 使用Google的庫AutoValue可以幫你自動生成這些類, 你需要做的就是定義你的欄位, 然後給類加上註解.

Setup

在project的build.gradle中:

buildscript {
    [...]
    dependencies {
        [...]
        classpath 'com.neenbedankt.gradle.plugins:android-apt:1.8'
    }
}

在app的build.gradle中:

apply plugin: 'com.neenbedankt.android-apt' // At the beginning
[...]
dependencies {
    [...]
    provided "com.google.auto.value:auto-value:1.2"
    apt "com.google.auto.value:auto-value:1.2"
}

基本使用

比如要建立Film類, 你可以寫一個這樣的抽象類:

@AutoValue
abstract class Film {
    static Film create(String name, int year) {
        return new AutoValue_Film(name, year);
    }

    abstract String name();
    abstract int year();
}

每一個欄位都對應一個抽象方法.
build一下, AutoValue_Film類就會自動生成, 加上靜態工廠方法(上面的create()方法) 然後就可以使用工廠方法來得到model:

Film matrix = Film.create("The Matrix", 1999);

點進自動生成的類AutoValue_Film裡可以看到, 連hashCode()和equals()方法都生成了.

用builder模式

上面的例子隨著欄位的增多, create()方法的引數會變得很多, 用起來不方便, 那麼此時就需要用Builder模式:

@AutoValue
abstract class Film {

    static Builder builder() {
        return new AutoValue_Film.Builder();
    }

    @AutoValue.Builder
    abstract static class Builder {
        abstract Builder setName(String value);
        abstract Builder setYear(int value);
        abstract Film build();
    }

    abstract String name();
    abstract int year();
}

這樣就可以很方便地加引數了:

Film matrix = Film.builder()
  .setName("The Matrix")
  .setYear(1999)
  .setCategory(Category.FANTASY)
  .setRating(8.7f)
  .setDuration(136)
  .setReleaseDate(releasedDate)
  .setDirectors(directorsList)
  .setCast(castList)
  .build();

AutoValue擴充套件 Parcelable

有時候你需要在Activity之間傳資料, 需要你的model是Parcelable的, 此時你就可以用這個auto-value-parcel, 在程式碼裡也只需要實現這個介面:

@AutoValue
abstract class Film implements Parcelable {
   [...]
}

還有很多的擴充套件庫: extensions for AutoValue, 比如AutoValue-Gson, AutoValue-Cursor, AutoValue-With, AutoValue-Redacted等.

這篇文章的作者說, 在library開發中, 應該考慮用抽象類而不是介面. 他的庫是AdapterDelegates.

作者先介紹了通用的概念比較:

• class vs. interface
  介面更解耦, 更靈活, 只是定義了一個協議, 不限制實現.
• interface vs. abstract class
  抽象類會有繼承的問題, 基類和子類會共享一些實現, 所以子類的編寫者最好能清楚基類的實現, 這樣才不會在寫子類實現抽象方法的時候打破了基類作者的意圖. 另外就是基類作者仍然可能會更新基類, 所以得時刻檢查子類是否還是符合基類的設計意圖.

但是為什麼作者還是要把自己庫中的介面改為抽象類呢? 這是因為作者的庫依賴於Android的庫, Android的庫中相關程式碼改了, 作者就得改自己的public介面, 加一個方法, 導致所有新版的使用者也都必須實現這個方法.

還有一個情況就是比如一個開發者使用了2.1版本, 但是他專案裡依賴的另一個第三方庫使用了2.0版本. 編譯不會出錯, 最終的apk中打包的是2.1版本. 然後在這個第三方庫的元件裡呼叫2.1才有的新方法時就會丟擲錯誤.

作者覺得那每次Android RecyclerView的Adapter更新都會導致自己的庫major update, 所以他決定把自己的AdapterDelegate介面改為抽象類. 這樣他就可以對新增的方法提供預設空實現.

這樣定義的抽象類只有抽象方法和一些空實現的方法, 並沒有狀態和行為的共享可能會傳播給子類, 其實和介面是一樣的.

實現bottom sheet的時候, 有三種選擇: container view + BottomSheetBehavior, BottomSheetDialogFragment, BottomSheetDialog. 前兩種的例子比較多, 作者要介紹的是第三種.

如何選擇取決你的用途, container view + BottomSheetBehavior 適用於persistent bottom sheet, 而BottomSheetDialogFragment和BottomSheetDialog適用於Modal bottom sheets.

之後作者提供了實現程式碼, 附有theme定製和狀態callback的設定.

這篇文章介紹Android Studio的版本控制系統.

在Android Studio 2.2開始, 加入了一個Create command line launcher, 這樣你就可以在命令列或者第三方的版本控制客戶端使用Android Studio的diff/merge tool了.
作者使用的客戶端是SourceTree.

用cmd + shift + A可以用來find action, 然後就可以找到Compare with branch: 可以比較當前檔案和某個分支上的檔案的diff;
另外還可以Compare with..., 來比較和之前某一個特定提交的diff; 以及Compare with Clipboard來和剪貼簿做比較.

還有一些其他有用的快捷鍵, 請看原文吧.

作者想做這樣一個UI, 左邊是一個icon, 右邊是兩行字, icon的top和bottom分別和第一行字的top和bottom對齊.

作者他們的應用從burger menu改為bottom navigation, 此篇為心得分享和他們改版時設計中的一些細節討論.

其中狀態儲存是一個最主要的技術問題.

改版之後, 作者他們的應用資料表明有以下幾個好處:

• 使用者參與度提升了;
• 在底部導航有入口的功能使用率提高了;
• 並沒有使用者反饋說新的導航不好.

Messaging Style Notifications是為資訊應用特殊設計的, 提供了一個像對話一樣的view.

Messaging-style notifications和Bundled notifications的主要區別是, Bundled notifications中我們持續建立新的notification, 然後它們被grouped together. 但是用Messaging-style notifications的時候, 我們只有一個notification, 然後我們把所有的資訊新增進去.

作者展示了實現程式碼和效果, 注意這個Messaging style並不是後項相容的, 只在Nougat及以後的版本才支援.

作者介紹了他的應用中對於Bottom sheet的使用.

Deep linking with bottom sheet Activity
作者用它處理Deep linking, 這樣使用者就不用每次都全屏開啟, 只先提供一個peek, 如果真的感興趣再開啟.

實現是用一個透明的Activity, 還有狀態列處理的細節.

Bottom sheet settings menu
關於Settings, 為了節省使用者的trip, 作者它們的應用用了options menu的彈出選單. 後來他們改用bottom sheet來實現, 並且結合了PreferenceFragmentCompat, 省去了一些SharedPreferences的讀寫操作.

Supporting tablet users
bottom sheet在平板上使用, 尤其是橫屏的時候, 看起來不太好.
所以作者定製了Bottom sheet的寬度, 在平板上時是一個指定寬度, 在手機上維持原狀.

基於Google的Mobile Vision APIs現在Android開發者可以在應用裡用上機器學習了. 現在這個Mobile Vision API包括三種類型Face Detection API, Barcode Detection API和Text API.

本文主要講人臉檢測部分, 後面會講二維碼檢測和文字的API.

作者的demo展示瞭如何從一個靜態照片中檢測出人臉區域, 並且標記出landmark(眼睛, 鼻子, 嘴巴等), 之後可以根據這些特徵位置加上一些覆蓋標記.

在Android中自定義字型的一個庫: Calligraphy.

如果你的輸入是html文字, 你想自動處理裡面的tag(比如), 用另一種字型, 怎麼處理呢, 作者給出了程式碼.

之前這個文章介紹過Reductor, 在Android Weekly之前也出現過, 我的筆記: Android Weekly Notes Issue 224.

Reductor是一個狀態管理的庫, 用Java重新實現了JavaScript的庫Redux.
它的中心思想:

之前的一篇文章做了一個TODO app, 然後作者發現這種mutable的資料會導致失控的資料改變, 然後可能會出現無法預測的行為. 做了一些改動之後, 我們發現可以通過只儲存一個immutable的物件和mutable的reference來避免這個問題.

這篇文章用Reductor來重新實現應用, 文中詳細說明了程式碼實現.

LIBRARIES & CODE

一個很小的庫, Activity直接的shared element transition動畫, 把一個圓形的ImageView變換到下一個Activity的方形ImageView.

用Kotlin實現的設計模式.