[FEAT] BaselineProfile 적용 #269
Conversation
WalkthroughBaselineProfile 모듈을 신규 추가하고 앱의 릴리스 빌드에서 코드/리소스 축소를 활성화했으며 Firebase 및 Play Services 의존성을 추가하고 일부 Firebase KTX 사용을 표준 라이브러리로 전환하고 Gradle/버전 카탈로그를 갱신했습니다. Changes
Sequence Diagram(s)sequenceDiagram
participant Test as StartupBenchmarks\n(Test)
participant MacroRule as MacrobenchmarkRule
participant Profile as BaselineProfileRule\n(Generator)
participant TargetApp as Target App
Note over Test,TargetApp: 측정: COLD 스타트 (10회)
Test->>MacroRule: measureRepeated(StartupTimingMetric, iterations=10)
MacroRule->>TargetApp: startActivityAndWait()
TargetApp->>TargetApp: 앱 실행 및 타이밍 측정
MacroRule->>MacroRule: 기록 및 반복
Note over Test,Profile: 프로파일 생성 흐름
Test->>Profile: generate()
Profile->>TargetApp: launchDefaultActivity()
Profile->>Profile: 수집 및 baseline 프로파일 출력
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Pre-merge checks and finishing touches❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (5)
app/proguard-rules.pro (1)
3-4: ProGuard keep 규칙이 너무 광범위합니다.
-keep class com.google.android.gms.** { *; }와-keep class com.google.firebase.** { *; }규칙은 모든 Google Play Services 및 Firebase 클래스를 보존합니다. 이는 APK 크기를 불필요하게 증가시키고 난독화의 이점을 감소시킬 수 있습니다.실제로 사용하는 특정 클래스나 Firebase 컴포넌트에 대해서만 선택적으로 keep 규칙을 적용하는 것을 권장합니다. Firebase의 경우 대부분 자체 ProGuard 규칙을 제공하므로 추가 규칙이 필요하지 않을 수 있습니다.
baselineprofile/src/main/java/com/dongchyeon/baselineprofile/StartupBenchmarks.kt (2)
53-54: 예외 타입을 더 구체적으로 지정하는 것을 고려하세요.현재 제네릭
Exception을 던지고 있습니다.IllegalArgumentException또는IllegalStateException과 같이 더 구체적인 예외 타입을 사용하면 예외 처리가 명확해집니다.- ?: throw Exception("targetAppId not passed as instrumentation runner arg"), + ?: throw IllegalArgumentException("targetAppId not passed as instrumentation runner arg"),
65-72: TODO: 추가 UI 인터랙션을 구현하여 BaselineProfile 커버리지를 확장하세요.현재는 기본 앱 시작만 프로파일링하고 있습니다. 주요 사용자 여정(예: 콘텐츠 로딩 대기, 스크롤, 상세 화면 이동)을 추가하면 BaselineProfile의 효과를 더욱 향상시킬 수 있습니다.
이러한 인터랙션 구현을 도와드릴까요? 또는 추적을 위한 별도 이슈를 생성해드릴까요?
baselineprofile/src/main/java/com/dongchyeon/baselineprofile/BaselineProfileGenerator.kt (2)
45-46: 예외 타입을 더 구체적으로 지정하는 것을 고려하세요.현재 제네릭
Exception을 던지고 있습니다.IllegalArgumentException또는IllegalStateException과 같이 더 구체적인 예외 타입을 사용하면 예외 처리가 명확해집니다.- ?: throw Exception("targetAppId not passed as instrumentation runner arg"), + ?: throw IllegalArgumentException("targetAppId not passed as instrumentation runner arg"),
58-62: TODO: 주요 사용자 여정을 추가하여 BaselineProfile을 확장하세요.현재는 기본 앱 시작만 포함되어 있습니다. 앱의 핵심 기능과 가장 자주 사용되는 화면으로의 내비게이션을 추가하면 BaselineProfile의 효과가 크게 향상됩니다.
예시:
- 비동기 콘텐츠 로딩 완료 대기
- 피드 스크롤
- 상세 화면으로 이동
- 주요 기능 실행
이러한 사용자 여정 구현을 도와드릴까요? 또는 추적을 위한 별도 이슈를 생성해드릴까요?
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (12)
app/build.gradle.kts(3 hunks)app/proguard-rules.pro(1 hunks)baselineprofile/.gitignore(1 hunks)baselineprofile/build.gradle.kts(1 hunks)baselineprofile/src/main/AndroidManifest.xml(1 hunks)baselineprofile/src/main/java/com/dongchyeon/baselineprofile/BaselineProfileGenerator.kt(1 hunks)baselineprofile/src/main/java/com/dongchyeon/baselineprofile/StartupBenchmarks.kt(1 hunks)build.gradle.kts(1 hunks)core/remoteconfig/src/main/java/com/yapp/remoteconfig/di/RemoteConfigModule.kt(1 hunks)gradle.properties(2 hunks)gradle/libs.versions.toml(6 hunks)settings.gradle.kts(2 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (20)
core/remoteconfig/src/main/java/com/yapp/remoteconfig/di/RemoteConfigModule.kt (1)
3-6: KTX에서 non-ktx로의 마이그레이션이 올바르게 적용되었습니다.Firebase는 2025년 7월에 KTX 모듈의 새 버전 배포를 중단하고 Firebase Android BoM에서 KTX 라이브러리를 제거했으며, Kotlin 확장 API가 각각의 메인 모듈에 추가되어 Kotlin 개발자가 메인 모듈에만 의존할 수 있게 되었습니다. Firebase는 앱을 메인 모듈의 KTX API로 마이그레이션하여 지속적으로 업데이트를 받고 새로운 기능을 활용하도록 권장합니다.
현재 코드의
Firebase.remoteConfig와remoteConfigSettingsDSL 구문은 non-ktx 버전에서도 동일하게 작동합니다. 이 마이그레이션은 의존성 버전 정렬 문제를 해결하면서 장기적인 유지보수성을 개선합니다.baselineprofile/src/main/AndroidManifest.xml (1)
1-1: LGTM!BaselineProfile 모듈에 필요한 최소한의 매니페스트 구성입니다.
baselineprofile/.gitignore (1)
1-1: LGTM!표준 빌드 출력 디렉토리 무시 규칙입니다.
app/proguard-rules.pro (2)
1-2: LGTM!디버깅을 위한 소스 파일 정보와 라인 번호 보존 규칙이 적절합니다.
6-7: LGTM!Kotlin 메타데이터와 어노테이션 보존 규칙이 적절합니다.
settings.gradle.kts (2)
7-7: LGTM!Google 리포지토리 선언을 간결한 형태로 개선했습니다.
44-44: LGTM!BaselineProfile 모듈이 프로젝트에 올바르게 추가되었습니다.
gradle.properties (2)
9-9: JVM 메모리 설정 증가를 팀과 확인하세요.힙 메모리를 6GB로, Metaspace를 1GB로 증가시켰습니다. BaselineProfile 생성에는 적절한 설정이지만, 개발 환경에 따라 일부 머신에서는 과도할 수 있습니다. 팀원들의 로컬 개발 환경에서 문제가 없는지 확인하세요.
24-25: LGTM!Configuration cache와 병렬 실행 활성화는 빌드 성능 향상에 도움이 됩니다.
baselineprofile/src/main/java/com/dongchyeon/baselineprofile/StartupBenchmarks.kt (2)
35-48: LGTM!벤치마크 테스트 구조가 표준적이며 올바릅니다.
CompilationMode.None()과CompilationMode.Partial(BaselineProfileMode.Require)를 비교하여 BaselineProfile의 효과를 측정하는 접근 방식이 적절합니다.
50-64: LGTM!벤치마크 설정이 적절합니다.
COLD시작 모드와 10회 반복은 시작 성능 측정에 합리적인 구성입니다.build.gradle.kts (1)
17-18: LGTM!BaselineProfile을 위한 플러그인 별칭이 올바르게 추가되었습니다.
apply false를 사용하여 루트 레벨에서는 적용하지 않고 필요한 모듈에서만 적용할 수 있도록 구성했습니다.baselineprofile/src/main/java/com/dongchyeon/baselineprofile/BaselineProfileGenerator.kt (1)
34-56: LGTM!BaselineProfile 생성기가 표준 방식으로 구현되었습니다.
includeInStartupProfile = true설정은 DEX 레이아웃 최적화에 적합합니다.app/build.gradle.kts (3)
1-9: 플러그인 중복 적용 확인 필요
id("orbit.android.application")(라인 2)와alias(libs.plugins.android.application)(라인 7)이 동일한 Android application 플러그인을 적용하는 것처럼 보입니다. 일반적으로 컨벤션 플러그인이 기본 플러그인을 감싸기 때문에, 둘 다 적용하면 중복되거나 충돌할 수 있습니다. 빌드가 정상적으로 동작하는지, 그리고 한 쪽의 적용만 필요한지 확인해 주시기 바랍니다.
29-34: 릴리스 빌드 최적화 설정 승인릴리스 빌드 타입에 코드 축소(
isMinifyEnabled = true)와 리소스 축소(isShrinkResources = true)를 적절히 활성화했습니다. BaselineProfile과 함께 이러한 최적화는 앱의 성능을 크게 개선하고 시작 시간을 단축합니다.
57-69: Firebase KTX에서 표준 라이브러리로 마이그레이션 확인 필요Firebase 라이브러리를 KTX 버전에서 표준 버전(firebase-analytics, firebase-crashlytics 등)으로 전환했습니다. Firebase BoM v34.0.0부터 KTX 모듈이 제거되었으므로, 이러한 변경이 필요합니다. 그러나 소스 코드에서
com.google.firebase.analytics.ktx같은 KTX 임포트를 사용 중이라면, 이를 표준 모듈 임포트(com.google.firebase.analytics)로 업데이트해야 합니다.소스 코드의 Firebase 임포트문을 KTX에서 표준 라이브러리로 마이그레이션했는지 확인해 주시기 바랍니다.
baselineprofile/build.gradle.kts (1)
1-66: BaselineProfile 모듈 구성 우수BaselineProfile 모듈 구성이 공식 Android 문서를 완벽하게 따릅니다. 플러그인 순서, 관리형 디바이스(Pixel 6 API 34) 설정, 그리고 targetProjectPath 구성이 모두 권장 사항과 일치합니다. 테스트 의존성도 매크로벤치마크 시나리오 작성에 필요한 UIAutomator 및 벤치마크 라이브러리를 포함하고 있습니다.
profileinstaller 라이브러리를 통해 로컬에서 생성된 BaselineProfile을 컴파일하고 검증할 수 있으며, 앱의 build.gradle.kts에서도 올바르게 종속성으로 추가되었습니다.
gradle/libs.versions.toml (3)
33-33: 버전 카탈로그 업데이트 승인Firebase BoM을 34.4.0으로 업데이트하고, BaselineProfile 관련 라이브러리들(uiautomator, benchmarkMacroJunit4, profileinstaller, baselineprofile)을 추가했습니다. 모든 버전이 현재 기준으로 적절하며 상호호환성이 검증된 조합입니다.
Also applies to: 57-59, 81-84
155-157: Firebase KTX에서 표준 라이브러리로 마이그레이션Firebase BoM v34.0.0부터 KTX 라이브러리가 제거되었으므로, firebase-analytics, firebase-crashlytics, firebase-config를 표준 라이브러리로 전환한 것이 올바른 접근입니다. 이들 라이브러리는 BOM에서 버전을 관리하므로 version.ref 없이 선언합니다.
새로 추가된 라이브러리(uiautomator, benchmark-macro-junit4, profileinstaller)도 적절하게 버전화되어 있습니다.
주의: 애플리케이션 소스 코드에서 기존 KTX 임포트(
firebase-analytics-ktx,firebase-crashlytics-ktx등)를 사용 중이라면, 이를 표준 모듈로 업데이트해야 합니다.Also applies to: 185-187
205-205: BaselineProfile 플러그인 카탈로그 항목 승인BaselineProfile 플러그인을 버전 카탈로그에 올바르게 추가했습니다. 이를 통해 모듈의 build.gradle.kts에서
alias(libs.plugins.baselineprofile)로 편리하게 참조할 수 있습니다.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
AGENTS.md (1)
1-21: 우수한 저장소 가이드라인 문서입니다.새로운 팀원들과 컨트리뷰터들을 위한 명확한 저장소 규약을 정의한 좋은 추가입니다. 문서 구조가 잘 짜여있고 액션 가능한 지침들이 포함되어 있습니다.
다음과 같은 선택적 개선사항을 고려해보실 수 있습니다:
Build 섹션에서 baselineprofile 관련 명령어 추가 (Line 6-11): 이 PR에서 BaselineProfile 모듈이 추가되었으므로, 다음과 같은 명령어를 추가하면 도움이 될 것 같습니다:
- `./gradlew :baselineprofile:measureRelease` – Run baseline profile generationTesting Guidelines에서 구체적인 예시 강화 (Line 16-17): "happy-path and primary failure cases"에 대해 구체적인 예시를 한두 개 추가하면 더욱 이해하기 쉬울 것 같습니다.
모듈 구조 섹션에서 baselineprofile 모듈 언급 (Line 4): 신규 추가된 baselineprofile 모듈을 모듈 조직 설명에 포함시키면 좋을 것 같습니다.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/android_ci.yml(1 hunks)AGENTS.md(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-07-16T14:32:09.264Z
Learnt from: DongChyeon
Repo: YAPP-Github/Orbit-Android PR: 233
File: domain/src/main/java/com/yapp/domain/usecase/AlarmUseCase.kt:38-61
Timestamp: 2025-07-16T14:32:09.264Z
Learning: In the Orbit-Android project, the team prefers to focus unit testing on core business logic rather than UseCase wrapper methods to avoid unnecessary dependency mocking costs. They consider it sufficient to test the main formatting logic (like formatTimeDifference) rather than testing thin wrapper methods in UseCases.
Applied to files:
AGENTS.md
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (1)
.github/workflows/android_ci.yml (1)
86-86: 설정 캐시 비활성화의 근거 및 영향 확인 필요.
--no-configuration-cache플래그 추가는 PR에서 언급된 io.grpc.InternalGlobalInterceptors 오류의 임시 해결책으로 보입니다. 그러나 다음 사항을 확인해야 합니다:
- 이 플래그가 필수적인 해결책인지, 아니면 라이브러리 버전 정렬 후 여전히 필요한지
- 설정 캐시 비활성화로 인한 CI/CD 성능 영향
- 이 변경사항이 단위 테스트와 계측 테스트 모두에 영향을 미치는지 (PR 설명에서는 계측 테스트 언급)
다음 중 하나를 수행해주세요:
- 이 플래그가 필요한 이유와 대체 해결책이 있는지 설명
- 또는, gradle.properties의 기본 설정 캐시 활성화와의 상호작용을 문서화하는 인라인 코멘트 추가
Related issue 🛠
closed #268
어떤 변경사항이 있었나요?
CheckPoint ✅
PR이 다음 요구 사항을 충족하는지 확인하세요.
Work Description ✏️
Uncompleted Tasks 😅
To Reviewers 📢
Summary by CodeRabbit
새로운 기능
성능 개선
문서