진쓰의 프로그래밍 지식저장소

아래 참고싸이트를 번역한 수준밖에안됩니다 ^^;;;

Thread 인스턴스를 생성해서 운영할때도 문제가 생길 수 있습니다.

Thread 가 실행되는 시점에서는 GC가 Thread를 수거해가지 않습니다. 또한, Thread가 참조하고있는

Outer class등의 reference도 잡고있어서, Activity내의 Thread를 운영할때는 주의를 기울여야 합니다.

흔히들 하는 실수

1. 액비비티 내에서 Thread의 참조변수를 static 변수로 두는 행위

2. custom Inner Thread class를 정의할때 non-static 으로 정의하는경우

해결책

1. Thread 인스턴스를 static변수로 저장하지 말아라.

2. custom static innter thread class를 정의하고 운영해라. 

단 Activity가 종료될때 (onDestroy() ), Thread의 종료를 끝낼 수 있는 로직을 추가해서 깔끔하게 종료되도록 해라.

참고

https://android.jlelse.eu/9-ways-to-avoid-memory-leaks-in-android-b6d81648e35e

아래의 참고싸이트를 번역한 수준밖에 안됩니다 ^^;;;

보통 Handler를 사용할때 생길 수 있는 문제가...

1. 멤버변수로 new Handler() 의 인스턴스를 가지고 있는경우

핸들러의 인스턴스를 클래스가 가지고있으면, Message Queue가 Outer class인 Outer class의 reference를 잡고있게 되어버린다.

2. 핸들러가 Outer class의 reference를 가지고 있어야 할 경우

해결책

1. Handler 인스턴스가 필요한경우 새롭게 Handler class를 상속받는 static inner class를 내부에 정의하고 구현.

-> 이렇게 되면 Handler 인스턴스를 사용해도 Message Queue는 Outer class Reference를 안잡게되어, Activity가 종료되는순간 해제되게됨.

2. WeakReference 사용

Handler인스턴스도 결국 메시지를 받아서 Outer class인 Acitivtiy의 view를 변경해야할 작업이 있을 수 있음

이럴때 WeakReference로 받게되어 처리하게되면, Activity종료시점에 안정적으로 해제할 수 있음. 또한, Acitivtiy가 날라간 경우도 생길 수 있는데 이때 null check를 통해 안정적으로 가저가면 문제는 해결됨.

참고

https://android.jlelse.eu/9-ways-to-avoid-memory-leaks-in-android-b6d81648e35e

아래 싸이트 에서 발췌하였습니다.

https://android.jlelse.eu/9-ways-to-avoid-memory-leaks-in-android-b6d81648e35e

들어가서 확인해보시면 알겠지만(6. AsyncTask Reference) 흔히들 Activity에서 inner class로 AsyncTask를 상속받은 클래스를 만든다음 거기서 시간이 많이 지연되는일 혹은, Outer class인 Activity의 view들을 직접 참조하여 사용하는 경우가 많을 것입니다.

1. 일반 inner class로 생성하여 outer class의 reference를 쥐지 않도록 해야합니다. static inner class를 사용하는게 바람직합니다.

2.outer class의 activity가 종료될때 AsyncTask가 진행중인일이있다면 취소를해주고 종료를 시켜줘야 합니다. 안그렇게 되면 AsyncTask는 activity가 종료되었음에도 불구하고 계속해서 동작하기 때문입니다.

3.inner asynctask에서 직접 outer class의 activity의 view를 참고하지말아야합니다. (결국 context를 쥐고있는것과 같게 됩니다.)

위의 3가지 실수를 막기위한 옵션으로는

1. inner AsyncTask class -> static inner AsyncTask class로 변경

2.Activity onDestory시점에서 AsyncTask의 task를 끝낼수있도록 cancel 요청을 날려야함

3.WeakReference를 사용해서 view혹은 context를받아야함