안드로이드는 필요에 따라 현재 메모리상에 상주된 프로세스들을 킬시켜 실행되는 프로그램에 메모리를 확보해준다....
따라서 헤비한 어플이 실행될경우 홈어플인 런쳐프로까지 같이 킬되는바람에 결국 돌아올때 홈어플을 재실행하게 되어
홈딜이생기게 된다.
여기까지는 이해가 되는데 말이죠... 런처프로의 keep in memory 옵션을 사용하면 이론적으로는 홈어플들이 어떤 상황에도 안죽어서 홈딜이 발생하지 않아야 하는게 아닌가 싶은데 현실은 그렇지 않죠?
런처에서 말하는 keep in memory가 안드로이드 운영체제상에서 어떤식으로 동작하는건지 자세히 알고 싶네요.
그동안 홈딜에 대해서 좀관찰해본바에 따르면.. 반드시 게임같은 큰 어플돌리고 나서 홈딜이 생기는건 아닙니다. 제경우엔 EStrings File manager 최신버전과 Quardrant benchmark를 실행했다가 종료하는순간 자주 홈딜이 발생을 했었습니다. 그래서 EStrongs File manager 는 낮은 버전으로 쓰고있고 Quardrant는 이제 테스트할것도 없어서 지워버렸습니다.
특히 quardrant 경우 별다른 벤치테스트 하지 않고 잠깐 system info만 보고 나오는데도 홈딜이 걸릴때도 있었습니다.
별거 없어보이는 이런 어플들이 사실 메모리 자원을 많이 쓰고있었을지도 모르죠.
테스크 전환때 보다 태스크 종료때 주로 홈딜이 많이 걸립니다. 그렇다면 어플이 종료하면서 메모리를 반환하는 과정이 원활치 않아 홈딜이 생기는 원인이 될까요? 메모리 최적화를 위한 garbege collection 이 동작하기 때문일까요?
백업어플을 써서 어플들을 한번에 백업하고 한번에 다 설치하고 하니 홈딜이 생겼던 경험도 있습니다. 그 이후론 꼭 하나씩 일일히 까는 버릇이 생겼습니다. (뭐사실 시간도 익숙해져서 이젠 비슷비슷합니다)
이번 루팅으로 /data/app -> /system/app 이동으로 홈딜이 사라졌다는 분도 계시는데...과연 기분상일까요? 실제로 그런걸까요? 아니면 오버클럭빨일 까요?
솔직히 현재 제 모토로이는 홈딜이 없다 라고 말해도 될정도로 하루종일 원활이 돌아갑니다. 그런데 이 상황을 정형화 시키기가 참 힘드네요.
쓰다보니 정말 주절주절이군요. 흠.
위젯 생각을 못했군요. 그러네요. 런처는 상주하지만 위젯들은 스왑할수있군요. 그렇다면 위젯들이 없으면 홈딜현상이 일어나지 말아야 하는것(아니면 거의)...이네요. 제가 궁금한건 절대로 스왑아웃되서는 안되는 프로세스를 안드로이드 운영체제에서 지정해줄수 있을까? 라는것이에요. 리눅스 유닉스를 쓴지오래되서 기억이 가물가물한데 그게 되던가...음... 런처의 keep in memory 옵션이 단지 계속해서 메모리에 상주해있어라(스왑아웃되도 무조건 원상복귀해라) 인지 아니면 진짜로 스왑아웃되지말고 계속 버텨라 인지 모르겠네요.
아마도 계속 메모리에서 버티라는 옵션인것 같습니다. (추측입니다)
실제로 런처 설치 후 keep in memory 를 체크 해둔 상태에서 캠코더로 동영상 촬영시 조금 찍다 보면 메모리 부족 메세지가 뜨거든요.
리눅스쪽 운영체제쪽은 저도 프로그래밍 해본 적이 없어서 뭐라 말씀 드리기 힘들지만 메모리 상주 옵션은 있을거라 생각합니다.
아니면 priority 를 아주 높게 설정해서 안드로이드 시스템에서 밀어내지 않는한 상주하게 한다던가.. 하는게 있지 않을까요
윈도우에서도 개별 프로세스 마다 priority 를 줄 수 있습니다. 리눅스도 있지 않을까요.. 그거 잘 못 정해주면 멀티태스킹에 심각한 영향을 초래하죠..
윈도우 작업관리자에서 프로세스에서 오른쪽 마우스 클릭 후 우선순위 설정을 하심 되는데... 절대! 실시간으로는 해보지 마세요!
운영체제론을 공부해보시면 알수 있습니다.
운영체제는 메모리 상에 상주를 하면서 각각의 프로세스들을 관리를 하게 됩니다.
사용자가 어떤 명령을 내리면 운영체제는 인터럽트를 발생시키고 현재 상황을 모두 중단 시키게 됩니다. 그리고 사용자의 명령을 수행하는데 이 명령을 수행하기 위해서는 현재 작업중인 내용을 메모리에 기록을 하게 됩니다. 메모리의 양이 충분하지 못한 경우에는 운영체제마다의 특별한 방식에 의해 우선순위를 정해서 디스크로 기록을 하게 됩니다. 이게 바로 디스크의 캐시라고 할수도 있습니다.
메모리 상에 그대로 둘 것인지 아니면 디스크에 저장을 할 것인지는 해당 프로세스의 호출 빈도와 우선순위에 따라 달리지게 되는거죠.
런쳐가 keep in memory 옵션을 통해서 메모리 상에 상주를 하게 되더라도 위젯까지 같이 메모리 상에 상주하는건 아니죠.
위젯들은 바탕화면에서 대기 상태로 있으면서 운영체제로 부터의 호출(인터럽트) 만을 기다리고 있는데 호출이 없었다면..
운영체제로 부터 우선순위(대기표 정도)는 낮아지게 되고 화면이 모두 전환되는 프로그램 실행 시 메모리가 아닌 디스크 상으로 상태가 저장되게 됩니다.
그러다가 어플이 종료 되고 (런처의 인터럽트 발생) 어플 실행전 상태값을 메모리로 부터 읽어와서 복원을 하게 되는데 이 때 위젯들과 런쳐가 동기화가 안되서 (런처는 메모리에 그대로 있지만 위젯들은 다시 메모리로 스왑을 해야 하죠...) 딜이 생기는 것처럼 느껴지는 것입니다.