Понимание трассировки стека утечки памяти LeakCanary

У меня есть простое новостное приложение, и недавно я начал получать отчеты о сбоях с OOM от некоторых пользователей (из Firebase Crashlytics). После некоторых исследований я обнаружил, что причина может быть в утечке памяти. Итак, я установил LeakCanary и, в конце концов, используя апо, я вижу, что он сообщает о потенциальной проблеме.

Может ли кто-нибудь из опытных помочь мне понять, в чем проблема? Я приложил журнал


leakcanary
person esQmo_    schedule 22.07.2019    source источник

Ответы (1)


arrow_upward
0
arrow_downward

См. https://square.github.io/leakcanary/fundamentals/#how-do-i-fix-a-memory-leak

Резюме:

  • Каждый узел в трассировке утечки является объектом Java и является либо классом, либо массивом объектов, либо экземпляром.
  • Спускаясь вниз, каждый узел имеет ссылку на следующий узел. В пользовательском интерфейсе эта ссылка выделена фиолетовым цветом. В представлении Logcat ссылка находится на строке, которая начинается со стрелки вниз.
  • В верхней части трассировки утечки находится корень сборки мусора (GC). Корни GC - это особые объекты, которые всегда доступны.
  • Внизу следа утечки находится экземпляр утечки. Этот экземпляр был передан в RefWatcher.watch (), чтобы подтвердить, что он будет собираться сборщиком мусора, и в итоге он не был собран, что вызвало срабатывание LeakCanary.
  • Цепочка ссылок из корня GC на экземпляр с утечкой - это то, что предотвращает сборку мусора для экземпляра с утечкой. Если вы можете определить ссылку, которая не должна существовать в этот момент времени, вы сможете выяснить, почему она все еще установлена ​​неправильно, а затем исправить утечку памяти.
person Pierre-Yves Ricau    schedule 22.07.2019
comment
Я уже приходил к этому сообщению с сайта LeakCanary, хотя на самом деле не понимаю - person esQmo_; 22.07.2019