最近一直在招聘数据工程师，我们自己的数据平台也有了些眉目，可以写写这个主题了。另外，以前写过一个系列叫做「后端是长久的职位么上和中」，很多朋友一直问，下呢？今天这篇文章是「下(1)」。
国内公司一般把处理和分析数据的工程师职位叫做数据工程师，或大数据工程师，虽然这个称谓像「数据科学家」一样语焉不详，甚至同样会被过度解读，但总是比科学家低调一点，安全一些。无论是数据科学家还是数据工程师，都是需要和数据打交道的人。他们是一群能够处理和分析海量数据的汉子，或女汉子，每天从手里流过上亿条的数据是稀松平常的事情。
那么，数据工程师是个有前途的职业么？我觉得是，不过这个职业与前端工程师或移动工程师相比，人数的需求可能没有那么多，但要求更高一些，不仅是技术上的要求，而且要对产品和数据敏感，同时具备很好的协调性，因为数据工程师可能要与产品经理、决策者、商务等各种角色打交道。
为什么数据工程师在这个时代会变得炙手可热呢？在移动互联网和云计算的时代，数据正在以几何级数增加，我们每个人每天都在产生大量的数据。当你开车上班的时候，会产生导航和交通数据，我们生病看医生的时候，会产生医疗数据，我们购物的时候，处理邮件的时候，编写文档的时候，查看股价的时候，拿着手机在路上打皮卡丘的时候……都在产生各种数据。未来是一个数据构筑的世界，数据也会改变未来。无论是实业创业还是移动互联网创业，这个趋势将不可逆转。
最近一直在看一些大数据相关的资料，结合我们自己构建数据平台的一些实践活动，谈一下我的几个想法。
要有数据，而且得大。
没数据都是扯闲篇的
经常遇到一些读者问，想学习大数据相关的技术，怎么入手？或者想在公司引入 Hadoop、Spark、Presto 等一系列技术框架，怎么出手？我就问，你们数据是什么量级呢？答，几百万吧！几百万条记录您用得上这些技术吗？如果你真的想从事数据相关的工作，最好到一家「有数据」的公司，没有真实数据，你永远不会遇到真实环境和数据给你带来的挑战，甚至，你根本想象不到会有哪些挑战，技术就会变成无水之源。知和行隔着万丈鸿沟，看别人纵马狂奔总是容易的，你得自己骑上去试试。
什么是大数据？这个大是相对的，我们人为的去给大数据设定一个阈值，比如1PB，毫无意义，只有当前的数据规模大到对你现有的软硬件技术构成挑战时，才能称作大数据。比如公司内产生的数据已经无法通过关系数据库处理了，得想别的辙，可以算「大」。而且，大数据和时代息息相关，八十年代的大数据和今天的大数据是不可比拟的（为什么八十年代也有大数据呢？因为数据科学已经存在了几十年了呀）。
可以说，「大数据是一种文化现象，它描述了数据在人类生活中所占的比重，随着科技的发展，数据所占的比重会越来越大」。如何描述大数据的特征呢？有个 4V 原则，分别指容量（Volume）、种类（Variety）、速度（Velocity）和价值（Value），你的公司有没有大数据，大数据的形式和能对公司产生的价值，都可以从这些方面来描述。
无论如何，你得有数据。
进行数据分析是一件困难的事
以前有读者发来邮件和我说，后端有什么挑战呢，几乎所有的技术都有现成框架了啊！首先，这些框架也是工程师设计和研发出来的，我以前说过，「顶级工程师做工具和平台」，想要找挑战，你可以开发出更好的工具啊。其次，即使有了这些工具，我们去处理数据的时候，依然会困难重重。
如果你想成为一个优秀的数据工程师，你需要统计学和线性代数的相关知识，你必须有熟练的编程技巧和数据抽象的能力，还能做数据的可视化。完成了数据平台的构建，还有机器学习等着，还有人工智能等着，还有不可知的未来等着，有时候我一想到这些，就会产生特别绝望的想法：人类终究还是要输给数据吧。
即使是最基础的数据处理链路，比如数据清洗、存储、分析和计算，也会碰到各种问题。我们最早一版的处理应用商店和游戏中心等 App 数据的时候，链路是这样的：数据上报，通过 hash 名称存成 gz 文件，然后用 Python 进行数据清洗，存入 Hadoop 集群的 HDFS，再进行离线计算，通过 Spark SQL 把部分数据存入 MySQL，并提供 HTTP API，给前端做展示。
优化后的策略是：对埋点数据格式进行重新整理和规划，引入 Presto，通过 ETL 程序把 HDFS 文件数据导入 Hive，并做 ORC 压缩处理，形成二进制格式（速度快，节省空间70%），并进行分区。然后通过 Presto jdbc 定时调度任务，将 Hive 数据做统计聚合至 MySQL。优化后的离线分析速度和灵活性都大大增加了。
推荐一下 Presto，这是一个非常优秀的分布式 SQL 查询引擎，可以实现全内存并行计算，动态编译执行计划，进行本地化计算。既适用交互式分析查询，也可以通过 API 实现数据聚合，数据量可以支持 GB 到 PB，非常惊人。
离线分析有了点眉目，还需要实时分析。有人说简单啊，Flume 进行数据采集，Kafka 做数据队列，Storm 作为 MQ 的消费者，对采集到的数据进行实时分析和流式计算，再存 MySQL，就行了。嗯，我就说说……
即使这是一套成熟的技术方案，当你去处理自己的实际业务时，也会遇到各种问题。你需要熟练掌握这些技术和引擎，并熟知你的业务数据，才能抽丝剥茧，层层推进，抵达彼岸。
好了，数据量足够大了，可以做机器学习了……
「嘀嗒嘀嗒」公众号作者朱赟博士曾经为「攻城狮群」写过两篇机器学习入门的文章，有兴趣的可以去围观一下，二爷看了之后都开始沉迷机器学习了。搜索「AngelaTalk」，关注「嘀嗒嘀嗒」后点击中间的自定义菜单，可以找到这两篇文章。对了，朱老师还写过一篇数据科学家的文章，也可以找来对照阅读。
人工智能……算了。
有价值的数据只能提供参考，并不能完全指导工作。
有了数据，有了数据分析结果，是不是就万事大吉了？非也，数据只能做参考，如果只看数据就可能出问题，因为数据会带来误导。
微软研究院的 Kate Crawford 女士曾经提到，如果仅对飓风桑迪到来前后的部分推特采样数据进行分析，可能会得出这样的结论：人们在飓风来临前在购物，飓风过后在聚会。
仔细分析后你会发现，这些推特数据大部分来自纽约州。首先，这些人是推特的重度用户，其次，沿海的新泽西人正在担心他们的房子会不会被飓风吹倒，谁还有心思和时间去发推特呢？换句话说，如果你使用推特数据来分析桑迪飓风的影响，得出的结论可能会是这场飓风危害不大。事实上，真正受到飓风影响的人根本没时间发推。
还有推荐引擎，经常有人在朋友圈抱怨，京东为什么会给我推荐没品位的手机，微博为什么给我推荐不适宜的影片，如果碰巧是个老程序员，还会抱怨这些平台的算法真是烂啊。其实不是这样的。也许你根本就没有评价过人家的商品呢，也许你根本就不是目标用户呢，也许，就是推荐引擎出了问题啊……
总之，数据的相关性不能完全体现因果关系。数据并不会自己说话，它只能够以一种量化的、无力的方式去描述和再现我们身边的社会事件。在现阶段，人还占据绝对主导地位！
一个产品，如果没有数据的反馈和感知，是没有生命力的。一个企业没有数据，估计也很难走的更远。要看数据啊！
今天是 卖桃者说 本月开放周期最后一天，敬请关注。
三表发了一篇「不合时宜」的文章，导致「三表龙门阵」被禁言了一个月。「三表蛇门阵」是他的临时避难所，这个月还想看三表的文章，搜索「sanbiao66」关注。
「即刻」是个很有创意的新形态资讯APP。你关心的五花八门的事情被做成了即刻上一个个的主题，可订阅跟踪相关资讯。我自己也在用，基本能替代微博和新闻软件，还经常发现一些让人欣喜的技术主题，值得一试。
【文/池建强 MacTalk（微信号：sagacity-mac）】
·氧分子网（http://www.yangfenzi.com）延伸阅读：
➤ 互联网历史中昙花一现的职业：闪客、外链发布员、短信写手、威客
➤ 电子科技大学互联网科学中心主任周涛：你也可以成为数据魔法师
我也认识公众号《嘀嗒嘀嗒》的作者朱赟。我又来问一个老问题了，不是专业统计学背景出身的计算机专业程序员，能干好数据分析这个职位吗？PS：最近恶补统计学知识，感觉头大，想求一点安慰即刻有三表的不合时宜的文章吗？
如果说大数据是一种潮流，那么选择数据工程师可以提升时髦值数据分析师是个有前途的职业么？安卓开发者表示看完后，认识了许多没听过的名词池先森推荐点数据结构和算法的书咯不懂业务逻辑谈数据都是耍流氓
池老师，还是比较注重技术。对数据分析的理解还是Angel说得更深刻些有人曾经说过，二十一世纪，最热门的将不再是计算机系，而是统计系仅仅是学常用的机器学习算法，要理解透都费劲了，虽然本科学了数学，研究生读了模式识别，工作几年后发现数学不够用了
先找个驴骑一下看别人纵马狂奔总是容易的，你得自己骑上去试试。不知道你们可视化是怎么做的。最近我遇到很多互联网行业的客户，之前都是养一个团队来专门做报表，结果一方面响应速度跟不上业务部门，一方面成本过高。现在他们都在寻求商业产品来更加敏捷的实现数据分析和可视化。
产品经理、运营人员和工程部门的人员，前者是用数据的人员，而后者是搭平台埋点的人员，如何让他们高效沟通，快速得到公司各部门想要的复合性指标？产品经理、运营人员和工程部门的人员，前者是用数据的人员，而后者是搭平台埋点的人员，如何让他们高效沟通，快速得到公司各部门想要的复合性指标？
二爷莫名躺枪哦哦，那就是开始目标就在于加快出报表的速度啊，spark在报表方面没啥优势，报表业务做好也不太容易，仓库设计上按照业务主题分好层次能减少运算量，也可以加快出报表写一个语言是什么水平？普通人需要走多久这段路？需要具备哪些条件？为了学习到 Presto 这个新词，把零钱都拿来赏了
坑多，不喜欢的人折腾的人勿入。作为一个数据工程，我觉得池老师应该增加一句我就想问问三表不合时宜的文章在哪里还能看到？给微信编外产品经理提个需求：微信聊天记录搜索太难用，不支持按发言者搜索正在数据的道路上挣扎
我看过好多遍的女神写的关于机器学习的文章： 1.是不是该转型搞机器学习呢？（嘀嗒嘀嗒） 2.如何学习一门新技术？（MacTalk） 3.软姐之机器学习第一讲（MacTalk） 4.IT 江湖（一）之 机器学习篇（嘀嗒嘀嗒） [认真脸]
这几天帮忙测试未上线系统，欢乐多。对面的产品经理和数据开发工程师，技术大牛，默默的对奋斗在码字路途上的程序猿致以最崇高的敬意。然而沟通方面特别困难，一个bug要好几个人才能表达清楚。三个数据工程师，墨迹一中午了。一个问题没解决了，都觉得自己对
非理工/设计类专业想要进入互联网行业的要求：1.运营：PS是基本功/一手软文是添头/各大社交网站粉丝以万为单位的大V好了你被录取了 可以来做实习生了（划重点 实习生2.产品：把玩过100+APP是基础/能直观感受到不足并提出改革方案你还有点看头/同类产品竞品分析（数据挖掘流量分析我们只要工程师
作者认为饭桌是促成人们放下猜忌、坦诚相待的极佳场合。这让我想起了一个产品经理朋友给我的关于如何说服工程师的忠告：「能讲数据就讲数据，没有数据就讲逻辑，如果连逻辑都没有，那就请吃饭」。池老师也教育我们说，世界上没有一顿望京小腰解决不了的问题，如果有，那就两顿
唉，又伤心了。怎么会选数据挖掘这个烂大街的方向呢，市场需求都是语音识别，计算机视觉，文字识别，视频分析什么的。以后这几个方向有需求的不要联系我，数据挖掘工程师表示感觉自己被冒犯了
文/续彬&池建强 来源：MacTalk
今天推送一篇前端雄文，读了这篇文章，你会有一种前端已经上了天的感觉，甚至有可能忘记催我写 Python 系列。不过这篇不是我亲手所写，而是我的一位老朋友的团队成员给 MacTalk 写的。我的老朋友叫恩阳，阿里高 P，非常高，他最知名的地方并不是技术好，管理团队牛逼，而是常年以一辆马二在杭州余杭地区纵横驰骋，天下闻名。可惜，最近他换了两辆豪车，一下子变得无趣了很多。
续彬是恩阳的同事，是我的朋友，也是阿里的技术专家，他最近在我的「攻城狮群」做了一次前端技术的分享，我建议他写一篇相关技术的文章，也就是今天的成文 —— 前端里的高级动画技术。
他的简介如下：
邓红春，在阿里的花名是续彬，现在负责天猫互动团队的终端技术，包括了 Web 前端以及 Native 客户端开发。我在08年刚毕业那会做了一段时间的 PHP + Mysql，做得比较杂，之后很长一段时间专注于前端开发。2010年加入了腾讯专业写 Javascript，再到2012年加入天猫一直到现在，这7年的时间内我一直聚焦在用户体验这件事情身上。
以下是正文。
前言
至从有了前端开发这个概念以来，其实这个岗位所做的事情都是围绕着人机交互来开展的，主要包括展示信息给用户看，然后获取用户的意图并做出响应（本文提到的前端主要是指大部分人认为的 Web 前端，其实 iOS 和 Android 的客户端开发本质上讲也是完成类似的工作，但技术栈还是不一样，而且拥有更多的底层能力，所以我用客户端便于区分，后面会提到，所以提前说明一下）。
随着终端设备以及业务的快速发展，前端工程也越来越复杂，所以分工也进一步精细化，有侧重做工具化与模块化架构的，有侧重无线体验或者 Web 与 Native 融合方面的，也有侧重复杂的商家后台或者数据可视化的，甚至有部分公司把 HTML+CSS 与 JS 的工作也分开的，所以出现了不同前端工程师会有不一样的侧重点。
在这种大背景下，提出『不会做动画的前端不是好开发』的论点显然是很难站住脚的，因为动画仅仅是前端技术的一部分，很多人在其他前端领域也做出了很高的成就。但是，作为一个多年从事于互动领域的我来说，写这样标题的文章出来其实是有私心的，因为我们的业务有越来越高的动画类需求，而在动画方面能紧跟技术趋势的优秀前端实在是比较难找，希望通过这么一篇文章，让那些想在动画方面有些提升的朋友有所帮助。
一、为什么前端的动画需求越来越强烈
本文讨论的主题是动画，是属于刚刚所说的展示以及响应，也就是输出的那部分，我认为一个高质量的动画在很多情况下都能大大提升用户的视觉体验，前提是使用得当并把握好度，理由如下：
1、更形象化的表现力。因为人们的现实世界就是动态的，有时候用静态的图片与文字很难把场景描述清楚，比如我们要展示狂欢的节日氛围。所以，天猫双 11 的狂欢城与晚会的页面就用了大量的动画来表现；
2、更自然的过渡效果。一个有趣的 loading 能缓解用户在等待响应过程中的焦虑情绪，就像是在等待上菜时可以看看京剧表演一样。而且，即便是性能 DIAO 炸天的 iPhone7plus，也有很多赏心悦目的界面切换动效。
3、更具互动性。这个不想多解释，试想一下一个一动不动树立在你面前的人和一个扭动身姿而且做出丰富表情的美女哪个更让你想有进一步交互？
所以，只要恰当的用好动画这个技能，能在非常多场景上大大提升用户体验，进而让用户更有参与感。在竞争激烈的互联网行业，好的体验能为业务带来巨大价值。比如，如果用户能在手机上和一件商品进行很好的交互，而不再只是看静态的图文详情，那用户会更乐意去体验它，从而提升购买转化率等等。
随着硬件与底层系统的发展，用户的终端对动画的表现能力越来越强，所以将会有更多的场景大量使用动画，从 2D 到 3D、从虚拟到现实，对前端团队的要求也越来越高，不再是能用 jQuery 的 animate 或者 Css 的 transition 做个 loading 可以了的时代了。
二、实现动画的方法
讲了这么多背景与趋势，下面进入正题，那前端可以使用哪些技术来实现动画呢？
1、对程序员而言最省事的就是视频或者 gif 图片了，而且目前在很多情况下也在广泛使用，优点是对业务方来说没有太多限制，沟通成本低，缺点是在色彩、透明度的表现力上不如 PNG，而且交互性差，不过也可以通过碎片组装的创新方式达到可以互动的效果；
2、又爱又恨的 Flash，具备成熟易用的 IDE 与强大的 ActionScript，简直就是为动画而生，而且兼容 IE。可是依赖插件、耗资源、安全性等问题让它在手机端几乎寸步难行，我想这个技术其实已经没有再考虑的必要了；
3、通过 JS 改变 Dom 节点的 css 属性应该是集开发成本低、兼容性好、具备互动性，加上 PNG 图片很好的色彩与透明度的表现力基本能满足很多动画需求，也是目前大部分前端使用的方法。但是在复杂的大场景中性能较差，并不是特别流畅，而且也解析 3D 模型；
4、Canvas 的到来仿佛是上帝为前端同学提供了神来之笔，而且是众多大厂推崇的官方标准，不需要插件，浏览器内核支持，可以绘制各种图形以及具备高性能的图片渲染能力，而且能比 flash 更好的与页面中其他元素交互等等，但纯手工编写 canvas 程序的成本其实较高（原因可以 google），动画实现起来较为繁琐，但可以通过封装一些方法进行解决；
5、大厂对 WebGL 的支持相当于为前端的那支神来之笔赋予了新的魔法，在 Canvas 的基础之上增加了 OpenGL ES 的 3D 绘制能力，并且能开启硬件 3D 加速渲染，让前端动画的世界充满了更多想象的空间，天猫双 11 狂欢城、年货节以及众多 AR 项目中已经在大规模尝试基于 Web3D 的渲染技术。
三、动画渲染技术的趋势。
可见，随着技术的发展，实现动画的方式有非常多，大家可以根据自己的业务与团队情况选择合适的方式进行开发，但为了给用户带来更极致、更创新的体验，需要我们掌握这些技术以便在需要的时候能马上实施。
具备更强表现力与想象空间的 Canvas+WebGL 显然是未来的大趋势，iOS 与 Android 对 WebGL 的支持越来越完善，目前已经能覆盖 80% 的手机用户了，而且很多 APP 的 WebView 底层做了很多优化，加上硬性的发展，覆盖率会持续升高。
随着 AR/VR 等虚拟技术以及硬件的发展，扁平化设计的小潮流逐步向更具景深感、立体感、动力惯性等物理效果发展，因为这才是更真实的世界，三维动效已经成为了大趋势，3D 模型会成为前端团队很难逃避的内容。
虽然本文主旨就是围绕着 Web 前端开发来讲的，然而客户端开发其实也有些同学也在做动画相关的一些事情，而且拥有更极致的性能与兼容性的表现，但也有开发成本高、无法开放、依赖发版、热更新有局限等问题，所以会更偏向于日常的标准化产品，如手游或者日常 APP 中的一些转场效果。当然，有些 Native 的渲染引擎在通过一系列设计与封装，在跨平台和热部署方面也取得了不错的进展。
由于 Canvas 和 WebGL 属于世界公认的 Web 标准，所以除了在开发成本、跨终端、热部署、开放性等方面拥有绝对优势之外，也具备活跃的生态和大量的储备开发力量，底层 runtime 不断在优化的情况下，将能满足快速的业务发展诉求。
所以，不管是 Native 前端还是 Web 前端，在动画方面都在快速发展，就像在 web 中可以选择多种渲染技术一样，采用 Native 还是 web 也要根据业务与团队情况进行选择。由于我们团队的业务量较大，而且需要为不同的品牌商甚至不一样的商品进行个性化开发，同时需要运行在不同的 APP 和不同类型的设备里面，长远来看，我个人更看好 Web 渲染技术的发展，而我们团队的客户端同学我会更倾向于更多的底层建设与更多的创新。从天猫近一两年的实施来看，我更加坚信这个方向，所以，接下来我会继续回到 Web 层面展开分享。
四、多实践才能出精品
高质量的动画包括几个要素：
需要如丝般顺滑的流畅体验，考核指标是 FPS 性能；
覆盖用户更多的场景，考核指标是设备兼容性；
逼真或者赏心悦目的渲染效果，如 3D 材质、色彩、粒子等；
其实这三者之间存在一定的矛盾，需要根据需求去平衡，做出一些取舍。但其实老板也业务方是不太喜欢取舍的，都能达到那是最好，所以作为技术人我们必须要有追求极致的钻研精神，下面我通过一些案例来分享一下我们是怎么做的。
先看一下效果，如下是 2014 和 2015 年的双 11 狂欢城的页面（gif 太大只给 url 吧）：
https://img.alicdn.com/tfs/TB128wmRpXXXXaxXpXXXXXXXXXX-278-496.gif
https://img.alicdn.com/tfs/TB1dg_RRpXXXXXDapXXXXXXXXXX-278-496.gif
做这个项目的时候，要同时满足业务与性能的要求，还是面临这不少挑战的：
1、图片多：100 多个品牌 logo，还有场景地皮
2、动画多：大量精灵动画，每个至少 3 帧
3、场景大：在手机上共有连续 8 屏的超长页面
所以这个页面将消耗大量内存与 GPU 资源，通过 Dom 实现会非常卡，所以我们选择了 canvas 进行实现，每年都会做一系列优化措施，比如：
1、除了 CDN+ 客户端预加载等常规缓存机制之外，我们在页面的运行时进一步做了 Canvas Cache，使用一个额外的 Canvas 来保存已经绘制过的内容，下一次使用的时候直接从这个 Canvas 上读取，这样就可以大大减少 Canvas 的绘制次数，例如原先首屏绘制次数约为 75 左右，使用 cache 后的次数约为 28，减少了 62.67%。
2、为了减少地皮图片的数量，2015 年的狂欢城我们与设计师沟通后决定尝试一下，使用地皮拼合的方案，重复使用一些图片进行对地皮的组装，由于图片的内存占用是根据图片尺寸转换为 2 的 N 次方，然后计算大小，所以图片尺寸越大占用内存可能导致指数级增长，狂欢城中的图片都是小图 (地图区块都是 256 以下，其他基本上也是 512 以下)，所以内存占用上会小很多。
3、通过 Hybrid 接口获取硬件信息（内存、GPU、屏幕等）判断如果是低端机器，我们采用非高清图片以及 Dom 的渲染方式进行优雅降级。
五、大胆尝试不断突破，3D 与 AR 时代的来临带来新的挑战
再来看看基于 WebGL 的 Web3D 案例，如下是 2016 年狂欢城项目：
https://img.alicdn.com/tfs/TB1KXL4QVXXXXXlaXXXXXXXXXXX-372-604.gif
当时我们希望通过 3D 为用户带来全新的视觉体验，但由于场景还是非常大，如果所有元素全部采用模型的话那面数将面临巨大的性能挑战。承载着众多品牌商的流量入口的业务压力下，我们和设计师经过大量的测试与探讨，最终实现了一个滚筒 + 纸片风的效果。过程中也尝试了用 CSS3 和 cavans 模拟 3D 来实现，但有各种闪烁以及卡顿问题，最终还是基于 WebGL 的 3D 图形进行实现的。说实话，从效果上讲我们并不是非常满意，毕竟做了一些妥协，但从技术上讲，是一次非常大的突破。
2017 年货节我们再一次挑战 Web3D 的极限，用更加有冲击力的体验展现过年的快乐氛围，拉近消费者与品牌之间的距离，我们设计了一个全模型的场景来构建，如下：
这个场景的模型有 30M，通过 WebGL 渲染出来之后就有些卡顿了，我们决定把更多的资源让给互动的主题内容，而不是场景，所以把外围场景转化成了一张全景图：
然而输出的全景图我们不打算放在一个球体上。因为有曲面就会有变形，但是天空部分因为是纯色，所以这部分形变是看不太出来的。可是如果这部分形变作用在建筑上就会非常明显。所以我们把球形换成一个「压扁柿饼形状」
最终我们实现的效果如下（其实摄像机可以做更多变换，有做导演的赶脚了）：
https://img.alicdn.com/tfs/TB15hHYQVXXXXcQaXXXXXXXXXXX-372-620.gif
可见，这时候的动画开发，除了考虑对图片的处理之外，还有模型文件的处理以及摄像机的使用。
说完从 2D 到 3D，再分享一下从虚拟到现实的动画应用，也就是我们所说的 AR（增强现实），如下是天猫 AR 业务里面的两个案例（一个是天猫互动 2015 年初首次尝试，一个是近期我们的合作伙伴使用天猫的接口实现的）:
https://img.alicdn.com/tfs/TB1dh_ZQVXXXXaBXVXXXXXXXXXX-352-395.gif
https://img.alicdn.com/tfs/TB1wmP0RXXXXXb.XFXXXXXXXXXX-374-614.gif
本文先不讨论 AR 的识别与跟踪算法，但对需要与算法对接的动画渲染技巧要求会更高，要与摄像头里面的现实场景混合在一起面临两个主要的新挑战：
1、除了虚拟的那部分动画需要足够的流畅之外，还要随着现实场景的变化而变化，摄像头的方位或者识别物本身可能都在高频晃动，所以虚拟物体怎么与摄像头以及算法进行绝对同步呢？实际上是非常难做到的，而且如果使用 Web 的方式进行渲染，问题会更大，因为摄像头与算法层通常是在客户端，部分算法能力可能在服务端。在摄像头获取图像，到算法计算，再到显示摄像头图像，最后到渲染反馈，任何一个环节都会有时间消耗，需要设计一个巧妙的同步机制才能让整个 AR 体验更加的顺畅，不然就会容易抖动。
2、在 AR 的场景中比在纯虚拟的场景中，对材质与光照的要求更加的强烈，因为如果渲染效果不真实，就算动画与跟踪做得再流畅也会出现格格不入的情况。
由于篇幅有限，更多的技术细节就不进行展开了，看到这里，你应该清楚自己是不是一个会做动画的前端了。
六、需要一套适合你的工具箱
开头有提到，自己完全手工去基于原生接口开发动画的成本还是比较高的，所以需要把通用的能力沉淀下来，为开发者提供更高效的开发体验，这样大家才能更专注于业务本身，避免很多重复劳动。所以，最省心的做法就是选择一个现成的产品进行使用，但前提是需要选择合适的，早期有 Egret、Pixi、unity、Cocos、three.js 等相关的动画引擎的产品，大家可以自己的需求进行选择。当然，如果发现没有非常适合的，可以选择进行扩展或者自己研发，以便满足自己团队的业务需要。
在 2014 年阿里选择了自研一个叫 Hilo 的引擎，其实根本原因是我们没找到一个适合电商业务的，否则可能就用了，就不会有今天的 Hilo，主要原因有：
1、性能要求高。天猫和淘宝大部分互动页面都是运行在 APP 中的 webkit 的 webview 容器中，而且和复杂的业务混合在一起，要求足够小、轻量、高性能；
2、需要易上手、易扩展。电商类业务开发节奏非常快，不能有太高的学习成本，也需要大型游戏的那么多功能，只要有极致的渲染以及物理能力即可，其他的可以根据情况选择性扩展，同时需要与其他业务保持同样的开发语言，而不是 TypeScript 或者其他脚本；
3、兼容性要求高。对于阿里的用户体量来说，10% 的用户就已经是很大一批用户了，所以对 IE 以及低端手机的支持不能完全不考虑；
4、开放性与安全性。
经过多年的实战，Hilo 支持了阿里很多动画相关的业务，比如上面提到的多年双 11 狂欢城，并行成了很多周边工具，天猫互动团队在 2016 年决定对 Hilo 进行开源，希望给有需要的团队多一个选择，其主要特点有：
1、极简内核，2D 部分已经开源（ https://github.com/hiloteam/ ），压缩后只有24KB；
2、采用前端工程师熟悉的 JS 标准语法，支持 ES6，支持 CommonJS/AMD/CMD/Standalone 引用方式；
3、支持 Webgl/canvas/weex/dom/flash 五种渲染模式，能兼容更多的运行环境；
4、充分的 API 与 UI 测试，安全稳定；
5、使用 Yeoman 脚手架，可以快速生成一个动画应用；
6、无缝衔接的丰富工具集（DragonBones 骨骼系统、TiledMap 地图编辑器、ChipmunkJS 物理系统、粒子编辑器、Flash&AE IDE 插件等等）；
所以，Hilo 除了支持大场景的互动页面之外，像如下这些简单的动画都是可以由工具直接导出为 Hilo 动画做成的（可交互可控制的 Canvas 动画，非 GIF）
http://gw.alicdn.com/tps/TB1DksKOXXXXXXaapXXXXXXXXXX-184-326.gif
https://img.alicdn.com/tfs/TB1Vsb8RpXXXXaxaXXXXXXXXXXX-352-449.gif
上文提到了很多 3D 和 AR 项目，也沉淀出了 Hilo3D，目前正在阿里集团内测，感兴趣的朋友可以到 github 提 issue，Hilo3D 的主要特点有：
1、沿用 Hilo2D 的设计风格与开发方式，极简 + 易上手
2、支持 glTF 模型，提供在线格式转化器
3、聚焦在渲染效果、性能、兼容性三方面
是不是有了适合你的工具箱就能放心大胆的走天下了呢？引用我常说的一句话，那就是「巧妇难为无米之炊」，技术再牛，没有原材料也是「英雄无用武之地」。所以还需要关注怎么提升模型素材的生产效率，降低业务落地成本，这部分内容下次有时间再分享。
结语
回到标题那个问题，是不是不会做动画的前端就不是好开发呢？显然太过绝对，如果说是，那肯定会被骂。不过我觉得能精通动画技术并与时俱进的前端开发肯定会很受欢迎，因为你是离用户最近的贴心人。
最后推荐一下 Hilo，以前我就推荐过，现在越来越成熟了。