前言:前端
运气不佳没有被选中到现场参加第二届 See Conf 蚂蚁金服体验科技大会,全程看的直播,印象最深的分别是上午场楼院长的分享以及下午场悠鹤大佬的分享。react
原先只是简单整理一下笔记,在记录过程当中,本身有一些想法冒了出来,因而就成了这篇笔记里的 “XX注”。webpack
因为当时在星巴克看的直播,有些内容没有听清楚,加上本身理解误差因此笔记不免有所疏漏或者错误,本身也在有疑惑的地方标注出来了,欢迎各位大佬指正web
制做人:XX,爱回收网前端开发,微信:X_XDalston算法
公众号:清风迅来,摄影/美食/旅行/前端/翻译/阅读/健身……redux
XX注:一开始没仔细听讲者说的内容,还觉得是讲者写的,就想,果真前端都这么文艺有才的啊…性能优化
XX注:想起了上午场的“情感”要素,或许有时候产品设计师也不会想到产品在海量的用户群体下,开放式的交互,结合真实的情感,会本身演化出各类意想不到而又在情理之中的体验服务器
XX注:依然仍是一个情字:情感、情绪、感情。 微信
XX注:第一次看到这个目录的时候,没仔细看,没什么感受;如今写笔记的时候,忽然发现讲者还真是挺文艺的,起标题很讲究文艺范儿,例如:又回到最初的起点,XXXXX 青涩的脸、……框架
开发时间短,项目工期赶
用户量大(且低版本安卓仍有很多用户)
XX注:简而言之,这是:日益增加的性能优化/开发效能需求与落后的兼容性问题之间的矛盾;无关对错,关乎取舍;
XX注:这个就不用解释了吧……
XX注:比如网游宣传语,一刀999,秒升99级,还行是吧?但换成:一刀 3.1415,秒升 0.618 级……(黑人问号???)
百分比进度条给用户以期待感
eg:讲者提到了王者荣耀每一个英雄在等级边上都有升级进度条,给人一种期待感
XX注:顺着这个例子,XX以为这样有利于玩家随时了解当前升级状况,有利于一些战术操做从而给对方一个惊喜,或是判断当前场上局势,或者只是单纯地告诉玩家,很快就要升级了再加油补几个兵。
进度条变化给用户以感知
数字真正表明可收取的数量
XX注:PPT 里的小蜜蜂是会动的,确实跳着8字。讲者描述的内容没仔细听,但这张图片的动效以及旁边的文字足够清晰和生动形象了,
讲者提到了,最后的实现是经过:两个三角函数叠加(而后说线上版本好像没有?什么新版主题来着?XX没听清楚……)
细节,上午场也有提到“细节”。在帮助引导系统中,经过不打扰用户的状况下,提供一些小细节给用户带来温暖的感受 ;而讲者在以后的演讲中也提到了细节两字,注重细节贯彻了蚂蚁庄园的核心价值观:为世界带来美好而微小的改变。在同类产品竞争激烈的状况下,细节或许是有能力打动用户的关键因素之一。
另外一个方面,既然称为细节,就很容易被忽略掉,就好比我书读的少,也没仔细观察过蜜蜂,若是不是讲者提到蜜蜂🐝是跳8的,若是看到这个细节,我也不会有所共鸣、不会在心里有一种“啊哈,这个好赞!”的感受。这样的代价或许就是,因为部分用户的认知能力没法Get到产品细节,因此某种意义上浪费了部分开发投入成本。
但又换句话说,考虑到人与人之间的交流,或许某个午后,一个发现这个神细节的人会由于这个细节而与另外一个朋友进行分享…… 好了打住不说了,随缘。
采用“分层设计”:
业务层:
理念:组件化、数据驱动
XX注:忘记讲者提到用了什么框架,但看到有 redux,那应该就是 react 了吧,但图上一堆 luna 又有点不肯定,估计是内部项目代号…… 组件化和数据驱动,就不解释了
数据层:
基于 Redux
XX注:核心概念:单一数据源、State 是只读的、使用纯函数来执行修改
细节:增长了“防抖”、“组合”
XX注:防抖(debounce),通常老是会拿来和“节流”(throttle)一块儿说,二者相似而不一样,目的都是优化高频执行操做的性能,例如监听屏幕滚动事件处理,看似只是滑动一下,实际每移动1像素都会触发一次滚动事件。防抖,举个例子,乘公交车,以司机开公交车为例,只要必定时间内,有人还在上车,那么司机就一直等,等到一段时间内没人上车了再开。例如模糊搜索通常为了减小服务器压力,会采用防抖,经过keydown的间隔判断只要用户还在输入,就一直等,等到认为用户中止输入了,再发送请求。
游戏层:
理念:
工程化
配置化
举例:雪碧图,抽取出来可配置
好处:减小开发在实现新功能时考虑的事情,下降了维护成本
效:游戏渲染调试
遇到问题:不知道边框在什么位置?(记不清)
如何解决:(XX忘记了)
净:调试代码无侵入
巧:图片自动合成。
自动化 => 雪碧图合成工做
尝试
最初:因为受 webpack 生命周期限制,不能很好地实现这种功能;
最终:改成 webpack loader
微:打磨动画细节:(蚂蚁庄园理念:为世界带来美好而微小的改变)
关于微,若是作得很差,那么 => 微不足道的问题,等用户体量大时,都会成为致命的问题
XX注:所谓防微杜渐,千里之堤毁于蚁穴。或许前阵子的 Ant Design 圣诞节彩蛋可能就是一个很不错的反面教材…… 就我我的角度而言这个彩蛋是个惊喜,但当用户体量大了,用户画像的数量和规模远超过彩蛋的可控范围了,那就没法称之为惊喜了.
极:纯手工切图
XX注:此处又是一种取舍,优雅的第一条就是“效”,而纯手工切图怎么看都和效率搭不上边,但正如上午娄院长提到的“高跟鞋隐喻”,所谓工匠精神,就是哪怕效率很低,开发很不爽,很痛苦,但看到最终图片体积小了,同时图片质量也很高,让产品的体验更好了,也愿意去作纯手工切图……
H5图片体积严格;
对大图片进行拆分;
每个点作到极致;
XX注:mock 数据的事情平时再常见不过了,但能 mock 得如此清丽脱俗气质不凡而又形象生动意简言骇,做者必定是个骨骼精奇万中无一的习武天才
XX注:这里没啥特别想说的,只是不知为啥忽然想到了 LOL 以及王者荣耀很重要的盈利点就是卖皮肤装扮,尤为是各类节日限定的皮肤,更坑的是 LOL 有时候还会拿过去限定的皮肤返场,经过10连抽卡的形式来卖,…… (实际上是想到了本身非洲人的黑历史,惟一欧洲是当年总算抽到了龙年盲僧李青,所谓龙瞎……)
XX注:此处引用一位朋友的原话:穿上这个套装,我就是最靓的崽儿。
XX注:接着上个话题,上个话题能够说是表面上看起来很光鲜,各类装扮,把小鸡打扮的贼靓;可是这光鲜背后大概就是程序猿/设计师小哥哥小姐姐们多少个日日夜夜费劲头发不断优化的成果。
需求介绍:
XX注:这类需求太常见了……
只在中秋节3天展现特殊样式
原先吃饼干动做改为吃月饼
团队状况
任务时间很少
现有的素材,已经有 1M 大小
解决方案:
1M 大小缘由:全部小鸡动画都是帧动画。每一个帧动画有20多帧,加起来有 1M 多
影响:每次进入首页,有1M多流量消耗,用户会发现流量忽然用掉好多,会对此质疑
从帧动画到骨骼X帧动画
想法:
尝试:
问题:
俩字儿 => 不会
XX注:这熟悉的北方口音,竟然给我一种好亲切的感受……
进展:
从10月底,尝试使用。发现仍是 dragon bones 实际上仍是用到了帧动画
后来(此处没记下来)而后与视觉合做
最终:数据文件+骨骼模型,100多K
另外一个需求:支持动态换装
- 方案:
- 资源系统
- 优势:
- 根据服务端版本,实时更新
- 主要优化方案:
- 加载策略:
- 介绍:优先加载 js 文件,而后异步加载主题图片、装扮图片
- 好处:加载 js 能保证主要功能不受素材文件加载异常的影响
- 利用工程化手段:
- 优化图片数量、体积、尺寸
- 解决图片云构建系统依赖问题
复制代码
优化无止境:为了小性能,不择手段,优化内存
问题:图片资源多,内存占用大,
before :5200b
XX注:减肥前
- 网上找算法
XX注:减肥中
- max-rects-algorithm
- 问题:
- 大学学的算法都还给老师了
- 解决方案:
- 让新进来的校招生,来实现该算法(还成功了)
XX注:算法鬼才,XXX淘到宝了
- 大体思路:
- 改变图片排列
- 优化了图片体积
复制代码
XX注:具体说了啥记不清了……就记得下图有两个游戏是用 R3 实现的,图3爬山赛我还真玩过…… 曾经有一次为了拿第一,原本差点就到第一了,结果手滑失误了,当时连删除当时第一名好友的心都有了,反正又不是微信…… 这里面删除好友的成本很低……
XX注:凡是过往,皆为序章。天道好轮回,……(?走错片场了)
线上遇到不少稳定性问题,可能与内存、CPU有关
XX注:安卓机:怪我咯?
蚂蚁庄园,虽然是 2D 的,不像 3D 那样对性能要求那么严格,可是仍须要优化
9月份,开启新版本的性能测试,
发现问题:用户闪退
尝试思路:WebGL 能避免闪退问题
实际业务场景:在一年多时间里,经历支付宝版本升级,支付宝内核升级,对安卓手机的支持度更好了
结论:又回到最初的起点: WebGL 青涩的脸
XX注:那些年,咱们填过的坑、改过的 bug、秃掉的头发……
XX注:此处记录的误差可能较大,仅供参考
提问:提了一个线上的bug,蚂蚁庄园排行榜,小鸡来偷吃的时候,有提醒,但点击的时候发现并无(大概是这样,当时过于震撼第一个问题竟然是提bug,而后就记不清说了啥)
回答:由于用户体量特别大,因此数据不必定会准,可能存在数据延迟。
提问:建议:揍小鸡的功能,加个新道具:中毒卡,做用是吃饲料的速度变慢。
回答:反馈很好,后期会与产品讨论。
问题:小鸡帧动画的问题,用什么引擎or工具解决?cocos2d
回答:这些都差很少。
问题:小鸡换装的时候,每次都要从新切图,拼装,不顺利。
回答:作了一个系统,把这些工做给视觉去作……
XX注:毕竟大公司,系统说作就作……
XX注:此处没听清楚具体的,但大体意思就是上面本身写的吧
XX注:前端有本身的优点:逻辑思惟与感性的结合,同时不管是2C仍是2B,都是开发中离用户最接近的一环,最容易体会到用户的真实需求,就好比最近我参与到一个公司内部的相似 TAPD 的协做平台,快接近开发完成时,本身就用上了,自测过程当中把此次开发任务添加为系统中的的一个项目,而且把遇到的bug在里面提交等等,多是这个项目最先的真实用户了,包揽了开发、测试、普通用户角色。
写这篇笔记的时候已经写到凌晨三点多了,既然主界面点小鸡的时候会有文字提示,或许能够考虑加入一些对熬夜人士的舒适提示:好比再熬夜发际线就和我同样了……
之后等想到了再更新吧,也就2个月前刚从北京回上海时开始玩的 ……
本身从事前端也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 会多写几篇技术文、读书笔记、项目盘点反思……
哦,还会记录最近本身与脱发抗争的经历……