最后收集所有的审查结果，输出分数以及根据相应细节得出的建议，得到结果下面就以一个收集页面加载图片数据为例说明。自定义配置通过额外传入配置config完成自定义配置，const

引言深度语义匹配在闲鱼搜索相关性计算中扮演重要角色，相关工作在文章[1]《闲鱼搜索相关性——体验与效率平衡的背后》中有简单的介绍。如题，本文介绍前段时间在深度匹配任务上的另一种尝试，通过检索和生成任务联合训练的方法提升相关性匹配的效果。融合生成任务提示匹配主任务的思路并不新颖，而在BERT流行的今天，本文则参考[2]《鱼与熊掌兼得：融合检索和生成的SimBERT模型》，稍加改动，使用BERT为Backbone来重新实现类似的思路，模型暂且仍叫SimBert。现状闲鱼搜索的深度语义匹配前期做过多种尝试，但最终全量策略有两种：1.

管理工具，既能进行版本管理，又可以兼顾构建工作流、发布包等流程方面的管理，已经是业界非常主流的多包管理方案。鉴于单npm包修改后的版本更新，我们不希望影响到其他未修改的

};LoginModuleImplV1Provider可以通过调用Create方法拿到对应的LoginModuleImplV1实例。x_module::ModuleCenter*

目录结构如何下载关注本公众号，消息页找到【2022白皮书】（无需注册或登录，手机党也可放心下载）祝温故知新，兔年开新。

海恩法则是德国飞机涡轮机的发明者帕布斯·海恩提出的一个在航空界关于飞行安全的法则。每一起严重事故的背后，必然有29次轻微事故和300起未遂先兆以及1000起事故隐患。作为开发者，安全生产是我们底线，敬畏每一行代码，挖掘每一个故障背后的根因，避免再次落入同一个坑是应该成为我们的工作习惯，这里有几个我们线上真实有趣的故障案例分享给大家。三目运算符--最熟悉的陌生人三目运算符任何一个初学JAVA的同学都会接触到，而且在我们代码中也处处可见：expression1

前言目前闲鱼不少业务正在从H5/Weex升级到Kun（基于W3C标准&Flutter打造的混合高性能终端容器），从测试角度来看，我们希望这种升级迭代对于用户体验是正向的，所以用好性能测试这把标准尺就显得格外重要。早期做性能保障时，我们在一些核心场景要上线或者上线之后遇到问题时，才去跑一些性能测试，这种方式只知道性能变差了，至于差在哪里，就只能反推开发去查问题，效率低且容易出问题。今年我们提出了基于容器分层的性能测试，目的是提前将性能风险点抛的更前置、更明确，特别对于Kun，除了容器本身的影响，Flutter引擎也会影响性能体验。我们要测什么性能指标对齐在确定我们要做性能分层测试后，第一个问题就随之而来——性能测试到底要测什么，什么样的指标才能够去衡量一个页面的好坏。我们有两个选择：A、业界通用的指标，和友商APP的度量标准对齐；B、开发打点，测试侧对数据进行清洗；我们毫不犹豫选择了方案A，因为我们期望的性能测试并不只是在闲鱼内部赛马，而是说这些数据也能与友商以及业界标杆APP看齐，追求更加极致的用户体验。最终我们KO确定的指标如下：我们对现有的主干业务场景以及技术栈进行了梳理，并结合核心的业务场景和关键能力组件，建立对于引擎电商领域核心的数据观察策略，沉淀各个能力层和领域层度量体系，用于衡量在各个领域层开展相关性能优化取得的效果。1.

状态履约执行：在实际线上履约、对接联调、代码开发、测试回归场景中，都需要执行状态的履约。另外，在不同的场景中，又希望有单独的定制功能，比如：在开发、测试过程中，只能推进测试订单，不能推进实际订单。•

背景帖子详情是一个图文/视频混排、拥有大量长文本、大量交互和部分细节动效的页面，细节组件非常多，页面复杂度高。按以往的页面协作方式，会将一个个组件样式、组件数据和组件交互逻辑交给对应的开发同学完成，通过多人协同最终搭建出完整的页面，但这样的方式会造成后期维护该页面的一到两个核心同学成本急剧增加，需要理解每个组件内的逻辑代码；于是为了改善页面内的协作效率，同时为开发上下游协同效率提升打好基础，通过大量案例/源码/文献调研，最后选择使用开源的XState方案来完成页面协同开发。XState的理论基础在使用XState前，我们一直在探索的方向是当下有没有一种适合降低研发上下游协同成本的代码即流程的理论模型或者方案，经过大量调研，最终找到了在致力促进团队间沟通提升生产力的基于可执行UML研究分支的W3C

Pro】主要原因是impeller目前阶段比较早，很多功能还有待完善，测试过程中也出现了大量渲染错误的问题。impeller距离生产中使用还需时日。impellerskiaraster线程平均帧耗时

研究背景通常情况下应用发布或重启时都存在cpu抖动飙高，甚至打满的现象，这是由于应用启动时，JVM重新进行类加载与对象的初始化，CPU在整个过程中需要进行比平时更多的编译工作。同样，闲鱼的消息系统在重新发布时经常有抖动的问题，如下图显示：日常情况下CPU使用率基本不超过20%，而每当应用重新发布时，服务器的cpu使用率骤增至40%以上。本文正是为了减少这种抖动，进而保障应用发布时的稳定性。Java的编译发布时CPU利用率的飙高很大程度上是编译造成的，因此在处理问题之前，我们需要了解Java编译的机制，这对于后续的理解很重要。如果已经该部分知识非常熟悉，则可以跳过本节直接阅读第三部分。常见的编译型语言如C++，通常会把代码直接编译成CPU所能理解的机器码来运行。然而为了实现“一次编译，处处运行”的特性。Java把编译的过程分成两个阶段：•

双十一与Kun关注闲鱼技术的同学想必都对Kun有所了解，Kun是闲鱼技术团队自研终端渲染容器，使用前端研发方式进行高效开发，最终以Flutter渲染给用户提供高性能体验。Kun已经在我发布的、闲鱼号、闲鱼超市等业务中使用，提供给用户良好的加载性能与独特的增强体验。一年一度的双十一要到了，我们也希望双十一能够应用Kun的加载性能与增强体验。而今年闲鱼双十一主互动是一个游戏化场景，具备互动复杂以及强运营诉求的特点，Kun能否在闲鱼双十一应用呢？要做哪些准备Kun之前的应用场景多是产品页面，页面交互相对简单，也不需要支持较强的运营能力。而双十一主互动和之前场景有较大差别，在双十一期间没有玩过闲鱼超级流通机的同学可以看下图体验下。整个页面分为两部分，上方区域是互动区域，用户通过做任务领取能量，收集能量共建风力发电机，页面上的元素会随着用户交互变化，在右上角还有一个入口点击进入摸鱼小游戏，用户快速点击屏幕模拟摸鱼行为进行PK；而下方区域则是运营区域，运营会根据双十一这段期间每天不同的主题搭建不同业务模块，涉及到促发布、免费送、回收、降价、商品列表等业务模块。因此在双十一主互动应用核心要完善两方面的能力，上方互动区域涉及的互动以及动效相关能力，下方运营区域涉及的搭建以及营销相关能力。加上页面性能与用户体验，综合来看需要解决下面这三个问题：1.

背景介绍在电商频道/导购详情页中，为让页面信息呈现更多更丰富效果经常使用嵌套滚动容器搭建页面，常在大促/首页/频道/信息流等多SPU/多频道关键信息场景下使用，今年从kun支持第一个闲鱼超市业务到双十一项目整个过程中，悉数落地7个业务场景中嵌套滚动容器构建页面占据6个。从技术角度，嵌套滚动容器组件属于复合性交互容器组件，包括手势冲突/交互体验/流畅度等方向会面临挑战，比如在H5因其机制在模拟手势交互过程会存在一些限制，为保证动态性/高性能/强体验，KUN

我们发现，优惠对象的判定过程，都是在回答“用户是否属于某个群体”，我们可以将这个关系进行抽象，提前制备并存储起来。在我们常见的技术手段中，表达一个用户是否属于某个群体有两种实现：1.

safety：https://dart.dev/null-safetyFlutterBoost：https://github.com/alibaba/flutter_boost抽奖有礼礼物

在互联网信息爆炸的今天，推荐系统是我们身边一个无法躲避的存在。在淘宝上浏览商品，在抖音上刷视频，以及无处不在的广告等等。本文探讨闲鱼商品推荐系统的同时，结合所面临的多推荐场景工程维护任务重、算法模型优化难以自动辐射多场景的痛点，介绍如何构建通用的推荐中台。背景推荐系统用户在网络上浏览时，如果能准确描述自己的需求，可以通过主动搜索来找到自己需要的信息。但是在不少情况下，用户并不一定能准确的描述自己的需求，或者用户就是来逛的，这个时候用户往往希望产品能主动把感兴趣的信息直接推送到自己面前。此时，推荐系统即发挥其中介作用，来连接用户与信息。而在互联网信息蓬勃发展的今天，每时每刻都在生产大量的信息与内容。因此，推荐系统需要解决的问题，便是从海量的候选信息中，挑选出用户最感兴趣的信息。为了完成这一挑选最优过程，典型的闲鱼商品推荐系统，涉及模块如下图所示。•

前言本文从KUN在闲鱼落地为出发点，介绍如何通过KUN实现Web和Flutter技术增强你的移动应用程序。在结合了Web和Flutter的各自优势，以及它们背后良好的生态和社区支持，你能用它来覆盖你的所有上层业务，达到更佳的动态化效果。介绍KUNKUN

最直接的方式是提升searcher的处理能力。因此，我们将searcher的列数从16列扩大至24列，提升了50%的实时增量处理能力，增量延时缓解。引擎架构治理我们重新思考了闲鱼主搜引擎的架构与定位

层叠上下文支持63个BOM-API，覆盖定时/跳转/URL/环境/Location/屏幕/存储/日志等并为此建立了超过1100个test-cases的高效的自动化测试系统。基于flutter

背景闲鱼某关键应用A依赖类目系统富客户端（下文简称类目客户端），旨在为闲鱼商品域其他应用提供各类商品类目及属性数据（下文简称CPV数据）查询服务。每天凌晨，该应用所依赖的类目富客户端执行新老版本数据包切换时，应用提供的服务抖动非常明显，表现为大量接口超时（耗时100ms

什么是单元测试《单元测试的艺术》中对单元测试的定义：一个单元测试是一段自动化的代码，这段代码调用被测试的工作单元，之后对这个单元的单个最终结果的某些假设进行校验。单元测试几乎都是用单元测试框架编写的；只要产品代码不发生变化，单元测试的结果是稳定的。为什么需要单元测试在我看来，单元测试的意义可以总结如下三点：单元测试是保证你写的代码是你想要的结果的最有效办法单元测试帮我们塑造设计单元测试是最好的文档之一单元测试描述了代码的预期行为，可以最有效地保证代码正确运行，减少代码缺陷；由于单元规模较小，当因为代码变更出现问题的时候，可以帮助我们快速定位问题；有单元测试覆盖的代码，让我们更有信心，敢于放心做代码重构；写单元测试的过程往往伴随着代码重构，如果发现一段代码单元测试很难写，就需要反思我们的设计，进而重构促进代码设计的优化，帮助我们塑造设计；同时单元测试也是一个最佳的、自动化的、可执行的文档；没有单测覆盖的代码，是很难被维护的。什么是有效的单元测试可读、可维护、可信赖、快速执行！《单元测试的艺术》中描述优秀单元的特性：它应该是自动化的，可重复执行；它应该很容易实现；它应该第二天还有意义；任何人都应该能一键运行它；它应该运行速度很快；它的结果应该是稳定的（如果运行之间没有进行修改的话，多次运行一个测试应该总是返回同样的结果）;它应该能完全控制被测试的单元；它应该是完全隔离的（独立于其他测试的运行)；如果它失败了，我们应该很容易发现什么是期待的结果，进而定位问题所在。可读性“一般程序员写得出计算机能读懂的代码。优秀程序员写得出人能读懂的代码”

前段时间，一款聊天机器人的意识问题引发伦理争议。人工智能再发展20年，是否会具备自主意识？未来我们又该以什么样的态度与人工智能和谐共处？当一辆自动驾驶汽车冲向行人，究竟谁该对危险负责，是车主？还是自动驾驶汽车的制造商？又或是人工智能系统的设计者？……科技发展突飞猛进，科技伦理问题也越发凸显。人工智能的发展道路存在分歧、技术缺陷使得系统存在隐患，技术滥用问题值得重视和关注。数字时代需要技术的担当和责任，让技术在“可用、可靠、可信、可控”的体系里发展，为人类社会创造更多的社会价值。由阿里巴巴集团主办的《数字时代的技术责任》论坛，将邀请清华大学苏世民书院院长薛澜、北京大学中国社会与发展研究中心主任邱泽奇、复旦大学数字与移动治理实验室主任郑磊、上海社科院互联网研究中心主任惠志斌，和阿里巴巴集团首席技术官程立、阿里巴巴集团法务&合规负责人屠剑威、阿里研究院院长高红冰、阿里巴巴人工智能治理与可持续发展研究中心AAIG负责人薛晖等多位内外部行业领域专家学者一起，深度探讨数字时代科技发展带来的新挑战和新问题，讨论如何让科技发展更好地为人服务，创造更多的社会价值。在本场论坛上，我们将聚焦科技伦理治理研究，以及发布首份《人工智能治理与可持续发展实践白皮书》。白皮书将会详细阐释企业面向可持续发展的人工智能治理体系，持续关注人工智能伦理与治理，涵盖数据安全和隐私保护、消费者权益和公平、深度合成治理等重要方向。目前，2022世界人工智能大会阿里巴巴专场论坛已经上线，欢迎扫码报名，期待您的莅临。

背景用户输入是平台获取用户信息的重要途径，也是用户自我表达的重要方式，社区业务场景下尤其如此，输入过程的流畅性、精准性、丰富性都是我们要重点保障的。下图是最近的一个产品需求，「圈内好物」板块下允许用户自定义「商品分组」。产品&设计同学有两个核心诉求：1.

前言本文仅以个人观点阐述未来的端研发趋势和人才岗位结构趋势的要求，进而引出闲鱼技术团队今天要做的事情，闲鱼技术团队作为集团创新产品的先头兵，一方面希望通过持续的技术革新为业务带来核心竞争力，另一方面也希望为集团开拓新的技术领域从而引领新的技术风潮，通过技术带来长期的效能红利。KUN作为闲鱼技术团队在终端技术这一未来岗位的核心转型的重要基础设施，在推进过程中一定也会遇到各种不同的声音，因此更有必要让大家了解我们的长期构想和实现路径。道路是曲折的，我们无法准确预测未来，但是可以肯定的是，闲鱼技术团队一直以创新突破作为团队的核心灵魂，这个灵魂植根于每一次技术设施升级、研发模式升级、人才岗位升级中并长久不衰。长期以来，闲鱼技术团队，尤其是闲鱼客户端团队都在争议和挑战中持续进步，不停的磨练自身的技术能力，我们有理由相信，一个勇于面向自身革命的团队，一个敢做旧时代掘墓人，新时代的引领者的团队，必将乘鲲而行，带领组织奔赴星辰大海。终端行业的趋势变化首先我想从几个角度去阐述一些趋势的变化终端设备的趋势变化【智能手机仍是未来三年关键】移动互联网的这十年来，设备从PC迁移到智能手机，在这个过程中又衍生出了平板、智能TV、可穿戴设备等新的终端产品，可预见的未来XR设备也会层出不穷。Anyway，在近几年的终端设备趋势来看，目前还没有任何一个终端产品具备目前智能手机的三大特性-刚性需求、高频使用、生态开放，因此往后三年看，在终端的硬件布局上，智能手机依然是今天的优质流量入口【1】。软件架构的趋势变化【跨端跨设备是业务刚需并持续演进】从PC互联网到移动互联网转型的这么多年来看，随着技术的不断演进，传统意义上的前端和客户端持续在做相互的渗透，从最早的Native+Web的混合架构，再到ReactNative/Weex的以JSRuntime驱动Native组件渲染的高性能跨端架构，再到Flutter以自绘能力推进多端一致性和性能显著提升的新架构的尝试，技术侧我们一直在致力于进一步提升终端设备上的研发效能从而推动业务的高效迭代和创新。另外随着小程序的在近些年作为各公司主要的用增入口或经营主阵地，进一步推动了跨端技术的演进和迭代。以极客邦组织的相应行业大会内容来看，行业所谓的大前端的技术趋势是长期存在的。它有几个典型的特点：上层以类前端技术作为研发的基础（JS/TS，同时Dart也是最早面向前端的设计的语言），下层通过抹平各操作系统的UI渲染和底层API的能力差异形成端侧容器，该类架构具备一次研发多端交付的特点，在具备高性能的前提下拥有较好的动态部署能力（Flutter在行业内也有很多开源动态化方案，可参考阿里的Kraken【2】和腾讯的MXFlutter【3】）。组织协同的趋势变化【岗位融合，减少无效协同是敏捷组织的核心诉求】技术趋势变化一定会影响组织协同方式的变化，混合架构带来的岗位的重新设定和组织架构的重新调整，在一定程度上你中有我，我中有你的不停相互影响着。以闲鱼为例，从最早的iOS/Android分端的岗位职能，到以业务视角分业务线不分端的岗位职能设计，背后既有独立业务线的快速交付的诉求，也是混合架构下释放的组织效能的体现。今天为止，闲鱼在客户端岗位上崇尚的就是一人开发，独立高质量交付。当然这样的岗位趋势也不是个例，在国内各大厂的大前端组织内我们也能看到不但客户端之间在做岗位融合，前端和客户端也在做岗位融合。我们把视野再放到海外，从google、facebook、amazon的数据来看，硅谷的巨头们在人才结构上掌握Front-End（包含前端、客户端等与用户交互相关的岗位）的人才比例有30%或更多，这更加催生了端到端全栈的应用开发工程师的存在。组织在融合是表象，背后说明一个本质问题，敏捷组织的构建关键在于减少协同。多岗位协同带来的组织间的管理摩擦严重影响大厂的交付效率和创新效率。基于以上的构想，作为闲鱼客户端的负责人，我认为未来的端侧研发的目的应该核心是服务与敏捷组织，激发公司的效能和创新的活力。我们的组织未来首先应该是岗位角色更少，岗位技术能多样，而对应的技术能力要为这个组织的角色服务，因此，所有的研发模式都要服务于如何让这件事更容易的发生。由于我们的技术主阵地依然是以智能手机为主的场景，如何有效的提升以智能手机为主、其他设备为辅的端侧交付效率就是我们核心要关注的事情。未来研发模式构想及路径端侧组织职能的再分配在行业的岗位职能中，客户端（iOS/Android）开发工程师、前端（Web）开发工程师，以及一些上层的细分岗位如Flutter工程师开发、RN开发工程师、小程序开发工程师等角色众多。而各类移动端中间件、移动端构建平台的相关研发工程师的岗位角色也需要相互配合，从这个角度上，岗位的细分一方面带来协同成本的显著增加，一方面在人才发展中造成不同的Job

长列表页面（如详情页、搜索结果页）不支持。点击“截长屏”后，能看到长列表页面会自动滚动，点击结束或者触底的时候，自动打开图片编辑页面，能看到生成的长截图。那小米系统是如何无侵入的实现以下关键点：1.

闲鱼经过近八年的发展，前端技术在整个研发体系中有着举足轻重的地位，前端有迭代速度快，动态化能力强，跨端适配成本低等显著优势。闲鱼前端一直使用淘系提供的基础技术和平台工具，但随着业务的不断发展，逐渐无法满足复杂、个性化的业务和技术环境。工欲善其事，必先利其器，拥有自己的上层研发体系势在必行，于是从去年下半年开始，前端开始着手代号为「魔鱼」的技术体系建设。魔鱼目前魔鱼包含产研平台、研发模式和网关建设三大部分。产研平台闲鱼原有的研发流程是在集团提供的工程研发平台上进行的。大致流程如下：1.

背景在服务端的质量保障中接口测试一直占据着重要的作用，从最开始的手工测试到编写接口测试代码，再到后来的基于流量录制的接口回放，测试效率不断得到提高，但是风险评估主要还是依赖开发同学以及测试同学对业务的熟悉程度，没有相应的工具予以支撑，回归的时候也没有重点，通常会全量回归，避免遗漏。因此开发相应的工具及平台精准确定代码的改动范围，有效评估影响面，提高回归效率。方案概述服务端主要对外提供

Bash是短时间内发现质量问题最有效的手段之一，组织团队的产品、开发、测试、UED、运营，甚至是客服、市场人员，放下他们手中的日常工作，一起来用他们能够想到的各种方式“训练”APP。Bug

2.消息队列其实有消息待处理，但是被设置了同步屏障，遍历队列消息列表如果没有找到异步消息，则会进入nativePollOnce等待唤醒；

背景闲鱼作为一款垂直交易社区APP，拥有复杂多样的业务场景：涉及c2c、回收寄卖、租房租赁、见面交易、验货担保等，复杂多变的交易模式。比如验货流程：•涉及39个状态机节点•横跨10+应用系统•涉及6个业务部门的合作•涉及接口几十个需要保证每个接口、每个场景切实可行，稍微有一点点问题，就会涉及到人民币的味道，实际工作中，我们遇到各种各样的问题，比较棘手的问题如下问题业务先赢的快速迭代模式下，全靠人工主力进行测试验证，测完新功能，还得回归老功能，一个小需求也须要好几个人日，版本PTM也要回归好几遍，ROI并不乐观，以下2个问题比较突出：交易业务强依赖中台，沟通成本高，跨团队协作难，迭代效率低，测试环境下如何自洽？复杂多样交易模式下，如何支撑需求稳步迭代上线以及日常回归验证？测试策略-自动化闲鱼质量基建正在快马加鞭进行中，针对闲鱼多样的交易模式，全靠人力是不可行的，累不说，改动、风险漏评估也时有发生。对此，我们根据接口->链路的策略，探索对比了几个不同的方案，在保证每个接口OK的基础上，保障全链路。接口层对于每一个大型应用程序来说，接口数量会不断增加，代码变更频率越来越大、系统不定期重构，这个接口的质量怎么来保障？传统编写脚本来进行的方式，投入的人力、时间成本过大，在实际的测试过程中我们探索了一些接口测试的新想法。目前业界公认的有效方式是基于引流回放的自动化测试，实现方案业内众说纷纭各有其词，但万变不离其中，引用下面这段总结，简单明了一种是黑盒测试思路，它在线上接口请求时采集线上流量（主要是请求参数和结果），然后使用和线上环境相同的环境（数据库共用等）下用采集到的流量重新触发请求，然后断言被请求的返回值是不是和录制时的一致。这种方法比较适合对Get类型的接口进行测试，而对于写操作的请求容易造成数据污染，再加上所采集流量的数据状态（数据时效性）、环境依赖性（各种中间件、接口内部请求的RPC调用）等因素，所以这种测试方式具有一些局限性，不能满足实际测试场景中复杂的需求。另一种思路相对白盒，主要是通过智能化的Mock手段，流量采集时采集代码运行过程中所依赖的外部中间件或者RPC调用的返回结果，当流量回放时，能够Mock本机程序对外的依赖中有可能产生变化的内容，使测试更关注本地接口的代码逻辑。阿里集团内部，基于流量回放的思想，主要实现了2种不同的流量录制回放方案，一种是基于doom的天启/暴雪，一种是基于JVM-Sandbox的凤凰，两种实现都借力于JVM

随机200query搜索满意度+6.6%；同样文本语义向量用于i2i向量召回，复用到闲鱼求购场景，核心指标点击互动人次相对提升20.45%。定义搜索query

现状闲鱼IM框架构建于2016-2017年，期间多次迭代升级导致历史包袱累积多，后经IM界面Flutter化，造成架构更复杂，开发层面总结闲鱼当前架构主要存在如下几个问题：•研发效率较低：当前架构开发需求涉及到Android/iOS双端的逻辑代码以及Flutter的UI界面代码，定位问题往往只能从Flutter

背景随着Flutter的发展，国内越来越多的App开始使用Flutter。为了降低风险，大部分App采用渐进式方式引入Flutter，在App里选几个页面用Flutter来编写，但都碰到了相同的问题，在原生页面和Flutter页面共存的情况下，如何管理路由？官方没有提供这样的解决方案，而FlutterBoost就是为了解决这个问题而生。FlutterBoost从开源后受到了社区开发者的欢迎，已经有很多App使用了FlutterBoost，社区开发者也很活跃，提了很多Issue和PR。感谢开发者的一路支持和包容，无论是意见反馈还是吐槽，我们都会认真看，会持续关注Issue。使命FlutterBoost的使命是让开发者非常简单的在原生App中开发Flutter页面。FlutterBoost做为Flutter

现状和问题闲鱼的舆情治理，依托阿里集团的设施建设，具备以下能力：崩溃异常、性能在线聚合查询；本地日志：TLog；在线日志：埋点日志（t+1）和用户行为日志（路径和请求）但在应对舆情治理方面仍存在较多的问题：有相当一部分闪退、黑屏、卡死舆情无

背景在2020年年初的时候接手了闲鱼的消息，当时的消息存在一些反馈：“闲鱼消息丢失”、“消息用户头像乱了”、“订单状态不对”。闲鱼消息的稳定性是个亟待解决的问题，我们调研了集团的一些解决方案，例如钉钉的IMPass。直接迁移的成本和风险都是比较大，包括服务端数据需要双写、新老版本兼容等。那基于闲鱼现有的消息架构和体系，如何来保证它的稳定性？治理应该从哪里开始？现在闲鱼的稳定性是什么样的？如何衡量稳定性？希望这篇文章，能让大家看到一个不一样的闲鱼消息。行业方案消息的投递链路大致分为三步：发送者发送，服务端接收然后落库，服务端通知接收端。特别是移动端的网络环境比较复杂，可能你发着消息，网络突然断掉了；可能消息正在发送中，网络突然好了，需要重发。在如此复杂的网络环境下，是如何稳定可靠的进行消息投递的？对发送者来说，它不知道消息是否有送达，要想做到确定送达，就需要加一个响应机制，类似下面的响应逻辑：发送者发送了一条消息“Hello”，进入等待状态。接收者收到这条消息“Hello”，然后告诉发送者说我已经收到这条消息了的确认信息。发送者接收到确认信息后，这个流程就算完成了，否则会重试。上面流程看似简单，关键是中间有个服务端转发过程，问题就在于谁来回这个确认信息，什么时候回这个确认信息。网上查到比较多的是如下一个必达模型，如下图所示：[发送流程]A向IM-server发送一个消息请求包，即msg:R1IM-server在成功处理后，回复A一个消息响应包，即msg:A1如果此时B在线，则IM-server主动向B发送一个消息通知包，即msg:N1（当然，如果B不在线，则消息会存储离线）[接收流程]B向IM-server发送一个ack请求包，即ack:R2IM-server在成功处理后，回复B一个ack响应包，即ack:A2则IM-server主动向A发送一个ack通知包，即ack:N2一个可信的消息送达系统就是靠的6条报文来保证的，有这个投递模型来决定消息的必达，中间任何一个环节出错，都可以基于这个request-ack机制来判定是否出错并重试。看下在第4.2章中，也是参考了上面这个模型，客户端发送的逻辑是直接基于http的所以暂时不用做重试，主要是在服务端往客户端推送的时候，会加上重试的逻辑。闲鱼消息的问题刚接手闲鱼消息，没有稳定相关的数据，所以第一步还是要对闲鱼消息做一个系统的排查，首先对消息做了全链路埋点。基于消息的整个链路，我们梳理出来了几个关键的指标：发送成功率、消息到达率、客户端落库率。整个数据的统计都是基于埋点来做的。在埋点的过程中，发现了一个很大的问题：闲鱼的消息没有一个全局唯一的ID，导致在全链路埋点的过程中，无法唯一确定这条消息的生命周期。消息唯一性问题之前闲鱼的消息是通过3个变量来唯一确定一个消息•SessionID:

背景IM消息作为闲鱼用户重要的交易咨询工具，核心目标有两点，第一是保证用户的消息不丢失，第二是保证用户的消息及时送达接收方。IM消息根据消息的接收方设备是否在线，分为离线和在线推送，数据显示目前闲鱼每天有超过一半以上的IM消息是走在线通道的，而在线消息的到达率、及时性是直接影响用户体验的，本文将着重分析优化在线通道的稳定性，保证用户消息及时到达。面临哪些问题端内长连接中断在IM场景中，用户与云端通信频繁，且为了实现用户的消息及时到达，往往采用云端下推消息的方式触达用户，所以用户在线时设备与云端会维持一条TCP长连接通道，可以更轻量级的与服务端进行交互，现代IM即时通讯的下行消息都是通过长连下发的，闲鱼消息使用的是ACCS长连接，ACCS是淘宝无线提供的全双工、低延时、高安全的通道服务。但是由于用户设备网络状态的不确定性，可能会发生各种各样的网络异常情况导致长连接通道中断，长连接一旦意外中断，就会导致用户无法及时收到在线消息，所以我们需要尽可能及时的感知到长连中断并尝试重连。下推的消息未达感知长连中断并重连只能在大多数时间保证长连接的有效性，但是在长连接无效或不稳定期间下推的消息客户端可能根本收不到，简单说就是仅仅有重连机制无法保证下行消息必达，可能有以下场景导致下行消息失败：服务端发送下行消息时长连畅通，消息在传输路上通道断掉，客户端无法收到

背景闲鱼每天流转的消息量级过亿，触达一半的用户，由于二手商品的性质，闲鱼用户需要通过聊天进一步了解宝贝成色，进行商品价格协商等，消息作为闲鱼的基础功能，在促进商品成交中起到很大的作用。同时在闲鱼，买卖双方通常是个人用户，是否在线存在非常大的不确定性，消息触达一旦出现问题，就有可能影响到商品成交，甚至还会出现引流到微信进行欺诈的情况，因此急需通过有效手段为用户提供稳定可靠的消息服务。问题定义在消息领域，从用户角度来说，问题现象主要是消息丢失、消息触达延迟等。从技术上来说丢消息的根因是端上架构设计，即有通过服务端接口拉消息，也有accs长连接通道下发消息，当有大量消息同时到达客户端时，消息合并或落库异常则会被丢弃掉，导致用户消息丢失。而在线消息延迟，更多是accs通道延迟和阻塞导致。但闲鱼消息因为收发链路长，服务端和客户端上实现的处理逻辑复杂，还涉及第三方通道，所以面临三个主要问题：如何在上线前尽早发现问题？线上出现问题如何快速发现？舆情问题如何有效定位？以上问题都值得去解，但是考虑到闲鱼闲鱼消息功能自上线以来，核心逻辑都是自己实现没使用集团现成的消息SDK，随着早起业务疯狂增长开发交替，现在开发接手消息的需求如履薄冰，从而导致消息线上问题不断叠加。着手消息问题治理，最优先需要的是有一个全面的排查手段，能够快速排查定位线上问题。消息全链路排查建设在定位舆情问题时，仅仅通过有限的文字描述和截图难以发现问题的本质，甚至是无法确认是端上问题还是服务端问题。举个栗子，某天晚上大家准备下班时，老板抛出一个舆情，用户反馈消息丢失，这时候大家都慌了，服务端、客户端、质量同学大家都聚集在一起定位问题，而定位的唯一途径就是你查你的日志，我查我的日志，查到最后还是在盲猜问题，耗时耗力不精准。从这件事情来看，要想提升闲鱼消息服务质量，光靠开发优化远远是不够的，还需要基建项目来提升定位问题的消息，于是质量团队和开发团队一起着重闲鱼消息全链路排查的建设。要做消息全链路排查，关键是有全面的消息日志支撑，能够获取到消息的完整轨迹。我们通过将服务端消息节点日志、接口日志、客户端消息状态埋点日志、和行为埋点日志聚合，最大程度还原用户当时的行为和消息途径链路。日志上报首先是消息链路的核心场景梳理，针对消息合并、落库、上屏、域环同步、域环更新等容易出现或反映问题的关键节点，会进行排查所需的日志上报。其次就是日志格式约定，核心是客户端在生成每一条消息时也会给它生成一个messageId，对于服务端推送的营销类消息，messageId则是由服务端生成。消息每经过一个核心节点都只将途经状态加上messageId上报，该id也会透传给服务端上报日志使用，这样messageId串联起了一条消息从客户端发到服务端再到客户端收的完整追踪链路。最后是上报的方式，最开始的想法是端上接入SLS

背景随着用户数的快速增长，闲鱼的IM也迎来了前所未有的挑战。多年的业务迭代，端侧IM的代码已经因为多年的迭代层次结构不足够清晰，之前消息一些隐藏起来的数据同步问题，也随着用户数的增大而被放大。这里面的具体流程在于，后台需要同步到用户端侧的数据包，后台会根据数据包的业务类型划分成不同的数据域，数据包在对应域里面存在唯一且连续的编号，每一个数据包发送到端侧并且被成功消费后，端侧会记录当前每一个数据域已经同步过的版本编号，下一次数据同步就以本地数据域的编号开始，不断的同步到客户端。当然用户不会一直在线等待消息，所以之前这里端侧采用了推拉结合的方式保证数据的同步。在线时使用ACCS实时的将最新的数据内容推送到客户端。ACCS是淘宝无线向开发者提供全双工、低延时、高安全的通道服务。离线启动后，根据本地的数据域编号，拉取不在线时候的数据差。当数据获取出现黑洞（数据包Version不连续的状态）时，触发数据同步拉取。分析现存的一个同步策略是可以基本保障IM的数据同步的，但是也伴随着一些隐含的问题：短时间密集数据推送时，会快速的触发多次数据域同步。域同步回来的数据如果存在问题，又会触发新一轮的同步，造成网络资源的浪费。冗余数据包/无效的数据内容会占用有效内容的处理资源，又对CPU和内存资源造成浪费。数据域中的数据包客户端是否正常消费，服务端侧无感知，只能被动地根据当前数据域信息返回数据。数据收取/消息数据体解析/存储落库逻辑拆分不够清晰，无法针对性的对某一层的代码拆分替换进行ABTest。针对遇见的这些问题，对闲鱼IM进行分层改造，抽离数据同步层。除了希望以后这个数据的同步内容可以用在IM之外，也希望随着稳定性的增加，赋能其他的业务场景。本文重点来看下端侧闲鱼IM数据同步的一些解决思路。数据同步优化拆分&分层对于服务端来说，业务侧产出数据包后，会拼接上当前的数据域信息，然后通过数据同步层将数据推送到端侧。对于客户端来说，接收到数据包后，会根据当前的数据域信息，来确定需要消费数据包的业务方，确保数据包在数据域内完整连续后，将数据体脱壳后交于业务侧消费，并且应答消费的状况。数据同步层的抽取，把数据同步中的加壳、脱壳、校验，重试流程封装到一起，可以让上层业务只需要关心自己需要监听的数据域信息，然后当这些数据域更新数据的时候，可以获取到这些数据进行消费，而不再需要关心数据包是否完整。业务侧只需要关心业务侧对接的协议，数据侧只需要关心数据侧包装的协议，网络层负责真实的数据传输。对齐数据层数据传输协议、描述当前数据包体数据域信息将消息的处理/合并/落库抽离成数据消费者上下楼依赖抽象化，去除对于具体实现的依赖数据层结构模型基于对于数据模型剥离和对当下遇见的问题的解决方案规整，将数据同步层拆分为这样的架构：step1：App启动时建立ACCS长链接服务，保证推推送信道链接，并且根据当前本地数据域信息触发一次数据拉取。step2：数据消费者注册消费者信息和需要监听的数据域信息，这里是一对多的关系。step3：新的数据抵达端侧后，将数据包放到指定的数据域的缓冲池，批量数据归纳结束后，重新出发数据的读取。step4：根据当前数据域优先级弹出最高优的数据包，判断数据域版本是否符合消费者要求，符合则将数据包脱壳后丢给消费者消费，不符合则根据上一次正确的数据包的域信息触发增量的数据域同步拉取。step5：触发数据域同步拉取时，block数据读取，此时通过ACCS触达的数据依旧会在继续归纳到指定的数据域队列中，等待数据域同步拉取结果，将数据包进行排序、去重，合并到对应的数据域队列中。然后重新激活数据读取。step6：数据包体被消费者正确消费后，更新域信息并且通过上行信道告知服务端已经正确处理的数据域信息。数据域同步协议Region中携带的数据不必过多，但是又需要将数据包的内容描述清楚目标用户的ID，用以确定目标数据包是否正确数据域ID和优先级信息当前数据包的域优先级版本排序策略针对于域数据归纳，无论是在写入数据的时候进行排序还是在读取的时候进行查找都需要进行一次排序的操作，时间复杂度最优也是O(logn)级别的，在实际coding中发现由于在一个数据域里面，数据包的Version信息是连续唯一并且不存在断层的，上一个稳定消费的数据体的Version信息自增就是下一个数据包的Version，所以这里采用了以Versio为主键的Map存储，既降低了时间复杂度，也使得唯一标识的数据包后抵达端侧的包内容可以覆盖之前的包内容。一些问题&解决策略多数据来源和唯一数据消费的平衡每当产生一条针对于当前用户的数据包，如果当前ACCS长链接存在，就会通过ACCS将数据包推送到客户端，如果App切换到后台一段时间，或者直接被杀死，ACCS链接断开，那么只能通过离线推送到用户的通知面板。所以每当App切换到活跃状态，都需要根据当前本地存储的数据域信息从后台触发一次数据同步数据包触达到端侧的来源主要是ACCS长链接的推送和域同步时的拉取，但是数据包的消费是根据数据域的监听划分的唯一消费者，也就是同一时间内只能消费一个数据包。在压力测试中，当后台短时间内密集的将数据包通过ACCS推送到端侧时，端侧接收到的数据包并不有序，不连续的数据包域版本又会触发新的数据域同步，导致同样的一份数据包会通过两个不同的渠道多次的触达到端侧，浪费了不必要的流量。当数据域同步时，这个时间节点产生的新数据包也会推送到端侧，数据体有效，并且需要被正确的消费。针对这些问题的解决策略：在数据消费和数据获取中间装载一个数据中间层，当触发数据域同步的时候block数据的读取并且ACCS推送下来的数据包会被存放在一个数据的中转站里面，当数据域同步拉取的数据回来后，对数据进行合并后再重启数据读取流程。数据域优先级需要推送到端侧的数据包，根据业务的不同优先级也有不同的划分，用户和用户的聊天产生的数据包会比运营类的消息的数据包优先级要高一些，所以要当多优先级的数据包快速的抵达端侧时，高优先级数据域的数据包需要被优先消费，而数据域的优先级也是需要动态调整，不断变换的优先级策略。针对这个问题的解决策略：不同的数据域，产生不同的数据队列，高优队列里面的数据包会被优先读取消费。每一个数据包体中带回的数据域信息，都可以标注当前的数据域优先级，当数据域优先级发生变化的时候，调整数据包消费优先级策略。优化效果除去结构上分层梳理，使得数据同步层和依赖的服务内容可便捷解耦/每一个环节可插拔之外，数据同步中对于消息消费时长/流量节省，压力测试场景下优化效果更加明显。压力测试场景：500ms内100条全乱序数据包推送消息处理时长（接收-上屏）缩短

中的主流优化思路，前面的优化手段都是这个思路快速响应用户，让用户觉得够快，不阻塞用户的交互即一帧时间内还有任务没有完成，则停止执行，保证列表先执行滑动，未执行任务在后续帧时间片上执行

背景闲鱼前端页面的性能常常被人念叨，凡跳转、必跳鱼的印象深入人心，部分页面甚至需要跳四五下才能打开，最近我们对闲鱼前端页面系统性的做了些优化，由于闲鱼前端技术栈相对多元，不同栈技术原理各不相同，优化方案也有所差异，本文主要介绍目前闲鱼占比较重的

招服务端／客户端／前端／算法／架构／质量工程师，简历投递guicai.gxy@alibaba-inc.com

Flutter+Serverless三端一体研发架构，客户端不仅仅是编写双端的代码，而是扩展了客户端的工作边界，形成完整的业务闭环。在新的研发模式落地与实践的过程中，一直在思考如何提高FaaS端研发体验与研发质量，以下是落地过程中遇到的问题。如何提高FaaS研发体验？FaaS层通常是直接在主干中逐块增加业务代码，这种写法领域数据间的依赖并不清晰，后续维护时需要针对领域数据进行更换、顺序调整或者由串行改并行时需要增加很多工作。如何提高FaaS侧研发质量？客户端同学编写FaaS代码时，需要针对服务端各种异常增加保护性代码与降级策略，比较容易出现遗漏从而导致整体质量下降。任务编排是什么？回顾一个完整的业务闭环，包括中台、领域层、业务层与渲染层。云端一体场景下FaaS侧更多的工作集中在业务层与渲染层，进行数据聚合、裁剪、字段映射和结构调整。以下单业务为例，FaaS层通过6次HSF（RPC框架）调用获取领取数据组装而成。商品信息、收货地址与闲鱼币可以并行执行，红包、运费与验货担保可以并行执行，由于依赖商品信息与收货地址，两组任务需要串行执行。上图中可以把每一个节点（例如：获取商品信息）抽象为任务，通过代码实现此流程就是任务编排。任务编排如何提升开发体验FaaS层通常是直接在主干中逐块增加业务代码，遇到复杂场景时主干代码可能百行甚至千行，以下是通过任务编排框架编写的下单页功能代码通过Map类型的数据作为入参，其中多个任务都可能使用到这些参数。使用then与thenAll两个API进行任务编排，then函数表示传入的函数串行执行，thenAll传入的函数需要并行执行。调用apply进行任务链路的执行。通过链式调用，整体结构非常清晰，框架的侵入性低。可以看到以上代码入参、任务编排与获取结果，结构非常清晰。从代码上就能看出任务数量、任务流程、任务的串行与并行。通过简洁、少侵入性与链式调用极大提升开发体验。requestItemDO函数是获取领域数据常见流程，首先是获取参数userId与itemId，通过HSF获取商品信息，拿到结果之后判断此次请求是否有效，如果有效返回具体Model数据。任务编排的应用场景任务类型任务编排并不局限于HSF任务，由于框架仅要求传入的是一个函数，通过函数进行抽象，可以支持任意类型的任务编排，例如：HSF、MetaQ、Tair、DB等。任务编排形式下单页的例子是串行&并行共存的场景，任务编排框架支持任意数量串行、并行、复杂场景任务编排。开发同学只需要开发任务函数，然后根据任务需要串行还是并行，调用具体API接口，不用关心同步与异步的各种操作细节。异步任务FaaS侧的代码通常都是IO密集型的任务，例如PRC调用、数据库读写等。Dart基于事件队列（Event

传递到对应的子节点，再由子节点不断向下分发直到叶子节点或可以给出业务输出的一层。这个过程有点类似递归或者分治的思想。StrategyHandler接口/**

背景在闲鱼的很多业务场景中有大量需要利用算法进行分类的需求，例如图片分类、组件识别、商品分层、纠纷类别预测等。这些场景往往需要模型识别出的结果具备可解释性，也就是识别不能只得到其类别，最好能在识别过程中同时解释类别的层级和来源。如何进行有解释的图片分类成为了项目研发中的一个需求，基于此我对NBDT算法进行了调研。NBDT

问题描述闲鱼是二手商品交易平台，当买家支付下单时，平台通过推送消息通知卖家；当卖家发货后，买家也会收到商品已发货推送消息。闲鱼的商品交易构建在消息会话之上，另外也需要消息推送让用户及时掌握二手商品交易动态和优惠活动信息。消息推送与用户体验息息相关，实时精准的消息推送有助于提升用户体验，为此我们专门针对闲鱼消息系统各个链路进行分析和优化，并取得了一定成果。接下来我们将通过技术视角介绍闲鱼消息系统现状、面临问题和优化方案，以期让读者了解消息系统设计理念和优化方向。闲鱼消息推送现状消息推送是移动互联网的基础设施，阿里内部也有很多消息推送平台，从系统分层上分为两种，第一种是与业务无关的建设消息推送底层能力的基础平台，负责对接操作系统的系统消息通道和各手机厂商的厂商消息通道，屏蔽各种通道差异，对外提供统一消息推送规范和能力；第二种是基于底层消息推送能力，与业务特点相结合后抽象设计的消息推送中台，闲鱼消息推送系统就属于第二种。问题抽象那么大家可能会对闲鱼消息推送系统存在的必要性存疑，比如为什么不复用手淘消息推送的架构和能力。实际上闲鱼消息推送系统有存在的必要性，这也是由闲鱼业务特点决定的。因为手淘消息会话模型是基于人与人的，两个人之间只会存在一个消息会话；而闲鱼的商品交易流转依赖消息触发，闲鱼消息会话模型是在人与人基础之上挂载商品，所以两个人之间可以存在多个消息会话。基础业务模型的差异导致上层消息推送系统有比较大的差异。闲鱼消息推送系统已经在线上稳定运行了很久，现有消息模型和系统性能基本满足业务需求。但随着闲鱼体量的增加，对消息推送整体的可靠性和性能提出更高要求，我们基于用户反馈对闲鱼消息推送系统的整体数据和架构进行review，发现一些影响用户体验需要优化的问题：调用底层消息推送平台的消息受理率比较低；通过系统通道和厂商通道的消息到达率和头部App相比有一定差距；云端之间缺少全链路采集和排查能力；前两个问题导致用户经常反馈收不到别人发的聊天消息，重要通知没有推送；最后一个问题导致消息推送逻辑偏向黑盒，对于用户问题排查和研发效率都造成了阻碍。基础依赖消息消息推送系统底层依赖ACCS和Agoo平台。ACCS和Agoo是阿里建设的底层消息推送平台，支撑了很多亿级设备应用的消息推送。ACCS是阿里无线向开发者提供全双工、低延时、高安全的通道服务，同时具备实时推送消息能力。ACCS是实时性更强的双向通道，支持业务上和用户产生实时的交互，展开各种形式的互动。Agoo是一个消息推送平台，基于客户端与服务端建立的长连接ACCS通道，可实时推送消息到用户端，是阿里无线端最基本的工具组件之一。当用户打开闲鱼App后，客户端会调用Agoo

背景高性能高流畅度一直是Flutter团队宣传的一大亮点，也是当初闲鱼选择Flutter的重要因素之一，但是随着复杂业务的应用落地，通过Flutter页面和原生页面滑动流畅度对比，我们开始产生怀疑，因为部分Flutter页面流畅度明显低于Native，是Flutter的宣传言过其实还是我们开发人员使用姿势有问题，今天我们就来具体分析下。Flutter渲染原理简介优化之前我们先来介绍下Flutter的渲染原理，通过这部分基础了解渲染流程以及主要耗时花费。Flutter视图树包含了三颗树：Widget、Element、RenderObjectWidget:

背景Serverless（无服务架构）被誉为下一代云计算，自概念推出以来，因为能带来研发交付速度提升与成本的降低在业内异常火爆。闲鱼客户端基于Flutter进行架构演进与创新，通过Flutter统一Android和iOS双端提升研发效能之后，希望通过Flutter+Serverless解决以下问题，从而进一步提升整体研发效率。各角色间存在大量的协同，导致整体研发效率低。移动端离业务越来越远，服务端没有时间做底层领域沉淀。研发架构的演进接下来我们带着这里两个问题回顾前后端研发架构演进的历史。PC互联网早期没有还没有前后端的概念，此阶段单个业务需求通常一个开发人员可以完成研发，前端网页与后端逻辑都写在一个工程中。随着业务越来越复杂，原本开发者负责前后端研发已经变得效率低下，此阶段随着移动互联网的爆发，服务端需要服务与PC、Android、iOS等多种前端。服务端总是有一个疑问：服务端设计接口时，是应该面向UI，还是应该面向通用服务？一个方案是抽取一部分服务端做BFF（Backend

最近小组在尝试使用集团DinamicX的DSL，通过下发DSL模板实现Flutter端的动态化模板渲染。在解决了性能方面的问题后，又面临了一个新的挑战——渲染一致性。如何在不降低渲染性能的前提下，大幅度提升Flutter与Native之间的渲染一致性呢？思路在初版渲染架构设计当中，我们以Widget为中心，采用了组合的方案来完成DSL到Widget的转化。这方面的工作在早期还算比较顺利，然而随着模板复杂度的增加，逐渐出现了一些Bad

sizedByParent之后，确保调用markNeedsLayoutForSizedByParentChange方法，将当前节点以及他的父节点设置为needsLayout，重新计算布局，重新绘制。

背景闲鱼作为电商场景的APP，最丰富的部分就是作为商品宝贝浏览承载的feeds，比如首页下面的宝贝信息流，搜索结果页以及详情页下面的猜你喜欢，这些feeds场景都少不了推荐算法在背后的支撑。我们观察到随着手机计算能力的提升，某些计算可以在端上直接计算，再统一上报到后端，这样相比云计算有很多明显的优势：1.