Apple PICO：首個實用化感知最佳化影像編解碼器
Apple ML Research · 2026-05-25
Apple 本週在 GitHub 上開源了 PICO（Perceptual Image Codec），這是首個針對人類視覺系統直接最佳化的實用型學習式影像編解碼器。與 AV1、VVC、ECM、JPEG-AI 等傳統或學習式編解碼器相比，PICO 在相同感知品質下可達到 2.3–3× 的位元率節省；對比其他學習式編解碼器，也有 20–40% 的位元率優勢。對應論文 arXiv:2605.05148 已同步發布。
核心設計
PICO 的核心差異在於最佳化目標：大多數影像編解碼器以 PSNR 或 MS-SSIM 等訊號層面指標為優化目標，而 PICO 直接使用「大規模主觀評分研究」的人類評分結果作為回饋訓練。研究團隊透過搜尋數百萬個模型配置的空間，找出同時兼顧感知品質與執行速度的最佳架構設計。
另一個關鍵設計選擇是跨平台一致性保證（cross-platform robustness guarantees）。大多數神經網路影像編解碼器在不同硬體或軟體環境下因浮點數差異會產生不一致的解碼結果，難以在生產環境部署。PICO 明確解決了這個問題，使其具備跨平台確定性解碼能力。
規格細節
- 編碼 12MP 圖片（iPhone 17 Pro Max）：230ms
- 解碼 12MP 圖片：150ms
- 對比 AV1/VVC：位元率節省 2.3–3×
- 對比其他學習式編解碼器：位元率節省 20–40%
- 具備跨平台確定性解碼保證
影響範圍
PICO 的發布對 Web 平台與行動應用開發者均具參考意義。位元率節省 2–3× 意味著在相同頻寬條件下可傳輸品質顯著更高的圖片，或在相同品質下大幅降低儲存與傳輸成本。Apple 選擇開源此編解碼器，表明其有意推動學習式影像壓縮在行業層面的標準化討論。GitHub 上已提供資料集連結與 BibTeX 引用，供學術研究者跟進。
GitHub Issues 導覽從 1,200ms 降到 70ms：三層快取架構實戰
GitHub Engineering · 2026-05-14
GitHub Issues 團隊本月發表工程案例，記錄如何將 Issues 頁面的導覽延遲從中位數 1,200ms 降至 700ms，P10 延遲從 600ms 降至 70ms。核心手段是建立三層快取架構，搭配 Stale-While-Revalidate（SWR）語意讓大部分導覽可以立即從本地資料渲染。
原本的問題
Issues 導覽的基線數據顯示：57.6% 的導覽是完整重新載入，中位 HPC（Highest Priority Content）延遲達 1,200ms，已進入「slow」分類。即使是 React soft navigation 也需要約 1,000ms，足以打斷工程師進行 Issue triage 時的注意力流。
採用的方法
團隊實作三層儲存結構：
- In-Memory Cache：快取最熱的 Issue payload，以同步方式讀取，消除 IndexedDB 非同步邊界成本
- IndexedDB（持久化層）：跨分頁和 Session 保留快取，SWR 語意確保即時渲染後再背景更新
- Preheating（背景預熱）：低優先權 Worker 主動走訪 Issue 參考並填充快取，附有 circuit breaker 防止過載
Service Worker 是整個架構的關鍵橋樑：攔截導覽請求，若本地有快取則透過 Request Header 通知伺服器，讓伺服器回傳輕量 HTML shell，由客戶端從快取渲染 Issue 內容。這在減少伺服器計算量的同時，也大幅縮短了 Turbo 導覽的往返時間。
實際效果
| Percentile | 改善前 | 改善後 |
|---|---|---|
| P10 | 600ms | 70ms |
| P25 | 800ms | 120ms |
| P50 | 1,200ms | 700ms |
| P75 | 1,800ms | 1,400ms |
| P90 | 2,400ms | 2,100ms |
預熱部署後快取命中率從初始 33% 上升到 96%。約 30% 的總流量達到 instant（<200ms）導覽，React-specific 路徑更達 70%。團隊接受約 4.7% 的 Server/Cache 數據差異作為速度換一致性的取捨，背景重新驗證確保最終一致性。
WAICT：讓伺服器無法偷換 JavaScript 的 Web 完整性新規格
Mozilla Hacks · 2026-05-05
Mozilla 發表了 Web Application Integrity, Consistency and Transparency（WAICT） 規格草案，目標是解決端對端加密 Web 應用的根本性安全漏洞：遭入侵的伺服器可以針對特定用戶投送篡改過的 JavaScript，使加密功能形同虛設且幾乎無從察覺。Firefox Nightly 中已有早期原型，演示站台 waict.dev 提供可測試的 E2EE 視訊通話範例。
現有信任模型的盲點
傳統瀏覽器安全模型假設伺服器是可信的：瀏覽器提供隔離執行環境，但前提是伺服器交付的是合法程式碼。對於 Signal、Bitwarden 類型的應用，若伺服器遭攻擊者掌控，可以對特定用戶投送修改過的加密實作，使攻擊者能讀取「加密」的訊息。這類攻擊難以偵測，因為受害用戶看不出程式碼有異。
WAICT 的兩個核心屬性
- Integrity（完整性）：瀏覽器執行的程式碼必須與開發者在 manifest 中承諾的版本一致
- Transparency（透明性）：Manifest 必須公開記錄於可獨立稽核的日誌，任何人可驗證
技術機制類似 Certificate Transparency：網站將客戶端程式碼密碼學綁定到 manifest，並將 manifest 提交至公開可稽核的日誌。選擇加入強制模式的網站，若有未公開記錄的程式碼，瀏覽器將拒絕執行，讓攻擊「可觀測且可追溯」。
影響範圍
WAICT 針對高安全性要求的 Web 應用，如加密通訊、密碼管理器、網路投票系統等。規格正在 GitHub 上公開制定，目標是最終標準化，非 Firefox 專屬功能。普通網站無需變更，只有選擇加入的應用才會受到額外的程式碼完整性驗證。
原始來源：Mozilla Hacks、waict.dev