Утечка памяти или просто медленный эмулятор? - PullRequest
Новая
       34

Утечка памяти или просто медленный эмулятор?

0 голосов
/ 11 февраля 2020

Я получил следующую ошибку на CI: 

531532 bytes retained by leaking objects
Signature: 57cc9bd9b14a813ead44f7eba2d9ffa1de2c4649
┬───
│ GC Root: Java local variable
│
├─ android.app.Instrumentation$InstrumentationThread thread
│    Leaking: UNKNOWN
│    Thread name: 'Instr: com.comp.test.runner.YInstrumentationRunner'
│    ↓ Instrumentation$InstrumentationThread.<Java Local>
│                                            ~~~~~~~~~~~~
├─ java.util.ArrayList instance
│    Leaking: UNKNOWN
│    ↓ ArrayList.elementData
│                ~~~~~~~~~~~
├─ java.lang.Object[] array
│    Leaking: UNKNOWN
│    ↓ Object[].[0]
│               ~~~
├─ org.junit.runner.Result$Listener instance
│    Leaking: UNKNOWN
│    ↓ Result$Listener.this$0
│                      ~~~~~~
├─ org.junit.runner.Result instance
│    Leaking: UNKNOWN
│    ↓ Result.failures
│             ~~~~~~~~
├─ java.util.concurrent.CopyOnWriteArrayList instance
│    Leaking: UNKNOWN
│    ↓ CopyOnWriteArrayList.elements
│                           ~~~~~~~~
├─ java.lang.Object[] array
│    Leaking: UNKNOWN
│    ↓ Object[].[4]
│               ~~~
├─ org.junit.runner.notification.Failure instance
│    Leaking: UNKNOWN
│    ↓ Failure.fThrownException
│              ~~~~~~~~~~~~~~~~
├─ androidx.test.espresso.NoMatchingViewException instance
│    Leaking: UNKNOWN
│    ↓ NoMatchingViewException.rootView
│                              ~~~~~~~~
├─ com.android.internal.policy.DecorView instance
│    Leaking: YES (View.mContext references a destroyed activity)
│    mContext instance of com.android.internal.policy.DecorContext, wrapping activity com.comp.android.t.ui.TransactionAggregateActivity with mDestroyed = true
│    View#mParent is null
│    View#mAttachInfo is null (view detached)
│    View.mWindowAttachCount = 1
│    ↓ DecorView.mContentRoot
├─ android.widget.LinearLayout instance
│    Leaking: YES (DecorView↑ is leaking and View.mContext references a destroyed activity)
│    mContext instance of com.comp.android.t.ui.TransactionAggregateActivity with mDestroyed = true
│    View#mParent is set
│    View#mAttachInfo is null (view detached)
│    View.mWindowAttachCount = 1
│    ↓ LinearLayout.mContext
╰→ com.comp.android.t.ui.TransactionAggregateActivity instance
​     Leaking: YES (ObjectWatcher was watching this because com.comp.android.t.ui.TransactionAggregateActivity received Activity#onDestroy() callback and Activity#mDestroyed is true)
​     key = 61835653-e97b-48a8-b7a2-8663d45eeec5
​     watchDurationMillis = 8798
​     retainedDurationMillis = 3797

1 Ответ

1 голос
/ 12 февраля 2020

Это определенно неожиданно. См. Документацию: https://square.github.io/leakcanary/recipes/#running -leakcanary-in-instrumentation-tests

LeakCanary автоматически отключается, если для LeakCanary.config.dumpHeap задать значение false, когда JUnit находится в пути к классам выполнения .

Пользовательский прослушиватель теста (leakcanary.FailTestOnLeakRunListener) будет запускать анализ только при успешном выполнении теста, а не при его неудаче.

Так что вы либо вручную включили LeakCanary в тестах пользовательского интерфейса, или код для определения того, что тесты пользовательского интерфейса работают, не работает. В любом случае, вам, вероятно, следует сообщить о проблеме в LeakCanary с этими подробностями.

...