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、存储区应将一个数据源指定为单一可信来源。每当应用需要访问这部分数据时，该数据应始终源于单一可信来源。详情请参阅单一可信来源。