DEVIEW 2014 [1D6]RE-view of Android L developer PRE-view

1. 이경민
LG전자
RE-viewofAndroid L DeveloperPRE-view

2. http://developer.android.com/preview/index.html

3. 1
http://developer.android.com/preview/index.html

4. 1
2
http://developer.android.com/preview/index.html

5. Material Design
Goals
-Create a visual language that synthesizes classic principles of good design with the innovation and possibility of technology and science.
-Develop a single underlying system that allows for a unified experience across platforms and device sizes. Mobile precepts are fundamental, but touch, voice, mouse, and keyboard are all first-class input methods.
Material is the metaphor
Bold, graphic, intentional
Motionprovides meaning
Principles
http://www.google.com/design/spec/material-design/introduction.html

6. Android Runtime
https://android-review.googlesource.com/#/c/98553/ https://android-review.googlesource.com/#/c/98374/

7. Android Runtime
https://android-review.googlesource.com/#/c/98553/ https://android-review.googlesource.com/#/c/98374/
Dalvikis dead, long live Dalvik! DO NOT MERGE

8. Android Runtime
https://android-review.googlesource.com/#/c/98553/ https://android-review.googlesource.com/#/c/98374/
Dalvikis dead, long live Dalvik! DO NOT MERGE

9. Android Runtime
https://android-review.googlesource.com/#/c/98553/ https://android-review.googlesource.com/#/c/98374/
Dalvikis dead, long live Dalvik! DO NOT MERGE

10. Key Architectural Changes in L

11. Key Architectural Changes in L
①UI Threading Model
Single UI (Main) Thread UI & Render Thread

12. Key Architectural Changes in L
①UI Threading Model
Single UI (Main) Thread UI & Render Thread
②VM Execution Model
Just-In-Time Compilation Ahead-Of-Time Compilation

13. Key Architectural Changes in L
①UI Threading Model
Single UI (Main) Thread UI & Render Thread
②VM Execution Model
Just-In-Time Compilation Ahead-Of-Time Compilation
③Garbage Collection Model
Less and shorter pauses and less fragmentation

14. Agenda
①UI Threading Model
Single UI (Main) Thread UI & Render Thread
②VM Execution Model
Just-In-Time Compilation Ahead-Of-Time Compilation
③Garbage Collection Model
Less and shorter pauses and less fragmentation

15. Render Thread in L
http://www.youtube.com/watch?v=3TtVsy98ces
①
①
②

16. Render Thread in L
http://www.youtube.com/watch?v=3TtVsy98ces
②

17. Render Thread in L
http://www.youtube.com/watch?v=3TtVsy98ces

18. Render Thread in L
http://www.youtube.com/watch?v=3TtVsy98ces
One of the most exciting topics that was glossed over was the introduction of a dedicatedrender thread. The goal of the render threadis to take many of the atomic animationsintroduced with material designand perform them autonomously, so they don’t hold up the primary UI toolkit thread.
Source: http://www.willowtreeapps.com/blog/google-io-from-the- trenches-android-l-and-material-design/

19. UI (Main) Thread
Activity
ThreadHelloAndroid.apk
Activity
Looper
Message
Queue
Service
BroadcastReceiver
ContentProvider
H
handleMessage()
ViewRootImpl
handleMessage()
TLS
Threaded
Task
Binder
Object
Storage
(File,Prefs,DB,Network)
Window
Android
Manifest.xml
Resources
Intent
Views
Views
Views
Application
Instrumentation test.apk
Test Case

20. Looper, Message Queue, and Handler

21. GPUI -UI on the GPU (Honeycomb~)
Source: Google I/O 2011 –Accelerated Android Rendering

22. GPUI -UI on the GPU (Honeycomb~)
Source: Google I/O 2011 –Accelerated Android Rendering
CPU Rasterization
GPU Composition

23. GPUI -UI on the GPU (Honeycomb~)
Increased Number of Pixels
Source: Google I/O 2011 –Accelerated Android Rendering
CPU Rasterization
GPU Composition

24. GPUI -UI on the GPU (Honeycomb~)
Increased Number of Pixels
Source: Google I/O 2011 –Accelerated Android Rendering
CPU Rasterization
GPU Composition
GPU RasterizationGPU Composition

25. GPUI -UI on the GPU (Honeycomb~)
GPUI
Display List
View Layers
Display List Properties
Increased Number of Pixels
Source: Google I/O 2011 –Accelerated Android Rendering
…
CPU Rasterization
GPU Composition
GPU RasterizationGPU Composition

26. Display List
A display list records a series of graphics related operation and can replay them later.
Display lists are usually built by recording operations on a android.graphics.Canvas.
Replaying the operations from a display list avoids executing views drawing code on every
frame, and is thus much more efficient.
DisplayList::Op[Non-Drawing]
<<enumeration>>
+Sav e
+Restore
+RestoreToCount
+Sav eLayer
+Sav eLayerAlpha
+Translate
+Rotate
+Scale
+Skew
+SetMatrix
+ConcatMatrix
+ClipRect
DisplayList::Op[Drawing]
<<enumeration>>
+DrawDisplayList
+DrawLayer
+DrawBitmap
+DrawBitmapMatrix
+DrawBitmapRect
+DrawBitmapData
+DrawBitmapMesh
+DrawPatch
+DrawColor
+DrawRect
+DrawRoundRect
+DrawCircle
+DrawOv al
+DrawArc
+DrawPath
+DrawLines
+DrawPoints
+DrawText
+DrawTextOnPath
+DrawPosText
+ResetShader
+SetupShader
+ResetColorFilter
+SetupColorFilter
+ResetShadow
+SetupShadow
+ResetPaintFilter
+SetupPaintFilter
+DrawGLFunction
OpenGLRenderer
drawDisplayList(…)
DisplayList
replay(…)
DisplayListRenderer
draw*(…, SkPaint)
void* buffer
SkWriter32
write*(…)
SkReader32
read*()
GLES20RecordingCanvas
draw*(…, Paint)
android_view_
GLES20Canvas_draw*(…)
GLES20Canvas
drawDisplayList(…)
draw*(…, SkPaint)
GLES2/gl2.h
glXXX(…)
Source: 10th Kandroid Conference – Skia and FreeType: Android 2D Graphics Essentials

27. Display List
A display list records a series of graphics related operation and can replay them later.
Display lists are usually built by recording operations on a android.graphics.Canvas.
Replaying the operations from a display list avoids executing views drawing code on every
frame, and is thus much more efficient.
DisplayList::Op[Non-Drawing]
<<enumeration>>
+Sav e
+Restore
+RestoreToCount
+Sav eLayer
+Sav eLayerAlpha
+Translate
+Rotate
+Scale
+Skew
+SetMatrix
+ConcatMatrix
+ClipRect
DisplayList::Op[Drawing]
<<enumeration>>
+DrawDisplayList
+DrawLayer
+DrawBitmap
+DrawBitmapMatrix
+DrawBitmapRect
+DrawBitmapData
+DrawBitmapMesh
+DrawPatch
+DrawColor
+DrawRect
+DrawRoundRect
+DrawCircle
+DrawOv al
+DrawArc
+DrawPath
+DrawLines
+DrawPoints
+DrawText
+DrawTextOnPath
+DrawPosText
+ResetShader
+SetupShader
+ResetColorFilter
+SetupColorFilter
+ResetShadow
+SetupShadow
+ResetPaintFilter
+SetupPaintFilter
+DrawGLFunction
OpenGLRenderer
drawDisplayList(…)
DisplayList
replay(…)
DisplayListRenderer
draw*(…, SkPaint)
void* buffer
SkWriter32
write*(…)
SkReader32
read*()
GLES20RecordingCanvas
draw*(…, Paint)
android_view_
GLES20Canvas_draw*(…)
GLES20Canvas
drawDisplayList(…)
draw*(…, SkPaint)
GLES2/gl2.h
glXXX(…)
Source: 10th Kandroid Conference – Skia and FreeType: Android 2D Graphics Essentials

28. Display List: An Example
DrawDisplayList
DrawPatch
Save
Translate
ConcatMatrix
DrawBitmap
RestoreToCount
$ adbshell dumpsysgfxinfo[pid|pname]
JB (API Level 18)
Source: 12thKandroid Conference –Terminology and History of Android Performance Features

29. Android Animation
DrawableAnimation
Frame(-by-Frame) Animation
View Animation
Tween(ed)Animation
Property Animation
What
Showing a sequence of images in order
Performing a series of transformations on a single image
Modifying an object's property values over a set period of time
Added/
Updated
1
1, 4
11, 16,18, 19
APIs
android.graphics.drawable.
AnimationDrawable
android.view.animation.*
android.animation.*
(2011/02) Animation in Honeycombhttp://android-developers.blogspot.kr/2011/02/animation-in-honeycomb.html
(2011/05) Introducing ViewPropertyAnimatorhttp://android-developers.blogspot.kr/2011/05/introducing-viewpropertyanimator.html
(2011/11) Android 4.0 Graphics and Animationshttp://android-developers.blogspot.kr/2011/11/android-40-graphics-and-animations.html
Source: 13thKandroid MinMax–Silky Rendering Choreographer and Animation

30. Property Animation (Pre-Jellybean)
Source: 13thKandroid MinMax–Silky Rendering Choreographer and Animation
ValueAnimator
doAnimationFrame()
TimeInterpolatorgetInterpolation()
Elapsed Fraction
TypeEvaluator
evaluate()
Interpolated Fraction
Current Value
Frame Time
( Frame Time –Start Time ) / Duration
Math.pow( Elapsed Fraction, 2 Factor )
e.g., AccelerateInterpolator
AnimatorUpdateListener
onAimationUpdate()
Start Value+ ( End Value–Start Value )  Interpolated Fraction
Thread Local Storage
sendEmptyMessageDelayed() w/ ANIMATION_FRAME
handleMessage()
sendEmptyMessage() w/ ANIMATION_START
AnimationHandler
start()
1
2
3
4
5
6
7
8

31. Drawing w/ Single UI Thread
Activity
SurfaceFlinger
Event
Set Property
Value
Invalidate
Measure &
Layout
Prepare
Draw
Update
DisplayList
Draw
DisplayList
Swap
Buffers
Display
List
Dequeue
Buffer
Composite
Windows
Post
Buffer
Enqueue
Buffer
Something
Happens
Draw
Display

32. Drawing w/ UI & Render Threads
Activity
SurfaceFlinger
Event
Set Property
Value
Invalidate
Measure &
Layout
Prepare
Draw
Update
DisplayList
Draw
DisplayList
Swap
Buffers
Display
List
Dequeue
Buffer
Composite
Windows
Post
Buffer
Enqueue
Buffer
Something
Happens
Draw
Display
Render Thread

33. Threads in Action
Threads in KitKat

34. Threads in Action
Threads in KitKat

35. Threads in Action
Threads in KitKat
Threads in L

36. Threads in Action
Threads in KitKat
Threads in L

37. Food for Further Review

38. Food for Further Review
Comparison w/ Other Technology/Platforms

39. Food for Further Review
Comparison w/ Other Technology/Platforms
•Windows Phone: UI & Compositor Thread, Storyboard-based vs. Timer-based Animationshttp://blogs.telerik.com/windowsphoneteam/posts/10-12-13/ui-vs-compositor-demystifying-the- main-windows-phone-7-os-threads.aspx

40. Food for Further Review
Comparison w/ Other Technology/Platforms
•Windows Phone: UI & Compositor Thread, Storyboard-based vs. Timer-based Animationshttp://blogs.telerik.com/windowsphoneteam/posts/10-12-13/ui-vs-compositor-demystifying-the- main-windows-phone-7-os-threads.aspx
•Web Animations: Javascript-based vs. CSS-basedhttp://www.html5rocks.com/en/tutorials/speed/high-performance-animations/

41. Food for Further Review
Comparison w/ Other Technology/Platforms
•Windows Phone: UI & Compositor Thread, Storyboard-based vs. Timer-based Animationshttp://blogs.telerik.com/windowsphoneteam/posts/10-12-13/ui-vs-compositor-demystifying-the- main-windows-phone-7-os-threads.aspx
•Web Animations: Javascript-based vs. CSS-basedhttp://www.html5rocks.com/en/tutorials/speed/high-performance-animations/
Implications to Application Developers

42. Food for Further Review
Comparison w/ Other Technology/Platforms
•Windows Phone: UI & Compositor Thread, Storyboard-based vs. Timer-based Animationshttp://blogs.telerik.com/windowsphoneteam/posts/10-12-13/ui-vs-compositor-demystifying-the- main-windows-phone-7-os-threads.aspx
•Web Animations: Javascript-based vs. CSS-basedhttp://www.html5rocks.com/en/tutorials/speed/high-performance-animations/
Implications to Application Developers
•Property Animation vs. Atomic Animation?

43. Agenda
①UI Threading Model
Single UI (Main) Thread UI & Render Thread
②VM Execution Model
Just-In-Time Compilation Ahead-Of-Time Compilation
③Garbage Collection Model
Less and shorter pauses and less fragmentation

44. Performance Boosting Thing

45. “Can u guys add some performance boosting thing on the next version”
Performance Boosting Thing

46. “Can u guys add some performance boosting thing on the next version”
Performance Boosting Thing

47. “Can u guys add some performance boosting thing on the next version”
Performance Boosting Thing

48. “Can u guys add some performance boosting thing on the next version”
Performance Boosting Thing

49. PBT == ART
Source: Google I/O 2014 –The ART Runtime

50. PBT == ART
Ahead-Of-Time (AOT)
Source: Google I/O 2014 –The ART Runtime

51. PBT == ART
Ahead-Of-Time (AOT)
Garbage Collection
Source: Google I/O 2014 –The ART Runtime

52. PBT == ART
Ahead-Of-Time (AOT)
Garbage Collection
64-bit Support
Source: Google I/O 2014 –The ART Runtime

53. DalvikVM: Register-based
※Stack, Accumulator, Register machine
Stackmachine : 0-operand instruction set
Accumulatormachine : 1-operand …
Registermachine : 2 or 3-operand …
000b: iload05
000d: iload04
000f: if_icmpge0024
0012: aload_3
0013: iload05
0015: iaload
0016: istore06
0018: lload_1
0019: iload06
001b: i2l
001c: ladd
001d: lstore_1
001e: iinc05, #+01
0021: goto000b
0007: if-gev0, v2, 0010
0009: aget v1, v8, v0
000b: int-to-long v5, v1
000c: add-long/2addr v3, v5
000d: add-int/lit8 v0, v0, #int 1
000f: goto0007
Java VM(JVM) bytecode
Dalvik VM(DVM) bytecode
Items
JVM
DVM
bytes
25
18
dispatches
14
6
reads
45
19
writes
16
6
public static long sumArray(int[] arr) {
long sum = 0;
For (inti: arr) {
sum += i;
}
return sum;
}

54. Just-In-Time Compiler (Froyo~)
Source: Google I/O 2010 –A JIT Compiler for Android's DalvikVM

55. Just-In-Time Compiler (Froyo~)
Source: Google I/O 2010 –A JIT Compiler for Android's DalvikVM
When to Compile?
What to Compile?

56. AOT Compiler (L~)
Source: Google I/O 2014 –The ART Runtime

57. AOT Compiler (L~)
When to Compile?
What to Compile?
Source: Google I/O 2014 –The ART Runtime

58. .art / .oat / .odex
Source: Google I/O 2014 –The ART Runtime

59. AOT in Action
~
~
~

60. AOT in Action
~
~
~

61. AOT in Action
~
~
~

62. AOT in Action
~
~
~

63. AOT in Action
~
~
~

64. JIT vs. AOT
AOT
Jazelle®
•Ahead of Time Compilation
•WIPI의COD (Compile-on- demand) 방식
•Java bytecode를CPU가바로실행함. (arm/thumb/java mode)
JIT
•Just-in-Time Compilation소프트웨어가속하드웨어가속
•10x ~ 15x
•6x ~ 10x
•6x ~ 10x
•어플리케이션크기가커짐.
•프로파일링및컴파일시간이있어실행초기느려질수있음.
►모바일단말에서는JIT와Jazelle® 사용이일반화되어있음.
►어플리케이션크기가커지는것을제외하면, AOT 방식이최대성능을보일수있음.
Source: 1stkandroidSeminar–DalvikVM vs. Java VM (류혁곤님발표)

65. JIT vs. AOT
AOT
Jazelle®
•Ahead of Time Compilation
•WIPI의COD (Compile-on- demand) 방식
•Java bytecode를CPU가바로실행함. (arm/thumb/java mode)
JIT
•Just-in-Time Compilation소프트웨어가속하드웨어가속
•10x ~ 15x
•6x ~ 10x
•6x ~ 10x
•어플리케이션크기가커짐.
•프로파일링및컴파일시간이있어실행초기느려질수있음.
►모바일단말에서는JIT와Jazelle® 사용이일반화되어있음.
►어플리케이션크기가커지는것을제외하면, AOT 방식이최대성능을보일수있음.
Source: 1stkandroidSeminar–DalvikVM vs. Java VM (류혁곤님발표)
Speed/Space

66. JIT vs. AOT
AOT
Jazelle®
•Ahead of Time Compilation
•WIPI의COD (Compile-on- demand) 방식
•Java bytecode를CPU가바로실행함. (arm/thumb/java mode)
JIT
•Just-in-Time Compilation소프트웨어가속하드웨어가속
•10x ~ 15x
•6x ~ 10x
•6x ~ 10x
•어플리케이션크기가커짐.
•프로파일링및컴파일시간이있어실행초기느려질수있음.
►모바일단말에서는JIT와Jazelle® 사용이일반화되어있음.
►어플리케이션크기가커지는것을제외하면, AOT 방식이최대성능을보일수있음.
Source: 1stkandroidSeminar–DalvikVM vs. Java VM (류혁곤님발표)
Optimization Window
Speed/Space

67. JIT vs. AOT
AOT
Jazelle®
•Ahead of Time Compilation
•WIPI의COD (Compile-on- demand) 방식
•Java bytecode를CPU가바로실행함. (arm/thumb/java mode)
JIT
•Just-in-Time Compilation소프트웨어가속하드웨어가속
•10x ~ 15x
•6x ~ 10x
•6x ~ 10x
•어플리케이션크기가커짐.
•프로파일링및컴파일시간이있어실행초기느려질수있음.
►모바일단말에서는JIT와Jazelle® 사용이일반화되어있음.
►어플리케이션크기가커지는것을제외하면, AOT 방식이최대성능을보일수있음.
Source: 1stkandroidSeminar–DalvikVM vs. Java VM (류혁곤님발표)
Optimization Window
Memory Sharing
Speed/Space

68. Food for Further Review

69. Food for Further Review
Comparison w/ Other Technology/Platforms

70. Food for Further Review
Comparison w/ Other Technology/Platforms
•Mono: JIT and (Full) AOThttp://www.mono-project.com/docs/advanced/aot/

71. Food for Further Review
Comparison w/ Other Technology/Platforms
•Mono: JIT and (Full) AOThttp://www.mono-project.com/docs/advanced/aot/
•.NET: NGenhttp://blogs.msdn.com/b/clrcodegeneration/archive/2010/04/27/ngen-walk-through-series.aspxhttp://en.wikipedia.org/wiki/Native_Image_Generator

72. Food for Further Review
Comparison w/ Other Technology/Platforms
•Mono: JIT and (Full) AOThttp://www.mono-project.com/docs/advanced/aot/
•.NET: NGenhttp://blogs.msdn.com/b/clrcodegeneration/archive/2010/04/27/ngen-walk-through-series.aspxhttp://en.wikipedia.org/wiki/Native_Image_Generator
Implications to Application Developers

73. Food for Further Review
Comparison w/ Other Technology/Platforms
•Mono: JIT and (Full) AOThttp://www.mono-project.com/docs/advanced/aot/
•.NET: NGenhttp://blogs.msdn.com/b/clrcodegeneration/archive/2010/04/27/ngen-walk-through-series.aspxhttp://en.wikipedia.org/wiki/Native_Image_Generator
Implications to Application Developers
•Getter/Setter vs. Direct Access to Field?

74. Food for Further Review
Comparison w/ Other Technology/Platforms
•Mono: JIT and (Full) AOThttp://www.mono-project.com/docs/advanced/aot/
•.NET: NGenhttp://blogs.msdn.com/b/clrcodegeneration/archive/2010/04/27/ngen-walk-through-series.aspxhttp://en.wikipedia.org/wiki/Native_Image_Generator
Implications to Application Developers
•Getter/Setter vs. Direct Access to Field?
•Small vs. Large Method?

75. Food for Further Review
Comparison w/ Other Technology/Platforms
•Mono: JIT and (Full) AOThttp://www.mono-project.com/docs/advanced/aot/
•.NET: NGenhttp://blogs.msdn.com/b/clrcodegeneration/archive/2010/04/27/ngen-walk-through-series.aspxhttp://en.wikipedia.org/wiki/Native_Image_Generator
Implications to Application Developers
•Getter/Setter vs. Direct Access to Field?
•Small vs. Large Method?
•Java-only vs. JNI w/ C/C++?

76. Agenda
①UI Threading Model
Single UI (Main) Thread UI & Render Thread
②VM Execution Model
Just-In-Time Compilation Ahead-Of-Time Compilation
③Garbage Collection Model
Less and shorter pauses and less fragmentation

77. Changes in GC: WHY?

78. Changes in GC: WHY?
192MBRAM320X480
2008HTC G1

79. Changes in GC: WHY?
1GBRAM
1280X800
2011
Motorola Xoom
192MBRAM320X480
2008HTC G1

80. Changes in GC: WHY?
1GBRAM
1280X800
2011
Motorola Xoom
192MBRAM320X480
2008HTC G1
2GB/3GBRAM
2560X1440
2014LG G3

81. Changes in GC: WHY?
Bigger Heaps
1GBRAM
1280X800
2011
Motorola Xoom
192MBRAM320X480
2008HTC G1
2GB/3GBRAM
2560X1440
2014LG G3

82. Changes in GC: WHY?
Bigger Heaps
Longer GC Pauses
1GBRAM
1280X800
2011
Motorola Xoom
192MBRAM320X480
2008HTC G1
2GB/3GBRAM
2560X1440
2014LG G3

83. Changes in GC: WHY?
Bigger Heaps
Longer GC Pauses
Poor UI Responsiveness
1GBRAM
1280X800
2011
Motorola Xoom
192MBRAM320X480
2008HTC G1
2GB/3GBRAM
2560X1440
2014LG G3

84. Changes in GC: WHAT?

85. Changes in GC: WHAT?
Pre-Gingerbread
•Stop-the-world
•Full heap collection
•Pause time often > 100ms
Gingerbread to Kitkat
•Concurrent Mark and Sweep (CMS)
•Partial collections
•Pause time usually < 5ms
Source: Google I/O 2011 –Memory management for Android Apps

86. Changes in GC: WHAT?
Pre-Gingerbread
•Stop-the-world
•Full heap collection
•Pause time often > 100ms
Gingerbread to Kitkat
•Concurrent Mark and Sweep (CMS)
•Partial collections
•Pause time usually < 5ms
Source: Google I/O 2011 –Memory management for Android Apps
Serial vs. Parallel
Concurrent vs. Stop-The-World
Compacting vs. Non-compacting vs. Copying

87. Changes in GC: WHAT?
Pre-Gingerbread
•Stop-the-world
•Full heap collection
•Pause time often > 100ms
Gingerbread to Kitkat
•Concurrent Mark and Sweep (CMS)
•Partial collections
•Pause time usually < 5ms
Source: Google I/O 2011 –Memory management for Android Apps
Serial vs. Parallel
Concurrent vs. Stop-The-World
Compacting vs. Non-compacting vs. Copying
Source: http://www.somanyword.com/2014/01/how- memory-management-garbage-collector-works-in-java- and-difference-types-of-garbage-collectors-in-java/
http://www.slideshare.net/dougqh/understanding- garbage-collection
Understanding Garbage Collection

88. Changes in GC: WHAT?
L and Beyond
•One GC pauseinstead of two
•Parallelized processing during the remaining GC pause
•Background stickyconcurrent mark sweep GC: Collector with lower pause time for the special case of cleaning up recently-allocated, short-livedobjects
•Improved garbage collection ergonomics, making concurrent garbage collections more timely, which makes GC_FOR_ALLOC events extremely rare in typical use cases
Source: Introducing ART (https://source.android.com/devices/tech/dalvik/art.html)

89. Changes in GC: WHAT?
L and Beyond
•One GC pauseinstead of two
•Parallelized processing during the remaining GC pause
•Background stickyconcurrent mark sweep GC: Collector with lower pause time for the special case of cleaning up recently-allocated, short-livedobjects
•Improved garbage collection ergonomics, making concurrent garbage collections more timely, which makes GC_FOR_ALLOC events extremely rare in typical use cases
Source: Introducing ART (https://source.android.com/devices/tech/dalvik/art.html)
Source: http://en.wikipedia.org/wiki/Human_factors_and_ergonomics
인간공학(人間工學, ergonomics)이란인간과그들이사용하는물건과의상호작용을다루는학문이다. 인간공학은인간의기계화가아닌인간을위한공학(design for human)을말한다. 즉, 인간의행동, 능력, 한계, 특성등에관한정보를발견하고, 이를도구, 기계, 시스템, 과업, 직무, 환경을설계하는데응용함으로써인간이생산적이고안전하며쾌적한환경에서작업을하고물건을효과적으로이용할수있도록하는것이다.
[네이버지식백과] 인간공학[Ergonomics] (학문명백과: 공학, 형설출판사)

90. Changes in GC: WHAT?
L and Beyond
•One GC pauseinstead of two
•Parallelized processing during the remaining GC pause
•Background stickyconcurrent mark sweep GC: Collector with lower pause time for the special case of cleaning up recently-allocated, short-livedobjects
•Improved garbage collection ergonomics, making concurrent garbage collections more timely, which makes GC_FOR_ALLOC events extremely rare in typical use cases
Source: Introducing ART (https://source.android.com/devices/tech/dalvik/art.html)
Source: http://en.wikipedia.org/wiki/Human_factors_and_ergonomics
인간공학(人間工學, ergonomics)이란인간과그들이사용하는물건과의상호작용을다루는학문이다. 인간공학은인간의기계화가아닌인간을위한공학(design for human)을말한다. 즉, 인간의행동, 능력, 한계, 특성등에관한정보를발견하고, 이를도구, 기계, 시스템, 과업, 직무, 환경을설계하는데응용함으로써인간이생산적이고안전하며쾌적한환경에서작업을하고물건을효과적으로이용할수있도록하는것이다.
[네이버지식백과] 인간공학[Ergonomics] (학문명백과: 공학, 형설출판사)
Tuning Garbage Collection with the 5.0 Java[tm] Virtual Machine
http://www.oracle.com/technetwork/java/ gc-tuning-5-138395.html
Garbage Collector Ergonomicshttp://docs.oracle.com/javase/7/docs/technotes/ guides/vm/gc-ergonomics.html

91. Two Pauses One Pause
Source: Google I/O 2014 –The ART runtime

92. Two Pauses One Pause
Source: Google I/O 2014 –The ART runtime

93. Two Pauses One Pause
Source: Google I/O 2014 –The ART runtime

94. Long Pause for GC_FOR_ALLOC
Source: Google I/O 2014 –The ART runtime

95. Long Pause for GC_FOR_ALLOC
Source: Google I/O 2014 –The ART runtime

96. Reducing Heap Fragmentation
Source: Google I/O 2014 –The ART runtime

97. Reducing Heap Fragmentation
Source: Google I/O 2014 –The ART runtime

98. GC Logs
GC_HPROF_DUMP_HEAP freed 47K, 50% free 2730K/5379K, external 8825K/9762K, paused 2262ms
GC_EXPLICIT freed 39K, 49% free 3434K/6727K, external 1625K/2137K, paused 61ms
GC_EXTERNAL_ALLOC freed 113K, 48% free 2849K/5447K, external 2069K/2137K, paused 29ms
GC_FOR_MALLOC freed 672K, 46% free 4505K/8263K, external 1625K/2137K, paused 36ms
GC_EXPLICIT freed 298K,5% free 9395K/9820K, paused 5ms+4ms, total 46ms
GC_FOR_ALLOC freed 62K, 4% free 9981K/10356K, paused 14ms, total 14ms
GC_CONCURRENT freed 452K, 5% free 11442K/11924K, paused 2ms+3ms, total 32ms
GC_BEFORE_OOM freed <1K, 25% free 48653K/64327K, paused 20ms
Gingerbread
L Preview
Explicitconcurrent mark sweepGC
freed 65595(3MB) AllocSpaceobjects, 9(4MB) LOS objects, 810% free, 38MB/58MB,
paused 1.195mstotal 87.219ms
Backgroundpartialconcurrent mark sweepGC
freed 74626(3MB) AllocSpaceobjects, 39(4MB) LOS objects, 1496% free, 25MB/32MB,
paused 4.422mstotal 1.371747s
Backgroundstickyconcurrent mark sweepGC
freed 70319(3MB) AllocSpaceobjects, 59(5MB) LOS objects, 825% free, 49MB/56MB,
paused 6.139mstotal 52.868ms
Source : http://www.anandtech.com/show/8231/a-closer-look-at-android-runtime-art-in-android-l/2

99. GC Logs
GC_HPROF_DUMP_HEAP freed 47K, 50% free 2730K/5379K, external 8825K/9762K, paused 2262ms
GC_EXPLICIT freed 39K, 49% free 3434K/6727K, external 1625K/2137K, paused 61ms
GC_EXTERNAL_ALLOC freed 113K, 48% free 2849K/5447K, external 2069K/2137K, paused 29ms
GC_FOR_MALLOC freed 672K, 46% free 4505K/8263K, external 1625K/2137K, paused 36ms
GC_EXPLICIT freed 298K,5% free 9395K/9820K, paused 5ms+4ms, total 46ms
GC_FOR_ALLOC freed 62K, 4% free 9981K/10356K, paused 14ms, total 14ms
GC_CONCURRENT freed 452K, 5% free 11442K/11924K, paused 2ms+3ms, total 32ms
GC_BEFORE_OOM freed <1K, 25% free 48653K/64327K, paused 20ms
Gingerbread
L Preview
Explicitconcurrent mark sweepGC
freed 65595(3MB) AllocSpaceobjects, 9(4MB) LOS objects, 810% free, 38MB/58MB,
paused 1.195mstotal 87.219ms
Backgroundpartialconcurrent mark sweepGC
freed 74626(3MB) AllocSpaceobjects, 39(4MB) LOS objects, 1496% free, 25MB/32MB,
paused 4.422mstotal 1.371747s
Backgroundstickyconcurrent mark sweepGC
freed 70319(3MB) AllocSpaceobjects, 59(5MB) LOS objects, 825% free, 49MB/56MB,
paused 6.139mstotal 52.868ms
Source : http://www.anandtech.com/show/8231/a-closer-look-at-android-runtime-art-in-android-l/2
GC Cause
•Alloc
•Background
•Explicit
•NativeAlloc
•CollectorTransition
•DisableMovingGc
•HomogeneousSpaceCompact
•HeapTrim

100. GC Logs
GC_HPROF_DUMP_HEAP freed 47K, 50% free 2730K/5379K, external 8825K/9762K, paused 2262ms
GC_EXPLICIT freed 39K, 49% free 3434K/6727K, external 1625K/2137K, paused 61ms
GC_EXTERNAL_ALLOC freed 113K, 48% free 2849K/5447K, external 2069K/2137K, paused 29ms
GC_FOR_MALLOC freed 672K, 46% free 4505K/8263K, external 1625K/2137K, paused 36ms
GC_EXPLICIT freed 298K,5% free 9395K/9820K, paused 5ms+4ms, total 46ms
GC_FOR_ALLOC freed 62K, 4% free 9981K/10356K, paused 14ms, total 14ms
GC_CONCURRENT freed 452K, 5% free 11442K/11924K, paused 2ms+3ms, total 32ms
GC_BEFORE_OOM freed <1K, 25% free 48653K/64327K, paused 20ms
Gingerbread
L Preview
Explicitconcurrent mark sweepGC
freed 65595(3MB) AllocSpaceobjects, 9(4MB) LOS objects, 810% free, 38MB/58MB,
paused 1.195mstotal 87.219ms
Backgroundpartialconcurrent mark sweepGC
freed 74626(3MB) AllocSpaceobjects, 39(4MB) LOS objects, 1496% free, 25MB/32MB,
paused 4.422mstotal 1.371747s
Backgroundstickyconcurrent mark sweepGC
freed 70319(3MB) AllocSpaceobjects, 59(5MB) LOS objects, 825% free, 49MB/56MB,
paused 6.139mstotal 52.868ms
Source : http://www.anandtech.com/show/8231/a-closer-look-at-android-runtime-art-in-android-l/2
GC Cause
•Alloc
•Background
•Explicit
•NativeAlloc
•CollectorTransition
•DisableMovingGc
•HomogeneousSpaceCompact
•HeapTrim
GC Type
•Sticky
•Partial
•Full

101. GC Logs
GC_HPROF_DUMP_HEAP freed 47K, 50% free 2730K/5379K, external 8825K/9762K, paused 2262ms
GC_EXPLICIT freed 39K, 49% free 3434K/6727K, external 1625K/2137K, paused 61ms
GC_EXTERNAL_ALLOC freed 113K, 48% free 2849K/5447K, external 2069K/2137K, paused 29ms
GC_FOR_MALLOC freed 672K, 46% free 4505K/8263K, external 1625K/2137K, paused 36ms
GC_EXPLICIT freed 298K,5% free 9395K/9820K, paused 5ms+4ms, total 46ms
GC_FOR_ALLOC freed 62K, 4% free 9981K/10356K, paused 14ms, total 14ms
GC_CONCURRENT freed 452K, 5% free 11442K/11924K, paused 2ms+3ms, total 32ms
GC_BEFORE_OOM freed <1K, 25% free 48653K/64327K, paused 20ms
Gingerbread
L Preview
Explicitconcurrent mark sweepGC
freed 65595(3MB) AllocSpaceobjects, 9(4MB) LOS objects, 810% free, 38MB/58MB,
paused 1.195mstotal 87.219ms
Backgroundpartialconcurrent mark sweepGC
freed 74626(3MB) AllocSpaceobjects, 39(4MB) LOS objects, 1496% free, 25MB/32MB,
paused 4.422mstotal 1.371747s
Backgroundstickyconcurrent mark sweepGC
freed 70319(3MB) AllocSpaceobjects, 59(5MB) LOS objects, 825% free, 49MB/56MB,
paused 6.139mstotal 52.868ms
Source : http://www.anandtech.com/show/8231/a-closer-look-at-android-runtime-art-in-android-l/2
GC Cause
•Alloc
•Background
•Explicit
•NativeAlloc
•CollectorTransition
•DisableMovingGc
•HomogeneousSpaceCompact
•HeapTrim
GC Type
•sticky
•partial
•(full)
Collector Type
•mark sweep
•concurrent mark sweep
•mark compact
•marksweep+ semispace
•concurrent copying + mark sweep

102. GC Logs
GC_HPROF_DUMP_HEAP freed 47K, 50% free 2730K/5379K, external 8825K/9762K, paused 2262ms
GC_EXPLICIT freed 39K, 49% free 3434K/6727K, external 1625K/2137K, paused 61ms
GC_EXTERNAL_ALLOC freed 113K, 48% free 2849K/5447K, external 2069K/2137K, paused 29ms
GC_FOR_MALLOC freed 672K, 46% free 4505K/8263K, external 1625K/2137K, paused 36ms
GC_EXPLICIT freed 298K,5% free 9395K/9820K, paused 5ms+4ms, total 46ms
GC_FOR_ALLOC freed 62K, 4% free 9981K/10356K, paused 14ms, total 14ms
GC_CONCURRENT freed 452K, 5% free 11442K/11924K, paused 2ms+3ms, total 32ms
GC_BEFORE_OOM freed <1K, 25% free 48653K/64327K, paused 20ms
Gingerbread
L Preview
Explicitconcurrent mark sweepGC
freed 65595(3MB) AllocSpaceobjects, 9(4MB) LOS objects, 810% free, 38MB/58MB,
paused 1.195mstotal 87.219ms
Backgroundpartialconcurrent mark sweepGC
freed 74626(3MB) AllocSpaceobjects, 39(4MB) LOS objects, 1496% free, 25MB/32MB,
paused 4.422mstotal 1.371747s
Backgroundstickyconcurrent mark sweepGC
freed 70319(3MB) AllocSpaceobjects, 59(5MB) LOS objects, 825% free, 49MB/56MB,
paused 6.139mstotal 52.868ms
Source : http://www.anandtech.com/show/8231/a-closer-look-at-android-runtime-art-in-android-l/2
GC Cause
•Alloc
•Background
•Explicit
•NativeAlloc
•CollectorTransition
•DisableMovingGc
•HomogeneousSpaceCompact
•HeapTrim
GC Type
•sticky
•partial
•(full)
Collector Type
•mark sweep
•concurrent mark sweep
•mark compact
•marksweep+ semispace
•concurrent copying + mark sweep

103. Food for Further Review

104. Food for Further Review
Comparison w/ Other Technology/Platforms

105. Food for Further Review
Comparison w/ Other Technology/Platforms
•Mono: SGen Garbage Collectorhttp://www.mono-project.com/docs/advanced/garbage-collector/sgen/

106. Food for Further Review
Comparison w/ Other Technology/Platforms
•Mono: SGen Garbage Collectorhttp://www.mono-project.com/docs/advanced/garbage-collector/sgen/
•V8: Stop-the-world, Generational, Accurate Garbage Collectorhttps://developers.google.com/v8/design#garb_coll

107. Food for Further Review
Comparison w/ Other Technology/Platforms
•Mono: SGen Garbage Collectorhttp://www.mono-project.com/docs/advanced/garbage-collector/sgen/
•V8: Stop-the-world, Generational, Accurate Garbage Collectorhttps://developers.google.com/v8/design#garb_coll
•Blink: Garbage Collection for Blink C++ objects (a.k.a. Oilpan) http://www.chromium.org/blink/blink-gc

108. Food for Further Review
Comparison w/ Other Technology/Platforms
•Mono: SGen Garbage Collectorhttp://www.mono-project.com/docs/advanced/garbage-collector/sgen/
•V8: Stop-the-world, Generational, Accurate Garbage Collectorhttps://developers.google.com/v8/design#garb_coll
•Blink: Garbage Collection for Blink C++ objects (a.k.a. Oilpan) http://www.chromium.org/blink/blink-gc
Implications to Application Developers

109. Food for Further Review
Comparison w/ Other Technology/Platforms
•Mono: SGen Garbage Collectorhttp://www.mono-project.com/docs/advanced/garbage-collector/sgen/
•V8: Stop-the-world, Generational, Accurate Garbage Collectorhttps://developers.google.com/v8/design#garb_coll
•Blink: Garbage Collection for Blink C++ objects (a.k.a. Oilpan) http://www.chromium.org/blink/blink-gc
Implications to Application Developers
•Primitive Values vs. Tiny/Short-lived Objects?

110. Food for Further Review
Comparison w/ Other Technology/Platforms
•Mono: SGen Garbage Collectorhttp://www.mono-project.com/docs/advanced/garbage-collector/sgen/
•V8: Stop-the-world, Generational, Accurate Garbage Collectorhttps://developers.google.com/v8/design#garb_coll
•Blink: Garbage Collection for Blink C++ objects (a.k.a. Oilpan) http://www.chromium.org/blink/blink-gc
Implications to Application Developers
•Primitive Values vs. Tiny/Short-lived Objects?
•Explicit GC w/ System.gc()?

111. Food for Further Review
Comparison w/ Other Technology/Platforms
•Mono: SGen Garbage Collectorhttp://www.mono-project.com/docs/advanced/garbage-collector/sgen/
•V8: Stop-the-world, Generational, Accurate Garbage Collectorhttps://developers.google.com/v8/design#garb_coll
•Blink: Garbage Collection for Blink C++ objects (a.k.a. Oilpan) http://www.chromium.org/blink/blink-gc
Implications to Application Developers
•Primitive Values vs. Tiny/Short-lived Objects?
•Explicit GC w/ System.gc()?
•JNI Code Incompatible with Compacting GC

112. Summary
①UI Threading Model
Single UI (Main) Thread UI & Render Thread
②VM Execution Model
Just-In-Time Compilation Ahead-Of-Time Compilation
③Garbage Collection Model
Less and shorter pauses and less fragmentation

113. Summary
①UI Threading Model
Single UI (Main) Thread UI & Render Thread
②VM Execution Model
Just-In-Time Compilation Ahead-Of-Time Compilation
③Garbage Collection Model
Less and shorter pauses and less fragmentation
(Software) Engineering is all about

114. Summary
①UI Threading Model
Single UI (Main) Thread UI & Render Thread
②VM Execution Model
Just-In-Time Compilation Ahead-Of-Time Compilation
③Garbage Collection Model
Less and shorter pauses and less fragmentation
(Software) Engineering is all about
TRADE-OFF!!!

115. Q&A
THANK YOU