| 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라고도 합니다.
- 시임: 프로세스 간 통신 또는 프로세스 간 통신 (IPC)을 추상화하고 동일한 앱-SDK 인터페이스를 유지하는 데 도움이 되는 Jetpack 라이브러리입니다.
SDK 런타임 아키텍처
SDK 런타임은 클라이언트-서버 유형의 모델을 채택합니다.
주요 차이점은 '클라이언트' (앱)와 '서버' (런타임 지원 SDK)가 동일한 기기에서 실행되며 이 커뮤니케이션이 프로세스 간에 발생한다는 점입니다.
이러한 문제를 해결하기 위해 SDK 런타임 내에서 앱-SDK 통합을 간소화하는 다음과 같은 Jetpack 라이브러리와 도구를 빌드했습니다.
- 시임 라이브러리: 래퍼 라이브러리 (또는 시임)는 프로세스 간 통신 또는 프로세스 간 통신 (IPC)을 추상화하는 데 도움이 됩니다. 또한 동일한 앱-SDK 인터페이스를 유지하는 데 도움이 됩니다.
- Backcompat 라이브러리: 이 라이브러리는 이전 버전과의 호환성을 처리하여 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로 이전해야 합니다.
인앱 씬 런타임 인식 SDK가 SDK 런타임 내에서 런타임 지원 SDK 호출을 처리하므로 앱 개발자는 1단계에서 변경할 필요가 없습니다.
3단계 - 전체 이전
이 마지막 단계에서 모든 SDK 기능을 런타임 지원 SDK로 이전하고 앱에서 모든 정적 라이브러리를 삭제했습니다.
이 시점에서 앱 클라이언트는 더 이상 빌드에 라이브러리를 포함할 필요가 없으며 매니페스트에 SDK 종속 항목만 나열하고 앱 코드에 SDK 호출을 포함하면 됩니다.
SDK 호출은 시스템을 통해 SDK 런타임으로 라우팅되며 여기서 런타임 지원 SDK가 자동으로 로드됩니다.
