雲計算

玩轉娛樂化時代|淘系互動團隊幾年的技術沉澱+經驗都在這!

lALPGpb_5uSVuarNAZDNAtA_720_400.png_720x720g.jpg

作者|渚薰
出品|阿里巴巴新零售淘系技術部

作者簡介:淘系技術部-互動-渚薰。12年加入阿里,曾先後參與和擔任手淘無線基礎架構工作、WEEX 前端框架工作。16年來到淘系互動團隊,帶領一群志同道合的兄弟姐妹們在互動業務領域探索技術價值、助力業務成長。

在人口紅利開始萎縮,各個 App 都開始以娛樂化互動作為重要手段來爭奪普通民眾的在線時長。因此在諸如互動業務領域內,我們就需要打造核心輕量化、研發速度快、用戶體驗好的互動技術。它是 Web 技術的一塊特定領域,它融合了圖形、渲染、動畫以及前端工程和軟件工程等知識。本文會把這些領域的知識有條理的梳理一遍呈現給大家。

解惑娛樂互動:認知場景,知道娛樂化互動的概念和意義。

為什麼要做娛樂化的互動

想必很多做業務的同學,已經聽過無數次產品同學把互動這個詞掛在嘴邊了。那麼為什麼一個在電商業務,需要把互動扯進來呢?我們來看看2020財年阿里巴巴投資者大會上,一張非常有份量的 PPT :

屏幕快照 2020-04-03 下午2.29.08.png

PPT 中,列舉了不少淘系內的大型互動產品,比如金幣莊園、淘寶人生,以及疊貓貓和雙11戰隊等大促互動。這些互動無外乎是吸引用戶、持續“消耗”用戶時間的有效手段。

同時,這類互動也會通過金幣、紅包、虛擬形象等利益或內容滲透到商業中,直接或間接的帶來 GMV 的增長。從戰略的角度來說“娛樂化互動產品矩陣、加速拉動用戶活躍度提升”,就意味著娛樂化的互動所帶來的價值是非常可觀的。

用戶面前的甜點

為什麼互動會如此吸引用戶,這要從用戶喜歡的三類事物說起:內容、社交和娛樂。

  • 內容:比如直播、短視頻、信息流、諮詢等是依靠內容本身來吸引用戶的。
  • 社交:比如朋友圈、陌生人交友等是通過人與人之間產生聯繫來吸引用戶的。
  • 娛樂:比如影音、書籍、遊戲等是通過賦予各類知識、情感享受來吸引用戶的。

我們常常會發現,內容被社交化,比如抖音。又會發現娛樂被社交化,比如王者榮耀。很少會發現獨立某類事物的產品存在,都是融合了內容、社交和娛樂的綜合產物。

用戶是如何互動的

互動可以理解為一種行為,它把內容、社交這類事物的產生在人人之間、人與平臺之間傳遞起來。比如這張圖:

屏幕快照 2020-04-03 下午2.30.12.png

用戶和用戶之間,用戶和平臺之間想要得到這些事物,就需要“互動”。這種過程它可能持續很久,也可能是一瞬間的事情。娛樂化能讓這些過程變得更有趣味性,比如藉助好玩的形式獲得平臺發出的紅包,又比如用雙11戰隊互相PK的方式讓用戶間完成社交聊天《知乎-如何看待2019雙11蓋樓挑戰?》。種種有趣的玩法和現象下,用戶樂於其中並最終獲得自己想要的事物,這就是我認為的娛樂化互動的意義。

所以總結下,互動並不是一種事物,娛樂化互動也並不是遊戲,它是一種有趣、好玩的獲得目標事物的過程。這個過程,用趣味的場景或玩法是非常有效的手段。

屏幕快照 2020-04-03 下午2.30.48.png

如何閱讀正文

說了這麼多,還只是個引子。接下來的內容都是基於這幾年淘系互動團隊在互動技術上的沉澱和經驗闡述的。如果,你已經是一位資深的互動技術架構師,希望你能找到互動技術和業務的結合點,跨領域形成融合。如果,你是一位互動業務的前端,希望你能分析自身業務處於哪一個階段、哪一個層次,並更加助力你的業務。如果,你仍然是一位非互動業務的前端,希望你能拓展知識領域、儲備相關技能,迎接娛樂化浪潮。

解讀知識領域:勾勒互動技術的圖譜,跨領域拓展知識。本文接下來從前端開發者的視覺來科普互動領域的技術體系。

技術知識圖譜

要開發互動 H5,到底需要學習多少知識?網傳曾有怎麼一份知識樹(出自 miloyip 的 Game Programmer)。這份知識樹從最基礎的知識到專業技能覆蓋的非常全,但這肯定會“逼退”很多想要進入這個領域的前端。但我的目標是讓前端開發者能開發娛樂化的互動,而不是真正的開發一款遊戲,所有我就對這些知識進行了重新歸類整理。

屏幕快照 2020-04-03 下午2.33.01.png

第一,編程基本功是每位技術同學都需要掌握的,特別是計算機科學和軟件開發,和具體的技術棧或者專業知識領域不強相關。也就是說,這一項對於大多數前端同學來說,是必選項,難度可以給一顆星。

第二,實戰應用技巧是對一個專業領域開發模式的總結,有一些不同於其他領域的技巧、架構和思維。學習開發模式可以從學習該領域的一個框架開始,就像你在學習一個 MVVM 框架(React、Vue、Angular)一樣。業界這樣的框架或引擎有很多,比如大名鼎鼎的 Unity,以及 Web Game 中有著廣泛好評的 PhaserEgretLaya,以及阿里已開源的 Hilo 和孵化中的 EVA 。所以在這一項上,對於前端同學來說,可以找準一款框架進行學習或深入研究,難度可以給一星半。

第三,數學/物理學是所有科學的基礎^-^。互動中的基礎科學,同樣包括了代數、幾何、力學、聲學、光學等等。這些知識在高中、大學的教學課本里基本都會涉及到。掌握基本知識後可以大致理解各種模型設計,深入研究後可以挖掘更加富有創意的模型。在這一項上,可能大家在畢業後會漸漸丟棄,重拾還是有點難度的,可以給二顆星。

第四,圖形學是渲染的底層技術,AI是某類玩法的核心要素。這些知識只有當你準備去從事這方面的項目開發時,才會專門用到,又或者最初只需瞭解一二即可。當然,它對於前端技術棧的同學來說,完全是一個從未涉足過的新領域,難度可以給到三顆星。

重構學習之路

經過分類歸納後,就可以梳理需要學習知識以及方式方法。

首先,如果覺得自己基本功還不行,就惡補它,做到能熟練掌握編程語言、數據結構、算法、容器特性,以及設計模式、敏捷開發等軟件工程的基礎理論,當然也不能紙上談兵,得實際應用在日常開發中。然後,適時掌握一個或兩個你覺得最優秀的框架,在實際項目中使用它,並吃透它。這樣下來,你就是一名合格的互動業務前端開發者了。

假如編寫邏輯並不能滿足你悸動的心,那麼我們就繼續:回去翻翻高中大學課本,看看已經放下了許久的知識,當你能熟練掌握了大學課本之後,通過這些知識,就能幫助你去理解和認知技術名詞和代碼實現。然後再苦心鑽研GPU工作原理、圖形語言的精妙之處,或許你就能創作一些有趣的特效出來。

再然後,如果你的需求方希望你研發一款在線實時多人對戰的玩法,那麼你就硬著頭皮去看下AI機器人的專題,那麼就可以寫出一些看起來並不那麼笨的AI機器人出現在真實玩家中間。

最後,理想是當一名架構師的話,那請把上面的這些階段和知識都精通吧。

明確角色和職責

學習目標和結果產出,也和你想要擔任的角色和職責是相關聯。

假如你非常熱衷於投入到業務的研發中,那麼作為一名開發者,你的職責就是提供可持續迭代、低代碼研發的解決方案。

假如你對美有特殊的見解,希望創作神奇夢幻般的效果,那麼作為一名技術美術,你的職責就是提供輔助創作的藝術工具以及許多精美的預設素材。

假如你總是操著一份想要制定標準的心,那麼作為一名架構師,你的職責就是提供完備穩定的頂層設計和架構方案。

解剖互動技術:深入互動去理解架構,不要放過任何細節。

前文中有提到淘系團隊正在孵化的 EVA,名字聽上去挺耳熟,不過這個不重要,重要的是我會借 EVA 的架構為大家剖析下互動的部分技術方案,以便大家對互動應該做什麼技術有所認知。

從體系到架構

淘系業務很複雜,整個前端體系也非常龐大,但好在有統一的業務平臺去支撐產品運營側的需求,以及有淘系大生態來保證工程、構建、容器、Web框架等。有了這些強大的靠背,對於互動技術來說,更多的關心互動域自身的研發平臺和核心基礎。先看這張大圖:

屏幕快照 2020-04-03 下午2.35.07.png

挑其中兩個來分析下它們的架構設計、分別是:EVA JS,EVA Store。

EVA JS 設計模式

EVA JS 也就是互動框架,為了承載互動業務的輕量化引擎,基本採用了業界成熟的架構實現,擁有 ECS、Loader、場景等基礎能力,依賴 Hilo 渲染,並提供豐富的擴展插件。核心部分的系統分層大體是這樣的:

屏幕快照 2020-04-03 下午2.35.33.png

其中,ECS 是 EVA Core 中的核心,全名 Entity Component System,是一種設計模式,也是參考了遊戲領域的架構設計,和我們常見的 OOP+MVC 有著比較大的差異。

舉個生動的例子,在程序裡創建一個爬山者,賦予它體力的屬性和行走的能力,並且行走會消耗體力。在面向對象的設計模式下,編程方式就是通過對繼承和實現接口來完成的。

屏幕快照 2020-04-03 下午2.35.48.png

從子類到基類,需要逐步抽象具體行為。那麼問題來了,因為繼承關係是一顆樹,當遇到某個具體對象(葉子節點)無法繼承某個基類(父節點)時,那麼就必須再創造一個基類(另一個父節點),並且尋找可以掛載的祖父節點。例如,我們通過對爬山者的抽象,創造了一個人的基類。人的基類繼承自渲染對象的基類下,此時如果要再實現一個爬山猴,那麼就又要創造一個動物的基類,同樣繼承自渲染對象的基類。

屏幕快照 2020-04-03 下午2.36.04.png

但它們兩者的很多行為都是一樣的,比如體力屬性、行走能力。這些行為雖然可以用接口的方式實現,但不免就顯得很繁瑣。因為,每設計一個類(增加了一個節點),就增加了維護一棵樹的成本(它總是會被繼承的)。那麼ECS又是怎麼做的呢?

屏幕快照 2020-04-03 下午2.36.20.png

在最初,爬山者就是一個空對象。當給這個空對象添加了一個渲染組件,並且提供了一張人的圖片時,它就變成了一個人。接著添加一個行走組件,就變成了一個可以行走的人。最後添加一個體力組件,就變成了一個有體力的可行走的人。接下來,系統就開始登場了,當重力系統介入的時候,這個人開始消耗體力了;當動畫系統介入時,行走的人動起來了;當渲染系統介入時,當前行走的狀態就顯示在了屏幕上。這些系統在一個循環裡不斷運行,每一幀都在改變這些組件的數據和狀態。

那麼如何實現爬山猴呢?僅僅只需要再新建一個空對象,添加這些組件,並賦予不同的參數值就可以了。

這個時候應該不難察覺,在一個場景裡實體是非常多的,比起維護繼承樹,維護能力組件的成本要低的多。這裡並不是在比較這兩種設計模式的優劣,而是詮釋在特定的場景下需要用合適的設計。ECS 不光擺脫了繼承樹的負擔,它還減少了數據通信的成本。

因 Game Loop 的存在,改變數據後每一幀讀取到的都是最新的數據,所以並不需要用單向綁定或事件機制來觸發的數據對視圖的刷新。因此也就不需要 MVC 當中的 Controller,整個 ECS 可看成一個自運作自更新的 View,只是數據存放在了 Component 裡,改變數據的Action存放在了 System 裡。

EVA Store設計模式

在互動中需要大量的素材,例如雪碧圖(Sprite)、雪碧圖動畫(SpriteAnimation)、骨骼動畫(SkeletalAnimation)等。

它們自然是交給引擎來讀取並展示的。但從原始資源到可被引擎讀取的素材之間,實際會需要一些預處理,比如對資源的檢測、對圖片的壓縮、對數據的優化等。一些引擎會附帶一些工具來對原始資源進行預處理。EVA Store 一方面成為這類資源輸入和素材輸出的集散地,另一方面集合多種素材預處理工具,可以給視覺和開發同學帶來許多便捷。

EVA Store 接收到的是一些原始資源,比如設計師給你切好的圖片、從專業軟件導出的動畫文件(一般包含圖片和JSON),或者是一份 Shader 代碼。

屏幕快照 2020-04-03 下午2.36.41.png

進入 EVA Store 時,首先需要把這些資源落庫方便進行管理,通常會基於一套 SaaS 服務來管理和檢索它們。

屏幕快照 2020-04-03 下午2.37.04.png

落庫後,這些資源會被交由預處理工具來進行針對性的處理,比如可以將圖片合成雪碧圖、可以檢測龍骨的正確性、以及最後對圖片和數據的壓縮優化等。這些預處理,既可以是自動化的,也可以通過一些編輯器來可視化的進行。

屏幕快照 2020-04-03 下午2.37.27.png

最後輸出的就是符合引擎和工作站要求的素材。

屏幕快照 2020-04-03 下午2.37.42.png

圖中可以清楚的看到從原始資源到標準素材的流進路線,其中核心部分就是eva-assets 。它是一個 JS SDK ,集中了 SaaS 服務調用、資源預處理,文件系統和網絡的適配器,使其既能在 Web 環境運行,也能在 Node 環境運行。

EVA Store 基於這個 SDK 完成素材中心網站的功能接入。它也可以被 Editor 或 EVA Workstation 使用來管理和處理這些素材。

如果這些架構的剖析看的還不過癮,可以關注後續淘系互動出品的更多技術分享和文章。

洞察時代演變:無論是堅持業務開發的同學,還是專精於架構研究的同學,都需要會創造價值。

所有業務都不是一朝變成現在的形態的,淘系互動業務近三年也經歷了一些變化,我把它們簡單劃分成三個時代。

動畫時代

在這個時代,產品希望在原本枯燥的界面上,用動畫來豐富需要表達的事物。例如,大促開始時的一段揭幕動畫或是引導點擊按鈕的一段引流動畫。這個時代的動畫,基本不需要太多交互,展示給用戶動畫播完就結束了。

frameLabelStart-https://ucc-vod.alicdn.com/sv/15bd0524-1713eda3d75/15bd0524-1713eda3d75.mp4 -frameLabelEnd

針對這樣的產品需求,前端的解決方案會有這麼三種:

屏幕快照 2020-04-03 下午2.39.40.png

實際開發中,在拿到設計師的動畫 Demo 稿或者僅有產品提供的動畫示意稿時,真要把它還原出來可能要花費大量的精力,有時跟 Demo 稿比起來也會差強人意。

所以這個時代,重點要解決生產品質的問題,也就是動畫還原的精細度。這時候,你可能會想到古老的 Flash,這個在90年代特別風靡的動畫製作軟件,設計師製作完動畫後,工程師們可以通過 ActionScript 來執行一些業務邏輯,並輕鬆的運行在 Web 環境下。

的確,Flash 的製作和開發工作流是非常“先進”的,它讓設計師和工程師們能做自己最擅長的事情,且互相配合的非常默契。那麼在當下,是否還有這樣的工作流可以讓它們各司其職呢?答案當然是有的。

屏幕快照 2020-04-03 下午2.40.06.png

在上圖中,設計師的生產工具變得更加專業和強大,比如 After Effect、DragonBone,這讓設計師們擁有了廣闊的創作空間。這些生產工具可以保存為源文件或者導出視頻、幀序列、GIF 等。

但源文件不能在 Web 上運行,視頻、幀序列、GIF 也不是我們想要的。這就需要一個把源文件轉成對 Web 友好的動畫格式(圖片資源+JSON 數據),這一步很多生產工具也會內置進去。

但在一些複雜的動畫場景裡,需要多段動畫或多種動畫,這個時候就需要有一個場景編輯器來組合這些動畫。比如 Unity 編輯器就可以是這樣的一個場景編輯器,它可以把多種動畫拼接在一起,變成一個完整的動畫場景。之後,把重組的資源和數據再導出給 Web。

在 Web 上,就需要一套能解析這個動畫格式的引擎,它可以被叫做動畫引擎。這個動畫引擎在運行時解析數據、分析數據,並逐幀繪製到畫布上,完成動畫內容的播放。迄今為止,這樣的動畫引擎也是非常多的,而絕大多數引擎也會提供支持播放這些動畫的插件,EVA JS 同樣可以支持雪碧圖動畫、骨骼動畫、Lottie 動畫等常見的動畫格式。

藉助這樣的工作流和工作模式,能99%的還原動畫精細度,且因為過程中並不需要開發者來還原動畫展現,整體的效率也能得到極大的提升。

大家如果對動畫的製作和原理感興趣,也可以順道去閱讀我早幾年在大會上分享的兩個話題:
《暢想動畫製作的樂趣》《漸進式動畫解決方案》

互動時代

來到了互動時代,這個時候產品已經不滿足單純的動畫展示給用戶,而是期望和用戶產生更多的交互。在動畫時代沉澱下來的工作流和引擎,基本能滿足這類需求。然後核心問題是,在不同的大促、不同的活動中,產品希望能複用這些作品,加以變化並且能快速上線,設計和開發也因為花了較大精力去完成某個作品,希望能讓它發揮更多的價值。所以這個時代,重點要解決生產關係的問題。

屏幕快照 2020-04-03 下午2.40.49.png

解決這樣的問題,最佳實踐通常是利用模塊化搭建的方式。把最初的項目沉澱為一個模塊,這個模塊封裝了主體邏輯,並提供了可運營化的服務功能。

屏幕快照 2020-04-03 下午2.41.02.png

在沉澱這個模塊的時候,一定要和產品以及設計充分溝通,把整個作品以產品化的方式進行重新梳理,並且預想可複用的場景,增加模塊的靈活性。之後需要有個業務平臺面向這類需求以搭建的方式選擇這些模塊並配置相關的數據。

屏幕快照 2020-04-03 下午2.42.05.png

模塊和業務平臺的關係是一對多的,也就是交付給業務平臺的模塊,是統一標準、統一體系的,不同業務特性可以架設不同的平臺,走不同的投放邏輯和運營策略,這些是業務特有的,並不附屬於模塊本身。

搭建的頁面中,除了互動類的模塊還可以添加其他商品類的模塊等等。這樣帶來的好處是,作為開發和設計同學只需面向模塊開發、交付符合標準的模塊即可,並不需要面向某個業務項目進行開發。

屏幕快照 2020-04-03 下午2.42.18.png

有了這樣一層關係後,以往優秀的互動產品就可以通過模塊的方式,賦能給更多的業務,從而發揮更大的價值。

業務複用的視頻:frameLabelStart-https://ucc-vod.alicdn.com/sv/3cef2890-1713eda581e/3cef2890-1713eda581e.mp4 -frameLabelEnd

娛樂化時代

到了現今,已經全面進入了娛樂化的時代。在這個時代,商業和互動結合的非常緊密。淘系在2年前漸漸孵化並生長出多個千萬級別的娛樂化互動產品,包括金幣莊園、天貓農場、淘寶人生等。這些產品不約而同的用娛樂化互動的手段,同自運營積分體系、全網商家、特色賣家等相互合作聯通,實現互動流量變現的高價值。在這些產品的孕育和發展中,比起以往僅存在於大促活動的互動項目,有著維護成本上的差異。所以在這個時代,重點要解決生產迭代的問題。

屏幕快照 2020-04-03 下午2.42.33.png

但這裡說的迭代,並不是想說把項目怎麼維護好,單測搞起來,做敏捷開發之類的事情。因為迭代的意義是能給讓業務不斷的往前推進,而不單只是讓代碼不出問題。所以,在分析整個業務推進的過程中,有幾個方面是需要去關注的。

屏幕快照 2020-04-03 下午2.42.58.png

第一,產品要和業務的區分開,產品是承載功能,而業務是把功能在某個時間段以某種外化的形式表達給用戶。比如,彈窗組件是一個產品,而金幣莊園升級的提示彈窗就是個業務。所以通常這類產品組件,也可以叫做業務組件,它高度抽象業務中的某些行為,並長期沉澱提供給業務日常運營使用。這種業務組件其實和互動時代的模塊很像,也是同一種產品化的思路,只不過顆粒度可能更小一點。在項目長期的運作中,我們都要面向某種產品能力進行迭代,而不要陷入單次的業務邏輯中。

第二,在有了業務組件後,業務邏輯就可以架在業務組件之上,專注於短週期內的迭代。這部分業務邏輯還可以用編排的方式來提高效率。關於邏輯編排的技術和方案,淘系互動團隊會在之後的文章中為大家分享。

第三,業務不斷向前發展,背後的數據也在不斷的產生變化來適應業務的需求。數據變化的週期相對來說是要長一點的,而一旦發生變化,就會牽連到業務組件以及業務邏輯。我們通常希望,服務端在返回數據時,儘量不要去動原來的數據結構,只增加類型或可枚舉的值,事實當然不可能經常如願以償。因此也需要適時的抽象產品能力,讓一個基礎的系統來提供穩定數據形態。在互動中,比如有任務系統、養成系統、集換系統等等。這些基礎系統的數據在一定週期內是穩定的,並且可以滿足不同的業務需求,完成不同的項目。

當需要面向多個獨立迭代的事物時,前端在代碼上的分層架構也要能適時的去配合這些迭代,並減少相互間的耦合。大家可能已經想到了MVP(或MVC)架構。

屏幕快照 2020-04-03 下午2.43.14.png

上面的圖基本很清楚了,不再贅述,只不過在娛樂化互動裡,有專門的一個Game View 來展示互動場景,同時會有一個 UI View 來展示交互界面。至於為什麼要把互動場景和交互界面區分開,主要是因為互動場景是逐幀刷新的,而交互界面不需要這麼高頻的刷新,分離後能使用各自合適的設計模式來處理。比如互動場景就可以用 ECS,而交互界面可以用 PureComponent。

人人可開發、處處有互動

到文末了,不免想打個小廣告,淘系技術部前端互動團隊的使命是“人人可開發、處處有互動”。基於這樣的目標,我們會提供統一的互動產品和研發平臺來支撐互動業務的研發。同時整個淘系技術部前端團隊,以技術驅動商業發展,不設界限的在前端相關領域深入突破,如互動、搭建、AI、Node、Serverless、中後臺、雲研發、終端技術等領域,以技術探索未來。

如果你也想一起定義未來,就快點加入我們一起改變世界吧!簡歷投遞到郵箱:[email protected]

Leave a Reply

Your email address will not be published. Required fields are marked *