이미 메모리를 덤프하고 메모리 누수가 있는지를 확인했습니다. 스크린 샷을 보면 한 조각 만 있지만 같은 유형의 발표자가 9 명 있다는 것을 알 수 있습니다. 오직 하나만 있어야합니다. 발표자 인스턴스 중 하나를 검사하면 프로파일 러에서 발표자에 대한 참조를 표시합니다. 이것들은 모두 RxAndroid 메소드의 콜백 메소드입니다. 조각의 onDestroyView에있는 모든 사람들을 적절하게 구독 취소합니다. 그래도 발표자 인스턴스는 정리되지 않습니다 (알 수 있듯이).프로파일 러를 사용하여 메모리 누수를 찾을 수있는 방법
그래서 개체가 여전히 가비지 수집되지 않았기 때문에 여전히 존재하는 유효한 (순환, 내부) 참조와 문제가있는 참조 (개체를 정리하지 못하게 함)를 구별하는 방법이 궁금합니다.
누가 메모리 누수가 발견 될 수 있는지 알아내는 방법을 안내 할 수 있습니까?
GC를 트리거 한 후이 덤프가 생성되었습니다. 
는 메모리 프로파일 러를 사용하여 가비지 수집을 강제하는 경우 는 당신은 그들이 실제 누출하고 단지 수집 기다리고되지 않은 가능성이 있으므로 사용에가 표시되는 추가 예상치 못한 객체를 알고있다. gc root에 대한 경로를 찾아야합니다. 그러면 다른 사용자가 가비지 수집을 유지하는 객체를 알 수 있습니다.
자세한 내용은 여기 'Garbge Collection Roots'섹션을 확인하십시오. 안드로이드 메모리 프로파일 러는 gc 루트에 도달하는 가장 짧은 홉 수를 알려주지 만, hprof를 캡처하고 Eclipse MAT과 같은 것을 사용하면 gc root의 경로를 볼 수 있습니다. Eclipse MAT는 누출 여부를 확인할 수도 있습니다.
메모리 누수를 감지하기 위해 Square에서 오픈 소스 라이브러리 Leakcanary을 시도해야합니다. 그것은
메모리 누수에 관한 내 블로그가 있습니다 & 누수록, you can find it here
누출 Canary는 누출 2 건을 찾는데 도움이되었습니다. 그러나 세 번째 누수가 발견되지 않았습니다. childFragmentManager 대신 supportFragmentManager를 사용했습니다. – stoefln
L 이미 일 했나요? https://github.com/square/leakcanary – Kriczer
LeakCanary에 깊이 들여다 보지 않았습니다. 지금은 그렇게 할 것입니다 ... – stoefln
어디에서 해당 객체의 Subscription을 저장합니까? 'unsubscribe'를 호출하는 것만으로는 충분하지 않습니다. 어떤 참조도 'null'해야합니다. 또는'onTerminateDetach'를 사용하십시오. – akarnokd