Android——AndroidX

Android Jetpack具體介紹什麼的參照官網。小白就不說了。

1、創新Android應用，選擇Activity & Fragment + ViewModel模版

2、ViewModel + LiveData

ViewModel爲界面組件提供數據，

LiveData可看作是一種可觀察數據存儲結構，其中添加了觀察者模式，可監聽數據變化；不受配置變化影響，即當界面reCreate時ViewModel數據不受影響；可共享數據，在不同的Fragment中加載相同的ViewModel即可共享。

class MainViewModel : ViewModel() {
    var data = MutableLiveData<String>()
}

onCreate() {
    viewModel = ViewModelProviders.of(this).get(MainViewModel::class.java)
    // 監聽數據變化
    // this傳參，表示LiveData遵循組建的生命週期，會自動清理
    viewModel.data.observe(this, Observer<String> {
        // update UI
    })
}

viewModel.data.setValue(value)
viewModel.data.postValue(value)

3、Room

數據庫存儲。

@Entity
data class User (
    @PrimaryKey
    var id: Int,

    @ColumnInfo(name = "name")
    var nickName: String?,

    var userIcon: String?
)

@Dao
interface UserDao {
    @Insert(onConflict = REPLACE)
    fun Insert(user : User)

    @Query("select * from user where id = :userId")
    fun load(userId : Int) : LiveData<User>
}

@Database(entities = arrayOf(User::class), version = 1)
abstract class MyDataBase : RoomDatabase() {
    abstract fun userDao() : UserDao

    companion object {

        private var DB: MyDataBase = Room.databaseBuilder(
            MyApplication.getInstance(),
            MyDataBase::class.java,
            AppConfig.DATABASENAME
        ).build()

        fun getInstance(): MyDataBase {
            return DB
        }
    }
}

4、測試：摘抄自官網

界面和交互：僅此一次需要 Android 界面插樁測試。測試界面代碼的最佳方法是創建 Espresso 測試。您可以創建 Fragment 併爲其提供模擬 ViewModel。由於 Fragment 只與 ViewModel 通信，因此模擬 ViewModel 就足以完全測試該界面。

ViewModel：可以使用 JUnit 測試來測試 ViewModel。您只需模擬 UserRepository 即可對其進行測試。

UserRepository：您也可以使用 JUnit 測試來測試 UserRepository。您需要模擬 Webservice 和 DAO。您可以測試它是否發出了正確的網絡服務調用、是否將結果保存到數據庫中，以及在數據已緩存且保持最新狀態時是否不會進行任何不必要的請求。由於 Webservice 和 UserDao 都是接口，因此您可以模擬它們或者爲更復雜的測試用例創建虛假實現。

UserDao：要測試 DAO 類，建議的方法是使用插樁測試。由於這些插樁測試不需要任何界面，因此它們仍會快速運行。對於每個測試，您可以創建內存數據庫，確保測試沒有任何副作用（如更改磁盤上的數據庫文件）。

Room 還允許指定數據庫實現，因此您可以通過爲其提供 SupportSQLiteOpenHelper 的 JUnit 實現來對其進行測試。通常不建議使用此方法，因爲設備上運行的 SQLite 版本可能與主機上的 SQLite 版本不同。

Webservice：務必使測試獨立於外界，因此即便是 Webservice 測試，也應避免對後端進行網絡調用。有很多庫可幫助解決此問題。例如，MockWebServer 是一個不錯的庫，可幫助您爲測試創建虛假的本地服務器。

測試軟件工件：架構組件提供了一個可控制其後臺線程的 maven 軟件工件。在 android.arch.core:core-testing 軟件工件內，有兩個 JUnit 規則：

InstantTaskExecutorRule：此規則可用於強制要求架構組件立即在調用線程上執行任何後臺操作。
CountingTaskExecutorRule：此規則可用於插樁測試，以等待架構組件的後臺操作或將其作爲空閒資源連接到 Espresso。

5、官方建議

1、您在清單中定義的入口點（Activity、Service、廣播接收器等）不是數據源。相反，它們應該只協調與該入口點相關的數據子集。由於每個應用組件存在的時間都很短暫（具體取決於用戶與設備的互動方式以及運行時的總體當前運行狀況），因此您不能將任何入口點作爲數據源。
2、應嚴格地在應用的各個模塊之間設定明確定義的職責界限。例如，不要在代碼庫中將從網絡加載數據的代碼散佈到多個類或軟件包中。同樣，不要將不相關的職責（如數據緩存和數據綁定）塞到同一個類中。
3、從每個模塊中儘可能少地公開代碼。不要試圖創建“僅此一個”的捷徑，從一個模塊中公開所有內部實現細節。您可能會在短期內縮短運行時間，但隨着代碼庫的發展，您會多次在技術上付出代價。
4、在定義模塊之間的交互時，應考慮如何使每個模塊可獨立測試。例如，如果使用明確定義的 API 從網絡獲取數據，將會更容易測試在本地數據庫中保留該數據的模塊。如果您將這兩個模塊的邏輯混合在一處，或將網絡代碼散佈在整個代碼庫中，那麼即便能夠進行測試，難度也會大很多。
5、應用的核心是使其脫穎而出的因素。不要花時間做無用功或一次又一次地編寫相同的樣板代碼。相反，應將精力集中在能使應用與衆不同的因素上，而讓 Android 架構組件以及建議的其他庫處理重複的樣板。
6、保留儘可能多的相關數據和最新數據，以便在設備處於離線模式時您的應用可用。雖然您可能享受着恆定的高速連接，但是您的用戶可能並沒有。
7、存儲區應將一個數據源指定爲單一可信來源。每當應用需要訪問這部分數據時，該數據應始終源於單一可信來源。詳情請參閱單一可信來源。