Search
這個月初小編去 COSCUP 分享的「模糊也是一種美 - 從 BlurHash 探討前後端上傳圖片架構」影片出來啦，有興趣的朋友可以搭配之前的 QA 一起看喔！
* 之前整理的 QA：https://www.facebook.com/kewang.information/posts/2679222995687391
#coscup #blurhash #funliday
上星期大家都有來聽小編在 COSCUP 分享的「模糊也是一種美 - 從 BlurHash 探討前後端上傳圖片架構」嗎？這個技術已經有實作在 Funliday-旅遊規劃 的 Web 跟 Android 囉。這個議題結束後，有朋友問了一些問題，這裡順便來統整回答一下：
1. client side upload 方式從 server 產出的 signed URL 是個什麼樣的東西？
signed URL 是為了讓沒有 access key 及 secret key 的 sender 也能在有權限管理的保護下做 S3 的檔案處理，而 Funliday 在這裡的實作是不用原檔名做 key，改用 UUID 產生避免檔名衝突。
2. client BlurHash decode 的效率如何？
在做 BlurHash decode 的時候因為用到的是 CPU 運算，而且 JavaScript 又是 single thread 的關係，所以在 decode 同時移動畫面的話，可能會造成 CPU 不夠力的 client 會有極短暫的延遲時間。這時候可以考慮把 decode 丟到 web worker 處理，避免卡到 UI thread 的順暢度。用 Android 的術語來說就是開 AsyncTask 啦！
3. 你們後來是使用哪種方式做上傳呢？
原先是使用 server side (2) 的方式，但在處理 MQ 上傳後的 notify 花了不少時間，而且上傳到 S3 也沒這麼快，所以後來改用 client side 的方式做上傳功能，運作上也比原先的方式順暢。
4. 為什麼不用 medium 的方式處理 blur？
因為 medium 檔案比 BlurHash 的字串大很多，而且要多發一次 request，成本比 BlurHash 高出不少，所以我們認為用 BlurHash 會是比較好的。
---
當然也是要感謝 gslin 大大，他在 4/26 (日) 簡單介紹了 BlurHash。小編下午看到這篇文章，馬上丟去 slack 問我們的設計師大大，看她覺得這效果如何？她過沒多久回覺得不錯，小編就在星期日的下午開始處理 server side 的實作。隔天星期一有了初步的成果，然後給我們的安卓五星上將看，星期二就完成 Android 實作並上線了！
也是因為 CDN 那塊後來把原先的 lambda 改用自己寫的 server 處理，所以實作 BlurHash 才能這麼快。lambda 這塊也是血淚史，下略 10000 字，之後有機會再跟大家分享。
---
歡迎大家對這塊有興趣的也來交流一下喔！
#blurhash #coscup
https://coscup.org/2020/zh-TW/agenda/QBHUWY
---
BlurHash 可以用來增強在觀看圖片時的使用者體驗，用 30 bytes 就能呈現出有意義的 placeholder。
但不同的圖片存取架構在實作 BlurHash encode 的時候會有不同做法。
這次的分享就會用 BlurHash 做為引子，帶入前端上傳圖片以及後端上傳圖片兩種系統架構要注意的地方。
主要內容包括：BlurHash、S3、CDN、Nodejs、SocketIO、Message queue、Image processing, Lazy loading、React
kewang 會以後端為主，分享以前後端不同方式上傳圖片的注意事項；而 simon 則會以前端 React 為主，並帶入 BlurHash + Lazy loading 的實作過程以及注意事項
---
小編第一次上 COSCUP 的正式 talk，這幾天持續整理投影片，歡迎這假日有空的朋友過來聽聽喔。搶先丟出其中一張投影片來給大家看看。
而且今年還是首次不用推倒售票亭，這麼好康一定要來聽啊！
時間：2020/08/01 (六) 10:45 ~ 11:15
地點：台科大 TR410 教室
#funliday #blurhash
blurhash 在 Awesome X - BlurHash 創造與Medium... | Facebook 的必吃
BlurHash 創造與Medium 一樣的圖片載入效果的套件，原理是預先把朦朧美的圖片演算成一串簡短的代碼，並在瀏覽器解碼顯示出來，在大圖載入前用朦朧美的 ... ... <看更多>