@ObsoleteCoroutinesApi とは「様子見」?

Coroutine で Channel 辺りをウロウロと。

あれ?

This declaration is experimental and its usage should be marked with '@kotlinx.coroutines.ObsoleteCoroutinesApi' or '@UseExperimental(kotlinx.coroutines.ObsoleteCoroutinesApi::class)'

調べてみる。

From the point of usage `ObsoleteCoroutinesApi` is just like experimental. The different is in intent. When API is experimental it might change or might graduate as is. For obsolete API we already know that there are problems with designs that will force us to deprecated this API in the future when we have a better replacement.

Right now there is no replacement for channel operations, so you have no choice but continue using them. However, we plan to replace them with mechanism based on lazy/cold streams (#254) in the future, which will get you much better performance.

What is the recommended approach for @ObsoleteCoroutinesApi #632

Google翻訳で。

使用の観点からObsoleteCoroutinesApiは実験的なようです。 違いは意図しています。 APIが実験的なものである場合、それは変更されるか、またはそのまま卒業するかもしれません。 時代遅れのAPIについては、より良い代替品があるときに将来的にこのAPIを非推奨にするような設計上の問題があることはすでにわかっています。

今のところチャンネル操作に代わるものはないので、あなたには選択肢がないがそれらを使い続けることができる。 ただし、将来的にはレイジー/コールドストリーム（＃254）に基づくメカニズムに置き換える予定です。これにより、パフォーマンスが大幅に向上します。

まとめ


@ExperimentalCoroutinesApi

→ 将来的には、変更される or そのまま。




@ObsoleteCoroutinesApi

→ 設計上の問題がある。

→ 今現在、代替えはない。

→ 将来的には非推奨。

アンダースコアがついてるのはそゆこと?


_events.consumeEach {

チャンネル周りは、今は「様子見」がいいのでしょうね。

【Android】Kotlin でモダンな concurrency その5

ライフサイクルとコルーチン

Actor は、UI管理にも便利で、タスクのキャンセルをシンプルにし、UIスレッドのオーバーロードを避けることができます。

まず、Activity に適用する JobHolder インターフェースを作成します。これは、セットしたタスクの親となり、それのキャンセルを可能にします。


interface JobHolder {
  val job: Job
}

Activity が destroy されるときに、job.cancel() を行います。


class MyActivity : AppCompatActivity(), JobHolder {

  override val job: Job = Job() // the instance of a Job for this activity

  override fun onDestroy() {
    super.onDestroy()
    job.cancel() // cancel the job when activity is destroyed
  }
}

Extension Function にして、JobHolder の すべての View からアクセス可能にします。


val View.contextJob: Job
  get() = (context as? JobHolder)?.job ?: NonCancellable

これらを組み合わせて、setOnClick に onClick のアクションを管理させるための conflated な Actor を作らせます。複数回の連続クリックは無視され、ANR を避けることができます。

そして、これらのアクションは、contextJob のコンテキストで実行されます。

また、Activity が destroy されるとキャンセルもされます。


fun View.setOnClick(action: suspend () -> Unit) {
  val eventActor = actor<Unit>(
    context = UI,
    start = CoroutineStart.UNDISPATCHED,
    capacity = Channel.CONFLATED,
    parent = contextJob
  ) {
    for (event in channel) action()
  }
  setOnClickListener { eventActor.offer(Unit) }
}

この例では、ここでは多すぎるイベントを無視するために Channel を conflated としてセットしています。すべてをイベントキューとしたい場合は、Channel.UNLIMITED とすることができます。その場合でも ANR は発生しません。

コルーチンとライフサイクルを組み合わせて、UIタスクのキャンセルを自動化することもできます。


val LifecycleOwner.untilDestroy: Job get() {
  val job = Job()

  lifecycle.addObserver(object: LifecycleObserver {
    @OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
    fun onDestroy() { job.cancel() }
  })
  return job
}

// 使い方
launch(UI, parent = untilDestroy) {
  // 何らかの処理
}

【Android】Kotlin でモダンな concurrency その1
【Android】Kotlin でモダンな concurrency その2
【Android】Kotlin でモダンな concurrency その3
【Android】Kotlin でモダンな concurrency その4


関連ワード:  Kotlin・開発・・・

【Android】Kotlin でモダンな concurrency その4

Channel を使ってコールバック不要に

Channel の定義 (JetBrains のドキュメントより):

Channel は、概念的に BlockingQueue とよく似ています。主な違いの一つは、Put の代わりに「送信中断」をを持ち、Take の代わりに「受信中断」を持つことです。

Blocking Queues

Actor

Channel をシンプルに使えるツールが Actor です。

Actor は Handler と非常によく似ており、コルーチンのコンテキスト（つまり、アクションを実行するスレッド）を定義し、シーケンシャルに実行します。

コルーチンを使っており、キャパシティを決めて実行を中断することができます。

Actor は基本的に、処理をコルーチンチャンネルに転送します。実行順序と実行するコンテキストを限定することを保証します。

これで、synchronize は不要となり、すべてのスレッドはフリーです。


protected val updateActor by lazy {
  actor<Update>(UI, capacity = Channel.UNLIMITED) {
    for (update in channel) when (update) {
      Refresh -> updateList()
        is Filter -> filter.filter(update.query)
        is MediaUpdate -> updateItems(update.mediaList as List<T>)
        is MediaAddition -> addMedia(update.media as T)
        is MediaListAddition -> addMedia(update.mediaList as List<T>)
        is MediaRemoval -> removeMedia(update.media as T)
    }
  }
}

// 使い方
suspend fun filter(query: String?) = updateActor.offer(Filter(query))

この例では、実行するアクションを選択する際、sealed クラスを利用しています。


sealed class Update
object Refresh : Update()
class Filter(val query: String?) : Update()
class MediaAddition(val media: Media) : Update()

すべてのアクションはキューとなり、決してパラレルには実行されません。mutable なものを密閉するにはいい方法です。

(つづく)

【Android】Kotlin でモダンな concurrency その1
【Android】Kotlin でモダンな concurrency その2
【Android】Kotlin でモダンな concurrency その3