Mae pob defnyddiwr yn cymryd lansiad cyflym ac UI ymatebol mewn cymwysiadau symudol yn ganiataol. Os bydd y cais yn cymryd amser hir i'w lansio, mae'r defnyddiwr yn dechrau teimlo'n drist ac yn ddig. Gallwch chi ddifetha profiad y cwsmer yn hawdd neu golli'r defnyddiwr yn llwyr hyd yn oed cyn iddo ddechrau defnyddio'r rhaglen.
Fe wnaethon ni ddarganfod unwaith bod yr app Dodo Pizza yn cymryd 3 eiliad i'w lansio ar gyfartaledd, ac i rai “rhai lwcus” mae'n cymryd 15-20 eiliad.
O dan y toriad mae stori gyda diweddglo hapus: am dwf cronfa ddata Realm, gollyngiad cof, sut y gwnaethom gronni gwrthrychau nythu, ac yna tynnu ein hunain at ein gilydd a gosod popeth.
Awdur yr erthygl: - Datblygwr Android yn Dodo Pizza.
Mae tair eiliad o glicio ar eicon y cymhwysiad i ailddechrau () o'r gweithgaredd cyntaf yn anfeidredd. Ac i rai defnyddwyr, cyrhaeddodd yr amser cychwyn 15-20 eiliad. Sut mae hyn hyd yn oed yn bosibl?
Crynodeb byr iawn ar gyfer y rhai nad oes ganddynt amser i ddarllen
Tyfodd ein cronfa ddata Realm yn ddiddiwedd. Ni chafodd rhai gwrthrychau nythu eu dileu, ond roeddent yn cronni'n gyson. Cynyddodd amser cychwyn y cais yn raddol. Yna fe wnaethom ei drwsio, a daeth yr amser cychwyn i'r targed - daeth yn llai nag 1 eiliad ac ni chynyddodd mwyach. Mae'r erthygl yn cynnwys dadansoddiad o'r sefyllfa a dau ateb - un cyflym ac un arferol.
Chwilio a dadansoddi'r broblem
Heddiw, rhaid i unrhyw raglen symudol lansio'n gyflym a bod yn ymatebol. Ond nid yw'n ymwneud â'r app symudol yn unig. Mae profiad defnyddiwr o ryngweithio â gwasanaeth a chwmni yn beth cymhleth. Er enghraifft, yn ein hachos ni, cyflymder dosbarthu yw un o'r dangosyddion allweddol ar gyfer gwasanaeth pizza. Os yw'r cyflenwad yn gyflym, bydd y pizza yn boeth, ac ni fydd yn rhaid i'r cwsmer sydd am fwyta nawr aros yn hir. Ar gyfer y cais, yn ei dro, mae'n bwysig creu'r teimlad o wasanaeth cyflym, oherwydd os mai dim ond 20 eiliad y mae'r cais yn ei gymryd i'w lansio, yna pa mor hir y bydd yn rhaid i chi aros am y pizza?
Ar y dechrau, roeddem ni ein hunain yn wynebu'r ffaith bod y cais weithiau'n cymryd ychydig eiliadau i'w lansio, ac yna fe ddechreuon ni glywed cwynion gan gydweithwyr eraill am faint o amser a gymerodd. Ond nid oeddem yn gallu ailadrodd y sefyllfa hon yn gyson.
Pa mor hir yw hi? Yn ôl , os bydd dechrau oer cais yn cymryd llai na 5 eiliad, yna ystyrir hyn “fel pe bai’n arferol”. Lansio app Android Dodo Pizza (yn ôl metrigau Firebase ) yn ar gyfartaledd mewn 3 eiliad - “Ddim yn wych, ddim yn ofnadwy,” fel maen nhw'n dweud.
Ond yna dechreuodd cwynion ymddangos bod y cais wedi cymryd amser hir iawn, iawn, iawn i'w lansio! I ddechrau, fe benderfynon ni fesur beth yw “hir iawn, iawn, iawn”. A gwnaethom ddefnyddio Firebase trace ar gyfer hyn .
Mae'r olrhain safonol hwn yn mesur yr amser rhwng yr eiliad y mae'r defnyddiwr yn agor y rhaglen a'r eiliad y mae'r gweithgaredd cyntaf yn cael ei ailddechrau. Yn y Consol Firebase gelwir y metrig hwn yn _app_start. Daeth i'r amlwg:
- Mae amseroedd cychwyn defnyddwyr uwchlaw'r 95fed canradd bron i 20 eiliad (rhai hyd yn oed yn hirach), er bod yr amser cychwyn oer canolrif yn llai na 5 eiliad.
- Nid yw'r amser cychwyn yn werth cyson, ond mae'n tyfu dros amser. Ond weithiau mae yna ddiferion. Gwelsom y patrwm hwn pan gynyddwyd y raddfa ddadansoddi i 90 diwrnod.
Daeth dau feddwl i’r meddwl:
- Mae rhywbeth yn gollwng.
- Mae'r "rhywbeth" hwn yn cael ei ailosod ar ôl ei ryddhau ac yna'n gollwng eto.
“Mae'n debyg rhywbeth gyda'r gronfa ddata,” meddylion ni, ac roedden ni'n iawn. Yn gyntaf, rydym yn defnyddio'r gronfa ddata fel storfa; yn ystod mudo rydym yn ei glirio. Yn ail, mae'r gronfa ddata yn cael ei llwytho pan fydd y cais yn dechrau. Mae popeth yn cyd-fynd.
Beth sy'n bod ar gronfa ddata Realm
Dechreuon ni wirio sut mae cynnwys y gronfa ddata yn newid dros oes y rhaglen, o'r gosodiad cyntaf ac ymhellach yn ystod defnydd gweithredol. Gallwch weld cynnwys cronfa ddata Realm trwy neu yn fanylach ac yn glir trwy agor y ffeil trwy . I weld cynnwys y gronfa ddata trwy ADB, copïwch ffeil cronfa ddata Realm:
adb exec-out run-as ${PACKAGE_NAME} cat files/${DB_NAME}Ar ôl edrych ar gynnwys y gronfa ddata ar wahanol adegau, fe wnaethom ddarganfod bod nifer y gwrthrychau o fath penodol yn cynyddu'n gyson.
Mae'r llun yn dangos darn o Realm Studio ar gyfer dwy ffeil: ar y chwith - sylfaen y cais beth amser ar ôl ei osod, ar y dde - ar ôl ei ddefnyddio'n weithredol. Gellir gweld bod nifer y gwrthrychau ImageEntity и MoneyType wedi tyfu'n sylweddol (mae'r sgrin yn dangos nifer y gwrthrychau o bob math).
Y berthynas rhwng twf cronfa ddata ac amser cychwyn
Mae twf cronfa ddata heb ei reoli yn ddrwg iawn. Ond sut mae hyn yn effeithio ar amser cychwyn y cais? Mae'n eithaf hawdd mesur hyn trwy'r ActivityManager. Ers Android 4.4, mae logcat yn arddangos y log gyda'r llinyn Arddangos a'r amser. Mae'r amser hwn yn hafal i'r egwyl o'r eiliad y caiff y cais ei lansio tan ddiwedd y rendro gweithgaredd. Yn ystod y cyfnod hwn, mae'r digwyddiadau canlynol yn digwydd:
- Dechreuwch y broses.
- Cychwyn gwrthrychau.
- Creu a chychwyn gweithgareddau.
- Creu cynllun.
- Rendro cais.
Yn addas i ni. Os ydych chi'n rhedeg ADB gyda'r baneri -S a -W, gallwch gael allbwn estynedig gyda'r amser cychwyn:
adb shell am start -S -W ru.dodopizza.app/.MainActivity -c android.intent.category.LAUNCHER -a android.intent.action.MAIN
Os ydych chi'n ei fachu oddi yno grep -i WaitTime amser, gallwch awtomeiddio'r casgliad o'r metrig hwn ac edrych yn weledol ar y canlyniadau. Mae'r graff isod yn dangos dibyniaeth amser cychwyn y cais ar y nifer o ddechreuadau oer y cais.
Ar yr un pryd, roedd yr un natur o'r berthynas rhwng maint a thwf y gronfa ddata, a dyfodd o 4 MB i 15 MB. Yn gyfan gwbl, dros amser (gyda thwf cychwyniadau oer), cynyddodd amser lansio'r cais a maint y gronfa ddata. Mae gennym ni ddamcaniaeth ar ein dwylo. Nawr y cyfan oedd ar ôl oedd cadarnhau'r ddibyniaeth. Felly, fe benderfynon ni gael gwared ar y “gollyngiadau” a gweld a fyddai hyn yn cyflymu'r lansiad.
Rhesymau dros dwf cronfa ddata diddiwedd
Cyn cael gwared ar “gollyngiadau”, mae'n werth deall pam eu bod yn ymddangos yn y lle cyntaf. I wneud hyn, gadewch i ni gofio beth yw Realm.
Mae Realm yn gronfa ddata nad yw'n perthyn. Mae'n caniatáu ichi ddisgrifio perthnasoedd rhwng gwrthrychau mewn ffordd debyg i faint o gronfeydd data perthynol ORM ar Android sy'n cael eu disgrifio. Ar yr un pryd, mae Realm yn storio gwrthrychau yn uniongyrchol yn y cof gyda'r nifer lleiaf o drawsnewidiadau a mapiadau. Mae hyn yn caniatáu ichi ddarllen data o'r ddisg yn gyflym iawn, sef cryfder Realm a pham ei fod yn cael ei garu.
(At ddibenion yr erthygl hon, bydd y disgrifiad hwn yn ddigon i ni. Gallwch ddarllen mwy am Realm yn y cŵl neu yn eu ).
Mae llawer o ddatblygwyr yn gyfarwydd â gweithio mwy gyda chronfeydd data perthynol (er enghraifft, cronfeydd data ORM gyda SQL o dan y cwfl). Ac mae pethau fel rhaeadru dileu data yn aml yn ymddangos fel rhywbeth a roddir. Ond nid yn y Deyrnas.
Gyda llaw, gofynnwyd am y nodwedd dileu rhaeadru ers amser maith. hwn и , yn gysylltiedig ag ef, yn cael ei drafod yn weithredol. Roedd teimlad y byddai'n cael ei wneud yn fuan. Ond yna cyfieithodd popeth i gyflwyno cysylltiadau cryf a gwan, a fyddai hefyd yn datrys y broblem hon yn awtomatig. Roedd yn eithaf bywiog a gweithgar ar y dasg hon , sydd wedi cael ei seibio am y tro oherwydd anawsterau mewnol.
Data yn gollwng heb ddileu rhaeadru
Sut yn union mae data yn gollwng os ydych yn dibynnu ar ddileu rhaeadru nad yw'n bodoli? Os ydych wedi nythu gwrthrychau Tir, yna rhaid eu dileu.
Gadewch i ni edrych ar enghraifft (bron) go iawn. Mae gennym wrthrych 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()
Mae gan y cynnyrch yn y cart wahanol feysydd, gan gynnwys llun ImageEntity, cynhwysion wedi'u haddasu CustomizationEntity. Hefyd, gall y cynnyrch yn y cart fod yn combo gyda'i set ei hun o gynhyrchion RealmList (CartProductEntity). Mae pob maes a restrir yn wrthrychau Tir. Os byddwn yn mewnosod gwrthrych newydd (copyToRealm() / copyToRealmOrUpdate()) gyda'r un id, yna bydd y gwrthrych hwn yn cael ei drosysgrifo'n llwyr. Ond bydd yr holl wrthrychau mewnol (delwedd, customizationEntity a cartComboProducts) yn colli cysylltiad â'r rhiant ac yn aros yn y gronfa ddata.
Gan fod y cysylltiad â nhw yn cael ei golli, nid ydym bellach yn eu darllen nac yn eu dileu (oni bai ein bod yn eu cyrchu'n benodol neu'n clirio'r “tabl cyfan”). Fe wnaethon ni alw hyn yn “gollyngiadau cof”.
Pan fyddwn yn gweithio gyda Realm, rhaid inni fynd trwy'r holl elfennau yn benodol a dileu popeth yn benodol cyn gweithrediadau o'r fath. Gellir gwneud hyn, er enghraifft, fel hyn:
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()
}
// и потом уже сохраняемOs gwnewch hyn, yna bydd popeth yn gweithio fel y dylai. Yn yr enghraifft hon, rydym yn cymryd yn ganiataol nad oes unrhyw wrthrychau Tir nythu eraill y tu mewn i ddelwedd, customizationEntity, a cartComboProducts, felly nid oes unrhyw ddolenni a dileadau nythu eraill.
Datrysiad "cyflym".
Y peth cyntaf i ni benderfynu ei wneud oedd glanhau'r gwrthrychau sy'n tyfu gyflymaf a gwirio'r canlyniadau i weld a fyddai hyn yn datrys ein problem wreiddiol. Yn gyntaf, gwnaed yr ateb symlaf a mwyaf greddfol, sef: dylai pob gwrthrych fod yn gyfrifol am dynnu ei blant. I wneud hyn, fe wnaethom gyflwyno rhyngwyneb a ddychwelodd restr o'i wrthrychau Tir nythu:
interface NestedEntityAware {
fun getNestedEntities(): Collection<RealmObject?>
}Ac fe wnaethon ni ei roi ar waith yn ein hamcanion Teyrnas:
@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 rydym yn dychwelyd pob plentyn fel rhestr fflat. A gall pob gwrthrych plentyn hefyd weithredu'r rhyngwyneb NestedEntityAware, gan nodi bod ganddo wrthrychau Realm mewnol i'w dileu, er enghraifft 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
)
}
}Ac yn y blaen, gellir ailadrodd nythu gwrthrychau.
Yna rydyn ni'n ysgrifennu dull sy'n dileu'r holl wrthrychau nythu yn rheolaidd. Dull (wedi'i wneud fel estyniad) deleteAllNestedEntities yn cael yr holl wrthrychau lefel uchaf a dull deleteNestedRecursively Yn cael gwared ar yr holl wrthrychau nythu yn rheolaidd gan ddefnyddio rhyngwyneb 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()
}
}
}Gwnaethom hyn gyda'r gwrthrychau sy'n tyfu gyflymaf a gwirio beth ddigwyddodd.
O ganlyniad, rhoddodd y gwrthrychau hynny y gwnaethom eu gorchuddio â'r ateb hwn y gorau i dyfu. Ac arafodd twf cyffredinol y sylfaen, ond ni ddaeth i ben.
Yr ateb "normal".
Er i'r sylfaen ddechrau tyfu'n arafach, roedd yn dal i dyfu. Felly dechreuon ni edrych ymhellach. Mae ein prosiect yn gwneud defnydd gweithredol iawn o storio data yn y Deyrnas. Felly, mae ysgrifennu'r holl wrthrychau nythu ar gyfer pob gwrthrych yn llafurddwys, ac mae'r risg o wallau yn cynyddu, oherwydd gallwch chi anghofio nodi gwrthrychau wrth newid y cod.
Roeddwn i eisiau gwneud yn siŵr nad oeddwn yn defnyddio rhyngwynebau, ond bod popeth yn gweithio ar ei ben ei hun.
Pan fyddwn ni eisiau i rywbeth weithio ar ei ben ei hun, mae'n rhaid i ni ddefnyddio myfyrio. I wneud hyn, gallwn fynd trwy faes pob dosbarth a gwirio a yw'n wrthrych Realm neu'n rhestr o wrthrychau:
RealmModel::class.java.isAssignableFrom(field.type)
RealmList::class.java.isAssignableFrom(field.type)Os yw'r maes yn Fodel Realm neu RealmList, yna ychwanegwch wrthrych y maes hwn at restr o wrthrychau nythu. Mae popeth yn union yr un fath ag y gwnaethom uchod, dim ond yma y caiff ei wneud ar ei ben ei hun. Mae'r dull dileu rhaeadru ei hun yn syml iawn ac mae'n edrych fel hyn:
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()
}
}
}
}
Estyniad filterRealmObject yn hidlo allan ac yn pasio gwrthrychau Teyrnas yn unig. Dull getNestedRealmObjects trwy fyfyrio, mae'n dod o hyd i holl wrthrychau'r Deyrnas nythu ac yn eu rhoi mewn rhestr linol. Yna rydyn ni'n gwneud yr un peth yn gyson. Wrth ddileu, mae angen i chi wirio'r gwrthrych am ddilysrwydd isValid, oherwydd efallai y gall gwrthrychau rhiant gwahanol fod wedi nythu rhai unfath. Mae'n well osgoi hyn a defnyddio awto-gynhyrchu id wrth greu gwrthrychau newydd.
Gweithredu'r dull getNestedRealmObjects yn llawn
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)
}
O ganlyniad, yn ein cod cleient rydym yn defnyddio “rhaeadru dileu” ar gyfer pob gweithrediad addasu data. Er enghraifft, ar gyfer gweithrediad mewnosod mae'n edrych fel hyn:
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 }
))
}
Dull yn gyntaf getManagedEntities yn derbyn pob gwrthrych ychwanegol, ac yna'r dull cascadeDelete Yn dileu'r holl wrthrychau a gasglwyd yn rheolaidd cyn ysgrifennu rhai newydd. Yn y pen draw, byddwn yn defnyddio'r dull hwn trwy gydol y cais. Mae gollyngiadau cof yn y Deyrnas wedi diflannu'n llwyr. Ar ôl gwneud yr un mesuriad o ddibyniaeth amser cychwyn ar nifer cychwyniadau oer y cais, gwelwn y canlyniad.
Mae'r llinell werdd yn dangos dibyniaeth amser cychwyn y cais ar nifer yr oerfel sy'n dechrau yn ystod dileu rhaeadru gwrthrychau nythu yn awtomatig.
Canlyniadau a chasgliadau
Roedd cronfa ddata Realm sy'n tyfu'n gyson yn achosi i'r cais lansio'n araf iawn. Fe wnaethom ryddhau diweddariad gyda'n "dileu rhaeadru" ein hunain o wrthrychau nythu. Ac yn awr rydym yn monitro ac yn gwerthuso sut yr effeithiodd ein penderfyniad ar amser cychwyn y cais trwy'r metrig _app_start.
Ar gyfer dadansoddiad, rydym yn cymryd cyfnod amser o 90 diwrnod ac yn gweld: dechreuodd amser lansio'r rhaglen, y canolrif a'r hyn sy'n disgyn ar y 95fed canradd o ddefnyddwyr, ostwng ac nid yw'n codi mwyach.
Os edrychwch ar y siart saith diwrnod, mae'r metrig _app_start yn edrych yn gwbl ddigonol ac mae'n llai nag 1 eiliad.
Mae'n werth ychwanegu hefyd, yn ddiofyn, bod Firebase yn anfon hysbysiadau os yw gwerth canolrifol _app_start yn fwy na 5 eiliad. Fodd bynnag, fel y gallwn weld, ni ddylech ddibynnu ar hyn, ond yn hytrach ewch i mewn a'i wirio'n benodol.
Y peth arbennig am gronfa ddata Realm yw ei bod yn gronfa ddata nad yw'n perthyn. Er gwaethaf ei hawdd i'w ddefnyddio, tebygrwydd i atebion ORM a chysylltu gwrthrychau, nid oes ganddo ddileu rhaeadru.
Os na chymerir hyn i ystyriaeth, yna bydd gwrthrychau nythu yn cronni ac yn “gollwng i ffwrdd.” Bydd y gronfa ddata yn tyfu'n gyson, a fydd yn ei dro yn effeithio ar arafu neu gychwyn y cais.
Rhannais ein profiad ar sut i wneud rhaeadru dileu gwrthrychau yn Realm yn gyflym, nad yw eto allan o'r bocs, ond y bu sôn amdano ers amser maith и . Yn ein hachos ni, cyflymodd hyn amser cychwyn y cais yn fawr.
Er gwaethaf y drafodaeth am ymddangosiad y nodwedd hon ar fin digwydd, mae absenoldeb dileu rhaeadru yn Realm yn cael ei wneud trwy ddyluniad. Os ydych yn dylunio cais newydd, yna cymerwch hyn i ystyriaeth. Ac os ydych chi eisoes yn defnyddio Realm, gwiriwch a oes gennych chi broblemau o'r fath.
Ffynhonnell: hab.com