Realm의 계단식 삭제가 오랜 출시 기간 동안 어떻게 승리했는지에 대한 이야기

모든 사용자는 모바일 애플리케이션의 빠른 실행과 반응형 UI를 당연하게 여깁니다. 애플리케이션을 실행하는 데 오랜 시간이 걸리면 사용자는 슬프고 화를 내기 시작합니다. 고객 경험을 쉽게 망치거나 사용자가 애플리케이션 사용을 시작하기도 전에 사용자를 완전히 놓칠 수 있습니다.

우리는 Dodo Pizza 앱이 실행되는 데 평균 3초가 걸리고 일부 "운이 좋은 사람들"의 경우 15~20초가 걸리는 것을 발견했습니다.

컷 아래에는 행복한 결말이 있는 이야기가 있습니다. Realm 데이터베이스의 성장, 메모리 누수, 중첩된 객체를 축적한 후 함께 힘을 합쳐 모든 것을 고친 방법에 대한 이야기입니다.

문서의 작성자 : 막심 카친킨 — Dodo Pizza의 안드로이드 개발자.

애플리케이션 아이콘을 클릭한 후 첫 번째 활동의 onResume()까지 15초는 무한대입니다. 그리고 일부 사용자의 경우 시작 시간이 20-XNUMX초에 도달했습니다. 이것이 어떻게 가능합니까?

읽을 시간이 없는 분들을 위한 아주 짧은 요약
Realm 데이터베이스는 끝없이 성장했습니다. 일부 중첩된 개체는 삭제되지 않고 지속적으로 누적되었습니다. 애플리케이션 시작 시간이 점차 늘어났습니다. 그런 다음 문제를 해결했고 시작 시간이 목표에 도달했습니다. 1초 미만이 되었고 더 이상 증가하지 않았습니다. 이 기사에는 상황에 대한 분석과 빠른 솔루션과 일반적인 솔루션의 두 가지 솔루션이 포함되어 있습니다.

문제 검색 및 분석

오늘날 모든 모바일 애플리케이션은 빠르게 실행되고 반응성이 있어야 합니다. 하지만 이는 단지 모바일 앱만의 문제가 아닙니다. 서비스 및 회사와의 상호 작용에 대한 사용자 경험은 복잡한 것입니다. 예를 들어, 우리의 경우 배달 속도는 피자 서비스의 주요 지표 중 하나입니다. 배달이 빠르면 피자가 따끈따끈할 것이고, 지금 먹고 싶은 손님은 오래 기다리지 않아도 될 것이다. 애플리케이션의 경우 빠른 서비스 느낌을 만드는 것이 중요합니다. 애플리케이션을 실행하는 데 20초밖에 걸리지 않는다면 피자를 기다리는 데 얼마나 오래 걸리나요?

처음에 우리는 때때로 응용 프로그램을 시작하는 데 몇 초가 걸린다는 사실에 직면했고, 다른 동료들로부터 시간이 얼마나 걸리는지에 대한 불만을 듣기 시작했습니다. 하지만 우리는 이런 상황을 일관되게 반복할 수 없었습니다.

얼마나 걸리나요? 에 따르면 구글 문서, 애플리케이션의 콜드 스타트에 5초 미만이 소요되면 이는 "정상적인 것처럼" 간주됩니다. Dodo Pizza Android 앱 출시(Firebase 측정항목에 따름) _app_start) 에 콜드 스타트 평균 3초 안에 – 그들이 말하는 것처럼 “좋지도, 끔찍하지도 않습니다.”

그러나 응용 프로그램을 시작하는 데 매우 오랜 시간이 걸린다는 불만이 나타나기 시작했습니다! 우선, 우리는 "매우, 매우, 매우 길다"가 무엇인지 측정하기로 결정했습니다. 그리고 이를 위해 Firebase 추적을 사용했습니다. 앱 시작 추적.

이 표준 추적은 사용자가 애플리케이션을 여는 순간과 첫 번째 활동의 onResume()이 실행되는 순간 사이의 시간을 측정합니다. Firebase 콘솔에서는 이 측정항목을 _app_start라고 합니다. 그것은 밝혀졌다:

• 중앙 콜드 시작 시간이 95초 미만임에도 불구하고 20번째 백분위수를 초과하는 사용자의 시작 시간은 거의 5초(일부는 더 길다)입니다.
• 시작 시간은 일정한 값이 아니지만 시간이 지남에 따라 증가합니다. 그러나 때로는 방울이 있습니다. 분석 규모를 90일로 늘렸을 때 이러한 패턴을 발견했습니다.

두 가지 생각이 떠올랐습니다.

1. 뭔가가 새고 있어요.
2. 이 "무언가"는 릴리스 후 재설정된 다음 다시 누출됩니다.

“아마도 데이터베이스에 문제가 있는 것 같아요.” 우리는 생각했고, 우리가 옳았습니다. 첫째, 데이터베이스를 캐시로 사용하고 마이그레이션 중에 데이터베이스를 지웁니다. 둘째, 애플리케이션이 시작될 때 데이터베이스가 로드됩니다. 모든 것이 잘 어울립니다.

Realm 데이터베이스에 어떤 문제가 있나요?

우리는 첫 번째 설치부터 활성 사용 중에 애플리케이션 수명 동안 데이터베이스 내용이 어떻게 변경되는지 확인하기 시작했습니다. 다음을 통해 Realm 데이터베이스의 내용을 볼 수 있습니다. 스테토 또는 다음을 통해 파일을 열면 더 자세하고 명확하게 알 수 있습니다. 렐름 스튜디오. ADB를 통해 데이터베이스의 내용을 보려면 Realm 데이터베이스 파일을 복사하세요.

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

여러 번 데이터베이스의 내용을 살펴본 결과 특정 유형의 개체 수가 지속적으로 증가하고 있음을 발견했습니다.

그림은 두 파일에 대한 Realm Studio의 일부를 보여줍니다. 왼쪽은 설치 후 일정 시간이 지난 애플리케이션 기반, 오른쪽은 활성 사용 후입니다. 객체의 개수를 알 수 있습니다. ImageEntity и MoneyType 크게 증가했습니다(스크린샷은 각 유형의 개체 수를 보여줍니다).

데이터베이스 증가와 시작 시간의 관계

통제되지 않은 데이터베이스 증가는 매우 나쁩니다. 그러나 이것이 애플리케이션 시작 시간에 어떤 영향을 미칩니까? ActivityManager를 통해 이를 측정하는 것은 매우 쉽습니다. Android 4.4부터 logcat은 Displayed 문자열과 시간을 사용하여 로그를 표시합니다. 이 시간은 애플리케이션이 시작된 순간부터 활동 렌더링이 끝날 때까지의 간격과 같습니다. 이 시간 동안 다음과 같은 이벤트가 발생합니다.

• 프로세스를 시작하십시오.
• 객체 초기화.
• 활동 생성 및 초기화.
• 레이아웃을 생성합니다.
• 애플리케이션 렌더링.

우리에게 적합합니다. -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로 증가한 데이터베이스의 크기와 증가 사이에도 동일한 관계가 있었습니다. 전체적으로 시간이 지남에 따라(콜드 스타트의 증가와 함께) 애플리케이션 시작 시간과 데이터베이스 크기가 모두 증가한 것으로 나타났습니다. 우리 손에는 가설이 있습니다. 이제 남은 것은 의존성을 확인하는 것뿐이었습니다. 따라서 우리는 "누출"을 제거하고 이것이 출시 속도를 높일 수 있는지 확인하기로 결정했습니다.

데이터베이스가 끊임없이 증가하는 이유

"누수"를 제거하기 전에, 그것이 처음에 나타난 이유를 이해하는 것이 좋습니다. 이를 위해 Realm이 무엇인지 기억해 봅시다.

Realm은 비관계형 데이터베이스입니다. Android의 ORM 관계형 데이터베이스 수를 설명하는 것과 유사한 방식으로 개체 간의 관계를 설명할 수 있습니다. 동시에 Realm은 최소한의 변환과 매핑으로 객체를 메모리에 직접 저장합니다. 이를 통해 디스크에서 데이터를 매우 빠르게 읽을 수 있으며 이것이 Realm의 강점이자 사랑받는 이유입니다.

(이 글의 목적상 이 설명만으로도 충분합니다. Realm에 대한 자세한 내용은 다음 링크에서 확인하실 수 있습니다. 선적 서류 비치 아니면 그들의 아카데미).

많은 개발자는 관계형 데이터베이스(예: 내부적으로 SQL이 포함된 ORM 데이터베이스)를 사용하여 더 많은 작업을 수행하는 데 익숙합니다. 그리고 계단식 데이터 삭제와 같은 일이 종종 주어진 것처럼 보입니다. 하지만 Realm에서는 그렇지 않습니다.

그런데 캐스케이드 삭제 기능은 오랫동안 요청이 많았습니다. 이것 개정 и 또 다른에 관한 내용이 활발히 논의되었습니다. 곧 끝날 것 같은 느낌이 들었습니다. 그러나 모든 것이 강한 링크와 약한 링크의 도입으로 해석되어 이 문제도 자동으로 해결됩니다. 이 작업에 매우 활기차고 적극적이었습니다. 풀 리퀘스트, 내부적인 문제로 인해 잠시 중단되었습니다.

계단식 삭제 없이 데이터 유출

존재하지 않는 계단식 삭제에 의존하는 경우 데이터가 정확히 어떻게 유출되나요? 중첩된 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). 나열된 모든 필드는 Realm 객체입니다. 동일한 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 객체가 없다고 가정하므로 다른 중첩 루프와 삭제가 없습니다.

"빠른" 솔루션

우리가 가장 먼저 결정한 일은 가장 빠르게 성장하는 개체를 정리하고 결과를 확인하여 이것이 원래 문제를 해결할 수 있는지 확인하는 것이었습니다. 첫째, 가장 간단하고 직관적인 해결책이 만들어졌습니다. 즉, 각 객체는 자신의 자식을 제거해야 합니다. 이를 위해 우리는 중첩된 Realm 객체 목록을 반환하는 인터페이스를 도입했습니다.

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

그리고 이를 Realm 객체에 구현했습니다:

@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의 데이터 캐싱을 매우 적극적으로 사용합니다. 따라서 각 개체에 대해 중첩된 개체를 모두 작성하는 것은 노동 집약적이며, 코드를 변경할 때 개체 지정을 잊어버릴 수 있기 때문에 오류 위험도 증가합니다.

인터페이스를 사용하지 않고 모든 것이 자체적으로 작동하는지 확인하고 싶었습니다.

무언가가 스스로 작동하기를 원한다면 리플렉션을 사용해야 합니다. 이를 위해 각 클래스 필드를 살펴보고 그것이 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 Realm 객체만 필터링하고 전달합니다. 방법 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 새 객체를 작성하기 전에 수집된 모든 객체를 반복적으로 삭제합니다. 결국 우리는 애플리케이션 전체에서 이 접근 방식을 사용하게 됩니다. Realm의 메모리 누수는 완전히 사라졌습니다. 애플리케이션의 콜드 스타트 ​​횟수에 대한 시작 시간의 의존성을 동일한 측정을 통해 결과를 확인했습니다.

녹색 선은 중첩된 객체의 자동 계단식 삭제 중 콜드 스타트 ​​횟수에 대한 애플리케이션 시작 시간의 의존성을 보여줍니다.

결과 및 결론

계속해서 증가하는 Realm 데이터베이스로 인해 애플리케이션 실행 속도가 매우 느려졌습니다. 중첩된 개체에 대한 자체적인 "계단식 삭제" 기능이 포함된 업데이트를 출시했습니다. 이제 _app_start 측정항목을 통해 우리의 결정이 애플리케이션 시작 시간에 어떤 영향을 미쳤는지 모니터링하고 평가합니다.

분석을 위해 90일의 기간을 사용하여 중앙값과 사용자의 95번째 백분위수에 해당하는 애플리케이션 시작 시간이 감소하기 시작했고 더 이상 증가하지 않는 것을 확인했습니다.

1일 차트를 보면 _app_start 측정항목이 완전히 적절해 보이고 XNUMX초 미만입니다.

또한 _app_start의 중앙값이 5초를 초과하면 기본적으로 Firebase가 알림을 보낸다는 점도 추가할 가치가 있습니다. 그러나 우리가 볼 수 있듯이 이것에 의존해서는 안 되며, 들어가서 명시적으로 확인해야 합니다.

Realm 데이터베이스의 특별한 점은 비관계형 데이터베이스라는 것입니다. 사용 편의성, ORM 솔루션 및 객체 연결과의 유사성에도 불구하고 계단식 삭제 기능이 없습니다.

이를 고려하지 않으면 중첩된 개체가 누적되어 "누출"됩니다. 데이터베이스는 지속적으로 증가하므로 애플리케이션의 속도 저하나 시작에 영향을 미칩니다.

Realm에서 객체를 빠르게 삭제하는 방법에 대한 경험을 공유했습니다. 이 방법은 아직 기본적으로 제공되지는 않지만 오랫동안 이야기되어 왔습니다. говорят и говорят. 우리의 경우 이로 인해 애플리케이션 시작 시간이 크게 단축되었습니다.

이 기능의 임박한 등장에 대한 논의에도 불구하고 Realm에서는 계단식 삭제 기능이 없도록 설계되었습니다. 새로운 애플리케이션을 디자인하는 경우 이 점을 고려하십시오. 그리고 이미 Realm을 사용하고 계시다면 이런 문제가 있는지 확인해 보세요.

출처 : habr.com