Home

안드로이드 플랫폼은 어플리케이션 설치를 위해 Android Application Package(APK) 파일을 사용한다. 사용자로부터 어플리케이션 설치 명령이 내려지면 어플리케이션 설치를 담당하는 시스템 서비스인 PackageManagerService는 APK 파일을 분해해 AndroidManifest.xml로 어플리케이션 정보를 등록하고 실행파일(classes.dex)과 리소스(이미지, 레이아웃 등)를 추출해 적절한 위치에 배치함으로써 어플리케이션을 설치한다.

그림 1은 APK 파일이 생성되는 과정을 나타낸다. java 소스 파일들은 class 파일들로 컴파일 된 후 안드로이드 라이브러리의 class 파일들과 함께 실행파일인 dex 파일로 변환된다. 또한 이미지, 레이아웃 등의 리소스는 aapt(Android Asset Packaging Tool)를 통해 컴파일 된 후 테이블 형태로 치환되어 resources.arsc라는 파일로 저장된다. 이렇게 생겨난 dex 파일과 resources.arsc 파일을 함께 압축해 APK 파일이 생성된다.

Fig. 1. 
APK file creation process

그림 2는 COFA를 위해 안드로이드 플랫폼 또는 서버에 추가된 구성요소들을 나타낸다. 안드로이드 플랫폼을 사용하는 디바이스만 로컬 디바이스 또는 원격 디바이스가 될 수 있으며 원격 서버의 경우 JVM(Java VM)만 실행 가능하면 운영체제에 상관없이 COFA 서버 역할을 수행할 수 있다. 별표(^*)로 표시된 부분은 기존 구성요소 중 수정된 부분을 나타내며 회색으로 표시된 부분은 추가된 구성요소를 의미한다. COFA를 사용한 일반적인 코드 오프로딩 과정은 다음과 같다.

Fig. 2. 
COFA components in android platform

어플리케이션이 설치되는 과정에서 해당 어플리케이션이 코드 오프로딩 기능을 사용하는 경우 PackagingService는 APK 파일을 분해 후 코드 포장 기법을 통해 컴퓨팅 집약적인 코드를 포장한다(①). 그 후 어플리케이션이 실행되면 선택적 사전 전송기법을 통해 포장된 코드를 전송해 적절한 위치에 저장한다(②). 실행된 어플리케이션이 컴퓨팅 집약적인 코드를 호출하면 OffloadingService는 이를 가로챈다(③). 그 후 DecisionEngine은 연결된 원격 디바이스/서버의 상태를 파악해 오프로딩 여부를 결정한다. 오프로딩이 결정되면 대상으로 결정된 원격 디바이스/서버로 호출된 메소드의 이름 및 인자와 패키지 이름을 전송한다(④). 원격 디바이스/서버의 TaskExecutor는 전송받은 정보를 사용해 코드를 실행 후 결과를 돌려준다(⑤).

어플리케이션 코드 일부를 다른 디바이스에서 실행시키기 위해서 떠올릴 수 있는 가장 쉬운 방법은 어플리케이션 코드 전체를 전송해 실행하는 것이다. 그러나 이 경우 데이터 전체가 전송되므로 전송 시간이 오래 걸릴 뿐만 아니라 서버 디바이스에서 실행될 수 있도록 설치하는 과정이 필요하다. COFA에서는 코드 포장 기법을 통해 어플리케이션의 컴퓨팅 집약적 코드를 추출해 개별적으로 관리함으로써 이를 방지한다.

코드 포장 기법은 안드로이드 어플리케이션의 실행파일을 분해해 분석 과정을 통해 컴퓨팅 집약적인 코드를 추출 후 원격 디바이스/서버에서 실행할 수 있는 형태로 포장하는 과정이며 그림 3과 같이 동작한다. 이를 위해서는 우선 어플리케이션의 실행파일인 classes.dex 파일을 코드 수준으로 분해해야 한다. dex 파일은 역 컴파일(Decompile) 과정을 통해 java class 파일들로 변환이 가능하지만 class 파일은 사람이 해석할 수 없는 형식으로 되어 있어 분석이 불가능하다.

Fig. 3. 
Code packaging process

사람이 해석할 수 있는 형식으로 되어 있는 smali 파일을 사용해 이 문제를 해결했으며 dex 파일로부터 smali 파일을 추출하기 위해 baskmali tool[14]을 안드로이드 플랫폼용으로 포팅해 사용했다.

이렇게 분해된 smali 파일 중 오프로딩의 대상이 되는 코드를 분류하기 위해 [7], [11]과 비슷한 자바 어노테이션 접근 방식을 사용한다. 개발자가 원격 디바이스/서버로 오프로딩 하고자 하는 코드를 보유한 클래스에 @ComputeIntensive라는 어노테이션을 명시하면 해당 클래스의 smali 파일은 오프로딩 대상 코드로 분류된다. 어플리케이션 실행 중 해당 클래스가 보유한 메소드가 호출되면 미리 정의된 AOP(Aspect-Oriented Programming) 프레임워크[15]는 메소드 호출을 가로채 OffloadingService로 전달한다. @ComputeIntensive 어노테이션이 명시된 코드를 파악하기 위해 dex 파일로부터 얻은 smali 파일들을 파싱하며 이 과정에서 오프로딩 대상이 되는 코드가 참조하는 패키지를 파악해 코드 테이블을 작성한다. 코드 테이블은 2열로 구성된 표로 오프로딩 대상 코드별로 해당 코드가 사용하는 패키지 목록을 나타낸다.

smali 파일들의 분석을 통해 컴퓨팅 집약적 코드와 해당 코드가 사용하는 패키지들이 분류되면 원격 디바이스/서버에서 실행 가능한 형태로 포장한다. 이는 smali 파일들을 모아 dex 파일로 변환하는 과정인데 이 과정에서 안드로이드 플랫폼용으로 포팅된 smali tool[14]을 사용한다.

코드 포장 기법은 실행 파일 분해, 분석 등의 작업으로 인해 오버헤드가 상당하다. 또한 오프로딩 기능을 사용하지 않는 어플리케이션에 대해 코드 포장을 진행할 경우 성능 저하를 발생시킬 수 있다. 이를 방지하기 위해 안드로이드 어플리케이션 설정 파일인 AndroidManifest.xml 내부의 <Application> 요소에 사용할 수 있는 useOffloding 속성을 추가했다. 어플리케이션 설치 시 PackageManagerService는 <Application>요소 내 “android:useOffloading=true” 항목을 발견하면 오프로딩 기능을 사용하는 어플리케이션이라 판단하고 PackagingService로 어플리케이션의 정보를 전달한다. 그 후 PackagingService는 해당 어플리케이션에 대해 코드 포장을 진행한다. 또한 코드 포장 과정은 어플리케이션 설치 시 한번만 진행되므로 어플리케이션이 실행된 후 코드를 주고받는 동안에는 성능 저하를 발생시키지 않는다.

어플리케이션이 오프로딩 대상 코드를 호출했을 때 해당 코드를 전송하면 직관적이지만 네트워크 통신 오버헤드로 인해 지연이 발생한다. 이를 방지하기 위해 COFA는 오프로딩 기능을 사용하는 어플리케이션이 실행되면 연결된 원격 디바이스/서버에 해당 어플리케이션의 오프로딩 해당 코드(dex 파일)를 미리 전송한다. 이렇게 전송된 코드는 로컬 디바이스와 연결이 지속되는 동안 램디스크(ramdisk)로 구성된 코드 캐쉬에 유지되며 연결이 끊어질 때 삭제된다. 만약 이미 전송되어 있다면 다시 전송하지 않고 기존에 전송된 파일을 사용한다. 이 과정을 선택적 사전 전송이라 하며 이를 통해 메소드 호출 때 마다 코드를 전송할 필요 없이 코드 오프로딩이 가능하다.

COFA는 오프로딩 여부와 연결된 디바이스/서버가 여러 대일 경우 어떤 디바이스로 오프로딩 할 것인지 결정하기 위해 간단한 결정 엔진을 사용한다. 원격 디바이스 또는 서버가 연결되면 로컬 디바이스의 DecisionEngine은 미리 정의된 테스트 코드를 전송해 실행시킨 후 시간을 기록한다. 이 시간이 로컬 디바이스의 테스트 코드 수행 시간보다 작다면 해당 디바이스로 오프로딩 한다. 만약 연결된 디바이스의 수가 여러 대라면 실행 시간이 가장 짧은 디바이스로 오프로딩 명령을 내린다. 향후에는 더 나은 오프로딩 결정을 위해 개발자가 COFA의 결정 엔진을 확장시킬 수 있도록 할 계획이다.

로컬 디바이스로부터 오프로딩 될 코드는 dex 파일로 되어 있다. 안드로이드 플랫폼에서는 어플리케이션의 크기가 커지는 것을 방지하기 위해 실행 파일을 여러 dex 파일로 나눠 실행할 수 있는 기능을 제공한다. 이는 하나의 메인 실행 파일을 두고 나머지를 라이브러리처럼 사용하도록 하는 방법으로 DexClassLoader를 통해 이뤄진다. 원격 디바이스의 경우 로컬 디바이스와 같이 안드로이드 플랫폼을 사용하므로 전송받은 코드를 DexClassLoader를 사용해 실행 후 결과를 돌려준다.

원격 서버의 경우 안드로이드 플랫폼을 사용하지 않아 dex 파일을 실행하기 위해서는 추가적인 작업이 필요하다. 안드로이드 플랫폼을 적재한 가상 머신을 사용하면 원격 서버를 안드로이드 디바이스처럼 사용할 수 있지만 가상 머신을 통해 실행시키는 것이므로 성능 저하가 발생한다. 이를 방지하기 위해 DePackagingService는 dex 파일을 전송받았을 때 dex2jar[16]를 사용해 jar 파일로 변환 후 저장한다. 그 후 컴퓨팅 집약적인 코드가 호출되면 원격 디바이스에서와 마찬가지로 ClassLoader를 사용해 코드를 실행한다.

COFA의 성능을 평가하기 위해 로컬 디바이스로는 LG에서 생산한 Nexus 7, 원격 디바이스로는 Nexus 6P, 원격 서버로는 PC에 리눅스 서버를 탑재해 사용했다. AOSP 6.0.1_r11[17] 내부에 COFA 프로토타입을 구현해 Nexus 7, Nexus 6P에 탑재했으며 실험에 사용한 디바이스/서버의 스펙은 표 1과 같다. COFA를 통해 코드 오프로딩을 함으로써 성능 향상과 에너지 절약할 수 있다는 사실을 검증하기 위해 두 가지 어플리케이션을 구현 후 실험을 진행했다.

실험에 사용된 디바이스/서버는 Wifi를 사용해 연결되어 있으며 Wifi AP는 802.11 a/b/g/n/ac를 지원한다. 로컬 디바이스인 Nexus 7의 에너지 소비를 측정하기 위해 /sys/class/power_supply/battery 폴더 내 current_now 파일과 voltage_now 파일의 값을 주기적으로 측정해 사용했다.

실험에 사용한 첫 번째 어플리케이션은 오델로(Reversi)로 minimax 알고리즘[18]을 사용해 다음 수를 계산한다. 계산의 복잡성을 위해 minimax tree의 깊이 6까지 탐색한 후 수를 결정하도록 구현했다. 또한 수를 두는 시간까지의 지연을 방지하기 위해 두 플레이어 모두 인공지능을 사용해 자동적으로 수를 계산하도록 했다. 다음 수를 계산하는 코드를 오프로딩 대상 코드로 설정해 실험을 진행했고 5회 반복 실험 후 평균값을 측정했다.

그림 4는 로컬 디바이스(Nexus 7) 홀로 오델로 게임을 실행했을 때와 원격 디바이스(Nexus 6P) 또는 원격 서버로 코드 오프로딩 했을 때의 실행 시간을 나타낸다. UI는 수를 계산 후 유저 인터페이스에 결과를 반영하는 시간을 나타내며 Computation은 수를 계산하는 시간을 나타낸다. 원격 디바이스/서버의 도움을 받을 때 다음 수를 계산하는 Computation 시간에서는 성능이 향상되는 반면 UI 반영 시간은 일정하게 나타나는 것을 알 수 있다. 전체적인 성능을 보았을 때 원격 디바이스로 코드오프로딩 시 1.8배, 원격 서버로 코드 오프로딩 시 4.7배 성능이 향상했으며 Computation 부분만 측정했을 시 각각 2.2, 13.3배 성능이 향상되었다는 것을 알 수 있다.

Fig. 4. 
Execution time for Reversi application

그림 5는 오델로 어플리케이션 실행 시 소비되는 에너지를 나타낸다. 실험 결과를 통해 COFA를 사용해 컴퓨팅 집약적인 코드를 오프로딩 시 에너지가 절약되는 것을 확인할 수 있다. 원격 디바이스로 오프로딩 시에는 65%, 원격 서버로 오프로딩 시에는 79% 에너지 소비가 감소되는 것을 확인할 수 있으며 원격 서버로 전송할 때가 원격 디바이스로 전송할 때 보다 전체 실행 시간이 짧아 더 적은 에너지를 소비하는 것을 확인할 수 있다.

Fig. 5. 
Energy consumption for Reversi application

두 번째로는 디바이스 성능을 정량적으로 나타내기 위해 많이 사용되는 린팩 벤치마크를 안드로이드 어플리케이션으로 구현해 실험을 진행했다. 린팩 벤치마크는 n x n 행렬의 선형대수 처리를 통해 시스템의 부동소수점 계산 능력을 평가한다[19]. 부동 소수점을 계산하는 코드를 오프로딩 대상으로 하여 실험을 진행했으며 오델로 어플리케이션 실험과 마찬가지로 5회 실험 후 평균값을 측정했다.

배열의 크기(n)를 다양하게 조절해가며 린팩 벤치마크 성능을 측정했으며 그 결과는 그림 6과 같다. n의 사이즈가 커질수록 로컬 디바이스 홀로 수행했을 때와 코드를 오프로딩 했을 때의 차이가 커지는 것을 확인할 수 있다. 벤치마크 결과 평균적인 처리량은 로컬 디바이스 홀로 처리 시 106.1 MFLOPS, 원격 디바이스로 코드 오프로딩 시 298.5 MFLOPS, 원격 서버로 오프로딩 시 2719.6 MFLOPS였으며 원격 디바이스/서버의 도움으로 인해 각각 2.9, 29.2배 성능이 향상되었다.

Fig. 6. 
Absolute execution time for Linpack application

그림 7은 린팩 어플리케이션을 통한 벤치마크 실행 도중 소비되는 에너지를 측정한 그래프이다. 배열의 크기가 커질수록 계산하는 양이 늘어 소비되는 에너지가 증가하는 것을 확인할 수 있으며 배열의 크기가 3000일 때 로컬 디바이스 홀로 수행했을 때 보다 원격 디바이스로 오프로딩 시 59%, 원격 서버로 오프로딩 시 66% 감소된 에너지가 소비되는 것을 확인할 수 있었다.

Fig. 7. 
Energy consumption for Linpack application

코드 오프로딩 기능을 사용하는 어플리케이션은 설치 시 코드 포장을 위해 추가적인 과정(분해, 분석, 포장)을 거친다. 코드 포장 과정의 부하를 측정하기 위해 어플리케이션 설치 시간을 측정했다. 그림 8은 오델로와 린팩 어플리케이션 설치 시 소요되는 측정한 그래프이다. 설치 외 세 가지 항목은 코드 포장 기법으로 인해 소요되는 시간이다.

분해는 baksmali tool을 사용해 dex 파일을 smali 파일들로 분해하는데 소요된 시간을 나타내고 분석은 smali 파일들을 분해해 컴퓨팅 집약적인 코드를 추리는 시간, 포장은 추려진 코드들을 모아 smali tool을 사용해 다시 dex 파일로 변환하는 시간을 의미한다. 두 어플리케이션 모두에서 코드 포장을 수행함으로써 설치만 하는 시간 대비 80%가 증가한 시간이 소요되었다. 그러나 코드 포장으로 인해 소요되는 시간을 포함하더라도 전체 설치 시간은 1.5초미만으로 길지 않은 시간이다. 또한 코드 포장 과정은 어플리케이션 설치 시 한번만 진행되고 그 이후 코드 오프로딩 과정에서는 실행되지 않는다. 그러므로 코드 포장 기법으로 인한 부하는 코드 오프로딩 성능에는 영향을 주지 않는다 할 수 있다.

Fig. 8. 
Application installation time breakdown