엑티비티 라이프사이클이라는게 있는데요..

사진을 올리려는데 댓글로는 잘 안올라가네요 -_-;; 네이년에 검색하시면 바로 나올껍니다..ㅎ

암튼... 그걸보시면..

엑티비티가 A가 create되고.. 엑티비티 스텍의 젤 위로 올라와 OnResume상태가 됬을때요..

또 다른  엑티비티 B가 호출되어 현재A의 위로 올라오게되면 A는 onPause상태로 빠지게되죠..

뒤로 빠진 A는 사용자에의해 다시 Resume 되거나 Stop되죠,,

근데 여기서 새로들어온 B가 메모리를 엄청나게 잡아먹어 CPU가 죽으려고 깔딱깔딱 한다면.....

엑티비티 메니져가 스택에 쌓여있던 A를 Kill하게 됩니다..

아마...ㅎㅎ

이상이구요~

좋은하루 보내십시오^^

Low memory killer 라는 놈이 있습니다.

Activity manager 가 스택에서 관리하는 액티비티들은 사용빈도에 따라 우선순위가 메겨져 있죠..

현재 실행중인 프로세서가 메모리 부족현상이 발생하면 OOM(Out Of Memory) 를 발생시키지 않고

이 low memory killer 가 activity manager 가 관리하는 스택을 참조해서

빈도수가 가장 낮은놈 부터 하나씩 kill 해 나가게 됩니다. 이때 액티비티의 상태는 onStop 상태인 놈들만 해당됩니다.

아,,, 그게요,,,

제가 예를 잘못들었군요...;;;

로우메모리킬러가 엑티비티를 죽이는게 아니라 프로세스를 날려버리는데요..

어떤 어플리케이션이 A가 3개의 엑티비티 A1, A2, A3를 가지고있고

다른 어플리케이션 B가 2개의 엑티비티 B1, B2를 가지고있을때

OOM이 발생할경우.....

프로세스들의 중요도에 따라 그룹으로 나눈 후에 중요도가 낮은 그룹에 있는 Process부터 하나씩  Kill하게 되는데요..

즉, B1 엑티비티를 날리는게 아니고 B프로세스를 통째로 Kill한다는거죠...

참고로..

안드로이드에서는 내가 짠 애플리케이션 프로세스의 생명주기를 직접 제어할수 없습니다..

이상이구요.. 혹시 제가 잘못알고 있는거면.. 다른 고수님들께서 다시 알려주실꺼에요^^;;

그럼.. 저녁 맛있게 드십시오...

1시간이나 남았는데 벌써배고프네요..ㅠ

제가 제대로 알고 있는건 아니지만 아는 한에서 말씀드려 볼께요.

문제가 되는 부분이나 잘못된 부분은 아시는 분께서 고쳐주시면 감사드릴께요 :)

============================================================================

gc의 경우, gc 정책이 process의 종료 ( back버튼 누를 시) 가 아닌 그냥 부족할때 종료합니다.

이종님 말씀대로, 프로세스 종료가 안드로이드 멋대로 이구요.

(gc의 타이밍을 찾아보다가 그냥 포기한적이 있었습니다.)

gc또한 프로세스의 killing이 아닌

각 프로세스별로 할당된 stack을 제거하는걸로 알고있습니다.

1byte stack, 2byte, 4byte.. 이런식으로 들고있는걸로 알고 있구요.

gc시 해당 스택의 하단부를 날리는 방식으로 처리하는걸로 알고있습니다.

액티비티또한 프로세스별로 액티비티 스택이 존재해서 처리되는걸로 알고 있구요.

진정한 고수님의 정식 답변을 기다립니다 :)

음...

가비지의 단위부터 정확히 파악하는게 먼저겠네요..

조언 주셔서 감사합니다.

시스템에서 기본으로 동작시키는 미디어매니저나 뮤직 알람같은 서비스들도 죽이는걸 확인했었습니다.

어플을 끄면 다시 죽었던 서비스를 동작 시키구요.

 각 프로세스 별로 우선순위가 있는데 제일 낮은 단계부터 죽이기 시작해서

그래도 부족할 경우에는 최악의 경우 시스템 관련 프로세스까지 죽이게 되네요.

그래도 acore는 살아있는거 같았는데 1.6떄 힙사이즈 테스트하면서 해볼거라 지금은 확실치 않네요.

acore는 시스템에 필요한 여러가지가 들어있습니다.

저도 모든 패키지를 다 까본게 아니라서 확실하게 말씀은 못드리지만,

기본적으로 home screen 이라 불리우는 Launcher의 프로세스 명이 acore 입니다 :)