Swift + UICollectionView + WebPSDWebImage WebP를 간단하게 처리할 수 있는 옵션을 제공했기 때문에 사용해 보았습니다.(주로 성능 조사)pod 'SDWebImage/WebP'까지 합치면 SDWebImage가 WebP를 마음대로 처리할 수 있습니다.
사용법은 평소에 SDWebImage를 사용하는 느낌이에요.imageView.setImageWithURL(NSURL(string: "http://path/to/image.webp"))웹P가 사이즈가 작아 보여서 퍼포먼스 셰프에선 못 참겠어.

WebP와 JPEG의 사이즈 비교

WebP: http://d3lncrho1w0yzl.cloudfront.net/photo1.100x133.2642bytes.webp (2642 bytes)

JPEG: http://d3lncrho1w0yzl.cloudfront.net/photo1.100x133.jpg (12,016 bytes)

및 사용된 이미지가 5x 크기로 열립니다.
또 같은 이미지를 사용하지만 캐시를 하지 않으려고 손발을 굴렸기 때문에 아래로 스크롤하는 부분은 모두 웹에서 시작됐다.

SS

결실

아마도 WebP는 JPEG보다 빠를 것이다.
WebP는 소프트웨어 디코딩이 필요하기 때문에 비용이 들기 때문에 아마도 매우 빠를 것이다.
조사 중

공연에 대한 보충

WebP(20-30% 정도)

JPG(20% 정도)

WebP: CPU ~20-30%, Network ~20KB/s
JPEG: CPU ~20%, Network ~130KB/s
거의 UICollectionVIew+SDWebImage로 인한 부하입니다.
왜 라인은 많이 나뉘는데 표시 순서를 유지합니까?
실장 안 보면 몰라.
WebP가 체감이 더 빠를 수도 있는데...
손에 들고 있는 아이폰 네트워크가 좀 융통성이 없어서 웹P가 비교적 빠르다.
이미지 크기가 작으면 WebP에 큰 부하가 없는 것 같습니다.
오버헤드가 얼마나 되는지, 전문 아카이브를 수행하지 않으면...(TODO)
추기: 로컬 파일(2KB, 100x133)로 해봤습니다.
불러오는 순간 렌더링할 수 있으며 일반적인 이미지와 다를 것이 없습니다.
디코딩이 빠를 수도 있어요.
추기: 로컬 22KB, 640x853의 버섯 이미지로 만들면 확실히 무겁습니다.(스크롤 시 스크래치 표시)
뭐, 컬렉션뷰 3열로 640x853 파일을 읽는 건 흔치 않은 것 같은데... (너비 640이면 아이폰이면 전 사이즈)
로컬에서 읽기 위해 SDWebImageUIImage+WebP.m를 단독으로 사용하지만 한 라인만 만들었기 때문이다.
라인을 분리해서 실시하면 치유가 잘 될 것 같아요.
하지만 실복은 번거롭기 때문에 언젠가는 하고 싶은 리스트에 깊이 들어가게 된다.
추기: 아이템으로 해봤는데 지연감 없는 표현이에요.
JPEG의 경우 이 레벨의 이미지는 60KB 정도입니다.
열화를 억제할 수 있다면 100KB가 넘는다.
CollectionView에서 사용할 줄은 몰랐지만 전체 화면의 이미지가 효과가 있을 수 있습니다.
쉽게 말해 2~5KB 정도의 웹P라면 많이 나와도 JPEG에 비해 성능이 나빠지지 않는다.
내 생각엔(느낌)
동시에 전체 화면에 표시되는 이미지는 WebP입니다.

그나저나 네트워크 성능에 관해서는

이해는 안 되지만 한번 써 보세요.
기사가 누명처럼 변했다.
고려해야 할 일
(RTT) ->SPDY

동시 요청 수 제한

TCP Slow Start -> SPDY

더 나아가 한가할 때Prefetch 이미지

요청 횟수.
휴대전화의 점방이 매우 크기 때문에 가능한 한 삭제하는 것이 비교적 안전하다.
이 프로그램은 한 화면에서 3x5=15의 요청을 건너뛰었다.
네트워크 설정을 할 수 없기 때문에 아무 말도 할 수 없지만 이번에는 기본적으로 점방 비용이다.(100Mbps 회선은 100kB/s만 사용...)
SPDY라고 하면 잘 해결될 것 같아요.
또는, 그림의 배열을 알면, 그림을 concet해서 나누어 줍니다.
동시에 요청 수 제한.
동일한 도메인의 동시 요청 수에 대한 제한
잘 모르겠지만 iOS는 5 같은 것 같아요.(농도->http://stackoverflow.com/questions/15089331/maximize-the-number-of-simultaneous-http-downloads）
즉, 아무리 조화가 잘 되더라도 단일한 영역에서 보내면 다섯 개만 동시에 재생할 수 있다 = 그림을 찾을 수 없다
행동만 봐도 큰 영향을 미칠 것 같은 느낌이 든다.
Native App의 도메인이 닫힙니다.이상하게 들리겠지만 한번 해보자.
(다시 보니 역시 다섯 개씩 가져오는 행동이군요...)
TCP Slow Start
이것은 통신을 시작할 때의 작은 통신량에서 시작하여 끊임없이 한 번 증가하는 양의 알고리즘이다.
일반적인 HTTP 통신이라면 TCP Slow Start를 반드시 사용합니다.
첫 번째 트래픽이 데스크탑인 경우 약 14KB
iOS의 숫자가 매우 작게 설정될 수 있기 때문에 12KB의 이미지가 꺼지지 않을 수도 있습니다.
워낙 회선이 빠르기 때문에 실제로는 2KB와 12KB는 별다른 변화가 없을 것이다.
하지만 수중에 있는 4S3G를 보면 JPEG의 속도가 느려서 영향을 미칠 수 있겠지..
그나저나 TCP 슬로우 스타트는keep-alived의 TCP 통신을 할 때 어떻게 될까? 공부하지 않는다.)
SPDY라고 하면 철저히 해결될 문제다.
이미지의 Prefetch
didScroll의 delegate를 얻을 수 있기 때문에 다양한 프로젝트를 계산하려고 노력합니다.
단순히 기대 캐시를 건너뛰면 되지만 알고리즘이 까다롭다.
Prefetch가 끝나기 전에 그림이 표시된 경우 이중 요청을 보냅니다.
Prefetch가 끝나면 이미지가 표시될 때까지 기다려야 하는 똑똑한 ViewCell
아주 귀찮아요.
A:observe binding 하면 됩니다.
너무 많이 써서 엉망진창이에요.
이따가 정리할게요.아마
어쨌든 도메인 네임 처리와prefetch를 먼저 시도해 봅시다.
그리고 튀는 화면에서 DNSlookup과 TCP handshake 통신을 하면 첫 번째 시야가 더 빨라집니다.
추기:
WebP(2KB)
JPEG(12KB)
15개의 이미지를 모두 표시합니다.초기화된 이미지가 표시되는 데 얼마나 걸리는지 측정한 것이다.
iPhone 4S + Wifi
WebP=>0.9s 전후
JPEG=>1.3s 전후
iPhone 4S + 3G
WebP=>3.0s 정도
JPEG=>4.1s 전후
아무래도 3G 모듈이 좀 딱딱한 것 같아서 상식적인 숫자는 아닌 것 같은데...
iPhone 5s(Simulate) + Wifi
WebP=>0.5s 정도
JPEG=>0.5s 정도
또한 동시에 표시되는 이미지의 수를 늘리기 위해 스크롤이 가속될 때 WebP와 JPEG의 지연이 같은 것을 볼 수 있다.
웹P의 소프트웨어 디코딩 처리인 줄 알았는데 JPEG도 느려졌다.
일반적으로 CollectionView 또는 SDWebImage 오버헤드로 간주됩니다.
추기:
30-50KB 정도의 주문WebP라면 4S도 바로 렌더링할 수 있다(0.1s 미만)
200KB 정도면 1s-2s 정도가 필요해 비현실적이다.(CPU 사용률도 100%가 됩니다.)
31KB(640x853): http://d3lncrho1w0yzl.cloudfront.net/photo1.640x.raw.webp
200KB(2448x3264): http://d3lncrho1w0yzl.cloudfront.net/photo1.raw.webp
하지만 2448x의 이미지는 아이폰에서 사용하지 않겠지...
추기:
980x의 55KB 웹P는 아이폰4S라면 조금 걸린다.구체적으로 CPU 100%는 단 한순간이다.그리기 시간은 0.1-0.2초 정도입니다.
5 번은 오케이.
아이패드면 괜찮아요.
아이패드의 폭은 980 정도이기 때문에 980x입니다.
레티나는 2048x 정도, 웹P는 200KB 정도다.
엄격해요?아이패드 레티나의 CPU가 강해서 잘 걸리지 않을 줄은 몰랐다.
전반적으로 장치에 적당한 해상도 이미지를 보내면 디코딩에 문제가 없을 것이다.
55KB(980x): http://d3lncrho1w0yzl.cloudfront.net/photo1.980x.raw.webp
200KB(2448x): http://d3lncrho1w0yzl.cloudfront.net/photo1.raw.webp
결론:
WebP에 긍정적으로 다가갔어요.