px 픽셀 단위를 쓰지 않는 이유모바일 기본 단위virtual pixels, logical pixelsPT (ios)ios 픽셀 밀도 정리DP (android)모든 기기, 픽셀 밀도에 대한 테스트SP디자인 이슈통계 자료모바일 기기 점유율 (2022)해상도 점유율해상도 기준 설정여러 해상도에 대응하는 방법디자인 이슈대응 방안1) 퍼센트, 스케일을 통해 완전히 똑같이 보이도록 작업한다2) 디자인 배치를 신경쓴다.개발(Development)Dimensions예시 - Galaxy Note 10스케일로 대응스케일 함수 구현문제점해결방안PixelRatio
- 참고자료 : https://vimeo.com/169809377 (px, pt, dp에 대한 비교 영상)
px 픽셀 단위를 쓰지 않는 이유
픽셀의 밀도가 점점 더 좋아지기 떄문이다.
스마트폰의 가로세로의 물리적인 크기가 동일하더라도, 디스플레이 내 픽셀의 밀도가 다르기 떄문에 다른 결과물을 보게 된다.
ppi : pixels per inch (디스플레이상에서의 해상도를 표현할 때 사용)
dpi : dots per inch (인쇄물, 출력물에서의 해상도를 표현할 때 사용)
둘이 혼용되어 자주 쓰이는 거 같은데, 같은 개념이라고 이해해도 될 거 같다.
* 참고 : https://blank2.tistory.com/3
* PPI 계산 공식 : https://www.calculatorsoup.com/calculators/technology/ppi-calculator.php
모바일 기본 단위
RN에서도 별도의 단위를 명시하지 않고 모바일의 기본 단위가 적용된다.
iOS의 기본단위 :pt(point)
android의 기본단위 :dp(density independent pixels)
pt와 dp는 논리적 픽셀 단위로, 실제 휴대폰에 표기 시 적절한 픽셀 개수로 변환되어 보여준다.따라서 해상도가 다르더라도 비슷한 UI를 볼 수 있게 되는 것이다.
위 그림은 공식문서
dp에 나오는 예시인데, 논리적 단위인 dp 단위를 적용하였기에 물리적으로 동일한 크기의 기기에서 봤을 때 유사한 UI가 나오고 있다. 이를 px 단위로 적용했다면 첫번째 휴대폰에선 엄청 크게 나왔을 거고, 이는 사용성을 해치게 된다.
virtual pixels, logical pixels
PT (ios)
- pt와 글자크기 ( 글자크기로 pt를 쓰는 것은 옳지 않다 ) : https://blog.gimm.io/difference-between-pixel-px-and-point-pt-font-sizes-in-email-signatures/
레티나 디스플레이가 나오기 전(아이폰4 이전 기기들)에는 가로세로 1인치 정사각형 안에 총 163개의 픽셀이 있었다. 이는 오늘날에도 기준값으로 쓰인다.레티나 디스플레이가 나오기 이전에는
px 단위로 작업해도 됐었다. 왜냐하면 모든 디스플레이가 인치당 163개의 픽셀로 고정이었기 떄문이다.레티나 디스플레이가 나오면서 같은 공간에 총 326개의 픽셀이 놓이게 되면서, 기존까지 픽셀 단위로 작업하던 디자인에 문제가 발생하게 된다.
픽셀의 밀도가 달라지면서 픽셀 단위로 디자인을 작업하면 실제 사용자가 보게되는 크기는 레티나 디스플레이냐 아니냐에 따라 실제 사용자가 보게되는 크기가 엄청 달라진다.
이를 해결하기 위해 애플에서 내놓은 단위가 바로
Point(pt) 단위다.1pt = (디바이스의 ppi / 163)px
- 레티나 이전의 디스플레이 :
1pt= (163/163)px =1px
- 레티나 디스플레이 :
1pt= (326/163)px =2px
이로써 이제는 px가 아닌
pt를 기준으로 디자인을 하면 디바이스의 픽셀 밀도에 따라 적절한 픽셀 개수로 변환되면서 픽셀 밀도가 서로 다른 디바이스 간에도 유사한 UI를 그릴 수 있게 되었다.ios 픽셀 밀도 정리
레티나 이전 | 1pt | 1px (@1x) | 아이폰4 이전 디바이스들 |
레티나 | 1pt | 2px (@2x) | 아이폰4~5세대 |
레티나 HD | 1pt | 3px (@3x) | 아이폰6세대~ |
DP (android)
- 안드로이드 공식문서 -
dp: https://developer.android.com/training/multiscreen/screendensities
안드로이드에서도 ios의 pt 단위와 유사한 논리적인 픽셀 단위로
DP(density-independent pixels) 단위를 내놓았다.pt와의 유일한 차이점은 기준값을 ios에서는 163으로 둔 것에 비해, 안드로이드는 기준값을 160으로 둔다는 것만 다르다.1dp = (디바이스의 ppi / 160)px
모든 기기, 픽셀 밀도에 대한 테스트
실제 기기에서 테스트하고 싶지만 기기를 구매하지 않으려면 Firebase Test Lab을 사용하여 Google 데이터 센터의 기기에 액세스하면 된다.
SP
안드로이드에서 폰트 크기를 설정하는 것.
스케일에 따라 언제나 동일한 비율의 글자 크기로 보여지고 싶다면, sp가 아닌 dp 값으로 TextView에 수치를 전달하는 것이 더 나을 수도 있다. 판단하게 적절한 수치를 할용하도록 하자.
디자인 이슈
- 해상도의 기준이 있어야 UI 디자인을 시작할 수 있다 : https://brunch.co.kr/@plusx/6
- 브라우저 트래픽 통계 자료 Starcounter : https://gs.statcounter.com/
통계 자료
모바일 기기 점유율 (2022)
전세계
- 애플&삼성 압도적 1등
아시아
- 삼성 1등
- 샤오미&애플
한국
- 삼성 압도적 1등
- 애플
해상도 점유율
모바일 (2022)
모바일 (2018)
태블릿 (2022)
해상도 기준 설정
2018년에는 해상도 기준을 세우기가 명확했다. 튀는 점유율이 명확하게 있었기 때문이다.
360 * 640: 40% 점유율 ⇒ 안드로이드 해상도 기준으로 활용
375 * 667: 9.38% 점유율 ⇒ iOS 해상도 기준으로 활용
여러 해상도에 대응하는 방법
플러스엑스 : 안드로이드를 먼저 작업한 후, 늘어난 만큼 우측과 하단의 여백을 줌으로써 iOS 디자인에 대응한다.
henry lee 브런치 글 : 더 작은 해상도를 기준으로 작업 후, 남는 여백을 작업하면 된다.
공통적인 의견은 남는 만큼 여백을 적절하게 조정함으로써 여러 해상도에 대응하고 있다.
디자인 이슈
문제는 사용자가 휴대폰 디스플레이 설정을 통해 scale vector 값을 임의로 조정할 수 있는데, 가장 크게 설정했을 때 UI가 깨지는 현상이 간간히 발생한다.
gs shop - 카테고리 글씨 잘림
리멤버 - 컨텐츠 겹침, 짤림
버거킹 - 컨텐츠 겹칩 & 짤림
네이버 - 컨텐츠 온전히 표현하지 못함네이버는 기존에 남는 여백이 워낙 많았기 때문에 늘려도 컨텐츠가 다 보이긴 하지만, 원 끝이 잘리거나 텍스트가 딱맞게 바닥에 붙는 등의 현상을 의도하진 않았을 것이므로 예시로 든다.
대응 방안
1) 퍼센트, 스케일을 통해 완전히 똑같이 보이도록 작업한다
삼성증권 앱은 디스플레이 설정을 어떻게 바꾸던 앱 내에선 모든 것이 똑같이 보인다.
넷플릭스에서는 가로 슬라이드 컨텐츠를 퍼센트로 디자인 함으로써 화면 크기 변경에도 콘텐츠 크기가 동일하게 나오는 것을 볼 수 있다. (아이콘이나 글씨 등 다른 것들은 변했는데, 퍼센트로 작업한 리스트 컨텐츠는 크기가 동일하다)
2) 디자인 배치를 신경쓴다.
- 아래로 흘러내리게 한다. ( 스케일 벡터를 임의로 올렸을 때 컨텐츠가 겹칠 수 있도록 디자인 하지 않는다. )
개발(Development)
Dimensions
React-Native에서는 Dimension를 통해 화면 크기와 스케일에 대한 정보를 얻을 수 있다.각각이 의미하는 바를 알아보자.
import { Dimensions } from 'react-native'; const { width, height, scale, fontScale } = Dimensions.get('window');
width,height는 android에서는dp, ios에서는pt값을 뜻한다.
scale은1dtor1pt당 사용하는 실제 픽셀 개수를 뜻한다.
fontScale은 android에서의sp(글자 크기를 위한 논리적인 단위) 수치를 뜻한다.
그래서
width * scale 하면 하드웨어 스펙상에 적힌 해상도 상의 width 값(실제 픽셀 개수)이 나온다.예시 - Galaxy Note 10
해상도(실제 픽셀 개수)는 가로로
2280px, 세로로 1080px을 가진다.401 ppi는 XXHDPI이므로 1dp당 3px을 쓰는 화면임을 알 수 있다.
dp 자체가 논리적인 픽셀 단위이므로, 설정을 통해서 1dp당 몇 px을 쓸 건지를 좀 더 조정할 수 있는데, 각 항목당 차례대로 dimensions를 조회한 결과는 아래와 같다.
dimensions {"fontScale": 1, "height": 786.2857142857143, "scale": 2.625, "width": 411.42857142857144} dimensions {"fontScale": 1, "height": 730.6666666666666, "scale": 2.8125, "width": 384} dimensions {"fontScale": 1, "height": 682, "scale": 3, "width": 360} // 기기의 오리지널 픽셀밀도 : XXHDPI dimensions {"fontScale": 1, "height": 639.0588235294117, "scale": 3.1875, "width": 338.8235294117647} dimensions {"fontScale": 1, "height": 600.8888888888889, "scale": 3.375, "width": 320}
설정의
중앙 값은 디스플레이의 기본값인 XXHDPI인scale이 3배가 적용되어 있고, 여기서 좀 더 작게 보고싶다, 좀 더 크게 보고싶다를 조정한다는 의미로 보면 된다.설정 값을 변경하면
scale(1dp당 몇 픽셀을 쓸 지) 값이 바뀌면서 실제 가로 세로의 dp 수치도 같이 조정되는데, 소스코드에 명시되어 있는 컨텐츠의 dp 수치는 동일하므로 더 크게, 더 작게가 되는 것이다.스케일로 대응
사용자의 디스플레이 설정 변경에 대해 열어두고 디자인 배치를 신경쓰겠다 하는 경우에는 디자인에서 뽑아주는 dp 수치와 배치를 그대로 그냥 개발하면 된다.
하지만
삼섬증권과 같이 유저의 디스플레이 설정에 상관없이 항상 같은 뷰를 봤으면 하는 경우에는 개발 단에서 스케일 이라는 함수를 만들어서 변화하는 dp에 맞춰서 컨텐츠의 dp값도 적절하게 같이 변하도록 만들어 줘야 한다.스케일 함수 구현
TBD
문제점
TBD
- scale의 문제점
- width를 기준으로 했을 때, 폴드 같은 경우는 height도 같이 커지면서 공간을 잘 활용하지 못하는 문제
- 그렇다고 verticalScale을 먹이면, 세로로 긴 폰에서는 height가 커지면서 공간을 잘 활용하지 못하는 문제
해결방안
TBD