2018年初冬，在淘宝996乐队的《持续迭代》的余味中，winter 在 Vue Conf 上以“挖掘 Vue 的声明式交互能力”为题做了演讲winter，本名程劭非，前手机淘宝前端负责人，阿里高级技术专家，JavaScript 专家，带领团队开发了阿里巴巴开源项目 Weex 移动前端开发框架。说到前端圈内的技术大牛，winter 这个名字就不得不提。winter 是谁？有人抓取GitHub中国区前100名用户，他排在第18位。知乎三大程序员「温赵轮」中的「温」。2016年的双十一会场，他带领团队开发的 Weex 前端框架覆盖了99.6%的会场页面，打开速度和页面流畅性都保障了完美的用户体验。余晟评价他：「真正的全栈工程师不是什么都会，而是有足够的知识和能力，遇到什么问题就能解决什么问题。我第一次接触这个说法的时候马上想到，程劭非应当就是前端出身的全栈工程师。」坚持自己喜欢的事，是一种什么样的体验？winter 出生于 1985 年 10 月 24 日，恰巧是我国的程序员节。江湖人称「计算机之子」。winter 的父母是最早的一批程序员，受父母影响，他很早就开始接触计算机。但小时候主要是以玩儿为主，他真正接触编程是高中的时候，在文曲星上面编写小游戏。那其实是个开玩笑的称号。当时还是在盛大的时候，同事说我爸妈都是程序员，就说我是计算机之子。本来应该说是程序员之子，是吧？我觉得程序员之子挺好，比计算机之子要好一些。我爸的工作偏硬件一些，我妈的工作偏软件一些。我爸在大学里面教书，我妈后来转销售、市场了，他们那个时候市场和销售不怎么分。她还自己创过业，经历比较丰富，但是也没有什么特别的成就吧，哈哈。我很早就开始接触计算机，从记事开始我家里就有电脑了，因为我爸妈都是干这个的。但是那个时候主要是以玩儿为主，真正接触编程还是高中弄了一个文曲星，当时它提供了一门非常简陋的语言——GVBASIC。我凭借各种研究出来的奇技淫巧，跨越了它的内存局限，在上面编游戏，形成了一套方法。后来发展到大家有新型号的触屏版文曲星，我根据内存的变化状况，研究出来触屏的位置怎么读取。高中的时候干了很多这样的事情。除了编程之外，winter 高中大学的时候还经常玩黑白棋。他自己写了个黑白棋 AI，据说赵劼有一次把它某个版本的子吃光了，然后 winter 表示这是个 bug。有人说喜欢一样东西是不需要理由的，但每个人对兴趣的选择其实并非出于偶然。其实有一些兴趣是消耗型的，比如游戏你玩儿完了就结束了。但是编程不同，它是一种累积型的兴趣。你可能一开始不是特别爽，一开始很艰难。但是随着你不断地投入时间，它给你的成就感和满足感是越来越高的。所以，我还是会把更多的时间放在这种兴趣上。玩游戏我也会比较偏爱这种发展型的游戏，而不是那种短时间、快速的游戏。所以呢，我觉得这是性格的导向吧。我很喜欢这种所谓的厚积薄发或者运筹帷幄，我喜欢做很有把握的事情。高中开始对编程有了一些基础的能力和兴趣，再往后就是大学参加 ACM 竞赛。当时成绩也算不上有多好吧，亚洲区域赛入围，省级比赛的金奖，前几名这样。所以大学的时候算是走上了正轨。后来自己到网上去找技术论坛开始学，然后参加工作，逐渐地有了更明确的方向。一直到现在也差不多做了十几年了。进阶的方法论：态度与技能编程是一种创造性的脑力劳动，这场漂流的大潮，它的规则就是不进则退。我在上大学的时候，选计算机专业，因为我妈是做这个的，她其实很严肃地问过我一个问题。她说计算机这个事儿你选了以后一辈子跟着跑，你觉得你 ok 吗？我当时也没有想太多，我说好，可以。虽然我至今仍然觉得 ok，挺好的。但是想一想，当时这个问题可能比我感受到的要更严肃一些。计算机的任何一个科目其实都是在拼命跑的，除了那些濒临淘汰的职业。我觉得其实前端并不快。客户端技术永远比前端技术发展得要快。只不过我们的某些领域，今天看似很稳定，但是可能真正革新的时候，你看不到那些变化。前端的好处就是这些变化都在标准里面，你就盯着这个标准去走，就可以了。所有的东西都会有人告诉你它变了，推着你向前走。而且前端社区比较活跃，能够把这些变化直接地传达给你。所以前端很快是个误解。我觉得其实前端很慢，因为标准发展得很慢，一定比私有的技术要慢。所以我倒是觉得前端工程师还是要更有危机感，就是不能跟着标准的节奏走，反而应该超在前面，看客户端里的那些技术能不能进到前端。不然就是很危险的事情。如果说有些工程师，他觉得连标准都跟不上，那我觉得可能这个人真的不太适合这个行业。如果世界上有一种万能的天赋，那一定是长久的热爱与坚持。关于勤奋的定义，winter 认为有两种。我觉得天赋谈不上，但是勤奋呢，我也谈不上。但是这里面有一点，就是说我们怎么样去定义这个勤奋吧。如果我们把勤奋定义为积极思考的话，那我觉得我是勤奋的。如果我们把勤奋定义为夜以继日地在这上面投入，那我觉得我已经懒得不行了。有些人是思想上的勤奋，有些人是行动上的勤奋。我觉得我思想上还是够勤奋的，包括新的技术也好，还是新的标准也好，这方面我始终没有落下过。我从来没有对自己讲过，你这个东西就不用学了。在我这里没有不用学，都用学。只是你有没有空，有没有更重要的事情去做，有没有更重要的东西去学。我特别烦网上的有一些言论，就是说：哎呀我这个东西不用学了。这个东西学了是浪费时间。其实最后你会发现，这些人把时间都浪费在逛街看电影上了。我不是说他们不应该干这些事，而是说，这些人不学这个并没有节省出来时间。怎么说呢？不管你出于什么动机去学习，原理都是一样的。有些东西是你必须要去学的，你总给自己找借口，其实什么都可以不学。计算机就是这样，你只会简单的 if、else、while 循环，你是可以写出来一切东西的。那么这样好不好呢？那我觉得肯定是有问题的。有些东西你可以学了之后很讨厌它，我觉得这是另一回事。但是你因为讨厌它，你不想学，这个事情就很奇葩。任何新的技术，你还是要把它研究明白的。比如 React 最新出的 Hooks，我也把它评价得一文不值，但是我仍然认真看了它的实现和它的一些想法，我觉得这是个态度问题。除此之外，一些细节也体现了 winter 对待技术的态度。网上传言 winter 用记事本写代码。因为他非常注重软件设计和可调试性，所以他敲代码时更在意思考的时间，不会过于依赖工具。有一次，因为和赵劼 PK 白纸写代码，他还改了飞机航班。他也很乐意分享自己的经验，关于前端工程师需要具备的能力，他系统性地总结出了一篇文章。首先我觉得前端分为三大基本能力：编程能力、架构能力和工程能力。在这个基础上具备一些前端的领域知识，更往上是对前端特有的构成体系的一些认知，就是说工具链，比如前端的性能问题，其实是这些实践中的体系。我在淘宝工作的时候，其实已经总结出来了几个比较通用的体系，比如中后台体系，就是怎样去快速地生产这些给专业人员用的中后台的操作界面。这个可能要形成一套方法。关于前端的架构体系，就是怎样建立一套基础库，建立基本的研发能力，去帮助整个团队去复用和快速地生产。然后，工具链和持续集成体系。这是通过工具统一提升团队的效率，帮助我们在线上减少问题，这里面也包括了监控与运维。性能体系，怎么产出性能更好的网页，怎样去建立从监控到人员的培训，再到跟其他端的配合，建立起这种真正提交给用户的高性能的网页。还有就是搭建体系，我们怎么用工具，就是用非代码的形式快速生产一些网页的系统。这大致就是我们前端工程师应该特别关注的几个大体系，加上通用能力。我觉得这就是衡量前端工程师的一个技能模型。程序员教育出了什么问题？winter 在手机淘宝一直负责前端工程师的面试与培养，这让他对程序员的教育问题有了更多的观察和思考。校招的时候我们去看通过的人，非常明显的一点就是他们都是主要靠自学的。没有一个人说我的学校教得特别好，都是说我自学了什么，我做了什么。我觉得这本身就是个问题。反映了我们的大学其实跟真正的行业需求匹配度挺低的。我不能说大学教得不好，但这个问题很明显。因为这个事情实在是太明显了，像阿里招聘的通过率很低很低，招不到。我觉得大学时其实应该更多地去写代码。我在大学的时候这方面感觉还不错，因为我参加了ACM竞赛，那个竞赛会写很多代码。它实际上是非常小的片段，类似一个个算法，并不能够成为很大的工程。我也看到大学里的老师很明确地发现了这些问题，在努力去解决。大家其实都有感觉的，我相信这个问题在几年之内应该至少会有所改善。不是说彻底解决，但是一定会变好。因为有很多优秀的人已经投入其中。我觉得这件事情有两个关键，一是怎样解决教育成果的评判问题，二是怎样解决师资的问题。我也联系过一些大学，其实他们最大的问题是没有好的师资。这个师资的问题是不是可以通过技术手段来解决；而评判的问题，我们可以通过商业模式去解决。我们应该能够去设计一种因为效果而赚钱的商业模式，通过这种方式拉回成本。否则的话，如果你去向学生收钱，因为学生缺乏评判能力，所以谁讲得幽默风趣，那就谁就能得到更多的生源。但是这样最终只会变成大家都去说相声，然后把教育变成德云社小剧场。我觉得最终教育这件事的解决，一定会变成受益者去买单，可能是企业去买单的这种教育模式。我们今天还有很长的路要走，所以首先应该是一些企业里的人开始关注教育这件事情。他认为编程不仅仅局限于 IT 领域，也是未来职业发展的趋势。我有时帮人家教教课，其实就是帮同事带带孩子，也有一些朋友会定期找我来学一下。很有意思，我有些朋友，比如猎头、律师他们想学学代码。所以，这符合我对未来职业的一种看法，将来各行各业都是需要写代码的。反而程序员可能会逐渐地变成一个很小的群体。因为其实代码可以更高效地表达和执行，值得去学习。律师要学到能分析卷宗是不是要很长时间？我觉得可能比你想象的要简单，因为我们有大量的库可以用。我们首先要建立编程的基本能力和思维，接下来只需要去理解这个库就可以了。我们并不需要自己真的去把这个东西做出来，所以实际上不会特别困难。当然我们如果想要更进一步，觉得开源的东西不够好，我们想给它贡献，那是需要很长时间，这也不是我能够教出来的。我觉得，可能100个程序员里有1个人会去尝试贡献这些开源的库，这已经是很不错的比例了。现在各行各业都开始学编程，这是一个必然的趋势，因为这样整体效率就会更高。就是大家都用代码，效率就更高。整个生产环节里只要有一个是非代码的，比如手淘的产品经理的文档，是文档而不是代码的话，效率马上就下来了。因为人类本身的自然语言是非常不严谨的，会存在大量的互相沟通的时间成本。除非它是一个形式化的东西，填空。而这个就已经很接近于编程了。前端如何优雅地进行职业规划？winter 一直相信这句话：You are the owner of your career. 你是你职业发展的责任人。我确实是从一开始就非常认可浏览器里面的前端这个方向。而且我从很年轻的时候，就发现浏览器里 JavaScript 的能力其实比大家认识的要强。所以从这一点上来讲，我应该从大三、大四左右，就基本上认定了前端这个方向是非常有发展的。所以我一直在努力地朝这方面积累。我在微软的时候虽然是客户端工程师，但其实我做的是浏览器，然后到盛大我在做渲染类相关的东西，同时也会负责一些前端的工作。所以对我来说，还是找一个我认为它有潜力的工作去做。后来我的职业发展的选择都是经过了一定的思考和设计的，没有那种非常突然的选择。我其实在盛大也不是全职的前端吧，到阿里算是百分之百的前端，也是个前端 leader（手淘前端的高级开发专家）。我觉得我在阿里之前，其实脑子里是没有线上这个概念的。在我看来整个的研发就是到产品的 deliver（交付）就结束了，觉得这个产品出来了自然而然就卖出去了。在阿里，我了解了产品的后半段，我真正认识到了什么叫作商业。业务有运营，技术有运维，还有监控之类的。有了所谓的线上意识。一个产品从它做完的那一刻其实是一个新的开始。我觉得这个是我最大的收获，理解了很多商业上的逻辑。另外，我觉得淘宝是我做的第一个真正的面向大量用户的产品。可能是因为我特别喜欢很挑战、很创新的东西，所以一直没有一个真正放到用户手里、被很多用户使用的产品。手机淘宝今天在整个市场也是最大的几个 App 之一，这个产品也始终会是我的骄傲。我觉得人一生能遇到这样的产品还是不容易的，虽然我也只是很多人中间的一个，但是这个真的是让我很有成就感。我考虑工作跟考大学时，考虑的问题都是一样的。这个工作带给我的 scope 有没有变大，资源有没有变多，成长有没有变好。其实这几个维度里面就包含大家平时关心的一切问题，什么薪资、级别这些东西。所以它是比较全面的考虑，更接近本质吧。因为如果你钱变多了，你做的事情还是和原来一样的，那迟早这个公司反应过来是要把你裁掉的呀！做技术的人日复一日地沉浸于创造，点滴的进步终会汇聚成真实的变革。其实知识始终都在那里，只不过你把它做成什么样的形式，去展现出来。所以从这一点来讲，我非常相信前端的机会都会在教育和出版行业。因为社交，你不 care 聊天的气泡是方的还是圆的，背景是粉的还是绿的，关键是谁在跟你聊天呀！而淘宝这种电子商务，主要还是你到底能买到什么商品，你买到的质量怎么样，花多少钱。这个网站做出花来，也不如图拍的漂漂亮亮，清清楚楚。我觉得从这个角度，前端在淘宝、腾讯这些领域，永远不会是一个非常重要的岗位。领域的特征就决定了它的前端只是一种锦上添花的东西。所以我一直坚信前端应该去做一些教育类的、娱乐的、展现性的事情。就算这次我还是找了一个工作，等两三年，我将来还是会做这块事情的。这是一个长期的规划。

On 2017-03-28 I visited a local customer who have been using our CRM on-Premise since 2010. The reason for this visit is that they have finished some reorganization and there are some new business process to implement after it. As the current 10 CRM Fiori application could not 100% fit with their business scenario, they are considering the possibility to build some custom application using Fiori, and would like to refer to suggestions from SAP.Below is the proof I present to our customers why Fiori is recommended ( I translate into English ):(1) Fiori consists of a large number of UI controls aimed at Enterprise application developed by top JavaScript developers in SAP. Those UI controls pass strict testing by SAP regarding functionality, usability, accessibility and performance. By developing on top of those controls, Fiori application developers can really concentrate on the implementation of their business logic. The final built application have a consistent look and feel.(2) Fiori is a responsive UI framework, which achieves that develop once, and can run on any supported terminals listed in SAP help. No additional pack and installation is necessary which is inevitable for other open source UI framework.(3) Fiori won Red Dot Award out of 4680 competitors from 61 countries in Design Concept Competition in 2015, which proves that the UX idea of Fiori has completely been confirmed by UX professionals.(4) Fiori provides robust role based access control and authorization where the concept of PFCG role is reused. Customer do not need to apply any third party authorization solutions.(5) Fiori has its dedicated software component and thus the upgrade is decoupled from CRM backend. While the backend version can keep stable, Fiori can be free to keep to latest version to benefit from continuous function enhancement and performance improvement shipped by SAP, no worry about any risks that this UI upgrade can have negative impact on backend.(6) The maintenance and continuous development ( new function iteration ) can never be ignored in Enterprise application development. There are also lots of tool-sets provided by Fiori to help customer with automation test and regression test, mock server to separate frontend / backend development. All of those help customer improve their development efficiency.Different voice from customerThe interesting point here is, I do hear another kind of invoice from some developers in customer company. They have different proposals:backendstill traditional ABAP development. Expose function module as web service via SOAMANAGER.frontend: VueVue is another UI framework based on MVVM which has more than 48000 stars in Github.Their argument(1) Fiori is too heavy especially when used in Mobile. Although Fiori has lots of built-in UI controls with product standard implemented by SAP, however the very controls customer frequently uses are only a small subset of them, and when building custom application especially in China, some product standard like accessibility are not so important. On the other hand Vue has lots of third party open source UI component library like element,iView and Mint UI.All those open source component library have lots of active contributors and can do the same good job as Fiori, at the same time they are very light weight.(2) Use Weex ( A framework for building Mobile cross-platform UI, more than 13000 stars in GitHub ), frontend developers can now program with simple syntax to build JavaScript application which has almost the same performance and UX as native application.Its slogan is “Write once, run everywhere”.UI5 – an “obsolete” framework?I have free talk with their developers offline and they told me they have already finished some internal project using Vue + Weex and have the feeling that they really benefit from the improved development efficiency and better performance than Fiori. They have the opinion that the way to directly manipulate DOM in JavaScript code like jQuery and UI5 on top of jQuery, is obsolete now. The idea of MVVM in Vue and Angular is the future.My personal opinionAs a developer myself, on the one hand I consider it is good to hear from customers that some of them have different technical proposal to fulfill their business requirement. On the other hand, during my presentation, I emphasize the fact that we are now building Enterprise application, not tiny application for personal users. Just take Fiori controls for example again. Although it looks quite trivial when taking each control out alone from end user point of view, such as a button, a text field, a label, however behind it the control developers in SAP do spend quite a lot of effort to ensure those control can work perfect on every supported device and every supported version of every supported browser. I am not sure whether this is still the case for mentioned open source component library in Vue ecosystem. Choosing Fiori means you can receive stable and continuous support from SAP, which might not be always available in open source community. I don’t know much about Vue, I am not sure whether it is really mature enough to build Enterprise application.Choose technology in Enterprise project implementation carefullyIn my opinion only students staying in colleague or those fresh graduates tend to make comparison against different programming languages or framework and finally they would like to come to a conclusion that “XXX is best. YYY is obsolete”. In fact I assume that when they say “XXX is best”, they actually would like to express “XXX is my favorite”. In our work we are not doing homework in university where we have freedom to choose our favorite language or framework. Instead, we are building Enterprise application which might be used by tens of thousands users simultaneously. The implementation of such application can last for several years. It is vital that in this area, it is not the “best” technology which must be chosen, but the one which is most fit with customer company’s development resource, fit with development project schedule and implementation, and is most sustainable when taking maintenance and continuous development into consideration. In my opinion I think jQuery based UI frameworks like UI5 have the mentioned advantages in this blog and are not obsolete compared with other listed popular frameworks.I am eager to hear comments from your side regarding this framework comparison topic.

On 2017-03-28 I visited a local customer who have been using our CRM on-Premise since 2010. The reason for this visit is that they have finished some reorganization and there are some new business process to implement after it. As the current 10 CRM Fiori application could not 100% fit with their business scenario, they are considering the possibility to build some custom application using Fiori, and would like to refer to suggestions from SAP.Below is the proof I present to our customers why Fiori is recommended ( I translate into English ):(1) Fiori consists of a large number of UI controls aimed at Enterprise application developed by top JavaScript developers in SAP. Those UI controls pass strict testing by SAP regarding functionality, usability, accessibility and performance. By developing on top of those controls, Fiori application developers can really concentrate on the implementation of their business logic. The final built application have a consistent look and feel.(2) Fiori is a responsive UI framework, which achieves that develop once, and can run on any supported terminals listed in SAP help. No additional pack and installation is necessary which is inevitable for other open source UI framework.(3) Fiori won Red Dot Award out of 4680 competitors from 61 countries in Design Concept Competition in 2015, which proves that the UX idea of Fiori has completely been confirmed by UX professionals.(4) Fiori provides robust role based access control and authorization where the concept of PFCG role is reused. Customer do not need to apply any third party authorization solutions.(5) Fiori has its dedicated software component and thus the upgrade is decoupled from CRM backend. While the backend version can keep stable, Fiori can be free to keep to latest version to benefit from continuous function enhancement and performance improvement shipped by SAP, no worry about any risks that this UI upgrade can have negative impact on backend.(6) The maintenance and continuous development ( new function iteration ) can never be ignored in Enterprise application development. There are also lots of tool-sets provided by Fiori to help customer with automation test and regression test, mock server to separate frontend / backend development. All of those help customer improve their development efficiency.Different voice from customerThe interesting point here is, I do hear another kind of invoice from some developers in customer company. They have different proposals:backendstill traditional ABAP development. Expose function module as web service via SOAMANAGER.Their argument(1) Fiori is too heavy especially when used in Mobile. Although Fiori has lots of built-in UI controls with product standard implemented by SAP, however the very controls customer frequently uses are only a small subset of them, and when building custom application especially in China, some product standard like accessibility are not so important. On the other hand Vue has lots of third party open source UI component library like element,iView and Mint UI.All those open source component library have lots of active contributors and can do the same good job as Fiori, at the same time they are very light weight.(2) Use Weex ( A framework for building Mobile cross-platform UI, more than 13000 stars in GitHub ), frontend developers can now program with simple syntax to build JavaScript application which has almost the same performance and UX as native application.Its slogan is “Write once, run everywhere”.UI5 – an “obsolete” framework?I have free talk with their developers offline and they told me they have already finished some internal project using Vue + Weex and have the feeling that they really benefit from the improved development efficiency and better performance than Fiori. They have the opinion that the way to directly manipulate DOM in JavaScript code like jQuery and UI5 on top of jQuery, is obsolete now. The idea of MVVM in Vue and Angular is the future.My personal opinionAs a developer myself, on the one hand I consider it is good to hear from customers that some of them have different technical proposal to fulfill their business requirement. On the other hand, during my presentation, I emphasize the fact that we are now building Enterprise application, not tiny application for personal users. Just take Fiori controls for example again. Although it looks quite trivial when taking each control out alone from end user point of view, such as a button, a text field, a label, however behind it the control developers in SAP do spend quite a lot of effort to ensure those control can work perfect on every supported device and every supported version of every supported browser. I am not sure whether this is still the case for mentioned open source component library in Vue ecosystem. Choosing Fiori means you can receive stable and continuous support from SAP, which might not be always available in open source community. I don’t know much about Vue, I am not sure whether it is really mature enough to build Enterprise application.Choose technology in Enterprise project implementation carefullyIn my opinion only students staying in colleague or those fresh graduates tend to make comparison against different programming languages or framework and finally they would like to come to a conclusion that “XXX is best. YYY is obsolete”. In fact I assume that when they say “XXX is best”, they actually would like to express “XXX is my favorite”. In our work we are not doing homework in university where we have freedom to choose our favorite language or framework. Instead, we are building Enterprise application which might be used by tens of thousands users simultaneously. The implementation of such application can last for several years. It is vital that in this area, it is not the “best” technology which must be chosen, but the one which is most fit with customer company’s development resource, fit with development project schedule and implementation, and is most sustainable when taking maintenance and continuous development into consideration. In my opinion I think jQuery based UI frameworks like UI5 have the mentioned advantages in this blog and are not obsolete compared with other listed popular frameworks.I am eager to hear comments from your side regarding this framework comparison topic.

目前，Flutter 和 React Native 当属此领域的佼佼者。Facebook 在 2015 年推出了 React Native，它的目标是创建移动应用程序，而不会影响应用程序的外观和感觉。随后，谷歌在 2017 年推出了 Flutter，它的目标是解决移动开发中跨平台、高性能问题。从这时起，新创业公司和企业就为他们选择其中哪个框架开发应用程序而陷入困境，这也推动了 Flutter vs React Native 的辩论。首先来说，笔者认为这两种框架并不存在谁要被 pk 掉的情况，毕竟这两种框架在特定的需求领域都能发挥很好的作用。换句话说，我们没必要对类似“谁是最好的语言”这种问题进行“党派之争”。但不得不承认，这两年 Flutter 发展非常迅猛，得到了越来越多企业和 coder 的关注，为了能让对此技术感兴趣的同学们有更深入的了解，我们采访了来自 ArchSummit 全球架构师峰会的讲师——同程旅行架构师李宁，由他来结合项目中的实际情况跟大家聊聊 Flutter 究竟有哪些优势又面临哪些问题，此外他将在ArchSummit全球架构师峰会中带来主题为《同程旅行 Flutter 的应用实践》的演讲，感兴趣的同学们也可多多关注。崛起的跨平台技术InfoQ：首先请您介绍一下跨平台技术的由来？互联网很多公司发展需要不断的快速试错，安卓和 iOS 市场占有率高，已经坐稳了移动开发的两大阵营。如何保证跨平台技术可以保证跨端的一致性、减少多端开发投入、提升开发效率，是所有开发者在不断探索和共同努力的方向，很多跨平台框架如 Hybrid、React Native、Weex、Flutter 等跨平台技术也由此应运而生。InfoQ：时至今日，已经有了很多跨平台框架，请您介绍一下目前比较流行的移动 APP 开发框架有哪些？它们又各有什么适用范围？目前比较流行的移动 APP 开发框架有：Hybrid、React Native、Weex、Flutter。Hybrid：可动态更新的页面，社区资源相对丰富，性能较差，对复杂用户界面支持不友好。适用范围：多应用于相对简单用户界面，可动态更新页面；React Native：对 IOS/安卓开发有一定认知，依赖 native 相关组件实现，有大量适配工作，支持热更。体验高于 Hybrid，可热更新。适用范围：更适合对原生开发有相关经验的开发者使用来开发，可实现相对复杂的界面；Weex：与 React Native 实现方式相似，依赖 Natvie 相关组件实现，封装 Native 组件工作量大，体验方面等同于 React Native，需要掌握 Vue 相关知识体系。适用范围：理论上等同于 React Native；Flutter：目前为止最接近原生的跨平台框架，自绘引擎，性能强大，流畅度高，易上手。需要具备原生开发能力，对 App 包大小影响较大。无法热更新。适用范围：自绘引擎性能强大，体验接近原生，开发易上手，可支持丰富的动画。可做较复杂动画和页面的开发。同程旅行 Flutter 实战InfoQ：Flutter 和 QT mobile 一样，实现了一个自绘引擎。但在近几年，QT 的声音一直很弱，您认为 Flutter 会不会步入 QT mobile 后尘呢？我认为不会的。首先，Flutter 官方推广力度比较大，版本更新频次较高，虽然都是使用自绘引擎，但是 Flutter 对前端开发更友好，性能强大，上手简单而 QT mobile 上手难。其次 QT mobile 社区生态推广力度小，受众也小，且 C++相对 Dart 开发效率低下，这也是造成 QT mobile 逐渐被遗忘的原因。InfoQ：请您展开说说相比于 React Native 框架，Flutter 的优势是什么？第一，JIT 模式下，编译速度与 JavaScript 基本持平，但是对于 AOT 模式下，Dart 效率远高于 JavaScript，JavaScript 则不具备 AOT 这个能力；第二，Flutter 使用的是自绘引擎，对 UI 的操作，布局的修改执行效率要比 React Native 效率高很多，React Native 基于 dom 树绘制修改原生组件，性能的瓶颈也在于此；第三，Dart 支持静态监测，可以在编译前发现很多编译问题，排除潜在问题（天生具备）而 React Native 则需要添加相关插件来做检测；第四点，Flutter 可支持较复杂的动画，流畅度方面表现高于 React Native。InfoQ：您和团队是基于怎样的考虑，选择 Flutter 开发成为团队的主要技术呢？关于这一点我们是这样考虑的，第一，Flutter JIT 编译模式可以极大地提升开发效率，原生开发前所未有的体会到了开发的便捷；第二，Flutter 可以严格保证跨端的一致性，AOT 模式下的高性能保证了体验流畅度，开发易上手、学习成本低，解决了我们提升开发效率和降低开发成本的诉求。InfoQ：开发者经常会这样评论：Flutter 目前最大的优势在于使用 Dart，最大的劣势也在于使用 Dart，对这句话您有何见解呢？对于优势之前问题的回答已经很全面了，这里就不在赘述，这个问题我主要来聊聊关于 Dart 的几点劣势：第一，不支持反射，无法在运行时动态修改类的行为；第二，线上发布代码，无法热更新；第三，Dart 相关社区目前还不是很完善，有待大家共同完善社区；第四，相关开发工具支持的力度还不是很成熟；第五，刚上手的开发者需要避免地狱嵌套这种模式，需要多注意控件的状态管理。第六，Dart 的空安全，在升级版本的时候，需要重新适配，比较头大。以上都算是 Flutter 上面的小瑕疵，但瑕不掩瑜，我相信使用 Dart 的开发者会越来越觉得 Dart 用起来“真香”。InfoQ：Flutter 框架有其自身的优越性，然而事物都有两面性，您能结合实践说一下目前发现的挑战有哪些吗？第一，Flutter 上线之后，业务发现异常。对于严重影响主流程的 case，只能通过发版来修复相关场景问题，无法做到及时止损，这样业务也会受损。对此，我们调研了一番，在一开始版本 Flutter 有支持热修复相关场景，后考虑到苹果审核或者 Google 自身官方审核不允许动态更新的机制，阉割了该功能，多么痛的领悟。后来，我们又对比了业界目前动态化方案，都是曲线救国，并不能从根本上处理问题，先透露下我们的方向，开启 Flutter JIT 模式来实现热修复，不过 JIT 模式下性能还是有损的，鱼和熊掌不能兼得。目前处于测试阶段，方案待同步给大家；第二，线上指标和本地调试性能的差异。目前 Flutter 提供了本地测试相关性能的工具，不过和线上指标相比还是有差异的。上线指标是我们关注的重点，用户不同机型，跑我们页面的性能需要指标量化，这就需要我们对线上相关指标监控起来，包括异常数据 、页面流畅度、cpu 使用率、首屏时间等都是需要量化和监控起来的。有了指标，后面就是针对性的优化了，持续优化是我们不断进步的方向；第三，切换版本。Flutter 升级迭代，都会发现相关需要适配的 API，以及需要兼容性的事情。之前升级 1.9.1-1.22.6（跨动比较大），除了应用层面 API 需要适配，一些底层渲染 API 也给删除了，没有相关方法，只能通过应用层面来适配，解决升级版本兼容性的问题（修改引擎层改动量大，版本升级适配工作量多）；第四，自动化集成。目前同程旅行 App 使用的是混合开发模式，Native 开发无感知集成到 App 中，目前分为上线集成模式和开发调试模式，分别用来集成 debug 产物和 release 产物，都以 Native 组件的方式集成进来。InfoQ：针对以上您发现的挑战，就其中一点说说您和团队的解决方案？上个问题已经为大家解答了一下，这里我再做一些补充。虽然 Flutter 提供了相关监测工具，但是基于 release 模式上线相关性能指标是无法真实监测到的，所以同程旅行为了及时监控到相关线上指标，自研了相关性能监控组件，量化了线上相关性能指标并进行了及时的治理工作。监控项主要分为以下几点：页面异常信息、FPS 监控、Crash。总的来说，监控性能以及相关指标的优化任重道远。Flutter 之前景探索InfoQ：在 Flutter 1.0 发布会上，Flutter 产品经理介绍了如何让 Flutter 运行在 Web 之上。那么经过发展目前 Flutter for Web 的现状是什么？关于 Flutter for Web 的现状，我认为虽然 Flutter2 已经正式支持稳定版本的 web 应用发布，但是包的大小、启动速度、FPS 等性能方面还不太令人满意，而且目前混合开发模式部署到 web 兼容适配问题还没有一个很好的适配方案。但是在我看来随着时间推移和社区的完善，这些问题肯定可以得到很好的解决。InfoQ：您认为 Flutter 的未来趋势如何呢？针对这个问题，基于上面的回答我先给大家总结几点优势：第一，Flutter 使用 Dart 语言进行开发，Dart 可快速上手，简单易学，越来越受开发者的追捧；第二，Flutter 性能表现和流畅的体验方面的优越性已经是当下跨平台不可逾越的；第三，随着越来越多的开发者加入到 Flutter 开发阵营和社区的生态的完善，开发者遇到的问题可得到越来越快速的解决；第四，Google 大力推广 Flutter，从频繁的版本发布我们可以看出 Google 对待 Flutter 推广的态度，特别基于目前国内混合开发声音越来越高，Flutter 对混合开发也是越来越重视，不断的进行性能优化和底层能力升级。因此，综合以上的几点优势我认为随着社区的完善和官方的大力推广 Flutter 在未来跨平台领域的市场占有率会越来越高，发展也会越来越好。采访嘉宾介绍李宁，同程旅行架构师，2016 年加入同程旅行，目前在研发中心的基础架构部门负责 iOS 端相关架构设计工作，包括持续集成工具链、组件化、跨平台等设计和开发，尤其在推动业务落地方面有丰富的实战经验，主导设计的 Flutter 混合框架已成为公司推动的主流跨平台解决方案，各项技术指标达到业内领先，已经受过相当规模的业务落地检验。在 App 架构设计方向有丰富的理论和实战经验，曾就职于金山、宜信等公司，主导了公司组件化，跨平台框架的相关设计并推演落地。李宁老师将在 11 月 12 日-13 日的 ArchSummit 全球架构师峰会中分享议题“同程旅行 Flutter 的应用实践”，针对如何通过技术手段，快速发现线上的异常，卡顿，Crash 以及如何量化线上性能指标等问题，分享实践过程中的相关解决方案，希望能为大家提供新的思路或者启发，点击了解详情。

前言前一篇文章里讲解了逻辑与Runtime&DSL，也提到了逻辑编排三板斧：元件 + 编排器 + Runtime，我在本篇将主要聊一聊元件设计以及YOHO的平台化。元件元件在我们的设计中，分为基础元件和业务元件，业务元件就是我们需要创建仓库、编写源码、提交发布的的元件，它是逻辑片段的实体；除它以外的都是基础元件，我们在设计给好莱坞使用的编排方案中。基础元件只有开始元件和结束元件，只是为了降低非研发人员的使用成本，元件越少越好。虽然分成了基础元件和业务元件，但业务元件实质上是一种特殊类型的基础元件，它们的关系类似于树和图，树也是图的一种，但书里常常会把书拆成单独的一个章节，因为树的体系足够大。业务元件也是，它就是基础元件中的 Custom 元件，但在元件体系中它的比重足够大，所以我们也将它抽出来作为一个大类来讲。元件语言业务元件的几个重要属性如下：初始化业务元件后，我们定义的文件结构：. |-- schema | |-- input.json | |-- output.json | `-- branch.json |-- index.js |-- package.jsonindex.js: 元件的入口文件，源码就写在里面，发布时文件中的源码会被作为 code 字段进行存储package.json: 元件的 dependency 就是从里面读取，作为元件的依赖项进行存储，和 code 字段配合使用input.json: 配置元件编排时渲染属性表单的JSON Schema，作为元件的 input 字段进行存储output.json: 用于描述元件的返回值，同样为JSON Schema，作为元件的 output 字段进行存储branch.json: 描述元件有几个分支，以及每种值的中文定义是什么我们对元件中分支判断的代码制定了规范，配合 branch.json ，将这种分支型业务元件的使用成本降到了最低，使用的复杂度转嫁为开发的约束性。拿《判断是否登录》元件举例，它有两个分支，已登录 与 未登录，代码进行分支判断是必须按照如下的格式书写：function foo() { if (isLogined) { return { branch: 0, data: { key: value } } } else { return { branch: 1, data: { key: value } } } }如果已登录，返回 branch 值为 0 ，如果未登录，返回 branch 值为 1。那么对应的 branch.json 必须如此定义：['已登录', '未登录']元件中返回的 branch 的值，会作为 branch.json 中的索引，元件中分支实际判断标准要和 branch.json 中的数组一一对应上，这样 runtime 才会按照正确的走向执行逻辑。元件整体设计基础工具侧，我们提供了模板初始化的能力、提供对应的元件开发脚手架，保障元件的基础开发能力，正在建设的 VSCode 插件用于提升研发体验，基于元件 OpenApi 提供的 元件 SDK 能够帮助元件录入元件市场，目前还只是服务本地研发，4月会进行线上元件开发的能力补齐。元件的表单配置项借助 form-render 实现了可视化的表单搭建，很好用，点赞。基于底层设施，上层实现了统一的元件市场，会按照应用、标签等进行隔离，所有业务的元件在元件市场中收敛，方便以后统一落入优酷物料中心。元件的一生一个元件从被生产到被编排，最后在页面被运行，贯穿了逻辑编排的始末，也是“逻辑是核心”的论证，下面我们就以元件的视角来看看整个逻辑编排过程中它都经历了啥。元件被发布后，进入元件市场，在编排界面，被拖拽生成元件实例，构建完整的业务逻辑。画布中，branch.json 被用于阐述各个分支，input.json 中的 json schema 通过 form-render 渲染为可配置的表单。编排实例创建完后，与UI编排进行关联，在UI搭建平台中创建的坑位，会需要元件执行后的返回值渲染UI，UI搭建平台会解析元件的 output.json ，将所有数据平铺展示。业务模块搭建完成后，跟随页面发布上线，runtime经过 启动 --> DSL 解析 --> 元件加载&注册 --> 元件检查 --> 元件执行 链路执行业务相关动作，在 元件执行 这一步，runtime 会进行 helper 和 payload 注入，提供帮助函数以及配置数据。两个问题这里有两个问题是我们落地过程中争论过的点，也希望各位看官提出自己的见解。先是业务元件 还是 结束元件？元件的 JSON Schema可以被修改吗？前端特色的逻辑编排集团内目前还是服务编排和业务编排比较多一点，也有服务端的逻辑编排，前端侧的逻辑编排却不多见。如果你对逻辑编排、业务编排、服务编排不是很清楚，推荐这篇文章 —— 《业务编排、服务编排、逻辑编排的区别》。在落地可视化搭建系统的过程中，结合搭建技术我们做了一点比较前端质的实现。我们的模块搭建系统，每个模块都会生成对应的 CDN 资源，页面组装的时候，会将页面用到的模块资源在服务端进行拼接 —— JS Combo。在逻辑编排落地的过程中，我们一不希望入侵现有构建服务，增加开发适配工作，第二也不希望逻辑编排增大页面 JS Bundle。所以在 runtime 的 dslWillInterpret 生命周期里，我们进行逻辑元件的资源按需动态加载。元件都很小，一个完整的流程对应的 JS 资源只有几 KB，这一点加载时间暂可忽略。配合上对已加载元件 JS 资源进行缓存重复利用，需要加载的资源体积会进一步减少。这个方案帮助我们解决了另一个问题，就是同一个业务模块中，我会创建多个编排实例，两个编排实例可能会在维护过程中出现使用同一个元件的不同版本，这种场景下，如果我们不进行按需动态加载，页面的 JS Bundle 可能会不可控地急速扩大。此时回头看，按需动态加载逻辑元件，帮助我们将页面的逻辑从 JS Bundle 中抽离了出去，替换成了简洁的 DSL，页面的 JS Bundle 也变小了，对于性能还有提升。YOHO平台YOHO平台的结构如下。在图的最右侧，有我们对 YOHO 的定位，它是一个平台。我们不希望做完全中心化的平台，我们只想约束协议、规范，基于这套编排协议做统一的 node 服务，对外提供 OpenApi；在前端交互侧，不奢求一套交互可以满足所有业务，编排器的外框架只会基于编排协议实现各个板块的适配器，你可以选择用或者不用我们提供的面板或者画布，或者选择性的用，编排器同样会基于这套协议去实现自动检查、编排快照等能力。求同存异是我们的选择。未来规划FBP，业务逻辑编排最后一公里这就需要提到我们当初做YOHO平台，要服务营销搭建平台的愿景了。将业务模块从易到难进行排列，前面75%的模块将由逻辑编排来覆盖。剩下的25%包含了我们的玩法类的或者定制性极强的模块，它们共同特点的逻辑要求高，内部状态多，想支持，也能支持，但元件调试发布、编排调试发布显得极为麻烦，在我们的预期中，这部分复杂模块是由研发来承接的。可视化搭建中逻辑编排的最后一公里还有解法吗？是可解的，基于现有能力去扩展 FBP 能力，让研发能够基于流来编程，在线编写 --> 在线测试 --> 流程纠错，你不仅可以更快的开发，而且你的代码会更加安全。总结逻辑编排的价值：可视化：简化了业务逻辑的生产UI与逻辑解耦：提高业务模块的可维护性逻辑复用：逻辑可以通过连接为多种不同的方式来产生不同的行为，会更好的代码复用能力天然跨端、跨容器：因为是纯 JS 执行，天然适配各端、各容器内。它的更深远意义是，如果UI + 逻辑能够覆盖所有模块开发，对于rax0.6 升 1.0、Weex 切 Kraken这种场景，迁移成本可以降低 90+%在线测试、自动纠错：让你的代码更安全YOHO的价值：统一大团队内的逻辑编排规范约束便捷的工具/库便于逻辑编排在业务中落地以下内容你可能感兴趣逻辑编排在优酷可视化搭建中的实践（一） - 逻辑与Runtime逻辑编排在优酷可视化搭建中的实践（二） - 编排器与业务

作者：闲鱼技术——黑荆背景闲鱼近期实现了端上直播间的 Flutter 技术重构，验证和拓展了 Flutter 在音视频领域的业务边界。因为直播丰富的玩法和可变的交互，通常我们会在直播间页面覆盖一层互动层，用于处理和展示业务互动行为。这一互动层，通常是由 H5/Weex 等技术来实现的，以满足动态性和业务投放的需求。因为其背后有着一整套配套的解决方案和能力，显然在 Flutter 场景下，复用或移植成熟的 Native 能力是比较好的解决方案，PlatformView 是最适合用于实现该组件的技术，这也是我们采用的方案。什么是 PlatformView？PlatformView 技术是 Flutter 提供的一种能够将 Native 组件嵌入到 Flutter 页面中的能力，有了这种能力，一些 Native 上非常成熟的功能组件，例如地图、广告页面、WebView 就可以很方便地和 Flutter 结合，在 Flutter 页面上展示。实现技术上，iOS 中，PlatformView 的 Native View 会被加入到 Flutter 的 UI 视图层级中，这种方式称之为 Hybrid Composition；而 Android 支持使用 VirtualDisplay 和 Hybrid Composition 两种模式，前者将 Native View 绘制到内存中，然后和 Flutter Widget 一起渲染到 Flutter 页面中，后者和 iOS 上类似。闲鱼目前在 Android 中使用的是 VirtualDisplay 这种模式。直播间互动层组件互动层是一个覆盖整个直播间的组件，隶属于某一特定的直播间，可以跟随该直播间上下翻页滑动，一般情况下处于直播间 View 层级的最上层，这样才能做到可以在直播间任意位置布局任意的元素并展示。它是一个背景透明的组件，当用户点击互动层上的元素时，由互动层来进行响应交互，而当用户点击透明区域时，事件会穿透互动层，由下面层级上最合适的组件来进行响应，不影响正常的直播间功能。这就要求我们对该组件的事件分发进行一些处理。这里主要的处理方案是，获取用户的点击位置坐标点，判断组件该像素点的透明度，根据一定的阈值来区分究竟是该由谁来响应。以 iOS 为例，我们知道 iOS 的事件响应分为两个阶段：第一阶段用于寻找最佳响应者，即在 View Tree 上不断调用 hitTest 和 pointInside 方法进行检测，第二阶段才是真正响应事件。所以对于 iOS 实现来说 ，我们只要干预第一阶段，重写该互动层 View 的 pointInside 方法增加上我们的透明度判断逻辑，就可以实现。Android 也是进行类似的处理。PlatformView 互动层的事件分发问题虽然通过 PlatformView 可以很方便地嵌入互动层 Native View，但在这个场景下事件处理遇到了一些麻烦。通常情况下，如果嵌入的 PlatformView 是一个正常响应事件的组件，那一般不会有问题，但由上面的分析可知，我们需要对事件进行特殊处理，因为互动层 PlatformView 处于整个直播间的最上层，所以正常情况下，所有它下面的 Flutter 组件都无法响应事件。我们可以将 PlatformView 的 hitTestBehavior 设置为 PlatformViewHitTestBehavior.transparent，这样可以将事件穿透到下面其他的 Flutter 组件，但是互动层本身就无法响应事件了。PlatformView 有两个身份，一个是作为 Native View，另外一个是作为 Flutter 组件树上的一个节点（Widget），因此它上面的事件由两部分共同配合处理。所以我们需要先探究一下 Flutter 框架是如何处理 PlatformView 在 Native 和 Flutter 两侧的事件分发和控制的，下面以 iOS 为例来进行具体分析。PlatformView 事件响应分析由 UI 层级图和下面的源码可以看出，PlatformView 是 FlutterView 的 subView。源码中的 embeded_view 是我们真正提供给 Flutter 的 Native View，它会传递给 FlutterTouchInterceptingView 的构造方法，成为其 subView，FlutterTouchInterceptingView 又是 ChildClippingView 的 subView。FlutterTouchInterceptingView这几个 view 中，FlutterTouchInterceptingView 是 Flutter 用来控制和处理 PlatformView 事件的关键。Flutter 需要有这个一个View 来拦截事件，因为事件毕竟是从 Native 传递给 Flutter 的，而 PlatformView 本身也是个 Native View，如果不对作用在 PlatformView 上的事件进行拦截的话，PlatformView 自身就会消化掉事件，而 Flutter 侧则感知不到也没法控制了。FlutterTouchInterceptingView 的 frame 和 embededView 保持一致，并作为其 superView，根据 iOS 的事件传递规则，FlutterTouchInterceptingView 会先接收到事件。由注释可知，FlutterTouchInterceptingView 实现了两个能力：一是它会延迟或者阻止事件到达 embededView；二是它会将所有的事件直接转发给 FlutterView。而这两点，分别是由 DelayingGestureRecognizer 和 ForwardingGestureRecognizer 这两个手势来完成的。DelayingGestureRecognizerDelayingGestureRecognizer 需要延迟其他事件响应，并且将除了 ForwardingGestureRecognizer 之外的其他手势都失效。DelayingGestureRecognizer 是添加在 embededView 的 superView（FlutterTouchInterceptingView） 上的手势（Gesture），之所以能够起作用拦截 embededView 的手势和事件，原因在于 iOS 的手势识别优先级高于普通的事件响应，且响应链一旦确定，每次事件响应，整条响应链上手势的 delegate 方法都会被调用，用于确定最终可以识别的手势。如下图，如果触摸了 View4，确定 View 4 为最佳响应者，则从 View4 到 rootView 上的所有手势（gesture2、gesture3、gesture4、gesture5）的 delegate 方法都会被调用。ForwardingGestureRecognizerForwardingGestureRecognizer 的实现就很简单了，它重写了事件的相关处理方法，将事件直接转发。因为 PlatformView 也作为 Flutter Widget Tree 的一个节点，事件转发到 Flutter 之后，遵循 Flutter 的事件处理机制，和其他手势一起在竞技场（Arena）中角逐是否能够响应。最终如果竞争成功，事件该由 PlatformView 来响应，则 FlutterTouchInterceptingView 的 releaseGesture 方法会被调用，DelayingGestureRecognizer 手势会被置成 Failed 状态，其他事件就可以开始响应。相应地如果竞争失败，那么 FlutterTouchInterceptingView 的 blockGesture 方法会被调用，DelayingGestureRecognizer 手势会被置成 Ended 状态，这表明事件被它响应并且完成了，其他手势或者 View 响应者就不会再响应该事件了。解决事件分发问题由上面 iOS 上的的事件原理可知，Flutter 主要是通过 DelayingGestureRecoginzer 和 ForwardingGestureRecoginizer 这两个手势来干预和控制 PlatformView 上 Native 的事件分发行为。所以可以想到，如果没有这两个事件，事件的响应又会和我们熟悉的 Native 流程一致。所以想要自定义 PlatformView 事件分发，在 iOS 上我们可以这么做：根据需要设置 PlatformView Widget 的 hitTestBehavior 参数；重写 PlatformView 的 pointInside 方法，在里面增加控制 Flutter 这两个手势的逻辑。因为 hitTest 寻找最佳响应者的过程一定在响应链响应之前，所以此处对 Flutter 手势的处理，不会影响事件转发给 Flutter 后的处理逻辑。具体到直播互动场景来说，为了能让事件在大多数情况下能够被互动层下面的组件响应，在 Flutter 侧 PlatformView Widget 的 hitTestBehavior 需要设置为 PlatformViewHitTestBehavior.transparent，目的是为了让 PlatformView Widget 之下的 Flutter Widget 可以响应事件。重写 PlatformView 的 pointInside，如果透明度判断认为该由互动层来响应，则禁用 Flutter 的这两个手势；如果不该由互动层响应（即该由其他 Flutter 组件来响应），则恢复这两个手势响应，不影响正常的逻辑。相关实现代码如下：因为 DelayingGestureRecoginzer 和 ForwardingGestureRecoginizer 这两个手势是定义在 FlutterTouchInterceptingView 中，而 FlutterTouchInterceptingView 是我们互动层 Native View 的 superView，所以代码中的 self.fluttterForwardGestureRecognizer 和 self.flutterDelayingGestureRecognizer 可以通过反射、循环遍历 superView 的手势列表来获取到。关于 Android 上的处理因为 Android 上 PlatfromView 采用了 VirtualDisplay 方案实现的，所以 FlutterView 和 PlatfromView 并不是真正处于同一个 ViewTree 中，因而在这个问题的处理上面和 iOS 略有不同，但原理相通。这里简单的说一下Android 上面的情况。PlatformView 原本的设计中是由 FlutterView 接收 Android 的原生 TouchEvent，然后转化为 Flutter 中用于事件处理的 Event，再分发给 Flutter中 的 Widget。当 PlatformView 的 Widget（AndroidView）接收到事件后，会再次将事件转化为 Android 的 TouchEvent，然后转给 Native 的 PlatformView 实现 View。如图：我们可以在 FlutterView 外面再套一层用于事件处理的 View（EventInterceptView），该 View 会优先接收到事件，然后根据实际需要，决定事件转发给 FlutterView 还是 PlatformView。如图：通过上述方案，我们在 iOS 和 Android 两端都可以做到在 PlatformView 互动层中实现透明度判断逻辑，并交给正确的响应者（Flutter 组件或者 Native View）来进行事件响应。使用 PlatformView 也让我们最大限度地复用了直播互动层背后对应的一整套解决方案，业务能力和使用体验都达到了和 Native 原生实现一样的效果。写在最后PlatformView 提供了在 Flutter 页面中嵌入 Native View 的能力，方便了很多业务场景和功能的实现，但 PlatformView 技术也还存在一些问题，例如使用了 PatformView 在某些场景下可能会导致图片、视频的纹理错乱等。闲鱼在直播业务中第一次在生产环境中使用了 PlatformView 技术，也解决了一些已知问题，但仍有很多问题是我们还没有发现和解决的，后续我们也会继续在这方面进行研究，探索使用 PlatformView 的最佳实践！

原创 淘系技术 淘系技术  2020-07-30项目一项目名称｜Rax开源时间｜2016.10.16项目地址｜https://github.com/alibaba/rax所属领域｜前端核心技术｜超轻量、高性能、前端解决方案、UI渲染｜多端（Web/小程序/Weex）开发项目介绍 可实现什么Rax是一个可支持同时开发Web/Weex/小程序多端的框架。使用Rax可以一次开发，多端运行，解放重复工作，专注产品逻辑，提升开发效率。项目介绍 可用于哪些场景服务于整个集团的 Web/Weex/小程序业务开发方，适用于一套代码开发后投放多端的场景，更可为其提供PHA/PWA/SSR等能力，能够极致提升前端交互体验。项目介绍运行环境：Web/Weex/小程序/Node开发语言：JavaScript开源协议：BSD License项目介绍 架构图社区活跃度contributors：85commits：5823目前成果Rax 是阿里巴巴开源的，用于构建通用应用程序的渐进式 React 框架。开源至今，收获6.6k Star，Rax在2019天猫双十一中得到全量使用，带来了更酷炫的端上能力和更极致的 Web 体验。Rax小程序目前在集团内已广泛使用，覆盖20+BU，累计落地小程序数量200+。团队介绍我们是「阿里巴巴淘系前端终端框架团队」，定位于架构的角色，我们负责为业务部门提供底层的基础设施保障以及提高开发效率的工具和框架，并且持续地探索前沿技术。目前团队主要集中于维护Rax和ICE两款开源项目。加入我们📮：xianyong.yxy@alibaba-inc.comhttp://mudu.tv/watch/4297536（视频讲解）http://mudu.tv/watch/4457778（视频讲解）           项目二项目名称｜飞冰（ICE）开源时间｜2018 年项目地址｜https://github.com/alibaba/ice所属领域｜前端核心技术｜框架、工具、微前端项目介绍 可实现什么飞冰（ICE）是一个企业级的中后台全方位解决方案，具体如下：1. 研发框架 icejs：通过 icejs 研发框架提供完整的标准化的 React 应用开发模式和最佳实践。2. 研发工具 iceworks：通过 Iceworks 提供了可视化辅助和代码编辑辅助的手段，提高您的开发效率及体验3. 微前端 icestark：面向大型工作台的微前端解决方案，通过引入框架应用和子应用的概念，框架应用负责系统整体布局以及子应用的注册、加载与渲染，同时在设计原则上约定「子应用尽量保持跟传统单页面应用一样的开发体验」，保证子应用自身可独立运行、存量应用可快速迁移适配、增量应用跟传统方式开发体验一致4. 工程工具 build-scripts：高度可扩展的工程解决方案，通过微内核 + 插件的设计原则，所有核心能力通过插件承载，支持不同体系的工程构建。项目介绍 可用于哪些场景ICE 主要服务于中后台应用场景，已经在淘宝、天猫、飞猪、菜鸟等十多个 BU 和社区的众多项目中落地使用，通过一站式解决方案以满足各种中后台和垂直域的应用场景需求。项目介绍运行环境：浏览器、Node开发语言：JavaScript开源协议：MIT项目介绍 架构图社区活跃度contributors ：62commits：447目前成果飞冰（ICE）是阿里巴巴开源的前端研发一站式解决方案。开源不到两年，共收获15.4k Star，成为这个在领域增长最快的阿里开源项目。自2018年开源以来，持续得到了业内广大的关注，并被国内众多个人与公司在其中后台项目中采用。ICE 通过提供海量的可组合可复用的物料，与配套研发工具 ICEWORKS，不仅将原本复杂的开发环境配置降到零难度，同时ICE 一站式解决方案极大程度的降低了非专业前端的开发门槛，提升了研发效率，降低了企业成本，因此 ICE 在社区得到了广泛的好评。团队介绍飞冰（ICE）项目隶属于阿里巴巴淘系技术部终端框架团队，主要为淘系业务提供架构支撑，面向社区开源的产品主要有中后台解决方案飞冰（ICE）体系、其中以研发框架 icejs、研发工具 iceworks、以及面向大型应用的微前端解决方案 icestark 等核心产品。加入我们📮：chenbinbin.cb@alibaba-inc.comhttp://mudu.tv/watch/4662084（视频讲解）http://mudu.tv/watch/4973371（视频讲解）项目三项目名称｜MNN开源时间｜2019.05.06项目地址｜https://github.com/alibaba/mnn所属领域｜人工智能 核心技术｜深度学习 推理引擎 Mobile项目介绍 可实现什么轻量级深度学习推理引擎，具有高性能、通用、易用的特点。项目介绍 可用于哪些场景MNN已经在阿里巴巴的手机淘宝、手机天猫、优酷、钉钉、闲鱼等30多个App中使用，覆盖直播、短视频、搜索推荐、商品图像搜索、互动营销、权益发放、安全风控等70多个场景。此外，IoT等场景下也有若干应用。项目介绍运行环境：iOS、Android、Windows、Linux、macOS开发语言：C/C++、Metal、OpenGL、OpenCL、Vulkan开源协议：Apache 2.0项目介绍 架构图社区活跃度contributors：43commits：637目前成果MNN是阿里巴巴开源的，一个快速，轻量级的深度学习框架。开源至今，共收获4.4k Star，MNN已经在阿里巴巴的手机淘宝、手机天猫、优酷、钉钉、闲鱼等30多个App中使用，覆盖直播、短视频、搜索推荐、商品图像搜索、互动营销、权益发放、安全风控等70多个场景。此外，IoT等场景下也有若干应用。团队介绍端智能团队是一支有理想有情怀的技术团队，我们致力于打造端智能算法工程体系，为开发者和消费者提供最好用的人工智能技术，推动商业智能化的快速发展。加入我们📮：yiliu.cyl@alibaba-inc.comhttps://mudu.tv/watch/4308076（视频讲解）https://mudu.tv/watch/4397479（视频讲解）项目四项目名称｜coobjc开源时间｜2019.02项目地址｜https://github.com/alibaba/coobjc所属领域｜iOS核心技术｜协程项目介绍 可实现什么Coobjc为objective-C和Swift语言提供了协程能力。支持await、generator和actor model项目介绍 可用于哪些场景Coobjc可以用于异步调用的场景，解决iOS中通过block调用的各种缺点。项目介绍运行环境：iOS开发语言：C、Objective-C、Swift开源协议：Apache项目介绍 架构图社区活跃度contributors：7commits：10项目成果coobjc 是手淘架构团队推出的能在 iOS 上使用的协程开发框架，目前支持 Objective-C 和 Swift 中使用。开源至今，收获3.7k Star，目前集团内有 7个 APP 接入，解决了手淘iOS客户端部分场景下的异步调用问题，使用同步代码写异步逻辑，代码更加清晰。

用户增长是一件个性化非常强的事情，淘宝在增长中执行的诸多策略或许拿到其他场景就完全没有效果。但另一方面，这些策略背后的思考路径和执行过程中总结的经验，是有参考意义的，有机会给读者在日常增长工作中带来一些提示。所以，本文不会出现太多实现细节，更多关注在策略制定背景和设计逻辑上。本文从我们对用户分层的定义开始，重点分享淘宝过去一段时间在“拉新”和“召回”两个方面的思考和经验。用户增长公式我们站在平台视角，根据活跃情况对用户进行区分。第一个层面是 MAU 和非 MAU，更细节的又各自有所区分。非 MAU 用户：即过去30天没有在平台出现过的用户，是用户增长流量引入的目标用户 。+ 潜在用户：非平台注册会员，从未有访问过我们的产品的人。+ 流失用户：此前已经成为平台会员，有过产品访问记录，但过去30天没有访问的用户。MAU 用户：如上图中着色部分，分为三层。+ 新增用户：顾名思义，是我们平台的纯新用户。就是从【潜在用户】转化而来的，平台用户纯增量。+ 召回用户：指回访的流失用户。是从【流失用户】转化而来的。+ 活跃用户：过去30天有产品访问行为，且当月又有访问的用户。实际上，按照用户活跃情况仍然能继续细分。例如，对流失用户还可以细分为：月度流失、季度流失和年度流失等。拆分了MAU的用户成分，再看MAU的数学描述，由三个部分求和而来：+ MNU：只得是本月MAU增量，就是上图中横线以下的部分，包括新增用户和召回用户。+ 上月新增用户留存：只上月的MNU本月有留存下来，转化为活跃的用户。上图中的r指的是留存率。+ 上月活跃用户未流失：上月的活跃用户，本月仍有回访，未流失的用户。上图中的 λ指的是流失率。通过对用户成分的拆分和用公式描述MAU，我们基本能够找到MAU增长的抓手是什么。而本文则会重点从MNU入手，介绍淘宝在MNU引入上的一些策略。流量引入体系淘宝用户增长的流量引入体系由三纵两横构成。三纵：即业务流程维度拆分的引流的三个阶段 。+ 用户触达：分为二方和三方两种用户触达方式，是最外侧直接接触目标用户的系统。+ 连接体系：目标用户被触达后，通过转化，将成为MAU用户，连接体系负责高效稳定引入用户。+ 用户承接：用户通过连接体系进入平台，用户承接将有效帮助用户落地，为接下来的用户成长打下基础。两横：即业务应用之下的基础设施和平台建设。+ 用户总线：主要负责域内域外用户信息互通和信息流转。+ 用户平台：分别针对【人】和针对【行为】，是以数据为核心的两个基础设施系统。本文后续内容个，将针对上述的五个部分分别介绍技术策略。对笔者认为更具有参考意义的部分，会用较大篇幅，其他的则一笔带过。策略1 —— 智能投放三方流量引入的主要手段仍然是广告投放，但有别于常规广告投放，用户增长广告投放目标的目标是：高质量MAU增量。上图为常规广告投放流程。广告主会以不同的采买方式够得渠道方的流量，通常PD/PDB/RTB 等类型，而不同的流量类型在质量上也会有所区别。最终，广告主将以 CPM 或 CPC 等结算规则进行结算。1.用户访问渠道后，渠道将会向广告主发起竞标请求；2.广告主通过对流量的识别分析，给出反馈，决定是否投放；3.如果选择投放，渠道侧将会按广告主的要求给用户进行素材曝光。至此，最传统的广告投放流程就结束了。而上文提到用户增长的广告投放目标是高质量MAU ，其中【高质量】是一个很重要的限定。所以，近年来渠道方提供了更先进的结算规则 oCPX ，即【可优化的 CPX 】。通过这种方式可以在成本一定的情况下，很大程度上提升广告主获取到流量的质量。即增加了上图中虚线一下的路程。1. 当渠道触达了用户（例如，用户发生了素材点击），渠道方会通知广告主；2. 广告主接到通知后，启动对该用户的跟踪。一旦该用户访问广告主的产品并完成既定行为，广告主将反馈渠道方；3. 渠道方把广告主的这次反馈作为素材推荐模型的正反馈，对模型进行优化。在这个流程中，我们认为有两个核心，这两个核心也是【智能投放】的重点：1.对人的认识。识别出用户增长的目标用户，做出准确判断，精准触达用户。2.对素材的认识。在认识人的基础上，叠加对素材的理解，做出高效的素材个性化推荐，提升触达效率。流量筛选（离在线人群服务）在日常广告渠道对接中，我们发现不同渠道的技术能力和技术策略有非常大的差异。有些渠道技术能力非常强，能够对用户做出精准的识别，能非常好的帮助广告主进行精准触达；而更多的渠道不具备这样的技术能力，或者其关注重点不在于此，广告主必须提供流量筛选能力。在这样的背景下，我们整合了大量数据源，建立起用户增长目标用户档案。一方面协助不具备流量删选能力的渠道进行精准的用户触达，另一方面为素材推荐提供数据支持。工程上，提供离线和在线两种服务。通过工程手段把流量筛选规范化，每一个接入的渠道都会通过流量筛选服务进行精准用户触达。流量筛选作为渠道对接的一个必选流程，大大提升流量质量，降低了广告投放的渠道成本。海量素材（素材个性化服务）除了人的问题，素材的问题更加棘手。常规的广告投放中，素材推荐往往发生在渠道方的系统上，很少有渠道会允许广告主自主进行素材推荐。这就要求渠道方要对广告主平台上的素材进行深刻理解，才有可能做出高效的推荐。但事实情况并不乐观，即使是技术能力最好的一些渠道系统，也只能允许广告主上传几张素材图片而已。素材曝光就是从这几张素材图片中选择，可以想见效率之低。根据我们的经验，这些素材的曝光点击率一般都在2% 以下。提升素材的曝光效率，一个基本条件就是素材数量。事实上淘宝有强大的素材能力，我们有海量的商品、权益和品牌信息；并且我们的设计师有丰富的经验，知道什么样的模板效率更高；更有先进的NLP算法支持我们做出高效的文案，这些元素通过工程能力的组合可以产出海量素材。此外，基于对素材背后不同元素的深刻理解，淘宝的个性化推荐也非常强大，能够给出非常高效的素材推荐。所以，在素材问题上，一方面对允许广告主自主推荐的渠道，我们接入自己的个性化推荐算法。基于背后的用户档案和海量素材，最高可以做到10%以上的曝光点击率。另一方面，对于不允许广告主自主推荐的渠道，我们正在寻求一种更先进的合作方式，即我们通过海量素材服务，赋能渠道推荐系统，实现高效用户触达。这也需要我们和渠道的共同努力。举个例子上图展示的就是我们在“抖音”平台上尝试的智能投放案例。图中三张素材图片都是通过工程能力，结合货品和设计师的模板合成而来的。而图示用户所看到的“女士冬装”也是基于算法对用户和素材的认知，进行的个性化推荐。策略2 —— 矩阵优势二方流量引入指的是利用自己平台上的多个产品，互相供给流量增量，形成流量矩阵。二方矩阵有非常明显的优势，假设平台上有 A 和 B 两个产品，产品A的活跃用户，可能是产品B的潜在用户。在这样的背景下产品 B 可以把服务输出到 A 上，与 A 的产品形成深度合作。在产品 A 触达用户，转化用户，再通过设计把用户转化到 B 上。用户天生具备对 A 产品的信任，所以B的触达和转化效率就会更高，在不脱离产品 A 的前提下，完成用户对 B 服务的转化，将大大提升后续用户成为 B 产品用户后的沉默成本。通过这种方式形成流量矩阵，矩阵中的流量质量较广告投放方式的流量高出很多。无疑“小程序”技术是跨产品服务输出，深度整合的最佳选择。“小程序”技术与此前大热的 RN 或 Weex 这类界面方案在某些程度上相似，但我认为其本质不同。类 RN 技术是一种在完整性和性能稳定性上经过了优化的界面方案，是对H5方案的优化；而小程序则不同，是在开发效率和灵活性上大大提升的 App 开发方案。“小程序”不同于界面方案，具有完整的 App 生命周期和 App 级的技术能力，这些都是服务输出和深度整合的必要前提。当然，二方矩阵的约束条件较多，也不是所有人都聚被建立流量矩阵的条件，所以本文不展开详述。策略3 —— 拉承一体引流与成长之间的空白用户触达后的引入是整个流量引入过程中最重要的一个环节，也是优化空间最大，抓手最多的环节。上图是我们梳理出用户从触达，到引流，最后成长的漏斗。不难发现，引入流程的终点是产品激活，也就是用户完成下载安装，并启动了 App。用户成长的起点是登录，也就是获取到用户信息的时候，而这两个流程之间还有一个巨大的空白——登录率。流量引入把用户输送到一个场景后，用户并没有马上进入成长流程，而是在注册登录这一步损失掉了大部分。关于登录率的问题，经过分析发现并没有太多抓手可以进行优化。用户引入后是冷启动状态，似乎只能通过通用的权益或玩法刺激用户进行注册登录。为了改变这个局面，我们把用户流量引入的技术流程进行重新设计。收口流量首先是规范化流量入口，通过制定 App 启动链接标准，封装 JS 和 Native 两个链接 SDK ，基本做到全量手淘 App 启动流量标准化，做到了数据埋点，跳转行为和用户心智的统一，为接下来进一步的制订运营抓手提供了技术基础。用户总线用户登录率缺少抓手的最大问题在于，用户从域外引入域内后还原为一个冷启动状态，用户在域外的行为记录无法在域内关联，进而执行有延续的承接策略。未解决这一问题，我们开发了“用户信息总线服务”。在用户数据视角，总线分为两个部分：+ 数据供给：当用户出现在站挖渠道，我们触达到用户后，就要向用户总线写入一条记录，记录用户在触达流程中的行为，包括但不限于：访问的商品，权益等。以设备为Key建立用户访问档案。+ 数据消费：用户发生激活行为时，承接应用通过用户总线获取用户在启动App之前的记录，进行连续性承接。充分发挥用户域外行为数据的作用，进行有针对性的引导。通过用户信息总线，把用户引入和承接连接起来，弥补之前流量引入和用户成长之间的登录率空白。举两个例子上图中的例子是我们在域外以权益方式触达用户，并刺激用户激活手机淘宝。当用户在域外访问了活动页，看到这个“15元手机淘宝专享”权益的时候，活动页已经把用户的信息写入了用户总线。随后，不管是直接点击链接唤起手淘，还是从商店下载安装点击ICON启动手淘，手机淘宝的首页都会从总线中得到信息，从而在固定区块还原出这个权益，让用户有一个延续性体验。第二个例子是在域外向用户投放了一个活动，这个活动展示了一个“5元话费”权益。不论用户通过何种方式激活手机淘宝后，手机淘宝内置的分流器都会通过用户总线中记录的信息，把场景还原到这个“5元话费”的活动上，而不是停留在首页。策略4 —— 长周期运营用户运营长周期运营，是我们对“用户长生命周期运营”的简称，也是对“用户运营”的一种解读。我们理解的用户生命周期运营是：从用户长生命周期视角， 以数据为基础， 结合算法能力， 驱动用户成长的运营方式非常重要的一点，用户运营的区别在于运营目标的改变，而非运营对象的改变。在这种运营方式下，我们的关注点从行为漏斗，变成了用户生命周期的跃迁。本质上是希望用户在我们设计的成长体系中不断向上发展。过去关注重点是用户行为漏斗上的效率，而现在这个目标成为了手段。全链路触达用户运营的一个具体案例就是——全链路触达。我们在用户动线的每一个节点上设置触点，这些触点的目标不是驱动用户走向漏斗的下一个节点，而是由用户生命周期干预系统统一控制，驱动用户在生命周期之间跃迁。首先定义出用户在平台上的生命周期节点。整合用户行为数据，利用算法能力计算出用户在生命周期中所处的位置，并预测用户跃迁到下一状态的概率。当识别出用户处在跃迁边界时，干预系统将通过全链路的触点向用户强调响应的货品、品牌、权益等信息，驱动用户快速跃迁。例如：当我们预测到一个用户长时间没有核心行为发生，即将流失的时候，就会通过上述方式，使用定向货品去刺激他，产生购买行为。我们用“临门一脚”形容这种驱动用户跃迁的运营方式。策略5 —— 平台提效提效问题是工程团队最擅长解决的问题之一，我们擅长以技术的方式替代人工，把过去需要两周完成的工作提效到15分钟完成。然而，在接触用户增长的不长时间里，我发现这种以提效为目的的系统建设只是对生产工具的改进，只能带来量变。处在一个数据驱动和人工智能快速发展的背景下，技术团队需要承担更多，需要改变我们的生产力水平，引入更先进的方法论，给业务带来质变。提升生产力，要改变的是整个工作的方式方法和流程，这就要求技术团队不仅仅能在单点上做好工具，提升效率；还要进一步把各个单点串联起来，形成工作流，把更先进的用户增长理论实体化，流程化，变成日常工作的默认选项。例如，我们认为“上卷和下钻”是数据分析中更加先进的方式，所以我们通过技术手段把这两项操作工具化。用户可以使用工具，快速对数据进行上卷或下钻，高效完成分析工作，拿到分析结论。另外，我们认为A/B实验是快速验证方案效果的最佳手段，所以开发了实验平台，系统化解决了数据可信度，流量分桶等等基础问题。所有业务都可以在平台支持下快速实验，拿到结果。然而，工具做完了，效率提升很大，但有一个问题始终不能解决：如果我没有意识进行数据深入分析，也就不会使用“上卷和下钻”的工具，如果我没有意识要验证决策，也就不会在产品发布流程中设计实验。所以，工具和单点优化提升了本来就要做这件事的人的效率，但并没有把这个先进的理论推广，甚至普及。要解决这个问题，就需要我们通过技术手段改造整个产品的发布流程。流程上形成“数据采集-基本分析-深度分析-验证决策”的闭环，把“上卷/下钻”分析和“A/B实验”作为默认选项植入流程，使整个流程进入一个更先进的阶段。用户增长团队的能力升级 —— 数据为王除了技术策略，最后想分享的是我所理解的用户增长团队的能力提升，尤其是像我所在团队这种从常规的工程技术团队转型而来的用户增长技术团队该如何提升能力。一般说来，传统的工程技术团队最重要的技能是“编码技能”，最重要的理论是“工程和架构理论”。最初我们在这两方面都比较差，而前期更多的是编码技能的提升，随着编码技能提升能接触到更多核心系统，承担更重要职责，所以逐渐在软件工程和架构设计的理论上有所提升。而在能力发展后期，理论和经验的提升将成为能力提升最重要因素。而用户增长团队则有所区别，在我的理解中，用户增长技术团队最重要的是“数据技能”和“用户增长”自有的一套理论，在这两方面的带动下，结合上工程技术能力，才能真正做好增长，真正体现出一个“用户增长技术团队”的差异性价值。而且，在用户增长能力提升前期，更快积累的是理论，用户增长理论发展时间相对较短，复杂性也远不如软件工程和架构设计。所以，前期了理论积累相对快速，而数据技能是需要每个人实打实的从0开始学习。能力发展后期，支撑能力提升的更是数据能力，因为在用户增长领域，需要我们能在数据中找到增长的机会和问题，在数据中验证决策，在数据中完成增长。数据技能非常重要，我在团队中始终对刚刚开始接触数据的成员有两个建议：解释趋势和关注分布。+ 关注趋势：选定一个需要关注的核心指标，建立其在时间维度的图表，关注趋势变化。通过各种手段试图解释趋势发生变化的原因，在解释原因的过程中就可以抽象出具有参考意义的方法论或是经验。+ 关注分布：关注核心指标在各个维度上的分布情况，找到分布不均匀的维度，不均匀本身就是机会或问题所在。通过进一步的分析，找到解决不均匀的方案，提出假设，大胆实验。5+1个策略，体现技术价值，改变增长局面以上就是手机淘宝在用户增长-流量引入方向上的几个技术策略，以及伯灵对用户增长技术团队能力升级的一些理解。

作者|手淘用户体验提升项目组出品|阿里巴巴新零售淘系技术部Weex 化的店铺性能优▐  背景店铺业务做为商家运营、营销的主阵地，是动态化方案激进的跟进者之一。2015年上线 Weapp 技术，就是在一码多端上的尝试。2017年，WeappPlus 的项目斐然崛起也和店铺有着千丝万缕的联系。没看错，就是 Weex 的第一个项目名。之后 Weex 如一阵飓风般刮过集团各大业务，或整体、或单页、或卡片的应用场景层出不穷。店铺作为第一批上线 Weex 的业务，承担积极的推动作用，甚至一度把客户端给做没了，客户端仅保留了店铺路由的逻辑。在页面渲染和呈现上，全业务、全页面都由 Weex 来承载。但是众所周知，Weex 技术在带来种种优点的同时，也有一个无法避免的短板。页面进入速度会变慢（相对于纯客户端页面而言），特别是店铺这种既需要复杂交互，同时还有三方 ISV 开放能力，单个页面的 js 超过 500K 的复杂业务场景。在结构上，店铺的分为 框架 - 子页 两部分：框架包含店铺名，心钻冠等级，顶部 tab 条，底部 tabbar 导航的能力。子页就是各个 tab 切换后的中间区域。首页就是屏幕中央的主要业务区域，可以通过 tab 完成多个页面间的切换。框架 和 子页，通过 embed 标签完成嵌套关系。同时为了让用户获得更大的浏览区域，引入了 Nested-Scroll, BindingX 等能力实现嵌套滚动，底色渐变等能力。最后店铺外投的 URL 形式众多，需要有能力支持各式各样的入口地址。综上，整个进店流程从链路上说可以分为三个阶段：路由，框架，首页。接下来，将从设计、分析、实现、上线等角度阐述整个优化工作的具体实现。希望能够帮助读者在优化自身业务时，有更多的方法。▐  开工★  优化开始的第一件事是什么？对，就是找把尺子。先确定好衡量的环境 和 数据口径，做到手中有尺，心中不慌。只有明确了标准，才能使工作的价值 更清晰、更准确、更容易 得被衡量。特别当兴冲冲得找老板汇报已经完成目标，结果一测发现还差一大截时，更能体会这条 tips 的重要。★  第二件 备好工具直接代码打性能日志（最简单也是最好用）有个小建议，同时输出时间戳 和 时间差。同时按一条主要的关键路径，把先后的日志按顺序串起来。SystemClock.uptimeMillis() 不推荐使用，请使用 System.currentTimeMillis() 。这样有个好处，当有多个系统交互，比如 前端 客户端java 客户端c++ 就在一条时间基线上，串起来看清晰很多。Systrace + TraceView + top + CharlesSystrace: 目标是跑满 cpu，这个在项目优化初期做一下，对整个流程有个宏观感觉。项目冲刺阶段做一次，重点突破。TraceView: 可多看看，找耗时方法很有效。top: 在遇到分析瓶颈的时候，不妨试试，往往能看出一些线索，比如 USER CPU 占用偏高，重点分析是否和多线程场景 和 检查 c++ 任务调度。Charles:在定位到底是 网络慢 还是 处理慢 的问题上，往往一针见血。所有工具都是手段，最重要的还是对 流程的理解 和 业务的熟悉。adb shell input tapinput tap 这个简单的特性，往往能化腐朽为神奇，减轻偶现问题的修复验证工作。▐  技术选型回忆下前面提到的店铺渲染三大阶段：整个优化工作都是围绕这三个阶段展开。这里进一步对三步进行细化，见下图。★  框架 - 子页 并行渲染在上述店铺三阶段中，可以发现 店铺框架 和 店铺首页，作为两个独立 WXSDKInstance，在整体流程中耗时占比较大。很朴素地就考虑到能不能将这两步并行起来。优化前由前端代码通过 embed 标签，直接就能确定了「子页」和「框架」嵌套关系 和 嵌套位置。流程相对简单。在引入并行渲染的优化后，事情变复杂。由客户端并行承载两个页面的绘制工作，再选择合适时机，把两个页面组合起来。从流程上来，「框架」和「子页」的 weex 渲染任务会并行进行。并且同时取消了「子页」的 loading，在用户交互感知上少了一个等待的过程。体感上提示很明显。★  数据请求托管经过分析，传统方式下，一次店铺打开，共有五次数据请求。虽然前端可以利用 Promise 技术做并发，但是依然存在等待数据的状态。针对上述五次请求，具体场景不同有不同的优化策略，其基本方向还是数据请求合并，并发请求，异步请求。过程中的注意点：1. 最优先考虑的还是数据合并，将多个数据请求合并成一个，最简单且效果最好。2. 并行数据请求，复用的是 weex 实例创建的时间，越早请求，效果越好。3. 异步请求的场景，远程数据获取 和 前端数据拉取 的先后关系不定，要注意数据缓存的设计。4. 对于所有处理数据的weex 模块，所有方法都不需要主线程执行。★  JS-Bundle 提前准备总所周知，优化 JS-Bundle 的加载速度，是提升 weex 业务体验最有效和最直接的抓手。 针对绝大多数 weex 场景，通过手淘现有Cache 技术完成 JS-Bundle 的客户端侧存储，已经可以很好地支持业务。但对于店铺这个 pv 亿计体量的业务还略显不足。主要体现在：到达率无法准确把控更新时间较久磁盘加载稍慢。针对上述几点改进空间，并且结合业务特点定制了 JS-Bundle 端侧存储能力。主要特点：1. 除首次纯新安装场景，其余情况总是优先返回本地缓存的 JS-Bundle。同时根据两次访问的时间差，判断是否要刷新本地缓存。且遵循 http 的 cache-control 策略。2. 客户端侧底层存储使用统一存储，在手淘打开后的首次访问时，读数据很慢，甚至在高端机上比走网络还慢。所以选取合适的时机做预热。3. 内存级缓存。内部使用 SoftReference 包裹数据体，防止 OOM。同时在 切后台 和 接到低内存警告 的时候，触发对象释放机制。在引入 JS-Bundle 提前准备后，用户最直观的感受就是整页白屏 loading 等待的时间大幅缩短，甚至页面转场完成时，首页就已经渲染完毕，避免了用户视觉上的空窗期。★  上下游优化再提几个比较容易忽略的优化点。Weex Module 的调用每次 module 调用虽然耗时很短，但是因为每次都要等待 WXJSBridge 线程空闲，并且获取到 cpu 时间片才能执行。所以常常会出现方法调用耗时 10ms，等待耗时 300ms 的现象。这点主要从前端优化。一方面尽量减少 module 调用，特别是关系到主链路的渲染流程中的 module 调用。另一方面，将不重要的 module 调用延后。例如店铺就将部分 ut 埋点逻辑，做了延后处理。流程上看，通过减少 JS-bridge 的任务调用，减少线程切换时间，从而减少 weex 渲染 view 的上屏时间。最终减少用户可流畅交互时间。图片预加载针对图文较多的业务，在客户端获取到数据接口后，直接利用图片库的预请求能力，做图片的加载。硬件加速部分手机厂商向公司开发了 API，允许在特定场景下调升 CPU 频率，从而实现加速的效果。最后也是最简单的一点减少 JS-Bundle 的文本大小，是最直观的提效做法。优化业务的前端代码，去掉过期的逻辑，去除无用判断，去掉冗余的依赖。店铺业务大约减少了 80K+ 的 js，获得了大约 40ms- 的性能提升。综上：所有优化点上线后。整个流程链路以下图流程经行。通过店铺性能调试工具可以实时验证观察各阶段的渲染效果。Web 前端性能优化实践前端 Web 页面的性能给大多数人的印象可能还停留在几年前的加载白屏、滑动体验差等，但是到了现在这个时间节点，必须停下来重新思考下现有的业务发展、技术开发方式等，最终我们觉得有理由并且有能力从全链路的角度来看前端 Web 页面性能，最终突破这一刻板印象。▐  优化思路在进行优化前，梳理了几个原则：1.明确目标：整体页面端内首屏时间 1.2s，端外首屏时间 3s，低端机首屏时间小于 2s，可交互时间小于 2.5s，可流畅交互时间小于 3s。性能优化无止尽，定好目标才能有的放矢。2.梳理端到端系统化每个环节：梳理宏观的每个环节，再具体分析到细节点。3.数据驱动性能优化：线上收集各个环节的性能数据，便于分析。4.投入产出比 ROI： 不要迷失在性能优化中，思考技术对于业务的价值。★  各环节耗时分布这张表统计了从点击开始到渲染完成各个环节的耗时分布，各个最低数值代表理论可行值，最大值代表线上真实数据耗时，因此可以清楚的知道哪个环节现阶段是最差的，然后进行针对性的分析和优化。最终会不断的调整这张表的数值分布，然后看哪个阶段还能继续优化，形成优化并数值调整 -> 线上验证 -> 再优化调整的正向循环。▐  渲染方案目前基于线上数据验证以及线下对比，如果一个页面资源（包括文档 HTML、js 资源）都是走缓存的形式，整体页面的性能、体验会比较好，对文档、资源的缓存非常关键。因此整体的渲染方案会最大限度的利用缓存，设计如下：1.袋鼠服务：面向前端的数据接口合并服务，模块直接取数据渲染，保证了页面渲染的一致性2.统一渲染页数据驱动页面渲染，所有页面的核心逻辑一致保证模块渲染与页面的分离，确保统一渲染页被稳定缓存3.页面渲染策略：区别首屏/非首屏渲染，保证首屏能快速渲染4.模块缓存池：解决所有页面模块缓存问题▐  优化系列基于性能优化的手段，目前我们可以主要分为以下三种：★  加载对于一张页面的加载，我们要做到 4 个 1：一个共享文档一个首屏关键 js一个首屏业务 combo 资源一个全局共享缓存池主要罗列了以下几个优化手段：1.按需加载：某些特别大的 js 资源可以按需加载，比如安全脚本大小会有 500K+2.分环境加载：由于目前端上 es6 环境支持的程度已经较好，因此可以在绝大多数场景去除 babel-polyfill 的依赖3.资源缓存：端上 combo 资源按版本拆分缓存资源缓存1.端上共享缓存池，缓存 combo 后的资源到内存以及缓存解 combo 后的缓存到内存/磁盘，这样在二次访问时达到重复利用的目的。2.优化资源传递消耗，内核之间只需 Stream 流形式传递，避免了类型如 byte -> String -> byteStream 之间的类型转化消耗。优势：1.无需推送 ZCache，共享单个级别的资源2.性能好：缓存 20-100ms vs网络请求 200-300ms+3.优于 httpcache，可以命中更多的 combo 组合劣势：1.会占用一定的内存来换取资源读取上的优势★  渲染对于渲染，我们要做到首屏尽可能快的渲染完成，主要罗列了以下几个优化手段：1.首屏/非首屏渲染，更细粒度的按行懒加载：对于一整张页面，我们希望能优先渲染首屏，可以尽快的呈现内容让用户看到。有时候首屏的内容也会非常长，还可以做到按行级别的控制懒加载渲染。2.js bridge 通道优化：端内需要有较多的与 native api 交互，通信效率也至关重要。js bridge 通道优化核心：解决JS引擎与内核 Java 层同步 IPC 通信阻塞问题优化前使用 prompt 方法进行 jsbridge 通信1.JS 引擎与内核 java 层同步IPC通信，阻塞 Render 线程，通信耗时：中/低端机100-200毫秒，导致延长渲染时间2.引发内存泄漏问题3.引起渲染引擎重排版，平均耗时 100ms 左右优化后使用 onConsoleMessage 方法进行 jsbridge 通信1.JS 引擎与内核 java 层异步IPC通信，不阻塞 Render 线程2.不引起渲染引擎重排版★  数据数据 Prefetch & 时机提前核心：解决数据/渲染并行执行，尽可能的减少数据请求时间1.利用了容器的初始化时间，进行并行数据请求，从而节省数据的请求时间2.进一步提前数据请求时间点到点击最终的节省时间 = 容器路由时间(找哪个容器渲染) + 容器启动时间 + 容器初始化时间 + 页面框架渲染时间中间过程优化核心：解决子线程与 UI 线程的阻塞问题，以及中间环节没必要的类型转换优化前优化后最后从宏观到微观。性能优化之初一定要有宏观视角，对整个框架的运行情况，要有做到心里有数，对问题进行全面分析，然后再对瓶颈进行拆解，拆解后的子任务也不能孤立去看，一定要放在系统内，综合选择最优方法。建立长期管控机制。性能优化成本也非常昂贵，性能优化在某种程度上，与其说是技术人员秀肌肉，不如说是还债，技术债（当然，真正有技术挑战在一些特定条件下做极致优化的情况不在此列)。从最初的技术方案设计，业务压力下充忙上线，线性的功能堆积，对现有架构设计的妥协等多种原因导致了性能问题的。如果在上线之初就能考虑到对性能的影响，好好设计方案，这时的成本是最低的。然而，一切依赖人的行为的机制都是不靠谱的，老虎也有打盹儿时。要减少运动式的做性能优化，需要建立一个依赖于客观数据长效的监控机制，这也是我们正在探索的方向。路漫漫其修远兮，吾将上下而求索。

闲鱼技术闲鱼在 2017 年便引入了 Flutter，是国内第一个引进Flutter的团队。当时的 Flutter 还远未成熟，行业内也没有把 Flutter 放入已有工程体系进行开发的先例。这两年，Flutter 也逐渐在其他企业里落地，但同时也不断有质疑的声音发出。甚至有传言表示“闲鱼的新业务已经放弃 Flutter”、“相信闲鱼遇到了很大的难题”......那么，作为 Flutter 先驱和探路者，闲鱼在过去几年的摸索过程中遇到过什么阻力？踩过什么“坑”？对于相关技术开源的态度是怎样的？对于以上的一些传言又是怎么看待的呢？针对这些疑问，闲鱼代表团队分享了一些开发者背后不为人知的小故事。希望能让大家从背后人的维度去看闲鱼团队，理解他们的初心，以及这个过程中遇到的挑战、挣扎、付出的努力、得到的教训。1. 在新技术落地过程中，遇到过什么阻力，有什么避免“踩坑”的经验？闲鱼从2017 年开始接触Flutter，最初是一个自上而下的尝试。一方面，从创新团队的角度来看，需要以战养战，为团队储备更多的人才；另一方面，希望切实解决当时团队人难招、产能低的问题。在前期的调研过程中，最初是希望将Flutter 作为闲鱼国际化版本的主要技术选型；由于后续业务上的决策，导致该项目夭折，因此希望将Flutter 引入主App 中进行探索。在尝试之初，从组织、配套工具，到架构侧都没有准备得特别好，项目落地面临很多困难。在团队抽调的突击小组中，有大量的研发人员非常不看好这项技术，大部分研发人员并不认同Flutter，没人知道这件事情该怎么做。当然，从2017 年开始，闲鱼在多个技术方向都进行了类似的尝试，实践证明，创新的确比想象难得多。时间来到2020 年，回首过去尝试的多个方向，目前只有Flutter 得到了阶段性的胜利，并作为闲鱼的技术品牌为大家广泛熟知。这里面所经历的艰难险阻只有当时参与过从0 到1 过程的研发人员才能体会。由于Flutter 落地过程的艰辛，其间也有不少同事离开了闲鱼，幸好后续有更多希望这件事情成功的研发人员加入，大家一起努力至今，才有了今天看到的成果。我们也非常感谢在此过程中付出过努力的每一位同事，不管今天他们是否还在闲鱼，是每一位同事的努力让美好终于发生。从Flutter 落地的过程中总结出以下观点，供大家参考。从布道者的角度来看，需解决以下两方面的问题：向上，需要得到更多决策者的支持；向下，需要减少开发者进入的成本。关于决策者链路，Flutter 在闲鱼落地的过程中没有上层的阻力，因为开始是一个自上而下的决策，但在后续的推广和落地过程中，从更大的组织视角去看，比如构建AliFlutter 组织、构建Flutter China 组织，这些是一个自下而上的行为。在这个过程中，闲鱼选择的是“农村包围城市”的理念。先从社区出发，发现同路人，找到不同公司、不同业务的价值，再回归内部，影响决策者。前期不管是构建集团Flutter 的兴趣小组，还是正式有了AliFlutter 的虚拟组织，都是找到同路人，探讨和争论其技术价值的过程，这个过程可以请各团队的关键决策者躬身入局。通过讨论又能帮助团队进行更深入的思考，并为Flutter 提供一个阶段性的明确定位——面向研发效能提升，构建新的研发模式，快速支持小前台业务落地。将该目标与阿里巴巴集团大的研发效能目标进行连接和推动，即可顺利地推进该项目。关于开发者成本，首先是自己团队的开发者成本。在任何新技术落地的前期，都有一定的成本，需要度过这个阶段才能得到收益。因此，在开始阶段，必须尽量降低落地成本。在项目之初，最好以小规模团队的形式进行尝试，同时新技术在前期架构落地中需要重点考虑过渡阶段的效率问题，不要断崖式地迁移。闲鱼在初期没有充分考虑这个问题，导致工程侧开始的架构并不合理。后来，闲鱼重点围绕混合架构，以Flutter 开发小组与原生开发小组的协作模式进行设计和落地后，该问题得到了有效解决。例如，前期闲鱼就重点解决了原生项目无法独立打包的问题，极大地解决了当时研发效率的阻塞问题。混合栈（Flutter Boost）的重新设计，也解决了当时由于Flutter和原生生命周期不一致带来的一系列复杂问题，保证了开发调试的稳定性。如果团队仍有余力，可以考虑对开源社区进行一些力所能及的输出。闲鱼先通过发布文章，再通过部分开源项目以及内部开源的形式，给Flutter 社区和阿里巴巴集团提供了一些帮助。闲鱼相信“日拱一卒，功不唐捐”，虽然依然还有很多问题需要解决，但是随着更多开发者的进入，大量的问题终究会被解决。2. 闲鱼对开源项目的态度是什么？未来会把大量文章中提到的技术开源出来吗？闲鱼在2018 年完成Flutter 主链路的部分改造后，发现在落地过程中有很多问题，而且Flutter 社区并没有给出很好的解决方案。从帮助Flutter 社区其他开发者的角度出发，闲鱼内部开始讨论开源事宜，这是闲鱼第一次尝试开源，所有人都没有经验。大家开开心心地希望能将自己做的一些事情同社区进行交流。当然，作为第一次开源，很多事情做得也非常糟糕，糟糕的文档、糟糕的Demo、没有测试用例、问题维护不及时、没有好的社区共建方式，于是引发了社区开发者的大量抱怨。从自己真实的感受来说，要维护好社区项目，需要付出大量的精力和时间，这些甚至需要不少同事全职去做，这对一个业务团队来说有些勉为其难。对开源的反思是要敬畏开源，敬畏社区，在反馈中不断地成长，完善自身项目。例如，Flutter Boost 前期的设计在兼容性上侵入性太强，导致后续的升级成本较高。在未来的3.0 版本中，闲鱼会主动解决这一问题，减少关键的几个类的继承和重写，简化概念，降低接入成本。目前，这个阶段会重点关注已经开源的项目，尤其是Flutter Boost 这种在阿里巴巴集团内外都属于开发者刚需的项目，需要持续地维护，也非常欢迎更多的社区开发者参与进来。关于文章中提到的其他Flutter 相关技术，闲鱼会尽量考虑使用Demo 等形式将部分原理输出，帮助开发者更好地理解文章及其背后的思想。一方面保证了闲鱼对Flutter 社区的启发和帮助，一方面也缓解了闲鱼目前面临的无法保证全职人员从事开源工作的问题。但不论如何，闲鱼希望通过文章及代码，持续地帮助Flutter 社区，尽我们的一份绵薄之力。也许我们做得并不完美，甚至不够优秀，但随着闲鱼有更多优秀研发人员的加入，在创新和分享文化方面进行不断的自我革新，相信总有一天能伴随这项技术成为真正的国民级别应用的贡献者。3. 听说闲鱼放弃了Flutter，作为当事人，闲鱼的态度是什么？在各类社交平台匿名区和公众号中，都有人阶段性地、煞有介事地散播闲鱼放弃了Flutter 以及未来不会再投入的消息，作为当事人，我先说结论——这些都是谣言！《Flutter企业级开发应用实战：闲鱼技术演进与创新》一书的出版是对这些谣言最有力的反驳，也感谢出版社帮我们辟谣。移动互联网发展的十年， 对于跨平台技术来说， 从最早的PhoneGap 到ReactNative、Weex，再到目前的Flutter，形形色色的技术不断迭代和演进。从当前阶段来看，Flutter 具备跨平台技术的先驱——QT 的大部分优势，且配套了更现代的语言、更合理的分层架构，并有Google 公司支持，是新一代跨平台技术的集大成者。在下一个十年，面向万物互联的新操作系统，如华为鸿蒙及Google Fuchsia 的出现，使得跨平台技术的价值进一步凸显。因此，学习这项开源技术对未来的开发者来说是一个不错的选择。我们无法预测Flutter 是否一定为下一个十年的主流技术，但这套代码和其背后的思想一定能给未来的开发者以启发，就像我们的前辈用QT 开发了KDE，KDE 又提供了一个排版引擎KHTML，而苹果公司Fork 了这个项目，从而产生了WebKit，而Google 又Fork 了WebKit，从而产生了Blink。这些令人尊敬的公司和开发者站在巨人的肩膀上不断地努力，最终打造了令人耳熟能详的技术，从而改变世界。今天，Flutter 代码中有很多概念也存在浏览器内核的一些影子。作为客户端的从业者，希望开发者都能客观地评价这些技术，根据实际情况进行学习并将其落地。对于外界传出的类似闲鱼放弃Flutter 的谣言，大部分时间我们选择付之一笑。作为管理者，我不太希望团队过于关注外部的评价和过度回应不实传闻，希望闲鱼的开发者可以做正确的事情，并保持长期的耐心。未来的三年，闲鱼更希望探索先进的研发模式，帮助整个阿里巴巴集团在商业竞争中保持技术的先进性和成本优势。当然，我们希望这种研发模式是基于我们现有的技术沉淀基础之上的，因此会依然持续地投入Flutter 之中。同时，作为一个创新团队，闲鱼也一定会持续地关注行业的最新动态，未来也一定会像在Flutter 领域一样，在其他领域有所建树。