前言：

运气不佳没有被选中到现场参加第二届 See Conf 蚂蚁金服体验科技大会，全程看的直播，印象最深的分别是上午场楼院长的分享以及下午场悠鹤大佬的分享。

原先只是简单整理一下笔记，在记录过程中，自己有一些想法冒了出来，于是就成了这篇笔记里的 “XX注”。

由于当时在星巴克看的直播，有些内容没有听清楚，加上自己理解偏差所以笔记难免有所疏漏或者错误，自己也在有疑惑的地方标注出来了，欢迎各位大佬指正

演讲人：悠鹤，蚂蚁金服前端技术专家

主办方：蚂蚁金服，第二届 See Conf 蚂蚁金服体验科技大会

笔记制作信息

制作人：XX，爱回收网前端开发，微信：X_XDalston

公众号：清风迅来，摄影/美食/旅行/前端/翻译/阅读/健身……

开场白：关于蚂蚁庄园的偷吃，微博上有位才子写了首小诗：

XX注：一开始没仔细听讲者说的内容，还以为是讲者写的，就想，果然前端都这么文艺有才的啊…

关于蚂蚁庄园的用户故事

1.某某邀请亲戚朋友一起养鸡，某天小鸡跑到父母的家里偷吃，父母说这是孩子的宠物， 把它也当成自己的孩子，就不忍心把来偷吃的小鸡赶走

XX注：想起了上午场的“情感”要素，或许有时候产品设计师也不会想到产品在海量的用户群体下，开放式的交互，结合真实的情感，会自己演化出各种意想不到而又在情理之中的体验

2.一对情侣在一起的时候，在蚂蚁庄园各自养了两只小鸡，后来，分手了，但双方并没有互删支付宝好友；直到有一天，小鸡跑到了对方家里，或许，会让双方有所感慨……

XX注：依然还是一个情字：情感、情绪、感情。 ​

目录：

XX注：第一次看到这个目录的时候，没仔细看，没什么感觉；现在写笔记的时候，突然发现讲者还真是挺文艺的，起标题很讲究文艺范儿，例如：又回到最初的起点，XXXXX 青涩的脸、……

WebGL，想说爱你不容易

最初选择的原因/优点：

• 比传统渲染技术（Canvas）更高效、性能更好

测试阶段发现问题/缺点：

• 在低版本安卓上，渲染错乱 & 其他问题

实际业务场景：

• 开发时间短，项目工期赶

• 用户量大（且低版本安卓仍有不少用户）

最终方案：

• 采用稳妥方案：对安卓仍采用 Canvas

结论：WebGL 想说爱你不容易

XX注：简而言之，这是：日益增长的性能优化/开发效能需求与落后的兼容性问题之间的矛盾；无关对错，关乎取舍；

0.3 6 颗鸡蛋？对小数点说 NO！

现象：

• 很久很久很久以前，某个未上线版本，用户的鸡蛋数量是带小数点的，0.36颗鸡蛋

XX注：就问你怕不怕，惊不惊喜，意不意外

问题：

• 小数部分容易造成困惑

  XX注：这个就不用解释了吧……

• 数字增加，用户感知不明显

  XX注：好比网游宣传语，一刀999，秒升99级，还行是吧？但换成：一刀 3.1415，秒升 0.618 级……（黑人问号？？？）

• 用户对于可收取的感知不明显

解决思路：

• 百分比进度条给用户以期待感

  • eg：讲者提到了王者荣耀每个英雄在等级边上都有升级进度条，给人一种期待感

    XX注：顺着这个例子，XX觉得这样有利于玩家随时了解当前升级情况，有利于一些战术操作从而给对方一个惊喜，或是判断当前场上局势，或者只是单纯地告诉玩家，很快就要升级了再加油补几个兵。

• 进度条变化给用户以感知

• 数字真正代表可收取的数量

「支付宝设计的神细节」之小蜜蜂

XX注：PPT 里的小蜜蜂是会动的，确实跳着8字。讲者描述的内容没仔细听，但这张图片的动效以及旁边的文字足够清晰和生动形象了，

讲者提到了，最后的实现是通过：两个三角函数叠加（然后说线上版本好像没有？什么新版主题来着？XX没听清楚……）

XX注：

• 细节，上午场也有提到“细节”。在帮助引导系统中，通过不打扰用户的情况下，提供一些小细节给用户带来温暖的感觉 ；而讲者在之后的演讲中也提到了细节两字，注重细节贯彻了蚂蚁庄园的核心价值观：为世界带来美好而微小的改变。在同类产品竞争激烈的情况下，细节或许是有能力打动用户的关键因素之一。

• 另一个方面，既然称为细节，就很容易被忽略掉，就比如我书读的少，也没仔细观察过蜜蜂，如果不是讲者提到蜜蜂?是跳8的，如果看到这个细节，我也不会有所共鸣、不会在内心有一种“啊哈，这个好赞！”的感觉。这样的代价或许就是，由于部分用户的认知能力无法Get到产品细节，所以某种意义上浪费了部分开发投入成本。

• 但又换句话说，考虑到人与人之间的交流，或许某个午后，一个发现这个神细节的人会因为这个细节而与另一个朋友进行分享…… 好了打住不说了，随缘。

如何优雅地「搞鸡」

XX注：上面提到的大致都是关乎用户体验的，这里来了点技术货。大概前面关于用户体验方面的内容让我的思维一直处于感性思维模式，所以一下子画风切换，有点跟不上突如其来的理性模式，所以笔记有点没跟上，思考力和理解力也没跟上（说白话就是讲者说了啥现在都忘了，以下内容基本都是靠看PPT脑补）……

如何「搞鸡」

• 采用“分层设计”：

  • 业务层：

    • 理念：组件化、数据驱动

      XX注：忘记讲者提到用了什么框架，但看到有 redux，那应该就是 react 了吧，但图上一堆 luna 又有点不确定,估计是内部项目代号…… 组件化和数据驱动，就不解释了

  • 数据层：

    • 基于 Redux

      XX注：核心概念：单一数据源、State 是只读的、使用纯函数来执行修改

    • 细节：增加了“防抖”、“组合”

      XX注：防抖（debounce），一般总是会拿来和“节流”（throttle）一起说，两者类似而不同，目的都是优化高频执行操作的性能，例如监听屏幕滚动事件处理，看似只是滑动一下，实际每移动1像素都会触发一次滚动事件。防抖，举个例子，乘公交车，以司机开公交车为例，只要一定时间内，有人还在上车，那么司机就一直等，等到一段时间内没人上车了再开。例如模糊搜索一般为了减少服务器压力，会采用防抖，通过keydown的间隔判断只要用户还在输入，就一直等，等到认为用户停止输入了，再发送请求。 ​

  • 游戏层：

    • 理念：

      • 工程化

      • 配置化

    • 举例：雪碧图，抽取出来可配置

• 好处：减少开发在实现新功能时考虑的事情，降低了维护成本

如何优雅

• 效：游戏渲染调试

  • 遇到问题：不知道边框在什么位置？（记不清）

  • 如何解决：（XX忘记了）

• 净：调试代码无侵入

  • 通过 webpack loader 保证不发布到生产环境

• 巧：图片自动合成。

  • 自动化 => 雪碧图合成工作

  • 尝试

    • 最初：由于受 webpack 生命周期限制，不能很好地实现这种功能；

    • 最终：改为 webpack loader

• 微：打磨动画细节：（蚂蚁庄园理念：为世界带来美好而微小的改变）

  • 关于微，如果做得不好，那么 => 微不足道的问题，等用户体量大时，都会成为致命的问题

    XX注：所谓防微杜渐，千里之堤毁于蚁穴。或许前阵子的 Ant Design 圣诞节彩蛋可能就是一个很不错的反面教材…… 就我个人角度而言这个彩蛋是个惊喜，但当用户体量大了，用户画像的数量和规模远超过彩蛋的可控范围了，那就无法称之为惊喜了.

• 极：纯手工切图

  XX注：此处又是一种取舍，优雅的第一条就是“效”，而纯手工切图怎么看都和效率搭不上边，但正如上午楼院长提到的“高跟鞋隐喻”，所谓工匠精神，就是哪怕效率很低，开发很不爽，很痛苦，但看到最终图片体积小了，同时图片质量也很高，让产品的体验更好了，也愿意去做纯手工切图……

  • H5图片体积严格；

    • png 无损压缩、不断压缩

  • 对大图片进行拆分；

  • 每一个点做到极致；

没有什么能够阻挡，对调通接口的向往

}} XX注：第一眼看到这个标题的时候，突然觉得他们组的服务端小伙伴们无辜地躺枪了……心疼三秒

例子： 出于无奈，用（和谐和谐）两字来代表小鸡... 来完成服务端的接口联调

XX注：mock 数据的事情平时再常见不过了，但能 mock 得如此清丽脱俗气质不凡而又形象生动意简言骇，作者一定是个骨骼精奇万中无一的习武天才

• 讲者补充：（这个画面大家肯定没见过，如果见到了肯定是严重的线上事故）

装扮与主题，开放与共赢

XX注：这里没啥特别想说的，只是不知为啥突然想到了 LOL 以及王者荣耀很重要的盈利点就是卖皮肤装扮，尤其是各种节日限定的皮肤，更坑的是 LOL 有时候还会拿过去限定的皮肤返场，通过10连抽卡的形式来卖，…… （其实是想到了自己非洲人的黑历史，唯一欧洲是当年总算抽到了龙年盲僧李青，所谓龙瞎……）

需求：

• 节日主题：（2018年春节主题）

• 高级装扮：推动业务成长，为了蚂蚁庄园与其他业务方的共赢

XX注:此处引用一位朋友的原话：穿上这个套装，我就是最靓的崽儿。

方案：FreeStyle 装扮制作平台

• 目的：解放开发与视觉的生产力

为了性能，不择手段；小问题，大算法

XX注：接着上个话题，上个话题可以说是表面上看起来很光鲜，各种装扮，把小鸡打扮的贼靓；但是这光鲜背后大概就是程序猿/设计师小哥哥小姐姐们多少个日日夜夜费劲头发不断优化的成果。

一个例子：中秋节的需求

• 需求介绍：

  XX注：这类需求太常见了……

  • 只在中秋节3天展示特殊样式

  • 原先吃饼干动作改成吃月饼

• 团队情况

  • 任务时间不多

  • 现有的素材，已经有 1M 大小

• 解决方案：

  • 向时间妥协。再追加五套帧动画，1M 的体积上，又加了500多 KB

解释：所以说这是最大的挑战

• 1M 大小原因：所有小鸡动画都是帧动画。每个帧动画有20多帧，加起来有 1M 多

• 影响：每次进入首页，有1M多流量消耗，用户会发现流量突然用掉好多，会对此质疑

解决过程：

• 从帧动画到骨骼X帧动画

  • 想法：

    • 用骨骼模型来重写

  • 尝试：

    • 白鹭时代，dragon bones

  • 问题：

    • 俩字儿 => 不会

      XX注：这熟悉的北方口音，居然给我一种好亲切的感觉…… ​

  • 进展：

    • 从10月底，尝试使用。发现还是 dragon bones 实际上还是用到了帧动画

    • 后来（此处没记下来）然后与视觉合作

    • 最终：数据文件+骨骼模型，100多K

• 另一个需求：支持动态换装

- 方案：

    - 资源系统

- 优点：

    - 根据服务端版本，实时更新

- 主要优化方案：

    - 加载策略：

        - 介绍：优先加载 js 文件，然后异步加载主题图片、装扮图片

        - 好处：加载 js 能保证主要功能不受素材文件加载异常的影响

    - 利用工程化手段：

        - 优化图片数量、体积、尺寸

        - 解决图片云构建系统依赖问题

• 优化无止境：为了小性能，不择手段，优化内存

  • 问题：图片资源多，内存占用大，

    • 安卓内存占用和图片尺寸成正比，会有各种渲染错乱、闪屏

  • before ：5200b

XX注：减肥前

- 网上找算法

    XX注：减肥中

    - max-rects-algorithm

        - 问题：

            - 大学学的算法都还给老师了

        - 解决方案：

            - 让新进来的校招生，来实现该算法（还成功了）

                XX注：算法鬼才，XXX淘到宝了

        - 大致思路：

            - 改变图片排列

- 优化了图片体积 

XX注：减肥后

In Tiny.js we trust, in R3 we trust.

XX注：具体说了啥记不清了……就记得下图有两个游戏是用 R3 实现的，图3登山赛我还真玩过…… 曾经有一次为了拿第一，本来差点就到第一了，结果手滑失误了，当时连删除当时第一名好友的心都有了，反正又不是微信…… 这里面删除好友的成本很低……

基于R3实现

又回到最初的起点； WebGL 青涩的脸

XX注：凡是过往，皆为序章。天道好轮回，……（？走错片场了）

回顾蚂蚁庄园上线一年多历程

• 线上遇到很多稳定性问题，可能与内存、CPU有关

  XX注：安卓机：怪我咯？

• 蚂蚁庄园，虽然是 2D 的，不像 3D 那样对性能要求那么严格，但是仍需要优化

• 9月份，开启新版本的性能测试，

  • 发现问题：用户闪退

  • 尝试思路：WebGL 能避免闪退问题

  • 实际业务场景：在一年多时间里，经历支付宝版本升级，支付宝内核升级，对安卓手机的支持度更好了

• 结论：又回到最初的起点： WebGL 青涩的脸

  XX注：那些年，我们填过的坑、改过的 bug、秃掉的头发……

问答环节

XX注：此处记录的偏差可能较大，仅供参考

提问：提了一个线上的bug，蚂蚁庄园排行榜，小鸡来偷吃的时候，有提醒，但点击的时候发现并没有（大概是这样，当时过于震撼第一个问题居然是提bug，然后就记不清说了啥）

XX注：还好这次没有被选中邀请来到Z空间现场，不然的话难免自己会真的会说出自己开发 ant design 项目时遇到的 bug 和坑…

回答：因为用户体量特别大，所以数据不一定会准，可能存在数据延迟。

提问：建议：揍小鸡的功能，加个新道具：中毒卡，作用是吃饲料的速度变慢。

回答：反馈很好，后期会与产品讨论。

问题：小鸡帧动画的问题，用什么引擎or工具解决？cocos2d

回答：这些都差不多。

问题：小鸡换装的时候，每次都要重新切图，拼装，不顺利。

回答：做了一个系统，把这些工作给视觉去做……

XX注：毕竟大公司，系统说做就做……

结语

前端职责：作为一名前端开发，不应只满足产品需求

更高要求：对产品负责，比如：给出自己的建议；甚至可以主导产品；

XX注：此处没听清楚具体的，但大致意思就是上面自己写的吧

XX注：前端有自己的优势：逻辑思维与感性的结合，同时不论是2C还是2B，都是开发中离用户最接近的一环，最容易体会到用户的真实需求，就比如最近我参与到一个公司内部的类似TAPD的协作平台，快接近开发完成时，自己就用上了，自测过程中把这次开发任务添加为系统中的的一个项目，并且把遇到的bug在里面提交等等，可能是这个项目最早的真实用户了，包揽了开发、测试、普通用户角色。

XX意见与建议：

写这篇笔记的时候已经写到凌晨三点多了，既然主界面点小鸡的时候会有文字提示，或许可以考虑加入一些对熬夜人士的温馨提示：比如再熬夜发际线就和我一样了……

以后等想到了再更新吧，也就2个月前刚从北京回上海时开始玩的 ……

XX反思：

时代变化与知识迭代

• 自己从事前端也5年多了，关于 webgl 同样涉猎较少，但正如讲者的经历，他们团队在接触2D动画、骨骼模型时也都是一脸蒙圈，但如他所言，咋办？一个字：学。就是这么简单。

• 或许正如第二天D2论坛里圆心提到的，与其他程序岗位不同，前端领域是一个变化很快的领域，充满挑战的同时，也是充满了机遇。

• 结合我自己经验，刚做前端的时候，凭着自己学校里自学的 jQuery 、搭个人博客还有计算机科班出身的基础和对前端的好感，入行前端，而后发现从 jQuery，jQuery UI 到 Bootstrap，到 template.js X lodash 到 Vue 全家桶再到现在的 React X Typescript X Mbox… 好像就从来没停下过学习的脚步……是不是很可怕？

• 却想起曾经在书声上多次听到的一句话：“未来十年，我们所认为的能力将荡然无存”。所以解决方案就是：《Lifelong Kindergarten》，面对不确定性的未来，保持好奇心，培养创造力、终身学习。

工程思维、工匠精神

• 用一句老比喻来说，上面提到的内容或许决定了我们职业发展的下限，讲者提到的，工程思维，工匠精神；可能则是决定了我们职业发展的上限。

• 也许上面的比喻并不恰当，不过工程思维、工匠精神的重要性想必听了这次的分享不言而喻。说到工匠精神，我的第一反应就是这本书《旅行与读书》，一个问题：“如果你到了一百岁生日，你要在哪个餐厅用餐？”以及一句话：“每当你以为单一美食最高境界过如此，总有新的经验能让我再度惊艳”。

• 而工程思维，这个我倒是觉得很简单：只要不断地被坑、填坑、被坑、填坑、被坑、填坑……就行，当然，只是普通的填坑不行，要优雅地填坑。

最后

写完这篇笔记，总共大概写了5个多小时左右… 效率上要加强，不然头发都不够掉了；当然笔记还有很多不足，望指正。

这篇笔记主要是XX自己随缘记录了一些想法，其实还是过于零散，兴许日后会对自己有影响的，只是最后的反思部分，亦或者正如文中出现的几处：引用 See Conf 上半场分享的几个观点，以后也许会在某个时刻，灵光乍现般记起这一次悠鹤分享的内容中的某个观点。

但不管怎么说，就如同读书、旅行，未必要领悟出什么人生哲理，而是在这个过程中足够爽就已经很好了；同样记笔记的这个过程，其实记多了会发现也是很有趣的，至少XX开始享受这一个过程，或许也已经足够了。（虽然头发掉了很多）

如果觉得这篇文章笔记有帮助，欢迎关注一下文章最开头的公众号二维码~ 今年立了 flag 会多写几篇技术文、读书笔记、项目盘点反思……