舒文:浅谈阿里前端的多样化

巴拉米 等级 1005 0 0

2007年,Jeff Atwood 提出了一个著名的观点, 戏谑又似认真地称其为 Atwood's Law(https://blog.codinghorror.com/the-principle-of-least-power/)any application that can be written in JavaScript, will eventually be written in JavaScript.

时间快速穿行13年到今天,仿佛在印证戏言成真:在互联网软件工业的疆域上,以ECMAScript 为圆点朝各个方向射出一箭,凡目力所及的范围内,皆似洒落上了这一箭之威。

而在阿里,也像在诠释着这些上述断言,前端技术如初生牛犊般从蛮荒时代的PC Web 踏入到多个领域,在许多重要战场中发挥着重要作用。

在这儿,借着 D2 大会的契机,简单分享几个前端领域在阿里的应用场景,附带一些我对前端技术领域的一些思考,期待能够和众多的行业同仁们有交流互动的机会。

从 Web 互动到媒体互动

在早期,Web上的互动是为提升页面氛围作为附庸而存在的,为此有一个专用词“网页特效”作为代称。

曾经很长一段时间,互联网上存在大量的特效代码库、特效网站专门服务于开发者。而这些特效的基础原理就是通过 Javascript来变换样式和操作DOM实现的。

随着标准组织和浏览器厂商的不断努力,现代化互动的基础开始成型。除了硬件性能提升外,HTML5/CSS3,Canvas、WebGL让互动的开发显得更为标准、更高效可行,而非各种原理古怪、性能堪忧的Hack技巧。这也让在Web上实现大型互动成为可能性 - 可是要知道,曾几何时,Flash几乎是“双十一狂欢城” 唯一的选择。

今天,互动产品及对应的互动前端技术早已成为各大互联网公司的标配:

  1. 在技术上,继承了Web的优势,能够调整迭代,无需发版,天生跨端的同时还能兼具不错的性能。

  2. 在商业形态上,更游戏化的互动包括不限于“蚂蚁森林”、“淘宝人生”、“天猫农场”等类社交游戏产品使“人与人”、“人与平台”之间的互动具备了更好的可玩性、用户黏性,从而具备了更高的商业价值。

2020年,互动技术也成为阿里经济体前端技术的重点发力方向。
以淘系互动技术为例,它构建在一个大型、完备的前端基座上:一体化的工程、构建、容器、框架、发布系统、渲染引擎。
互动前端技术的核心简单地大概分为三部份:

  1. (互动)框架:基于游戏领域的通用构架,自底到顶的分层实现-Render/Render OBJ/Design Pattern/Utils,具备加载器、ECS、场景、插件化扩展等基础能力。

  2. (互动)素材中心:接收并处理互动展示层所需要的资源并输出成型的互动素材,并通过SaaS化服务进行管理。

  3. (互动)研发平台:面向互动生产者的工作平台,它具备包括不限于编码、拼装、编排在内的构建能力。

基于这套互动技术体系,冷冰冰的商业化产品开始具备了越来越多的趣味性和创意体验。

当互联网基础设施不断完善,硬件与带宽成本持续降低,直播/短视频逐渐形成获取用户时间的主流产品形态,也成为人&人、人&机互动的新场景。

传统的解决方案是在视频媒体上“遮盖”一层Web页面,内嵌在页面中的互动(如领取红包)和视频内容没有事实上的关联,而是通过预置的逻辑进行触发,“伪装”成视频与互动同步的用户体感。这种方式成本低廉,但代价则是牺牲了创意和灵活性,缺少想像空间,没有未来。

而媒体智能互动则是更合理的解决方案:通过智能化手段进行手势、表情等识别,互动素材与效果均与视频内容强关联,并在视频流上完成素材渲染。

  • 从实时渲染角度来看,核心技术环节在:图像采集、数据处理、算法识别、渲染计算、端渲染展示

  • 从研发生产角度来看,关键流程在:玩法生产、应用管理、玩法使用、端渲染展示

上述每个节点都涉及到各个关联技术及工具/产品,正是这些能力组成了媒体智能的技术体系。

从长远来看,无论在互动的自身形态、输入方式、承载媒介还是玩法创意,都必将有长足地发展,对于前端体系的从业人员,只要持续关注用户&终端、熟悉业务、不断学习必定会获得长足的技术竞争力和创造力!

搭建,不止于提效

过去几年,我在负责面向消费者端的搭建体系:把形形色色、千奇百怪的页面都看作组件们的集合,然后用极致简单的搭积木方式将它进行可视化组装。

如果拿冰山举例,我们尽量让用户们(运营、开发者)只看到露出海面的那一段,把概念和实操尽一切可能地简化,而被屏蔽在冰山下面的东西,包括了一系列的交付

  1. 高度被抽象的 界面+数据描述标准 ,我们称之为模块

  2. 兼顾性能和灵活性的 客户端+服务端渲染架构

  3. 离线的、简洁的 零代码可视化平台

  4. 提供线上服务的 页面渲染引擎 + 数据网关;

有了这些交付物(以及基于它构建的大型生态),前端、设计师、后端(多数时候甚至不需要)围绕着高度可被复用的产品模块即可进行页面组装,将业务发布上线。这个方案简单又高效。以至于在很长时间,这套构架最终产生成了数以百万计的各种页面,其中包括不限于双十一,我们在阿里系各种App看到的很多页面都是基于这样的方案出来的。

然而这并不是终点。

其实道理也很简单:当效率上达到一定临界点后(通常是边际效应开始递减),对应的技术方案都越界碰触到另一个领域。

搭建技术也一样 - 一个业务的运行通常不是搭建一个页面就完成了 - 它涉及到整个业务的执行周期。好比一个线下商场要做一场年货活动,上架商品 这个任务只是工作中的一部份,其他包括不限于选商家、选货品、制造氛围、顾客动线都是必须得完成的工作。

而线上业务的运行亦如此,除了“搭建页面” 这个看似简单的动作外,还有各种上下游环节,包括不限于 - 数据哪来(选品)、以什么规则展示(算法千人千面)、抵达什么用户(人群规则)、界面是怎样的(新式交互)、在哪儿展示(跨端渲染)、浏览体验是否又快又好(性能&质量)、业务效果如何(数据看板)等等,每个环节都或多或少地关联着前端相关技术。

基于此,我们根据业务的实际需要拓展了系统的功能边界。慢慢地,原本的面向效率、被高度抽象化的工具系统成为了一个解决具象业务的产品。

在这个转变过程中,原本核心工作是完成前台页面的前端程序员,逐渐成为了一个面向业务的技术工程师,而其工作职责从原来的高效交付扩大到了方方面面,技术视野、技术能力都得到了很大的提升。这时,我们也很难单纯用技术栈来界定这位程序员是前端抑或是后端工程师。

相信在未来,这样的前端工程师会越来越多,也会成为前端发展的一个方向。
技术栈从来不是技术人的桎梏!

Serverless,孕育新的生产关系

还是得谈谈这个话题,如果说越发完善的研发工程体系在提升交付整备质量、周全的性能故障监控系统在改进交付效果,那么 Serverless 就是在尝试着在最合适的环节来优化生产关系。

想必很多初入 CRUD 阶段的前端同学都尝试写过一个形如 Todo、blog-like等应用,基于广受各类教程推荐的 Express/Koa+MongoDB+ReactJS/VueJS 套件方案实现。

然而写完应用后的踌躇满志在遇到技术面试/业务应用时则一片茫然:怎么和预想的不一样? - 性能调试、高可用、容量规划、多应用调用、数据库优化、跨栈中间件等等都是未曾太多考虑的问题,但若稍加深入思考,无需很久就进入新一阶段的灵魂拷问:为什么我要使用Node而不是其他工业化程度更高的语言技术栈?

而云原生下的Serverless 让多数前端们开始解除束缚:

  1. 便捷可弹的BaaS服务

  2. 弱/低运维成本

  3. 现代化的函数计算

  4. 高速交付

无用赘谈太多的优势,只需缓解运维成本、稳定可弹的计算资源,在完备地BaaS下,离终端用户足够近的前端们就能快速的进行多栈开发,而这则很大机会带来的生产关系的变革,重新定义前后端的边界 - 把原来以 BFF 层为界碑的研发模式重新刷新一遍。

在这个基础上,一部份的前端职能会发生深刻的变化,他们为成为离业务更近的产品工程师,既可以实施商业小程序/轻应用,也能主导一场营销大促、也能驱动一个新业务场景的诞生。

当然,围绕着这种生产关系的周边生态,如职业定义、招聘要求、未来前景、企业人才规划都会随之发生变化。

也期待着这一天的到来。

关于 D2 多样化专场

其实在阿里以至行业,有更多的垂直深入的前端技术场景,包括不限于智能研发、文档协同、行为分析、跨端IoT、中后台研发、数据可视化、跨端研发等技术领域,限于篇幅不在此赘述,其中一部分领域性内容也会在 D2 大会上进行输出。

D2 组委会成员们花了相当多的时间和精力组织预选、试讲和遴选,从超过40个话题里面选取了少数具有代表性、技术性的内容,而它们都来自各领域的技术专家们基于实际的业务场景进行抽象淬炼,内容质量和信息密度都经得起推敲,也感谢这些热爱技术、愿意分享的嘉宾们。

写到最后

在最后,今年的D2设立了“多样化”专题,当然不是为了证明前端无所不至这种狭隘观点。

其实,除了很多人记得的 Atwood 的妙语外, Reg Braithwaite 也有箴言:
The strength of JavaScript is that you can do anything. The weakness is that you will.

软件语言史上至今没有、相信未来也不会有银弹。
任何一项技术的诞生都源于解决某类逻辑事务,而随着问题逐渐被缓解,带着技术信仰的领域头羊们总会试图在衍生场景中复用技术优势,撞破边界牢笼 - 尽管大多最终颓然而止 - 这是不幸的,但确实是幸福的:不幸的是他们没有成功,幸运的也正是他们失败了。

在前端领域,包括不限于标准规范、应用框架、解决方案每隔一个阶段就会被更新,我们不需要抱怨要学习的东西如此之多。因为这一方面预示着这项技术的工业化程度还需要提升,同样地,在问题的背面也意味着行业空间大,具备非凡活力,行业人拥有了不起的创造力和多且大的发展机会。

相信驱动这些活力和创造力的,不是来自空中造楼阁欲望,而是技术人对解决现实世界问题的渴望。

同时也衷心祝愿所有参加D2的前端同行们能够在这个快速变化、发展的技术领域中找到最适合的赛道成就自我!

本文转自 https://fed.taobao.org/blog/taofed/do71ct/krg5m9/?spm=taofed.blogs.blog-list.3.1a8c5ac890ImpQ,如有侵权,请联系删除。

收藏
评论区

相关推荐

舒文:浅谈阿里前端的多样化
2007年,Jeff Atwood 提出了一个著名的观点, 戏谑又似认真地称其为 Atwood's Law(https://blog.codinghorror.com/theprincipleofleastpower/): _any application that can be written in JavaScript, will event
Android系统启动流程(四)Launcher启动过程与系统启动流程
Android框架层 Android系统启动categories: Android框架层本文首发于微信公众号「刘望舒」 前言此前的文章我们学习了init进程、Zygote进程和SyetemServer进程的启动过程,这一篇文章我们就来学习Android系统启动流程的最后一步:Launcher的启动流程,并结合本系列的前三
Android Binder原理(二)ServiceManager中的Binder机制
Binder原理 Android框架层本文首发于微信公众号「刘望舒」<more 前言在上一篇文章中,我们了解了学习Binder前必须要了解的知识点,其中有一点就是Binder机制的三个部分:Java Binder、Native Binder、Kernel Binder,其中Java Binder和Native
Android深入理解JNI(二)类型转换、方法签名和JNIEnv
Android框架层 Android深入理解JNI Android框架层本文首发于微信公众号「刘望舒」 前言上一篇文章介绍了JNI的基本原理和注册,这一篇接着带领大家来学习JNI的数据类型转换、方法签名和JNIEnv。<!more 1.数据类型的转换首先给出上一篇文章中androidmediaMediaRecorder.cpp中的androidmediaMe
Android Binder原理(六)Java Binder的初始化
Binder原理 Android框架层本文首发于微信公众号「刘望舒」<!more 前言在这篇文章中,我根据Android系统的分层,将Binder机制分为了三层:1. Java Binder (对应Framework层的Binder)2. Native Binder(对应Native层的Binder)3. Kernel Binder(对应Kernel层的Bi
Android深入四大组件(一)应用程序启动过程(后篇)
Android框架层 Android深入四大组件categories: Android框架层本文首发于微信公众号「刘望舒」 1.ActivityManageService到ApplicationThread的调用流程AMS的startActivity方法中return了startActivityAsUser方法:<!moreframeworks/base/s
Android深入四大组件(三)Service的绑定过程
Android框架层 Android深入四大组件categories: Android框架层本文首发于微信公众号「刘望舒」 前言我们可以通过调用Context的startService来启动Service,也可以通过Context的bindService来绑定Service,建议阅读此篇文章前请阅读这篇文章,知识点重叠的部分,本篇文章将不再赘述。<!more
Android解析WindowManager(一)WindowManager体系
Android框架层 Android系统服务 WindowManagercategories: Android框架层本文首发于微信公众号「刘望舒」 前言WindowManagerService(WMS)和AMS一样,都是Android开发需要掌握的知识点,同样的,WMS也很复杂,需要多篇文章来进行讲解,为何更好的理解WMS,首先要了解WindowManage
Android解析WindowManager(二)Window的属性
Android框架层 Android系统服务 WindowManagercategories: Android框架层本文首发于微信公众号「刘望舒」 前言在上一篇文章我们学习了WindowManager体系,了解了Window和WindowManager之间的关系,这一篇我们接着来学习Window的属性。<!more 1.概述上一篇文章中我们讲过了Window
Android解析WindowManager(三)Window的添加过程
Android框架层 Android系统服务 WindowManagercategories: Android框架层本文首发于微信公众号「刘望舒」 前言在此前的系列文章中我们学习了WindowManager体系和Window的属性,这一篇我们接着来讲Window的添加过程。建议阅读此篇文章前先阅读本系列的前两篇文章。<!more 1.概述WindowMana
Android解析ActivityManagerService(二)ActivityTask和Activity栈管理
Android框架层 Android系统服务 ActivityManagerService Android框架层本文首发于微信公众号「刘望舒」 前言关于AMS,原计划是只写一篇文章来介绍,但是AMS功能繁多,一篇文章的篇幅远远不够。这一篇我们接着来学习与AMS相关的ActivityTask和Activity栈管理。 1.ActivityStackActivi
Android输入系统(三)InputReader的加工类型和InputDispatcher的分发过程
Android框架层 Android输入系统 Android框架层本文首发于微信公众号「刘望舒」 前言在上一篇文章中,我们学习了输入事件的处理,输入事件会交由InputDispatcher进行分发,那么InputDispatcher是如何进行分发的?这篇文章会给你答案。 1.InputReader的加工类型在这篇文章中,我们知道InputReader会对原始
Android包管理机制(二)PackageInstaller安装APK
Android框架层 Android包管理机制 Android框架层本文首发于微信公众号「刘望舒」 前言在本系列上一篇文章中我们学习了PackageInstaller是如何初始化的,这一篇文章我们接着学习PackageInstaller是如何安装APK的。本系列文章的源码基于Android8.0。 1.PackageInstaller中的处理紧接着上一篇的内
java+web+批量下载文件
JavaWeb 文件下载功能 文件下载的实质就是文件拷贝,将文件从服务器端拷贝到浏览器端,所以文件下载需要IO技术将服务器端的文件读取到,然后写到response缓冲区中,然后再下载到个人客户端。 1\. 文件名 - 接受前端发来的文件名 获取到前端页面发送过来的要下载的文件的名字 String filenameValue = req.getP
Vert.x Web 文档手册
Vert.x Web ========== 中英对照表 ----- * Container:容器 * Micro-service:微服务 * Bridge:桥接 * Router:路由器 * Route:路由 * Sub-Route: 子路由 * Handler:处理器,某些特定的地方未翻译 * Blocking:阻塞式