티스토리 뷰
안드로이드에는 런쳐(홈 앱)에 위젯을 사용자 마음대로 설치할 수 있다. 사용자는 주어진 기능이기 때문에 원하는대로 사용하려고 하게되는데, 많이 설치하면 할수록 런쳐가 사용하는 메모리가 커진다는 것을 잘 이해하지 못하는 것 같다. 개발자들도 위젯을 개발해 보지 않으면 위젯의 생명 주기를 잘 이해하지 못하곤 한다.
위젯은 런쳐의 메모리를 사용한다.
그렇다. 위젯은 런쳐의 메모리를 사용하고 지속적으로 점유한다. 그런데 런쳐는 사실상 계속 살아있는 앱이므로 런쳐의 메모리가 커지면 가용램이 줄어든다고 말할 수 있다 이는 곧 전체적인 폰의 성능 저하로 이어지게 된다.
만약 게임등에 의해 메모리 사용이 극대화 되고 가용램이 없게되면 LMK(Low Memory Killer)에 의해 우선순위에 따라 프로세스들이 죽어가게 된다. 거의 최종 단계에 가야 런쳐가 종료될 수 있다. 런쳐의 우선순위가 매우 높게 설정되기 때문이다. 어쩌다 간혹, 앱 실행 중에 홈 키로 빠져나갈 때 자연스럽지 않고 런쳐가 다시 실행되는 듯 한 모습을 볼 수 있는데, 런쳐가 중단되었다가 다시 실행되었다고 보면 될 것이다. 이런 경우 홈으로의 전환이 느려지고 폰이 빠릿하지 못하다는 느낌을 받을 수 있다. 양날의 검이라고 볼 수 있는데.. 이런 현상을 줄이려고 런쳐의 우선순위가 높은 것이다.
따라서 런쳐가 사용하는 메모리는 적으면 적을수록 좋다. 그러므로 위젯을 설계할 때에는 메모리를 고민해야 한다.
기술적으로 위젯의 동작 대해 말하자면, 위젯은 위젯을 제공하는 각 앱의 프로세스 위에 로딩되는 것이 아니고 그 메모리를 사용하지도 않는다. 위젯 개발시 오해하기 쉬운 부분이다. 위젯의 뷰를 구성하기 위해서 위젯을 채울 준비 작업들은 각 앱의 프로세스 위에서 일어나지만(AppWidgetProvider가 동작되는 부분), 실제로 위젯이 화면에 뿌려질 때 동작되는 프로세스는 런쳐이며 로딩되면서 사용하는 메모리 역시 런쳐의 메모리이다. 위젯의 뷰 구성을 위해 사용하는 RemoteViews가 Parcelable을 구현하는 것을 보면 알 수 있듯 프로세스간 통신(앱 프로세스 -> 런쳐 프로세스)으로 객체를 전달하기 위해서이다. 클릭 이벤트 처리를 위해 PendingIntent를 사용하는것을 보면 이벤트들이 내 앱 위에서 일어나는 일이 아니라는 것을 눈치챌 수 있다.
이미지와 구성요소를 적게 사용해야 한다
때문에 위젯 개발자들은 메모리가 공동 점유됨을 알고 주의하여 개발하여야 한다. 예쁜 UI를 구성하기 위해 위젯에 큰 이미지를 많이 쓰게되면 그만큼 메모리를 사용하게 된다. 레이아웃에 뷰를 잔뜩 올려 복잡하게 구성하면 런쳐가 로딩하는데 부하가 걸리고 화면을 그리는데도 늦어진다.
좀 더 주의깊게 주의해야 할 점은 gone으로 visibility를 설정해 둔 뷰와 이 뷰가 사용하는 이미지도 메모리에 로딩된다는 것이다. 당연한 이야기인데 간과하기 쉽다. 만약 뷰가 ImageView와 같이 이미지를 로딩할 수 있는 것이라면 여기에 src나 background로 할당한 이미지도 레이아웃이 inflate되는 시점에 메모리에 올라오게 된다. gone으로 해 두었다고 해도 말이다. 나중에 필요할 때 visibility만 교체해서 쓰겠다고 생각한다면 메모리를 낭비하는 것이다. Activity는 생명 주기가 짧으니까 이렇게 해도 문제가 없다. 그러나 위젯은 그렇지 않다는 것을 고려해야한다.
같은 이유로 selector drawable사용도 메모리를 의도치않게 쓰게 만든다. 버튼들이 사용자의 액션에 따라 보여지는 형태가 달라지길 원한다면 selector를 사용하게 된다. pressed, focused 등 상태에 따라 눌림효과나 선택된 효과 등의 다른 이미지를 설정하여 쓰는데, 여기서 설정한 모든 이미지들은 layout의 inflate타이밍에 모두 메모리에 올려진다. 사용자의 터치에 대해 매우 짧은 순간에 반응해야 하므로 필요에 따라 로딩하는 것은 불가능하다. 당연한 프로세스로 이해해야 한다. 그러나 어쨌든 그만큼 메모리를 사용하므로 필요한 부분에만 적당히 사용하도록 고려해야 한다.
마치면서
사용자에게 선택받기 위해 화려하게 구성하는 것에 손이 가기 쉽겠지만, 장기적으로 사용자를 고려한다면 필요한 부분만 간단히 제공하는 것이 최상이라 생각된다. 이러한 점을 이해하도록 기획하는 사람들이나 디자이너들을 설득하는 것이 개발하는 사람에게 필요하다.