14
The other main interesting interaction in the UI
is tracking your finger
-- scrolling and flinging a list, swiping a gallery, etc.
UI에서 이루어지는 또다른 중요하고 흥미로운 상호작용중에 하나는
바로 이용자의 손가락의 움직임을 추적한다는 것입니다. -- 스크롤하는 것,
목록을 fling하는 것(??), 앨범을 슥슥 넘기는 것(swipe?) 등등
These interactions involve updating the contents inside of a window,
so require re-rendering that window
for each movement.
이러한 상호작용을 하려면
창 안에있는 내용을 업데이트해줘야 합니다.
그래서 매번 움직임이 있을 때마다 그 창을 다시 렌더링하는 작업이 필요하게 됩니다.
However, being able to do this rendering off the main thread
probably doesn’t gain you much.
하지만 이렇게 주요 쓰레드를 render off(??)할 수 있게 된다고 해서 얻는 것이 많지는 않습니다.
These are not simple “move this part of the UI from X to Y,
and maybe tell me when you are done” animations
이런 작업은 "UI의 이 부분을 X에서 Y로 옮긴 후 완료되면 알려줘라" 같은 단순한 작업이 아닙니다.
-- each movement is based on events
received about the finger on the screen,
which need to be processed
by the application on its main thread.
--- 모든 움직임은
화면을 터치한 손가락에 대한 이벤트에 근거합니다.(??).
이 이벤트들은 어플리케이션이 메인 쓰레드에서 처리해주어야 하죠.
(내용을 도무지 못 따라가겠네요 ㅜㅜ 몬말인지가 잘.. 프로그래밍하시는 분들은 몬 말인지 이해하시나욤 --a)
15
That said,
being able to avoid redrawing all of the contents
of the parts of the UI that are moving
can help performance.
UI중에서 움직이는 부분 안에 있는 모든 내용을 매번 다시 그려주지 않아도 되면, 성능면에서 도움이 됩니다.
And this is also a technique
that Android has employed since before 1.0;
이것은 안드로이드가 1.0버전 이전부터 도입해온 기법이기도 합니다.
UI elements like a ListView
that want to scroll their content
can call
http://developer.android.com/reference/android/view/View.html#setDrawingCacheEnabled(boolean)
to have that content rendered into a cache
so that only the bitmap needs to be drawn as it moves.
ListView(목록 보여주는..) 같은 UI 엘리먼트들은 그안에 들어있는 내용을 스크롤해야 하는데,
setDrawingCacheEnabled라는 것을 호출해서 그 안의 내용을 cache안에다가 render해둔다음에,
움직일 때마다 bitmap만 다시 그려주면 됩니다.
16
Traditionally on Android,
views only have their drawing cache
enabled as a transient(일시적인) state,
such as while scrolling or tracking a finger.
전통적으로 안드로이드에서는,
view(보여주는 엘리먼트??)만이 그려주는 cache(drawing cache)를 갖고 있는데요,
이 drawing cache는 스크롤을 할 때라든지, 손가락의 움직임을 추적할 때 등,
일시적인 상태에서만 쓸 수 있는 상태가 됩니다.
This is because
they introduce a fair amount more overhead:
extra memory for the bitmap
(which can easily total to multiple times
larger than the actual frame buffer
if there are a number of visual layers),
이렇게 하는(일시적인 상태에서만 enabled되게하는??) 이유는 뭐냐면요
이것을 쓰면(drawing cache??) 부하가 많이 걸리기 때문입니다.
비트맵 용으로 추가적인 메모리가 필요하게 되죠.
and when the contents inside of a cached view
need to be redrawn
it is more expensive
because there is an additional step
required to draw the cached bitmap back to the window.
그리고 cached된 view안에 있는 내용을 다시 그려야 하는 상황이 되면,
메모리가 더 많이 필요하게 됩니다.
왜냐하면 cached된 비트맵을 도로 창에다가 그리는데 또 추가적인 작업이 필요하기 때문이죠.
17
So, all those things considered,
in Android 1.0
having
each view
drawn into a texture
and those textures
composited to the window in another thread
is just not that much of a gain,
with a lot of cost.
그래서, 모든 것을 고려하면, 안드로이드 1.0에서
각각의 뷰(view)가 texture에 그려지게 하는 것, 그리고 이 texture가 또 다른 쓰레드에서 창에서 혼합되게 하는 방식으로는 얻는 것은 없으면서 비용만 높은 방법입니다.
The cost is also in engineering time
-- our time was better spent
working on other things like
a layout-based view hierarchy
(to provide flexibility in adjusting for different screen sizes)
and “remote views”
for notifications and widgets,
which have significantly benefited the platform as it develops.
엔지니어하는데 들어가는 시간도 비용이라고 할 수 있죠.
-- 개발자의 시간은 layout-based view hierarchy(여러가지 화면 사이즈에서 잘 보이도록 하는..)나
"remote view(알림이나 위젯용)"같은 것 관련 작업에 쓰는 편이 훨씬 좋습니다. 알림이나 위젯 등은 (안드로이드)플랫폼이 발전하면서 큰 이득을 봤죠.
