사용및 로그에 에러가나는것은없습니다..

프로그램 관리자로 메모리 확인시 나타나는현상입니다.

다만 메모리가 과다하게 축척되다가

가끔 메모리가 오버대면 메모리정리하는 식으로 하네요..

메모리 정리할때도 앱이꺼지는것은 아니고 잠깐 껌은화면 나왔다가 넘어가는 정도입니다.

오류는 안나는데 의도할때 메모리를 반환하지 않아서 올린질문입니다.

finish를 호출한다고 해서 onDestroy메소드가 항상 호출되지 않습니다.

System.gc 도 실행하더라도 바로 메모리 해제를 수행하지 않습니다.

또한 intent를 띄울때 사용한 context의 범위에 따라 메모리가 해제되지 않을 수 있습니다.

위의 이유 때문에 원하는 타이밍에 메모리 해제가 안돼는것 같습니다.

다른 콜백메소드에 조건을 달아서 해제를 해주는 것도 나쁘지 않을거라 생각합니다.

인텐트 생성시 컨텍스트를 this로 지정하게 되면 당연히 액티비티의 객체 자체를 가지게 되면 액티비티 객체에서 Context 정보를 쓰는것입니다. 액티비티 객체는 해당 활동의 모든 데이터 정보와 뷰 구조 뷰객체 정보 등 정말 비싼 자원들을 가지게 되는데요. 이렇게 건너 건너 건너 this를 자주 사용하게 되면 분명 화면 표시는 하지 않지만 해당 정보 객체가 계속 다른 액티비티의 Context정보 레퍼런스에 사용되기 때문에 메모리 참조가 유지되어 GC가 해당 레퍼런스의 해제를 하지 않습니다. 없어진 액티비티에서는 이미 onDestroy는 호출 되었더라도 다른 객체에서 참조하고 있기 때문에 메모리에서 해제할 수 없는것입니다.

위경우와 연계되는 내용인데 NoBrain님 말씀처럼 네이티브 힙 메모리를 사용하는 비트맵팩토리의 문제인 확률이 90% 이상으로 보입니다. 대부분 문제가 디코딩된 비트맵 때문인 경우이죠.

다이얼로그등 윈도우 정보가 필요한 경우를 제외하고는 getApplicationContext를 이용하시는것을 권장합니다.

onDestroy에서는 꼭 비트맵이 들어있던 뷰의 drawable을 얻어서 bitmapdrawable일 경우 recycle 처리를 해주시고 해당 drawable의 콜백도 null로 set해주세요... 사용하고난 Bitmap의 recycle작업도 병행해주시구요...

별다른 정보가 없어서 제 짧은 지식으로는 떠오르는것은 이정도네용...