协程最佳实践 android官网地址
这些实践可以让你的程序在使用协程的时候更加的易扩展和易测试
1.注入调度器
不要在创建一个协程的时候或者调用withContext，硬编码来指定调度器 比如这样的
class NewsRepository {
// DO NOT use Dispatchers.Default directly, inject it instead
suspend fun loadNews() = withContext(Dispatchers.Default) { /* ... */ }
}
而应该进行注入
class NewsRepository(
private val defaultDispatcher: CoroutineDispatcher = Dispatchers.Default
) {
suspend fun loadNews() = withContext(defaultDispatcher) { /* ... */ }
}
原因：依赖注入的模式可以让你在测试的时候容易更换调度器 详细参考Android中简易的协程
2. 挂起函数在实现的时候，应该保证对主线程是安全的
比如这样的：
suspend fun fetchLatesNews():ListArtical{
withContext(Dispatchers.IO){
}
}
主线程调用的时候
suspend operator fun updateContent(){
val news = fetchLatesNews()
}
这样可以保证你的App是易扩展的，类挂起方法调用的时候，不需要担心线程是在哪个环境调度的，由具体实现类中的方法来确保线程调度的安全
3. viewModle 应该去创建一个协程
viewModle更应该去创建一个协程，而不是去暴露一个suspend方法。 比如应该是这样：
//示例代码，viewModle内去创建一个协程
class LastestNewsViewModel{
//内部维护了一个可观察的带状态的数据
private val _uiState = MutableStateFlow<LatestNewsUiState>(LatestNewsUiState.Loading)
val uiState:StateFlow<LatestNewsUiState> = _uiState
//重点来了，这里不是一个suspend方法
fun loadNews(){
viewModleScope.lanuch{
val lastestNewsWithAuthors = getLatestNewsWithAuthors()
_uiState.valule = LastestNewUiState.Success(lastestNewsWithAuthors)
}
}
}
而不是这样的
class LastestNewsViewModel():ViewModel{
//这种是直接返回了一个suspend方法
suspend fun loadNews() = getLatestNewsWithAuthors()
}
除非不需要调用知道数据流的状态，而只需要发射一个单独的数据。（个人理解，是保持viewModle中的定义，维护一个可观察的带状态的数据，而不是直接扔原始数据出来）
4.不要暴露可修改的参数类型
应该对其他类暴露不可修改的的类型，这样所有可变类型数据的变更都集中在一个类里，如果有问题的时候，更容易调试（也是迪米特原则） 比如应该是这样的
class LastestNewsViewModel : ViewModel{
//可修改类型
private val _uiState = _MutalbeStateFlwow(LastestNewsViewModel.Loading)
//对外暴露不可修改类型数据（对外不提供修改功能）
val uiState : StateFlow<LatestNewsUiState> = _uiState
}
5. 数据和业务层应该暴露挂起函数 或 Flow
数据层和业务层通常需要暴露方法，去执行一次性的调用或者需要持续接收数据的变化，这时候应该提供为一次性调用提供挂起函数 或者 提供Flow来帮忙观察数据的变化操作 比如这样的：
class ExampleRepository{
//为一次性的调用提供 suspend方法
suspend fun makeNetworkRequest(){}
//为一需要观察的数据提供Flow对象
fun getExamples():Flow<Example>{}
}
最佳的实践可以使调用者通常是业务层，能够控制业务的执行和生命周期的运转，并且在需要的时候可以取消任务
6. 在业务和数据层创建协程
在数据和业务层需要创建协程的原因可能有不几的原因，下边是一些可能的选项
- 如果协程的任务是相关的，且只在用户在当前界面时才显示，那么它需要关联调用者的生命周期，这个调用者通常就是ViewModel，在这种 情况下， 应该使用coroutineScope 和 supervisorScope
示例代码：
class GetAllBooksAndAuthorsUseCase(
private val booksRepository:BooksRepository,
private val authorsRepository:AuthorsRepository,
private val defaultDispatcher:CoroutineDispatcher = Dispatchers.Default
){
suspend fun getBookdAndAuthors():BookAndAuthors{
//平行的情况需要等待结果，书籍列表和作者列表需要同时准备好之后再返回
return coroutineScope{
val books = async(defaultDispatcher){
booksRepository.getAllBooks()
}
val authors = async(defaultDispatcher){
authorsRepository.getallAuthors()
}
//准备好数据之后再返回
BookAndAuthors(books.await(),authors.await())
}
}
}
- 如果这个任务是在App开启期间需要执行，这个任务也不绑定到某一个具体的界面，这时候任务是需要在超出调用者的生命周期的，这种场景下，需要用到
external 的 CoroutineScope ，详细可参考 协程设计模式之任务不应该被取消
参考示例代码：
class ArticalesRepository(
private val articlesDataSource: ArticlesDataSource,
private val externalScope:CoroutineScope,
private val defaultDispatcher:CoroutineDispatcher = Dispatchers.Default
){
//这个场景是这样的，即使我们离开的屏幕，也希望这个预订操作是能够被完整执行的，那么这任务斋要在外部域开启一个新的协程里来完成这wh
suspend fun bookmarkArtical(artical:Article){
externalScope.lanuch(defaultDispatcher){
articlesDataSource.bookmarkArticle(article)
}.join() //等待协程执行完毕
}
}
说明: 外部域需要被一个比当前界面的生命周期更长的一个类来创建，比如说 Application或者是一个navigatin grah的ViewModel
7. 避免使用GlobalScope全局作用域
就像最佳实践里边的注入调度器，如果用了GlobalScope，那就是在类里边使用硬编码，可能会有以下几个负面影响
- 硬编码。
- 难以测试
8. 协程需要可以被取消
取消操作也是一种协程的操作，意思是说当协程被取消的时候，协程并没有直接被取消，除非它在 挂起 或者 有取消操作，如果你的协程是在操作一个阻塞的操作，需要确保协程是中途可以被取消的。 举个例子，如果你正在读取多个文件，需要在读取每个文件之前，检查下协程是否已经被取消了，一个检查协程是否被取消的方法就是 调用 ensureActivite方法，(或者还有isActive可用) 参考示例代码：
someScope.lanuch{
ensureActive()//检查协程是否已经被取消
readFile(file)
}
更多详细的描述信息可以参考 取消协程
9. 协程的异常处理
如果协程抛出的异常处理不当，可能会导致你的App崩溃。如果异常出现了，就在协程里就捕获好异常并进行处理
参考示例代码：
class LoginViewModel(
private val loginRepository:LoginRepository
):ViewModel(){
fun login(username:String,token:String){
viewModleScope.lanuch{
try{
loginRepository.login(username,token)
//通知界面登录成功
}catch(error:Throwable){
//通知view 登录操作失败
}
}
}
}
更多协程异常的处理，或者其他场景需要用到CoroutineExceptionHandler，可以参考 协程异常处理
