Android 中协程的最佳实践

本页面介绍了一些最佳实践,这些实践通过在使用协程时使您的应用更具可扩展性和可测试性,从而产生积极影响。

注入调度器

创建新的协程或调用 withContext 时,请勿硬编码 Dispatchers

// DO inject Dispatchers
class NewsRepository(
    private val defaultDispatcher: CoroutineDispatcher = Dispatchers.Default
) {
    suspend fun loadNews() = withContext(defaultDispatcher) { /* ... */ }
}

// DO NOT hardcode Dispatchers
class NewsRepository {
    // DO NOT use Dispatchers.Default directly, inject it instead
    suspend fun loadNews() = withContext(Dispatchers.Default) { /* ... */ }
}

这种依赖项注入模式使测试更容易,因为您可以在单元测试和 Instrumentation 测试中将这些调度器替换为 测试调度器,以使您的测试更具确定性。

挂起函数应能够安全地从主线程调用

挂起函数应该是主线程安全的,这意味着它们可以安全地从主线程调用。如果某个类在协程中执行长时间的阻塞操作,则它负责使用 withContext 将执行移出主线程。这适用于应用中的所有类,无论该类位于架构的哪个部分。

class NewsRepository(private val ioDispatcher: CoroutineDispatcher) {

    // As this operation is manually retrieving the news from the server
    // using a blocking HttpURLConnection, it needs to move the execution
    // to an IO dispatcher to make it main-safe
    suspend fun fetchLatestNews(): List<Article> {
        withContext(ioDispatcher) { /* ... implementation ... */ }
    }
}

// This use case fetches the latest news and the associated author.
class GetLatestNewsWithAuthorsUseCase(
    private val newsRepository: NewsRepository,
    private val authorsRepository: AuthorsRepository
) {
    // This method doesn't need to worry about moving the execution of the
    // coroutine to a different thread as newsRepository is main-safe.
    // The work done in the coroutine is lightweight as it only creates
    // a list and add elements to it
    suspend operator fun invoke(): List<ArticleWithAuthor> {
        val news = newsRepository.fetchLatestNews()

        val response: List<ArticleWithAuthor> = mutableEmptyList()
        for (article in news) {
            val author = authorsRepository.getAuthor(article.author)
            response.add(ArticleWithAuthor(article, author))
        }
        return Result.Success(response)
    }
}

这种模式使您的应用更具可扩展性,因为调用挂起函数的类不必担心对哪种类型的操作使用哪个 Dispatcher。此责任在于执行工作的类。

ViewModel 应创建协程

ViewModel 类应优先创建协程,而不是公开挂起函数来执行业务逻辑。如果 ViewModel 中的挂起函数不是使用数据流公开状态,而只需要发出单个值,则它们可能很有用。

// DO create coroutines in the ViewModel
class LatestNewsViewModel(
    private val getLatestNewsWithAuthors: GetLatestNewsWithAuthorsUseCase
) : ViewModel() {

    private val _uiState = MutableStateFlow<LatestNewsUiState>(LatestNewsUiState.Loading)
    val uiState: StateFlow<LatestNewsUiState> = _uiState

    fun loadNews() {
        viewModelScope.launch {
            val latestNewsWithAuthors = getLatestNewsWithAuthors()
            _uiState.value = LatestNewsUiState.Success(latestNewsWithAuthors)
        }
    }
}

// Prefer observable state rather than suspend functions from the ViewModel
class LatestNewsViewModel(
    private val getLatestNewsWithAuthors: GetLatestNewsWithAuthorsUseCase
) : ViewModel() {
    // DO NOT do this. News would probably need to be refreshed as well.
    // Instead of exposing a single value with a suspend function, news should
    // be exposed using a stream of data as in the code snippet above.
    suspend fun loadNews() = getLatestNewsWithAuthors()
}

视图不应直接触发任何协程来执行业务逻辑。相反,将此责任委托给 ViewModel。这使得您的业务逻辑更容易测试,因为 ViewModel 对象可以进行单元测试,而不是使用测试视图所需的 Instrumentation 测试。

此外,如果在 viewModelScope 中启动工作,则您的协程会自动在配置更改后继续存在。如果您改为使用 lifecycleScope 创建协程,则必须手动处理这种情况。如果协程需要超出 ViewModel 的范围,请查看 业务和数据层中创建协程部分

不要暴露可变类型

优先向其他类暴露不可变类型。这样,对可变类型的所有更改都集中在一个类中,这使得在出现问题时更容易调试。

// DO expose immutable types
class LatestNewsViewModel : ViewModel() {

    private val _uiState = MutableStateFlow(LatestNewsUiState.Loading)
    val uiState: StateFlow<LatestNewsUiState> = _uiState

    /* ... */
}

class LatestNewsViewModel : ViewModel() {

    // DO NOT expose mutable types
    val uiState = MutableStateFlow(LatestNewsUiState.Loading)

    /* ... */
}

数据层和业务层应该暴露挂起函数和Flow

数据层和业务层中的类通常会公开函数来执行一次性调用或接收数据更改通知。这些层中的类应该暴露**用于一次性调用的挂起函数**和**用于通知数据更改的Flow**。

// Classes in the data and business layer expose
// either suspend functions or Flows
class ExampleRepository {
    suspend fun makeNetworkRequest() { /* ... */ }

    fun getExamples(): Flow<Example> { /* ... */ }
}

此最佳实践使调用方(通常是表示层)能够控制在这些层中发生的作业的执行和生命周期,并在需要时取消。

在业务层和数据层中创建协程

对于需要出于不同原因创建协程的数据层或业务层中的类,有不同的选项。

如果在这些协程中要执行的作业仅在用户位于当前屏幕上时才相关,则它应遵循调用方的生命周期。在大多数情况下,调用方将是ViewModel,并且当用户从屏幕导航离开并且ViewModel被清除时,调用将被取消。在这种情况下,应使用coroutineScopesupervisorScope

class GetAllBooksAndAuthorsUseCase(
    private val booksRepository: BooksRepository,
    private val authorsRepository: AuthorsRepository,
) {
    suspend fun getBookAndAuthors(): BookAndAuthors {
        // In parallel, fetch books and authors and return when both requests
        // complete and the data is ready
        return coroutineScope {
            val books = async { booksRepository.getAllBooks() }
            val authors = async { authorsRepository.getAllAuthors() }
            BookAndAuthors(books.await(), authors.await())
        }
    }
}

如果要执行的作业在应用程序打开期间始终相关,并且该作业不绑定到特定屏幕,则该作业应超出调用方的生命周期。对于这种情况,应使用外部CoroutineScope,如Coroutines & Patterns for work that shouldn’t be cancelled 博客文章中所述。

class ArticlesRepository(
    private val articlesDataSource: ArticlesDataSource,
    private val externalScope: CoroutineScope,
) {
    // As we want to complete bookmarking the article even if the user moves
    // away from the screen, the work is done creating a new coroutine
    // from an external scope
    suspend fun bookmarkArticle(article: Article) {
        externalScope.launch { articlesDataSource.bookmarkArticle(article) }
            .join() // Wait for the coroutine to complete
    }
}

externalScope应该由比当前屏幕生命周期更长的类创建和管理,它可以由Application类或作用域到导航图的ViewModel管理。

在测试中注入TestDispatchers

在测试中,应将TestDispatcher的实例注入到您的类中。kotlinx-coroutines-test中有两个可用的实现

  • StandardTestDispatcher:使用调度程序将在其上启动的协程排队,并在测试线程不忙时执行它们。您可以挂起测试线程以让其他排队的协程使用诸如advanceUntilIdle之类的方 法运行。

  • UnconfinedTestDispatcher:以阻塞方式急切地运行新的协程。这通常使编写测试更容易,但为您提供了更少的控制权,无法控制在测试期间协程的执行方式。

有关更多详细信息,请参阅每个调度程序实现的文档。

要测试协程,请使用runTest协程构建器。runTest使用TestCoroutineScheduler跳过测试中的延迟并允许您控制虚拟时间。您还可以使用此调度程序根据需要创建其他测试调度程序。

class ArticlesRepositoryTest {

    @Test
    fun testBookmarkArticle() = runTest {
        // Pass the testScheduler provided by runTest's coroutine scope to
        // the test dispatcher
        val testDispatcher = UnconfinedTestDispatcher(testScheduler)

        val articlesDataSource = FakeArticlesDataSource()
        val repository = ArticlesRepository(
            articlesDataSource,
            testDispatcher
        )
        val article = Article()
        repository.bookmarkArticle(article)
        assertThat(articlesDataSource.isBookmarked(article)).isTrue()
    }
}

所有TestDispatchers都应共享相同的调度程序。这使您可以将所有协程代码在单个测试线程上运行,以使您的测试确定性。runTest将在返回之前等待所有位于同一调度程序上或为测试协程子级的协程完成。

避免使用GlobalScope

这类似于“注入调度程序”的最佳实践。通过使用GlobalScope,您正在硬编码类使用的CoroutineScope,这会带来一些缺点

  • 促进硬编码值。如果您硬编码GlobalScope,您也可能正在硬编码Dispatchers

  • 使测试变得非常困难,因为您的代码在不受控制的作用域中执行,您将无法控制其执行。

  • 您无法拥有一个通用的CoroutineContext来执行作用域本身内置的所有协程。

相反,请考虑为需要超出当前作用域的作业注入CoroutineScope。查看在业务层和数据层中创建协程部分以了解有关此主题的更多信息。

// DO inject an external scope instead of using GlobalScope.
// GlobalScope can be used indirectly. Here as a default parameter makes sense.
class ArticlesRepository(
    private val articlesDataSource: ArticlesDataSource,
    private val externalScope: CoroutineScope = GlobalScope,
    private val defaultDispatcher: CoroutineDispatcher = Dispatchers.Default
) {
    // As we want to complete bookmarking the article even if the user moves
    // away from the screen, the work is done creating a new coroutine
    // from an external scope
    suspend fun bookmarkArticle(article: Article) {
        externalScope.launch(defaultDispatcher) {
            articlesDataSource.bookmarkArticle(article)
        }
            .join() // Wait for the coroutine to complete
    }
}

// DO NOT use GlobalScope directly
class ArticlesRepository(
    private val articlesDataSource: ArticlesDataSource,
) {
    // As we want to complete bookmarking the article even if the user moves away
    // from the screen, the work is done creating a new coroutine with GlobalScope
    suspend fun bookmarkArticle(article: Article) {
        GlobalScope.launch {
            articlesDataSource.bookmarkArticle(article)
        }
            .join() // Wait for the coroutine to complete
    }
}

Coroutines & Patterns for work that shouldn’t be cancelled 博客文章中了解有关GlobalScope及其替代方案的更多信息。

使您的协程可取消

协程中的取消是协作式的,这意味着当协程的Job被取消时,协程不会被取消,直到它挂起或检查取消。如果您在协程中执行阻塞操作,请确保协程是可取消的

例如,如果您要从磁盘读取多个文件,在开始读取每个文件之前,请检查协程是否已取消。一种检查取消的方法是调用ensureActive函数。

someScope.launch {
    for(file in files) {
        ensureActive() // Check for cancellation
        readFile(file)
    }
}

来自kotlinx.coroutines的所有挂起函数(如withContextdelay)都是可取消的。如果您的协程调用它们,则无需执行任何其他工作。

有关协程中取消的更多信息,请查看协程中的取消博客文章

注意异常

协程中未处理的异常可能导致应用程序崩溃。如果可能发生异常,请在使用viewModelScopelifecycleScope创建的任何协程的主体中捕获它们。

class LoginViewModel(
    private val loginRepository: LoginRepository
) : ViewModel() {

    fun login(username: String, token: String) {
        viewModelScope.launch {
            try {
                loginRepository.login(username, token)
                // Notify view user logged in successfully
            } catch (exception: IOException) {
                // Notify view login attempt failed
            }
        }
    }
}

有关更多信息,请查看博客文章协程中的异常,或Kotlin 文档中的协程异常处理

了解有关协程的更多信息

有关更多协程资源,请参阅Kotlin 协程和流的其他资源页面。