메트로놈 Simple Metronome TIL 7
계속 돌 권리는 공짜가 아니라 거래로 얻는다
홈 버튼을 누르면 메트로놈이 멈췄다. 처음엔 화면을 나갈 때 소리를 끄는 코드를 빼면 되겠거니 했는데, 빼도 얼마 못 가 끊겼다. 시스템이 앱을 정리해 버리기 때문이다.
안드로이드는 화면에 없는 앱이 계속 도는 것을 강하게 제한한다. 계속 돌려면 시스템에 신고해야 한다. 그 신고 형식이 포그라운드 서비스다. 화면 없이 도는 작업 단위를 서비스라고 부르는데, 그중 사용자에게 드러내 놓고 도는 것이 포그라운드 서비스다.
이건 권한이라기보다 거래에 가깝다.
- 우리가 지는 의무는 상시 알림이다. 지금 뭔가 돌고 있다는 걸 사용자가 항상 볼 수 있어야 한다. 음악 앱에 늘 알림이 붙어 있는 이유가 이것이다.
- 대가로 시스템이 함부로 끄지 않는다.
여기서 배운 건 기술보다 태도다. 플랫폼이 막아 둔 것을 뚫으려 할 때, 대개 우회로가 아니라 정식 창구가 있다. 그 창구는 공짜가 아니고 의무를 요구한다. 의무가 감당할 만하면 그 길로 가는 게 맞다. 우리 경우엔 알림 하나를 띄우는 것이 의무였고, 메트로놈은 어차피 알림에 조작 버튼을 두는 게 편해서 손해가 아니었다.
코드를 빼서 얻는 기능과 구조를 바꿔야 얻는 기능이 있다
정지 코드를 빼는 것으로 안 됐던 이유는, 소리를 누가 들고 있느냐가 안 바뀌었기 때문이다. 소리 내는 부분이 화면에 딸려 있으면 화면이 사라질 때 같이 위태로워진다.
그래서 소리 내는 부분 전체를 화면에서 떼어 서비스로 옮겼다. 이제 화면은 없어도 되고, 소리는 서비스가 들고 있다.
기능 요청을 받으면 “무엇을 빼면 되나”부터 떠올리기 쉬운데, 그렇게 되는 건 절반도 안 된다. 나머지는 무엇이 무엇을 소유하는지를 바꿔야 한다.
상태의 진실은 죽지 않는 쪽이 쥔다
화면은 죽었다 살아난다. 회전하거나 테마를 바꾸면 안드로이드는 화면을 통째로 다시 만든다. 반면 서비스는 그동안에도 계속 소리를 내고 있다.
그러면 “지금 재생 중인가”라는 값을 누가 들고 있어야 하는가. 화면이 들고 있으면 다시 만들어질 때 복원되는데, 그 복원된 값이 실제와 다를 수 있다. 실제로 화면이 저장해 둔 “재생 중”이 되살아났는데 서비스는 이미 멈춰 있던 경우가 있었다.
그래서 진실은 서비스가 쥐고, 화면이 가진 값은 버튼 글자를 정하는 표시용으로 내렸다. 화면이 서비스에 붙을 때마다 서비스에 물어보고 자기 표시를 맞춘다.
같은 정보가 두 곳에 있으면 반드시 하나를 진실로 정해야 한다. 고르는 기준은 수명이다. 오래 사는 쪽, 죽었다 살아나지 않는 쪽이 진실을 쥔다.
주고받는 값은 절대 위치로 준다
서비스가 소리를 내고 화면이 박 표시를 켜니, 지금 몇 번째 박인지를 서비스가 화면에 알려 줘야 했다.
여기서 “다음 박으로 넘겨”라고 보내면 화면이 안 보고 있던 동안의 신호가 사라져서 영영 어긋난다. 대신 “지금 세 번째 박”이라고 절대 위치를 보냈다. 그러면 화면이 나갔다 들어와도 다음 신호 한 번에 정확히 맞춰진다. 복구를 위한 별도 장치가 필요 없다.
두 곳이 상태를 주고받을 때 증분으로 보내면 놓친 만큼 영구히 틀어지고, 절대값으로 보내면 다음 한 번에 저절로 복구된다. 놓칠 가능성이 있는 통로에서는 절대값이 싸다.
정리의 짝은 성공이 아니라 요청이다
화면이 서비스에 붙는 것을 바인딩이라고 한다. 붙여 달라고 요청하면 시스템이 뒤에서 연결을 맺고, 준비되면 알려 준다. 요청과 완료가 분리돼 있다.
여기서 함정이 있었다. 처음에는 “연결이 완료됐을 때만 정리한다”로 짰다. 정상적인 순서면 문제가 없다. 그런데 연결 완료 알림이 오기 전에 사용자가 앱을 나가면, 정리 조건이 아직 거짓이라 정리를 건너뛴다. 요청은 이미 접수돼 있는데 정리만 안 되는 상태가 된다.
이게 왜 문제냐면 메모리가 안 치워지기 때문이다. 코틀린이나 자바는 안 쓰는 메모리를 자동으로 치워 주는 장치가 있고, 이걸 가비지 컬렉션이라고 한다. 그런데 이 장치의 판단 기준은 “논리적으로 끝났나”가 아니라 “누가 아직 붙잡고 있나”다. 시스템이 우리 연결 요청을 붙잡고 있고 그 요청이 화면을 가리키고 있으면, 화면은 이미 끝났는데도 치워지지 않는다. 화면은 이미지와 뷰를 잔뜩 물고 있어서 덩치가 크고, 앱을 들락거릴수록 죽은 화면이 쌓여 결국 메모리 부족으로 앱이 죽는다.
고친 방식은 조건을 지운 것이다. 붙는 자리에서 항상 요청하니 떠나는 자리에서도 항상 정리한다. 아직 연결 안 된 요청을 정리해도 아무 문제가 없었다.
일반화하면 이렇다. 요청과 완료가 분리된 작업에서 정리의 짝은 요청이지 완료가 아니다. “성공했을 때만 정리한다”는 조건은 안전해 보이지만, 실패하거나 지연된 경우를 그대로 흘려보낸다. 정리 코드에 조건이 붙어 있으면 그 조건이 거짓인 채로 끝나는 경로가 있는지 먼저 확인한다.
예외 함수가 생겼다면 비교 기준이 좁다는 신호다
설정을 바꾸면 소리를 다시 만들어야 하는데, 처음에는 템포와 박자 정도만 비교해서 달라졌는지 판단했다. 그러다 사운드 종류만 바꾸면 반영이 안 되는 문제가 생겼고, 그때 “무조건 다시 시작하기”라는 예외 통로를 따로 만들어 붙였다.
나중에 비교 대상을 설정 전체로 넓히자 그 예외 통로가 통째로 필요 없어졌다. 무엇이 바뀌든 값이 다르면 다시 만든다.
교훈은 예외를 만들 때다. 정상 경로가 못 잡는 경우를 예외 함수로 덧대고 있다면, 그건 정상 경로의 판단 기준이 좁다는 신호일 때가 많다. 예외를 늘리기 전에 기준을 넓힐 수 있는지 먼저 본다.
백그라운드를 켜는 순간 “앱을 떠난다”가 여러 갈래로 쪼개진다
전에는 화면을 벗어나면 무조건 소리가 멈췄으니 생각할 게 없었다. 계속 재생을 켜자 떠나는 방식마다 사용자가 기대하는 게 달라졌다.
- 홈으로 나가기, 다른 앱으로 전환, 뒤로가기, 화면 회전, 테마 변경 — 계속 울려야 한다. 연습 중에 잠깐 다른 걸 보는 상황이다.
- 최근 앱 목록에서 앱을 밀어서 치우기 — 꺼져야 한다. 앱을 치웠는데 소리가 계속 나면 사용자는 끄는 법을 못 찾는다.
- 알림의 정지 버튼 — 당연히 꺼진다.
이걸 하나씩 정하지 않으면 기본 동작이 제멋대로 정해 준다. 백그라운드 동작을 붙이는 작업의 절반은 소리를 계속 내는 게 아니라, 어떤 이탈이 계속이고 어떤 이탈이 끝인지 목록을 만들어 정하는 일이었다.
요약
- 플랫폼이 막아 둔 것에는 대개 정식 창구가 있고, 그 창구는 의무와 대가를 짝지은 거래다. 의무가 감당할 만한지로 판단한다.
- 코드를 빼서 얻는 기능이 있고 소유 구조를 바꿔야 얻는 기능이 있다. 후자를 전자로 착각하면 시간을 버린다.
- 같은 정보가 두 곳에 있으면 오래 사는 쪽이 진실을 쥔다. 죽었다 살아나는 쪽이 쥐면 복원된 값이 실제와 어긋난다.
- 놓칠 수 있는 통로로 상태를 보낼 땐 증분이 아니라 절대값을 보낸다. 절대값은 다음 한 번에 저절로 복구된다.
- 요청과 완료가 분리된 작업에서 정리의 짝은 요청이다. 정리에 조건이 붙어 있으면 그 조건이 거짓인 채 끝나는 경로를 의심한다.
- 정상 경로를 못 잡아 예외 함수를 덧대고 있다면, 대개 정상 경로의 판단 기준이 좁은 것이다.
- 백그라운드 동작을 켜면 “앱을 떠난다”가 여러 갈래로 쪼개진다. 갈래마다 계속인지 끝인지 직접 정해야 한다.