ਇਸ ਕਹਾਣੀ ਦੀ ਕਹਾਣੀ ਕਿ ਕਿਵੇਂ ਰੀਅਲਮ ਵਿੱਚ ਕੈਸਕੇਡ ਡਿਲੀਟੇਸ਼ਨ ਇੱਕ ਲੰਬੇ ਲਾਂਚ ਉੱਤੇ ਜਿੱਤ ਗਈ

ਸਾਰੇ ਉਪਭੋਗਤਾ ਮੋਬਾਈਲ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਤੇਜ਼ ਲਾਂਚ ਅਤੇ ਜਵਾਬਦੇਹ UI ਨੂੰ ਸਵੀਕਾਰ ਕਰਦੇ ਹਨ। ਜੇਕਰ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਲਾਂਚ ਹੋਣ ਵਿੱਚ ਲੰਬਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ, ਤਾਂ ਉਪਭੋਗਤਾ ਉਦਾਸ ਅਤੇ ਗੁੱਸੇ ਮਹਿਸੂਸ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਹੈ। ਤੁਸੀਂ ਆਸਾਨੀ ਨਾਲ ਗਾਹਕ ਅਨੁਭਵ ਨੂੰ ਖਰਾਬ ਕਰ ਸਕਦੇ ਹੋ ਜਾਂ ਉਪਭੋਗਤਾ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਗੁਆ ਸਕਦੇ ਹੋ।

ਅਸੀਂ ਇੱਕ ਵਾਰ ਖੋਜ ਕੀਤੀ ਸੀ ਕਿ ਡੋਡੋ ਪੀਜ਼ਾ ਐਪ ਨੂੰ ਔਸਤਨ ਲਾਂਚ ਹੋਣ ਵਿੱਚ 3 ਸਕਿੰਟ ਲੱਗਦੇ ਹਨ, ਅਤੇ ਕੁਝ "ਖੁਸ਼ਕਿਸਮਤ ਲੋਕਾਂ" ਲਈ ਇਸ ਵਿੱਚ 15-20 ਸਕਿੰਟ ਲੱਗਦੇ ਹਨ।

ਕੱਟ ਦੇ ਹੇਠਾਂ ਇੱਕ ਖੁਸ਼ਹਾਲ ਅੰਤ ਵਾਲੀ ਕਹਾਣੀ ਹੈ: ਰੀਅਲਮ ਡੇਟਾਬੇਸ ਦੇ ਵਾਧੇ ਬਾਰੇ, ਇੱਕ ਮੈਮੋਰੀ ਲੀਕ, ਕਿਵੇਂ ਅਸੀਂ ਨੇਸਟਡ ਵਸਤੂਆਂ ਨੂੰ ਇਕੱਠਾ ਕੀਤਾ, ਅਤੇ ਫਿਰ ਆਪਣੇ ਆਪ ਨੂੰ ਇਕੱਠਾ ਕੀਤਾ ਅਤੇ ਸਭ ਕੁਝ ਠੀਕ ਕੀਤਾ।

ਲੇਖ ਲੇਖਕ: ਮੈਕਸਿਮ ਕਾਚਿਨਕਿਨ - ਡੋਡੋ ਪੀਜ਼ਾ ਵਿਖੇ ਐਂਡਰਾਇਡ ਡਿਵੈਲਪਰ।

ਐਪਲੀਕੇਸ਼ਨ ਆਈਕਨ 'ਤੇ ਕਲਿੱਕ ਕਰਨ ਤੋਂ ਲੈ ਕੇ ਪਹਿਲੀ ਗਤੀਵਿਧੀ ਦੇ onResume() ਤੱਕ ਤਿੰਨ ਸਕਿੰਟ ਅਨੰਤ ਹੈ। ਅਤੇ ਕੁਝ ਉਪਭੋਗਤਾਵਾਂ ਲਈ, ਸ਼ੁਰੂਆਤੀ ਸਮਾਂ 15-20 ਸਕਿੰਟਾਂ ਤੱਕ ਪਹੁੰਚ ਗਿਆ. ਇਹ ਵੀ ਕਿਵੇਂ ਸੰਭਵ ਹੈ?

ਉਹਨਾਂ ਲਈ ਇੱਕ ਬਹੁਤ ਹੀ ਛੋਟਾ ਸਾਰਾਂਸ਼ ਜਿਨ੍ਹਾਂ ਕੋਲ ਪੜ੍ਹਨ ਲਈ ਸਮਾਂ ਨਹੀਂ ਹੈ
ਸਾਡਾ ਰੀਅਲਮ ਡੇਟਾਬੇਸ ਬੇਅੰਤ ਵਧਿਆ. ਕੁਝ ਨੇਸਟਡ ਵਸਤੂਆਂ ਨੂੰ ਮਿਟਾਇਆ ਨਹੀਂ ਗਿਆ ਸੀ, ਪਰ ਲਗਾਤਾਰ ਇਕੱਠਾ ਕੀਤਾ ਗਿਆ ਸੀ। ਐਪਲੀਕੇਸ਼ਨ ਸ਼ੁਰੂ ਹੋਣ ਦਾ ਸਮਾਂ ਹੌਲੀ-ਹੌਲੀ ਵਧਦਾ ਗਿਆ। ਫਿਰ ਅਸੀਂ ਇਸਨੂੰ ਠੀਕ ਕੀਤਾ, ਅਤੇ ਸ਼ੁਰੂਆਤੀ ਸਮਾਂ ਟੀਚੇ 'ਤੇ ਆ ਗਿਆ - ਇਹ 1 ਸਕਿੰਟ ਤੋਂ ਘੱਟ ਹੋ ਗਿਆ ਅਤੇ ਹੁਣ ਵਧਿਆ ਨਹੀਂ ਗਿਆ. ਲੇਖ ਵਿੱਚ ਸਥਿਤੀ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਦੋ ਹੱਲ ਹਨ - ਇੱਕ ਤੇਜ਼ ਅਤੇ ਇੱਕ ਆਮ।

ਸਮੱਸਿਆ ਦੀ ਖੋਜ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ

ਅੱਜ, ਕਿਸੇ ਵੀ ਮੋਬਾਈਲ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਜਲਦੀ ਲਾਂਚ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਜਵਾਬਦੇਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਪਰ ਇਹ ਸਿਰਫ਼ ਮੋਬਾਈਲ ਐਪ ਬਾਰੇ ਨਹੀਂ ਹੈ। ਇੱਕ ਸੇਵਾ ਅਤੇ ਇੱਕ ਕੰਪਨੀ ਨਾਲ ਗੱਲਬਾਤ ਦਾ ਉਪਭੋਗਤਾ ਅਨੁਭਵ ਇੱਕ ਗੁੰਝਲਦਾਰ ਚੀਜ਼ ਹੈ. ਉਦਾਹਰਨ ਲਈ, ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਡਿਲੀਵਰੀ ਦੀ ਗਤੀ ਪੀਜ਼ਾ ਸੇਵਾ ਲਈ ਮੁੱਖ ਸੂਚਕਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ। ਜੇਕਰ ਡਿਲੀਵਰੀ ਤੇਜ਼ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਪੀਜ਼ਾ ਗਰਮ ਹੋ ਜਾਵੇਗਾ, ਅਤੇ ਜੋ ਗਾਹਕ ਹੁਣ ਖਾਣਾ ਚਾਹੁੰਦਾ ਹੈ, ਉਸ ਨੂੰ ਜ਼ਿਆਦਾ ਦੇਰ ਉਡੀਕ ਨਹੀਂ ਕਰਨੀ ਪਵੇਗੀ। ਐਪਲੀਕੇਸ਼ਨ ਲਈ, ਬਦਲੇ ਵਿੱਚ, ਤੇਜ਼ ਸੇਵਾ ਦੀ ਭਾਵਨਾ ਪੈਦਾ ਕਰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ ਜੇਕਰ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਲਾਂਚ ਕਰਨ ਵਿੱਚ ਸਿਰਫ 20 ਸਕਿੰਟ ਲੱਗਦੇ ਹਨ, ਤਾਂ ਤੁਹਾਨੂੰ ਪੀਜ਼ਾ ਲਈ ਕਿੰਨਾ ਸਮਾਂ ਉਡੀਕ ਕਰਨੀ ਪਵੇਗੀ?

ਪਹਿਲਾਂ, ਅਸੀਂ ਖੁਦ ਇਸ ਤੱਥ ਦਾ ਸਾਹਮਣਾ ਕਰ ਰਹੇ ਸੀ ਕਿ ਕਈ ਵਾਰ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਲਾਂਚ ਕਰਨ ਵਿੱਚ ਕੁਝ ਸਕਿੰਟ ਲੱਗ ਜਾਂਦੇ ਸਨ, ਅਤੇ ਫਿਰ ਅਸੀਂ ਦੂਜੇ ਸਾਥੀਆਂ ਦੀਆਂ ਸ਼ਿਕਾਇਤਾਂ ਸੁਣਨੀਆਂ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀਆਂ ਕਿ ਇਸ ਵਿੱਚ ਕਿੰਨਾ ਸਮਾਂ ਲੱਗਾ। ਪਰ ਅਸੀਂ ਇਸ ਸਥਿਤੀ ਨੂੰ ਲਗਾਤਾਰ ਦੁਹਰਾਉਣ ਵਿੱਚ ਅਸਮਰੱਥ ਰਹੇ।

ਇਹ ਕਿੰਨਾ ਚਿਰ ਹੈ? ਇਸਦੇ ਅਨੁਸਾਰ ਗੂਗਲ ਦਸਤਾਵੇਜ਼, ਜੇਕਰ ਕਿਸੇ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਠੰਡੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ 5 ਸਕਿੰਟਾਂ ਤੋਂ ਘੱਟ ਸਮਾਂ ਲੱਗਦਾ ਹੈ, ਤਾਂ ਇਸ ਨੂੰ "ਆਮ ਵਾਂਗ" ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਡੋਡੋ ਪੀਜ਼ਾ ਐਂਡਰਾਇਡ ਐਪ ਲਾਂਚ ਕੀਤੀ ਗਈ (ਫਾਇਰਬੇਸ ਮੈਟ੍ਰਿਕਸ ਦੇ ਅਨੁਸਾਰ _ਐਪ_ਸਟਾਰਟ) 'ਤੇ ਠੰਡੀ ਸ਼ੁਰੂਆਤ ਔਸਤਨ 3 ਸਕਿੰਟਾਂ ਵਿੱਚ - "ਮਹਾਨ ਨਹੀਂ, ਭਿਆਨਕ ਨਹੀਂ," ਜਿਵੇਂ ਕਿ ਉਹ ਕਹਿੰਦੇ ਹਨ।

ਪਰ ਫਿਰ ਸ਼ਿਕਾਇਤਾਂ ਆਉਣੀਆਂ ਸ਼ੁਰੂ ਹੋ ਗਈਆਂ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਲਾਂਚ ਕਰਨ ਲਈ ਬਹੁਤ, ਬਹੁਤ, ਬਹੁਤ ਲੰਬਾ ਸਮਾਂ ਲੱਗ ਗਿਆ! ਸ਼ੁਰੂ ਕਰਨ ਲਈ, ਅਸੀਂ ਇਹ ਮਾਪਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਕਿ "ਬਹੁਤ, ਬਹੁਤ, ਬਹੁਤ ਲੰਮਾ" ਕੀ ਹੈ। ਅਤੇ ਅਸੀਂ ਇਸਦੇ ਲਈ ਫਾਇਰਬੇਸ ਟਰੇਸ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਐਪ ਸਟਾਰਟ ਟਰੇਸ.

ਇਹ ਸਟੈਂਡਰਡ ਟਰੇਸ ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਖੋਲ੍ਹਣ ਦੇ ਪਲ ਅਤੇ ਪਹਿਲੀ ਗਤੀਵਿਧੀ ਦੇ onResume() ਦੇ ਲਾਗੂ ਹੋਣ ਦੇ ਸਮੇਂ ਦੇ ਵਿਚਕਾਰ ਦੇ ਸਮੇਂ ਨੂੰ ਮਾਪਦਾ ਹੈ। ਫਾਇਰਬੇਸ ਕੰਸੋਲ ਵਿੱਚ ਇਸ ਮੈਟ੍ਰਿਕ ਨੂੰ _app_start ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ:

• 95ਵੇਂ ਪਰਸੈਂਟਾਈਲ ਤੋਂ ਉੱਪਰ ਵਾਲੇ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਸ਼ੁਰੂਆਤੀ ਸਮਾਂ ਲਗਭਗ 20 ਸਕਿੰਟ (ਕੁਝ ਜ਼ਿਆਦਾ ਲੰਬਾ) ਹੈ, ਭਾਵੇਂ ਕਿ ਮੱਧਮ ਕੋਲਡ ਸਟਾਰਟਅੱਪ ਸਮਾਂ 5 ਸਕਿੰਟਾਂ ਤੋਂ ਘੱਟ ਹੈ।
• ਸ਼ੁਰੂਆਤੀ ਸਮਾਂ ਇੱਕ ਸਥਿਰ ਮੁੱਲ ਨਹੀਂ ਹੈ, ਪਰ ਸਮੇਂ ਦੇ ਨਾਲ ਵਧਦਾ ਹੈ। ਪਰ ਕਈ ਵਾਰ ਬੂੰਦਾਂ ਵੀ ਹੁੰਦੀਆਂ ਹਨ। ਸਾਨੂੰ ਇਹ ਪੈਟਰਨ ਉਦੋਂ ਮਿਲਿਆ ਜਦੋਂ ਅਸੀਂ ਵਿਸ਼ਲੇਸ਼ਣ ਦੇ ਪੈਮਾਨੇ ਨੂੰ 90 ਦਿਨਾਂ ਤੱਕ ਵਧਾ ਦਿੱਤਾ।

ਮਨ ਵਿੱਚ ਦੋ ਵਿਚਾਰ ਆਏ:

1. ਕੁਝ ਲੀਕ ਹੋ ਰਿਹਾ ਹੈ।
2. ਇਹ "ਕੁਝ" ਰੀਲੀਜ਼ ਤੋਂ ਬਾਅਦ ਰੀਸੈਟ ਹੁੰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਦੁਬਾਰਾ ਲੀਕ ਹੁੰਦਾ ਹੈ।

"ਸ਼ਾਇਦ ਡਾਟਾਬੇਸ ਦੇ ਨਾਲ ਕੁਝ," ਅਸੀਂ ਸੋਚਿਆ, ਅਤੇ ਅਸੀਂ ਸਹੀ ਸੀ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਅਸੀਂ ਡੇਟਾਬੇਸ ਨੂੰ ਕੈਸ਼ ਵਜੋਂ ਵਰਤਦੇ ਹਾਂ; ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੌਰਾਨ ਅਸੀਂ ਇਸਨੂੰ ਸਾਫ਼ ਕਰਦੇ ਹਾਂ। ਦੂਜਾ, ਐਪਲੀਕੇਸ਼ਨ ਸ਼ੁਰੂ ਹੋਣ 'ਤੇ ਡਾਟਾਬੇਸ ਲੋਡ ਹੁੰਦਾ ਹੈ। ਸਭ ਕੁਝ ਇਕੱਠੇ ਫਿੱਟ ਬੈਠਦਾ ਹੈ.

ਰੀਅਲਮ ਡੇਟਾਬੇਸ ਵਿੱਚ ਕੀ ਗਲਤ ਹੈ

ਅਸੀਂ ਇਹ ਦੇਖਣਾ ਸ਼ੁਰੂ ਕੀਤਾ ਕਿ ਕਿਵੇਂ ਡੇਟਾਬੇਸ ਦੀਆਂ ਸਮੱਗਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਜੀਵਨ ਵਿੱਚ ਬਦਲਦੀਆਂ ਹਨ, ਪਹਿਲੀ ਸਥਾਪਨਾ ਤੋਂ ਅਤੇ ਅੱਗੇ ਸਰਗਰਮ ਵਰਤੋਂ ਦੌਰਾਨ। ਤੁਸੀਂ ਦੁਆਰਾ ਰੀਅਲਮ ਡੇਟਾਬੇਸ ਦੀਆਂ ਸਮੱਗਰੀਆਂ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹੋ ਸਟੈਥੋ ਜਾਂ ਹੋਰ ਵਿਸਥਾਰ ਵਿੱਚ ਅਤੇ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਫਾਈਲ ਖੋਲ੍ਹ ਕੇ ਰੀਅਲਮ ਸਟੂਡੀਓ. ADB ਦੁਆਰਾ ਡੇਟਾਬੇਸ ਦੀਆਂ ਸਮੱਗਰੀਆਂ ਨੂੰ ਵੇਖਣ ਲਈ, Realm ਡੇਟਾਬੇਸ ਫਾਈਲ ਦੀ ਨਕਲ ਕਰੋ:

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

ਵੱਖ-ਵੱਖ ਸਮਿਆਂ 'ਤੇ ਡਾਟਾਬੇਸ ਦੀ ਸਮੱਗਰੀ ਨੂੰ ਦੇਖਣ ਤੋਂ ਬਾਅਦ, ਸਾਨੂੰ ਪਤਾ ਲੱਗਾ ਕਿ ਕਿਸੇ ਖਾਸ ਕਿਸਮ ਦੀਆਂ ਵਸਤੂਆਂ ਦੀ ਗਿਣਤੀ ਲਗਾਤਾਰ ਵਧ ਰਹੀ ਹੈ।

ਤਸਵੀਰ ਦੋ ਫਾਈਲਾਂ ਲਈ ਰੀਅਲਮ ਸਟੂਡੀਓ ਦਾ ਇੱਕ ਟੁਕੜਾ ਦਿਖਾਉਂਦੀ ਹੈ: ਖੱਬੇ ਪਾਸੇ - ਐਪਲੀਕੇਸ਼ਨ ਬੇਸ ਇੰਸਟਾਲੇਸ਼ਨ ਤੋਂ ਕੁਝ ਸਮੇਂ ਬਾਅਦ, ਸੱਜੇ ਪਾਸੇ - ਸਰਗਰਮ ਵਰਤੋਂ ਤੋਂ ਬਾਅਦ। ਇਹ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿ ਆਬਜੈਕਟ ਦੀ ਗਿਣਤੀ ImageEntity и MoneyType ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਵਧਿਆ ਹੈ (ਸਕਰੀਨਸ਼ਾਟ ਹਰੇਕ ਕਿਸਮ ਦੀਆਂ ਵਸਤੂਆਂ ਦੀ ਸੰਖਿਆ ਦਿਖਾਉਂਦਾ ਹੈ)।

ਡਾਟਾਬੇਸ ਵਿਕਾਸ ਅਤੇ ਸ਼ੁਰੂਆਤੀ ਸਮੇਂ ਵਿਚਕਾਰ ਸਬੰਧ

ਬੇਕਾਬੂ ਡਾਟਾਬੇਸ ਵਾਧਾ ਬਹੁਤ ਮਾੜਾ ਹੈ। ਪਰ ਇਹ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਸ਼ੁਰੂਆਤੀ ਸਮੇਂ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਤ ਕਰਦਾ ਹੈ? ਐਕਟੀਵਿਟੀਮੈਨੇਜਰ ਦੁਆਰਾ ਇਸ ਨੂੰ ਮਾਪਣਾ ਕਾਫ਼ੀ ਆਸਾਨ ਹੈ। ਐਂਡਰਾਇਡ 4.4 ਤੋਂ, ਲੌਗਕੈਟ ਸਟ੍ਰਿੰਗ ਡਿਸਪਲੇਅ ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ ਲੌਗ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਇਹ ਸਮਾਂ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਲਾਂਚ ਹੋਣ ਤੋਂ ਲੈ ਕੇ ਸਰਗਰਮੀ ਰੈਂਡਰਿੰਗ ਦੇ ਅੰਤ ਤੱਕ ਅੰਤਰਾਲ ਦੇ ਬਰਾਬਰ ਹੈ। ਇਸ ਸਮੇਂ ਦੌਰਾਨ ਹੇਠ ਲਿਖੀਆਂ ਘਟਨਾਵਾਂ ਵਾਪਰਦੀਆਂ ਹਨ:

• ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕਰੋ।
• ਵਸਤੂਆਂ ਦੀ ਸ਼ੁਰੂਆਤ।
• ਗਤੀਵਿਧੀਆਂ ਦੀ ਸਿਰਜਣਾ ਅਤੇ ਸ਼ੁਰੂਆਤ.
• ਇੱਕ ਖਾਕਾ ਬਣਾਉਣਾ।
• ਐਪਲੀਕੇਸ਼ਨ ਰੈਂਡਰਿੰਗ।

ਸਾਡੇ ਲਈ ਅਨੁਕੂਲ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ -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 ਸਮਾਂ, ਤੁਸੀਂ ਇਸ ਮੈਟ੍ਰਿਕ ਦੇ ਸੰਗ੍ਰਹਿ ਨੂੰ ਸਵੈਚਲਿਤ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਨਤੀਜਿਆਂ ਨੂੰ ਦ੍ਰਿਸ਼ਟੀਗਤ ਰੂਪ ਵਿੱਚ ਦੇਖ ਸਕਦੇ ਹੋ। ਹੇਠਾਂ ਦਿੱਤਾ ਗ੍ਰਾਫ਼ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਸ਼ੁਰੂ ਹੋਣ ਦੀ ਗਿਣਤੀ 'ਤੇ ਐਪਲੀਕੇਸ਼ਨ ਸ਼ੁਰੂ ਹੋਣ ਦੇ ਸਮੇਂ ਦੀ ਨਿਰਭਰਤਾ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ।

ਉਸੇ ਸਮੇਂ, ਡੇਟਾਬੇਸ ਦੇ ਆਕਾਰ ਅਤੇ ਵਿਕਾਸ ਦੇ ਵਿਚਕਾਰ ਸਬੰਧਾਂ ਦਾ ਉਹੀ ਸੁਭਾਅ ਸੀ, ਜੋ ਕਿ 4 MB ਤੋਂ 15 MB ਤੱਕ ਵਧਿਆ. ਕੁੱਲ ਮਿਲਾ ਕੇ, ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਸਮੇਂ ਦੇ ਨਾਲ (ਕੋਲਡ ਸਟਾਰਟ ਦੇ ਵਾਧੇ ਦੇ ਨਾਲ), ਐਪਲੀਕੇਸ਼ਨ ਲਾਂਚ ਕਰਨ ਦਾ ਸਮਾਂ ਅਤੇ ਡੇਟਾਬੇਸ ਦਾ ਆਕਾਰ ਦੋਵੇਂ ਵਧ ਗਏ ਹਨ. ਸਾਡੇ ਹੱਥਾਂ 'ਤੇ ਇੱਕ ਅਨੁਮਾਨ ਹੈ. ਹੁਣ ਸਿਰਫ਼ ਨਿਰਭਰਤਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨਾ ਬਾਕੀ ਸੀ। ਇਸ ਲਈ, ਅਸੀਂ "ਲੀਕ" ਨੂੰ ਹਟਾਉਣ ਅਤੇ ਇਹ ਦੇਖਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਕਿ ਕੀ ਇਹ ਲਾਂਚ ਨੂੰ ਤੇਜ਼ ਕਰੇਗਾ।

ਬੇਅੰਤ ਡੇਟਾਬੇਸ ਵਾਧੇ ਦੇ ਕਾਰਨ

"ਲੀਕ" ਨੂੰ ਹਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਸਮਝਣ ਯੋਗ ਹੈ ਕਿ ਉਹ ਪਹਿਲੀ ਥਾਂ 'ਤੇ ਕਿਉਂ ਦਿਖਾਈ ਦਿੱਤੇ. ਅਜਿਹਾ ਕਰਨ ਲਈ, ਆਓ ਯਾਦ ਕਰੀਏ ਕਿ ਖੇਤਰ ਕੀ ਹੈ।

ਰੀਅਲਮ ਇੱਕ ਗੈਰ-ਸੰਬੰਧੀ ਡੇਟਾਬੇਸ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਆਬਜੈਕਟ ਵਿਚਕਾਰ ਸਬੰਧਾਂ ਦਾ ਵਰਣਨ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਐਂਡਰੌਇਡ 'ਤੇ ਕਿੰਨੇ ORM ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਦਾ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ। ਉਸੇ ਸਮੇਂ, ਰੀਅਲਮ ਆਬਜੈਕਟਸ ਨੂੰ ਸਿੱਧੇ ਮੈਮੋਰੀ ਵਿੱਚ ਸਟੋਰ ਕਰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਘੱਟ ਤੋਂ ਘੱਟ ਪਰਿਵਰਤਨ ਅਤੇ ਮੈਪਿੰਗ ਹੁੰਦੀ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਡਿਸਕ ਤੋਂ ਡੇਟਾ ਨੂੰ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਪੜ੍ਹਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਜੋ ਕਿ ਰੀਅਲਮ ਦੀ ਤਾਕਤ ਹੈ ਅਤੇ ਇਹ ਕਿਉਂ ਪਿਆਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

(ਇਸ ਲੇਖ ਦੇ ਉਦੇਸ਼ਾਂ ਲਈ, ਇਹ ਵੇਰਵਾ ਸਾਡੇ ਲਈ ਕਾਫੀ ਹੋਵੇਗਾ। ਤੁਸੀਂ ਕੂਲ ਵਿੱਚ ਰੀਅਲਮ ਬਾਰੇ ਹੋਰ ਪੜ੍ਹ ਸਕਦੇ ਹੋ ਦਸਤਾਵੇਜ਼ ਜਾਂ ਉਹਨਾਂ ਵਿੱਚ ਅਕੈਡਮੀ).

ਬਹੁਤ ਸਾਰੇ ਡਿਵੈਲਪਰ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ (ਉਦਾਹਰਨ ਲਈ, ਹੁੱਡ ਦੇ ਹੇਠਾਂ SQL ਦੇ ਨਾਲ ORM ਡੇਟਾਬੇਸ) ਨਾਲ ਵਧੇਰੇ ਕੰਮ ਕਰਨ ਦੇ ਆਦੀ ਹੁੰਦੇ ਹਨ। ਅਤੇ ਕੈਸਕੇਡਿੰਗ ਡੇਟਾ ਮਿਟਾਉਣ ਵਰਗੀਆਂ ਚੀਜ਼ਾਂ ਅਕਸਰ ਇੱਕ ਦਿੱਤੇ ਵਾਂਗ ਜਾਪਦੀਆਂ ਹਨ। ਪਰ ਖੇਤਰ ਵਿੱਚ ਨਹੀਂ।

ਵੈਸੇ, ਕੈਸਕੇਡ ਡਿਲੀਟ ਕਰਨ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਪੁੱਛਿਆ ਜਾ ਰਿਹਾ ਹੈ। ਇਹ ਸੰਸ਼ੋਧਨ и ਹੋਰ, ਇਸ ਨਾਲ ਜੁੜੇ, ਸਰਗਰਮੀ ਨਾਲ ਚਰਚਾ ਕੀਤੀ ਗਈ ਸੀ. ਇੱਕ ਅਹਿਸਾਸ ਸੀ ਕਿ ਇਹ ਜਲਦੀ ਹੀ ਹੋ ਜਾਵੇਗਾ. ਪਰ ਫਿਰ ਸਭ ਕੁਝ ਮਜ਼ਬੂਤ ​​​​ਅਤੇ ਕਮਜ਼ੋਰ ਲਿੰਕਾਂ ਦੀ ਜਾਣ-ਪਛਾਣ ਵਿੱਚ ਅਨੁਵਾਦ ਕੀਤਾ ਗਿਆ ਹੈ, ਜੋ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਆਪਣੇ ਆਪ ਹੱਲ ਕਰ ਦੇਵੇਗਾ. ਇਸ ਕੰਮ 'ਤੇ ਕਾਫੀ ਜ਼ਿੰਦਾਦਿਲ ਅਤੇ ਸਰਗਰਮ ਸੀ ਬੇਨਤੀ ਖਿੱਚੋਜਿਸ ਨੂੰ ਅੰਦਰੂਨੀ ਮੁਸ਼ਕਲਾਂ ਕਾਰਨ ਫਿਲਹਾਲ ਰੋਕ ਦਿੱਤਾ ਗਿਆ ਹੈ।

ਕੈਸਕੇਡਿੰਗ ਮਿਟਾਏ ਬਿਨਾਂ ਡਾਟਾ ਲੀਕ

ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਗੈਰ-ਮੌਜੂਦ ਕੈਸਕੇਡਿੰਗ ਡਿਲੀਟ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹੋ ਤਾਂ ਡੇਟਾ ਲੀਕ ਕਿਵੇਂ ਹੁੰਦਾ ਹੈ? ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਨੇਸਟਡ ਰੀਅਲਮ ਆਬਜੈਕਟ ਹਨ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਮਿਟਾਉਣਾ ਲਾਜ਼ਮੀ ਹੈ।
ਆਉ ਇੱਕ (ਲਗਭਗ) ਅਸਲੀ ਉਦਾਹਰਨ ਵੇਖੀਏ। ਸਾਡੇ ਕੋਲ ਇੱਕ ਵਸਤੂ ਹੈ 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()) ਪਾ ਦਿੰਦੇ ਹਾਂ, ਤਾਂ ਇਹ ਆਬਜੈਕਟ ਪੂਰੀ ਤਰ੍ਹਾਂ ਓਵਰਰਾਈਟ ਹੋ ਜਾਵੇਗਾ। ਪਰ ਸਾਰੀਆਂ ਅੰਦਰੂਨੀ ਵਸਤੂਆਂ (ਚਿੱਤਰ, ਕਸਟਮਾਈਜ਼ੇਸ਼ਨ ਏਂਟੀਟੀ ਅਤੇ ਕਾਰਟਕੌਂਬੋ ਉਤਪਾਦ) ਮਾਤਾ-ਪਿਤਾ ਨਾਲ ਸੰਪਰਕ ਗੁਆ ਦੇਣਗੇ ਅਤੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਰਹਿਣਗੇ।

ਕਿਉਂਕਿ ਉਹਨਾਂ ਨਾਲ ਕਨੈਕਸ਼ਨ ਖਤਮ ਹੋ ਗਿਆ ਹੈ, ਇਸ ਲਈ ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਪੜ੍ਹ ਨਹੀਂ ਸਕਦੇ ਜਾਂ ਉਹਨਾਂ ਨੂੰ ਮਿਟਾ ਨਹੀਂ ਸਕਦੇ (ਜਦੋਂ ਤੱਕ ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਐਕਸੈਸ ਨਹੀਂ ਕਰਦੇ ਜਾਂ ਪੂਰੀ “ਸਾਰਣੀ” ਨੂੰ ਸਾਫ਼ ਨਹੀਂ ਕਰਦੇ)। ਅਸੀਂ ਇਸਨੂੰ "ਮੈਮੋਰੀ ਲੀਕ" ਕਹਿੰਦੇ ਹਾਂ।

ਜਦੋਂ ਅਸੀਂ ਰੀਅਲਮ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਸਾਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਸਾਰੇ ਤੱਤਾਂ ਵਿੱਚੋਂ ਲੰਘਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਅਜਿਹੇ ਓਪਰੇਸ਼ਨਾਂ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਚੀਜ਼ ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਮਿਟਾਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਇਸ ਤਰ੍ਹਾਂ:

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()
}
// и потом уже сохраняем

ਜੇ ਤੁਸੀਂ ਅਜਿਹਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਸਭ ਕੁਝ ਉਸੇ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰੇਗਾ ਜਿਵੇਂ ਇਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ. ਇਸ ਉਦਾਹਰਨ ਵਿੱਚ, ਅਸੀਂ ਇਹ ਮੰਨਦੇ ਹਾਂ ਕਿ ਚਿੱਤਰ, ਕਸਟਮਾਈਜ਼ੇਸ਼ਨ ਐਂਟਿਟੀ, ਅਤੇ ਕਾਰਟਕੌਂਬੋ ਉਤਪਾਦ ਦੇ ਅੰਦਰ ਕੋਈ ਹੋਰ ਨੇਸਟਡ ਰੀਅਲਮ ਆਬਜੈਕਟ ਨਹੀਂ ਹਨ, ਇਸਲਈ ਕੋਈ ਹੋਰ ਨੇਸਟਡ ਲੂਪਸ ਅਤੇ ਡਿਲੀਟ ਨਹੀਂ ਹਨ।

"ਤੇਜ਼" ਹੱਲ

ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਜੋ ਅਸੀਂ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਉਹ ਸੀ ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਵਧਣ ਵਾਲੀਆਂ ਵਸਤੂਆਂ ਨੂੰ ਸਾਫ਼ ਕਰਨਾ ਅਤੇ ਇਹ ਦੇਖਣ ਲਈ ਨਤੀਜਿਆਂ ਦੀ ਜਾਂਚ ਕਰਨਾ ਕਿ ਕੀ ਇਹ ਸਾਡੀ ਮੂਲ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰੇਗਾ। ਪਹਿਲਾਂ, ਸਭ ਤੋਂ ਸਰਲ ਅਤੇ ਸਭ ਤੋਂ ਅਨੁਭਵੀ ਹੱਲ ਬਣਾਇਆ ਗਿਆ ਸੀ, ਅਰਥਾਤ: ਹਰੇਕ ਵਸਤੂ ਨੂੰ ਆਪਣੇ ਬੱਚਿਆਂ ਨੂੰ ਹਟਾਉਣ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ. ਅਜਿਹਾ ਕਰਨ ਲਈ, ਅਸੀਂ ਇੱਕ ਇੰਟਰਫੇਸ ਪੇਸ਼ ਕੀਤਾ ਜਿਸ ਨੇ ਇਸਦੇ ਨੇਸਟਡ ਰੀਅਲਮ ਆਬਜੈਕਟ ਦੀ ਸੂਚੀ ਵਾਪਸ ਕੀਤੀ:

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 ਇੰਟਰਫੇਸ ਨੂੰ ਵੀ ਲਾਗੂ ਕਰ ਸਕਦਾ ਹੈ, ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਇਸ ਵਿੱਚ ਮਿਟਾਉਣ ਲਈ ਅੰਦਰੂਨੀ ਖੇਤਰ ਆਬਜੈਕਟ ਹਨ, ਉਦਾਹਰਨ ਲਈ 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()
   }
 }
}

ਅਸੀਂ ਇਹ ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਵਧਣ ਵਾਲੀਆਂ ਵਸਤੂਆਂ ਨਾਲ ਕੀਤਾ ਅਤੇ ਜਾਂਚ ਕੀਤੀ ਕਿ ਕੀ ਹੋਇਆ ਹੈ।

ਨਤੀਜੇ ਵਜੋਂ, ਉਹ ਵਸਤੂਆਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਅਸੀਂ ਇਸ ਘੋਲ ਨਾਲ ਕਵਰ ਕੀਤਾ ਸੀ, ਵਧਣਾ ਬੰਦ ਹੋ ਗਿਆ। ਅਤੇ ਆਧਾਰ ਦਾ ਸਮੁੱਚਾ ਵਾਧਾ ਹੌਲੀ ਹੋ ਗਿਆ, ਪਰ ਰੁਕਿਆ ਨਹੀਂ.

"ਆਮ" ਹੱਲ

ਹਾਲਾਂਕਿ ਅਧਾਰ ਹੋਰ ਹੌਲੀ-ਹੌਲੀ ਵਧਣਾ ਸ਼ੁਰੂ ਹੋਇਆ, ਇਹ ਅਜੇ ਵੀ ਵਧਿਆ. ਇਸ ਲਈ ਅਸੀਂ ਹੋਰ ਦੇਖਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ। ਸਾਡਾ ਪ੍ਰੋਜੈਕਟ ਰੀਅਲਮ ਵਿੱਚ ਡੇਟਾ ਕੈਚਿੰਗ ਦੀ ਬਹੁਤ ਸਰਗਰਮ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਇਸ ਲਈ, ਹਰੇਕ ਆਬਜੈਕਟ ਲਈ ਸਾਰੀਆਂ ਨੇਸਟਡ ਵਸਤੂਆਂ ਨੂੰ ਲਿਖਣਾ ਲੇਬਰ-ਇੰਟੈਂਸਿਵ ਹੈ, ਨਾਲ ਹੀ ਗਲਤੀਆਂ ਦਾ ਖਤਰਾ ਵੱਧ ਜਾਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਤੁਸੀਂ ਕੋਡ ਬਦਲਦੇ ਸਮੇਂ ਵਸਤੂਆਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨਾ ਭੁੱਲ ਸਕਦੇ ਹੋ।

ਮੈਂ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਚਾਹੁੰਦਾ ਸੀ ਕਿ ਮੈਂ ਇੰਟਰਫੇਸ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ, ਪਰ ਇਹ ਸਭ ਕੁਝ ਆਪਣੇ ਆਪ ਕੰਮ ਕਰਦਾ ਹੈ।

ਜਦੋਂ ਅਸੀਂ ਕੁਝ ਆਪਣੇ ਆਪ ਕੰਮ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਤਾਂ ਸਾਨੂੰ ਪ੍ਰਤੀਬਿੰਬ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਪੈਂਦੀ ਹੈ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ਅਸੀਂ ਹਰੇਕ ਕਲਾਸ ਫੀਲਡ ਵਿੱਚ ਜਾ ਸਕਦੇ ਹਾਂ ਅਤੇ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹਾਂ ਕਿ ਇਹ ਇੱਕ ਰੀਅਲਮ ਆਬਜੈਕਟ ਹੈ ਜਾਂ ਆਬਜੈਕਟ ਦੀ ਸੂਚੀ:

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 ਰਿਫਲਿਕਸ਼ਨ ਰਾਹੀਂ, ਇਹ ਸਾਰੀਆਂ ਨੇਸਟਡ ਰੀਅਲਮ ਆਬਜੈਕਟ ਲੱਭਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਰੇਖਿਕ ਸੂਚੀ ਵਿੱਚ ਰੱਖਦਾ ਹੈ। ਫਿਰ ਅਸੀਂ ਵਾਰ-ਵਾਰ ਉਹੀ ਕੰਮ ਕਰਦੇ ਹਾਂ। ਮਿਟਾਉਣ ਵੇਲੇ, ਤੁਹਾਨੂੰ ਵੈਧਤਾ ਲਈ ਵਸਤੂ ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ isValid, ਕਿਉਂਕਿ ਇਹ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਵੱਖ-ਵੱਖ ਮੂਲ ਵਸਤੂਆਂ ਵਿੱਚ ਇੱਕੋ ਜਿਹੇ ਨੇਸਟ ਕੀਤੇ ਹੋਏ ਹੋ ਸਕਦੇ ਹਨ। ਇਸ ਤੋਂ ਬਚਣਾ ਬਿਹਤਰ ਹੈ ਅਤੇ ਨਵੇਂ ਆਬਜੈਕਟ ਬਣਾਉਣ ਵੇਲੇ ਆਈਡੀ ਦੀ ਆਟੋ-ਜਨਰੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰੋ।

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 ਡੇਟਾਬੇਸ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਬਹੁਤ ਹੌਲੀ ਹੌਲੀ ਲਾਂਚ ਕਰਨ ਦਾ ਕਾਰਨ ਬਣ ਰਿਹਾ ਸੀ। ਅਸੀਂ ਨੇਸਟਡ ਆਬਜੈਕਟਸ ਦੇ ਆਪਣੇ "ਕੈਸਕੇਡਿੰਗ ਡਿਲੀਟ" ਦੇ ਨਾਲ ਇੱਕ ਅਪਡੇਟ ਜਾਰੀ ਕੀਤਾ ਹੈ। ਅਤੇ ਹੁਣ ਅਸੀਂ ਨਿਗਰਾਨੀ ਕਰਦੇ ਹਾਂ ਅਤੇ ਮੁਲਾਂਕਣ ਕਰਦੇ ਹਾਂ ਕਿ ਸਾਡੇ ਫੈਸਲੇ ਨੇ _app_start ਮੀਟ੍ਰਿਕ ਦੁਆਰਾ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਸ਼ੁਰੂਆਤੀ ਸਮੇਂ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ ਹੈ।

ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ, ਅਸੀਂ 90 ਦਿਨਾਂ ਦੀ ਸਮਾਂ ਮਿਆਦ ਲੈਂਦੇ ਹਾਂ ਅਤੇ ਦੇਖਦੇ ਹਾਂ: ਐਪਲੀਕੇਸ਼ਨ ਲਾਂਚ ਕਰਨ ਦਾ ਸਮਾਂ, ਮੱਧਮਾਨ ਅਤੇ ਉਹ ਜੋ ਉਪਭੋਗਤਾਵਾਂ ਦੇ 95ਵੇਂ ਪ੍ਰਤੀਸ਼ਤ 'ਤੇ ਆਉਂਦਾ ਹੈ, ਘਟਣਾ ਸ਼ੁਰੂ ਹੋ ਗਿਆ ਹੈ ਅਤੇ ਹੁਣ ਵਧਦਾ ਨਹੀਂ ਹੈ।

ਜੇਕਰ ਤੁਸੀਂ ਸੱਤ-ਦਿਨਾਂ ਦੇ ਚਾਰਟ 'ਤੇ ਨਜ਼ਰ ਮਾਰਦੇ ਹੋ, ਤਾਂ _app_start ਮੈਟ੍ਰਿਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਢੁਕਵੀਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ ਅਤੇ 1 ਸਕਿੰਟ ਤੋਂ ਘੱਟ ਹੈ।

ਇਹ ਵੀ ਜੋੜਨਾ ਮਹੱਤਵਪੂਰਣ ਹੈ ਕਿ ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ, ਜੇਕਰ _app_start ਦਾ ਮੱਧਮ ਮੁੱਲ 5 ਸਕਿੰਟਾਂ ਤੋਂ ਵੱਧ ਹੈ ਤਾਂ Firebase ਸੂਚਨਾਵਾਂ ਭੇਜਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਦੇਖ ਸਕਦੇ ਹਾਂ, ਤੁਹਾਨੂੰ ਇਸ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ, ਸਗੋਂ ਅੰਦਰ ਜਾ ਕੇ ਇਸ ਦੀ ਸਪੱਸ਼ਟ ਜਾਂਚ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

ਰੀਅਲਮ ਡੇਟਾਬੇਸ ਦੀ ਖਾਸ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਹ ਇੱਕ ਗੈਰ-ਸੰਬੰਧੀ ਡੇਟਾਬੇਸ ਹੈ। ਇਸਦੀ ਵਰਤੋਂ ਦੀ ਸੌਖ, ORM ਹੱਲਾਂ ਅਤੇ ਆਬਜੈਕਟ ਲਿੰਕਿੰਗ ਦੀ ਸਮਾਨਤਾ ਦੇ ਬਾਵਜੂਦ, ਇਸ ਵਿੱਚ ਕੈਸਕੇਡ ਮਿਟਾਉਣਾ ਨਹੀਂ ਹੈ।

ਜੇਕਰ ਇਸ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਨਹੀਂ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਨੇਸਟਡ ਵਸਤੂਆਂ ਇਕੱਠੀਆਂ ਹੋ ਜਾਣਗੀਆਂ ਅਤੇ "ਲੀਕ ਹੋ ਜਾਣਗੀਆਂ।" ਡੇਟਾਬੇਸ ਲਗਾਤਾਰ ਵਧੇਗਾ, ਜੋ ਬਦਲੇ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਸੁਸਤੀ ਜਾਂ ਸ਼ੁਰੂਆਤ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰੇਗਾ।

ਮੈਂ ਆਪਣੇ ਤਜ਼ਰਬੇ ਨੂੰ ਸਾਂਝਾ ਕੀਤਾ ਹੈ ਕਿ ਕਿਵੇਂ ਰੀਅਲਮ ਵਿੱਚ ਆਬਜੈਕਟਾਂ ਦੇ ਕੈਸਕੇਡ ਨੂੰ ਜਲਦੀ ਮਿਟਾਉਣਾ ਹੈ, ਜੋ ਕਿ ਅਜੇ ਤੱਕ ਬਾਕਸ ਤੋਂ ਬਾਹਰ ਨਹੀਂ ਹੈ, ਪਰ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਇਸ ਬਾਰੇ ਗੱਲ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ. ਉਹ ਕਹਿੰਦੇ ਹਨ и ਉਹ ਕਹਿੰਦੇ ਹਨ. ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਇਸਨੇ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਸ਼ੁਰੂਆਤੀ ਸਮੇਂ ਨੂੰ ਬਹੁਤ ਤੇਜ਼ ਕੀਤਾ.

ਇਸ ਵਿਸ਼ੇਸ਼ਤਾ ਦੀ ਨਜ਼ਦੀਕੀ ਦਿੱਖ ਬਾਰੇ ਚਰਚਾ ਦੇ ਬਾਵਜੂਦ, ਰੀਅਲਮ ਵਿੱਚ ਕੈਸਕੇਡ ਮਿਟਾਉਣ ਦੀ ਅਣਹੋਂਦ ਡਿਜ਼ਾਇਨ ਦੁਆਰਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ. ਜੇਕਰ ਤੁਸੀਂ ਨਵੀਂ ਐਪਲੀਕੇਸ਼ਨ ਡਿਜ਼ਾਈਨ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਸ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖੋ। ਅਤੇ ਜੇਕਰ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਰੀਅਲਮ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਜਾਂਚ ਕਰੋ ਕਿ ਕੀ ਤੁਹਾਨੂੰ ਅਜਿਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹਨ।

ਸਰੋਤ: www.habr.com