【Jetpack Compose】「Layout Inspector Recomposition counts」で re-compose 回数を確認する

Jetpack Compose を使っていると、

いつ、どの composable が、 compose されているか、

パフォーマンスが重ければ重いほど気になります。

確認してみましょう。

 

Layout Inspector

すごく便利そうな AndroidStudio の機能です。

【 Jetpack Compose】Layout Inspector Recomposition counts

👉 Compose のパフォーマンス  |  Jetpack Compose  |  Android Developers hatena-bookmark


[Tools]

  ↓

[Layout Inspector]

 

利用条件

端末側で設定が必要です。


表示属性検査を有効にする

【 Jetpack Compose】Layout Inspector Recomposition counts

👉 Compose のツール  |  Jetpack Compose  |  Android Developers hatena-bookmark

R8 などは OFFにする。


debug {
  minifyEnabled false // for layout inspector
  proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}

あと、一番ネックになるのがこれ。

This is only available in Electric Eel at the moment:

"For even more cutting edge features, you can take a sneak peek at the Android Studio Electric Eel release in the Canary channel [...] These features will be promoted to more stable channels once we have your feedback and make improvements, so please try them out."

👉 android - Jetpack Compose: The layout inspector is not showing the menu for recomposition counts - Stack Overflow hatena-bookmark


Android Studio Electric Eel release in the Canary channel

今はまだ、非Statble な「Android Studio Electric Eel」でしか使えないようです。

JetBrains の「Toolbox」を使っていれば問題ありません。

JetBrains Toolbox で Android Studio の Stable/Beta/Canary が同時に管理できる?

使ってない人は、すぐインストールしておきましょう。

👉 JetBrains Toolbox で Android Studio の Stable/Beta/Canary が同時に管理できる? hatena-bookmark

 

結果

左下に Layout Inspector が開いたら以下。


[Component Tree]

  ↓

[View Option]

  ↓

[Show Recomposition counts]

compose counts

ヘビーな LazyVerticalGrid でやってみました。

re-compose されると、その部分が赤く変色します。



しかしこれ、

重すぎやせんか、ツールとして。

しかも、よく落ちる。

今後、期待しています。

👉 「Compose Compiler Reports」 recompose される条件とタイミングと範囲を知りたい hatena-bookmark
👉 【Jetpack Compose】LazyVerticalGrid - Profile GPU Rendering / Profile HWUI rendering - YouTube hatena-bookmark

【AndroidStudio】DesignTools の Preview デフォルトを「Split」→「Code」にする

JetPack Compose を触りながら、

コードの編集をしてファイルを切り替えていると、

デフォルトで右側に「Preview」画面が表示されますね。

なんかうざい。

Default Split

デフォルトは 「Split」 でなく 「Code」 でいいのに。

デフォルトを「Code」にしておきましょう。


[Preferences]

  ↓

[Editor]

  ↓

[Design Tools]

最近、この Preview画面、

ずっと Refreshing 状態のときがあったり、

デザインのためのビルドされるのも意図したときだけにしたかったので。

【Jetpack Compose】Compose (androidx.compose.*) のバージョンが分かれている件

元は、こんな感じで問題ありませんでした。


ext.versions = [
  'kotlin'  : '1.6.21'
  'compose' : '1.2.0-rc02'
]

dependencies {
  classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:${versions.kotlin}"
}

composeOptions {
  kotlinCompilerExtensionVersion versions.compose
}


implementation "androidx.compose.material:material:${versions.compose}"
implementation "androidx.compose.material:material-icons-extended:${versions.compose}"
implementation "androidx.compose.ui:ui:${versions.compose}"
implementation "androidx.compose.ui:ui-tooling-preview:${versions.compose}"
debugImplementation "androidx.compose.ui:ui-tooling:${versions.compose}"
debugImplementation "androidx.compose.ui:ui-test-manifest:${versions.compose}"
androidTestImplementation "androidx.compose.ui:ui-test-junit4:${versions.compose}"

アップデート通知が出たので、いつものように


1.3.0-alpha01

に上げました。


ext.versions = [
  'kotlin'  : '1.6.21'
  'compose': '1.3.0-alpha01'
]

...

ビルドできなくなりました。

なんでや。

 

■ kotlin と compose の関係

kotlin と compose には、お互いに対応するバージョンが決まっていましたね!

Compose to Kotlin Compatibility Map

👉 Compose to Kotlin Compatibility Map  |  Android Developers hatena-bookmark

あれ、compose「1.3.0-alpha01」がないよ!

 

■ 「Compose」 は1つではない

Jetpack Compose is multiple things under one name:

- A compiler plugin that helps efficiently calculate the difference between two in-memory tree data structures
- A new UI toolkit for Android
- A new UI toolkit for desktop apps (Compose Desktop)

👉 Drop "androidx" from Jetpack Compose package name, for multiplatform, before 1​.​0 release. · Change.org hatena-bookmark

どうやら、Android でいうと compose は

- compose compiler
- compose ui toolkit

の2つに分かれているようです

👉 This version (1.2.0-alpha08) of the Compose Compiler requires Kotlin version 1.6.20 but you appear to be using Kotlin version 1.6.21 which is not known to be compatible. hatena-bookmark

 

■ まとめ

上記2つのことを考慮して書き換えます。


ext.versions = [
  'kotlin'    : '1.7.0'
  'compose'   : '1.2.0',         // compose-compiler
  'composeUi' : '1.3.0-alpha01'  // compose-ui
]

dependencies {
  classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:${versions.kotlin}"
}

composeOptions {
  kotlinCompilerExtensionVersion versions.compose // compose-compiler
}

// compose-ui
implementation "androidx.compose.material:material:${versions.composeUi}"
implementation "androidx.compose.material:material-icons-extended:${versions.composeUi}"
implementation "androidx.compose.ui:ui:${versions.composeUi}"
implementation "androidx.compose.ui:ui-tooling-preview:${versions.composeUi}"
debugImplementation "androidx.compose.ui:ui-tooling:${versions.composeUi}"
debugImplementation "androidx.compose.ui:ui-test-manifest:${versions.composeUi}"
androidTestImplementation "androidx.compose.ui:ui-test-junit4:${versions.composeUi}"

👉 This version (1.2.0-alpha08) of the Compose Compiler requires Kotlin version 1.6.20 but you appear to be using Kotlin version 1.6.21 which is not known to be compatible. hatena-bookmark

@Composable の LifecycleOwner は誰なのか - collectAsStateWithLifecycle

 

Compose までの Flow の collect

coroutine など非同期処理を行う場合ライフサイクルの考慮が必要でしたね!


viewLifecycleOwner.lifecycleScope.launch {
  viewLifecycleOwner.lifecycle.repeatOnLifecycle(STARTED) {
    myViewModel.myUiState.collect {
      // ... 
    }
  }
}

これは、Fragment のビューが STARTED になったときに収集を開始し、RESUMED まで継続し、STOPPED に戻ったときに停止します。

@Composable の LifecycleOwner は誰なのか - collectAsStateWithLifecycle

👉 【MVVM】 Kotlin Flow で使える5つの利用パターン hatena-bookmark

生き死にだけでではないのです。

collect する期間も考えなくてはなりません。

 

Compose では

@Composable 内で、


val items by viewModel.items.collectAsState(initial = emptyList())

というような形で、かんたんに Flow や StateFlow を 収集できます。

しかし、

バックスタック中に、無駄に APIにリクエストしたり、DBにクエリーを投げたりしてません?

逆に、更新されずに古いままの更新されてない画面見せられたりして萎えたりもします。

 

collectAsStateWithLifecycle() の登場

👉 collectAsStateWithLifecycleが追加されたぞ - Qiita hatena-bookmark

所属は以下のようです。

androidx.lifecycle.lifecycle-runtime-compose


implementation "androidx.lifecycle:lifecycle-runtime-compose:2.6.0-alpha01"

実装を見てみます。

ホットな StateFlow と コールドな Flow に向けて2つずつ公開されています。


fun <T> StateFlow<T>.collectAsStateWithLifecycle(
    lifecycleOwner: LifecycleOwner = LocalLifecycleOwner.current,
    minActiveState: Lifecycle.State = Lifecycle.State.STARTED,
    context: CoroutineContext = EmptyCoroutineContext
): State<T> 

fun <T> StateFlow<T>.collectAsStateWithLifecycle(
    lifecycle: Lifecycle,
    minActiveState: Lifecycle.State = Lifecycle.State.STARTED,
    context: CoroutineContext = EmptyCoroutineContext
): State<T> 

fun <T> Flow<T>.collectAsStateWithLifecycle(
    initialValue: T,
    lifecycleOwner: LifecycleOwner = LocalLifecycleOwner.current,
    minActiveState: Lifecycle.State = Lifecycle.State.STARTED,
    context: CoroutineContext = EmptyCoroutineContext
): State<T>

fun <T> Flow<T>.collectAsStateWithLifecycle(
    initialValue: T,
    lifecycle: Lifecycle,
    minActiveState: Lifecycle.State = Lifecycle.State.STARTED,
    context: CoroutineContext = EmptyCoroutineContext
): State<T>

ライフサイクルや期間を与えて collect 動作を設定できます。

ありがとうございます。

 

LifecycleOwner は誰なのか

前述引用の実装コードより。


...
lifecycleOwner: LifecycleOwner = LocalLifecycleOwner.current,
...




LocalLifecycleOwner

ライフサイクルのオーナーといえば、Compose 以前は、

Activity、Fragment、View

ぐらいで考えていましたが。

きっとオーナーは、Activity ではなく、

最上位のルートの @Composable

ではなかろうか。

いや、ワンチャン Activity かもしれん。

見てみましょう。


println("オーナー → ${LocalLifecycleOwner.current}")

 

結果


D: オーナー → androidx.navigation.NavBackStackEntry@4dc222c4

「NavBackStackEntry」さんらしいですわ。

(つづく...)

【Jetpack Compose】ViewModel を捨てて Repository を Composable に直結する

 

気になるのはライフサイクル。

 

きっかけ

フル Compose でよくあるTodoのようなメモのようなアプリを作ってみました。

一通りの機能は実装しました。




👉 Jetpack Compose without ViewModel #shorts - YouTube hatena-bookmark

いろいろ Compose を試しながら進んでいくと ViewModel がスカスカになりました。


@HiltViewModel
class TodoViewModel @Inject constructor(
  private val repository: TodoRepositoryInterface
) : ViewModel() {

  val items: Flow<List<Todo>> = repository.load()

  fun insert(text: String) = repository.insert(text)

  fun update(id: Long, text: String) = repository.update(id, text)

  fun delete(id: Long) = repository.delete(id)

}

ViewModel いらなくね?

ViewModel を省略して、Repository を直結します。

 

結果

以下、少しの書き換えで問題なく動きます。


@Composable
fun TodoScreen(
  //viewModel: TodoViewModel = hiltViewModel()
  repository: TodoRepository = TodoRepository(
    Database(
      AndroidSqliteDriver(
        schema = Database.Schema,
        context = LocalContext.current,
        name = "database.db"
      )
    )
  )
) {




//val items by viewModel.items.collectAsState(initial = emptyList())
val items by repository.load().collectAsState(initial = emptyList())




//viewModel.insert(target.text)
repository.insert(target.text)




//viewModel.update(target.id, target.text) 
repository.update(target.id, target.text)




//viewModel.delete(target.id)
repository.delete(target.id)




//viewModel.delete(target.id)
repository.delete(target.id)

画面回転問題なし、メモリーリークもありません。

すんなりです。

Square製 SQLDelight + Flow(coroutine extension) を使っていますが、

Room + LiveData でもいけると思います。

Composable で Flow(LiveData) を受け取った瞬間に、

collectAsState(ObserveAsState) で State に変換できるんなら、

それのほうが良くね?

ライフサイクルの差も気にしなくていいし。

しかし、緩衝国がなくなるのはなんだか不安です。

Hilt で @Singleton で、ぶち込んでやりたかったです。

あ、でもこれ、 re-compose のたびに、Repository インスタンスが...

(つづく...)

👉 「SwiftUIでMVVMを採用するのは止めよう」と思い至った理由 - Qiita hatena-bookmark
👉 ViewModel はいつ生まれていつ死ぬか 【→ Jetpack Compose】 hatena-bookmark
👉 Jetpack ComposeとViewModelについて考える - Blog - Mori Atsushi hatena-bookmark