前端圖片編輯功能的實踐小結

我們在發佈器上提供了圖片編輯功能，去支持封面圖的編輯，並且統一多端協議，打通素材中心，實現一套協議，多端渲染。

背景

發佈器的整體框架解決了業務接入效率的問題，但我們還需要去解決業務效果問題。短視頻的發佈效果是目前的重點，對比快手、小紅書、抖音等一衆競品，可以發現他們的封面圖的效果更加豐富。因此，我們在發佈器上提供了圖片編輯功能，去支持封面圖的編輯，並且統一多端協議，打通素材中心，實現一套協議，多端渲染。

和競品做一樣的事情？不！

我們研究了抖音、快手等的封面編輯功能。在體驗完之後，感覺他們的功能還是相對單一，基本只有花字、和模板。所以我們提供更豐富的能力，且具有淘寶的特色，能服務好我們的客戶。

▐ 競品分析

下圖一抖音、圖二快手、圖三淘系

au4dHD

圖一

圖二

圖三

▐ 核心效果：花字

花字的難點在於實現一套協議多端渲染，所以需要充分考慮移動端、PC 端的渲染差異。其次需要考慮如何快速拓展新效果。

▐ 難點一：點 9 圖

什麼是點 9 圖？爲什麼難？

點 9 圖是一種特殊的圖片樣式，可以確保圖片拉伸時，所設定的關鍵部分不變形 移動端系統支持點 9 圖渲染，但 PC 端需要實現一套點 9 圖渲染引擎

普通圖片經由原圖拉伸之後，會產生缺角部分的形變。但我們希望的是，邊角部分始終不變，這樣才符合視覺的需求。所以在這張點 9 圖中，兩個缺角，其實就是整張圖的關鍵部分。大多數的點 9 圖，其實也就是對邊角有一些特殊要求。我們通常可以通過 4 個方向的 Padding，來將這些關鍵部分劃分出來。

步驟一：裁剪區塊 （SourceCanvas 對源圖片進行裁剪）

步驟二：區塊拉伸 （ScaleCanvas 對某一個區塊進行拉伸、平鋪）

步驟三：區塊拼接 （TargetCanvas 將處理好的區塊拼接起來，導出目標尺寸的新圖片）

對於一些素材，在上圖的 2、4、5... 用於拉伸的區塊上可能也存在一些圖案，所以我們給定一個寬高比，在寬高比之內，做拉伸，到達寬高比之後，將兩張原圖拼接，並重新拉伸到相應的大小，之後不停的拼接。這種處理方式，可以同時解決相框特效，因爲本質上，相框其實就是區塊 5 爲透明的點 9 圖

▐ 難點二：定位與線性佈局

定位的協議，我們先設定了上、下、左、右、中 5 個方向的二進制值，最後通過位運算得出細分的 9 個點，實現一個 9 宮格式的定位。而對於線性佈局，它原本也是移動端的概念，我們在 PC 端上實現了橫縱兩種配置。

/*定位協議*/
上：00001 (二進制)
左：00010
下：00100
右：01000
中：10000
// 設置好上述五個方向的值之後，對每個方向互相做或運算。
如：
   00001
|  00010
---------
   00011
上左 = 上|左 = 00001 | 00010 = 00011 (十進制：3)
上中 = 上|中 = 00001 | 10000 = 10001 (十進制：17)
上右 = 上|右 = 00001 | 01000 = 01001 (十進制：9)
左中 = 左|中 = 00010 | 10000 = 10010 (十進制：18)
中 = 10000                          (十進制：16)
右中 = 右|中 = 01000 | 10000 = 11000 (十進制：24)
下左 = 下|左 = 00100 | 00010 = 00110 (十進制：6)
下中 = 下|中 = 00100 | 10000 = 10100 (十進制：20)
下右 = 下|右 = 00100 | 01000 = 01100 (十進制：12)

  • 初始化時，以各個圖片的配置計算其位置。

  • 將花字的各個元素合併成一個整體 Group

  • 所有元素以 Group 左上角爲原點對齊，初始化時沒有任何偏移

  • 計算出整個 Group 的最大寬高，以該尺寸作爲一個初始狀態 OriginSize

  • 依照上述初始狀態，對每一個元素做初始化的偏移。如定位值爲 17，那麼他的 left 應該爲(OriginSize.width - Self.width) / 2

  • 初始化後，之後的計算基本與定位值無關，我們記錄初始化後的各個子元素與文本之間的距離，並把它們保存起來，文本 Change 時，對每一個子元素重新設定位置，即可

（上圖中可以看到 “VLOG MY LIFE” 、 “HAVE A NICE DAY” 這兩個黃色文字，其實是以圖片形式展現的，他們的定位值分別爲 17、20 ）

多花字的線性佈局中，初始化時、所有元素的垂直、水平偏移都需要累加上之前所有元素的寬高和；文本編輯時，將以初始化的位置爲基礎，依照文本框寬高的變化，對各個元素的位置進行動態計算。

未來發展

雖然目前的基礎能力組件本身都有對應實現。但落實到具體業務上，我想還是有很長一段路要走的。從 0 到 1 很關鍵，但是想要創造實際價值， 1 只是起點。未來的發展我想主要從性能、功能兩方面下手。

由於用戶的設備配置參差不齊，對 Canvas 頻繁的繪製會帶來性能負擔，我們本意是希望提升用戶體驗，但可能由於性能問題效果大打折扣。我們可以用多層的 Canvas 來實現特效。不同的特效分佈在不同層級的 Canvas 上，這樣可以靈活管理不同特效的性能開銷，最終再合併導出。

我們的期望是能覆蓋 80% 以上的需求，但除了花字以外的其他特效，我們對於用戶的實際訴求支持不完善，沒有豐富的材，沒有做到將特效交給用戶自由配置。我們可以先對齊專業圖片編輯競品的能力，再根據用戶使用反饋，對一些特效行取捨和優化。

 

作者 | 山漸

編輯 | 橙子君

出品 | 阿里巴巴新零售淘系技術

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/vn4V89OW9mXRX5-fNfumfg

猜你喜歡