# DroidKnights 2024
작년 "DroidKnights 2023"에 이어, "DroidKnights 2024" 컨퍼런스에도 다녀왔습니다. 🙂 이번에도 많은 안드로이드 개발자분들을 만날 수 있었습니다. 이번 컨퍼런스에서는 Compose와 관련된 주제가 많았고, 최적화 관련 주제에 대한 발표 세션도 있었습니다. 그중 들었던 세션들을 정리해보려고 합니다.
## Compose 성능 최적화를 위한 Stability 마스터 하기 - 엄재웅님
1. Jetpack Compose: Stable 버전이 발표된지 3년이 지났으며, 13만 개가 넘는 앱에서 사용되며 안정성 입증.
2. Compose 구조: Source → Compiler → Runtime → UI.
3. Compose Compiler: Jetpack Compose 내에서 중추적인 역학을 하는 핵심 구성 요소
4. 최근 변화: 4월에 Jetbrains로 코드 베이스 이동, Kotlin 2.0과 통합.
5. Compose Runtime: Gap Buffer라는 데이터 구조에서 파상된 Slot table을 사용해서 상태 저장
6. Smart Recomposition, Strong Skipping Mode, Stability Configuration File 등으로 성능 향상.
7. Recomposition은 State나 매개변수 변경 시 발생.
8. Stable 타입: 원시 타입, 불변 data class, @Stable, @Immutable.
9. Unstable 타입: 추상 클래스, List, Map.
10. 주요 어노테이션: @Immutable, @Stable, @NonRestartableComposable로 안정성 관리.
## 앱 성능 영혼까지 끌어올리기 - 배필주님
1. Crash 발생률이 가장 낮은 앱과 가장 높은 앱의 이용자 사용 시간 차이가 대략 2분정도 차이가 남.
2. 성능 관리 핵심 요소: 응답성, 안전성, 효율성.
3. 안전성: 크래시 발생 위치 및 원인 분석.
4. 기기 특성: 네트워크, 국가, 기기 사양 등 파악.
5. 응답성: 앱 시작 시간, UI 반응 속도.
6. 효율성: CPU, 메모리, 배터리 상태 모니터링.
7. Firebase Performance Monitoring: 자동 추적, 커스텀 트레이스를 통해서 상태를 확인
8. 개선 사례: 앱 시작 시간 최적화, Baseline Profile 적용.
9. 결과: CPU 부하 감소, 진입 속도 23~25% 개선.
## Compose UI 컴포넌트 설계와 테스트 - 김수현님
1. 컴포넌트 설계 기준: 재사용 가능성, 테스트 가능성, 단일 책임, 변경에 유연함.
2. 화면 단위 구현 vs 컴포넌트 단위 구현: 컴포넌트 단위가 변경사항 전파에 유리.
3. 선언형 UI: React, Flutter, SwiftUI, Jetpack Compose
4. 재사용성: 비즈니스 확장과 변경을 고려한 설계.
5. 중복 코드: 외관상 중복된 코드라도 수정의 이유가 다르면 실제로는 중복이 아니다.
6. Stateful vs Stateless: Stateful은 상태를 공유하거나 재사용하기 어려움 따라서 State Hoisting을 통해 상태와 UI를 분리.
7. 컴포넌트 테스트: Contract 분석, 의미 있는 단위로 쪼개어 테스트.
8. Screenshot Testing: 다양한 해상도에서 시각적 검증.
9. UI 테스트 도구 : Compose UI Testing, Compose Preview, Screenshot Test.
10. 테스트 코드: 기능 검증과 함께 실질적인 문서 역할.
## Github Actions로 효율적인 배포 환경 만들기 - 김태성님
1. 자동화 필요성: 테스트 누락, 코드 스타일, 수동 배포 등의 문제점 개선을 위해 Github Actions 활용.
2. SDLC(Software Development Lifecycle): 소프트웨어 개발 생명 주기를 분석, 설계, 구현, 테스트, 배포 단계로 구성하여 자동화.
3. 구현: 정적 분석 검사, 유닛 테스트, 빌드 테스트를 자동화하여 개발 생산성과 코드 품질을 향상.
4. 테스트: 데일리 앱 및 기능 테스트를 자동 배포하여 QA 테스트 용이성 증대.
5. 배포: 마일스톤 생성과 릴리즈 브랜치 자동 생성을 통해 배포 과정의 투명성과 신속성을 높임.
6. 자동화 프로세스: PR 리뷰에서의 코멘트, Firebase App Distribution을 활용한 QA 자동화 등으로 효율적인 배포 환경 구축.
7. 배포 시 Lint 검사: Lint 검사를 통해 글로벌 서비스에서의 미번역 문구 노출 이슈 발생 제거
8. 릴리즈 노트: 변경 사항 추적과 규격화된 포맷을 통한 팀 간 협업 향상.
## 당신의 앱 빌드는 안녕하십니까? - 차용호님
1. 개발자의 단위 작업에 걸리는 시간 : (수정시간 + 빌드시간) * 반복횟수
2. 수정시간은 개발자 개인의 생산성에 의존
3. Build Requirement Checker, Repository Content Filtering, 외부 의존성 Mirroring 을 사용해서 빌드 안전성 개선
4. Build Requirement Checker : 빌드에 필수적인 항목이 제대로 구성되어 있는지 검사
5. Incremental Build(증분 빌드) : 변경된 부부관 그 영향을 받는 부분만 다시 빌드하고, 나머지 부분은 재활용
6. BuildConfig : BuildConfig의 사용으로 인해 빌드 성능에 큰 영향을 끼칠 수 있음. valueOf() 로 감싸면 inline 최적화가 방지됨 (Debug에서는 느릴 수 있음)
7. Gradle Build Cache : 이전 빌드의 결과물을 재사용
8. Remote Gradle Build Cache를 사용해서 로컬이 아닌 Remote에서 사용 가능
9. Gradle 빌드캐시는 다양한 이유로 오염되기 쉬움 → 해결 방안으로 Android Gradle Cache Fix plugin을 사용 또는 incremental = false 하여 해결 → 문제가 있을 경우 끌 수는 있지만 빌드 성능 저하가 발생할 수 있음
10. JVM Option 에서 Parallel GC 설정 및 Heap Size 증가를 통해서 빌드 속도를 증가시킬 수 있음
## Compose Material3 커스텀 디자인 시스템 구축기 - 권대원님
1. 디자인 시스템의 목적: 개발과 디자인을 효율적으로 연결하여 빠르고 일관된 프로덕트 개발을 지원하는 라이브러리 시스템
2. 시간 절약: 레거시 코드 파악 시간을 줄이며 작업자들이 직접적인 개발에 집중
3. 사용자 경험 향상: 일관된 UI 개발을 통해 좋은 사용자 경험을 제공
4. Jetpack Compose 선택: 100% Jetpack Compose 기반으로 UI와 비즈니스 로직을 분리하고 컴포넌트 단위로 개발
5. KPDS(Kurly product design system) 구조: foundation/layout에 의존하며, 기본적인 구성 요소로는 Color, Typography, Icon 등이 있음.
6. 디자인 토큰 사용: 색상, 글꼴, 치수와 같은 디자인 속성을 하드코딩 대신 토큰을 사용하여 통일성과 수정 용이성을 제공
7. Color Token: 다크테마나 레이아웃에 따라 다른 값을 가리키며, 의미론적인 이름으로 사용 목적을 정의
8. 컴포넌트 개발: Figma를 기반으로 사용하기 쉬운 컴포넌트를 개발하고 이를 효율적으로 관리
9. 트러블 슈팅: 하위 스코프에서 상태를 읽고 Compose 람다식을 최적화하여 재사용
10. KPDS 방향성: 디자인과 개발 코드의 통합, 아토믹 디자인 원칙을 따르며 변화에 유연하게 대응할 수 있는 구조를 목표
이번 컨퍼런스를 통해 최적화할 수 있는 부분을 고민해보고, 그 내용을 기반으로 실제로 적용해보려고 합니다. 😃
