소반 (크기 적응)
지금까지, 나는 몇 가지 모바일 단말기 크기 적응 방안을 시도했다. 초기 백분율 단위에서 rem, VH, VW, flex 레이아웃과 결합 된 이러한 적응 단위에 이르기까지, 나는 여전히 새로운 시나리오를 최적화하고 시도하고 있으며, 이 몇 가지 시나리오를 결합하여 사용하려고합니다. 생산 환경에 적용한 후, 약간의 작은 성적을 거두었고, 약간의 작은 단점도 발견되었다. 다음은 이러한 시나리오에 대한 간단한 논의와 저자가 사용할 때 발생하는 몇 가지 문제와 사용 시나리오를 공유하는 것입니다.
백분율 단위는 프런트엔드를 배울 때 접하는 가장 빠른 크기 단위이며,% 는 상위 요소의 크기에 따라 분배됩니다. 상위 요소가 200px * 400px 상자이고 하위 요소가 폭: 80% 로 설정된 경우 폭은 160px 로 설정됩니다. 마찬가지로 백분율은 상위 요소의 크기를 기준으로 계산됩니다. 백분율은 상위 요소의 크기가 고정된 경우에 유용합니다. 그렇다면 상위 요소가 고정된 크기가 없다면 하위 요소의 크기에 따라 확장한다면 어떨까요? 그런 다음 실제 표시 높이는 0 이지만 너비는 0 이 아니라는 것을 알 수 있습니다. 크기가 설정되지 않은 상위 요소의 너비는 상위 요소의 너비를 상속하지만 높이는 상속하지 않습니다. 기본값은 0 입니다. 그러면 우리의 하위 요소 설정의 백분율과 폭은 정확하고 높이는 0 입니다. 백분율은 상위 요소의 크기를 기준으로 계산되므로 상위 요소의 너비가 0 이 아니면 0 이 아닌 값을 계산할 수 있으며 높이가 0 이면 0 만 계산할 수 있습니다. 따라서 상위 요소에 고정 크기가 없어 하위 요소로 확장해야 하는 경우 height 에서 사용하는 백분율은 0 이 됩니다. 따라서 높은 사용 비율을 신중하게 사용해야 합니다. 그래서, 만약 우리가 다른 크기의 휴대 전화 화면에 적응 하기 위해 백분율을 사용 하 여 UI 디자인이 모든 크기의 휴대 전화 화면에서 올바른 비율로 재현할 수 있도록, 우리는 루트 요소에 특정 크기를 설정 해야 합니다, 그래서 우리는이 크기에 따라 단계적으로 백분율을 계산할 수 있습니다.
실제로 UI 요구 사항이 무제한으로 로드할 수 있는 스크롤 목록인 경우 루트 요소에 특정 높이를 설정할 수 없으며 백분율이 높이에서 유효하지 않다는 것을 시각적으로 알 수 있습니다. 그러면 목록 항목에 대한 특정 높이만 설정할 수 있지만 크기가 다른 목록 항목의 비율이 UI 디자인과 일치한다는 보장은 없습니다. 이것은 백분율 단위 적응의 분명한 단점입니다. 그러나 UI 설계에서 개별 배율이 UI 와 일치할 필요가 없는 경우에도 백분율 단위를 계속 사용할 수 있습니다.
그런 다음, 백분율 단위가 우리의 수요를 충족시키지 못하기 때문에, 우리는 새로운 방안을 찾기 시작했다. 이때는 사람들이 계속 이야기하고 있는 rem 단위를 쉽게 찾을 수 있다. (윌리엄 셰익스피어, REM, REM, REM, REM) Rem 은 웹에서 지원하는 많은 크기 단위 중 하나입니다. Em 과 많이 닮았는데 em 과 rem 의 차이점은 무엇입니까? Em 은 상위 요소의 글꼴 크기 속성을 기반으로 하고 rem 은 루트 요소의 글꼴 크기 속성을 기반으로 합니다. 상위 요소가 font-size: 50px 로 설정된 경우 하위 요소의 1em == 50px 입니다. 또한 하위 요소에 font-size 가 설정되어 있지 않으면 기본적으로 상위 요소의 font-size 가 상속되므로 하위 요소의 하위 요소도 1em == 50px 를 충족합니다. 하위 요소가 자체 font-size 를 설정하면 위의 방정식이 더 이상 충족되지 않는다는 것을 직관적으로 이해할 수 있습니다. 따라서 부모 요소가 자신의 font-size 를 설정해야 하고 그 자식 요소가 또 em 을 만들어 할아버지 요소 (부모 요소) 를 기준으로 크기를 설정하려는 경우 어색한 상황에 처하게 됩니다.
그렇다면 빠른 안구 운동의 차이점은 무엇입니까? 앞서 언급했듯이 rem 은 루트 요소의 글꼴 크기를 기준으로 합니다. 루트 요소가 font-size: 50px 로 설정된 경우 상위 요소의 font-size 설정에 관계없이 하위 요소 또는 중첩된 다중 레벨 하위 요소에서 width: 1rem 을 사용하여 width: 50px 의 피드백을 받게 됩니다. 즉, em 단위에서 위에서 언급한 난처한 상황을 해결했다. 그러나 font-size 는 단계적으로 전달될 수 있으므로 루트 요소 아래의 첫 번째 수준 요소에서 font-size 를 기본값으로 다시 설정하는 것이 좋습니다. 이렇게 하는 이유는 한 단계 중첩된 과정에서 텍스트 노드가 나타나지만 해당 font-size 를 설정하지 않은 경우 이 텍스트 노드의 글꼴 크기가 루트 요소 설정의 font-size 가 되고 글꼴이 커지기 때문입니다. 대부분의 텍스트 노드에 동일한 글꼴 크기가 필요한 경우 각 텍스트 노드에서 글꼴 크기 값을 다시 설정하는 것은 불편합니다. 따라서 루트 요소 아래의 첫 번째 수준에 있는 하위 요소가 font-size 의 크기를 설정하면 모든 텍스트 노드가 루트 요소의 값이 아닌 font-size 의 값을 상속합니다. 따라서 각 텍스트 노드에서 글꼴 크기를 설정할 필요가 없습니다.
EM& 소개 Rem 두 단위, 우리는 EM &；; Rem 은 자체적으로 적합한 사용 시나리오를 가지고 있지만, 이에 비해 rem 은 전체 맞춤 시나리오에 더 적합할 수 있습니다. 그렇다면 1rem 의 크기를 어떻게 결정해야 할까요? 온라인 자료에는 많은 확실한 방안이 있는데, 그중에는 주로 두 가지 핵심 계산 방법이 있다.
첫 번째는 치수 범위에 따라 결정됩니다. 즉, 모바일 터미널의 다양한 크기에서 여러 범위를 나누고 각 범위에서 고정 값을 결정하는 것입니다. 구체적인 구현은 미디어 쿼리와 결합하여 화면 크기에 맞게 다양한 범위의 고정 값을 설정하는 것입니다.
다른 하나는 화면의 폭과 디자인 초안의 폭을 기준으로 숫자를 계산하는 것입니다. 이 계산은 모든 차원에서 고유한 값을 얻을 수 있습니다. 이는 js 를 통해 장치의 화면 폭을 가져온 다음 디자인 원고의 폭으로 변환하여 값을 계산한 다음 js 를 통해 루트 요소로 동적으로 설정하는 것입니다.
이 두 가지 생각은 기본적으로 위에 있지만 구체적인 변환 계산일 뿐 회사마다 생각이 다르다. 구체적인 변환은 여기를 클릭하시면 됩니다. 내 자신의 방안은 두 번째다. 화면의 폭과 디자인 원고의 폭에 따라 환산한다. 그런 다음 저자가 어떻게 변환되었는지 소개하겠습니다.
사실 필자의 변환 계산 방법은 인터넷 휴대전화와 같지만, 나는 이 변환 계산 방법을 그렇게 이해하지 못했다. 다만 이 샘플 계산은 매우 편리할 것이다. 제가 받은 디자인 원고는 750 mm 폭이고 처음에는 750px 를 75rem 으로 변환하려고 했는데, 실제 장비의 1rem 크기는 75 를 화면 너비로 나누면 1rem (실제 장비) 입니다. 하지만 나중에 1rem= 10px (디자인 초안) 의 계산이 chrome 에서 무효가 된다는 것을 알아내려고 했습니다. Chrome 은 최소 12px 까지만 도달할 수 있지만 실제로 계산된 1rem 은 12px 보다 훨씬 작습니다. 왜냐하면 휴대폰의 폭은 대부분 360-480 사이이기 때문입니다. 나중에 1rem= 100px (디자인 초안) 로 바뀌었습니다. 750px=7.5rem. 모두1rem =/kr 이 됩니다 디자인에 130px * 80px 의 요소가 있다면 1.3REM 만 있으면 됩니다. 계산은 100 으로 나누면 됩니다. 그래프를 자를 때 직접 계산하면 됩니다. 계산기로 하나씩 계산할 필요가 없습니다. 나중에이 프로그램은 오랜 시간이 걸렸습니다. 위에서 연결된 블로그가 NetEase 휴대 전화에 도입 된 것을 보았습니다. 생각보다 훨씬 더 많이 생각했습니다. 나는 눈이 멀고 죽은 쥐를 만났습니다.
이 시나리오는 IOs 의 webview 에서 rem 을 사용하여 네트워크 이미지를 동적으로 로드하는 것을 발견할 때까지 모바일 터미널 어댑터의 주요 선택이었습니다. 조사 결과 js 인터페이스를 통해 얻은 네트워크 사진이 로드 시 제대로 표시되지 않는 것으로 나타났습니다. 이것이 제가 rem 과 함께 더 잘할 수 있는 것이 있는지 생각하기 시작한 것입니다. 왜냐하면 제가 위챗 H5 를 할 때, rem 으로 눈금을 잘못 본 적이 없었기 때문입니다. 내 의견으로는, rem 은 대부분의 인터페이스에서 여전히 잘 적응한다. 그러나 rem 의 단위 계산은 7.5 의 화면 폭을 기준으로 하고 1rem (실제 장치) 의 값은 정수라고 보장할 수 없기 때문에 디자인 원고 위의 작은 공백도 발견했습니다. 예를 들면 10px 보다 작은 것과 같습니다. 그러면 rem 이 정확하지 않게 됩니다. 특히 7.5rem 자체가 화면 폭이지만 px 를 더하면 px 를 제거한 후 얼마나 많은 rem 이 남아 있는지 계산할 수 있습니다.
그 다음 나는 플렉스를 완전히 안아주기 시작했다. Flex 레이아웃을 사용한 후 flex 와 rem 을 결합하면 더 잘할 수 있다는 것을 알게 되었습니다. 간격이 px 를 사용하고 일부 요소가 rem 을 사용하면 나머지는 flex 스트레칭으로 바로 확산될 수 있기 때문에 px 를 빼면 얼마나 많은 rem 이 남아 있는지 걱정하지 않아도 됩니다. 이동측은 기본적으로 flex 와 호환되며 직접 사용할 수 있지만 적절한 커널 접두사를 추가해야 합니다. Flex 의 사용은 레이아웃의 쓰기를 크게 최적화합니다.
나중에, 대중&; Vh 쌍, VW 는 실제로 window.innerWidth 를 기반으로 하고, VH 는 window.innerHeight 100vw 를 기준으로 화면 가시 범위의 너비와 같고, 100vh 는 화면 가시 범위와 같습니다 그리고 VW 가 750px= 100rem (디자인 초안) 과 비슷하다는 것을 발견했습니다. 이 경우 1rem 의 크기는 1vw 와 동일하므로 VW 는 기본적으로 rem 과 거의 동일하게 사용됩니다. 한 화면의 너비는 100vw 와 같고 percentage 와 비슷하지만 VW 는 percentage 처럼 상위 요소가 아닌 화면 너비를 기반으로 하기 때문에 수평 맞춤에 매우 좋은 결과를 얻을 수 있습니다. 하지만 VH 는 한 화면의 너비와 높이로 H5 인터페이스를 만들어야 하는 경우가 있기 때문에 VH 가 작동합니다. 일반적으로 100vh 는 한 화면의 높이입니다. 그러나 VH 를 사용할 때 입력 레이블이 있는 화면 H5 등록 페이지처럼 사용자가 정보를 기입해야 하는 문제가 있습니다. 배경 이미지의 높이를 100vh 로 설정합니다. 입력 상자에 초점이 맞춰지면 휴대폰 키보드가 팝업되고 배경 이미지가 압축됩니다. 화면 표시 높이는 화면 높이에서 휴대폰 키보드 높이를 뺀 것이므로 100vh 는 화면 높이가 아닌 이 높이로 변경됩니다. 이 문제는 VW 와 VH 를 사용할 때 발생하는 유일한 문제입니다. 나는 아직 좋은 해결책을 생각해 내지 못했다. 키보드가 나오지 않으면 화면 높이가 필요하니 VH 를 적극 추천합니다. 반면에 대중은 아직 어떤 문제도 겪지 않았다.
개편에서 몇 가지 방법을 시도해 보았는데, 각 방법마다 장단점이 있다. 그러나 장면 선택 사용에 따라 조합하면 상당히 좋은 맞춤 효과를 얻을 수 있습니다.