저 시- 경 지 2.0 한민

는 아래 조건 르는 경 에 한하여 게

l 저 물 복제, 포, 전송, 전시, 공연 송할 수 습니다.

l 저 물 리 목적 할 수 습니다.

다 과 같 조건 라야 합니다:

l 하는, 저 물 나 포 경 , 저 물에 적 된 허락조건 명확하게 나타내어야 합니다.

l 저 터 허가를 면 러한 조건들 적 되지 않습니다.

저 에 른 리는 내 에 하여 향 지 않습니다.

것 허락규약(Legal Code) 해하 쉽게 약한 것 니다.

Disclaimer

저 시. 하는 원저 를 시하여야 합니다.

경 지. 하는 저 물 개 , 형 또는 가공할 수 없습니다.

공학석사학위논문

모바일 응용의 사용자 중심 반응시간

분석 및 활용

2014 년 2 월

서울대학교 대학원

전기컴퓨터공학부

성노섭

위 원 장 : 조 유 근 (인)

부위원장 : 김 지 홍 (인)

위 원 : 민 상 렬 (인)

모바일 응용의 사용자 중심 반응시간

분석 및 활용

지도교수 김지홍

이 논문을 공학석사 학위논문으로 제출함

2014 년 2 월

서울대학교 대학원

전기컴퓨터공학부

성 노섭

성노섭의 공학석사 학위논문을 인준함

2014 년 2 월

i

요약

모바일 장치에서 응용의 사용자 경험은 매우 중요하며, 최근 연구 결과

에 따르면 사용자의 입력에 대한 반응 시간이 사용자 경험을 결정하는 가

장 중요한 요소인 것으로 조사되었다. 그러나 현재 응용 개발에 사용되는

성능 분석 도구들은 사용자가 느끼는 반응 시간보다는 작업 수행 시간을

기준으로 동작하기 때문에, 이러한 도구들을 활용한 응용 최적화는 사용

자가 느끼는 반응 시간을 단축하여 사용자 경험을 향상하는 데에는 많은

제약이 따른다.

사용자 경험에 큰 영향을 주는 반응 시간의 최적화를 위해서는 먼저 응

용 사용자가 느끼는 반응 시간을 측정하고 측정된 반응시간에 영향을 미

치는 계산 경로에 대한 이해가 필요하다. 따라서, 본 연구에서는 이러한

기존 성능 분석 도구의 문제점을 개선하여 화면 중심의 사용자가 느끼는

반응 시간을 직접적으로 측정하고 분석하여 최적화에 활용할 수 있는 도

구를 제안하고 구현하였다. 개발한 사용자 중심 반응 시간 분석 도구는

사용자가 느끼는 반응 시간을 결정하는 가장 늦은 화면 갱신 경로를 중심

으로 유용한 정보를 개발자에게 제공하여 응용 최적화에 활용할 수 있게

한다.

본 연구에서 제안하는 도구의 구현은 Dalvik 가상머신 번역기에 구현했

으며, 메소드 호출을 후킹하여 반응 시간 종료시점 판단과 내부 주요 정

ii

보들을 제공한다. 이를 통해 프레임워크, 커널, 응용 소스 코드의 수정 없

이 응용 측정이 가능하다. 개발한 도구의 효용성을 검증하기 위해

Android 4.0.4를 탑재한 삼성 Galaxy Nexus에서 도구를 사용하여 인기

응용들에서 나타나는 반응 시간 지연 패턴을 파악하였고, 이를 기반으로

최적화를 수행한 결과, 최대 33%까지 사용자 중심 반응 시간을 개선 할

수 있었다.

주요어 : 사용자 중심 반응 시간, 반응 시간 측정, 성능 critical-path 분석, 모바일

응용 프로그램 최적화

학번 : 2012-20791

iii

목차

요약 i

목차 iii

그림목차 v

표목차 vi

제 1 장 서론 1

1.1 연구 배경 . . . . . . . . . . . . . . . . . . 1

1.2 연구 동기 . . . . . . . . . . . . . . . . . . 4

1.3 관련 연구 . . . . . . . . . . . . . . . . . . 6

1.4 연구 기여 . . . . . . . . . . . . . . . . . . 9

제 2 장 사용자 중심 반응 시간 11

2.1 기준 별 반응 시간의 정의 . . . . . . . . . . . . 11

2.1 각 정의에 따른 반응 시간 비교 . . . . . . . . . . 13

제 3 장 사용자 중심 반응 시간 분석 도구 15

3.1 개관 . . . . . . . . . . . . . . . . . . . . 15

3.2 메소드 호출 후킹과 기록 모듈 . . . . . . . . . . 17

3.3 반응 시간 종료 판단 모듈 . . . . . . . . . . . . 19

3.4 기록 분석, 응용 가이드라인 확인 모듈과 진단 엔진 . . . 23

iv

제 4 장 정확도 및 오버헤드 실험과 사례 연구 24

4.1 정확도 및 오버헤드 측정 환경과 방법 . . . . . . . . 24

4.2 정확도 및 오버헤드 실험 결과 . . . . . . . . . . . 25

4.3 사례 연구 . . . . . . . . . . . . . . . . . . 27

4.3.1 TIME Mobile . . . . . . . . . . . . . . . . 27

4.3.2 PvStar+ . . . . . . . . . . . . . . . . . . 29

4.3.3 Reddit-is-fun . . . . . . . . . . . . . . . . 31

제 5 장 결론 36

5.1 결론 . . . . . . . . . . . . . . . . . . . . . 36

5.2 향후 연구 . . . . . . . . . . . . . . . . . . . 37

참고문헌 38

Abstract 39

v

그림목차

그림 1 사용자 입력에 대한 각 기준 별 반응 완료 시점 . . . . . 12

그림 2 각 반응 시간 정의에 따른 응용 반응 시간 . . . . . . . 13

그림 3 사용자 중심 반응 시간 분석 도구의 구조 . . . . . . . . 15

그림 4 화면 갱신 시나리오. . . . . . . . . . . . . . . . 19

그림 5 응용에 적용 가능한 반응 시간 종료 판단 시나리오 . . . . 20

그림 6 사용자 중심 반응 시간 종료 판단 알고리즘 유사코드 . . 21

그림 7 반응 시간 종료 판단 도구의 정확도 . . . . . . . . . 25

그림 8 반응 시간 종료 판단 도구의 오버헤드 . . . . . . . . . 26

그림 9 TIME Mobile 응용 실행 기록. . . . . . . . . . . . 27

그림 10 wiktionary 지연 된 쓰기의 반응 시간 . . . . . . . . 28

그림 11 PvStar+ 스레드 별 실행 기록 . . . . . . . . . . . 30

그림 12 PvStar+ 광고 요청 시점에 따른 응용의 반응 시간 . . . . 30

그림 13 Reddit-is-fun 클래스 별 응용 실행 기록. . . . . . . 31

그림 14 Reddit-is-fun 응용 실행 기록 . . . . . . . . . . . 33

그림 15 Reddit-is-fun 응용의 최적화에 따른 반응 시간 . . . . 34

그림 16 Reddit-is-fun 응용의 최적화에 따른 critical-path의 변화 35

vi

표목차

표 1 마켓 인기 응용들의 화면 구성 . . . . . . . . . . . . . 7

표 2 중요 기록 메소드 목록 . . . . . . . . . . . . . . . 17

１

제 1 장 서론

1.1 연구 배경

스마트폰과 같은 모바일 장치는 상호작용 중심의 장치이다. 이러한

장치는 대부분 특정한 기능들을 가지고 있는 응용 프로그램(이하

“응용”)들을 통하여 사용되며, 응용 마켓에 있는 많은 종류의 응용

중에서 사용자에게 실제 사용되는 응용은 높은 사용자 경험을 가지고

있는 응용이다. 사용자 경험에는 많은 요소가 존재하지만, 최근

모바일 응용의 사용자 경험에 관련된 연구 결과[1]에 따르면 모바일

응용의 사용자들은 성능이라는 요소를 가장 중요하게 고려하는

것으로 나타났다. 결국, 모바일 장치에서 응용의 여러 가지 사용자

요청에 대한 빠른 반응은 사용자 경험이라는 측면에서 중요하며,

이러한 반응 시간에 대한 이해와 분석이 응용 설계에 매우 중요한

부분을 차지한다고 할 수 있다.

전통적인 컴퓨팅 환경(PC)에서 반응 시간은 일반적으로 작업의

시작부터 끝까지의 시간으로 정의된다. 하지만 모바일 장치에서

사용자는 눈에 보여지는 UI(User Interface)가 화면에 표시되는

２

대로 다음 입력을 하거나 해당 작업은 끝났다고 판단하는 경향이

있다. 다른 말로 하면, 사용자는 화면에 표시되는 순간까지만

기다리며 이후에 화면에 표시되지 않고 진행되는 백그라운드 작업의

완료를 기다리지 않는다는 것이다. 이러한 이유로 전통적인 환경에서

사용되는 반응시간, 즉 계산 중심 반응시간은 모바일 장치에서

사용자가 느끼는 반응 시간을 표현하기에 적합하지 않다. 예를 들어

브라우저 응용을 이용하여 어떤 웹 페이지에 방문하는 경우에는,

요청한 URL 의 페이지를 다운받고 Webkit 이 해당 페이지를

WebView 를 통해 화면에 표시를 하고 방문 기록과 웹 캐쉬를

갱신하는 작업을 수행한다. 이 때에, 사용자가 느끼는 반응 시간은

WebView 를 통해 화면에 표시되고 다음 입력을 넣을 수 있는

상태가 되기까지이며, 이 시간은 방문 기록과 웹 캐쉬를 갱신하는

작업의 시간을 포함하는 계산 중심 반응 시간과 비교하여 많은

차이가 날 수 있다. 그러므로, 모바일 장치에서 사용자가 실제로

느끼는 성능, 즉 반응 시간을 알기 위해서는 사용자 중심으로 새로운

반응 시간에 대한 정의가 필요하다.

본 논문에서는 모바일 장치에서 사용자 중심 반응 시간을 제안하고

기존 정의와의 차이를 보여준다. 또한, Dalvik 가상머신의 메소드

３

호출 과정을 이용하여 응용에서 여러 스레드간의 관계를 정의하고

사용자가 느끼는 반응 시간을 탐지하는 기법과 도구를 소개한다.

나아가 제안한 도구를 활용하여 응용의 반응 시간을 측정하고 이

동안의 주목할 내부 정보들을 개발자에게 제공함으로 개선되는

사용자 중심 반응 시간 최적화 사례를 소개한다.

４

1.2 연구 동기

기존 반응 시간 정의의 적합성을 먼저 검토하여 새로운 평가 기준의

필요성에 대해서 알아본다. 이를 위하여 화면 중심, 그리고 기존 반응

시간의 정의와 유사한 계산 중심이라는 2 가지 다른 기준으로 응용의

반응 시간을 측정했다. 이에 대한 자세한 설명은 2 장에서 설명한다.

앞서 정의한 2 가지 관점에 따른 응용들의 반응 시간을 측정한 결과,

화면 중심 반응 시간과 계산 중심 반응 시간은 최대 두 배 이상이 될

수도 있다는 것을 알 수 있었으며, 계산 중심 반응 시간은 항상 화면

중심 반응 시간보다 길다는 것을 알 수 있었다. 응용 설계 가이드[2]는

사용자가 응용이 빠르게 동작한다고 믿게 하기 위해서 사용자가 볼 것을

우선하여 처리하고 보지 못하는 것은 뒤로 미루는 구조를 추천한다. 예를

들어, 웹 페이지를 로딩하여 화면에 표시하는 작업은 일반적으로 로딩한

웹 페이지가 화면에 표시된 이후에 웹 캐시를 저장하고 방문 기록을

갱신하는 등의 작업을 수행한다. 이러한 경우에 계산 중심 반응 시간은

화면 중심 반응 시간보다 월등히 길어 질 수 있으며, 계산 중심 반응

시간을 줄이고자 수행한 최적화가 화면 중심 반응 시간에 영향을

미친다고 보장할 수 없게 된다.

５

사용자가 느끼는 응용의 반응 시간은 사용자 경험 향상을 위해서

필수적으로 고려해야 하는 요소임에도 불구하고, 플랫폼에서 제공되는

DDMS[3]와 같은 성능 관리 도구는 아직 시스템 중심, 즉 계산 중심의

도구이다. 그러므로, 현재 사용자가 느낄 반응 시간을 알고 싶은 개발자는

응용에서 사용하는 화면 업데이트 관련 API 가 플랫폼에서 어떻게 처리가

되는지에 대한 이해를 가지고 응용에 로그를 삽입하는 방법 밖에 없다.

하지만, 플랫폼에 대한 깊은 이해가 있다 하더라도 이러한 코드를

삽입하는 것은 매우 어려운 일이다. 모바일 장치의 응용은 높은 반응성을

유지하고 메인 스레드가 무거운 작업을 수행하느라 정지되는 것을 방지할

목적으로 스레드를 통한 비동기식 작업을 빈번히 수행한다. 이러한 여러

스레드들의 동작 순서와 시간 등은 개발자가 코드 수준에서 알 수

없으므로, 응용의 성능 측정에는 적합하지 않다.

응용의 사용자 경험 향상을 위해서는 개발자에게 사용자가 느끼는

반응 시간에 대한 지표를 제공하고 이 시간을 결정하는 중요 정보를

제공하여 응용의 흐름을 파악할 수 있어야 하며, 가능한 최적화 힌트를

제공해야 할 것이다. 이러한 정보를 통해서 반복적으로 응용 최적화를

수행한다면 사용자가 느끼는 실제 성능에 대한 향상을 기대해 볼 수 있다.

６

1.3 관련 연구

HCI(Human Computer Interaction) 연구 그룹들에 의해 컴퓨터의 반응

시간이 사용자 경험에 많은 영향을 미친다는 사실이 밝혀졌다.[4] 최근

모바일 장치 관련 연구에서는 이러한 반응 시간의 중요성과 응용의 반응

시간을 분석하여 응용의 성능 향상을 도와주는 도구인 AppInsight 와

Panappticon 이 제안되었다.

AppInsight 는 응용의 소스 코드에 정적 분석을 통한 자동 소스 삽입

기술을 통하여 응용내의 스레드 관계를 분석하고 화면 갱신의 가장 긴

경로인 critical-path 를 찾아주는 도구이다. 그러나 정적 분석을 사용하므로

3 자에 의한 성능 측정이 불가능할 뿐만 아니라, 응용의 소스코드를

수정할 때마다 코드 삽입을 반복적으로 해야 되는 한계가 있다.

Panappticon 은 Android 프레임워크와 리눅스 커널에 로그 코드를

삽입하여 각 스레드 관계를 분석하고 장치의 자원사용 정보를 알려주는

도구다. 그러나 프레임워크에서만 약 17 개 이상의 클래스의 수정을

필요로 하며, 커널의 주요 모듈 대부분에 대한 수정을 필요로 하므로

매우 낮은 확장성과 이식성을 가진다.

AppInsight 와 Panappticon 모두 응용의 성능을 실험하는데 효과적인

도구이나 사용자의 입력이 인가되는 시점과 모든 화면 갱신에 대한

７

요청을 기록하여 마지막 화면 갱신 시점을 반응 완료시점으로 판단하므로

마켓에 존재하는 응용에 적용하기 어렵다는 문제점이 있다.

응용 광고 애니메이션 JavaScript 정지 화면

gReader ⅹ ▲ ▲ ▲

PvStart+ ○ ⅹ ⅹ ⅹ

News Republic ⅹ ○ ▲ ⅹ

MocoSpace ○ ○ ▲ ⅹ

Seesmic ○ ▲ ⅹ ⅹ

Browser ⅹ ▲ ▲ ▲

표 1 마켓 인기 응용들의 화면 구성

(○ : 항상 사용, ▲ : 부분 사용, x : 미 사용)

표 1 은 Android 응용 마켓에서 1,000,000 다운로드 이상을 기록한

응용들의 여러 화면에 대한 구성을 나타낸다. 사용자에 의해 사용되는

응용은 대부분 수입, 정보전달, 아름다움 등을 목적으로 광고, JavaScript,

애니메이션을 많이 사용한다. 이러한 기능들은 반복적인 혹은 무한정적인

화면 갱신를 유발하기 때문에 AppInsight 와 Panappticon 에서 제안한

８

기법으로는 어떠한 시점의 화면 갱신까지가 사용자가 관심 있는 화면

변화인지 알 수 없다.

추가적으로, 선행 연구에서 제공하는 응용 실행 동안의 자원사용,

메소드 실행 정보, 스레드 정보와 같은 많은 정보의 단순 나열은 숙련된

개발자가 아니면 이를 응용 최적화에 적용하기 매우 어렵다는 문제점이

있다. 모바일 장치에서 지원하는 각 프레임워크 별 응용 설계 원칙[7]에

따라 응용의 문제점을 지적하고 이에 대한 최적화 힌트를 제공하는 것이

가능하다면, 보다 활용도 높은 응용 진단 도구가 될 수 있을 것이다.

９

1.4 연구 기여

본 연구의 기여는 크게 3 가지로 정리 할 수 있다.

첫 번째로, 전통적인 컴퓨팅 환경에서의 반응 시간과 모바일 장치에서

사용자가 느끼는 반응 시간의 차이를 실험하고, 이를 토대로 사용자가

느끼는 반응 시간에 대한 최적화 필요성을 확인했다.

두 번째로, 사용자가 관심 있는 화면 갱신 작업만을 기록함으로 실제

응용에 적용 가능하며 확장성과 이식성이 높은 반응 시간 측정 방법론을

제안하고 구현했다. 응용은 일반적으로 10 개 이상의 스레드들로 구성되며,

이 중 일부는 데몬 혹은 애니메이션과 같이 반복적인 혹은 무한정적인

화면 갱신를 수행할 수 있다. 각 화면 갱신 요청에 대한 식별자를

이용하여 여러 화면 갱신 요청 중 사용자가 관심 있는 요청만 기록하여

무한한 화면 갱신 요청이 있는 환경에서도 사용자가 느끼는 반응 시간을

판단할 수 있다. 또한, 제안한 사용자 중심 반응 시간 측정 방법론을

기반으로 해당 시간까지의 스레드 관계, 메소드 호출 정보, I/O 수행

기록하고 응용 설계 원칙에 위반되는 사항과 최적화 대상에 대한 힌트를

제공한다. 추가적으로 프레임워크, 커널, 응용의 수정 없이 Dalvik

가상머신 번역기에서 메소드 호출을 감시하는 것으로 필요한 정보를

추출할 수 있는 환경을 구현함으로 높은 이식성과 확장성을 가진다.

１０

마지막으로, 모바일 장치 사용자들에 의해 널리 사용되고 있는 인기

있는 응용을 제안한 도구로 진단하고 문제점을 찾아 이를 재현하고

최적화를 수행하여 얻을 수 있는 사용자 중심 반응 시간의 개선을

탐색했다.

１１

제 2 장 사용자 중심 반응 시간

2.1 기준 별 반응 시간의 정의

본 논문에서는 기존 반응 시간 정의의 적합성을 먼저 검토하여 새로운

평가 기준의 필요성에 대해서 알아본다. 이를 위하여 화면 중심과 계산

중심이라는 2 가지 다른 기준을 정의했다.

화면 중심 반응 시간은 응용 개발 가이드에 따르면 사용자가 느끼는

반응 시간과 가장 유사할 것으로 추정되는 기준[5,6]으로, 사용자의 입력

이후에 해당 작업과 관련된 UI 가 화면에 전부 표시된 때 까지다. 측정은

실시간으로 모바일 장치의 프레임 버퍼 자료를 샘플링해서 더 이상

화면에 특정한 변화가 없을 때 까지를 측정했다.

계산 중심 반응 시간은 기존의 반응 시간과 유사하게 사용자의

입력으로 시작된 작업의 끝까지의 시간으로, 더 이상 새로운 메소드의

호출이 없을 때까지를 측정했다. 측정은 Dalvik 가상머신 번역기에서

메소드 호출을 감시하여 더 이상 새로운 메소드가 호출되지 않을

때까지를 측정했다.

그림

그림이다

수준이라

것이다.

큰 차이

반응 시

그림 1 사

1 은 사용

다. 각 정의

라면, 사용자

하지만, 각

이가 날 수도

간을 응용

사용자 입력

자 입력에

의에 따른 반

자 중심의

각 정의에 따

도 있다면,

최적화에 반

１２

에 대한 각

따른 각 정

반응 시간의

반응 시간

따른 반응 시

사용자 경

반드시 고려

각 기준 별 반

정의 별 반응

의 차이가 사

간을 따로

시간은 응용

경험 향상을

려해야 할 것

반응 완료

응 완료 시점

사용자가 느

사용할 필

용과 수행 작

을 위하여 사

것이다.

시점

점을 보여주

느끼지 못하

필요성은 없

작업에 따라

사용자 중심

주는

하는

없을

라서

심의

2.2

앞서

환경에서

Icecream

응용은

있는 인

그림

보여준다

많은 메

브라우저

2 각 정의

정의한 2

서 자주 사

m sandwich(

Facebook, A

인기 있는 응

그림

2 은 앞서

다. 계산 중

메소드를 호

저와 이메일

의에 따른

가지 반응

용되는 대표

(4.0.4)를 탑

Android 기본

응용을 선택하

2 각 반응

서 정의한

중심 반응 시

호출하여 상

일 응용의 경

１３

반응 시간

시간 정의를

표적인 응용

탑재한 Nexu

본 브라우저

하여 수행했

시간 정의

2 가지 관

시간은 화면이

상당히 느린

경우에는 화

간 비교

를 적용한 도

용의 반응 시

us S 에서

저, 이메일,

했다.

에 따른 응

관점에 따른

이 완벽히

린 반응 시

화면 표시가

도구를 구현

시간을 측정

실험을 진

대중 교통

응용 반응 시

응용들의

표시가 된

시간을 얻을

완료된 이

현하고, 모바

정했다. 실험

진행했고, 대

현황을 알

시간

반응 시간

이 후에도

을 수 있었

후에 웹 캐

바일

험은

대상

수

간을

수

었다.

캐시

１４

갱신, 방문 기록 갱신, 새로운 이메일의 첨부파일의 백그라운드 다운로드

등의 작업의 수행으로 인해 느린 반응 시간 결과를 얻게 되었다.

실험을 통해서 화면 중심 반응 시간과 계산 중심 반응 시간은 최대 두

배 이상이 될 수도 있다는 것을 알 수 있었다. 이는 계산 중심 반응

시간을 최적화하더라도 최적화 대상이 앞서 언급한 사용자가 느끼지

못하는 부분에 대한 최적화라면, 사용자 경험 측면에서는 무의미한 일이

될 수 있다. 그러므로, 화면 중심 반응 시간, 즉 사용자 중심의 반응

시간에 대한 이해는 사용자 경험 향상을 위해 필수적이라고 할 수 있다.

제

3.1

그

로

그

되는

호출

드

을

제 3 장

1 개관

그림 3는 모

구현된 사용

그림

그림 3에서

는 가상머신

출되는 메소

호출 기록

정의하여 반

사용자

모바일 장치

용자 중심 반

3 사용자

모바일 응

신의 번역기

소드의 정보를

모듈은 전

반응 시간

１５

중심 반

에 활발히

반응 시간 분

중심 반응

응용에 구현되

에 구현되어

를 메소드

달받은 정보

종료 판단

반응 시간

사용되고

분석 도구의

시간 분석

되어 있는

어 있다. 메

호출 기록

보를 기록하

모듈로 전

간 분석

있는 Andr

의 구조를 보

도구의 구

모듈들은 응

메소드 호출

모듈에 전

하고 해당 메

달한다. 반

도구

roid를 대상

보여준다.

조

응용마다 생

출 후킹모듈

전달한다. 메

메소드의 역

반응 시간 종

상으

생성

듈은

메소

역할

종료

１６

판단 모듈은 메소드의 역할 정보에 기반하여 사용자가 관심 있는 화

면 갱신 작업의 종료여부를 판단하고 종료 시에는 ADB(Android

Debug Bridge)를 통하여 테스크탑 응용에게 전달한다.

데스크탑 응용은 기록 분석, 응용 가이드라인 확인 모듈과 진단 엔

진으로 구성되어있다. 기록 분석 모듈은 전달받은 응용 반응 시간 동

안의 기록들을 스레드 별로 분류하고 화면 갱신의 가장 긴 경로인

critical-path를 생성하여 전달한다. 응용 가이드라인 확인 모듈은 스

레드 별 수행 메소드 기록과 critical-path를 기반으로 잘 알려진 응

용 설계 가이드라인[7]을 위반하는 일이 있는지 판단한다. 최종적으

로 진단 엔진에서는 수집된 정보들을 critical-path와 함께 표시하고,

개발자가 우선적으로 확인해야 할 사항들을 순차적으로 표시해준다.

１７

3.2 메소드 호출 후킹과 기록 모듈

응용의 수정 없이 응용의 내부 동작을 파악하기 위해서는 Dalvik

가상머신 번역기의 메소드 호출을 후킹하는 방법이 필요하다. 번역기의

구현 부에는 메소드를 호출하기 직전 관련된 클래스, 메소드. SP(Stack

Pointer), PC(Program Counter) 등을 저장하고 있는 구조체가 있다. 이

구조체를 후킹 함수에 전달함으로 내부 동작을 파악 가능하며, 함수의

호출과 종료 시점에 기록하여 해당 메소드 시작과 종료 시점을 파악한다.

표 2 중요 기록 메소드 목록

분류 작업 자료 설명

사용자 입력 USER_INPUT time 사용자의 화면 터치로 발생하는 이벤트 핸들러

액티비티 START_ACTIVITY time 액티비티 실행

비동기 작업

SEND_MSG REMOVE_MSG msg_id

runnable_objtid

스레드 간 메시지나 런어블 오브젝트 전달

DISPATCH_MSG 스레드 간 메시지나 런어블 오브젝트 처리

RUNNABLE runnable_obj

tid 스레드에 작업을 전달

화면 갱신 INVALIDATE / DRAW view_id 화면 갱신 요청/처리

I/O READ / WRITE SEND / RECV

time, tid 플래시와 네트워크 입출력

Webkit PAGE_START PAGE_FINISH

time, tid 웹 페이지 로딩의 시작 / 끝을 알려주는 콜백

OpenGL REQUEST_RENDER

DRAW_FRAME time, tid

OpenGL 를 이용한 화면 갱신

１８

메소드 기록 모듈에서는 오버헤드 감소를 위하여 미리 정의된 관심

있는 메소드만 기록하도록 하고 있다. 표 2 는 메소드 기록 모듈에서

관리하는 메소드 목록이다. 기록 대상 명시적으로 화면의 갱신을

시켜주는 메소드(화면 갱신, Webkit, OpenGL) 혹은 화면의 갱신에 영향을

줄 수 있는 중요 메소드(비동기 작업, 사용자 입력, 액티비티)를 기록한다.

이렇게 기록된 정보는 실시간으로 반응 시간 종료 판단 모듈로 전달하여

종료 시점으로 판단될 때까지 기록 수집을 반복한다.

3.3

다양한

관심 있

Android

가능하지

요청은

인해 수

관계파악

그림

스

3 반응 시

한 응용에

있는, 즉 요청

d 응용에서

지만, 메인

다른 스레

수행되는 화

악도 수반되

림 4 화면

스레드로 인

시간 종료

적용할 수

청된 작업에

서 화면 갱

스레드의

레드에서도

화면 갱신을

되어야 한다.

갱신 시나리

인한 화면 갱

１９

판단 모듈

있는 반응

대한 화면

갱신의 수행

오버헤드

가능하다.

을 모두 추

.

리오 : (a) 메

갱신; (c) 데

듈

응 시간 종료

면 갱신만을

행은 원칙

드를 줄이기

결국, 사용

추적하기 위

메인 스레드

몬 스레드로

료 판단 기법

추적할 수

적으로 메

기 위하여

용자가 요청

위해서는 각

드 화면 갱신

로 인한 화면

법은 사용자

있어야 한

인 스레드

화면 갱신

청한 작업으

각 스레드간

신; (b) 작업

면 갱신

자가

한다.

드만

신의

으로

간의

업

그림

invalidat

특정한

이루어

저장하고

수 있다

같이

작업(As

요청을

제공하는

수행된다

것만으로

스레드를

이러한

애니메이

동시에

필요하다

4 은 응

te 와 update

화면에 대해

질 수 있고

고 해당 식별

다. 하지만

모든 작업

syncTask)을

위임한다.

는 AsyncTa

다. 하지만

로는 충분하

를 통하여

화면 갱

이션, 광고

이 중에서

다.

그림 5 응

응용에서

e 는 각각 화

해서 메인 스

고, 이러한

별자를 가진

일반적인

업을 메인

요청하여

이러한 작

sk, send /

만 다른 스

하지 않다. (

반복적으로

신은 사용

등이 있을

사용자에 의

응용에 적용

２０

발생 가능

화면 갱신 요

스레드에서

경우에는

진 갱신이 이

응용은 이보

인 스레드에

다른 스레

업의 요청과

handleMessa

스레드의

c)의 경우와

로 화면 갱

용자가 요청

수 있다.

의한 요청된

가능한 반

능한 화면

요청과 처리

요청하고

각 요청의

이루어질 때

보다 복잡한

에서 처리

레드에 필요

과 처리는

age 또는 ru

화면 갱신

와 같이 응용

갱신이 이루

청한 것이

결국, 스레

된 작업만을

반응 시간 종

갱신 시

리를 나타낸다

메인 스레드

식별자(예

때 반응의 종

한 구조를

리하지 않고

요한 작업과

Android 프

unnable 객체

신 요청만

용이 수행되

루어지는 경

아닐 것이

드간의 관계

을 추적할 수

종료 판단 시

시나리오들이

다. (a)와 같

드에서 갱신

: view ID

종료를 판단

가진다. (b

고 비동기

과 화면 갱

프레임워크에

체를 이용하

을 기록하

는 동안 데

우도 있으

이다. 예로

계를 파악하

수 있는 방법

시나리오

이며

같이

신가

D)를

단할

b)와

기식

갱신

에서

하여

하는

데몬

으며,

로는

하는

법이

그림

예이다.

스레드는

그림

알고리즘

할 때마

요청한

5 는 응용

응용이 데

는 화면 갱신

그림 6 사용

6 는 응용

즘의 유사 코

마다 해당 메

화면 갱신만

용에 적용

데몬, 작업

신을 수행한

용자 중심

용의 사용자

코드이다. 미

메소드의 정

만을 추적하

２１

가능한 반

, 메인 스

한다.

반응 시간

자 중심 반응

미리 정의한

정보로 반응

하기 위해서

반응 시간

스레드들로

종료 판단

응 시간 종

한 기록 대상

응 종료 여부

Android 프

종료 판단

구성되어

알고리즘 유

종료 판단을

상 메소드의

부를 판단한

프레임워크에

단 시나리오

있으며, 모

유사코드

위해 사용

호출이 발

한다. 사용자

에서 제공하

오의

모든

용된

발생

자가

하는

２２

onClick 과 같은 입력 핸들러 구간 내에서 발생한 화면 갱신 요청 혹은

스레드에게 작업을 위임하는 요청을 해시 자료 구조에 모은다. 입력

핸들러 구간 내에서 발생한 화면 갱신 요청은 이후에 등장할 화면 갱신

수행과 비교하여 동일한 식별자를 가진 모든 요청에 대한 수행이

완료되었을 때를 종료로 판단한다. 만약 입력 핸들러 내에서 asyncTask,

sendMessage, threadStart 와 같이 다른 스레드에게 작업을 위임하는 요청이

발생하면 해당 객체의 식별자를 저장하고 이후에 등장하는 동일한

식별자를 가진 asyncTask, handleMessage, threadRun 을 새로운 입력 핸들러

구간으로 간주하고 해당 구간 동안의 요청을 다시 모은다. 이러한 작업은

여러 스레드를 거쳐서 화면 갱신이 수행될 수 있으므로, 재귀적으로

수행된다.

２３

3.4 기록 분석, 응용 가이드라인 확인 모듈과 진단 엔진

데스크탑 응용의 모듈 중 하나인 기록 분석 모듈은 표 2 에서 나열한

정보를 스레드 별 시간 축을 기준하여 개발자가 볼 수 있는 형태로

재정렬하는 역할을 수행한다. ADB 를 통해 전달받은 응용 수행 기록들은

이 단계에서 critical-path 를 중심으로 가장 많은 시간 수행된 스레드,

메소드 정보와 I/O 정보들을 표시해준다. 이 때 critical-path 는 가장

마지막에 수행된 화면 갱신 메소드를 기준으로 해당 메소드가

호출되기까지 언제, 어떤 스레드를 거쳐서 수행되었는지를 분석한다.

응용 가이드라인 확인 모듈은 구글에서 제공하는 응용 설계

가이드라인[7]을 바탕으로 응용 수행 기록 중 이를 위반하는 행동이

있는지 확인하여 진단 엔진에게 전달한다. 대표적인 예로, 메인

스레드에서 수행되거나 반응 완료 이전에 빈번한 플래시 I/O 작업, critical-

path 에 해당 하는 화면 갱신이 광고 요청일 경우 등이 있다.

진단 엔진은 응용 가이드라인을 통해 전달받은 응용 설계 원칙에

어긋나는 사항들을 확인하여 데스크탑 응용 UI 에 우선 확인 사항으로

표시해준다. 추가적으로, 가장 많이 수행된 메소드들의 순위와 수행시간,

스레드 별 수행시간을 표시한다. 표시한 정보를 기반하여 미리 정의한

규칙에 따라 다음 확인 사항으로 권장 표시를 한다. 현재 설정은 1 개의

스레드에서 수행한 시간이 전해 반응시간의 50% 이상이거나 네트워크의

수행이 반응시간의 50%이상일 때 등이 있으며, 해당 설정은 변경

가능하다.

２４

제 4 장 정확도 및 오버헤드 실험과 사례 연구

4.1 정확도 및 오버헤드 실험 환경과 방법

실험은 Android 4.0.4 Icecream Sandwich 가 탑재된 삼성 Galaxy Nexus 에서

수행됐다. 기본적으로 사용자가 느끼는 반응 시간 종료 시점을 정확하게

판단하는 것이 중요하다. 응용 마켓에 올라와 있는 응용을 대상으로

사용자 중심 반응 완료 시점 판단 정확도 평가를 위해 응용 수행 과정을

카메라를 이용하여 촬영하고 이를 응용 반응 시간 종료 판단 모듈에서

결정하는 반응 시간과 비교했다. 각 응용의 선택은 1,000,000 이상의

다운로드를 기록한 인기응용을 대상으로 선정하고, 반응 시간 실험은

응용의 런칭과 중요 작업 중 하나씩을 선택했으며, 7 개의 응용의 14 개의

작업에 대해 실험했다.

4.2

그림

대한 실

시간은

카메라

판단하는

사용자

내부정보

오버헤드

2 정확도

7 은 Andr

실험이다. 실

평균적으로

실험에 허

는 것을 알

그

자가 느끼는

보를 수집하

드로 인해 사

및 오버헤

roid 응용 마

실험 결과

로 약 100

용 가능한

수 있다.

그림 7 반응

는 반응

하는 것은 개

사용자가 느

２５

헤드 실험

마켓에서 각

약 93%

0ms 정도였

오차 범위

시간 종료

완료 시점

개발자에게

느끼는 반응

험 결과

각 카테고리

정도의 정

였다. 이는

위 내의 시간

료 판단 도구

점을 판단하

유용한 정보

응 완료 시점

별 인기 있

정확도를 보

눈으로 보

간으로 상당

구의 정확도

하고 이

보가 될 수

점을 해친다

있는 응용들

보였으며, 오

보고 판단하

당히 정확하

구간 동안

있지만, 높

다면 무의미

들에

오차

하는

하게

안의

높은

할

것이다.

오버헤드

대비 약

있다.

그림 8 은

드를 보여준

약 1% 정도로

그림

은 반응 완

준다. 실험한

로 응용의

림 8 반응

２６

료 시점 탐

한 응용들에

수행에 큰

시간 종료

탐색 도구에

대한 평균

영향을 주지

판단 도구의

에서 모바일

균 오버헤드

지 않는다는

의 오버헤드

응용 부분

는 반응 시

는 것을 알

드

분의

시간

수

4.3

응용

사용하여

응용 마

본 도구

수행하여

4.3

TIME

자료 등

이상을

흥미롭

개발한

런칭 작

스레드가

시간 전

3 사례 연

마켓에서

여 수행해보

마켓에 존재

구를 통해 탐

여 가능성을

3.1 TIME

E Mobile 은

등을 읽고

기록한 매우

롭게도 이

응용임에도

작업에서 하

가 플래시

전에 수행되는

연구

자주 사용

보고, 응용의

하는 대부분

탐지된 문제

을 탐색하는

Mobile

은 미국의 TI

의견을 공

우 인기 있는

응용은 구

도 불구하여

하나의 스레

I/O 와 네트

는 약 1.6M

그림 9 T

２７

용되는 응

의 반응 시간

분의 응용은

제점을 오픈

방향으로

IME 지에서

유할 수 있

는 응용이다

구글 인기 개

발견된 문

레드가 대부

트워크 I/O

MB 캐시로 인

TIME Mobile

용들을 반

간 최적화를

은 소스 코드

픈 소스 응용

진행했다.

서 제공하는

있는 응용으

다.

개발자로 등

제점은 응용

부분 수행

를 동시에

인해 쓰기가

e 응용 실행

반응 시간

를 가능성을

드가 존재하

용에 재현하

각종 뉴스

으로 1,000,

등록되어 있

용 설계 원칙

시간을 차

담당하고,

가 발생했다

행 기록

분석 도구

을 탐색해본

하지 않으므

하고 최적화

와 평론, 보

000 다운로

있는 전문가

칙 위반이었

지하며, 해

런칭의 반

.

구를

본다.

므로

화를

보도

로드

가가

었다.

해당

반응

그림

이전의

쓰기는

현재 사

중 하나

문제를

받아온

수행하는

메인 스

추가적인

그림

개선되는

있을 수

9 에서 볼

쓰기 연산

캐쉬 갱신

사용자 경험에

나는 지연된

를 재현하기

직후에 파

는 것을 기

스레드에 화

인 스레드를

그

9 은 지연

는 반응 시간

수 있으나, 평

볼 수 있는

산으로 지연

작업임을

에 영향을

I/O 를 통한

기 위해서

파일 캐시의

본 응용으로

화면 갱신을

를 생성하여

림 10 wiktio

연된 쓰기를

간은 쓰기에

평균적으로

２８

것과 같이

연되는 시간

확인 할 수

주지 않는

한 반응 시간

wiktionary

의 형태로

로 했다. 최

을 요청한 이

쓰기를 수

onary 지연

를 적용한 w

에 소요되는

33%정도 개

이 약 2.5

간을 확인

수 있었다. 이

부분이므로

간 최적화가

라는 위키

1.6M 를

최적화된 응

이후에 완료

행하도록 했

된 쓰기의

wiktionary 의

는 시간과 자

개선이 가능

초의 반응

할 수 있

이러한 캐쉬

로, 제안되는

가 될 수 있다

키낱말사전에

쓰기하고

용은 페이지

료되면 메인

했다.

반응 시간

의 반응 시

자료의 양에

능한 것을 확

시간과 바

으며, 이러

갱신 작업

는 최적화 방

다.

에서 페이지

화면 갱신

지를 받아오

인 스레드에

시간 결과이

따라 변동

확인했다.

바로

러한

업은

방향

지를

신을

오고

에서

다.

동이

4.3

PvSta

시청하거

검색, 구

높은 다

이 응

기록을

갱신 작

그림

호출되며

것이 확

광고의

onCreate

대한 수

문제

응용인

요청이

3.2 PvStar

ar+ 는 You

거나 방송을

구독 채널의

다운로드 수를

응용은 런칭

critical-path

작업은 응용에

11 과 같

며, 작업을

확인되었다.

표시는 항

e() 시점에서

수정이 제안되

상황의 재

Maniana 라

critical-path

r+

uTube 클라

을 시청할 수

비디오 탐

를 기록하고

칭과 인기 동

h 로 분석한

에 붙어있는

그림 11 P

같이 이러한

수행 할 때

그러나, 광

상 네트워크

서 빠르게

되었다.

재현을 위해

라는 일정

h 의 최종 화

２９

라이언트 중

수 있는 응용

탐색 등을 수

고 있는 응용

동영상 목록

한 결과 항

는 AdMob 광

PvStart+ 스레

한 광고의 요

때마다 onRe

광고 표시에

크 작업을

요청해 주

해 AdMob

관리 응용

화면 갱신 되

하나로 Y

용이다. 사용

수행할 수

용 중 하나이

록을 보는

항상 critical

광고였다.

레드별 실행

요청은 응용

Resume() 단

에 대한 응용

수반 하므로

는 것을 권

광고 계정을

에 광고를

되도록 구현

YouTube 비

용자의 선호

있는 응용으

이다.

작업을 수

-path 를 결

행 기록

용의 onRes

계에서 광고

용 가이드라

로 응용의

권장하고 있

을 생성하여

추가하여,

현했다.

비디오를 검

호에 따른 방

으로 마켓에

수행했고, 수

결정하는 화

ume() 시점

고를 요청하

라인에 따르

xml 파일이

있으므로, 이

여 오픈 소

광고에 대

색,

방송

에서

수행

화면

점에

하는

르면

이나

이에

소스

대한

３０

그림 12 PvStart+ 광고 요청 시점에 따른 응용의 반응 시간

그림 10 는 서로 다른 광고 요청 시점에 따른 응용의 반응 시간을

나타낸다. Xml 로딩의 경우 xml 문서에서 onCreate() 시점에서 먼저 광고

요청을 수행하도록 구현되어있다. 같은 기능을 하는 작업임에도 불구하고

어느 시점에서 광고를 요청하는지에 따라서 반응 시간이 약 15% 정도

차이가 있다는 것을 알 수 있었다. 광고의 요청은 독립된 스레드로 메인

스레드에서의 요청 후로는 독립적으로 수행되므로, onResume() 이전에 더

많은 일은 한다면 이러한 반응 시간의 차이는 더욱 커질 수 있다.

4200

4400

4600

4800

5000

5200

5400

5600

5800

6000

Xml 로딩 응용 onResume 로딩 응용

반응시간(밀리초)

4.3

Reddi

다운로드

news 의

비디오

실제로

하지 않

결과를

진행했다

그림

속하는

Downloa

2 위는

메소드였

parseSub

큰 영향

3.3 Redd

it-is-fun 은

드 횟수도 뉴

의 오픈 소

시청, 포럼

로 사용되는

않고 소스 코

바탕으로

다.

그림

13 은 해당

메소드 중

adThreadsTa

동일 클래

였다. 전체

bredditJSON

향을 주고

it-is-fu

TIME Mob

뉴스 카테고

스 버전이다

참여 등 매

는 응용의

코드 전체를

소스 코드

림 13 Reddi

당 응용의 클

중 가장 긴

ask 클래스의

래스 동일

반응 시간

N 이 4526m

있는 것

３１

un

bile 과 유사

고리에서는

다. 수행하는

매우 다양한

오픈 소스

가지고 있

를 분석하면

t-is-fun 클래

클래스 별 실

시간 수행

의 doInBack

메소드가

간 7111ms

ms 로 전체

것을 알 수

사한 응용으

최상위 권을

는 기능은

한 기능을 폭

버전이므로

는 상황에서

면서 응용을

래스별 응용

실행 정보이

행된 메소드

kground 라

호출한 par

중에 doIn

반응 시간

수 있었으므

으로, 마켓에

을 차지하고

뉴스 구독

폭넓게 제공

로 문제의

서 제안한 도

을 재구성하

용 실행 기록

이다. 먼저, c

드를 살펴보

는 asynTask

rseSubreddit

nBackground

에 각각 약

므로, 해당

에서의 평가

고 있는 Red

독, 방송 시

한다.

재현은 따

도구를 이용

하는 방향으

록

critical-path

았다. 1 위

k 메소드이

tJSON 이라

d 가 5344m

약 75%, 63%

당 메소드들

가와

ddit

청,

따로

용한

으로

에

위는

며,

라는

ms,

%로

들을

３２

우선적으로 살펴보았다. parseSubredditJSON 이라는 메소드는

doInBackground 에서 초기단계에 서버로부터 네트워크를 통해 데이터를

JSON 오브젝트 형태로 전달받고 이를 파싱하여 화면에 표시할 데이터를

생성하는 메소드였다. 독특한 부분은 이러한 메소드는 런칭 단계에서

초기화면을 구성할 때만 쓰이며, 매우 높은 오브젝트 파싱 오버헤드와

네트워크 오버헤드를 가졌음에도 불구하고 캐시에 대한 구현이 전혀

존재하지 않았다. 런칭을 제외한 나머지 페이지에서는 주로 Webkit 을

사용하고 이를 통한 캐시를 지원했다. 우선 최적화 대상으로 서버에서

전달받은 JSON 오브젝트의 유효성을 확인하는 프로토콜이 존재한다고

가정하고, 캐시를 지원하도록 재 구현했다. 그림 15 의 캐시를 사용하는

응용은 기존 간단한 캐시 정책을 추가했을 경우에 대한 반응 시간의

차이를 보여준다. 평균적으로 약 26%의 반응 시간 단축을 확인할 수

있었다.

두 번째로는, 가장 많은 시간이 걸린 메소드 중 3 번째에 해당하는

ShowThumbnailsTask 클래스의 doInBackground 메소드를 기준으로 분석을

진행했다. ShowThumbnailsTask 는 화면에 보여줄 이미지의 썸네일을

네트워크를 통해 받아오는 역할을 수행한다. 이 작업은 반응 시간의 가장

후반 부에 발생하는 작업이므로, 만약 앞서 언급한

DownloadThreadsTask 가 수행될 때 의존성 없이 미리 수행이 가장 하다면

이에 따른 이득을 얻을 수 있을 것으로 기대했다. 먼저 I/O 기록상에서는

DownloadThreadsTask 와 ShowThumbnailsTask 가 네트워크를 사용하는

시간은 중복되지 않으므로 네트워크 장치의 사용에 대한 경쟁 문제는

없을 것

중복되서

중심으로

widget 는

사용한다

스레드에

있었다.

결과 D

사용하고

접근하는

그림

것으로 판단

서 실행되는

로 살펴보았

는 초기 on

다는 것을

에서 만들어

이를 바탕

ownloadThr

고 ShowThu

는 것을 확인

림 14 Reddit-

단했으며,

는 부분이

았다. 그림

nCreate() 파

확인 할

어야 될 자료

탕으로 각 스

readsTask 가

umbnailsTas

인할 수 있

-is-fun 응용

(b) 스레드

３３

그림 14.(a

없었다. 다

림 14.(b)와

파악되었고, 그

할 수 있었

료구조는 Ar

스레드에서

가 수행되는

k 가 수행되

었다.

용 실행 기록

별 화면 관

a)와 같이

다음으로, 화

같이 해

그 결과 Li

었으므로, 화

rrayList 와

접근한 자

는 10 번 스

되는 13 번

록 : (a) 반응

관련 자료 접

parseSubre

화면 자료

당 작업에

istView 와

화면 갱신

Bitmap 라는

자료구조의 타

스레드에서는

번 스레드는

시간 critic

접근 기록

edditJSON

접근 기록

에서 사용하

ImageView

을 위해

는 것을 알

타입을 확인

는 ArrayList

Bitmap 만

cal-path 정보

과

록을

하는

를

각

수

인한

를

만을

보;

３４

이러한 정보는 두 개의 메소드의 자료 의존성에 대한 힌트를 제공하여

병렬화 수행 가능성을 탐색할 기회를 부여했다. 두 메소드를 집중적으로

분석한 결과 DownloadThreadsTask 에서 JSON 오브젝트를 파싱한 이후에

각 리스트 아이템의 URL 을 얻고 나서 추가적인 작업을 수행하지 않고,

ShowThumbnailsTask 를 바로 수행할 수 있다는 것을 발견했다. 그림 15 의

병렬화 수행 응용은 이러한 최적화를 결과를 보여준다. 기존 응용 대비

약 10%의 성능 향상을 확인할 수 있었다.

그림 15 Reddit-is-fun 응용의 최적화에 따른 반응 시간

그림 16 는 병렬화에 대한 최적화 수행 이후의 응용 실행에 따른

critical-path 의 변화이다. 그림 13.(a)와 비교하여 동시에 수행되는 구간이

0

1000

2000

3000

4000

5000

6000

7000

8000

기본 응용 캐시를 사용하는 응용 병렬화 수행 응용

반응시간(밀리초)

생겼으며

했다.

그

며, 이에 따

그림 16 Red

따라 사용자

ddit-is-fun 응

３５

자 중심의

응용의 최적

반응 시간이

적화에 따른

이 단축되는

critical-path

는 것을 확

h 의 변화

확인

３６

제 5 장 결론

5.1 결론

본 논문에서는 모바일 환경의 특성으로 인해 모바일 응용의 반응

시간과 기존 반응 시간과 차이점을 보여주고 모바일 응용 최적화를

위해서 사용자 중심의 반응 시간이 필요함을 보였다. 또한, 응용

개발자들에게 널리 사용되고 있는 응용 성능 분석 도구가 이러한

사용자 중심의 반응 시간을 고려하지 않고 있으므로, 이와 같은

도구를 활용한 사용자 경험을 향상은 매우 어렵다는 것을 알 수 있다.

따라서 본 논문에서는 사용자 중심 반응 시간을 Dalvik 가상머신

번역기 수준에서 적은 오버헤드로 파악할 수 있는 방법론을 제시했다.

또한, 응용의 반응 시간을 측정하고 분석하여 이를 토대로 사용자

경험을 향상시킬 수 있는 최적화 힌트를 제공함으로써 사용자 중심의

최적화를 수행할 수 있는 도구를 구현했다.

개발한 도구를 이용하여 널리 사용되고 있는 응용들을 진단해본

결과, 모바일 응용 설계에 중요한 사용자 중심 반응 시간을 고려하지

않은 응용들을 발견할 수 있었다. 이러한 경우에 제안한 도구를

활용하여 최적화를 수행하면 사용자가 실제 느끼는 반응 시간, 즉

의미 있는 성능 향상이 가능하며 최대 33%까지 사용자 중심 반응

시간을 개선 할 수 있었다.

３７

5.2 향후 연구

본 논문에서는 개발한 사용자 중심 반응 시간 측정 및 분석 도구는

게임과 같이 Android 네이티브 메소드를 활발히 이용하는 경우와 각

스레드에서 접근하는 자료의 의존성을 파악하는 것이 어렵다는

단점을 가지고 있다. 네이티브 메소드를 지원하면 진단할 수 있는

응용의 범위가 넓어지며, 스레드 간의 자료 의존성을 파악할 수

있으면 개발자에게 스레드 간의 병렬화 가능성을 명확히 제시해

줌으로써 컴퓨팅 자원을 보다 효율적으로 사용할 수 있게 할 수 있을

것이다. 따라서 향후에는 리눅스 커널에 메소드 후킹과 같은 모듈을

추가하여 네이티브 메소드를 지원하도록 확장시키고, taint[8] 분석과

같은 기법을 적용하여 도구의 활용성을 높일 계획이다.

또한, 제안한 사용자 중심 반응 시간 판단 모듈은 응용 개발자를

위한 최적화 정보 제공을 위해 사용될 수 있을 뿐만 아니라, 시스템

최적화를 위한 시스템 수준의 도구로 사용될 수 있다. 사용자 중심

반응 시간이 종료됨에 따라서 운영체제는 사용자가 관심 없는

구간에서 공격적인 에너지 절약 정책 혹은 여러 플래시 / 네트워크

입출력 요청 중에 현재 사용자 반응 시간에 영향을 주는 요청의

우선순위 부여 정책 등으로 에너지 절약과 성능 향상에 활용 될 수

있으므로, 이에 대한 연구를 진행할 계획이다.

３８

참고문헌

[1] Tom Carpenter, Apigee Survey : Users Reveal Top Frustrations

That Lead to Bad Mobile App Reviews, http://apigee.com /about/

pressrelease/apigee-survey-users-reveal-top-frustrations-lead-

bad-mobile-app-reviews, 2012

[2] APPLE INC., Launch time performance guidelines, http://developer.

apple.com/documentation/Performance/Conceptual/LaunchTime/La

unchTime.pdf

[3] GOOGLE INC., Using DDMS, http://developer.android.com/

tools/debugging/ddms.html

[4] N. Tolia, et al., “Quantifying Interactive User Experience on Thin

Clients,” IEEE Computer, 2006

[5] L. Ravindranath, et al., “AppInsight: mobile app performance

monitoring in the wild,” in Proc. International Conference on

Operating System Design and Implementation, 2012

[6] L. Zhang, et al. "Panappticon: Event-based tracing to measure

mobile application and platform performance," Hardware/Software

Codesign and System Synthesis (CODES+ ISSS), 2013

[7] GOOGLE INC., Performance Tips, http://developer.android.com/

training/articles/perf-tips.html

[8] W. Enck, et al., “TaintDroid: An Information-Flow Tracking System

for Realtime Privacy Monitoring on Smartphones,” in Proc. International

Conference on Operating System Design and Implementation, 2010

３９

Abstract

For mobile applications where the quality of user experience is

important, the response time to user’s input is considered as the

most important factor that affects user experience. However,

existing performance analysis tools for mobile applications have no

notion of the user-perceived response time, they are limited in

improving user experience of mobile apps by reducing the user-

perceived response time.

In order to optimize the user-perceived response time, it is

necessary to measure the user-perceived response time of a mobile

app and understand the app’s critical path that affects the user-

perceived response time. In this thesis, we develop a user-

perceived response time analyzer, called URA, which measures and

analyzes user-perceived response time of mobile apps. URA

computes the critical program execution path that decides the user-

perceived response time of mobile apps and provides the critical path

information to developers so that developers can utilize it for app

optimizations.

URA was implemented in the Java interpreter of Dalvik virtual

machine so that method invocations can be intercepted for collecting

internal execution information. Hooking method invocations in the

interpreter allows to collect execution traces(necessary for

computing the user-perceived response time) without modifying

４０

none of the framework, Linux kernel, and application source code.

In order to validate the effectiveness of URA, we implemented

URA in Samsung Galaxy Nexus(Icecream Sandwich 4.0.4 version)

tested URA using several popular mobile apps. Using the URA’s

response time analysis results, we showed that the user-perceived

response time can be reduced by up to 33%.

keywords : user-perceived response time, response time measurement,

performance-critical path analysis, optimization of mobile applications

Student number : 2012-20791