이미지 및 사진 · 이미지 변환기 및 압축기
Web Worker와 OffscreenCanvas가 이미지 변환의 반응성을 유지하는 방법
· 작동 방식
브라우저 처리 중 캔버스 웹 작업자
큰 이미지를 인코딩하는 데는 실제 CPU 시간이 걸리며 기본 스레드에서 수행하면 페이지가 정지됩니다. 이 게시물에서는 Web Worker와 OffscreenCanvas가 UI 스레드 외부로 작업을 이동하는 방법과 해당 아키텍처가 개인 정보 보호 및 제한에 대해 무엇을 의미하는지 설명합니다.
정지되는 탭 — 페이지를 그리는 스레드에서 과도한 인코딩이 실행될 때 발생하는 상황
배치 디코딩, 다시 그리기 및 인코딩에는 CPU 작업과 디코딩된 픽셀 메모리가 필요합니다. 컨트롤, 진행률 업데이트 및 페인팅을 처리하는 동일한 이벤트 루프에서 모든 작업이 실행되면 파일이 완료될 때까지 인터페이스가 응답을 중지할 수 있습니다. 따라서 집중 패널은 전환하지 않는 방문자에게 시작 비용을 지불하는 대신 첫 번째 전환이 시작될 때 모듈 작업자를 게으르게 생성합니다.
응답성은 약속된 타이밍 수치가 아니라 아키텍처 목표입니다. 장치 로드, 이미지 크기, 브라우저 구현 및 배치 구성은 여전히 페이지의 느낌을 결정합니다. 중요한 장치의 대표 파일로 확인하세요. 보편적인 전환 기간을 공개하거나 근로자가 비용이 많이 드는 작업을 무료로 제공한다고 주장하지 마십시오.
메인 스레드와 그것이 중요한 이유 - 레이아웃, 입력 및 스크립트를 위한 하나의 스레드와 작업이 세 가지 모두를 차단하는 시간
기본 스레드는 DOM과 방문자가 터치하는 컨트롤을 소유합니다. ToolAcre는 이를 사용하여 선택 항목의 유효성을 검사하고, 소스 차원에 대해 간략하게 디코딩하고, 설정을 빌드하고, 상태를 렌더링하고 결과를 다운로드합니다. 배치의 반복되는 디코드, 캔버스 그리기 및 인코딩 루프는 `image.worker.js` 뒤에 존재하므로 파일 간에 진행 메시지가 반환될 수 있습니다.
작업자는 모든 기본 스레드 작업을 제거하지 않습니다. 선택한 각 파일은 처음에 패널에서 확인 및 측정되며, 결과는 나중에 미리 보기 및 다운로드 작업으로 변환됩니다. 디자인은 반복되는 무거운 파이프라인을 인터페이스 소유권에서 멀리 이동시키면서 브라우저 API와 프레젠테이션을 각각이 속한 컨텍스트에서 유지합니다.
웹 작업자: DOM이 없는 두 번째 스레드 — 작업자가 만질 수 있는 것과 없는 것, 파일이 여기로 이동하는 방법
작업자는 일반적인 DOM 액세스 권한이 없습니다. 직렬화 가능한 항목 설명, 설정 및 각 파일의 ArrayBuffer를 수신합니다. 모든 항목에 대해 인터페이스에서 사용하는 것과 동일한 순수 변환 계획을 구축하고, Blob을 생성하고, 디코드-그리기-인코드를 실행하고, 결과 Blob을 바이트로 변환하고, 배치의 나머지 부분을 포기하지 않고 파일별 실패를 기록합니다.
이러한 격리는 오류 처리에도 영향을 미칩니다. 이후 항목이 계속되는 동안 손상된 파일이 failures 배열에 들어갈 수 있습니다. 작업자는 항목 간의 취소를 확인하고 현재 파일 이름으로 진행 상황을 보고합니다. UI는 설명 없이 비활성화된 버튼을 그대로 두는 대신 작업자 시간 초과를 더 적거나 더 작은 이미지를 시도하라는 조언으로 변환합니다.
OffscreenCanvas: 표시 요소 없이 그리기 및 인코딩 — 작업자가 자체 캔버스를 얻고 ConvertToBlob을 호출하는 방법
`createCanvas`은 생성자가 존재할 때 `OffscreenCanvas`을 선호합니다. 해당 경로 내에서 `encodeCanvas`는 대상 MIME 유형 및 선택적 품질을 사용하여 `convertToBlob`을 호출합니다. 동일한 렌더러는 HTML 캔버스를 생성하고 콜백 기반 `toBlob`를 사용하여 OffscreenCanvas를 사용할 수 없는 컨텍스트에 대한 대체를 유지할 수도 있습니다.
대체를 정확하게 설명하는 것이 중요합니다. OffscreenCanvas가 선호되며, 소스에서 가능한 유일한 캔버스는 아닙니다. 마찬가지로, 브라우저 WebP 인코딩은 디코드 지원에서 가정하는 대신 최종 인코딩 결과로 확인됩니다. 애플리케이션은 요청된 인코더가 다른 MIME 유형으로 자동 대체하지 않고 형식을 생성할 수 없는 경우 오류를 약속합니다.
전송 가능 항목 및 복사본 — 수십 메가바이트를 복제하지 않고 ImageBitmap 또는 ArrayBuffer를 워커로 이동
작업자를 호출하기 전에 패널은 각 파일을 ArrayBuffer로 읽고 해당 버퍼를 전송 목록에 포함합니다. 모든 입력 버퍼를 복제하는 대신 소유권이 작업자에게 이동됩니다. 인코딩 후 작업자는 Blob 바이트를 Uint8Array로 래핑하고 응답 경로에서 전송할 수 있도록 해당 지원 버퍼를 등록합니다.
이렇게 하면 피할 수 있는 복사가 줄어들지만 디코딩된 이미지와 캔버스는 여전히 메모리를 차지합니다. `executePlan`는 `finally` 블록의 각 ImageBitmap을 닫아 디코딩된 픽셀이 즉시 해제될 수 있도록 합니다. 전송 가능 항목, 명시적 비트맵 정리 및 픽셀 예산 보호 기능은 다양한 압력 원인을 해결합니다. 누구도 무제한 일괄 청구를 승인하지 않습니다.
이 아키텍처가 개인 정보 보호 이야기이기도 한 이유 - 전체 파이프라인이 탭에 있고 네트워크 패널은 침묵을 유지합니다.
변환 코드는 파일 업로드 요청 없이 브라우저 이미지 및 캔버스 API를 호출합니다. 단위 테스트는 네트워크 액세스가 금지된 지원되는 모든 입력-출력 조합에 대한 계획을 보호합니다. 이에 따라 구성의 개인 정보 보호 정책은 좁습니다. 도구 코드는 파일, 붙여넣은 텍스트 또는 생성된 출력을 전달하는 요청을 하지 않습니다.
페이지 자체는 여전히 사이트 자산과 공개된 외부 스크립트를 로드할 수 있으므로 "자동 네트워크 패널"에는 해석이 필요합니다. 로드 후 DevTools를 지우고 새 요청에서 고유하고 무해한 테스트 파일 이름이나 페이로드 바이트를 찾으세요. 소스 검토와 런타임 관찰은 함께 전환 경로에 대한 주장을 뒷받침합니다. 전체 브라우저 환경을 오프라인 샌드박스로 바꾸지도 않습니다.
한계는 어디에서 오는가? 메모리와 캔버스 캡이 업로드 캡을 대체하므로 최대치는 장치입니다.
로컬 처리는 업로드 제한을 입력 유효성 검사, 디코딩된 픽셀, 캔버스 할당 및 사용 가능한 장치 메모리의 제약 조건으로 대체합니다. 각 입력 파일은 초점이 맞춰진 패널에 의해 40 MB으로 제한됩니다. 계획된 출력 기하 도형은 장치 픽셀 예산에 맞춰지며 해당 가드가 요청을 변경할 때 사용자는 축소된 크기의 이름을 지정하는 경고를 받습니다.
구성에는 고정된 배치 수가 없습니다. 20개의 작은 그래픽과 20개의 고해상도 사진은 동일한 할당이 아닙니다. 전화기는 데스크톱보다 먼저 실패할 수 있습니다. 진실한 운영 조언은 지원되지 않는 최대 수 또는 메가픽셀 한도를 게시하지 말고 시간 초과 또는 메모리 오류가 발생한 후 더 적거나 더 작은 파일을 처리하는 것입니다.
요약: 무겁고 조용한 인터페이스 — 이미지 변환기 및 압축기가 장치의 기본 스레드에서 변환을 수행하는 방법
반복되는 파이프라인이 작업자에서 실행되고 해당 캔버스가 화면 밖에 있을 수 있으며 대용량 바이트 버퍼가 전송 가능 항목으로 이동하기 때문에 인터페이스가 더 조용하게 유지됩니다. 이는 마케팅 속기가 아닌 구체적인 소스 속성입니다. 모든 브라우저가 동일하게 일정을 예약한다고 주장하지 않고 작업이 발생하는 위치와 진행 상황이 어떻게 반환되는지 설명합니다.
워크플로가 실제로 사용하는 이미지로 아키텍처를 테스트합니다. 변환 중 컨트롤을 관찰하고, 파일별 진행 상황을 확인하고, 실패를 검사하고, 네트워크 패널에서 테스트 마커를 확인하세요. ToolAcre의 디자인은 불투명한 원격 작업이 아닌 실제 작업자 모듈, 측정된 출력 및 로컬 다운로드 바이트 등 관찰 가능한 증거를 제공합니다.