[android/안드로이드] Supporting Multiple Screens ( 여러 스크린 지원 )

출처 : http://developer.android.com/guide/practices/screens_support.html

- 안드로이드는 다양한 스크린 사이즈와 density 를 가진 여러 종류의 단말들이 있고, API 들이 이를 지원해준다.

- 시스템이 적절한 로직으로 스케일링과 리사이징을 하긴 하지만, UI 최적화를 위한 노력이 필요하며,대부분의 단말환경에서 직접 테스트해봐야 한다.

Overview of Screens Support

Terms and concepts

- screen size 는 대각선 물리적 사이즈로, small, normal, large, extra large 4가지로 구분된다. 
 

- screen density는 dpi (dots per inch) 를 말하며 특정 area 에 얼마나 많은 pixel 이 들어가는지를 말한다. low, medium, high, extra high 4가지로 구분된다.
 

- Orientation는 portrait 혹은 landscape
 

- Resolution 은 screen에 있는 total 물리적 pixel 수이다. 
 

- Density-independent pixel (dp) 는 UI layout 시 사용되는 가상의 pixel unit이다. 이는 density 에 독립적으로 사용되는 unit이다.( 다시 말해 density 에 영향받지 않고(독립적으로) 똑같은 view 를 display 하는 단위라고 보면 된다. ) 1dp 는 160 dpi screen(기본값인 medium density) 에서의 1 pixel 값과 같다. runtime에 이 dp 값을 해당 device의 density 에 맞도록 보이지 않게 scaling 하는 작업이 수행된다. px = dp * ( dpi / 160 ). 다른 density 의 screen 에서도 같은 view 를 보여주고 싶다면 dp 값을 사용해야 한다.
 

dp = px * 160 / dpi

Range of screens supported

Density independence

- 안드로이드 시스템은 dp값을 현재 screen density 에 맞게 scale 하는 작업과, drawable을 scale 하는 작업을 해 주어 density independent 한 환경을 구성한다.
 

- 대부분의 경우 모든 layout 을 dp unit 으로 구성하거나 wrap_content 로 구현함으로서 density-independent 한 UI 를 구성할 수 있다.

How to Support Multiple Screens

- manifest 에 스크린 사이즈를 정의하여, google play 에서 해당 스크린만 앱을 사용할 수 있도록도 할 수 있다.

Using configuration qualifiers

- resource best match 전략을 적용할 때, best match 될 target 이 없는 경우 lower quality 쪽으로 접근을 한다. lower quality 쪽에 resource 가 없다면 crash 가 발생한다. 

좀 이해가 안 되는 부분이다.. scale down 을 하면 될 것 같은데 왜 crash 를 낼까..?

- 만약 scale 되지 않고 사용되어야 할 이미지가 있다면 drawable-nodpi 에 resource 를 넣어주어야 한다. 이 안에 있는 resource 가 사용될 때에는 이미지를 scaling 하지 않는다.

 

Designing alternative layouts and drawables

Alternative Layouts

- 어플은 small screen에도 맞아야 하고, bigger screen 에서는 그것을 위해 디자인 된 것처럼 보여야 하며, landscape 와 portrait 둘 다 지원가능해야 한다.

Alternative Drawables

- low : medium : high : extra-high = 3 : 4 : 6 : 8

Best Practice

1. layout xml에는 wrap_content, fill_parent, dp만을 사용한다.
 

2. application code 에 hard-coded pixel 값을 사용하지 않는다.
 

3. AbsoluteLayout 을 사용하지 않는다. ( deprecated 되었다. )
 

4. 다른 screen density 에 대해 대체할 수 있는 bitmap drawable 들을 제공한다.

Additional Density Considerations

- manifest 의 android:anyDensity="false' 값을 줌으로서 pre-scaling 을 예방할 수 있다. 아니면 Bitmap 의 inScaled 속성을 "false" 로 둘 수도 있다. 대신 draw time 에 scale 할 수 있다.
 

- 이 pre-scaling 을 막아버리면, 단말은 scaling 을 하지 않으려고, 해당 density 를 기준으로 drawing 을 먼저 한다. 그 다음에 실제 drawing 타입에 스케일링을 하는 것인데, 이것은 performance 적으로 좋다.
 

- 기본적으로는 pre-scaling 을 disable 하지 않는 것이 좋다. 예상치 못한 결과를 가져오기 쉽기 때문이다.

[android/안드로이드] pre-scaling & auto-scaling & compatible mode

 

Scaling Bitmap objects created at runtime

- Runtime 에 만든 bitmap 은 기본적으로 medium-density 용이라고 가정이 되어 scaling 이 적용된다.
 

- Runtime 으로 만든 BItmap 에도 당연히 density 를 적용할 수 있다. DisplayMetrics 를 통해서 현재 Density 를 가져와 적용하던가, DisplayMetrics.DENSITY_HIGH 등의 constant 를 통해 bitmap.setDensity() 함수를 통해 Bitmap 의 density 설정이 가능하다.
 

- BitmapFactory 를 사용하는 경우에는 BitmapFactory.Options 의 inDensity field 에 density 값을 넣어줄 수 있다. ( inScaled 값에는 pre-scale 여부를 넣어줄 수 있다. )

 

Converting dp units to pixel units

- code 에서도 pixel 보다는 dp 를 적용하는 것이 좋다. getResources().getDisplayMetrics().density 를 이용하여 pixel 에 곱해주어야 한다.
 

- Threshold 관련해서 dp를 적용하는 좋은 방법은 직접 계산보다는 ViweConfiguration 을 이용하는 방법이 좋다.

 

Using pre-scaled configuration values

- ViewConfiguration.getScaledXXX() 함수들을 이용하면 distance, speed, time 관련된 device specific 한 값들을 얻기 좋다.

How to Test Your Application on Multiple Screens

- 안드로이드의 에뮬레이터를 이용하는 것이 좋은 UI 를 위한 테스트로 좋은 방법이다.

 - built-in emulator 에서 제공하지 않는 option 의 device 환경을 구성하고 싶다면, 다음의 command line 명령어를 사용한다.
 

> emulator -avd <avd_name> - scale <#>dpi

도움이 되셨다면 손가락 꾸욱~ ( 로그인 필요 x )