안드로이드 Oreo의 변화와 모바일 앱/플랫폼의 적합한 성능 측정 방법에 대한 자료입니다. 단순히 크래시를 넘어 어떠한 성능 매트릭을 수집해야 되는지, 그리고 동작원리에 대한 큰 틀을 설명했습니다.

1. 안드로이드 Oreo의 변화 와
모바일 앱/플랫폼의 적합한 성능 측정 방법
IMQA 손영수

2. 순서
• 안드로이드 8.0의 대대적인 변화
• 모바일(안드로이드) 에서의 성능 품질
• 모바일 어플리케이션에서 유의미한 성능 품질
확보 방안

3. #1. 안드로이드 8.0의 놀라운 변화

31. #2. 모바일에서의 성능 품질

32. 모바일 QA = 사전 테스트 + 사후 크래시 분석

33. 현재 모바일 앱 품질 확보 방안

36. Mobile은 공유자원.. 이중 하나만 잘못되어도..
Android iOS

37. 전 계층을 다 모니터링 해야 한다.

38. 전 계층을 다 모니터링 해야 한다.
CPU & GPU Memory NetworkStorage
Method Trace
Layout (60fps)
Wake Locks
Over Draws
Animations
Job Schedulers..
GC
Object Allocations
Caching
Background/Foregrou
nd Policy
BITMAP
Optimization..
Batch
(Job Scheduler)
Pre Patching
Data Compression
Response Time
Traffic, Packet, Error,
Dropped In/Out
File I/O
SQL Lite Operations
IOPS
CPU / GPU Governor
VSync
Wear Leveling
Seq , Random
Read/Write Speed
Battery Power
Consumption
WWAN(HSPA, LTE,
WiMAX..)
Peak Bit Rate /
Throughput MAX
Wear Leveling
Seq , Random
Read/Write Speed

39. #2.1 Memory 관리

40. 안드로이드는
앱당 메모리에 대한 제약만 있음.
CPU, IO 사용량에는 제한이 없음.

41. 개발 편의성/ 관리를 위해 직접 메모리를 관리하고 싶지만..
Java에서는
C, C++에서 사용하는 ‘free’, ‘delete’가 없기 때문에
주기적으로 혹은 특정 조건일 때 GC를 하게 됩니다.
이로인해 프로그래머는 메모리 관리에 대해서 고민을 적게 할 수 있습니다.
하지만 임베디드 환경에서는 메모리 하나 하나가 매우 소중합니다.

42. 안드로이드 메모리 관리방법 (GC)에 대한 발전사

43. 기본적으로 할당하는 방식은
Strong Reference 입니다.
Strong
- 기본적으로 할당하는 방식을 Strong Reference 라고 부릅니다.
mLauncher = new <Launcher>(launcher);
- GC과정에서 연결된 객체들을 Mark하고 Mark되지 않은 객체들을 Sweep합니다.

44. Strong 이외에 3가지가 더 있습니다.
1. 종류
Soft reference, Weak reference, Phantom reference
Private WeakReference<Launcher> mLauncher;
mLauncher = new WeakReference<Launcher>(launcher);
2. 원리
- GC동작에서 Strong이 아닌 경우 Mark하지 않고
Reference Queue라는 공간에 객체를 넣고,
Sweep하는 과정에서 제거 Queue에 있는 객체들을 제거 합니다.

45. 더 자세히 보겠습니다.
1. Soft reference
Mark가 되기도 하고 Reference Queue에 담기기도 합니다.
Soft reference로 참조된 객체는 메모리가 절대적으로 부족한 상황이 되기전에는 참조가 유지됩니다.
각 앱마다 할당된 메모리가 절대적을 부족할 때 Soft이면 제거, 여유롭다면 Strong과 같이 제거하지 않습니다.
2. Weak reference
Referene Queue에 담깁니다.
Weak reference로 참조된 객체는 Soft Reference보다 더 약한 연결고리를 가집니다.
메모리의 상태와 관계없이 GC가 동작되는 순간 Marked Object라도 회수됩니다.
Strong Soft
Weak
Phantom
Mark
Reference Queue

46. (다른작업도 쓰레드로 진행가능)
안드로이드 구 버전의 GC방식
Serial Mark&Sweep과 Concurrent Mark&Sweep 동작 비교

47. Android ART 이후 변화된 메모
리 구조..

48. Rosalloc 이란
(Runs of Slots Allocator)
작은 객체들을 위한
thread local storage를 만들자.
Bulk free를 위하여.
작은 객체를 할당하는 영역과
큰 객체를 할당하는 영역을 구분하자
하나의 영역에 객체를 할당하니,
GC가 빈번하게 발생해서,
역할을 나누자!

49. 변경된 메모리 Workflow

50. 변경한 이유.. (Intel의 연구)
Object Size 분포 (Bytes)

51. 변경한 이유.. (Google Map 사
례)
Object Life Time (1세대에서 대부분 걸러짐)
살아남는 %
GC 실행횟수

52. 추가적인 기교들을 더함.
• Dalvik이 두번 Pause(mark ­remark) 해서 객체 mark-sweep 함
• ART에서는 한번 pause(mark를 병렬로 진행 ­ remark에서만 멈춤).
• 그래도 mark-sweep은 느리니 병렬로 해서 빠르게 정리하자.
• 최근 생성(sticky)하거나, 짧은 수명의 객체는 빨리 제거하자.
• 메모리가 부족해 GC를 돌리면 OOM이 날수 있으니, 더 낮은 상한성 (GC Timelier) 만
들어서 돌리자.

53. Android L부터 GC 전략 추가
• CMS (기본전략)
• Mark-Sweep 전략을 유지하되 성능을 향상 시키는 방법
• Mark-Sweep 의 느린 속도를 해결하기 위해 병렬, 부분, 이전 세대에만 생성된 것을 제
거하는 방식 등이 종합적으로 적용함.
• SS : Semi Space (aka From Space To Space)
• 빠른 GC 방법 / 단 메모리는 많이 사용하는 방법 -> 단 첫 GC의 정확도는 Mark-Sweep
보다 낮은 문제가 있음.
• 2개의 Semi Space 를 만들어서 정리하는 방법
• GSS : Generation Semi Space
• Semi Space를 세대별로 하는 방법.

54. 제조사의 상황에 따라
다양한 전략들을 도입해 배포 가능함.

55. L부터 Foreground / Background
GC 로 구성함.
Foreground gc (화면 담당)
Background gc (백드라운드 담당)

56. Foreground gc는 Concurrent Mar
Sweep

57. Foreground gc는 동시다발적으로 진행.

58. Background
gc는
Semi-Space
(#1)

59. Background
gc는
Gen Semi-
Space (#2)

60. Background
gc는
CMS (#3)

61. 왜 Foreground / Background GC
로 나누었을까?
Foreground GC (화면 담당)
Background GC (백드라운드 담당)
• Foreground GC -> CMS (파편화보다 빠른 정리)
빠르게 정리되는 것이 중요. 화면이 빈번하게 변경되므로
생명 주기가 긴 객체가 없다. 파편화 이슈보다 빠르게 정
리가 중요 (화면은 자주 갱신되니)
• Background GC (생명주기 긴 객체 -> 파편화)
항상 메모리에서 떠 있는 녀석들이 많다. 그만큼 생명주기
도 기니까 파편화가 많이 발생할수 있음. 속도보다는
memory compact 하는 녀석을 선택하는 것이 좋음.

62. 왜 Oreo부터
Foreground / Background
GC를
Concurrent Compaction
으로 단일화 하려고 할까?

63. 줄어든 App Size, LOS/ ROS의 성공적인 도입,
멀티 코어 디바이스 확대

64. Background gctype 은 언제든지 변경
(기본 gc 설정은 제조사 마음)
• To disable background compaction do:
• adb shell setprop dalvik.vm.backgroundgctype CMS
• To enable:
• adb shell setprop dalvik.vm.backgroundgctype SS

65. MemFree vs MemoryAvailable.
cat /proc/meminfoOS 메모리 정보는
MemFree보다
MemAvailable을 이용하세요.
MemFree:
The amount of physical RAM, in kilobytes,
left unused by the system.
MemAvailable:
An estimate of how much memory is available
for starting new application

66. #2.2 UI Rendering

67. Vsync 란 (60fps = 16ms의 중요성)

68. Android 3.0 이전
뷰의 부분 변경을 해결하기 위해 cascading하여 그렸음.

69. Android 3.0 이후
Display List 도입으로 ViewRoot에 방문없이,
쉽게 변경 내용을 업데이트할수 있음.

70. Android 3.0 이후 ­ HW Acceleration 도
입
https://developer.android.com/guide/topics/graphics/hardware-accel.html
http://blog.danlew.net/2015/10/20/using-hardware-layers-to-improve-animation-performance/

71. Android 5.0 이후 ­ material design 도
입
Material 의 animation 효과 어떻게 하지?
자 그럼 이제 GPU를 사용해 CPU 부하 줄이자 (RenderThread도입)

72. Android 4와 5의 CPU 부하 비교

73. UI Thread 와 RenderThread의 관계

74. #2.3 CPU/ GPU Throttling

75. CPU 절전 모드?

76. 이유는.. 밧데리 절약, 온도 등.

77. 시사점..
CPU Governor 정책에 의해.
CPU가 뜨거워지면 -> 절전 모드로..
밧데리를 아끼기 위해 일이 없으면 -> 천천히 돌아가게..
개발자 입장에서는 내 앱이 최적의 상황에서만. 돌길 바랄뿐.
*cpu/gpu governor 정리자료
http://ajgupta.github.io/android/2015/01/28/CPU-and-
GPU-governors/

78. #2.4 Storage

79. CPU, UI Rendering 만큼 신경써야 하는 영역..
우리가 간과하는 큰 부분이 있습니다.
심지어 프로파일러 마저도.. 없는 영역??
I/O

80. 모바일 스토리지 종류에 따라 차이나는 IO 성능

81. 4kb 에 랜덤 읽기 / 쓰기 속도

82. 4kb에 빠르다고 해서 256kb도 빠른게 아니
다

83. 위 상황에서
앱끼리 경쟁에 빠지면...

84. 시사점..
Database, File I/O Benchmark Test의 의미가 무색..
하나의 디바이스에서 매겨진 랭킹이.
다른 디바이스에서 동일하다는 보장이 없다..
또한 나의 앱이 IO를 쓸따 다른 앱이 IO를 안쓴다는 보
장도 없다..
직접 case by case 다 보셔야 한다.. (정말 가능?)

85. 또 하나의 변수 .. Wear Leveling (웨
어 레벨링)
Wear Leveling 전 Wear Leveling 후

86. 시사점..
화면을 16ms 안에 못 그려졌다면. 누구 책임인가?
데이터 읽기 / 쓰기 속도가 뒤죽 박죽 이라면 누구 책
임인가?
앱 개발자가 해결할수 있는 문제인가?..

87. # 2.4. 이 모든 원인은 밧데리..

89. 밧데리의 수명은 제한적
제조사의 고민
• 오래 사용하기 위해 전력 소비량을 낮추던가?
• 동일한 전력을 계속 공급해 성능은 유지하지만,
2,3시간 만에 방전 되던가?

90. 복잡한 다계층 시스템에 대해서 다시 생각해 보자.
CPU & GPU Memory NetworkStorage
Method Trace
Layout (60fps)
Wake Locks
Over Draws
Animations
Job Schedulers..
GC
Object Allocations
Caching
Background/Foregrou
nd Policy
BITMAP
Optimization..
Batch
(Job Scheduler)
Pre Patching
Data Compression
Response Time
Traffic, Packet, Error,
Dropped In/Out
File I/O
SQL Lite Operations
IOPS
CPU / GPU Governor
VSync
Wear Leveling
Seq , Random
Read/Write Speed
Battery Power
Consumption
WWAN(HSPA, LTE,
WiMAX..)
Peak Bit Rate /
Throughput MAX
Wear Leveling
Seq , Random
Read/Write Speed

91. 복잡한 다계층 시스템에 대해서 다시 생각해 보자.
CPU & GPU Memory NetworkStorage
UI Rendering Time
(Native, Web)
Event
GC Pause Time
Memory Allocation
Wear Level
HTTP Response Time
Traffic In/Out
File I/O
SQL Lite Operations
IOPS
CPU / GPU Governor
VSync
Wear Leveling
Seq , Random
Read/Write Speed
Battery Power
Consumption
WWAN(HSPA, LTE,
WiMAX..)
Peak Bit Rate /
Throughput MAX
Wear Leveling
Seq , Random
Read/Write Speed

92. # 2.5 성능에 대한 정리

93. #3. 모바일 어플리케이션의 유 의미한 성능 확보 방안은?

94. 사전 테스트
(고객 배포 이전에 Quality Gate 역할)
단점들…
1) 고객의 Device와 나의 Device는 다른 상황..
2) 다른 앱의 간섭으로 발생한 문제라면.
3) 구할 수 없는 디바이스라면….

95. 배포후 크래시 수집 -> 성능 개선..
1) 고객은 이미 떠나는 상황.. (별점 테러)
2) 크래시 상황이 100% 재현이 안됨..
3) 크래시 제공 회사가 주는 제약들
• Google만 써
• 북미에 있는 서버
• 데이터는 다 저장못해 (샘플링 방식)

96. 전방위적으로 모니터링 한다면.
• 사고가 나기 전에도 전반적인 운행 상황도,
• 사고날때는 더 상세한 상황을..

98. 사용자 수
액티비티 관
계
문제 상황

99. 에 따른 문제상황
파악가능
액티비티
OS 버전
기기 종류
지역

100. 적용한 필터는 모든 디테일 화
면에도 적용

101. 시간별 자원 사용량과 요청한 함수, OS Level 데이터 제공

102. 현재 앱의 가장 문제되는 구간(병목) 파악

103. 필터 그룹 저장

104. 저장된 필터 그룹이용
자세한 원인 파악 가능

105. THANK YOU!
ysson@onycom.com