소개

요 전날 릴리스 전에 지뢰를 밟아, 그러고 보니 이전에도 비슷한 지뢰를 밟은 것을 기억했기 때문에 썼습니다.

사례

사례 1

발생한 사건

단일 Activity상에서 복수 Fragment(각각 A, B, C, D로 한다)를 전환하는 앱을 만들고 있을 때, BottomNavigation에서 전환하는 것도 Release 빌드에서만 D의 Fragment로 전환하려고 하는데도 B 의 조각이 표시되었습니다.

원인

Fragment의 tag에 그 Fragment의 Class.simpleName을 이용하고 있었던 것.

debug 빌드에서는 Proguard가 무효이므로 문제없이 독특한 문자열로서 기능해 주었지만, release 빌드에 있어서 난독화된 결과 아래와 같은 매핑이 되고 있었다.

A -> a.a

B --> b.b

C -> c.c

D --> d.b

여기서 name으로 참조하고 있으면 B와 D는 다른 것으로 인식할 수 있었던 것, simpleName을 참조하면 각각 b로밖에 볼 수 없고, Fragment 전환시 findByTag하면 b로밖에 참조할 수 없다. B와 D가 동일시되어 버렸다.

대응책

릴리스 전이었던 것과 다음의 사례와는 달리 Fragment의 식별만 할 수 있으면 좋기 때문에 simpleName 대신 name을 참조하도록 코드를 변경했는데 Release 빌드에서도 문제 없게 움직이게 되었다

사례 2

발생한 사건

앱을 업데이트하면 이전 버전에서 설정 한 앱의 설정 항목이 변경됩니다.

원인

SharedPreferences의 key에 이용하는 캐릭터 라인을 베타 쓰지 않고 Class.name로 생성하고 있었던 것.

simpleName이 아니라 name이므로 독특한 key는 되지만, 업데이트에 의한 클래스수의 증감이 있었던 것에 의해 mapping이 바뀌어 버려 보존시의 key로 참조할 수 없게 되어 버렸다.

예) 업데이트에 따라 패키지 b에 M이라는 클래스가 추가되었다.

Ver 1.0.0

a/A -> a.a

b/N -> b.a

Ver 1.0.1

a/A -> a.a

b/M -> b.a

b/N -> b.b

대응책

그 이후는 SharedPreferences의 key는 베타 쓰기로 정의, 이용하게 되었다

덧붙여 이 때는 앱은 릴리스 되었기 때문에 기존 유저가 보존한 설정의 key는 난독화된 클래스명 그대로였다

역기로 SharedPreferences의 wrapper 클래스에 자전으로 신구의 난독화된 클래스명의 mapping 처리를 써 변환하고 있던 기억

결론

simpleName, name은 디버그 LogCat에서의 이용 정도에 두는 것이 무난하다고 합니다.
아무리 안드로이드 스튜디오 선생님에게도 화를 낼 수 있으므로 Timber 사용하면 simpleName을 참조 할 필요도 없습니다.

만약 사용하는 경우는 Proguard가 걸려도 문제없는 내용인지 어떤지를 판단하고 나서 사용하도록 하지 않으면 위험하므로 조심합시다(자계)

simpleName, name에 관한 다른 사례를 가지고 계신 분은 꼭 가르쳐 주세요.