Tweet
Tweet

Slide 1

Slide 1 text

Room 時代にも役に立つかも知れない SQLite の Tips 【 Y U M E M I x S a n s a n T e c h M e e t u p 】 A n d r o i d 開 発 に お け る チ ャ レ ン ジ を 語 る Sansan株式会社 技術本部 Bill One Engineeringグループ エンジニア 辰濱 健一

Slide 2

Slide 2 text

2014年にSansanに入社し、徳島県にある「Sansan 神山ラボ」にて勤務。 Sansan、Eight のアプリ開発を担当し、インドにも赴いて国際化対応を担当 した。 グローバル戦略統括部を経て、現在はBill Oneの国際化対応を担当。エンジニ アコミュニティの運営も行っている。 辰濱 健一 Sansan株式会社 技術本部 Bill One Engineeringグループ エンジニア

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

Sansan神山ラボ

Slide 5

Slide 5 text

Agenda - ANR について - SQLite の詳細について - クエリのパフォーマンス計測 - パフォーマンス改善 - Room での tips 本セッションでは SQLite が原因で ANR が出ていた問題を解決した話をします。 (Room が出ていなかったときの話です) 近年は Room が補完してくれている部分もありますが、Room のコアとなる SQLite の事も知っておくと役に立つかも知れません。

Slide 6

Slide 6 text

ANR について

Slide 7

Slide 7 text

• ANR とは、Application Not Responding の略 • UI スレッドが長時間（5秒以上）ブロックされると発生 • ANR が発生すると、ユーザーはアプリを強制終了できる ANR について

Slide 8

Slide 8 text

ANR について ANR を発生させないためには • 通信処理やファイルの読み書きはメインスレッド で行わない • 重たい計算処理もメインスレッドで行わない

Slide 9

Slide 9 text

ANR の検出 • Play Console の Android Vitals • Firebase Crashlytics (new! 2021/秋〜) ANR について

Slide 10

Slide 10 text

ANR のスタックトレースからは、どの UI スレッドが待たされたかが分かるが、 どの処理によって待たされているのかは分からないことがある → CPU プロファイラを使ってどの処理が遅いか特定 【参考 / CPU Profiler を使用して CPU アクティビティを検査する】 https://developer.android.com/studio/profile/cpu-profiler SQLite まわりがあやしかったので、より具体的にどのクエリが遅いか特定 → SQLite をきちんと理解する必要があった ANR について

Slide 11

Slide 11 text

SQLite の詳細について

Slide 12

Slide 12 text

• オープンソースで軽量なリレーショナルデータベースライブラリ • マルチプラットフォーム • SQL が使える • データは一つのファイルに格納される • セキュリティ機能は搭載されていない 【参考 / What Is SQLite?】 https://sqlite.org/index.html • Android OS に標準で搭載されている • 現在では Room が SQLite の抽象化レイヤーとして提供されているので、 Room を利用することが強く推奨されている SQLite について

Slide 13

Slide 13 text

Android では Room の利用が強く推奨されている 出典：SQLite を使用してデータを保存する / Android デベロッパー https://developer.android.com/training/data-storage/sqlite

Slide 14

Slide 14 text

• マルチスレッド対応をしている 【参考 / Using SQLite In Multi-Threaded Applications】 https://www.sqlite.org/threadsafe.html • ロックはファイル単位 • テーブルや列単位のロックは存在しない • スレッドセーフだが、ロックの単位が大きいので待ち時間が多くなる → 1トランザクションごとにファイルのロックが発生している 【参考 / Appropriate Uses For SQLite】 https://www.sqlite.org/whentouse.html SQLite の詳細について

Slide 15

Slide 15 text

• ジャーナルモード ファイルへの更新方法を指定できる （DELETE | TRUNCATE | PERSIST | MEMORY | WAL | OFF） 【参考 / Pragma statements supported by SQLite】 https://www.sqlite.org/pragma.html#pragma_journal_mode • WAL モード：書き込みの反映は早い（が、読み込みは遅い） • SQLIte 3.7.0 (2010-07-21) or later でしか使えない • MEMORY モード：高速（だが揮発する） • 上限に注意。テストには向いてそう SQLite の詳細について

Slide 16

Slide 16 text

• Android OS のバージョンと SQLite バージョン • SQLite は Android OS にバンドルされている • Realm のように、アプリ側でバージョンを指定できない • 前述の WAL モードも API 11 からしか使えない • Room はこのあたりのバージョン差異を吸収している SQLite の詳細について 出典：android.database.sqlite / Android デベロッパー https://developer.android.com/reference/android/database/sqlite/package-summary.html

Slide 17

Slide 17 text

• Android で SQLite を使うコードの例 SQLite の詳細について トランザクションの開始 トランザクションの終了

Slide 18

Slide 18 text

• トランザクションモード • Exclusive モード（default） • 他の全てのトランザクションをロックする • データの一貫性は向上するが、パフォーマンスが出ない • beginTransaction ではこのモードになる • Immediate モード • 他のトランザクション書き込みはロックするが、読み込みはできる • トランザクションの並列度が増し、パフォーマンスが向上する • Phantom Read（更新される前の値の読み込み）が発生するリスクを伴う • beginTransactionNonExclusive という API で呼び出し可能 SQLite の詳細について

Slide 19

Slide 19 text

• TransactionListener • トランザクションのコールバック を受け取ることができる • onBegin() • onCommit() • onRollback() • beginTransactionWithListener で Listener を渡して呼び出す • パフォーマンス測定に活用した SQLite の詳細について

Slide 20

Slide 20 text

クエリのパフォーマンス計測

Slide 21

Slide 21 text

前述の通り、SQLite ではファイル単 位のロックになってしまう。 実処理を短時間で行えるクエリであっ たとしても、直前にスロークエリが実 行されていたら、処理完了まではかな りの時間になってしまう。 → 次の2カ所の時間が欲しい • beginTransaction() → onBegin() • onBegin() -> endTransaction() クエリのパフォーマンス計測 これにより、「UX から推測される遅い処理」と「実処理の時間」を明確にする

Slide 22

Slide 22 text

そこで、SQLiteTransactionListener の出番 クエリのパフォーマンス計測 db.beginTransaction() （transaction lock...） listener.onBegin() （execute ...） db.endTransaction() listener.onCommit() or listener.onRollbaack()

Slide 23

Slide 23 text

クエリのパフォーマンス計測 独自のプロファイラを作った db.beginTransaction() （transaction lock...） listener.onBegin() （execute ...） db.endTransaction() listener.onCommit() or listener.onRollbaack() 1 2

Slide 24

Slide 24 text

クエリのパフォーマンス計測 独自のプロファイラを実装に仕込んでいく（地道に…）

Slide 25

Slide 25 text

クエリのパフォーマンス計測 アプリを動かしてみたログ Main thread で DB を触っている！！ ANR のトリガーになるので要改修 • Logcat に出力しているので、DB アクセスがリアルタイムで分かる • どの操作をしたときに、どのクエリが実行されているか把握しやすい

Slide 26

Slide 26 text

クエリのパフォーマンス計測 アプリを動かしてみたログ db.beginTransaction() （transaction lock...） listener.onBegin() （execute ...） db.endTransaction() listener.onCommit() or listener.onRollbaack() 1 2 重たい処理！！ 待ちが発生 → 実処理が短くても、長時間処理が返ってこないクエリが多々存在する

Slide 27

Slide 27 text

他にも、 • SQL の実行計画を分析（EXPLAIN）で実行計画を見る • .timer on … .timer off で実行時間を測る という手段も使いました。 DB Browser for SQLiteも便利 クエリのパフォーマンス計測 クエリ クエリ結果 クエリの実行情報

Slide 28

Slide 28 text

パフォーマンス改善

Slide 29

Slide 29 text

• メインスレッドでの呼び出し • Transaction 内で不必要な処理をしていた • 複数書き込みで都度 Transaction を張っていた • 不必要な再読込の抑制 • FirstScroll のための全件読み込み ボトルネックのパターン

Slide 30

Slide 30 text

• メインスレッド以外に切り替える方法 • RxJava であれば、observeOn • Coroutine であれば、withContext • Room だとデフォルトではメインスレッドで呼び出すとクラッシュするの ですぐ分かる（安心） メインスレッドでの呼び出しへの対応

Slide 31

Slide 31 text

Transaction 内で不必要な処理をしていた 加工処理などは Transaction 外に移動

Slide 32

Slide 32 text

複数書き込みで都度 Transaction を張っていた 一つのオブジェクトを保存する API を何度も呼ばずに List で受け取れる API も提供する 他にも、複数のテーブルをまとめて一つの Transaction で保存するのも有効

Slide 33

Slide 33 text

• Activity#onResume で DB にアクセスしていて、 Activity に返ってくるたびに DB にアクセス → ViewModel などの中間層でキャッシュして、キャッシュ値を読み込む （キャッシュの更新タイミングには気をつけないといけない） 不必要な再読込の抑制

Slide 34

Slide 34 text

• View に出していないデータの更新による再読み込み • バックグランド処理がトリガーになっていた • 対応 • テーブルを一覧と詳細で分割 • 一覧更新を DB からの変更通知ではなく、 アプリ内イベントでトリガーに更新するようにした 不必要な再読込の抑制 一覧に出している プロパティ 変更されても 一覧は更新不要

Slide 35

Slide 35 text

• FirstScroll のための全件読み込み • 全件読み込まないと、FirstScroll のための 情報を作れない • ページングと相性が悪く、全件読み込むしかない… • 対応 • 全プロパティではなく、FirstScroll 構築に必要な サブセット（id と 日付）だけ一旦読み込む • 他の情報は表示時に遅延読み込み 不必要な再読込の抑制

Slide 36

Slide 36 text

サブセットだけの読み込みの例 不必要な再読込の抑制

Slide 37

Slide 37 text

• id と FirstScroll に必要な情 報だけを全件取得する • 表示領域の id のみ、初回表 示時に遅延読み込み • スクロールのパフォーマン スへの影響は軽微＆一覧が 数万件ある場合などは大き な速度改善になった • Realm のプロパティの遅延 評価みたいですね 全件読み込みの高速化＆遅延読み込み

Slide 38

Slide 38 text

これらの改善を行って、 20倍の高速化になりました！

Slide 39

Slide 39 text

Room での tips

Slide 40

Slide 40 text

ビルド時に生成されるクラスで SQLite を叩いている 生成されたコードを見ると 何をやっているのかよくわかる

Slide 41

Slide 41 text

• ある程度カスタマイズができる（が、通常そんなに触らなくても良さそう） • setQueryCallback(…) • いつ、どのクエリが実行されたのかを把握するには便利 • CRUD のクエリだけなく、BEGIN TRANSACTION なども出る • setJournalMode(…) • デフォルトで最適なモードがあたっている（ので、気にすることはないはず） 【参考 / RoomDatabase.Builder】 https://developer.android.com/reference/androidx/room/RoomDatabase.Builder Roomdatabase.Builder

Slide 42

Slide 42 text

@Transaction をつけると1つのトランザクションにまとめられる （ファイルへの反映回数が1回にまとまるので高速化） 複数の処理を1つのトランザクションにまとめる

Slide 43

Slide 43 text

• Dao で SELECT する列を明示して、サブセットの型で返す テーブルのサブセットだけ取得したいとき 出典：YouTube / What’s new in Room (Android Dev Summit '19) https://youtu.be/_aJsh6P00c0?t=784

Slide 44

Slide 44 text

• Repository 生成時に SupportSQLiteOpenHelper も渡す • Repository 内で SupportSQLiteOpenHelper#getWritableDatabase などを使う Dao で SQLite を直で触りたい場合（あるのか？）

Slide 45

Slide 45 text

• Room は Flowable や LiveData で DB の変更通知を受け取れるが、 テーブルが更新されればとにかく通知される仕組みになっている • 関心のないオブジェクトや列の変更でも emit されてしまい、意図しない 再読み込み（さらなる DB のアクセス）を誘発してしまう • InvalidationTracker や InvalidationTracker.Oberver の実装を見ればよくわかる • 対策 • Dao の Flowable に distinctUntilChanged() をかまして使う • LiveData の場合は MediatorLiveData で distinct して流す 【参考 / Avoid false positive notifications for observable queries】 https://medium.com/androiddevelopers/7-pro-tips-for-room-fbadea4bfbd1#5e38 Room の変更通知について

Slide 46

Slide 46 text

まとめ

Slide 47

Slide 47 text

まとめ - Room は SQLite のラッパーライブラリ - SQLite の知見があると Room の挙動をよく理解できる - Room の変更通知を過信すると、意図しない emit が含まれることがある - これからの Room の進化に期待！ - 暗号化の提供…まだかな？

Slide 48

Slide 48 text

No content