※ 본 포스팅은 Amit Shekhar의 작성한 “Android App Release Checklist For The Production Launch“의 번역 글로 저자에게 번역 요청에 대한 승인을 받고 작성된 글입니다.
열심히 앱을 만들어온 당신은 이 특별한 순간을 기다려왔습니다. 그 결과물을 상용 서비스로 런칭하려고 하는데, 혹시 내가 뭔가 놓친게 있나, 잊고 있는게 있나 생각이 들 수 있습니다.
본 포스팅에서는 그런 당신을 위한 궁극의 출시 전 체크리스트를 소개합니다.
1. Analytics 추가
의미있는 모든 곳에 분석 툴을 추가했는지 확인하세요. 가장 좋은 방법은 어떤 데이터가 필요한지, 어떤 메트릭을 측정하고 싶은지 생각해보고, 당신이 추가한 분석 툴을 통해 해당 데이터와 메트릭을 얻을 수 있는지 확인해보세요. 만약 이러한 모든 것들을 얻을 수 있다면 다음으로 이동해도 좋습니다.
2. Proguard 적용
우리가 만든 앱에 proguard를 적용하는 것은 여러 가지 면에서 도움이 됩니다. 앱 사이즈 감소로 직결되는 코드 량을 최소화 시킬 수 있고, 당신의 앱을 리버싱하려는 해커/개발자들로 하여금 코드를 알아보기 어렵게 난독화해줍니다.
자 그럼, Proguard를 적용할 때 고려해야 할 중요한 부분을 살펴봅시다.
● proguard-rules.pro 파일에 당신의 프로젝트에 포함된 라이브러리들에 관한 Proguard Rule들을 추가하는 것을 잊지마세요.
예를 들어, Okio 라이브러리를 사용한다면, 아래 rule을 추가해야 할 것입니다.
-dontwarn okio.**
만약 Proguard를 적용하고 싶지 않은 class들이 있다면, keep class를 사용하세요.
예를 들어, AmitShekhar.java 클래스에 난독화를 적용하고 싶지 않다면, 아래와 같은 rule을 적용해야 합니다.
-keep class com.mindorks.AmitShekhar**
● 프래그먼트 TAG로 AwesomFragment.class.getSimpleName()와 같은 구문은 사용하지 마세요. Proguard는 다른 package에 존재하는 같은 이름을 갖는 Fragment에 대해 동일한 이름을 할당할 수 있습니다.
이런 경우, 두 개의 프래그먼트가 동일한 TAG를 갖는 버그가 발생하게 됩니다.
● 원본 코드를 추적하기 위해 Proguard의 매핑 파일을 잘 보관하세요. 충돌 시 원본을 보기 위해 PlayStore 콘솔 같은 다른 곳에도 업로드해야 합니다.
3. Application 크기확인
앱 크기를 줄일 수록, 더 많은 다운로드 기회를 얻고, 사용자가 앱을 삭제할 일은 줄어들 수 있습니다. 그렇기 때문에 앱이 차지하는 용량은 매우 중요합니다. 배포 전 사용하지 않는 리소스 삭제를 꼭 잊지 마세요.
4. Crash Reporting 라이브러리 추가
Crash reporting 라이브러리를 적절히 추가했는지 확인하세요. 키가 production 혹은 그 외의 것들을 위한 것인지 확인해야 합니다.
5. Upgrade testing
이전 버전에서 새로운 버전으로 성공적으로 업데이트 되었다면 테스트하세요. 아마 데이터베이스를 수정하면서 데이터베이스 버전을 올리지 않았을 수 있습니다. 혹은 데이터베이스에서 변경된 내용을 마이그레이션하지 않았을 수 있습니다.
6. Logging과 Debugging을 Off 하세요
Release build 시 Logging과 Debugging을 모두 해제했는지 확인하세요. 디버그 전용의 앱을 사용자에게 제공해서는 안됩니다.
7. 신규 추가/수정된 내용 정리
새로운 버전을 PlayStore에 등록하는 동안 새롭게 추가/수정된 내용들을 준비하세요.
8. 업데이트된 스크린샷
새로운 버전의 앱을 등록하는 동안 새로운 스크린샷을 준비하세요. 사용자가 업데이트된 앱의 기능을 알 수 있게 도와줍니다.
9. 버전 명과 버전 코드
Release 빌드 시 올바른 버전 명과 버전 코드를 기입하는 것을 잊지 마세요. 그렇지 않으면, 추후 문제 발생 시 서로 다른 Release들 사이에서 문제를 관리하고 추적하는데 어려움을 가질 수 있습니다.
10. 성능 체크
다음의 지표들을 반드시 체크해야 합니다.
- Frames Per Second
- CPU Usage
- Memory Usage
- Network Traffic
- Disk
11. 다국어 지원
만약 다른 언어들을 지원한다면, 모든 언어들을 위한 string들을 추가했는지 확인하세요.
12. 다양한 OS 버전, 스크린 사이즈들에서 테스트하세요.
Android의 다양성에 대해 생각해보면, 모양, 크기, 다양한 성능 수준 그리고 다양한 버전의 Android가 있습니다. 따라서 넓은 범위의 Android 디바이스에서 테스트, 구동해봐야 합니다.
13. 보안 관점에서 앱을 살펴보세요.
중요하고, 쉽게 해킹될 수 있는 key 혹은 무언가가 있는지 확인하세요. 만약 그런 것들이 있다면 그런 것들을 좀더 안전하게 보호해야 합니다.
14. PlayStore 피드백을 항상 확인하세요
사용자가 이전 버전에서 보고한 것을 수정한 경우라면, 그 사용자의 피드백에 회신해주세요. 그게 바로 Release 체크리스트를 위한 것입니다.
'개발 > Android' 카테고리의 다른 글
Android Jetpack Navigation 사용하여 parameter 전달하기 (0) | 2020.11.08 |
---|---|
BroadcastReceiver에서 Background thread를 사용 시 주의 사항 (0) | 2020.11.08 |
[Android] Firebase FCM을 사용하여 서버 없이 push 알림 구현하기 – part 2 (0) | 2020.11.08 |
[Android] Firebase FCM을 사용하여 서버 없이 push 알림 구현하기 – part 1 (0) | 2020.11.08 |
[Android] SharedPreference commit과 apply (0) | 2020.11.08 |