SlideShare a Scribd company logo
1 of 85
Download to read offline
안드로이드 Oreo의 변화 와
모바일 앱/플랫폼의 적합한 성능 측정 방법
손영수
ysson@onycom.com
순서
• 안드로이드 8.0의 대대적인 변화
• 모바일(안드로이드) 에서의 성능 품질시 고려해
야 할 것들..
#1. 안드로이드 8.0의 놀라운 변화
Facebook 의 redex 프로젝트에 영향을 받는 것으로 추정.
http://bit.ly/2GGNuA4
#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는 동시다발적으로 진행.
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 도입 + ICS부터 기본으로 적용
hardware layer 동시 사용도 필수
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
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
발표 자료
http://bit.ly/2BQtGXo
THANK YOU!
ysson@onycom.com
성능에 관심있는 분은
KPPG
(Korea Pattern & Performance Group)
페이스북 그룹으로..

More Related Content

What's hot

[145]5년간의네이버웹엔진개발삽질기그리고 김효
[145]5년간의네이버웹엔진개발삽질기그리고 김효[145]5년간의네이버웹엔진개발삽질기그리고 김효
[145]5년간의네이버웹엔진개발삽질기그리고 김효
NAVER D2
 
공감세미나 성능테스트
공감세미나 성능테스트공감세미나 성능테스트
공감세미나 성능테스트
Lim SungHyun
 
[211]대규모 시스템 시각화 현동석김광림
[211]대규모 시스템 시각화 현동석김광림[211]대규모 시스템 시각화 현동석김광림
[211]대규모 시스템 시각화 현동석김광림
NAVER D2
 
[NDC10] Unity Build 로 빌드타임 반토막내기 - 송창규
[NDC10] Unity Build 로 빌드타임 반토막내기 - 송창규[NDC10] Unity Build 로 빌드타임 반토막내기 - 송창규
[NDC10] Unity Build 로 빌드타임 반토막내기 - 송창규
ChangKyu Song
 
[Hello world 오픈세미나]n grinder helloworld발표자료_저작권free
[Hello world 오픈세미나]n grinder helloworld발표자료_저작권free[Hello world 오픈세미나]n grinder helloworld발표자료_저작권free
[Hello world 오픈세미나]n grinder helloworld발표자료_저작권free
NAVER D2
 
Kgc2014 삼한제국기 포스트모템 김찬웅
Kgc2014 삼한제국기 포스트모템 김찬웅Kgc2014 삼한제국기 포스트모템 김찬웅
Kgc2014 삼한제국기 포스트모템 김찬웅
Chanwoong Kim
 

What's hot (20)

[133] 브라우저는 vsync를 어떻게 활용하고 있을까
[133] 브라우저는 vsync를 어떻게 활용하고 있을까[133] 브라우저는 vsync를 어떻게 활용하고 있을까
[133] 브라우저는 vsync를 어떻게 활용하고 있을까
 
Nginx Testing in NAVER
Nginx Testing in NAVERNginx Testing in NAVER
Nginx Testing in NAVER
 
[145]5년간의네이버웹엔진개발삽질기그리고 김효
[145]5년간의네이버웹엔진개발삽질기그리고 김효[145]5년간의네이버웹엔진개발삽질기그리고 김효
[145]5년간의네이버웹엔진개발삽질기그리고 김효
 
[121]네이버 효과툰 구현 이야기
[121]네이버 효과툰 구현 이야기[121]네이버 효과툰 구현 이야기
[121]네이버 효과툰 구현 이야기
 
KGC 2014 프로파일러를 이용한 게임 클라이언트 최적화
KGC 2014 프로파일러를 이용한 게임 클라이언트 최적화KGC 2014 프로파일러를 이용한 게임 클라이언트 최적화
KGC 2014 프로파일러를 이용한 게임 클라이언트 최적화
 
공감세미나 성능테스트
공감세미나 성능테스트공감세미나 성능테스트
공감세미나 성능테스트
 
[211]대규모 시스템 시각화 현동석김광림
[211]대규모 시스템 시각화 현동석김광림[211]대규모 시스템 시각화 현동석김광림
[211]대규모 시스템 시각화 현동석김광림
 
Front end 웹사이트 성능 측정 및 개선
Front end 웹사이트 성능 측정 및 개선Front end 웹사이트 성능 측정 및 개선
Front end 웹사이트 성능 측정 및 개선
 
[124] 하이브리드 앱 개발기 김한솔
[124] 하이브리드 앱 개발기 김한솔[124] 하이브리드 앱 개발기 김한솔
[124] 하이브리드 앱 개발기 김한솔
 
[NDC10] Unity Build 로 빌드타임 반토막내기 - 송창규
[NDC10] Unity Build 로 빌드타임 반토막내기 - 송창규[NDC10] Unity Build 로 빌드타임 반토막내기 - 송창규
[NDC10] Unity Build 로 빌드타임 반토막내기 - 송창규
 
Advanced nGrinder 2nd Edition
Advanced nGrinder 2nd EditionAdvanced nGrinder 2nd Edition
Advanced nGrinder 2nd Edition
 
[114]angularvs react 김훈민손찬욱
[114]angularvs react 김훈민손찬욱[114]angularvs react 김훈민손찬욱
[114]angularvs react 김훈민손찬욱
 
what is_tabs_share
what is_tabs_sharewhat is_tabs_share
what is_tabs_share
 
[111] 네이버효과툰어떻게만들어졌나
[111] 네이버효과툰어떻게만들어졌나[111] 네이버효과툰어떻게만들어졌나
[111] 네이버효과툰어떻게만들어졌나
 
[122]네이버의모던웹라이브러리 박재성
[122]네이버의모던웹라이브러리 박재성[122]네이버의모던웹라이브러리 박재성
[122]네이버의모던웹라이브러리 박재성
 
[152] 웹브라우저 감옥에서 살아남기
[152] 웹브라우저 감옥에서 살아남기[152] 웹브라우저 감옥에서 살아남기
[152] 웹브라우저 감옥에서 살아남기
 
[NDC17] 왓 스튜디오 서비스파트
[NDC17] 왓 스튜디오 서비스파트[NDC17] 왓 스튜디오 서비스파트
[NDC17] 왓 스튜디오 서비스파트
 
[IGC 2016] 유니티코리아 오지현 - “뭣이 중헌디? 성능 프로파일링도 모름서”: 유니티 성능 프로파일링 가이드
[IGC 2016] 유니티코리아 오지현 - “뭣이 중헌디? 성능 프로파일링도 모름서”: 유니티 성능 프로파일링 가이드[IGC 2016] 유니티코리아 오지현 - “뭣이 중헌디? 성능 프로파일링도 모름서”: 유니티 성능 프로파일링 가이드
[IGC 2016] 유니티코리아 오지현 - “뭣이 중헌디? 성능 프로파일링도 모름서”: 유니티 성능 프로파일링 가이드
 
[Hello world 오픈세미나]n grinder helloworld발표자료_저작권free
[Hello world 오픈세미나]n grinder helloworld발표자료_저작권free[Hello world 오픈세미나]n grinder helloworld발표자료_저작권free
[Hello world 오픈세미나]n grinder helloworld발표자료_저작권free
 
Kgc2014 삼한제국기 포스트모템 김찬웅
Kgc2014 삼한제국기 포스트모템 김찬웅Kgc2014 삼한제국기 포스트모템 김찬웅
Kgc2014 삼한제국기 포스트모템 김찬웅
 

Similar to Android 성능 지표와 Oreo 의 개선사항

모니터링 영역의 변천사_클라우드, 디지털 경험까지)
모니터링 영역의 변천사_클라우드, 디지털 경험까지)모니터링 영역의 변천사_클라우드, 디지털 경험까지)
모니터링 영역의 변천사_클라우드, 디지털 경험까지)
IMQA
 
MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...
MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...
MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...
문기 박
 
[NDC12] 변화량 분석을 중심으로 한 저비용 고효율의 지속가능한 코드퀄리티 관리법 - 송창규
[NDC12] 변화량 분석을 중심으로 한 저비용 고효율의 지속가능한 코드퀄리티 관리법 - 송창규[NDC12] 변화량 분석을 중심으로 한 저비용 고효율의 지속가능한 코드퀄리티 관리법 - 송창규
[NDC12] 변화량 분석을 중심으로 한 저비용 고효율의 지속가능한 코드퀄리티 관리법 - 송창규
ChangKyu Song
 

Similar to Android 성능 지표와 Oreo 의 개선사항 (20)

프론트엔드 개발자를 위한 크롬 렌더링 성능인자 이해하기
프론트엔드 개발자를 위한 크롬 렌더링 성능인자 이해하기프론트엔드 개발자를 위한 크롬 렌더링 성능인자 이해하기
프론트엔드 개발자를 위한 크롬 렌더링 성능인자 이해하기
 
모니터링 영역의 변천사_클라우드, 디지털 경험까지)
모니터링 영역의 변천사_클라우드, 디지털 경험까지)모니터링 영역의 변천사_클라우드, 디지털 경험까지)
모니터링 영역의 변천사_클라우드, 디지털 경험까지)
 
실 사례로 보는 고객 디지털 경험 지키기
실 사례로 보는 고객 디지털 경험 지키기실 사례로 보는 고객 디지털 경험 지키기
실 사례로 보는 고객 디지털 경험 지키기
 
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 맵에디터 제작하기
 
프론트엔드 개발자를 위한 크롬 렌더링 성능 인자 이해하기
프론트엔드 개발자를 위한 크롬 렌더링 성능 인자 이해하기프론트엔드 개발자를 위한 크롬 렌더링 성능 인자 이해하기
프론트엔드 개발자를 위한 크롬 렌더링 성능 인자 이해하기
 
[DEVIEW 2016] 네이버의 모던 웹 라이브러리 - egjs
[DEVIEW 2016] 네이버의 모던 웹 라이브러리 - egjs[DEVIEW 2016] 네이버의 모던 웹 라이브러리 - egjs
[DEVIEW 2016] 네이버의 모던 웹 라이브러리 - egjs
 
MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...
MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...
MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...
 
Pg day seoul 2016 session_02_v1.0_ff
Pg day seoul 2016 session_02_v1.0_ffPg day seoul 2016 session_02_v1.0_ff
Pg day seoul 2016 session_02_v1.0_ff
 
[NEXT] Android Profiler 사용법
[NEXT] Android Profiler 사용법 [NEXT] Android Profiler 사용법
[NEXT] Android Profiler 사용법
 
NAVER TECH CONCERT_FE2019_빠르게 훑어보는 웹 개발 트렌드
NAVER TECH CONCERT_FE2019_빠르게 훑어보는 웹 개발 트렌드NAVER TECH CONCERT_FE2019_빠르게 훑어보는 웹 개발 트렌드
NAVER TECH CONCERT_FE2019_빠르게 훑어보는 웹 개발 트렌드
 
중고나라 거래 통계 서비스 1차 개발 완료 보고
중고나라 거래 통계 서비스 1차 개발 완료 보고중고나라 거래 통계 서비스 1차 개발 완료 보고
중고나라 거래 통계 서비스 1차 개발 완료 보고
 
서버학개론(백엔드 서버 개발자를 위한)
서버학개론(백엔드 서버 개발자를 위한)서버학개론(백엔드 서버 개발자를 위한)
서버학개론(백엔드 서버 개발자를 위한)
 
꿀밋업2탄_도메인 모델에 따른 데이터 분리 저장과 API 연결
꿀밋업2탄_도메인 모델에 따른 데이터 분리 저장과 API 연결꿀밋업2탄_도메인 모델에 따른 데이터 분리 저장과 API 연결
꿀밋업2탄_도메인 모델에 따른 데이터 분리 저장과 API 연결
 
Android와 Flutter 앱 개발의 큰 차이점 5가지
Android와 Flutter 앱 개발의 큰 차이점 5가지Android와 Flutter 앱 개발의 큰 차이점 5가지
Android와 Flutter 앱 개발의 큰 차이점 5가지
 
Sencha ExtJS를 활용한 Big Data Platform 개발 사례
Sencha ExtJS를 활용한 Big Data Platform 개발 사례 Sencha ExtJS를 활용한 Big Data Platform 개발 사례
Sencha ExtJS를 활용한 Big Data Platform 개발 사례
 
Event storming based msa training commerce example add_handson_v3
Event storming based msa training commerce example add_handson_v3Event storming based msa training commerce example add_handson_v3
Event storming based msa training commerce example add_handson_v3
 
Big Data platform을 위한 Sencha Ext JS 사례.
Big Data platform을 위한 Sencha Ext JS 사례.Big Data platform을 위한 Sencha Ext JS 사례.
Big Data platform을 위한 Sencha Ext JS 사례.
 
2015 oce specification
2015 oce specification2015 oce specification
2015 oce specification
 
[NDC12] 변화량 분석을 중심으로 한 저비용 고효율의 지속가능한 코드퀄리티 관리법 - 송창규
[NDC12] 변화량 분석을 중심으로 한 저비용 고효율의 지속가능한 코드퀄리티 관리법 - 송창규[NDC12] 변화량 분석을 중심으로 한 저비용 고효율의 지속가능한 코드퀄리티 관리법 - 송창규
[NDC12] 변화량 분석을 중심으로 한 저비용 고효율의 지속가능한 코드퀄리티 관리법 - 송창규
 

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
 
FullStack 개발자 만들기 과정 소개 (Android + MEAN Stack + Redis 다루기)
FullStack 개발자 만들기 과정 소개  (Android + MEAN Stack + Redis 다루기) FullStack 개발자 만들기 과정 소개  (Android + MEAN Stack + Redis 다루기)
FullStack 개발자 만들기 과정 소개 (Android + MEAN Stack + Redis 다루기)
 
[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
 

Android 성능 지표와 Oreo 의 개선사항

  • 1. 안드로이드 Oreo의 변화 와 모바일 앱/플랫폼의 적합한 성능 측정 방법 손영수 ysson@onycom.com
  • 2. 순서 • 안드로이드 8.0의 대대적인 변화 • 모바일(안드로이드) 에서의 성능 품질시 고려해 야 할 것들..
  • 3. #1. 안드로이드 8.0의 놀라운 변화
  • 4.
  • 5.
  • 6. Facebook 의 redex 프로젝트에 영향을 받는 것으로 추정. http://bit.ly/2GGNuA4
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.
  • 14.
  • 15.
  • 16.
  • 17.
  • 18.
  • 19.
  • 20.
  • 21.
  • 22.
  • 23.
  • 24.
  • 25.
  • 27. 모바일 QA = 사전 테스트 + 사후 크래시 분석
  • 28. 현재 모바일 앱 품질 확보 방안
  • 29.
  • 30. Mobile은 공유자원.. 이중 하나만 잘못되어도.. Android iOS
  • 31. 전 계층을 다 모니터링 해야 한다.
  • 32. 전 계층을 다 모니터링 해야 한다. 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
  • 34. 안드로이드는 앱당 메모리에 대한 제약만 있음. CPU, IO 사용량에는 제한이 없음.
  • 35. 개발 편의성/ 관리를 위해 직접 메모리를 관리하고 싶지만.. Java에서는 C, C++에서 사용하는 ‘free’, ‘delete’가 없기 때문에 주기적으로 혹은 특정 조건일 때 GC를 하게 됩니다. 이로인해 프로그래머는 메모리 관리에 대해서 고민을 적게 할 수 있습니다. 하지만 임베디드 환경에서는 메모리 하나 하나가 매우 소중합니다.
  • 36. 안드로이드 메모리 관리방법 (GC)에 대한 발전사
  • 37. 기본적으로 할당하는 방식은 Strong Reference 입니다. Strong - 기본적으로 할당하는 방식을 Strong Reference 라고 부릅니다. mLauncher = new <Launcher>(launcher); - GC과정에서 연결된 객체들을 Mark하고 Mark되지 않은 객체들을 Sweep합니다.
  • 38. 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에 있는 객체들을 제거 합니다.
  • 39. 더 자세히 보겠습니다. 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
  • 40. (다른작업도 쓰레드로 진행가능) 안드로이드 구 버전의 GC방식 Serial Mark&Sweep과 Concurrent Mark&Sweep 동작 비교
  • 42. Rosalloc 이란 (Runs of Slots Allocator) 작은 객체들을 위한 thread local storage를 만들자. Bulk free를 위하여. 작은 객체를 할당하는 영역과 큰 객체를 할당하는 영역을 구분하자 하나의 영역에 객체를 할당하니, GC가 빈번하게 발생해서, 역할을 나누자!
  • 44. 변경한 이유.. (Intel의 연구) Object Size 분포 (Bytes)
  • 45. 변경한 이유.. (Google Map 사 례) Object Life Time (1세대에서 대부분 걸러짐) 살아남는 % GC 실행횟수
  • 46. 추가적인 기교들을 더함. • Dalvik이 두번 Pause(mark ­remark) 해서 객체 mark-sweep 함 • ART에서는 한번 pause(mark를 병렬로 진행 ­ remark에서만 멈춤). • 그래도 mark-sweep은 느리니 병렬로 해서 빠르게 정리하자. • 최근 생성(sticky)하거나, 짧은 수명의 객체는 빨리 제거하자. • 메모리가 부족해 GC를 돌리면 OOM이 날수 있으니, 더 낮은 상한성 (GC Timelier) 만 들어서 돌리자.
  • 47. 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를 세대별로 하는 방법.
  • 48. 제조사의 상황에 따라 다양한 전략들을 도입해 배포 가능함.
  • 49. L부터 Foreground / Background GC 로 구성함. Foreground gc (화면 담당) Background gc (백드라운드 담당)
  • 54. 왜 Foreground / Background GC 로 나누었을까? Foreground GC (화면 담당) Background GC (백드라운드 담당) • Foreground GC -> CMS (파편화보다 빠른 정리) 빠르게 정리되는 것이 중요. 화면이 빈번하게 변경되므로 생명 주기가 긴 객체가 없다. 파편화 이슈보다 빠르게 정 리가 중요 (화면은 자주 갱신되니) • Background GC (생명주기 긴 객체 -> 파편화) 항상 메모리에서 떠 있는 녀석들이 많다. 그만큼 생명주기 도 기니까 파편화가 많이 발생할수 있음. 속도보다는 memory compact 하는 녀석을 선택하는 것이 좋음.
  • 56. 줄어든 App Size, LOS/ ROS의 성공적인 도입, 멀티 코어 디바이스 확대
  • 57. Background gctype 은 언제든지 변경 (기본 gc 설정은 제조사 마음) • To disable background compaction do: • adb shell setprop dalvik.vm.backgroundgctype CMS • To enable: • adb shell setprop dalvik.vm.backgroundgctype SS
  • 58. 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
  • 60. Vsync 란 (60fps = 16ms의 중요성)
  • 61. Android 3.0 이전 뷰의 부분 변경을 해결하기 위해 cascading하여 그렸음.
  • 62. Android 3.0 이후 Display List 도입으로 ViewRoot에 방문없이, 쉽게 변경 내용을 업데이트할수 있음.
  • 63. Android 3.0 이후 ­ HW Acceleration 도입 + ICS부터 기본으로 적용 hardware layer 동시 사용도 필수 https://developer.android.com/guide/topics/graphics/hardware-accel.html http://blog.danlew.net/2015/10/20/using-hardware-layers-to-improve-animation-performance/
  • 64. Android 5.0 이후 ­ material design 도 입 Material 의 animation 효과 어떻게 하지? 자 그럼 이제 GPU를 사용해 CPU 부하 줄이자 (RenderThread도입)
  • 65. Android 4와 5의 CPU 부하 비교
  • 66. UI Thread 와 RenderThread의 관계
  • 67. #2.3 CPU/ GPU Throttling
  • 70. 시사점.. CPU Governor 정책에 의해. CPU가 뜨거워지면 -> 절전 모드로.. 밧데리를 아끼기 위해 일이 없으면 -> 천천히 돌아가게.. 개발자 입장에서는 내 앱이 최적의 상황에서만. 돌길 바랄뿐. *cpu/gpu governor 정리자료 http://ajgupta.github.io/android/2015/01/28/CPU-and- GPU-governors/
  • 72. CPU, UI Rendering 만큼 신경써야 하는 영역.. 우리가 간과하는 큰 부분이 있습니다. 심지어 프로파일러 마저도.. 없는 영역?? I/O
  • 73. 모바일 스토리지 종류에 따라 차이나는 IO 성능
  • 74. 4kb 에 랜덤 읽기 / 쓰기 속도
  • 75. 4kb에 빠르다고 해서 256kb도 빠른게 아니 다
  • 77. 시사점.. Database, File I/O Benchmark Test의 의미가 무색.. 하나의 디바이스에서 매겨진 랭킹이. 다른 디바이스에서 동일하다는 보장이 없다.. 또한 나의 앱이 IO를 쓸따 다른 앱이 IO를 안쓴다는 보 장도 없다.. 직접 case by case 다 보셔야 한다.. (정말 가능?)
  • 78. 또 하나의 변수 .. Wear Leveling (웨 어 레벨링) Wear Leveling 전 Wear Leveling 후
  • 79. 시사점.. 화면을 16ms 안에 못 그려졌다면. 누구 책임인가? 데이터 읽기 / 쓰기 속도가 뒤죽 박죽 이라면 누구 책 임인가? 앱 개발자가 해결할수 있는 문제인가?..
  • 80. # 2.4. 이 모든 원인은 밧데리..
  • 81.
  • 82. 밧데리의 수명은 제한적 제조사의 고민 • 오래 사용하기 위해 전력 소비량을 낮추던가? • 동일한 전력을 계속 공급해 성능은 유지하지만, 2,3시간 만에 방전 되던가?
  • 83. 복잡한 다계층 시스템에 대해서 다시 생각해 보자. 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
  • 85. THANK YOU! ysson@onycom.com 성능에 관심있는 분은 KPPG (Korea Pattern & Performance Group) 페이스북 그룹으로..