| Key concepts | Set up your development environment | Build an RE SDK | Consume the RE SDK | Testing, and building for distribution |
주요 개념
이 섹션에서는 SDK 런타임 아키텍처, 런타임 지원 SDK 설치 방법, 이전 버전과의 호환성, 기존 SDK를 SDK 런타임으로 이전하는 방법을 설명합니다.
용어 설명
- 런타임 지원 SDK (RE SDK): SDK 런타임 환경에서 실행되고 프로세스 간 통신(IPC)을 통해 앱과 통신하도록 만들어진 SDK입니다.
- 런타임 인식 SDK (RA SDK): 런타임 지원이 아닌 SDK로, 앱에 정적으로 연결되며 기존 SDK 코드와 런타임 지원 SDK를 호출하는 새 코드가 포함될 수 있습니다.
- 이를 정적으로 연결된 또는 정적 SDK라고도 합니다.
- Shim: 프로세스 간 또는 프로세스 간 통신 (IPC)을 추상화하고 동일한 앱-SDK 인터페이스를 유지하는 데 도움이 되는 Jetpack 라이브러리입니다.
SDK 런타임 아키텍처
SDK 런타임은 클라이언트-서버 유형의 모델을 채택합니다.
주요 차이점은 '클라이언트' (앱)와 '서버' (런타임 지원 SDK)가 동일한 기기에서 실행되며 이 통신은 프로세스 간에 발생한다는 점입니다.
이러한 문제를 해결하기 위해 Google에서는 SDK 런타임 내에서 앱-SDK 통합을 간소화하는 다음 Jetpack 라이브러리 및 도구를 빌드했습니다.
- 심 라이브러리: 래퍼 라이브러리 (또는 심)는 프로세스 간 통신 또는 프로세스 간 통신 (IPC)을 추상화하는 데 도움이 됩니다. 또한 동일한 앱-SDK 인터페이스를 유지하는 데도 도움이 됩니다.
- 호환성 라이브러리: 이 라이브러리는 이전 버전과의 호환성을 처리하여 SDK 런타임의 사용 가능 여부와 관계없이 SDK가 호환되도록 합니다.
- UI 라이브러리: 런타임 지원 SDK에서 UI를 가져오거나 뷰의 크기를 조절하고 레이아웃을 다시 지정하는 등 원격 프레젠테이션을 처리하는 라이브러리도 제공합니다.
설치 흐름 변경사항
Android 스튜디오나 기타 도구에서 런타임 지원 SDK를 빌드하면 런타임 지원 SDK의 게시 형식인 Android SDK 번들(ASB)이 생성됩니다.
bundletool은 ASB를 처리하여 런타임 지원 SDK용 APK를 생성합니다. 이 별도의 APK에는 SDK 코드는 포함되지만 앱 코드는 포함되지 않습니다.
앱의 매니페스트 파일은 런타임 지원 SDK 이름과 버전에 대한 종속 항목을 선언하며 이 종속 항목은 설치 프로그램 앱에 의해 해결됩니다.
설치 프로그램에서 SDK APK를 가져오면 SDK APK 설치로 설치가 시작됩니다. 성공하면 앱의 APK를 설치합니다.
앱이 Android 13 이하에 설치된 경우와 SDK 런타임을 지원하지 않는 기기에서는 흐름이 다릅니다. 이 시나리오에서 스토어는 런타임 지원 SDK와 앱 코드가 모두 포함된 단일 APK를 설치합니다. 자세한 내용은 배포 섹션을 참고하세요.
앱이 프로덕션에서 이 SDK에 종속될 때마다 앱 스토어는 이 ASB에서 올바른 SDK APK를 만들어 설치합니다.
이전 버전과의 호환성
SDK 런타임은 Android 14에서 도입되었으므로 SDK 또는 앱 개발자에게 오버헤드를 도입하지 않고 이전 버전을 지원해야 했습니다.
Android 13 이하에서 이전 버전과의 호환성을 처리하기 위해 SDK 런타임의 기기 지원 여부와 관계없이 런타임 지원 SDK를 원활하게 실행할 수 있는 Jetpack 라이브러리가 도입되었습니다.
이 가이드를 따르면 런타임 지원 SDK가 기본적으로 이전 버전과 호환되므로 추가로 취해야 할 단계가 없습니다.
관련 단계에서 하위 호환성과 관련된 조치를 강조 표시하지만 일반적으로 올바른 종속 항목을 선언하고 해당하는 경우 *Compat 클래스를 사용해야 합니다.
기존 SDK 마이그레이션
런타임으로 이전하려는 기존 SDK가 있는 경우 전체 코드베이스를 한 번에 리팩터링하지 않아도 됩니다. 대신 기존 SDK 로직을 새 런타임 지원 SDK로 점진적으로 이전할 수 있습니다.
기존 SDK를 SDK 런타임으로 이전하려면 다음 세 단계를 따르는 것이 좋습니다.
- 대응하는 두꺼운 런타임 인식 SDK와 함께 전환 기간 런타임 지원 SDK를 빌드합니다. 이를 통해 기존 SDK에서 비즈니스 로직을 점진적으로 이전하고 A/B 테스트를 위한 테스트 플랫폼을 제공할 수 있습니다.
- 앱 이전을 용이하게 하기 위해 기존 SDK 비즈니스 로직을 모두 안정적인 상태로 이동하고 대응하는 씬 런타임 인식 SDK를 사용
- 관심 있는 앱이 완전한 이전을 통해 씬 런타임 인식 SDK 없이 런타임 지원 SDK를 직접 사용할 수 있도록 지원
1단계 - 전환 기간: 두꺼운 런타임 인식 SDK
런타임 인식 SDK에 일부 비즈니스 로직을 유지하도록 선택하여 시작할 수 있습니다. 이를 두꺼운 런타임 인식 SDK 또는 인앱 래퍼라고 합니다.
이 방법을 사용하면 새로 빌드된 런타임 지원 SDK와 함께 SDK의 기능을 전부 또는 일부를 정적 앱 라이브러리에 유지할 수 있습니다.
이를 통해 사용 사례를 런타임 지원 SDK로 점진적으로 이전하고 기존 SDK에 대해 런타임 지원 SDK를 테스트할 수 있습니다.
이 단계에서는 앱 개발자가 SDK를 사용하는 방식을 변경할 필요가 없습니다. 런타임 인식 SDK를 사용하는 데 필요한 작업을 실행하는 것은 정적 앱 라이브러리 (런타임 인식 SDK)이기 때문입니다.
2단계 - 정상 상태: 씬 런타임 인식 SDK
두꺼운 런타임 인식 SDK와 달리 얇은 래퍼 또는 얇은 런타임 인식 SDK(얇은 RA_SDK)에는 정적으로 연결된 라이브러리 SDK에 API 변환 및 런타임 지원 SDK 호출 코드만 포함됩니다.
이 단계에서는 모든 SDK 코드를 정적 앱 라이브러리 SDK에서 런타임 지원 SDK로 이전해야 합니다.
앱 개발자는 1단계에서 변경할 필요가 없습니다. 인앱 씬 런타임 인식 SDK가 SDK 런타임 내에서 런타임 지원 SDK를 호출하기 때문입니다.
3단계 - 전체 이전
이 마지막 단계에서는 SDK의 모든 기능을 런타임 지원 SDK로 이전하고 앱에서 모든 정적 라이브러리를 삭제했습니다.
이 시점에서 앱 클라이언트는 빌드에 라이브러리를 더 이상 포함할 필요가 없으며 매니페스트에 SDK 종속 항목만 나열하고 앱 코드에 SDK 호출을 포함하면 됩니다.
SDK 호출은 시스템에 의해 SDK 런타임으로 라우팅되며, 여기서 런타임 지원 SDK가 자동으로 로드됩니다.
