Developer Ahn

출처: http://leipiel.tistory.com/8

저번 포스팅에서 디자이너가 제작 전에 이해하거나 알아둬야 할 기본적인 안드로이드 UI 정보에 대해 정리해 보았다. 앞선 내용 전부 디자인 제작 시 반영이 잘 되었다면 개발파트에서 적용하는데 큰 문제는 없을 것이다.

이번에는 실제로 개발자와 협업할 때 필요한 UI 가이드 문서 제작 방법을 정리하려고 한다. 전에도 언급했다시피 UI는 결국 개발 파트를 거쳐 완성되므로 개발 파트와 디자인 파트 간의 밀도 있는 소통이 이루어져야 하며 그 중심에는 UI 가이드 문서가 있다. 정리하고자 하는 가이드 방식은 개인 경험을 통해 축적된 것이기 때문에 내 방식을 주장하거나 강요하는 것은 절대로 아니다. '그냥 이런 방식도 있구나.' 정도로 읽으시면 되겠다. (제 방식에 오류나 더 나은 방법은 알려주세요.)

1. Layout

레이아웃은 UI 구조 및 구성 의도를 잘 전달하기 위해 표시한다.
가상의 프레임들을 시각적으로 제공해 줌으로써 개발자는 버튼의 위치 및 정렬, 각 view의 부모, 형제, 자식 관계를 쉽게 이해할 수 있다. 나의 경우는 이 프레임들을 투명도가 있는 컬러 박스로 구분하되, 필요에 따라 선으로 구분하여 표시한다. 이 표시는 각 구성요소의 위치나 관계성을 이해하기 쉽게 하는 용도다. 개발 관점의 view 구성 가이드가 아니므로 개발자가 더 효율적인 방법으로 구성하면 된다.

2. Images

이미지는 기본적으로 사이즈가 고려된 분할 이미지 파일 형태로 제공되기 때문에 사이즈를 기재해줄 필요는 없다. 40dp x 40dp로 제작된 이미지는 40dp x 40dp로 표출되는 것은 너무 당연한 것이기 때문. (코드 상에서도 이미지 사이즈를 입력하지 않아도 리소스 사이즈 그대로 표시된다.)

이미지는 파일명 정보가 가장 중요하다.
물론 이미지 파일들을 보면 어디에 쓰인 것인지 알 수는 있겠지만 리소스가 많고 투명 값이 많은 이미지들의 경우 탐색기의 썸네일로만 구분하기 어렵기 때문에 가이드에 이미지 파일명이 기재되는 것이 바람직하다. 또 버튼과 같이 이벤트에 따라 여러 개의 이미지 리소스를 사용하는 경우는 미리 약속한 규칙으로 표현해주면 된다. 우리의 경우 파일명 접미사 규칙을 이용하여 구분하고 있다.

_n은 normal, _p는 press를 의미함

3. Weight

전 포스팅에서 전체 디스플레이의 가변성을 고려하여 디자인해야 한다고 언급한 적이 있다. 전체 영역 중 어떤 view가 가변성을 가질 것인지 표시해 주는 것이다. 나는 개발자가 사용하는 명칭 그대로 weight라고 약속하여 가이드에 표시하고 있다. 이런 명칭을 규정하기 나름이므로 각자 환경에 맞게 규정하여 표시하면 된다. 또 연속성을 갖는 여러 개의 가변 영역일 경우 해당 비율을 기재해주면 된다.

4. Spacing

모든 레이아웃 구성요소들의 간격은 기본 dp단위로 기재한다.
굳이 margin, padding 구분하여 세세히 기재해줄 필요는 없다. 부모 객체에 padding 값을 적용하는 것과 자식에 margin 값을 적용하는 것은 특별한 경우를 제외하고는 차이가 없다. 그러므로 간격 값만 표시하고 그것을 어느 객체에 margin / padding으로 처리할 것인지는 개발자의 몫으로 남기자.

Header에 left-padding:8 을 할지, btn_prev에 left-margin:8 을 할지는 개발자의 선택!

5. Align

안드로이드에서 구성요소의 위치를 좌표로 지정하여 사용하는 경우는 매우 드물다. 그렇기 때문에 정렬(Align)과 간격(Spacing)을 이용하여 위치 값을 가이드 해야 한다. 정렬 값은 가로 기준, 세로 기준 두 개의 값을 표시하며 이 또한 개발자와 사전에 약속한 규칙으로 기재하면 된다.
나의 경우, 안드로이드에서 사용하는 명칭은 익숙하지 않아 웹상의 용어로 규정하여 사용했었다. (align, v-align) 요즘은 가이드 내에서 최대한 텍스트를 줄이기 위해 선으로 표시하는 방법을 사용한다.

Prev 버튼이 Header 기준으로 align=left, v-align=center에 위치함을 점선으로 표시

6. Text

기본 서체 단위는 SP를 사용하며 이의 환산 방식은 DP와 동일하다. 다만 SP를 사용하는 이유는 OS나 어플리케이션 상에서 서체 크기를 변경하여 사용할 때 적용되는 단위가 SP라고 한다. 그러므로 서체는 SP 단위로 기재한다.(편의에 따라 단위는 생략하자.) 색상은 일반적으로 Hex 값으로 입력하니 hex 값을 기재해주면 된다.
행간은 조절 가능하나 자간은 불가능한 것으로 알고 있다.(문자의 가로 비율을 조절할 수 있으나 자간이나 커닝은 조절할 수 없는 것으로 알고 있음) 이런 부분은 OS의 버전업에 따라 변동이 있으므로 체크하여 표현성에 자유로움을 더하자.

굵기, 크기, 색상으로 표기되어 있다.
때에 따라 TextView가 고정 크기일 수도, 문자길이에 따른 가변너비일 수도 있다.

디자이너 관점에서 안드로이드 개발자와 협업하기 위한 GUI 개발 가이드를 작성하는 규칙(?)을 끄적여봤다.
사실 위에 쓰여진대로 app GUI 가이드 문서를 만든다는 것은 여간 번거로운 작업이 아닐 수 없다. 그래픽툴로 디자인하는 시간만큼 GUI 개발 가이드를 작성하는 시간이 소요되는 것이 나의 경험이다. 물론 시간을 줄일 수 있는 방법이 있고, 그런 방법을 계속 고민하고 테스트해 보지만 그럼에도 불구하고 GUI개발 가이드 작업은 참 재미없고 지루한 작업이다.
여기서 간과하지 말아야 할 것은 GUI 개발 가이드는 디자이너-개발자의 소통을 돕기 위한 미리 합의한 규칙 정도 되는 것이다. 소통을 위한 도구일 뿐이지 목적은 아니다. 그러므로 처한 상황과 여건에 맞게 최소한의 기재만 해도 GUI 개발하는데 무리가 없게 개발자와 많은 대화와 고민을 하는 것이 가장 중요하다.

출처: http://leipiel.tistory.com/7

디자인의 특성상 디자이너의 작업물이 독립적인 결과물로 산출되는 경우는 거의 없다.
편집, 인쇄 디자이너는 자신의 작업물이 온전하게 결과물로 나오기 위해 인쇄 과정을 이해하는 노력이 필요하다. 직접 인쇄소를 들락날락하며 필름교정과 인쇄교정을 직접하는 것은 인쇄과정이 자신의 결과물에 미치는 영향을 잘 알기 때문이다.

UI 디자인은 어떨까? 모바일은 각 플랫폼 클라이언트 개발자를 통해 구현되고 웹은 퍼블리셔나 웹개발자를 통해 구현된다. (영세한 회사는 웹퍼블리셔가 없는 경우도 많다.) 내가 아무리 포토샵으로 미려하게 디자인을 한다 하더라도 개발에 적용될 수 없는 화면 구성이거나 개발자가 전혀 이해할 수 없는 방식으로 전달하게 된다면 결과물은 형편 없을 것이 뻔하다. 결국 UI 디자인의 최종 결과물은 실제 구동되는 프로그램으로 구현되는 것이기 때문에 개발에 대한 이해도가 꼭 필요하다고 생각한다. (물론 개발을 배우자라는 말은 아니다.)

이미 iOS도 아이폰6와 6+ 덕분에 플렉서블한 디자인 설계를 해야되지만 안드로이드는 이미 태생부터 멀티 디스플레이를 고려하는 디자인을 해야만 한다. 어떻게하면 다양한 End-User의 모바일 디바이스에 디자인 의도를 동일하게 전달할 수 있을까? 라는 질문에서 시작했고 결국 회사의 안드로이드 개발팀을 끈질기게 괴롭히고 닥달한 끝에 회사 내부에서 [디자인/개발 협업을 위한 가이드 규칙]을 정의할 수 있었다. 2013년, 시간을 들여 정의한 덕분에 지금까지 개발간 특별한 불통없이 UI협업이 적절하게 이루어졌다고 생각한다. 그 가이드 규칙과 내가 경험한 노하우를 끄적여 보고자 한다. 물론 이것이 틀린 부분도 있을 것이고(나나 우리 개발동료들이나 우리 수준에 맞는 정리일 뿐 모든 기술적 오류나 정보를 알고 한 것이 아니기 때문) 정답도 아니다. 우연히 들리신 분들은 그냥 참고용으로 보시면 되겠다. 오류 사항은 '이 녀석들, 이런 상식도 몰라'하고 웃어주시면 된다. (욕..욕만은 반사!)

1. 크기의 단위 (Dimension)

DIP (Device Independent Pixels) or DP

안드로이드에서 사용하는 독립적 단위 수치. 이론 상 어떠한 해상도에서도 같은 크기를 보여주는 것이 핵심이라고 한다. (같은 크기를 보여주는 것은 구글의 가이드라인을 잘 지키지 않으므로 큰 의미가 없어져 버렸다.)
안드로이드 초기에는 디자이너들이 dp라는 개념을 전혀 몰랐고 개발 또한 px수치로 개발하는 개발자도 더러 보았다. 하지만 요즘은 왠만한 UI 디자이너들은 한번씩은 들어봤고 물어봤을만한 수치가 아닐까? 개발자에게 전달되는 GUI 개발 가이드 문서에 dp로 기재되었느냐 아니냐에 따라 단편적으로 디자이너의 이해수준을 가늠하는 척도가 되기도 하는 그 dp, 이제는 다 아는 것이지만 안드로이드 UI 디자인을 정리할 때 빠질 수 없는 부분이기에 간단히 정리하고 넘어가자.

변환식 : px = dp x (dpi/160)

1dp 값

※ MDPI는 1dp=1px이 되는 기준 dpi

변환식이 있지만 이것은 px 에서 dp 치환을 이해하는 것으로 족하다. 그냥 외우자. 주입식 교육에 찌들어버린 머리로는 외우는 것 이상의 좋은 방법이 떠오르지 않는다.

SP(Scale Independent Pixels)

스케일에 따른 독립 픽셀 단위. 기본적으로 치환 방식은 dp와 동일한 값이다. 다만 sp수치는 OS설정이나 app 설정에서 단계별로 설정한 값으로 변경하면 함께 변하는 유동적인 값이다. 그렇기 때문에 sp는 글꼴 크기를 지정할 때 사용을 권장한다. (특별한 경우 다르게 쓰일 수 있다. 하지만 거의 드물고 적합한 구성은 아니라고 생각한다. 그냥 서체 크기는 sp라고 알고 있으면 된다.)

디자인 제작 시 DP, SP 적용

dp의 개념을 어렴풋이 알지만 실제 포토샵에서 디자인 작업을 할 때 이것을 어떻게 적용해야 하는지 헷갈릴 수 있다. 어찌보면 간단하다. 1dp, 정수 단위로 작업하면 된다. 즉, 1080 x 1920(xxhdpi)의 픽셀 해상도를 기준으로 작업하게 된다면 모든 GUI 구성요소(가이드 시 수치로 전달되거나 조각낸 이미지 리소스 사이즈 모두 다)들이 3px의 배수로 제작하면 된다.

하지만 난 여기서 더 나아가 2dp(xxhdpi 기준, 6px) 단위로 작업하라고 말하고 싶다. 이유는 간단하다. 1dp 단위로 작업할 경우 홀수는 hdpi일 때 픽셀 환산 소수점이 나타나게 된다. 예를 들면 3dp가 xxhdpi에서 픽셀 환산 시 9px이지만 hdpi에서는 4.5px이다. 하지만 물리적 픽셀은 소수점이 존재하지 않는다. 구성요소 픽셀과 디스플레이의 픽셀이 1:1매칭해야 가장 깔끔하고 뚜렷하게 보이게 되는데 그런 점에서 볼 때 디자인 제작 시 2dp의 배수로 제작을 염두하고 만드는 것이 결과적으로 좋다. (hdpi를 사용하는 단말이 거의 존재하지 않을 때는 고려하지 않아도 좋다. 슬슬 고려하지 않아도 되는 추세일지도 모르겠다.)

2. Density & Screen Size

구글은 해상도 및 화면크기가 다른 디바이스들을 범용으로 지원하기 위해 밀도(Density)와 화면크기(Screen size)로 분류하여 기준을 제시하고 있다.

스크린 사이즈 분류

• small (least 426dp x 320dp)
• normal (least 470dp x 320dp)
• large (least 640dp x 480dp)
• xlarge (least 960dp x 720dp)

• ldpi (120dpi)
• mdpi (160dpi)
• hdpi (240dpi)
• xhdpi (320dpi)
• xxdpi (480dpi)
• xxxhdpi (640dpi)

복잡한 것 같지만 간단하다. 현재 출시된 폰으로 비교해 보자.

노란색으로 강조한 것을 비교해 보면, 두 단말의 픽셀 해상도는 동일하지만 dp 해상도는 달라지게 된다. 이것은 같은 픽셀 해상도지만 스크린의 차이 때문에 밀도 분류가 다르게 적용되면서 1dp가 갖는 픽셀 수가 달라지기 때문이다.
포토샵으로 동일한 px 도큐멘트에서 디자인 작업을 했다 하더라도 스크린/밀도에 따라 가이드에 적히는 dp는 변할 수 있다는 점 기억하자. 또 스크린 사이즈 몇 부터 몇은 normal, 디스플레이 ppi 몇 부터 몇은 xhdpi와 같이 구글에서 기준을 제시하고 있으나 이것을 지킬 제조사들이 아니다. 특이한 단말은 확보하여 개발의 도움으로 확인하는 절차를 거쳐야 한다.

국내 주요 Display dp 해상도 비교 (phone)

현재 출시된 1440 x 2560px의 QHD 폰들은 정리가 되진 않았지만 dp환산으로는 360 x 640dp이기 때문에 고려하고 보면 될 것이다. 물론 이 중 현재는 거의 사용하지 않는 크기의 디스플레이도 있겠지만 전체적인 이해를 위한 것이니 이 점은 염두하자. 실제 적용할 때는 app의 적용 대상 단말이라든가, 디바이스별 점유율 등을 고려해야 하겠다. (현재는 320 x 480px를 가진 단말을 지원하는 것이 절대적인 비효율일 것이다.)

디자인 제작 시 영역의 가변성 고려

위의 비교표처럼 각기 다른 크기의 디스플레이를 다 만족시킬 수 있는 UI가 되려면 디자이너가 그래픽 작업을 시작하기 전에 가변성을 고려한 유연한 화면 설계를 미리하고 진행해야 한다.
위의 모든 디스플레이를 고려한다는 전제로,
width : 최소 320dp ~ 최대 400dp (차이 값 80dp)
height : 최소 480dp ~ 최대 640dp (차이 값 160dp)

가변적 화면구성 예시. 각 화면의 주요 구성요소들이 전체 view의 변화에도 잘 대응한다.

높이만 예시로 보자. 전체 view 에 있는 모든 구성요소가 최대 높이 640dp, 최소 높이 480dp에도 모두 담길 수 있게 디자인해야 한다. 만약 구성요소들의 높이가 480dp를 넘었다면 640dp에서는 정상적으로 나오나 480dp에서는 찌그러져 나올 것이다. 또한 전체 view 크기의 변화에도 구성요소들이 자연스러운 위치로 변화하는 것도 고려해야 한다. 위의 예시를 보면 140dp 높이를 가진 view는 헤더 바로 밑에 고정 간격 값, 하단 인증 버튼은 bottom에 간격 값으로 위치한다. 가운데 텍스트 view 영역 중앙에 위치하면서 가변영역을 구성한다. (이에 대한 자세한 설명은 다음 포스팅에 상세 설명할 예정이다.)
이런 가변성을 미리 고려하고 디자인 작업을 진행을 하게되면 개발파트로 넘어가 app에 적용된 후 멀티 디바이스의 문제로 다시 재작업하는 일은 없어질 것이다.

3. 리소스 폴더 구조

화면들을 포토샵으로 제작하는 작업이 완료되면 각각의 구성요소 리소스를 분할하고 가이드를 제작하는 과정을 거친다. 최종적으로 이렇게 잘라낸 이미지 리소스로 내가 공들여 만든 GUI를 표현해 주고 있다. 그럼 과연 그 리소스들이 어떤 구조로 쓰이는지 이해하고 제작하고 있는 것일까?
디자이너가 완벽하게 이해할 이유는 없겠지만 drawable 폴더의 구조와 관계성을 어느정도 이해하는 것은 필요하고 생각한다.

밀도 분류

• drawable-nodpi
• drawable-ldpi
• drawable-mdpi
• drawable-xhdpi
• drawable-xxhdpi

(tvdpi나 xxxhdpi가 있지만 우선 제외하자.) 폴더명에서 잘 드러난다. 각 dpi별로 이미지 리소스를 구분하여 넣는다. 해당 dpi에 알맞는 이미지 리소스를 넣게 되면 단말별로 자신에게 맞는 리소스만을 불러 사용하기 때문에 이미지 최적화나 메모리 관리 등 여러 장점들이 존재한다. 다만 모든 리소스들 갖게 되면 app 용량이 늘어날 수 있으니 app의 목적이나 여러 환경을 고려하여 판단해야 하겠다. 

아마 대부분 가장 큰 사이즈만 작업을 한다. 어차피 단말에서 알아서 리사이징을 하기 때문이다. 이미지 리소스가 xxhdpi 폴더에만 있는 app을 xhdpi 단말에서 구동하게 되면 자체적으로 xxhdpi에 있는 리소스를 66.6% 다운 스케일링하여 표출한다. 그렇기 때문에 큰 사이즈 리소스만 갖고 있어도 표현의 문제는 없다고 보여진다. 다만 불필요하게 큰 이미지를 축소해 보여지므로 메모리 관리는 허술할 여지가 있다. (요즘 폰들은 메모리 걱정할 이유가 없나?)

또 하나 기억할 것은 drawable 폴더를 읽는 순서가 있다. 보통 자신에게 맞는 dpi 폴더를 먼저 읽고 해당 리소스가 없으면 가장 큰 dpi폴더에서부터 작은 폴더 순으로, 가장 마지막에 nodpi로 읽는다. 단말별로 조금씩 다르다는 어느 개발자 분의 블로그에서 읽은 적이 있었는데 거의 대부분은 언급한 순서로 결과가 나왔다.
이런 성질을 이용한 유용한 Tip이 있다. 경험 상 큰 리소스를 낮은 dpi 단말에서 표현해 줄 때 큰 문제는 없으나 작은 이미지, 얇은 표현의 이미지(블릿 아이콘이나 light 서체로 만든 BI) 등 미세한 다운스케일링이 필요한 이미지들은 깨짐 현상이 발생한다. 이 현상은 iOS에서도 마찬가지로 나타나는데, 내 판단에는 실시간으로 소프트웨어로 이미지 스케일링 프로세스의 한계라고 보여진다. 이런 것은 각 사이즈별로 작업하여 갖고 있는 것이 좋다. 따라서 낮은 dpi 단말에서 깨짐이 우려되는 리소스들만 작업하여 각 dpi 폴더에 넣어준다. 그러면 우선순위로 그 리소스들은 dpi에 맞게 표현이 되고 나머지 리소스는 가장 큰 리소스를 사용하게 된다.

nodpi 폴더에 있는 리소스는 dpi에 상관없이 100% 사이즈로 표현한다. 즉 dpi와 관계없이 이미지 픽셀을 1:1매칭해서 표현한다. 활용방법은 드물지만 필요에 따라 유용하게 사용할 수 있으니 기억할 수 있도록 하자.

• drawable-normal-xhdpi
• drawable-large-xhdpi
• drawable-normal-land-xxhdpi

1.안드로이드의 주요 단위

디바이스별 테스트

Keypoint

- 안드로이드의 기준 DPI는 중간 수준인 160 DPI이다.

- 160 DPI를 기준으로 DPI가 크면 밀도가 높아지고, DPI가 작으면 밀도가 낮아진다.

- 또한, 160 DPI인 경우 밀도독립 단위인 DP(DIP)와 픽셀이 같은 크기를 갖는다.

- 즉, 160 DPI에서 1 DP는 1 PX이 된다.

2.DIP (Density Independent Pixels) 또는 DP

* dp 와 dip (Density Independent Pixel)

말 그대로 실제 픽셀에 독립적인 단위로 안드로이드 폰의 다양한 해상도를 지원하기 위해 만든 단위이다. 큰 화면이든 작은 화면이든 같은 크기로 나타나게 되어있다. (그러나 적용해보면 미세하게 다르다..) 즉, 화면이 작은 폰에서 10원짜리 만하게 나타난다면 화면이 큰 폰에서도 10원짜리 만하게 나타나도록 되어있다. dp(dip)와 px간의 변환을 하는 방법은 아래와 같다.

※ java코드에서 dp를 px로 바꾸는 방법

java코드에서 density또는 dpi를 이용해서 dp를 px로 변환할 수도 있지만 TypedValue를 이용해서 다음과 같이 구할 수 있다.