2023 关于图像互动技术前景思考

前言 很久没有在外部写文章,跟我的读者们交流了,一些知心一点的同事,也离职了。所以最近感觉有点缺外部的输入,还是想写点文章,跟各种各样的朋友交流一下。 熟悉我的人应该知道,去年参加了支付宝的五福的前端开发,主要负责的是 AI 年画。 年画里面其实是有很多图形互动技术,比如秒轮廓,让后让兔子动起来,然后整个过度动画到装饰页面,装饰页面对于贴纸相关的操作,里面其实用到了大量的图形互动技术,主要用的是蚂蚁的 2D 互动引擎 Tiny.js。 后面我会整理一下,把年画的一些方案公布出来,有兴趣的可以看一下。 在做五福之前,我从来没有接触互动技术,对于如何开发互动应用没有任何概念,另外像五福这种大促时间又紧,任务又重,压力十分之大。 还好跟我合作的 partner 是懂的,并且有互动技术大佬给我们当技术顾问,所以才能顺利的上线并取得了不错的效果。 工作内容发生变化 回到我自己今天写这篇文章的目的,主要是我的工作内容要发生变化了,以后要从一个传统前端要转向一个图形互动技术方向的前端了。 这意味着什么呢? 服务的用户从公司内部用户转向了公司外部的 C 端用户。 用户量更大,意味着要求就更高,挑战就更大,也容易出故障。 技术方向发生了分叉,得重新开始学,学习任务极大。 互动技术方向对于我来说几乎是从 0 开始学,前面几年的前端经验积累用处就没那么大了,对于 React、构建工具、微前端这样的知识未来就不会再花很多的时间去学习了。 需要从 0 开始学习互动技术方向的内容:图形学、WebGL、2D 引擎库、3D 引擎库等等,还得稍微补一些数学知识。这块从我目前的学习以及同事了解,学习内容非常的多,而且对专业要求极高,不亚于传统前端的技术栈。 变化的原因主要是组内对于互动技术这块需要更多的人才,今年这块的业务会更多,另外就是在五福里接触过之后,觉得这块还是比较有意思的,特别是搞 3D 的,比如今年的福气乐园,看来就比较高大上。 两者结合,今年就准备开始走这个方向了。 不过对于现在来说,换方向对于职业发展有一些风险的,我也是在思考过后才决定的。 前景思考 对于换职业方向,其实我觉得是一件很重要的事情,需要慎重,影响未来的发展,尽量还是朝着前景好的方向转。 我记一下我现在对这个方向的思考,如果你刚好准备换方向可以参考一下。 担心的 路会往专精方向走,需要接受找工作没那么多公司招这个岗位的情况。 目前每个互联网公司都会招传统写页面的前端,但是对于图像互动技术的前端的岗位需求会少很多。 门槛高相对较高、知识的广度和深度往往不限于前端。 比如需要掌握图形学、部分数学这样非常专业的知识,相对还是比较难一些。 工程化相对落后,开发体验相对较差。 这块的知识体系跟图形/游戏行业是紧密相连的,整体看仅前端范围内还是比其它场景更大的端和场景弱不少,包括应用场景、专业度、生产模式工作流啥的,都比较落后。 看好的 就是因为门槛高,才容易形成壁垒,不容易别替换(当然,反过来,也不容易替换别人,看自己怎么看待)。 在随着未来 AI 的发展,同事随着年龄变大,才不容易被年轻人或者 AI 替代。 看好未来人机交互的进步,甚至是变革。 主要看好两个方向 元宇宙 (不看好的朋友请保留意见)。现在国内腾讯(QQ 小窝)、阿里(淘宝人生、天猫二楼的 3D体验空间)、百度(希壤)、网易(网易瑶台)等都在布局这方面的,国外的更不用说了,Facebook 都直接改名为 meta 了。 人机交互变革。目前来看前端主要是负责电脑或者手机显示器和人进行交互,未来以后可能是 VR、AR 进行交互。 最后 通过上面的分析,主要是看好未来人机交互的进步,才选择了这个方向。就算以后这个方向发展得不好,有了这些基础知识还是可以往其他的方向,比如一些设计行业(家装设计)、可视化、游戏等行业进行发展。 最后如果你来选,你会怎么来选呢?欢迎留言说一下你的看法。

February 19, 2023 · 1 min · 68 words · 桃翁

【实战】分享一个花了 499 学到的写作方法:问题 + 回答

大家好,我是桃翁,一个不止前端的前端工程师。 前言 前几天在一个写作课里学习到一个写作技巧:文章 = 问题 + 答案。 大概就是说当你看到一个话题,想写成文章的时候,可以想一想你针对这个话题会有哪些问题。然后挨个回答一下这个问题,把回答组合一下,就成为一篇文章了。 我发现这个方法跟我有一些文章的方法很像,但是我并没有这样总结出来,而是在写的时候自然而然就这么去设计了。 以这篇用 husky 和 lint-staged 构建代码检查工作流 文章举个例,做一个实战教学,建议看下面的内容的时候先阅读一下这篇文章。 实战 一、提问题 我要介绍的主题是:构建代码检查工作流。 针对这个主题,我想到了几个问题: 什么是代码检查? 什么情况下需要用到代码检查? 怎么做代码检查? 怎么把代码检查做成工作流? 注意:每个人想到的问题不一样,所以写的思路可能也不太一样。 如果想不到什么问题,我这里给到的建议可以提 what、when、why、how 这样的问题,这也是一种写作方法,后面再讲。 根据以上的思路就可以把大纲列出来。 二、列大纲 其实一般可以直接把这些问题当做大纲。 但是我这篇文章后面又考虑到怎么做代码检查东西比较多,只有在知道了最基础的代码检查方法之后,才可能推到出要用 husky 和 lint-staged 这样的工具。 所以我最终还是以陈述的方式为大纲,一步一步的引导,最终把把代码检查做成工作流。 所以最终这篇文章的目录大概是这样的。 前言里面回答了什么是代码检查和什么情况下需要用到代码检查。 在最简单的方法这个大纲里就是怎么做代码检查。 最后的三个都是讲怎么把代码检查做成工作流。 三、回答问题 大纲做好了,就开始填内容了。 前言就没什么好说的了,主要是介绍背景,然后引出我们怎么做代码检查。 接下来就写了最简单的方法来做代码检查,再提出了两个问题。 其实这两个问题就是来解决工作流的问题。 下面的两个段落就是来解决这两个问题,看到没有,这又是问题 + 回答的模式,不仅大话题可以引发问题,还可以问题里套问题。 标题:通过 scripts 来解决如果检测工具多,需要多次处理,解决问题 1. 标题:通过 husky(哈士奇)来解决容易遗忘的问题,解决问题 2. 所以整篇文章都是以问题驱动,一步一步引导读者把小问题解决了,最终串起来就把大问题解决了。 总结 总结一下,这种问题 + 回答的写作方式有什么好处: **段落之间具有连贯性。**每个标题之前都是承上启下,都是来解决上面一个标题的问题,然后引出下面一个问题。 读者读起来很流畅,会产生恍然大悟的感觉。 最后在复盘一下这篇用 husky 和 lint-staged 构建代码检查工作流 我觉得不好的地方: 标题不够小白,导致受众不够多,导致打开率低。 在前言里背景介绍得不够细致,如果以前没做过这方面的,可能体感不强。

March 1, 2022 · 1 min · 70 words · 桃翁

img 和 picture 的区别和使用场景

img img 是 HTML4 时就有的标签, 至今仍然是在网页中嵌入图片的最常用的方式。 与 <span>, <em> 等标签一样属于行内标签 (准确地说属于 Phrasing Content)。下面是一个示例: <img src="favicon72.png" alt="MDN logo" srcset="favicon144.png 2x"> img 其实也可以控制在高清屏幕采用哪个图片,适合用在移动端 picture <picture> <source srcset="/media/cc0-images/surfer-240-200.jpg" media="(min-width: 800px)"> <img src="/media/cc0-images/painted-hand-298-332.jpg" alt="" /> </picture> 要决定加载哪个URL,user agent 检查每个 <source> 的 srcset、media 和 type 属性,来选择最匹配页面当前布局、显示设备特征等的兼容图像。 picture 就可以方便的控制在某种媒体类型,加载哪个图片。感觉比较适合做响应式用。 相比 img 标签,picture 提供了更丰富的响应式资源选择方式; picture 是 HTML5 中定义新标签, 其中可以定义若干个 <source>,浏览器会匹配 <source> 的 type, media, srcset 等属性, 来找到最适合当前布局、视口宽度、设备像素密度 的一个去下载。 为了向下兼容不识别 <picture> 和 <source> 的浏览器,<picture> 中还可以写一个 <img> 作为 fallback。...

July 1, 2021 · 2 min · 234 words · 桃翁

桃翁2020年度总结

前言 2020 年真的是不平凡的一年, 疫情夺走了很多人的生命,还夺走了我的工作(公司因为疫情被迫裁员),所以今年换了工作来到了蚂蚁,在蚂蚁的工作经历跟之前在蘑菇街完全不一样。。。 工作 来蚂蚁这半年我觉得在工作上的成长比我之前在蘑菇街一年半的成长都还多,经历比较丰富。 阿里一直都有拥抱变化的文化,我来大概五个月的时候就换了三个主管,经历了好几次的组织架构变动,我刚进来的时候同组的同事(之前组内大概 12 人)到现在还跟我一组的仅剩一名。 不过随着每一次的变动,我的分工也越来越清晰,从最开始哪里缺人就去哪里,再到负责一块模糊的业务线,再到一个人带着 3 个合作伙伴负责一整个业务线,再到现在有了 3 个正式加 6 个合作伙伴的阵型。 作为整个业务线的 owner 不仅要接需求还要去预测业务未来的走向,这样才能在技术上做好提前的准备,当业务真的来了,才能快速的支持。这个是我在试用期答辩的时候面试官给到我的期望,这个我在之前试用期结束后有写过。 原来我是个业务性选手???? 只不过那个时候我只是觉得这个话说得很对,并没有体感,但是当我在负责整块业务的,以及带着一群人在做的期间,作为业务 owner 必须得去思考这些了,因为我们这里业务发展得很快,虽然我们业务团队成员变多了,但是需求也越来越多,所以如果不提前去做一些业务上的预测,技术上的沉淀,当业务发展再快点,需求再多一些我们目前的这些人就消化得很吃力,甚至吃不下,这是我今年非常大的一个收获。 对于这个收获其实我之前想过我为什么可以得到,我刚开始把原因归结到了运气,因为我能有机会负责一条业务线的东西是由于我的师兄以及其他大部分同事都走了,现有的业务只能由留下来的人去承担,所以我当时想到了那些得到晋升或者 375 的同学是不是运气好,可以做到好的业务或者技术。但是又细想如果机会给你了,如果没有把它当机会,而且他这块重重的东西当做负担,或者平常心看待,可能也做不出什么优秀的成果。 但是一件平凡的事情如果交给一个优秀的人去做,大概率还是会做出优秀的东西。 所以最后我得出的结论是运气可以让一个准备好了,有实力的人加速成功,但不会让一个平凡的人获得成功。 学习与写作 当我在准备写总结的时候,我本以为今年读的书(去年 20 本)会比去年要少,没想到今年还略多一点,读完的都有 29 本了,但是我明显能感觉到今年花在读书上的时间变少了,特别是在入职蚂蚁之后,属于自己的时间更少了。 我想可能是渐渐的找到了读书的方法,越读越快了吧。 下面是我今年读书列表:豆瓣主页 在写作方面今年公开文章产量就很低了,只有 13 篇,基本都是上半年写的,下半年入职蚂蚁之后就基本没怎么写了,一方面是因为确实工作太忙了,另一方面需要在公司内部写不少的文档。 文章列表见博客:前端桃园 技术 很遗憾今年对技术没有做什么深的研究,主要是业务太忙,把我对技术的追求抹平了,整天就想着如何能把业务支持下去。 来蚂蚁半年没写过 React,大部分时间写钉钉小程序和支付宝小程序,另外还写了将近两个月的云凤蝶。 在我没怎么接触过小程序前,对小程序有刻板的印象,总觉得小程序限制太多,很简单,没有什么意思,当然也不知道其原理,所以对小程序比较抵触。 但是当我写了两三个月之后,对小程序了解得越来越多,但是另一方面发现自己对小程序了解得越来越少,为什么这么说呢? 当我还没怎么接触小程序的时候可能想到的就只有 小程序的语法是什么样的,小程序是怎么运行的,但是写得越来越久,发现自己以前的视野太小了,整个小程序生态还有很多东西可以去研究,越写越发现自己不会的越来越多,这些不知道反而让我对小程序产生了兴趣,感觉可以有新的东西值得去研究。 比如小程序他是怎么运行的,跟原生、H5 之前的区别在哪里,关联是什么,view 层是怎么渲染的,逻辑部分的 js 是怎么执行的,与客户端,容器是怎么通信,怎么打包的,怎么编译的,编译出来的东西又是什么,怎么发布上架的,以及什么情况下使用小程序技术栈、什么情况下使用 h5 技术栈,等等等,这些没有搞明白的问题深深的让我对小程序产生了兴趣。 所以明年在技术上的一个目标就是深入小程序。 生活 家人 生活方面最令我开心的就是女朋友在 11 月份从上海辞职,来到了杭州,结束了 3 年的异地恋,每天下班后有个人在家里等的感觉真好! 旅游 西安旅游 国庆去西安旅游了,在去西安之前我们还先去南京溧水参加了【咪豆音乐节】。这次是准备得最充分的一次,还做了一些攻略。 重庆 Outing 重庆三峡博物馆 江景:重庆洪崖洞夜景...

January 24, 2021 · 1 min · 106 words · 桃翁

蚂蚁、字节、滴滴面试经历总结

前言 最近两篇面试以及离职相关的文章不容错过哦。 离开蘑菇街后,我最近的一些想法 拼多多和酷家乐面试总结 今年面试还是比较顺的,面了五家公司(酷家乐、拼多多、字节、滴滴、蚂蚁),都过了。 在文章里我不仅会列出面试题,还会给到一些答题建议,个人能力有限,也不能保证我回答都正确,如果有错误,希望能纠正我。 字节 一面 说一下浏览器缓存 浏览器缓存分为强缓存和协商缓存,强缓存会直接从浏览器里面拿数据,协商缓存会先访问服务器看缓存是否过期,再决定是否从浏览器里面拿数据。 控制强缓存的字段有:Expires和Cache-Control,Expires 和 Cache-Control。 控制协商缓存的字段是:Last-Modified / If-Modified-Since 和 Etag / If-None-Match,其中 Etag / If-None-Match的优先级比Last-Modified / If-Modified-Since高。 cookie 与 session 的区别 Session 是在服务端保存的一个数据结构,用来跟踪用户的状态,这个数据可以保存在集群、数据库、文件中; Cookie 是客户端保存用户信息的一种机制,用来记录用户的一些信息,也是实现 Session 的一种方式。 详见:COOKIE和SESSION有什么区别? 浏览器如何做到 session 的功能的。 其实就是考察 http 怎么处理无状态是怎么处理的,具体可见 COOKIE和SESSION有什么区别?里面的答案。 解释一下:csrf 和 xss XSS:恶意攻击者往 Web 页面里插入恶意 Script 代码,当用户浏览该页之时,嵌入其中 Web 里面的 Script 代码会被执行,从而达到恶意攻击用户的目的。 CSRF:CSRF 攻击是攻击者借助受害者的 Cookie 骗取服务器的信任,可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击服务器,从而在并未授权的情况下执行在权限保护之下的操作。 详见:前端安全面试题 怎么防止 csrf 和 xss 详见:前端安全面试题 跨域的处理方案有哪些 常用的:jsonp、CORS、nginx 代理,完整的大概是九种,可见:九种跨域方式实现原理(完整版) CORS 是如何做的?...

May 18, 2020 · 3 min · 499 words · 桃翁