SlideShare a Scribd company logo
1 of 105
Download to read offline
안드로이드 Oreo의 변화 와
모바일 앱/플랫폼의 적합한 성능 측정 방법
IMQA 손영수
순서
• 안드로이드 8.0의 대대적인 변화
• 모바일(안드로이드) 에서의 성능 품질
• 모바일 어플리케이션에서 유의미한 성능 품질
확보 방안
#1. 안드로이드 8.0의 놀라운 변화
#2. 모바일에서의 성능 품질
모바일 QA	=	사전 테스트 + 사후 크래시 분석
현재 모바일 앱 품질 확보 방안
Mobile은 공유자원.. 이중 하나만 잘못되어도..
Android iOS
전 계층을 다 모니터링 해야 한다.
전 계층을 다 모니터링 해야 한다.
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
#2.1 Memory 관리
안드로이드는
앱당 메모리에 대한 제약만 있음.
CPU, IO 사용량에는 제한이 없음.
개발 편의성/ 관리를 위해 직접 메모리를 관리하고 싶지만..
Java에서는
C, C++에서 사용하는 ‘free’, ‘delete’가 없기 때문에
주기적으로 혹은 특정 조건일 때 GC를 하게 됩니다.
이로인해 프로그래머는 메모리 관리에 대해서 고민을 적게 할 수 있습니다.
하지만 임베디드 환경에서는 메모리 하나 하나가 매우 소중합니다.
안드로이드 메모리 관리방법 (GC)에 대한 발전사
기본적으로 할당하는 방식은
Strong Reference 입니다.
Strong
- 기본적으로 할당하는 방식을 Strong Reference 라고 부릅니다.
mLauncher = new <Launcher>(launcher);
- GC과정에서 연결된 객체들을 Mark하고 Mark되지 않은 객체들을 Sweep합니다.
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에 있는 객체들을 제거 합니다.
더 자세히 보겠습니다.
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
(다른작업도 쓰레드로 진행가능)
안드로이드 구 버전의 GC방식
Serial Mark&Sweep과 Concurrent Mark&Sweep 동작 비교
Android	ART	이후 변화된 메모
리 구조..
Rosalloc 이란
(Runs of Slots Allocator)
작은 객체들을 위한
thread local storage를 만들자.
Bulk free를 위하여.
작은 객체를 할당하는 영역과
큰 객체를 할당하는 영역을 구분하자
하나의 영역에 객체를 할당하니,
GC가 빈번하게 발생해서,
역할을 나누자!
변경된 메모리 Workflow
변경한 이유.. (Intel의 연구)
Object	Size	분포 (Bytes)
변경한 이유.. (Google	Map	사
례)
Object	Life	Time	(1세대에서 대부분 걸러짐)
살아남는 %
GC	실행횟수
추가적인 기교들을 더함.
• Dalvik이 두번 Pause(mark ­remark) 해서 객체 mark-sweep 함
• ART에서는 한번 pause(mark를 병렬로 진행 ­ remark에서만 멈춤).
• 그래도 mark-sweep은 느리니 병렬로 해서 빠르게 정리하자.
• 최근 생성(sticky)하거나, 짧은 수명의 객체는 빨리 제거하자.
• 메모리가 부족해 GC를 돌리면 OOM이 날수 있으니, 더 낮은 상한성 (GC Timelier) 만
들어서 돌리자.
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를 세대별로 하는 방법.
제조사의 상황에 따라
다양한 전략들을 도입해 배포 가능함.
L부터 Foreground / Background
GC 로 구성함.
Foreground	gc (화면 담당)
Background	gc (백드라운드 담당)
Foreground gc는 Concurrent Mar
Sweep
Foreground	gc는 동시다발적으로 진행.
Background	
gc는
Semi-Space	
(#1)
Background	
gc는
Gen	Semi-
Space	(#2)
Background	
gc는
CMS	(#3)
왜 Foreground / Background GC
로 나누었을까?
Foreground	GC (화면 담당)
Background	GC (백드라운드 담당)
• Foreground GC -> CMS (파편화보다 빠른 정리)
빠르게 정리되는 것이 중요. 화면이 빈번하게 변경되므로
생명 주기가 긴 객체가 없다. 파편화 이슈보다 빠르게 정
리가 중요 (화면은 자주 갱신되니)
• Background GC (생명주기 긴 객체 -> 파편화)
항상 메모리에서 떠 있는 녀석들이 많다. 그만큼 생명주기
도 기니까 파편화가 많이 발생할수 있음. 속도보다는
memory compact 하는 녀석을 선택하는 것이 좋음.
왜 Oreo부터
Foreground	/	Background	
GC를
Concurrent Compaction
으로 단일화 하려고 할까?
줄어든 App	Size, LOS/	ROS의 성공적인 도입,
멀티 코어 디바이스 확대
Background	gctype 은 언제든지 변경
(기본 gc 설정은 제조사 마음)
• To	disable	background	compaction	do:	
• adb shell	setprop dalvik.vm.backgroundgctype CMS	
• To	enable:	
• adb shell	setprop dalvik.vm.backgroundgctype SS
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
#2.2 UI Rendering
Vsync 란 (60fps = 16ms의 중요성)
Android 3.0 이전
뷰의 부분 변경을 해결하기 위해 cascading하여 그렸음.
Android 3.0 이후
Display List 도입으로 ViewRoot에 방문없이,
쉽게 변경 내용을 업데이트할수 있음.
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/
Android 5.0 이후 ­ material design 도
입
Material 의 animation 효과 어떻게 하지?
자 그럼 이제 GPU를 사용해 CPU 부하 줄이자 (RenderThread도입)
Android 4와 5의 CPU 부하 비교
UI Thread 와 RenderThread의 관계
#2.3 CPU/ GPU Throttling
CPU 절전 모드?
이유는.. 밧데리 절약, 온도 등.
시사점..
CPU Governor 정책에 의해.
CPU가 뜨거워지면 -> 절전 모드로..
밧데리를 아끼기 위해 일이 없으면 -> 천천히 돌아가게..
개발자 입장에서는 내 앱이 최적의 상황에서만. 돌길 바랄뿐.
*cpu/gpu governor 정리자료
http://ajgupta.github.io/android/2015/01/28/CPU-and-
GPU-governors/
#2.4 Storage
CPU, UI Rendering 만큼 신경써야 하는 영역..
우리가 간과하는 큰 부분이 있습니다.
심지어 프로파일러 마저도.. 없는 영역??
I/O
모바일 스토리지 종류에 따라 차이나는 IO 성능
4kb 에 랜덤 읽기 / 쓰기 속도
4kb에 빠르다고 해서 256kb도 빠른게 아니
다
위 상황에서
앱끼리 경쟁에 빠지면...
시사점..
Database, File I/O Benchmark Test의 의미가 무색..
하나의 디바이스에서 매겨진 랭킹이.
다른 디바이스에서 동일하다는 보장이 없다..
또한 나의 앱이 IO를 쓸따 다른 앱이 IO를 안쓴다는 보
장도 없다..
직접 case by case 다 보셔야 한다.. (정말 가능?)
또 하나의 변수 .. Wear Leveling (웨
어 레벨링)
Wear	Leveling	전 Wear	Leveling	후
시사점..
화면을 16ms 안에 못 그려졌다면. 누구 책임인가?
데이터 읽기 / 쓰기 속도가 뒤죽 박죽 이라면 누구 책
임인가?
앱 개발자가 해결할수 있는 문제인가?..
# 2.4. 이 모든 원인은 밧데리..
밧데리의 수명은 제한적
제조사의 고민
• 오래 사용하기 위해 전력 소비량을 낮추던가?
• 동일한 전력을 계속 공급해 성능은 유지하지만,
2,3시간 만에 방전 되던가?
복잡한 다계층 시스템에 대해서 다시 생각해 보자.
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
복잡한 다계층 시스템에 대해서 다시 생각해 보자.
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
# 2.5 성능에 대한 정리
#3. 모바일 어플리케이션의 유 의미한 성능 확보 방안은?
사전 테스트
(고객 배포 이전에 Quality Gate 역할)
단점들…
1) 고객의 Device와 나의 Device는 다른 상황..
2) 다른 앱의 간섭으로 발생한 문제라면.
3) 구할 수 없는 디바이스라면….
배포후 크래시 수집 -> 성능 개선..
1) 고객은 이미 떠나는 상황.. (별점 테러)
2) 크래시 상황이 100% 재현이 안됨..
3) 크래시 제공 회사가 주는 제약들
• Google만 써
• 북미에 있는 서버
• 데이터는 다 저장못해 (샘플링 방식)
전방위적으로 모니터링 한다면.
• 사고가 나기 전에도 전반적인 운행 상황도,
• 사고날때는 더 상세한 상황을..
사용자 수
액티비티 관
계
문제 상황
에 따른 문제상황
파악가능
액티비티
OS 버전
기기 종류
지역
적용한 필터는 모든 디테일 화
면에도 적용
시간별 자원 사용량과 요청한 함수, OS Level 데이터 제공
현재 앱의 가장 문제되는 구간(병목) 파악
필터 그룹 저장
저장된 필터 그룹이용
자세한 원인 파악 가능
THANK YOU!
ysson@onycom.com

More Related Content

What's hot

[NDC10] Unity Build 로 빌드타임 반토막내기 - 송창규
[NDC10] Unity Build 로 빌드타임 반토막내기 - 송창규[NDC10] Unity Build 로 빌드타임 반토막내기 - 송창규
[NDC10] Unity Build 로 빌드타임 반토막내기 - 송창규
ChangKyu Song
 
Kgc2014 삼한제국기 포스트모템 김찬웅
Kgc2014 삼한제국기 포스트모템 김찬웅Kgc2014 삼한제국기 포스트모템 김찬웅
Kgc2014 삼한제국기 포스트모템 김찬웅
Chanwoong Kim
 
백승엽, M2프로젝트의 오류보고시스템, NDC2010
백승엽, M2프로젝트의 오류보고시스템, NDC2010백승엽, M2프로젝트의 오류보고시스템, NDC2010
백승엽, M2프로젝트의 오류보고시스템, NDC2010
devCAT Studio, NEXON
 
이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018
이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018
이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018
devCAT Studio, NEXON
 
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
devCAT Studio, NEXON
 

What's hot (20)

[NDC10] Unity Build 로 빌드타임 반토막내기 - 송창규
[NDC10] Unity Build 로 빌드타임 반토막내기 - 송창규[NDC10] Unity Build 로 빌드타임 반토막내기 - 송창규
[NDC10] Unity Build 로 빌드타임 반토막내기 - 송창규
 
[NEXT] Android Profiler 사용법
[NEXT] Android Profiler 사용법 [NEXT] Android Profiler 사용법
[NEXT] Android Profiler 사용법
 
KGC 2014 프로파일러를 이용한 게임 클라이언트 최적화
KGC 2014 프로파일러를 이용한 게임 클라이언트 최적화KGC 2014 프로파일러를 이용한 게임 클라이언트 최적화
KGC 2014 프로파일러를 이용한 게임 클라이언트 최적화
 
[114]angularvs react 김훈민손찬욱
[114]angularvs react 김훈민손찬욱[114]angularvs react 김훈민손찬욱
[114]angularvs react 김훈민손찬욱
 
[IGC 2017] 엔지메이킹 이대희 - 이제는 웹에서 게임을 만들 수 있는 환경 'Construct3를 바탕으로'
[IGC 2017] 엔지메이킹 이대희 - 이제는 웹에서 게임을 만들 수 있는 환경 'Construct3를 바탕으로'[IGC 2017] 엔지메이킹 이대희 - 이제는 웹에서 게임을 만들 수 있는 환경 'Construct3를 바탕으로'
[IGC 2017] 엔지메이킹 이대희 - 이제는 웹에서 게임을 만들 수 있는 환경 'Construct3를 바탕으로'
 
[133] 브라우저는 vsync를 어떻게 활용하고 있을까
[133] 브라우저는 vsync를 어떻게 활용하고 있을까[133] 브라우저는 vsync를 어떻게 활용하고 있을까
[133] 브라우저는 vsync를 어떻게 활용하고 있을까
 
Kgc2014 삼한제국기 포스트모템 김찬웅
Kgc2014 삼한제국기 포스트모템 김찬웅Kgc2014 삼한제국기 포스트모템 김찬웅
Kgc2014 삼한제국기 포스트모템 김찬웅
 
[NDC17] 왓 스튜디오 서비스파트
[NDC17] 왓 스튜디오 서비스파트[NDC17] 왓 스튜디오 서비스파트
[NDC17] 왓 스튜디오 서비스파트
 
[IGC 2017] 오토데스크 박준석 - 3ds Max 2018과 Shotgun을 이용한 게임 제작 Pipeline 소개
[IGC 2017] 오토데스크 박준석 - 3ds Max 2018과 Shotgun을 이용한 게임 제작 Pipeline 소개[IGC 2017] 오토데스크 박준석 - 3ds Max 2018과 Shotgun을 이용한 게임 제작 Pipeline 소개
[IGC 2017] 오토데스크 박준석 - 3ds Max 2018과 Shotgun을 이용한 게임 제작 Pipeline 소개
 
FullStack 개발자 만들기 과정 소개 (Android + MEAN Stack + Redis 다루기)
FullStack 개발자 만들기 과정 소개  (Android + MEAN Stack + Redis 다루기) FullStack 개발자 만들기 과정 소개  (Android + MEAN Stack + Redis 다루기)
FullStack 개발자 만들기 과정 소개 (Android + MEAN Stack + Redis 다루기)
 
[111] 네이버효과툰어떻게만들어졌나
[111] 네이버효과툰어떻게만들어졌나[111] 네이버효과툰어떻게만들어졌나
[111] 네이버효과툰어떻게만들어졌나
 
[123] electron 김성훈
[123] electron 김성훈[123] electron 김성훈
[123] electron 김성훈
 
[DEVIEW 2016] 네이버의 모던 웹 라이브러리 - egjs
[DEVIEW 2016] 네이버의 모던 웹 라이브러리 - egjs[DEVIEW 2016] 네이버의 모던 웹 라이브러리 - egjs
[DEVIEW 2016] 네이버의 모던 웹 라이브러리 - egjs
 
[네이버오픈소스세미나] egjs-view360 개발기 - 김희재
[네이버오픈소스세미나] egjs-view360 개발기 - 김희재[네이버오픈소스세미나] egjs-view360 개발기 - 김희재
[네이버오픈소스세미나] egjs-view360 개발기 - 김희재
 
백승엽, M2프로젝트의 오류보고시스템, NDC2010
백승엽, M2프로젝트의 오류보고시스템, NDC2010백승엽, M2프로젝트의 오류보고시스템, NDC2010
백승엽, M2프로젝트의 오류보고시스템, NDC2010
 
[IGC 2016] 유니티코리아 오지현 - “뭣이 중헌디? 성능 프로파일링도 모름서”: 유니티 성능 프로파일링 가이드
[IGC 2016] 유니티코리아 오지현 - “뭣이 중헌디? 성능 프로파일링도 모름서”: 유니티 성능 프로파일링 가이드[IGC 2016] 유니티코리아 오지현 - “뭣이 중헌디? 성능 프로파일링도 모름서”: 유니티 성능 프로파일링 가이드
[IGC 2016] 유니티코리아 오지현 - “뭣이 중헌디? 성능 프로파일링도 모름서”: 유니티 성능 프로파일링 가이드
 
[122]네이버의모던웹라이브러리 박재성
[122]네이버의모던웹라이브러리 박재성[122]네이버의모던웹라이브러리 박재성
[122]네이버의모던웹라이브러리 박재성
 
이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018
이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018
이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018
 
[D2 CAMPUS] tech meet up(Back-end) - 교내 웹서비스 개발 일지 (박은찬님)
[D2 CAMPUS] tech meet up(Back-end) - 교내 웹서비스 개발 일지 (박은찬님)[D2 CAMPUS] tech meet up(Back-end) - 교내 웹서비스 개발 일지 (박은찬님)
[D2 CAMPUS] tech meet up(Back-end) - 교내 웹서비스 개발 일지 (박은찬님)
 
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
 

Similar to 안드로이드 Oreo의 변화와 모바일 앱/플랫폼의 적합한 성능 측정 방법

모니터링 영역의 변천사_클라우드, 디지털 경험까지)
모니터링 영역의 변천사_클라우드, 디지털 경험까지)모니터링 영역의 변천사_클라우드, 디지털 경험까지)
모니터링 영역의 변천사_클라우드, 디지털 경험까지)
IMQA
 
[NDC12] 변화량 분석을 중심으로 한 저비용 고효율의 지속가능한 코드퀄리티 관리법 - 송창규
[NDC12] 변화량 분석을 중심으로 한 저비용 고효율의 지속가능한 코드퀄리티 관리법 - 송창규[NDC12] 변화량 분석을 중심으로 한 저비용 고효율의 지속가능한 코드퀄리티 관리법 - 송창규
[NDC12] 변화량 분석을 중심으로 한 저비용 고효율의 지속가능한 코드퀄리티 관리법 - 송창규
ChangKyu Song
 
[박민근] 3 d렌더링 옵티마이징_nv_perfhud
[박민근] 3 d렌더링 옵티마이징_nv_perfhud[박민근] 3 d렌더링 옵티마이징_nv_perfhud
[박민근] 3 d렌더링 옵티마이징_nv_perfhud
MinGeun Park
 

Similar to 안드로이드 Oreo의 변화와 모바일 앱/플랫폼의 적합한 성능 측정 방법 (20)

모니터링 영역의 변천사_클라우드, 디지털 경험까지)
모니터링 영역의 변천사_클라우드, 디지털 경험까지)모니터링 영역의 변천사_클라우드, 디지털 경험까지)
모니터링 영역의 변천사_클라우드, 디지털 경험까지)
 
Android와 Flutter 앱 개발의 큰 차이점 5가지
Android와 Flutter 앱 개발의 큰 차이점 5가지Android와 Flutter 앱 개발의 큰 차이점 5가지
Android와 Flutter 앱 개발의 큰 차이점 5가지
 
실 사례로 보는 고객 디지털 경험 지키기
실 사례로 보는 고객 디지털 경험 지키기실 사례로 보는 고객 디지털 경험 지키기
실 사례로 보는 고객 디지털 경험 지키기
 
프론트엔드 개발자를 위한 크롬 렌더링 성능인자 이해하기
프론트엔드 개발자를 위한 크롬 렌더링 성능인자 이해하기프론트엔드 개발자를 위한 크롬 렌더링 성능인자 이해하기
프론트엔드 개발자를 위한 크롬 렌더링 성능인자 이해하기
 
GDG DevFest Busan 16" Android Nougat Developer's Note
GDG DevFest Busan 16" Android Nougat Developer's NoteGDG DevFest Busan 16" Android Nougat Developer's Note
GDG DevFest Busan 16" Android Nougat Developer's Note
 
HTML5/JSON 을 이용해 범용 2D 맵에디터 제작하기
HTML5/JSON 을 이용해 범용 2D 맵에디터 제작하기HTML5/JSON 을 이용해 범용 2D 맵에디터 제작하기
HTML5/JSON 을 이용해 범용 2D 맵에디터 제작하기
 
[215]네이버콘텐츠통계서비스소개 김기영
[215]네이버콘텐츠통계서비스소개 김기영[215]네이버콘텐츠통계서비스소개 김기영
[215]네이버콘텐츠통계서비스소개 김기영
 
[NDC12] 변화량 분석을 중심으로 한 저비용 고효율의 지속가능한 코드퀄리티 관리법 - 송창규
[NDC12] 변화량 분석을 중심으로 한 저비용 고효율의 지속가능한 코드퀄리티 관리법 - 송창규[NDC12] 변화량 분석을 중심으로 한 저비용 고효율의 지속가능한 코드퀄리티 관리법 - 송창규
[NDC12] 변화량 분석을 중심으로 한 저비용 고효율의 지속가능한 코드퀄리티 관리법 - 송창규
 
[박민근] 3 d렌더링 옵티마이징_nv_perfhud
[박민근] 3 d렌더링 옵티마이징_nv_perfhud[박민근] 3 d렌더링 옵티마이징_nv_perfhud
[박민근] 3 d렌더링 옵티마이징_nv_perfhud
 
모바일 게임 최적화
모바일 게임 최적화 모바일 게임 최적화
모바일 게임 최적화
 
Spark machine learning & deep learning
Spark machine learning & deep learningSpark machine learning & deep learning
Spark machine learning & deep learning
 
Android Applications on Galaxy S (장기성)
Android Applications on Galaxy S (장기성)Android Applications on Galaxy S (장기성)
Android Applications on Galaxy S (장기성)
 
Java와 go 간의 병렬 프로그램 성능 비교
Java와 go 간의 병렬 프로그램 성능 비교Java와 go 간의 병렬 프로그램 성능 비교
Java와 go 간의 병렬 프로그램 성능 비교
 
Python과 Tensorflow를 활용한 AI Chatbot 개발 및 실무 적용
Python과 Tensorflow를 활용한  AI Chatbot 개발 및 실무 적용Python과 Tensorflow를 활용한  AI Chatbot 개발 및 실무 적용
Python과 Tensorflow를 활용한 AI Chatbot 개발 및 실무 적용
 
The MongoDB Strikes Back / MongoDB 의 역습
The MongoDB Strikes Back / MongoDB 의 역습The MongoDB Strikes Back / MongoDB 의 역습
The MongoDB Strikes Back / MongoDB 의 역습
 
모바일 Rpg 게임서버 제작
모바일 Rpg 게임서버 제작모바일 Rpg 게임서버 제작
모바일 Rpg 게임서버 제작
 
웨일브라우저 성능 및 메모리 최적화
웨일브라우저 성능 및 메모리 최적화웨일브라우저 성능 및 메모리 최적화
웨일브라우저 성능 및 메모리 최적화
 
Ndc2010 김주복, v3. 마비노기2아키텍처리뷰
Ndc2010   김주복, v3. 마비노기2아키텍처리뷰Ndc2010   김주복, v3. 마비노기2아키텍처리뷰
Ndc2010 김주복, v3. 마비노기2아키텍처리뷰
 
C# / .NET Framework로 미래 밥그릇을 챙겨보자 (Basic)
C# / .NET Framework로 미래 밥그릇을 챙겨보자 (Basic)C# / .NET Framework로 미래 밥그릇을 챙겨보자 (Basic)
C# / .NET Framework로 미래 밥그릇을 챙겨보자 (Basic)
 
[IGC 2017] 넥스트플로어 김영수 - Protocol:hyperspace Diver 개발 포스트모템
[IGC 2017] 넥스트플로어 김영수 - Protocol:hyperspace Diver 개발 포스트모템[IGC 2017] 넥스트플로어 김영수 - Protocol:hyperspace Diver 개발 포스트모템
[IGC 2017] 넥스트플로어 김영수 - Protocol:hyperspace Diver 개발 포스트모템
 

More from YoungSu Son

오픈소스 Jedis 리펙토링 하기 (redis java 라이브러리)
오픈소스 Jedis 리펙토링 하기 (redis java 라이브러리) 오픈소스 Jedis 리펙토링 하기 (redis java 라이브러리)
오픈소스 Jedis 리펙토링 하기 (redis java 라이브러리)
YoungSu Son
 

More from YoungSu Son (20)

Fault Tolerance 패턴
Fault Tolerance 패턴 Fault Tolerance 패턴
Fault Tolerance 패턴
 
Clean Code, Software Architecture, Performance Tuning
Clean Code, Software Architecture, Performance TuningClean Code, Software Architecture, Performance Tuning
Clean Code, Software Architecture, Performance Tuning
 
인공지능 식별추적시스템 실증랩 구축및 운영 - 평가모델 고도화
인공지능 식별추적시스템 실증랩 구축및 운영 - 평가모델 고도화인공지능 식별추적시스템 실증랩 구축및 운영 - 평가모델 고도화
인공지능 식별추적시스템 실증랩 구축및 운영 - 평가모델 고도화
 
Prototype 패턴 (심만섭)
Prototype 패턴 (심만섭) Prototype 패턴 (심만섭)
Prototype 패턴 (심만섭)
 
Chain of Responsibility (심수연 - 소프트웨어 마에스트로 10기)
Chain of Responsibility (심수연 - 소프트웨어 마에스트로 10기)Chain of Responsibility (심수연 - 소프트웨어 마에스트로 10기)
Chain of Responsibility (심수연 - 소프트웨어 마에스트로 10기)
 
Singleton 패턴 (김진영 - EVA, 소마에 10기)
Singleton 패턴 (김진영 -  EVA, 소마에 10기) Singleton 패턴 (김진영 -  EVA, 소마에 10기)
Singleton 패턴 (김진영 - EVA, 소마에 10기)
 
실전 서버 부하테스트 노하우
실전 서버 부하테스트 노하우 실전 서버 부하테스트 노하우
실전 서버 부하테스트 노하우
 
생성 패턴 (강태우 - 소마에 10기)
생성 패턴 (강태우 - 소마에 10기) 생성 패턴 (강태우 - 소마에 10기)
생성 패턴 (강태우 - 소마에 10기)
 
DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)
DevOps 오픈소스 트랜드 (클라우드, 모바일 중심) DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)
DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)
 
SW 아키텍처 분석방법
SW 아키텍처 분석방법 SW 아키텍처 분석방법
SW 아키텍처 분석방법
 
Android Studio 개발 셋팅 + Genymotion
Android Studio 개발 셋팅 + GenymotionAndroid Studio 개발 셋팅 + Genymotion
Android Studio 개발 셋팅 + Genymotion
 
[NEXT] Flask 로 Restful API 서버 만들기
[NEXT] Flask 로 Restful API 서버 만들기 [NEXT] Flask 로 Restful API 서버 만들기
[NEXT] Flask 로 Restful API 서버 만들기
 
[NEXT] GCM을 이용한 게시글 자동 갱신
[NEXT] GCM을 이용한 게시글 자동 갱신[NEXT] GCM을 이용한 게시글 자동 갱신
[NEXT] GCM을 이용한 게시글 자동 갱신
 
[NEXT] Andorid에 MVC 패턴 적용하기
[NEXT] Andorid에 MVC 패턴 적용하기[NEXT] Andorid에 MVC 패턴 적용하기
[NEXT] Andorid에 MVC 패턴 적용하기
 
[NEXT] 화면 재갱신이 되는 안드로이드 앱 만들기 - 네트워크에 독립하는 구조로 변경
[NEXT] 화면 재갱신이 되는 안드로이드 앱 만들기 - 네트워크에 독립하는 구조로 변경[NEXT] 화면 재갱신이 되는 안드로이드 앱 만들기 - 네트워크에 독립하는 구조로 변경
[NEXT] 화면 재갱신이 되는 안드로이드 앱 만들기 - 네트워크에 독립하는 구조로 변경
 
오픈소스 Jedis 리펙토링 하기 (redis java 라이브러리)
오픈소스 Jedis 리펙토링 하기 (redis java 라이브러리) 오픈소스 Jedis 리펙토링 하기 (redis java 라이브러리)
오픈소스 Jedis 리펙토링 하기 (redis java 라이브러리)
 
URQA 삼성 컨퍼런스 발표
URQA 삼성 컨퍼런스 발표 URQA 삼성 컨퍼런스 발표
URQA 삼성 컨퍼런스 발표
 
[NEXT] Nextgram Refactoring
[NEXT] Nextgram Refactoring[NEXT] Nextgram Refactoring
[NEXT] Nextgram Refactoring
 
[NEXT] Android Profiler
[NEXT] Android Profiler[NEXT] Android Profiler
[NEXT] Android Profiler
 
NIO로 구현 Reactor/ Proactor 성능 테스트
NIO로 구현 Reactor/ Proactor 성능 테스트 NIO로 구현 Reactor/ Proactor 성능 테스트
NIO로 구현 Reactor/ Proactor 성능 테스트
 

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

  • 1. 안드로이드 Oreo의 변화 와 모바일 앱/플랫폼의 적합한 성능 측정 방법 IMQA 손영수
  • 2. 순서 • 안드로이드 8.0의 대대적인 변화 • 모바일(안드로이드) 에서의 성능 품질 • 모바일 어플리케이션에서 유의미한 성능 품질 확보 방안
  • 3. #1. 안드로이드 8.0의 놀라운 변화
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.
  • 14.
  • 15.
  • 16.
  • 17.
  • 18.
  • 19.
  • 20.
  • 21.
  • 22.
  • 23.
  • 24.
  • 25.
  • 26.
  • 27.
  • 28.
  • 29.
  • 30.
  • 32. 모바일 QA = 사전 테스트 + 사후 크래시 분석
  • 33. 현재 모바일 앱 품질 확보 방안
  • 34.
  • 35.
  • 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
  • 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 동작 비교
  • 48. Rosalloc 이란 (Runs of Slots Allocator) 작은 객체들을 위한 thread local storage를 만들자. Bulk free를 위하여. 작은 객체를 할당하는 영역과 큰 객체를 할당하는 영역을 구분하자 하나의 영역에 객체를 할당하니, GC가 빈번하게 발생해서, 역할을 나누자!
  • 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 (백드라운드 담당)
  • 61. 왜 Foreground / Background GC 로 나누었을까? Foreground GC (화면 담당) Background GC (백드라운드 담당) • Foreground GC -> CMS (파편화보다 빠른 정리) 빠르게 정리되는 것이 중요. 화면이 빈번하게 변경되므로 생명 주기가 긴 객체가 없다. 파편화 이슈보다 빠르게 정 리가 중요 (화면은 자주 갱신되니) • Background GC (생명주기 긴 객체 -> 파편화) 항상 메모리에서 떠 있는 녀석들이 많다. 그만큼 생명주기 도 기니까 파편화가 많이 발생할수 있음. 속도보다는 memory compact 하는 녀석을 선택하는 것이 좋음.
  • 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
  • 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
  • 77. 시사점.. CPU Governor 정책에 의해. CPU가 뜨거워지면 -> 절전 모드로.. 밧데리를 아끼기 위해 일이 없으면 -> 천천히 돌아가게.. 개발자 입장에서는 내 앱이 최적의 상황에서만. 돌길 바랄뿐. *cpu/gpu governor 정리자료 http://ajgupta.github.io/android/2015/01/28/CPU-and- GPU-governors/
  • 79. CPU, UI Rendering 만큼 신경써야 하는 영역.. 우리가 간과하는 큰 부분이 있습니다. 심지어 프로파일러 마저도.. 없는 영역?? I/O
  • 80. 모바일 스토리지 종류에 따라 차이나는 IO 성능
  • 81. 4kb 에 랜덤 읽기 / 쓰기 속도
  • 82. 4kb에 빠르다고 해서 256kb도 빠른게 아니 다
  • 84. 시사점.. Database, File I/O Benchmark Test의 의미가 무색.. 하나의 디바이스에서 매겨진 랭킹이. 다른 디바이스에서 동일하다는 보장이 없다.. 또한 나의 앱이 IO를 쓸따 다른 앱이 IO를 안쓴다는 보 장도 없다.. 직접 case by case 다 보셔야 한다.. (정말 가능?)
  • 85. 또 하나의 변수 .. Wear Leveling (웨 어 레벨링) Wear Leveling 전 Wear Leveling 후
  • 86. 시사점.. 화면을 16ms 안에 못 그려졌다면. 누구 책임인가? 데이터 읽기 / 쓰기 속도가 뒤죽 박죽 이라면 누구 책 임인가? 앱 개발자가 해결할수 있는 문제인가?..
  • 87. # 2.4. 이 모든 원인은 밧데리..
  • 88.
  • 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. 전방위적으로 모니터링 한다면. • 사고가 나기 전에도 전반적인 운행 상황도, • 사고날때는 더 상세한 상황을..
  • 97.
  • 100. 적용한 필터는 모든 디테일 화 면에도 적용
  • 101. 시간별 자원 사용량과 요청한 함수, OS Level 데이터 제공
  • 102. 현재 앱의 가장 문제되는 구간(병목) 파악