|
| 1 | +title: 羚珑视频编辑器开发总结 |
| 2 | +subtitle: 羚珑视频编辑器简化视频制作步骤,实现丰富的动态效果设计 |
| 3 | +cover: http://img14.360buyimg.com/ling/s900x383_jfs/t1/117598/19/16824/638806/5f4de7e3E9df6c5cb/7cf1b6118eec8bce.png |
| 4 | +categories: Web开发 |
| 5 | +tags: |
| 6 | + - web |
| 7 | + - 视频编辑器 |
| 8 | +author: |
| 9 | + nick: 凹凸曼-大力士 |
| 10 | +date: 2020-09-01 14:36:00 |
| 11 | +wechat: |
| 12 | + share_cover: http://img14.360buyimg.com/ling/s900x544_jfs/t1/128241/13/11440/853163/5f4de7e3E7b373079/1da4131643707dea.png |
| 13 | + share_title: 羚珑视频编辑器开发总结 |
| 14 | + share_desc: 羚珑视频编辑器简化视频制作步骤,实现丰富的动态效果设计 |
| 15 | +--- |
| 16 | + |
| 17 | +## 项目背景 |
| 18 | + |
| 19 | +羚珑平台在静态类的设计中,已经取得了相应的成绩。在这个基础上结合当前大环境,我们认为可以去做一些动态类的设计,将动画和音效转化为可储存,可移植,可复用的数据。从而用户进行创作的时候,可以通过相对很简单的方式去使用这些高品质的动画和效果。 |
| 20 | + |
| 21 | +## 视频编辑器解决了什么问题? |
| 22 | + |
| 23 | +视频编辑器的主要作用是用户可以通过操作静态的PSD从而得到我们想要的动态设计效果。对比AE等复杂的视频编辑软件,学习成本大大降低,且动效的可复用性、移植性等也减轻了用户的工作量。 |
| 24 | + |
| 25 | +以下为设计效果: |
| 26 | + |
| 27 | + |
| 28 | +## 开发实录 |
| 29 | + |
| 30 | +### 如何让你的静态PSD"动"起来? |
| 31 | + |
| 32 | +参考 AE 的制作动画的过程,首先会预设剧本和分镜,其次规划好分镜中的镜头如何运动,角色如何运动,以及处理和规划素材。我们可以提炼出几个关键点:多场景、镜头移动(即场景整体的动效)、规划素材(图层内容出现时刻及时间长短灵活可控) |
| 33 | +视频编辑器操作主要涉及功能点如下: |
| 34 | +* 多场景的切换与转场效果的融合,使视频效果更加生动灵活; |
| 35 | +* 场景动效以及动效参数的设置,减少了同类型动效的开发(如位移动效合并为一个),也打开了设计师对动效使用的想象力,收获额外的视频效果; |
| 36 | +* 图层操作,调整出现时刻及持续时间; |
| 37 | + |
| 38 | +编辑器界面如下图: |
| 39 | + |
| 40 | + |
| 41 | +### 状态管理 |
| 42 | + |
| 43 | +视频编辑器的实现主要分为 5 个部分,视频预览区、动效添加区、参数编辑区、图层操作区、场景操作区,如下图其他部分的每一个操作都会映射到视频预览区,且各个部分数据共享。除此之外,编辑器的每一步操作都需要被”记住“,便于编辑的人回退、还原其操作。 |
| 44 | + |
| 45 | + |
| 46 | +经分析会涉及到以下场景,如: |
| 47 | +* 预览区组件的状态需要共享 |
| 48 | +* 其他操作区的变动会改变预览区组件的状态 |
| 49 | +* 组件状态都需要可撤销/还原 |
| 50 | + |
| 51 | +我们可以采用 redux 集中管理状态以减少组件之间的数据流传递;对于撤销还原功能,我们可以采用 redux-undo,根据现有的 **reducer** 和配置对象,增强现有其撤消还原功能。 |
| 52 | +``` |
| 53 | +import ReduxUndo from 'redux-undo' |
| 54 | +//定义原有的 reducer |
| 55 | +const editReducer = (state = null, action) => { |
| 56 | + switch (action.type) { |
| 57 | + case VIDEO_INIT: { |
| 58 | + const { templates } = action.payload |
| 59 | + return { templates } |
| 60 | + } |
| 61 | + case VIDEO_TPL_CLEAR: { |
| 62 | + return {} |
| 63 | + } |
| 64 | +} |
| 65 | +
|
| 66 | +//通过 ReduxUndo 增强 reducer 的可撤销功能 |
| 67 | +export const undoEditReducer = ReduxUndo(editReducer, { |
| 68 | + initTypes: [VIDEO_TPL_CLEAR], |
| 69 | + filter: function filterActions (action, currentState, previousHistory) { |
| 70 | + const { isUndoIgnore = false } = action |
| 71 | + return !isUndoIgnore |
| 72 | + }, |
| 73 | + groupBy: groupByActionTypes([SOME_ACTION]), |
| 74 | + /* |
| 75 | + 自定义分组 |
| 76 | + groupBy:(action, currentState, previousHistory) => { |
| 77 | + |
| 78 | + }, |
| 79 | + */ |
| 80 | +}) |
| 81 | +``` |
| 82 | + |
| 83 | +**参数说明** |
| 84 | +* **initTypes**:历史记录将根据初始化操作类型进行设置(重置) |
| 85 | +* **filter**:过滤器, 可以帮助过滤掉不想在撤消/重做历史中包含的操作; |
| 86 | +* **groupBy**:可以通过默认的 groupByActionTypes 方法将动作组合为单个撤消/重做步骤。也可以实现自定义分组行为,如果返回值不为 null,则新状态将按该返回值分组。如果下一个状态与上一个状态归为同一组,则这两个状态将在一个步骤中归为一组;如果返回值为 null,则 redux-undo 不会将下一个状态与前一个状态分组。 |
| 87 | + |
| 88 | +使用 store.dispatch() 和 Undo/Redo Actions 对你的状态执行撤消/重做操作 |
| 89 | +``` |
| 90 | +import { ActionCreators } from 'redux-undo' |
| 91 | +export const undo = () => (dispatch, getState) => { |
| 92 | + dispatch(ActionCreators.undo()) |
| 93 | +} |
| 94 | +export const redo = () => (dispatch, getState) => { |
| 95 | + dispatch(ActionCreators.redo()) |
| 96 | +} |
| 97 | +export const recovery = () => (dispatch, getState) => { |
| 98 | + dispatch(ActionCreators.jumpToPast(0)) |
| 99 | + dispatch(ActionCreators.clearHistory()) |
| 100 | +} |
| 101 | +``` |
| 102 | + |
| 103 | +**总结** |
| 104 | + |
| 105 | +对于状态管理,首先我们可以从以下几点考虑是否需要引入redux、mobx等工具: |
| 106 | +* 状态是否被多个组件或者跨页面共享; |
| 107 | +* 组件状态需要跨越生命周期; |
| 108 | +* 状态需要如持久化,可恢复/撤销等操作。 |
| 109 | +在使用redux管理状态时,避免将所有状态抽离至redux store中,如 |
| 110 | +* 组件的私有状态; |
| 111 | +* 组件状态传递层级较少; |
| 112 | +* 当组件被unmount后可以销毁的数据等 |
| 113 | +原则上是能放在组件内部就放在组件内部。其次为了状态的可读性和可操作性,在状态结构设计前,需要理清楚各个数据对象的关系,平衡数据获取及操作复杂度,推荐扁平化数据结构以减少嵌套和数据冗余。 |
| 114 | + |
| 115 | +### 图层交互 |
| 116 | + |
| 117 | +在使用编辑器的过程中,图层的交互操作是最多最频繁的,我们参考了常用的客户端视频编辑软件 AE、Final Cut 的交互,尽可能在 Web 上提供用户操作的便利性及图层可视化,具体效果如下: |
| 118 | + |
| 119 | + |
| 120 | +梳理图层操作需求,主要包含: |
| 121 | +* 图层轨道需要伸缩 ( 调整图层持续时间 |
| 122 | +* 图层上的动效轨道可以单独伸缩( 调整动效持续时间 |
| 123 | +* 图层轨道需要左右移动,且动效轨道跟随移动(调整出现的时刻 |
| 124 | +* 动效轨道可以单独左右移动 (调整动效出现的时刻 |
| 125 | +* 不同图层轨道可以上下调整顺序,动效轨道跟随图层轨道移动 (调整图层顺序 |
| 126 | +* 拖动时显示不同的外观 |
| 127 | + |
| 128 | +初始的时候首先考虑到需要移动图层顺序,我们基于 react-sortable-hoc 实现了基本的图层顺序拖曳移动 , 但是对于图层的拉伸、左右拖动处理需要自定义鼠标事件进行处理,并需要自定义计算控制图层的移动,而且最初没有考虑到拖动过程中拖动源的外观需要调整,最终,我们放弃这种实现。我们需要一个可定制化程度更高的拖曳组件,经过一番比较后,我们最终选定了 [react-dnd](https://react-dnd.github.io/react-dnd/about) 拖拽组件,查看其官方说明: |
| 129 | +> 可帮助您构建复杂的拖放界面,同时保持组件的分离;且适用于拖动时在应用程序的不同部分之间传输数据,更完美的是组件可以响应拖放事件更改其外观和应用程序状态。 |
| 130 | +
|
| 131 | +详细说明下,react-dnd 建立在 HTML5 拖放 API 之上,它可以对已拖动的 DOM 节点进行屏幕快照,并直接将其用作“拖动预览”, 简化了我们在光标移动时进行绘制的操作。不过,HTML5 拖放 API 也有一些缺点。它在触摸屏上不起作用,并且在 IE 上提供的自定义机会少于其他浏览器。这就是为什么在 react-dnd 中以可插入方式实现 HTML5 拖放支持的原因,你也可以不使用它,根据触摸事件,鼠标事件等自己来编写其他实现。 |
| 132 | + |
| 133 | +下面,我们从外到内,介绍基本的实现。 |
| 134 | + |
| 135 | +### 场景层面 |
| 136 | + |
| 137 | +引入所需组件 |
| 138 | + |
| 139 | +``` |
| 140 | +import { DndProvider } from 'react-dnd' |
| 141 | +import HTML5Backend from 'react-dnd-html5-backend' |
| 142 | +``` |
| 143 | + |
| 144 | +将 DndProvider 放在整个场景的外层,设置 backend 为 HTML5Backend |
| 145 | +``` |
| 146 | +<DndProvider backend={HTML5Backend}> |
| 147 | + <TemplateViewer // ----- 单个场景展示组件 |
| 148 | + template={tpl} |
| 149 | + handleLayerSort={handleLayerSort} |
| 150 | + onLayerDrop={onLayerDrop} |
| 151 | + onLayerStretch={onLayerStretch} |
| 152 | + /> |
| 153 | + <CustomDragLayer /> // --- 自定义拖拽预览图层 |
| 154 | +</DndProvider> |
| 155 | +
|
| 156 | +``` |
| 157 | + |
| 158 | + |
| 159 | +<TemplateViewer /> 里包含不同类型的图层组件。每个图层组件都提供一个纯渲染组件的方法 renderLayerContent,大致结构如下: |
| 160 | + |
| 161 | +``` |
| 162 | +export function renderLayerContent (layer) { |
| 163 | + return <div style={{...}}>...</div> |
| 164 | +} |
| 165 | +
|
| 166 | +export default function XxxxLayerComponent (layer) { |
| 167 | + ... |
| 168 | + return <div>{renderLayerContent(layer)}</div> |
| 169 | +} |
| 170 | +``` |
| 171 | + |
| 172 | +<CustomDragLayer /> 里根据当前拖拽的对象的组件类型,调用相应 renderLayerContent 绘制拖拽可视内容,以实现拖拽前后的视图一致。 |
| 173 | + |
| 174 | + |
| 175 | +### 图层层面 |
| 176 | + |
| 177 | + |
| 178 | +图层可以上下拖动,也可以左右拖动,意味它本身即是拖拽源,也是放置的目标。 |
| 179 | + |
| 180 | +为了区分拖拽的目的,我们定义了两个拖拽源 |
| 181 | +``` |
| 182 | + const [{ isHorizontalDragging }, horizontalDrag, preview] = useDrag({ |
| 183 | + item: { |
| 184 | + type: DragTypes.Horizontal, |
| 185 | + }, |
| 186 | + collect: monitor => ({ |
| 187 | + isHorizontalDragging: monitor.isDragging(), |
| 188 | + }), |
| 189 | + }) |
| 190 | + const [{ isVerticalDragging }, verticalDrag, verticalPreview] = useDrag({ |
| 191 | + item: { |
| 192 | + type: DragTypes.Vertical, |
| 193 | + }, |
| 194 | + collect: monitor => ({ |
| 195 | + isVerticalDragging: monitor.isDragging(), |
| 196 | + }), |
| 197 | + }) |
| 198 | +``` |
| 199 | + |
| 200 | +在放置处理中根据拖拽类型进行判断处理 |
| 201 | +``` |
| 202 | + const [, drop] = useDrop({ |
| 203 | + accept: [DragTypes.Horizontal, DragTypes.Vertical], |
| 204 | + drop (item, monitor) { |
| 205 | + // 处理左右拖动 |
| 206 | + }, |
| 207 | + hover: throttle(item => { |
| 208 | + // 处理上下排序 |
| 209 | + }, 300), |
| 210 | + }) |
| 211 | +``` |
| 212 | + |
| 213 | +将定义好的拖动源和放置目标关联 DOM 。最外层 DIV 为图层可拖动区域即放置目标,然后依次为水平拖拽层,垂直拖拽层 |
| 214 | + ``` |
| 215 | + <div ref={drop}> // --- 放置目标 DOM |
| 216 | + <div ref={verticalPreview}> |
| 217 | +
|
| 218 | + <div ref={horizontalDrag}> // --- 水平拖拽 DOM |
| 219 | + |
| 220 | + <div ref={verticalDrag}> // --- 垂直拖拽 DOM |
| 221 | + <Icon type='drag'/> |
| 222 | + </div> |
| 223 | +
|
| 224 | + /* 图层内容展示 */ |
| 225 | + <div>{renderLayerContent(layer)}</div> |
| 226 | + </div> |
| 227 | + </div> |
| 228 | + </div> |
| 229 | + ``` |
| 230 | + |
| 231 | +以上关于图层上下拖动、左右拖动的大体框架已经实现。 |
| 232 | + |
| 233 | +上下拖动排序时,为了拖动过程中不展示拖动源只保留生成的屏幕快照,可以根据当前的拖动状态将拖动源的透明度设置为 0 |
| 234 | + |
| 235 | + |
| 236 | +``` |
| 237 | +<div ref={drop}> // --- 放置目标 DOM |
| 238 | + <div |
| 239 | + ref={verticalPreview} |
| 240 | + style={{ opacity: isVerticalDragging ? 0 : 1 }} |
| 241 | + > |
| 242 | + ... |
| 243 | + </div> |
| 244 | +</div> |
| 245 | +
|
| 246 | +``` |
| 247 | +水平拖动时,设置拖动源半透明,处理方式与上下拖动时同理。 |
| 248 | + |
| 249 | + |
| 250 | +### 图层内 |
| 251 | + |
| 252 | +图层内有两个区域,下方区域可通过左右两端的操作点进行拉伸,上方区域可以在下方区域的宽度内左右移动以及同样通过左右两端的操作点进行拉伸。 |
| 253 | +移动的实现方式前面已经介绍过就不重复了,针对拉伸的操作,我们封装一个 Stretch 类来统一处理 |
| 254 | +``` |
| 255 | +function Stretch ({ |
| 256 | + children, |
| 257 | + left, |
| 258 | + width, |
| 259 | + onStretchEnd, |
| 260 | + onStretchMove, |
| 261 | +}) { |
| 262 | + function handleMouseDown (align) { |
| 263 | + // 计算偏移 |
| 264 | + } |
| 265 | +
|
| 266 | + return ( |
| 267 | + <div> |
| 268 | + {children} |
| 269 | + <div |
| 270 | + className={classnames(styles.stretch, styles.stretchHead)} |
| 271 | + onMouseDown={handleMouseDown('head')} |
| 272 | + /> |
| 273 | + <div |
| 274 | + className={classnames(styles.stretch, styles.stretchEnd)} |
| 275 | + onMouseDown={handleMouseDown('end')} |
| 276 | + /> |
| 277 | + </div> |
| 278 | + ) |
| 279 | +} |
| 280 | +``` |
| 281 | + |
| 282 | +将需要支持拉伸的区域作为作为 Stretch 的 children 传递进来 |
| 283 | +``` |
| 284 | +<div> |
| 285 | + <div> |
| 286 | + {motions.map((motion, i) => <Stretch key={i}>{/* 上方某个区域 */}</Stretch>)} |
| 287 | + </div> |
| 288 | + <div> |
| 289 | + <Stretch>{/* 下方区域 */}</Stretch> |
| 290 | + </div> |
| 291 | +</div> |
| 292 | +``` |
| 293 | + |
| 294 | +## 体验优化 |
| 295 | + |
| 296 | +### 添加快捷键 |
| 297 | + |
| 298 | +整个编辑器内容比较的多,对频繁的操作,我们可以保留常用快捷键的操作习惯。如空格播放、delete 删除等等,该功能我们可以使用 react-hot-keys 实现。 |
| 299 | + |
| 300 | +首先引入该快捷键库,然后指定绑定的快捷键,添加事件处理。 |
| 301 | +``` |
| 302 | +import Hotkeys from 'react-hot-keys' |
| 303 | +
|
| 304 | +<Hotkeys |
| 305 | + keyName='space' |
| 306 | + onKeyDown={(keyName, e) => { |
| 307 | + e.preventDefault() |
| 308 | + play() |
| 309 | + }} |
| 310 | +/> |
| 311 | +``` |
| 312 | + |
| 313 | +### 文本转 SVG |
| 314 | + |
| 315 | +另外图层内容展示时有个小技巧,产品需求中文案图层平铺展示。可怜我最初竟然是通过文本长度以及轨道长度计算出文本展示次数,然后再放到 push 到节点中。经大佬改造后才明白可以将文本转化为 SVG 然后以背景图展示,真香! |
| 316 | +``` |
| 317 | +<div |
| 318 | + className={styles.contentText} |
| 319 | + style={{ |
| 320 | + backgroundImage: `url("data:image/svg+xml;utf8, |
| 321 | + <svg xmlns='http://www.w3.org/2000/svg' version='1.1' width='${size(layer.text) * 12 + 15}px' height='35px'> |
| 322 | + <text x='10' y='22' fill='black' font-size='12'> |
| 323 | + ${layer.text} |
| 324 | + </text> |
| 325 | + </svg>")`, |
| 326 | + }} |
| 327 | +/> |
| 328 | +``` |
| 329 | +实现效果: |
| 330 | + |
| 331 | + |
| 332 | +## 项目总结 |
| 333 | + |
| 334 | +本文讲述了视频编辑器中操作区主要模块的处理。关于状态管理,我们主要需要明确引入管理工具的是否必要以及使用状态管理工具后是否所有状态都必须移入store中等等。另外对于复杂的图层拖拽功能,要像剥洋葱一样,先层层拆解,从而层层完善其结构。 |
| 335 | +对项目而言,拿到需求后,我们从整体到局部进行分析,优先确定整体的框架、核心功能的实现方式等,进而考虑如何提高用户体验度。需求分清主次,以便于我们排列优先级从而开发提高效率。 |
0 commit comments