2012/07/19

Nexus 7은 흥미로운 화면크기를 가졌습니다.

안드로이드 프래임웍의 어머니인 Dianne Hackborn
https://plus.google.com/105051985738280261832/posts/6eWwQvFGLV8 에 대한 번역글 입니다.

Nexus 7은 흥미로운 화면크기를 가졌습니다.


  • 7 인치.
  • 800x1280.
  • "tvdpi" density (수치로 보면 213).
  • dp단위로는 600 x 961


먼저 화면크기에 대해 이야기해보죠. raw해상도를 무시하면 이것은 보통의 7인치 타블랫과 마찬가지가지인 7" 타블랫입니다. 600x1024 화면을 가지는 몇몇 7"타블랫이 있긴한데 그것들은 다른 density(mdpi)를 가지고 있습니다. Density로만 따지면 우린 동일한 화면 공간을 가지고 있습니다. 600x961 또는 600x1024는 각각 16:10 또는 16:9 화면의 차이일 뿐입니다.



가장 크게보면, 최신 안드로이드 화면을 분류하는 기준인 "작은 화면 폭"의 정의의 측면에서 이들은 모두 -sw600dp입니다.

몇몇 분들이 Nexus 7인 10"UI의 화면 사이즈를 그져 화면 크기만 줄인게 아니다라는 글을 남기셨네요. 어느 정도 사실입니다. 물론 큰 화면의 phone UI도 아닙니다. 시스템과 앱에서는 각각 가장 최적으로 동작하는 UI를 사용합니다. 예를 들어 시스템 UI(Status bar나 Navigation bar, 설정화면)에서는 600dp화면에서 너무 조밀하기 때문에 Phone UI를 사용합니다. 다른 앱들은 타블랫 UI를 섞어 사용합니다. -- 예를 들면 Gmail앱은 대화목록에서는 타블랫 UI를 사용하고 메시지 화면에서는 가로모드, 세로모드에 따라서 각각 폰과 같은 단일 pane UI, 타블랫과 같은 dual-pane 을 사용합니다.

기존의 PhoneUI을 확대시켜 큰 화면을 지원하려는 개발자에게는 이것은 화면 구성의 큰 변혁이 일어나야 한다는 걸 의미합니다. 그리고 layout 담당자에게 모든 사이즈를 살펴보도록 해야합니다. 만약 UI가 600dp 화면에 적합한 크기라면 -sw600dp를 사용하세요. 만약 크거나 작은 공간이 필요하다면 다른 width를 사용하세요. 현재 실제 width에 맞춰서 동적으로 화면을 전환할 수(화면회전간에 변경되는) 있습니다. fragments가 그럼 화면 구성을 구현하는데 상당한 도움이 될껍니다.


이제 화면 density 에 대해 알아볼까요. 전 tvdpi 에 대해 많은 개발자들이 "이건 머지?!?"란 반응에 놀랐어요. 이 density는 이미 TV 화면 지원을 위해 작년에 소개되었어요. http://developer.android.com/reference/android/util/DisplayMetrics.html#DENSITY_TV

TV에서 xhdpi 는 1080p 출력을 위해 사용됩니다.(이것은 사용자가 TV에서 어느정도 떨어져있다는것을 가정에서 UI를 설계하게 합니다.) 그리고 tvdpi는 720p 화면에서 같은 UI크기를 표현하기 위해 추가되었습니다. 이미 알려진대로 이 density는 800x1280 7"화면과 같습니다. : 600x1024에 mdpi(160dp)이면 160*(800/600) = 약 213dpi 이죠.

앱개발자 들의 다음 리엑션은 아마도 "머? 또 다른 density를 지원해야한다고??" 일겁니다. 다행이도 그럴 필요는 없습니다. 우리는 tvdpi를 보조 density로 생각합니다. -- 호환 디바이스를 위해 중요하지만 개발자들이 이를 위한 리소르를 따로 만드는것을 장려하지 않습니다.이미 Android의 density scaling이 이러한 임이의 density를 지원하도록 설계되었기 때문에 모든 UI 설계에 density의 개념을 포함시키고 UI구성요소의 pixel-accurate 배치를 layout manager를  통하도록  함으로써 별도의 작업없이 이 해상도에 대한 지원이 가능합니다. 

물론 모든 가능한 density에 대해 bitmap을 각각 제공할 필요도 없습니다. Android는 bitmap을 현재의 density 에 맞도록 적절히 scaling합니다(보통 읽혀지는 시점에). 모든 layout의 단위 또한 scale 될수 있도록 dp단위로 제공되고 이를 화면상의 배치를 위해 layout manager가 pixel 단위를 사용합니다.(density에 따라 scaled된 이후에) 폰트크기 또한 간단히 scale되고 해상도에 맞춰 그려집니다. 레이아웃이 pixel로 처리된 후 문자의 크기는 hinting으로 인한 에러를 줄이기 위해 최종 pixel크기 기준으로 계산됩니다.


만약 bitmap이 의도하지 않았던 density로 scaled될지라도 테두리가 부드럽게 처리된 결과물을 얻을 수 있습니다. 안드로이드에서 이런 이슈를 완화시키는 몇가지 방법이 있습니다.


  • Nexus 7같은 화면의 기기는 상당히 높은 density 이기 때문에 scaling이 잘 눈에 띄지 않습니다.
  • 안드로이드는 Scale을 시킬 bitmap을 고를때 일반적으로 더 높은 density의 bitmap을 선택합니다. tvdpi 화면의 경우 보통 hdpi의 폰들을 지원하기 위해 대부분의 앱들이 포함하고 있는 hdpi 의 리소스들을 scale down시키게 됩니다.
  • 안드로이드 타블랫 UI에서는 일반 앱 아이콘보다 큰 사이즈의 아이콘을 사용합니다. 이를 위해 더 높은 density 의 아이콘을 사용하는 방식을 이용합니다. http://developer.android.com/reference/android/app/ActivityManager.html#getLauncherLargeIconDensity() 는 사용할 density를 리턴합니다. 앱의 아이콘은 산뜻한 화면의 핵심적인 요소이기고 디자인된 아이콘이 scaling없이 사용될수 있도록 density는 한단계 높은 density가 선택됩니다. (mdpi->hdpi, hdpi->xhdpi 등) 런처에서나 앱의 아이콘이 사용되는 곳에서 tvdpi 화면은 hdpi density로 지정되어 디자인된 크기가 사용됩니다.

Nexus 7 는 안드로이드 density scaling 이 얼마나 잘 동작하는지에 대한 큰 테스트였고 저는 이 결과에 매우 만족합니다. 사실 젤리빈 오픈소스 플래폼내에서 tvdpi 리소스가 사용되는 곳은 notification tray의 배경 이미지가 유일합니다. 또 그 리소스는 다른 화면 크기마다 각각의 버전이 있습니다. 이는 앱이 사용할만한 일반적인 접근법이 아닙니다. 화면에서 볼 수 있는 거의 모든것이 tvdpi 리소스 지정없이 scaling이나 기존의 hdpi 리소스를 그냥 사용하는 방식으로 충분히 처리가 가능합니다.