런처에서 사용한 Downloadable Application 통한 플랫폼화 기술

이번 포스팅에서는 런처플래닛에 대해 소개하고 런처에서 사용한 Downloadable Application 통한 플랫폼화 기술에 대해 알려드리려고 합니다.

그럼 먼저 런처플래닛 동영상 보고 갈게요~ ^^

런처플래닛은 국내 최초로 초기화면을 오른쪽으로 넘기면 페이스북, 네이트 판·이슈업, 날씨, 전화·문자 등 즐겨 찾는 앱들을 편리하게 이용할 수 있는 ‘서비스카드’ 기능을 추가해 편의성을 극대화 한 새로운 모바일 홈입니다.

서비스카드란 수 많은 앱들 중에 자주 이용하는 핵심 기능만을 대기화면에 배치한 뒤 단순한 화면 넘김을 통해 빠른 실행이 가능하게 한 기능으로 심플하고 다이나믹한 모션 유저 인터페이스(UI)를 제공합니다.

스마트폰 초기화면 꾸미기 서비스로, 작년  7월 베타버전을 선보인 이후부터 직관적이고 효율적 화면구성과 다양한 인기테마, 편리한 앱 관리 도구 등으로 사용자들에게 큰 호응을 얻어 왔고, 지난 12월에는 100만 다운로드를 돌파하기도 했습니다.

런처플래닛은 직관적이고 편리한 화면 구성을 통해 빠르고 안정적인 구동 속도를 제공하며, 라바, 헬로키티, 몰랑 등 다양한 인기 캐릭터 테마들의 적용과 효율적인 앱 관리 도구인 런처바, 폴더관리 기능을 탑재해 자신만의 스마트폰 관리 기능을 강화했습니다.

런처플래닛은 안드로이드OS 4.0.2 이상이 설치된 스마트폰 사용자라면 T스토어 및 구글 플레이스토어를 통해 무료로 다운받아 설치 가능하며 테마 변경은 원하는 아이템을 다운 받아 적용하면 됩니다.

안드로이드 어플리케이션을 개발하다 보면,  단순 어플리케이션을 넘어 플랫폼화된 어플리케이션을 제공하여, 서비스의 활용을 극대화 하고자 할 때가 있습니다. 예를 들어 카카오톡의 경우 단순 메시징 어플리케이션을 넘어 게임과의 결합으로 사용자의 서비스 활용을 극대화 하고 있습니다. 이에 런처에서 사용한 Downloadable Application 통한 플랫폼화 기술을  소개 하려고 합니다.

Downloadable Application 플랫폼화에 필요한 구조

Downloadable Application을  플랫폼화 하기 위해서는 Downloadable Application을 관리하는 스토어 서버 및 Downloadable Application을 로딩하는 Platform Application (런처플래닛),  Third-party에서 개발이 가능한 SDK 가 필요합니다. 우선 Downloadable Application을 관리하는 스토어 서버를 설명하겠습니다.

Downloadable Application 스토어 서버

Downloadable Application 스토어 서버는 Tomcat + Spring 기반으로 Downloadable Application 목록을 단말이 요청하면 JSON 포맷으로 전달하는 기능이 포함되어 있습니다. 이 밖에도 Downloadable Application 목록을 관리하기 위한 어드민 페이지가 존재하며,  어드민 페이지를 통해 현재 배포되고 있는 Downloadable Application을 추가, 삭제, 수정 등을 수행합니다.

[ 그림1. Downloadable Application 스토어 서버 연동 ]

요청으로는 단말의 종류(삼성 갤럭시 등) ,OS 버전(JellyBean, KitKat 등 ) 등이 전달되며 이에 맞는 Downloadable Application 목록을 응답으로 단말에 전달합니다. 응답 메세지에는 Downloadable Application 버전, Play Store/T Store 위치, 아이콘 이미지 URL 정보 등을 가지고 있으며, Platform Application(런처플래닛)은 이 정보를 바탕으로 Downloadable Application 신규/업데이트 여부 등을 판단하여 해당 Downloadable Application을 받을 수 있는 Play Store/T store로 연결합니다.

Platform Application(런처플래닛)

Platform Application에서는 Downloadable Application 스토어 서버와의 연동을 통해 설치된 Downloadable Application을 ACTION_PACKAGE_ADDED,  ACTION_PACKAGE_REMOVED, ACTION_PACKAGE_REPLACED Broadcasting Message를 통해 탐지하여, Downloadable Application을 로딩 및 실행 합니다.

Downloadable Application을 로딩 및 실행하기 위해서는 사전에 약속된 인터페이스가 필요하며 이 인터페이스에 따라 구현된 Downloadable Application을 ClassLoader를 통해 로딩하여야 합니다.

해당 기술을 이해하기 위해서는 우선  ClassLoader의 구조부터 살펴봐야 하겠습니다.

[ 그림2. ClassLoader 구조도 ]

위 그림은 ClassLoader가 Class를 찾고 로딩하는 순서를 나타낸 것입니다. 과정을 자세히 설명하면 아래와 같습니다.

  1. Application ClassLoader 는 현재 자신이 가지고 있는 Class Cache(이미 로딩된 Class들의 Container)를 탐색하여 찾는 Class가 없으면, System ClassLoader 에 Class 로딩 요청을 합니다.  ( 1 -> 2 과정)
  2. System ClassLoader는 Class Cache를 탐색하여 찾는 Class가 없으면, ClassPath 변수에 지정된 라이브러리에서 Class 로딩을 시도합니다. ClassPath에도 찾는 Class가 없으면 Application ClassLoader 에 Class 로딩을 요청합니다. ( 3 -> 4 과정 )
  3. Application ClassLoader는 application의 dex 파일을 읽어 Class 로딩을 시도합니다. 로딩할 Class가 존재하면 3단계( Physical Loading, Linking, Initializing )과정을 거처 Class를 로딩합니다. 존재하지 않으면 NotClassFoundException 이 발생합니다. ( 5과정 )

3단계( Physical Loading, Linking, Initializing )를 설명하면 다음과 같습니다.

  • Physical Loading는 class 파일을 읽어 메모리상에 로딩하는 부분입니다.
  • Linking은 Bytecode 무결성 검사, 로딩하는 Class에서 사용하는 변수, 메소드, 인터페이스, 관련 Class에 필요한 메모리 확보 및 레퍼런스 검사를 담당하는 부분입니다.
  • Initializing은 static 코드, static 변수를 실행 및 초기화 하는 부분입니다.

위의 사항을 정리하면 기본적으로 ClassLoader는 트리 구조를 가지며, Leap Node ClassLoader ( Application ClassLoader) 에서 Root Node ClassLoader ( System ClassLoader )로 올라가는 경우는 Class Cache에서 이미 로딩된 Class를 찾는 순서이며, 그 반대로 내려가는 경우는 dex 파일을 읽어 실제로 Class 로딩하는 부분에 해당합니다.

위의 구조에서 Downloadable Application 플랫폼화 기술을 구현하기 위해 Platform Application ClassLoader의 자식 ClassLoader가 DownLoadable Application ClassLoader이 되도록 구성 합니다(그림3).  이러한 구성으로 Platform Application ClassLoader에 인터페이스 클래스가 위치에 있고, 이를 구현한 Downloadable Application을 Downloadable Application ClassLoader에서 가지고 있는 구성으로 이루어져야 Third-party SDK 배포에 포함된 Downloadable 인터페이스 라이브러리를 사용하여 Downloadable Application 개발이 가능해 집니다.

[ 그림3.  Downloadable Application  개발에 필요한 ClassLoader 구조도]

또한  Android APK의 리소스(이미지, 화면레이아웃) 로딩 또한 중요한 부분이므로  이 부분의 해결 방안이 필요합니다. Context의 createPackageContext를 사용하여 Downloadable Application의 Android Context를 생성할 수 있으며, inflatLayout 또는 getResource 통해 Android APK 리소스에 접근이 가능합니다. 문제는 이렇게 생성된 Context 의 ClassLoader가 위의 구조를 따라가지 않는다는 것입니다(그림 4). 즉 그림4. 에 제시된 구조를 그림3.과 같이 변경하여야 합니다.

[그림4. createPackageContext로 생성된 ClassLoader 구조도 ]

이 부분을 해결하기 위해 다음에 설명할 Java Reflection 기술을 이용한 Context의 ClassLoader 변경입니다.

Java Reflection 기술을 이용한 Context ClassLoader 변경

Java Reflection 기술은 Java VM에 로딩된 객체를 클래스의 정의가 없어도 변수, 메소드를 변경 및 호출을 가능하도록 하는 기술입니다. 위에 설명된 ClassLoader 구조를 구현하기 위해 Context 객체의 mPackageInfo.mClassLoader를 Downloadable Application을 로딩한 ClassLoader로 교체합니다.

Context packageContext = mContext.createPackageContext( ... ) Class<?> packageContextClass = (Class<?>)packageContext.getClass();
Field packageContextClassField = packageContextClass.getDeclaredField("mPackageInfo");
packageContextClassField.setAccessible(true);
Object packageContextClassFieldObj = packageContextClassField.get(packageContext);
Class<?> packInfoClass = packageContextClassFieldObj.getClass();
Field packInfoClassField = packInfoClass.getDeclaredField("mClassLoader");
packInfoClassField.setAccessible(true);
packInfoClassField.set(packageContextClassFieldObj, newClassLoader);

Android Classloader의 한계점

Android ClassLoader는 한 번 로딩된 Class에 대해서 upload 기능을 제공하고 있지 않습니다. 이러한 제한으로 Downloadable Application을 update 할 경우 기존의 Downloadable Application ClassLoader에 의해 로딩된 Class와의 충돌을 피할 수 없으며, Application 을 다시 시작할 수 밖에 없습니다.

Third-party SDK  구성

Platform Application(런처플래닛)에서 구동되는 Downloadable Application을 개발하기 위해 제공되는 SDK에는 Downloadable Framework Library 와  Downloadable Application Viewer, Downloadable Application 개발 가이드, Sample Downloadable Application이 있습니다.

Downloadable Framework Library는 Third-party 개발사에서 Downloadable Application을 개발 시에 구현해야 하는 인터페이스 라이브러리이며, Downloadable Framework Library를 구현한 Downloadable Application은 Downloadable Application Viewer를 통해 간단하게 테스트를 수행 할 수 있습니다. Downloadable Application 개발 가이드에는 이러한 개발 방법에 대해 설명이 되어 있으며, Sample Downloadable Application을 참조하여 개발을 진행합니다.

이러한 Third-party SDK를 배포함으로써 개발/테스트를 Third Party에서 자체 진행할 수 있으며, 개발 완료 시 런처플래닛과 협의하여 QA 진행 및 Downloadable Application 배포를 진행합니다.

KitKat의 ART 적용 시 문제점 발생 여지 검토

KitKat 이전 기존의 Android에서 JIT compiler로 Bytecode 를 Machine code로 런타임 시에 변환을 하기 때문에 Application 실행 및 구동에 지연이 발생할 수 있습니다. 이러한 이유로 KitKat의 ART 는 Bytecode to Machine code 전환을 어플리케이션 설치 시에 지원함으로써 실행 및 구동을 좀더 빠르게 할 수 있습니다.  기본적으로 위에 제시되는 Downloadable Application 개발은 Java단에서 수행하므로 KitKat의 ART와의 문제는 발생하지 않습니다. (LG G pro에서 ART로 설정하여 테스트하여 문제없음을 확인하였습니다. )

맺음말

앞으로 안드로이드 분야에서 자사 플랫폼을 쉽게 이식시키고, SDK를 제공하여 Third-party에서 안드로이드가 기본적으로 제공하는 기능을 넘어서는 개발이 가능하다면, 하나의 확고한 플랫폼으로 자리 잡을 수 있을 것이라고 생각합니다. 이러한 점에서 런처플래닛의 플랫폼화 기술은 그 가능성을 한 단계 향상시킨 기반 기술이라고 생각합니다. 감사합니다.

이현록 Store Client 기술개발팀

현재 Store Client 팀에서 Launcher 를 개발하고 있습니다.

공유하기