답변:
PNG는 픽셀 완벽 (비 손실)이며 표시하는 데 추가 CPU 에너지가 거의 필요하지 않습니다. 그러나 큰 PNG는 압축 된 이미지 형식보다 저장소에서 읽는 데 더 오래 걸리므로 표시 속도가 느려집니다.
JPG는 저장하기에 더 작지만 손실이 많으며 (양은 압축 수준에 따라 다름) 표시하려면 훨씬 더 복잡한 디코딩 알고리즘이 필요합니다. 그러나 일반적인 압축 및 이미지 품질은 일반적으로 사진에 충분합니다.
사진과 큰 모든 것에 JPG를 사용하고, 작거나 "픽셀 완벽"(예 : 작은 아이콘)으로 표시되도록 설계된 모든 것에 PNG를 사용하거나 합성 된 투명 오버레이 등의 일부로 사용합니다.
Apple은 iPhone App Bundle에 포함 된 PNG 이미지를 최적화합니다. 실제로 iPhone은 하드웨어에 맞게 색상 바이트가 최적화 된 특수 인코딩을 사용합니다. XCode는 프로젝트를 빌드 할 때이 특수 인코딩을 처리합니다. 따라서 iPhone에서 PNG를 사용하면 크기 고려 사항 외에 추가 이점이 있습니다. 이러한 이유로 인터페이스의 일부로 표시되는 이미지 (테이블보기, 레이블 등)에 PNG를 사용하는 것이 좋습니다.
사진과 같은 전체 화면 이미지를 표시하는 경우 PNG는 손실이없고 이미지를 디코딩 할 때 리소스 사용량은 말할 것도없고 시각적 품질이 JPG보다 좋기 때문에 여전히 이점을 얻을 수 있습니다. 파일 크기의 실질적인 이점을 확인하기 위해 JPG의 품질을 줄여야 할 수 있지만 최적이 아닌 이미지를 표시합니다.
파일 크기는 확실히 요소이지만 이미지 형식을 선택할 때 다른 고려 사항도 있습니다.
PNG에 대해 고려해야 할 중요한 사항이 하나 있습니다. PNG가 Xcode 빌드에 포함 된 경우 iOS에 최적화됩니다. 이것을 PNG 크러쉬라고합니다. 런타임에 PNG를 다운로드하면 분쇄되지 않습니다. 분쇄 된 PNG는 100 % JPG와 거의 동일하게 실행됩니다. 낮은 품질의 JPG가 높은 품질의 JPG보다 더 잘 실행됩니다. 따라서 성능 측면에서 가장 빠른 것부터 가장 느린 것까지 낮은 품질의 JPG, 고품질 JPG, PNG Crushed, PNG가됩니다.
PNG를 다운로드해야하는 경우 다운로드하기 전에 서버에서 PNG를 분쇄하는 것이 좋습니다.
http://www.cocoanetics.com/2011/10/avoiding-image-decompression-sickness/
Cocoanetics 좋은 아이폰 OS의 성능 벤치 마크 게시 된 블로그 와 분쇄하지 않고, 다양한 품질 수준 및 PNG 파일에서 JPG를의를.
그의 결론에서 :
알파 채널이 절대적으로 필요하거나 PNG를 사용해야하는 경우 웹 서버에 pngcrush 도구를 설치하고 모든 PNG를 처리하도록하는 것이 좋습니다. 거의 모든 경우에 고품질 JPEG는 더 작은 파일 크기 (즉, 더 빠른 전송)와 더 빠른 압축 및 렌더링을 결합합니다.
PNG는 UI 요소에 사용할 작은 이미지에 적합하지만 카탈로그 나 잡지와 같은 전체 화면 응용 프로그램에 사용하는 것은 합리적이지 않습니다. 소스 자료에 따라 60 ~ 80 % 사이의 압축 품질을 선택하고 싶을 것입니다.
모든 것을 표시하는 측면에서 한 번 그린 UIImage 인스턴스에는 캐시 된 압축되지 않은 버전의 파일이 포함되어 있기 때문입니다. 그리고 큰 이미지가 화면에 나타나기 위해 시각적으로 멈추지 않는 곳에서는 미리 두 개의 이미지에 대해 강제로 압축을 풀어야합니다. 그러나 이러한 작업에는 많은 양의 RAM이 필요하며 지나치게 많이 사용하면 앱이 종료 될 수 있습니다. NSCache는 RAM이 부족 해지면 이미지를 자동으로 제거하므로 자주 사용하는 이미지를 배치하기에 좋은 장소입니다.
이미지에 여전히 압축 해제가 필요한지 여부를 알 수있는 방법이 없다는 것은 유감입니다. 또한 이미지가이 효과에 대해 알리지 않고 압축되지 않은 버전을 제거했을 수 있습니다. 이는 Apple의 버그보고 사이트에서 제기 할 수있는 좋은 레이더 일 수 있습니다. 그러나 다행스럽게도 이미지가 이미 압축 해제 된 경우 위와 같이 이미지에 액세스하는 데 시간이 걸리지 않습니다. 그래서 당신은 "적시에"뿐만 아니라 "경우에 따라"도 그렇게 할 수 있습니다.
약간의 감압 성능 데이터를 공유하겠다고 생각했습니다 ...
360도 뷰어의 프로토 타이핑을하고 있습니다. 사용자가 여러 각도에서 찍은 일련의 사진을 회전시켜 물체를 부드럽게 회전 할 수있는 느낌을 줄 수있는 캐 러셀입니다.
방정식에서 파일 i / o를 가져 오기 위해 이미지 데이터를 NSData 배열에로드했지만 즉시 NSImage를 만듭니다. 거의 최대 프레임 속도 (~ 25fps)에서 테스트하고 Instruments에서 시청하면 앱이 CPU에 확실히 묶여 있고 CPU 부하가 약 10 % 증가하여 ~ 275kb png와 ~ 75kb jpg를 보여줍니다.
확실히 말할 수는 없지만 CPU 제한은 일반적인 프로그램 실행과 메모리의 모든 데이터 이동에서 비롯된 것이지만 이미지 압축 해제는 GPU에서 수행됩니다. 어느 쪽이든 JPG 대 PNG 성능 인수는 특히 더 작은 파일 크기 (따라서 적어도 체인의 일부 부분에서 메모리에있는 개체의 더 작은 크기)를 고려할 때 JPG를 선호하는 것으로 보입니다.
물론 모든 상황은 다르며 테스트를 대신 할 수는 없습니다 ...
적절한 형식으로 아트 워크 제작 섹션의 휴먼 인터페이스 지침 에 언급 된 '사진에 JPEG 사용' .