🤜🏼 🏴 🕢 レルムのカスケード削除がどのように長いスタートを勝ち取ったかの物語 👨‍👦 🌆 🕺🏻

すべてのユーザーは、モバイルアプリでは当然のことながら高速起動と応答性の高いUIを採用しています。アプリケーションの起動に時間がかかると、ユーザーは悲しくて怒ります。アプリケーションの使用を開始する前であっても、顧客エクスペリエンスを簡単に台無しにしたり、ユーザーを失ったりする可能性があります。

Dodo Pizzaアプリケーションが平均3秒で開始することがわかったら、一部の「幸運なもの」の場合は15〜20秒かかります。

カットの下には、ハッピーエンドのストーリーがあります。レルムデータベースの成長、メモリリーク、ネストされたオブジェクトの保存方法、そしてすべてをまとめて修正した方法についてです。

記事の著者：Maxim Kachinkinは、DodoPizzaのAndroid開発者です。

アプリケーションアイコンをクリックしてから最初のアクティビティのonResume（）までの3秒は無限大です。また、一部のユーザーの場合、起動時間は15〜20秒に達しました。これはどうして可能ですか？

読む時間がない人のための非常に短い要約

Realm. , . . , — 1 . — - -.

問題の検索と分析

今日、モバイルアプリケーションは、迅速に起動し、応答する必要があります。しかし、それはモバイルアプリだけではありません。サービスや会社とやり取りするユーザーエクスペリエンスは複雑です。たとえば、私たちの場合、配達速度はピザサービスの重要な指標の1つです。配達が速ければ、ピザは熱くなり、今食べたい顧客は長く待つ必要はありません。アプリケーションの場合、アプリケーションが20秒しか開始しない場合、ピザにどれくらいの時間がかかるので、高速サービスの感覚を作り出すことが重要です。

最初は、アプリケーションが数秒間起動されることがあるという事実に直面しましたが、その後、他の同僚から「長い」という苦情が寄せられ始めました。しかし、この状況を安定して繰り返すことはできませんでした。

それはどのくらい長いですか？によるGoogleのドキュメントでは、アプリケーションのコールドスタートに5秒もかからない場合、「通常の種類」と見なされます。 Dodo Pizza Androidアプリケーションは（Firebase _app_startメトリックによると）コールドスタートで平均3秒で起動されました-彼らが言うように、「良くない、ひどい」。

しかし、その後、アプリケーションが非常に、非常に、非常に長い間起動されたという苦情が現れ始めました！まず、「非常に、非常に、非常に長い」ものを測定することにしました。そして、これにはFirebase trace App starttraceを使用しました。

この標準トレースは、ユーザーがアプリケーションを開いてから最初のアクティベーションのonResume（）が実行されるまでの時間を測定します。 Firebase Consoleでは、このメトリックは_app_startと呼ばれます。それは明らかになった：

コールドスタート時間の中央値が5秒未満であるにもかかわらず、95パーセンタイルを超えるユーザーの起動時間はほぼ20秒です（一部のユーザーはそれ以上です）。
起動時間は一定ではありませんが、時間の経過とともに増加します。しかし、時々転倒が観察されます。分析スケールを90日に増やしたときに、このパターンが見つかりました。

2つの考えが思い浮かびました。

何かが漏れています。
この「何か」はリリース後に破棄され、その後再びリークされます。

「おそらくデータベースの何か」と私たちは考え、正しかった。まず、データベースをキャッシュとして使用し、移行中にクリアします。次に、アプリケーションの起動時にデータベースがロードされます。それはすべて一緒に収まります。

レルムデータベースの何が問題になっていますか

最初のインストールからさらにアクティブな使用の過程で、アプリケーションの存続期間中にデータベースのコンテンツがどのように変化するかを確認し始めました。あなたはを通してレルムデータベースの内容を表示することができStethoてファイルを開くか、より詳細にかつ視覚的にレルムメーカー。ADBを介してデータベースの内容を表示するには、レルムデータベースファイルをコピーします。

adb exec-out run-as ${PACKAGE_NAME} cat files/${DB_NAME}

さまざまな時点でデータベースの内容を調べたところ、特定のタイプのオブジェクトの数が絶えず増加していることがわかりました。

写真は、2つのファイルのRealm Studioのフラグメントを示しています。左側-インストール後しばらくしてからのアプリケーションデータベース、右側-アクティブに使用した後。オブジェクトの数ことが分かるImageEntityとは、MoneyType（スクリーンショットは、各タイプのオブジェクトの数を示す）が大きく成長しています。

データベースの成長と起動時間の関係

制御されていないデータベースの増加は非常に悪いです。しかし、これはアプリケーションの起動時間にどのように影響しますか？ActivityManagerを使用して測定するのは非常に簡単です。Android 4.4以降、logcatは表示された文字列と時刻でログを表示します。この時間は、アプリケーションの開始からアクティビティのレンダリングの終了までの間隔に等しくなります。この間、イベントが発生します。

プロセスを開始します。
オブジェクトの初期化。
アクティビティの作成と初期化。
レイアウトの作成。
アプリケーションのレンダリング。

私たちに適しています。-Sフラグと-Wフラグを指定してADBを実行すると、開始時刻を指定して拡張出力を取得できます。

adb shell am start -S -W ru.dodopizza.app/.MainActivity -c android.intent.category.LAUNCHER -a android.intent.action.MAIN

そこからgrep -i WaitTime時間を収集すると、このメトリックの収集を自動化して、結果をグラフィカルに確認できます。以下のグラフは、アプリケーションの起動時間のアプリケーションのコールドスタート数への依存性を示しています。

同時に、ベースのサイズと成長の依存性は同じで、4MBから15MBに増加しました。全体として、時間の経過とともに（コールドスタートの増加に伴い）、アプリケーションの起動時間とデータベースのサイズの両方が増加したことがわかりました。私たちの手には仮説があります。今では依存関係を確認するために残った。そのため、「リーク」を削除して、起動が高速化されるかどうかを確認することにしました。

データベースの無限の成長の理由

「リーク」を取り除く前に、なぜそれらがまったく現れたのかを理解する価値があります。これを行うために、レルムが何であるかを覚えておきましょう。

レルムは非リレーショナルデータベースです。これにより、Android上の多くのORMリレーショナルデータベースが説明するのと同様の方法で、オブジェクト間の関係を説明できます。同時に、レルムは、変換とマッピングの数を最小限に抑えて、オブジェクトをメモリに直接保存します。これにより、ディスクからデータを非常にすばやく読み取ることができます。これは、レルムの強みであり、愛されています。

（この記事の目的のために、この説明は私たちにとって十分です。あなたはクールなドキュメントまたは彼らのアカデミーでレルムについてもっと読むことができます）。

多くの開発者は、リレーショナルデータベース（たとえば、内部でSQLを使用するORMデータベース）をより多く使用することに慣れています。また、カスケードデータの削除などは当然のことのように思われることがよくあります。しかし、レルムではありません。

ちなみに、カスケード削除機能は長い間求められてきました。この改訂とそれに関連する別の改訂が活発に議論されました。もうすぐやる気がしました。しかし、その後、すべてが強いリンクと弱いリンクの導入に変わり、これもこの問題を自動的に解決します。このタスクでは、かなり活発でアクティブなプルリクエストがありましたが、内部の問題のために一時停止されました。

カスケード削除なしのデータリーク

存在しないカスケード削除を希望する場合、データはどの程度正確にリークしますか？ Realmオブジェクトをネストしている場合は、それらを削除する必要があります。

（ほぼ）実際の例を見てみましょう。オブジェクトがありますCartItemEntity：

@RealmClass
class CartItemEntity(
 @PrimaryKey
 override var id: String? = null,
 ...
 var name: String = "",
 var description: String = "",
 var image: ImageEntity? = null,
 var category: String = MENU_CATEGORY_UNKNOWN_ID,
 var customizationEntity: CustomizationEntity? = null,
 var cartComboProducts: RealmList<CartProductEntity> = RealmList(),
 ...
) : RealmObject()

カート内の製品には、写真ImageEntity、カスタマイズされた材料など、さまざまなフィールドがありますCustomizationEntity。また、バスケット内の製品は、独自の製品セットと組み合わせることもできますRealmList (CartProductEntity)。リストされているフィールドはすべてレルムオブジェクトです。同じIDの新しいオブジェクト（copyToRealm（）/ copyToRealmOrUpdate（））を挿入すると、このオブジェクトは完全に上書きされます。ただし、すべての内部オブジェクト（image、customizationEntity、cartComboProducts）は親との接続を失い、データベースに残ります。

それらとの接続が失われたため、それらを読み取ったり削除したりすることはありません（明示的に参照するか、「テーブル」全体をクリアしない限り）。これを「メモリリーク」と呼びました。

Realmを使用する場合、そのような操作の前に、すべての要素を明示的に調べ、すべてを明示的に削除する必要があります。これは、たとえば、次のように実行できます。

val entity = realm.where(CartItemEntity::class.java).equalTo("id", id).findFirst()
if (first != null) {
 deleteFromRealm(first.image)
 deleteFromRealm(first.customizationEntity)
 for(cartProductEntity in first.cartComboProducts) {
   deleteFromRealm(cartProductEntity)
 }
 first.deleteFromRealm()
}
//

これを行うと、すべてが正常に機能します。この例では、image、customizationEntity、およびcartComboProducts内に他のネストされたレルムがないことを前提としているため、他のネストされたループや削除はありません。

クイックソリューション

まず、最も成長の速いオブジェクトをクリーンアップして結果を確認することにしました。これで元の問題が解決するかどうかを確認します。最初に、最も単純で直感的な解決策が作成されました。つまり、各オブジェクトは、それ自体の後に子を削除する責任があります。これを行うために、ネストされたRealmオブジェクトのリストを返す次のインターフェイスを導入しました。

interface NestedEntityAware {
 fun getNestedEntities(): Collection<RealmObject?>
}

そして、それをレルムオブジェクトに実装しました。

@RealmClass
class DataPizzeriaEntity(
 @PrimaryKey
 var id: String? = null,
 var name: String? = null,
 var coordinates: CoordinatesEntity? = null,
 var deliverySchedule: ScheduleEntity? = null,
 var restaurantSchedule: ScheduleEntity? = null,
 ...
) : RealmObject(), NestedEntityAware {

 override fun getNestedEntities(): Collection<RealmObject?> {
   return listOf(
       coordinates,
       deliverySchedule,
       restaurantSchedule
   )
 }
}

getNestedEntities我々は、すべての子供たちにフラットなリストを返します。また、各子オブジェクトはNestedEntityAwareインターフェイスを実装して、削除する内部Realmオブジェクトがあることを通知できます。次に例を示しScheduleEntityます。

@RealmClass
class ScheduleEntity(
 var monday: DayOfWeekEntity? = null,
 var tuesday: DayOfWeekEntity? = null,
 var wednesday: DayOfWeekEntity? = null,
 var thursday: DayOfWeekEntity? = null,
 var friday: DayOfWeekEntity? = null,
 var saturday: DayOfWeekEntity? = null,
 var sunday: DayOfWeekEntity? = null
) : RealmObject(), NestedEntityAware {

 override fun getNestedEntities(): Collection<RealmObject?> {
   return listOf(
       monday, tuesday, wednesday, thursday, friday, saturday, sunday
   )
 }
}

など、オブジェクトのネストを繰り返すことができます。

次に、ネストされたすべてのオブジェクトを再帰的に削除するメソッドを記述します。このメソッド（拡張機能の形式で作成）deleteAllNestedEntitiesは、すべてのトップレベルオブジェクトを取得deleteNestedRecursivelyし、NestedEntityAwareインターフェイスを使用してネストされたすべてのものを再帰的に削除します。

fun <T> Realm.deleteAllNestedEntities(entities: Collection<T>,
 entityClass: Class<out RealmObject>,
 idMapper: (T) -> String,
 idFieldName : String = "id"
 ) {

 val existedObjects = where(entityClass)
     .`in`(idFieldName, entities.map(idMapper).toTypedArray())
     .findAll()

 deleteNestedRecursively(existedObjects)
}

private fun Realm.deleteNestedRecursively(entities: Collection<RealmObject?>) {
 for(entity in entities) {
   entity?.let { realmObject ->
     if (realmObject is NestedEntityAware) {
       deleteNestedRecursively((realmObject as NestedEntityAware).getNestedEntities())
     }
     realmObject.deleteFromRealm()
   }
 }
}

最も成長の速いオブジェクトでこれを行い、何が起こったかを確認しました。

その結果、このソリューションでカバーしたオブジェクトは成長を停止しました。そして、基地の全体的な成長は鈍化しましたが、止まりませんでした。

「通常の」ソリューション

ベースはゆっくりと成長し始めましたが、それでも成長していました。それで私たちはさらに調べ始めました。私たちのプロジェクトでは、レルムのデータキャッシングが非常に積極的に使用されています。したがって、各オブジェクトにネストされたすべてのオブジェクトを書き込むのは面倒であり、コードを変更するときにオブジェクトを指定するのを忘れることができるため、エラーのリスクが高まります。

インターフェイスを使用するのではなく、すべてが単独で機能するようにしたかったのです。

何かを単独で機能させたい場合は、リフレクションを使用する必要があります。これを行うには、クラスの各フィールドを調べて、それがRealmオブジェクトであるかオブジェクトのリストであるかを確認します。

RealmModel::class.java.isAssignableFrom(field.type)

RealmList::class.java.isAssignableFrom(field.type)

フィールドがRealmModelまたはRealmListの場合、このフィールドのオブジェクトをネストされたオブジェクトのリストに追加します。すべてが上で行ったのとまったく同じですが、ここでのみそれが単独で行われます。カスケード削除メソッド自体は非常に単純で、次のようになります。

fun <T : Any> Realm.cascadeDelete(entities: Collection<T?>) {
 if(entities.isEmpty()) {
   return
 }

 entities.filterNotNull().let { notNullEntities ->
   notNullEntities
       .filterRealmObject()
       .flatMap { realmObject -> getNestedRealmObjects(realmObject) }
       .also { realmObjects -> cascadeDelete(realmObjects) }

   notNullEntities
       .forEach { entity ->
         if((entity is RealmObject) && entity.isValid) {
           entity.deleteFromRealm()
         }
       }
 }
}

拡張機能filterRealmObjectは、レルムオブジェクトのみをフィルタリングして渡します。このメソッドgetNestedRealmObjectsは、リフレクションによってネストされたすべてのRealmオブジェクトを検索し、それらを線形リストに追加します。次に、同じことを再帰的に行います。削除するときは、オブジェクトの有効性を確認する必要がありisValidます。これは、異なる親オブジェクトが同じネストされたオブジェクトを持っている可能性があるためです。これを回避し、新しいオブジェクトを作成するときはid自動生成を使用することをお勧めします。

getNestedRealmObjectsメソッドの完全な実装

private fun getNestedRealmObjects(realmObject: RealmObject) : List<RealmObject> {
 val nestedObjects = mutableListOf<RealmObject>()
 val fields = realmObject.javaClass.superclass.declaredFields

//   ,     RealmModel   RealmList
 fields.forEach { field ->
   when {
     RealmModel::class.java.isAssignableFrom(field.type) -> {
       try {
         val child = getChildObjectByField(realmObject, field)
         child?.let {
           if (isInstanceOfRealmObject(it)) {
             nestedObjects.add(child as RealmObject)
           }
         }
       } catch (e: Exception) { ... }
     }

     RealmList::class.java.isAssignableFrom(field.type) -> {
       try {
         val childList = getChildObjectByField(realmObject, field)
         childList?.let { list ->
           (list as RealmList<*>).forEach {
             if (isInstanceOfRealmObject(it)) {
               nestedObjects.add(it as RealmObject)
             }
           }
         }
       } catch (e: Exception) { ... }
     }
   }
 }

 return nestedObjects
}

private fun getChildObjectByField(realmObject: RealmObject, field: Field): Any? {
 val methodName = "get${field.name.capitalize()}"
 val method = realmObject.javaClass.getMethod(methodName)
 return method.invoke(realmObject)
}

その結果、クライアントコードでは、すべてのデータ変更操作に「カスケード削除」を使用します。たとえば、挿入操作の場合、次のようになります。

override fun <T : Entity> insert(
 entityInformation: EntityInformation,
 entities: Collection<T>): Collection<T> = entities.apply {
 realmInstance.cascadeDelete(getManagedEntities(entityInformation, this))
 realmInstance.copyFromRealm(
     realmInstance
         .copyToRealmOrUpdate(this.map { entity -> entity as RealmModel }
 ))
}

最初に、メソッドgetManagedEntitiesは追加されたすべてのオブジェクトを取得し、次にメソッドcascadeDeleteは新しいオブジェクトを書き込む前に、収集されたすべてのオブジェクトを再帰的に削除します。最終的に、アプリケーション全体でこのアプローチを使用することになります。レルムのメモリリークは完全になくなりました。アプリケーションのコールドスタート数に対する起動時間の依存性について同じ測定を実行すると、結果が表示されます。

緑の線は、ネストされたオブジェクトの自動カスケード削除中のコールドスタートの数に対するアプリケーションの起動時間の依存性を示しています。

結果と結論

増え続けるレルムデータベースは、アプリケーションの起動を大幅に遅くしました。ネストされたオブジェクトの独自の「カスケード削除」を備えたアップデートをリリースしました。そして今、私たちは_app_startメトリックを通じて、私たちの決定がアプリケーションの起動時間にどのように影響したかを追跡および評価します。

分析のために、90日の時間間隔を取り、次のことを確認します。アプリケーションの起動時間の中央値とユーザーの95パーセントに該当する時間の両方が減少し始め、それ以上増加しません。

7日間のグラフを見ると、_app_startメトリックは完全に適切に見え、1秒未満です。

また、_app_startの中央値が5秒を超えると、デフォルトでFirebaseが通知を送信することも追加する必要があります。ただし、ご覧のとおり、これに依存するのではなく、明示的に確認してください。

レルムデータベースの特徴は、それが非リレーショナルデータベースであるということです。その単純な使用法、ORMソリューションでの作業とオブジェクトのリンクの類似性にもかかわらず、カスケード削除はありません。

これが考慮されていない場合、ネストされたオブジェクトは蓄積され、「リーク」します。データベースは絶えず大きくなり、それがアプリケーションの速度低下や起動に影響を及ぼします。

私はすぐに箱のない外ではありませんが、長い持っていたレルムにカスケード削除のオブジェクトをどのように行う我々の経験、共有の話と話を。私たちの場合、これによりアプリケーションの起動時間が大幅に短縮されました。

この機能の差し迫った外観についての議論にもかかわらず、レルムにカスケード削除がないことは設計によって行われます。新しいアプリケーションを設計する場合は、これを考慮してください。また、すでにレルムを使用している場合は、そのような問題がないかどうかを確認してください。

レルムのカスケード削除がどのように長いスタートを勝ち取ったかの物語