P粉0345716232023-08-25 17:51:37
chrome.webRequest API와 달리 chrome.webNavigation API는 chrome.webNavigation API가 Service Worker를 깨울 수 있기 때문에 완벽하게 작동합니다. 이제 chrome.webRequest API API를 chrome의 에 넣을 수 있습니다. webNavigation.
으아악P粉3863180862023-08-25 00:41:03
문제 설명
해결책:
• 악용
• 离屏API
• nativeMessagingAPI
• WebSocketAPI
• chrome 메시징 API
• 전용 탭
주의
정의에 따라 서비스 워커(SW)는 지속될 수 없으며 브라우저는 특정 시간(Chrome에서는 5분)이 지나면 모든 활동/요청을 강제로 종료해야 합니다. 비활성 타이머(즉, 그러한 활동이 진행되지 않는 경우)는 30초로 훨씬 더 짧습니다.
Chromium 팀 은 현재 이 동작을 좋은 것으로 간주합니다(팀에서는 때때로 일부 측면을 완화했습니다. 예를 들어 Chrome 114는 각 메시지 후에 chrome.runtime 포트를 확장했습니다). 그러나 이는 자주 발생하지 않는 이벤트를 관찰하는 확장 프로그램에만 적용됩니다. 하루에 몇 번만 실행하므로 실행 사이의 브라우저 메모리 공간이 줄어듭니다(예: URL이 포함된 webRequest/webNavigation 이벤트 > 거의 방문하지 않는 사이트에 대한 필터링). 이러한 확장은 상태를 유지하도록 재설계될 수 있습니다(예). 불행히도 그러한 짧은 서사시는 많은 경우에 지속 가능하지 않습니다.
문제 1: Chrome 106 이하에서는 webRequest 이벤트에 대해 소프트웨어 를 깨우지 않습니다.
다른 답변에서 볼 수 있듯이 chrome.webNavigation와 같은 API를 구독해 볼 수도 있지만 작업자 스레드가 시작된 후에 발생하는 이벤트에만 도움이 됩니다.
문제 2: 행사로 인해 직원이 무작위로 잠에서 깨어나지 않습니다.
해결책은 chrome.runtime.reload()를 호출하는 것일 수 있습니다.
문제 3: Chrome 109 이하에서는 이미 실행 중인 백그라운드 스크립트에서 새로운 chrome API 이벤트 의 소프트웨어 수명 주기를 연장할 수 없습니다. 즉, 30초 비활성 제한 시간의 마지막 몇 밀리초 내에 이벤트가 발생하면 코드가 비동기적으로 어떤 것도 안정적으로 실행할 수 없음을 의미합니다. 이는 사용자가 귀하의 확장 프로그램이 신뢰할 수 없다고 생각할 것임을 의미합니다.
질문 4: 확장 프로그램이 원격 연결을 유지하거나 상태(변수)를 다시 빌드하는 데 오랜 시간이 걸리거나 다음과 같은 이벤트가 자주 발생하는 경우 MV2보다 성능이 저하됩니다.
새 이벤트를 위한 SW를 실행하는 것은 본질적으로 새 탭을 여는 것과 같습니다. 환경을 생성하는 데 약 50ms가 걸리고, 전체 SW 스크립트를 실행하는 데 100ms(또는 코드 양에 따라 1000ms)가 걸릴 수도 있고, SW 스크립트를 읽는 데 1ms(또는 데이터에 따라 1000ms)가 걸릴 수도 있습니다. 저장 및 재구축/수화 상태). 거의 빈 스크립트라도 최소 50밀리초가 소요되는데, 이는 고작 1밀리초밖에 걸리지 않는 이벤트 리스너를 호출하는데 상당한 오버헤드입니다.
SW는 탭을 클릭한 후 무언가를 쓰는 등 자연스러운 간격이 있는 사용자 작업에 대한 응답으로 이러한 이벤트가 생성되어 소프트웨어가 종료되고 새 이벤트가 다시 시작되어 CPU, 디스크를 소비하기 때문에 하루에 수백 번 다시 시작될 수 있습니다. , 배터리 및 일반적으로 스케일링 응답에서 눈에 띄는 지연이 자주 발생합니다.
Chrome 110에서는 버그가 발생했습니다. 비동기식 chrome API를 호출하면 작업자 스레드가 추가로 30초 동안 실행됩니다. 이 버그는 아직 수정되지 않았습니다.
//Background.js
으아아아기고자: Kevin Augusto.
Chrome 109 이상에서는 오프스크린 API를 사용하여 오프스크린 문서를 만들고 30초 이내에 메시지를 보내 서비스 워커를 계속 실행할 수 있습니다. 현재 문서의 수명은 제한이 없지만(오디오 재생만 제한되며 우리가 사용하지 않음) 이는 향후 변경될 수 있습니다.
manifest.json
으아아아offscreen.html
으아아아offscreen.js
으아아아배경.js
으아아아nativeMessaging 호스트 시간 "영구" 서비스 워커 스레드 Chrome 105 이상에서는 chrome.runtime.connectNative를 전달하세요. 충돌이나 사용자 작업으로 인해 호스트 프로세스가 종료되면 포트가 닫히고 소프트웨어가 평소대로 종료됩니다. 포트의 onDisconnect 이벤트를 수신하여 chrome.runtime.connectNative를 다시 호출하는 것을 방지할 수 있습니다.
Chrome 116 이상: WebSocket 메시지를 30초마다 교환하여 활성 상태를 유지합니다(예: 25초마다 한 번씩).
단점:
*://*/*)에 대한 광범위한 호스트 권한.
경고! sendMessage를 사용하는 경우 sendMessage에 대한 해결 방법(아래)을 구현할 수도 있습니다.
으아악
으아악
으아악
이미 chrome.runtime.connect와 같은 포트를 사용하고 있는 경우
으아악
으아악
으아악
ManifestV2의 영구 배경 페이지와 동일한 기능을 가지지만 a) 표시되고 b)를 통해 액세스할 수 없습니다(chrome.extension.getBackgroundPagechrome.extension.getViews로 대체 가능).
페이지에 정보/로그/차트/대시보드를 추가하면 사용자가 더 쉽게 사용할 수 있으며 탭이 실수로 닫히는 것을 방지하기 위해 beforeunload 리스너도 추가할 수 있습니다.
영구 서비스 워커와 같은 것이 없기 때문에 상태(변수)를 저장/복원해야 하며 이러한 해결 방법에는 위에서 언급한 대로 작업자가 종료될 수 있는 제한 사항이 있습니다. 예에서 상태를 유지할 수 있습니다.
단지 상태/변수 관리를 단순화하기 위해 작업자 스레드를 영구화해서는 안 됩니다. 이는 상태를 재구축하는 데 비용이 많이 들거나 이 답변의 시작 부분에 나열된 빈번한 이벤트에 빠진 경우 작업자 스레드를 다시 시작하여 악화된 성능을 복원하기 위해서만 수행됩니다.