闲鱼flutter辟谣 2021年闲鱼严打

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

Flutter浪潮下的音视频研发探索

文/陈炉军

整理/LiveVideoStack

大家好，我是阿里巴巴闲鱼事业部的陈炉军，本次分享的主题是Flutter浪潮下的音视频研发探索，主要内容是针对闲鱼APP在当下流行的跨平台框架Flutter的大规模实践，介绍其在音视频领域碰到的一些困难以及解决方案。

分享内容主要分为四个方面，首先会对Flutter有一个简单介绍以及选择Flutter作为跨平台框架的原因，其次会介绍Flutter中与音视频关系非常大的外接纹理概念，以及对它做出的一些优化。之后会对闲鱼在音视频实践过程中碰到的一些Flutter问题提出了一些解决方案——TPM音视频框架。最后是闲鱼Flutter多媒体开源组件的介绍。

Flutter

Flutter是一个跨平台框架，以往的做法是将音频、视频和网络这些模块都下沉到C++层或者ARM层，在其上封装成一个音视频的SDK，供UI层的PC、iOS和Android调用。

而Flutter做为一个UI层的跨平台框架，顾名思义就是在UI层也实现了一个跨平台开发。可以预想的是未Flutter发展的好的话，会逐渐变为一个从底层到UI层的一个全链路的跨平台开发，技术人员分别负责SDK和UI层的开发。

在Flutter之前已经有很多跨平台UI解决方案，那为什么选择Flutter呢？

我们主要考虑性能和跨平台的能力。

以往的跨平台方案比如Weex，ReactNative，Cordova等等因为架构的原因无法满足性能要求，尤其是在音视频这种性能要求几乎苛刻的场景。

而诸如Xamarin等，虽然性能可以和原生App一致，但是大部分逻辑还是需要分平台实现。

我们可以看一下，为什么Flutter可以实现高性能：

原生的native组件渲染以IOS为例，苹果的UIKit通过调用平台自己的绘制框架QuaztCore来实现UI的绘制，图形绘制也是调用底层的API,比如OpenGL、Metal等。

而Flutter也是和原生API逻辑一致，也是通过调用底层的绘制框架层SKIA实现UI层。这样相当于Flutter他自己实现了一套UI框架，提供了一种性能超越原生API的跨平台可能性。

但是我们说一个框架最终性能怎样，其实取决于设计者和开发者。至于现在到底是一个什么状况：

在闲鱼的实践中，我们发现在正常的开发没有特意的去优化UI代码的情况下，在一些低端机上，Flutter界面的流畅性是比Native界面要好的。

虽然现在闲鱼某些场景下会有卡顿闪退等情况，但是这是一个新事物发展过程中的必然问题，我们相信未来性能肯定不会成为限制Flutter发展的瓶颈的。

在闲鱼实践Flutter的过程中，混合栈和音视频是其中比较难解决的两个问题，混合栈是指一个APP在Flutter过程中不可能一口气将所有业务全部重写为Flutter，所以这是一个逐步迭代的过程，这期间原生native界面与Flutter界面共存的状态就称之为混合栈。闲鱼在混合栈上也有一些比较好的输出，例如FlutterBoost。

外接纹理

在讲音视频之前需要简要介绍一下外接纹理的概念，我们将它称之为是Flutter和Frame之间的桥梁。

Flutter渲染一帧屏幕数据首先要做的是，GPU发出的VC信号在Flutter的UI线程，通过AOT编译的机器码结合当前Dart Runtime，生成Layer Tree UI树，Layer Tree上每一个叶子节点都代表了当前屏幕上所需要渲染的每一个元素，包含了这些元素渲染所需要的内容。将Layer Tree抛给GPU线程，在GPU线程内调用Skia去完成整个UI的渲染过程。Layer Tree中有PictureLayer和TextureLayer两个比较重要的节点。PictureLayer主要负责屏幕图片的渲染，Flutter内部实现了一套图片解码逻辑，在IO线程将图片读取或者从网络上拉取之后，通过解码能够在IO线程上加载出纹理，交给GPU线程将图片渲染到屏幕上。但是由于音视频场景下系统API太过繁多，业务场景过于复杂。Flutter没有一套逻辑去实现跨平台的音视频组件，所以说Flutter提出了一种让第三方开发者来实现音视频组件的方式，而这些音视频组件的视频渲染出口，就是TextureLayer。

在整个Layer Tree渲染的过程中，TextureLayer的数据纹理需要由外部第三方开发者来指定，可以把视频数据和播放器数据送到TextureLayer里，由Flutter将这些数据渲染出来。

TextureLayer渲染过程：首先判断Layer是否已经初始化，如果没有就创建一个Texture，然后将Texture Attach到一个SufaceTexture上。

这个SufaceTexture是音视频的native代码可以获取到的对象，通过这个对象创建的Suface，我们可以将视频数据、摄像头数据解码放到Suface中，然后Flutter端通过监听SufaceTexture的数据更新就可以顺利把刚才创建的数据更新到它的纹理中，然后再将纹理交给SKIA渲染到屏幕上。

然而我们如果需要用Flutter实现美颜，滤镜，人脸贴图等等功能，就需要将视频数据读取出来，更新到纹理中，再将GPU纹理经过美颜滤镜处理后生成一个处理后的纹理。按Flutter提供的现有能力，必须先将纹理中的数据从GPU读出到CPU中，生成Bitmap后再写入Surface中，这样在Flutter中才能顺利的更新到视频数据，这样做对系统性能的消耗很大。

通过对Flutter渲染过程分析，我们知道Flutter底层需要渲染的数据就是GPU纹理，而我们经过美颜滤镜处理完成以后的结果也是GPU纹理，如果可以将它直接交给Flutter渲染，那就可以避免GPU-CPU-GPU这样的无用循环。这样的方法是可行的，但是需要一个条件，就是OpenGL上下文共享。

OpenGL

在说上下文之前，得提到一个和上线文息息相关的概念：线程。

Flutter引擎启动后会启动四个线程：

第一个线程是UI线程，这是Flutter自己定义的UI线程，主要负责GPU发出的VSync信号时候用当前Dart编译的机器码和当前运行环境创建出Layer Tree。

还有就是IO线程和GPU线程。和大部分OpenGL处理解决方案中一样，Flutter也采取一个线程责资源加载，一部分负责资源渲染这种思路。

两个线程之间纹理共享有两种方式。一种是EGLImage(IOS是 CVOpenGLESTextureCache)。一种是OpenGL Share Context。Flutter通过Share Context来实现纹理共享，将IO线程的Context和GPU线程的Context进行Share，放到同一个Share Group下面，这样两个线程下资源是互相可见可以共享的。

Platform线程是主线程，Flutter中有一个很奇怪的设定，GPU线程和主线程共用一个Context。并且在主线程也有很多OpenGL 操作。

这样的设计会给音视频开发带来很多问题，后面会详细说。

音视频端美颜处理完成的OpenGL纹理能够让Flutter直接使用的条件就是Flutter的上下文需要和平台音视频相关的OpenGL上下文处在一个Share Group下面。

由于Flutter主线程的Context就是GPU的Context，所以在音视频端主线程中有一些OpenGL操作的话，很有可能使Flutter整个OpenGL被破坏掉。所以需要将所有的OpenGL操作都限制在子线程中。

通过上述这两个条件的处理，我们就可以在没有增加GPU消耗的前提下实现美颜和滤镜等等功能。

TPM

在经过demo验证之后，我们将这个方案应用到闲鱼音视频组件中，但改造过程中发现了一些问题。

上图是摄像头采集数据转换为纹理的一段代码，其中有两个操作：首先是切进程，将后面的OpenGL操作都切到cameraQueue中。然后是设置一次上下文。然后这种限制条件或者说是潜规则往往在开发过程中容易被忽略的。而这个条件一旦忽略后果就是出现一些莫名其妙的诡异问题极难排查。因此我们就希望能抽象出一套框架，由框架本身实现线程的切换、上下文和模块生命周期等的管理，开发者接入框架以后只需要安心实现自己的算法，而不需要关心这些潜规则还有其他一些重复的逻辑操作。

在引入Flutter之前闲鱼的音视频架构与大部分音视频逻辑一样采用分层架构：

1：底层是一些独立模块

2：SDK层是对底层模块的封装

3：最上层是UI层。

引入Flutter之后，通过分析各个模块的使用场景，我们可以得出一个假设或者说是抽象：音视频应用在终端上可以归纳为视频帧解码之后视频数据帧在各个模块之间流动的过程，基于这种假设去做Flutter音视频框架的抽象。

咸鱼Flutter多媒体开源组件

整个Flutter音视频框架抽象分为管线和数据的抽象、模块的抽象、线程统一管理和上下文同一管理四部分。

管线，其实就是视频帧流动的管道。数据，音视频中涉及到的数据包括纹理、Bit Map以及时间戳等。结合现有的应用场景我们定义了管线流通数据以Texture为主数据，同时可以选择性的添加Bit Map等作为辅助数据。这样的数据定义方式，避免重复的创建和销毁纹理带来的性能开销以及多线程访问纹理带来的一些问题。也满足一些特殊模块对特殊数据的需求。同时也设计了纹理池来管理管线中的纹理数据。

模块：如果把管线和数据比喻成血管和血液，那框架音视频的场景就可以比喻成器官，我们根据模块所在管线的位置抽象出采集、处理和输出三个基类。这三个基类里实现了刚才说的线程切换，上下文切换，格式转换等等共同逻辑，各个功能模块通过集成自这些基类，可以避免很多重复劳动。

线程：每一个模块初始化的时候，初始化函数就会去线程管理的模块去获取自己的线程，线程管理模块可以决定给初始化函数分配新的线程或者已经分配过其他模块的线程。

这样有三个好处：

一是可以根据需要去决定一个线程可以挂载多少模块，做到线程间的负载均衡。第二，多线程并发式能够保证模块内的OpenGL操作是在当前线程内而不会跑到主线程去，彻底避免Flutter的OpenGL 环境被破坏。第三，多线程并行可以充分利用CPU多核架构，提升处理速度。

从Flutter端修改Flutter引擎将Context取出后，根据Context创建上下文的统一管理模块，每一个模块在初始化的时候会获取它的线程，获取之后会调用上下文管理模块获取自己的上下文。这样可以保证每一个模块的上下文都是与Flutter的上下文进行Share的，每个模块之间资源都是共享可见的，Flutter和音视频native之间也是互相共享可见的。

基于上述框架如果要实现一个简单的场景，比如画面实时预览和滤镜处理功能，

1：需要选择功能模块，功能模块包括摄像头模块、滤镜处理模块和Flutter画面渲染模块，

2：需要配置模块参数，比如采集分辨率、滤镜参数和前后摄像头设置等，

3：在创建视频管线后使用已配置的参数创建模块

4：最后管线搭载模块，开启管线就可以实现这样简单的功能。

上图为整个功能实现的代码和结构图。

结合上述音视频框架，闲鱼实现了Flutter多媒体开源组件。

组要包含四个基本组件分别是：

1：视频图像拍摄组件

2：播放器组件

3：视频图像编辑组件

4：相册选择组件

现在这些组件正在走内部开源流程。预计9月份，相册和播放器会实现开源。

后续展望和规划

1：实现开头所说的从底层SDK到UI的全链路的跨端开发。目前底层框架层和模块层都是各个平台各自实现，反而是Flutter的UI端进行了跨平台的统一，所以后续会将底层也按照音视频常用做法把逻辑下沉到C++层，尽可能的实现全链路跨平台。

2：第二部分内容为开源共建，闲鱼开源的内容不仅包括拍摄、编辑组件，还包括了很多底层模块，希望有开发者在基于Flutter开发音视频应用时可以充分利用闲鱼开源出的音视频模块能力，搭建APP框架，开发者只要去负责实现特殊需求模块就可以，尽可能的减少重复劳动。

相关问答

Q1: Flutter BottomAppBar 自定义路径 + 贝塞尔曲线实现闲鱼底部导航

网上已经有不少文章展示如何使用 CircularNotchedRectangle 或 AutomaticNotchedShape 实现带凹陷效果的 BottomAppBar，但是都没有提到如何自定义 NotchedShape 实现任意形状的 BottomAppBar，本文以闲鱼底部导航为例展示如何自定义 NotchedShape。

首先假设你已经知道如何使用 CircularNotchedRectangle 创建凹陷效果，我们主要做的就是写一个新的 class 继承 NotchedShape 来实现我们想要的效果。

在开始写 NotchedShape 之前我们先准备好一个正常的 BottomAppBar，因为不是重点，具体的实现就不展开说了，看起来像是这样的：

唯一值得一提的是，中间的按钮是一个正常的 FloatingActionButton ，为了让它比原来大并能超出 BottomAppBar 而使用了 Transform.scale 。

接下来，我们创建新的 class CustomNotchedShape 继承 NotchedShape 并 override getOuterPath ：

NotchedShape 和 CustomClipperPath 很像，都是通过创建一个 path 来定义我们想要的形状，如果你有 CustomClipperPath 的经验，那 NotchedShape 也就差不多了。唯一不一样的是 Path getOuterPath(Rect host, Rect? guest) 有两个参数， host 在这里就是 BottomAppBar 本身的矩形边界， guest 则是嵌入 BottomAppBar 的矩形边界。由于我们并不需要嵌入 guest，第二个参数可以忽略掉。

我们可以先简单写一个梯形 path 来验证。

效果：

知道怎么使用 path 创建自定义形状之后就可以思考如何实现闲鱼底部导航的效果了，经过观察，这样的效果可以由圆弧或贝塞尔曲线组合而成，使用贝塞尔曲线可能是最简单的，而且只需要一个控制点的贝塞尔曲线。

我们可以先画轮廓直线，然后再换成单个控制点的贝塞尔曲线即可。

lx 和 ly 是旁边两条斜线的 x、y，radius 是顶部横线的长度。

然后我们替换成贝塞尔曲线以及选择合适的控制点，再引入两个变量 bx、by 作为控制点的 x、y 偏移量，所有参数调整到合适到值之后即可实现最终效果：

源码：

DartPad 在线演示： ;id=a976bbb3961a8c5f5998a54c8d2ed7aa

Q2: 阿里IM技术分享(六)：闲鱼亿级IM消息系统的离线推送到达率优化

本文由阿里闲鱼技术团队逸昂分享，原题“消息链路优化之弱感知链路优化”，有修订和改动，感谢作者的分享。

闲鱼的IM消息系统作为买家与卖家的沟通工具，增进理解、促进信任，对闲鱼的商品成交有重要的价值，是提升用户体验最关键的环节。

然而，随着业务体量的快速增长，当前这套消息系统正面临着诸多急待解决的问题。

以下几个问题典型最为典型：

1）在线消息的体验提升；

2）离线推送的到达率；

3）消息玩法与消息底层系统的耦合过强。

经过评估，我们认为现阶段离线推送的到达率问题最为关键，对用户体验影响较大。

本文将要分享的是闲鱼IM消息在解决离线推送的到达率方面的技术实践，内容包括问题分析和技术优化思路等，希望能带给你启发。

（本文已同步发布于：）

本文是系列文章的第6篇，总目录如下：

《阿里IM技术分享(一)：企业级IM王者——钉钉在后端架构上的过人之处》

《阿里IM技术分享(二)：闲鱼IM基于Flutter的移动端跨端改造实践》

《阿里IM技术分享(三)：闲鱼亿级IM消息系统的架构演进之路》

《阿里IM技术分享(四)：闲鱼亿级IM消息系统的可靠投递优化实践》

《阿里IM技术分享(五)：闲鱼亿级IM消息系统的及时性优化实践》

《阿里IM技术分享(六)：闲鱼亿级IM消息系统的离线推送到达率优化》（* 本文）

从数据通信链接的技术角度，我们根据闲鱼客户端是否在线，将整体消息链路大致分为强感知链路和弱感知链路。

强感知链路由以下子系统或模块：

1）发送方客户端；

2） idleapi-message（闲鱼的消息网关）；

3） heracles（闲鱼的消息底层服务）；

4） accs（阿里自研的长连接通道）；

5）接收方客户端组成。

整条链路的核心指标在于端到端延迟和消息到达率。

强感知链路中的双方都是在线的，消息到达客户端就可以保证接收方感知到。强感知链路的主要痛点在消息的端到端延迟。

弱感知链路与强感知链路的主要不同在于：弱感知链路的接收方是离线的，需要依赖离线推送这样的方式送达。

因此弱感知链路的用户感知度不强，其核心指标在于消息的到达率，而非延迟。

所以当前阶段，优化弱感知链路的重点也就是提升离线消息的到达率。换句话说，提升离线消息到达率问题，也就是优化弱感知链路本身。

下图一张整个IM消息系统的架构图，感受下整体链路：

如上图所示，各主要组件和子系统分工如下：

1） HSF是一个远程服务框架，是dubbo的内部版本；

2） tair是阿里自研的分布式缓存框架，支持 memcached、Redis、LevelDB 等不同存储引擎；

3） agoo是阿里的离线推送中台，负责整合不同厂商的离线推送通道，向集团用户提供一个统一的离线推送服务；

4） accs是阿里自研的长连接通道，为客户端、服务端的实时双向交互提供便利；

5） lindorm是阿里自研的NoSQL产品，与HBase有异曲同工之妙；

6）域环是闲鱼消息优化性能的核心结构，用来存储用户最新的若干条消息。

强感知链路和弱感知链路在通道选择上是不同的：

1）强感知链路使用accs这个在线通道；

2）弱感知链路使用agoo这个离线通道。

通俗了说，弱感知链路指的就是离线消息推送系统。

相比较于在线消息和端内推送（也就是上面说的强感知链路），离线推送难以确保被用户感知到。

典型的情况包括：

1）未发送到用户设备：即推送未送达用户设备，这种情况可以从通道的返回分析；

2）发送到用户设备但没有展示到系统通知栏：闲鱼曾遇到通道返回成功，但是用户未看到推送的案例；

3）展示到通知栏，并被系统折叠：不同安卓厂商对推送的折叠策略不同，被折叠后，需用户主动展开才能看到内容，触达效果明显变差；

4）展示到通知栏，并被用户忽略：离线推送的点击率相比于在线推送更低。

针对“1）未发送到用户设备”，原因有：

1）离线通道的token失效；

2）参数错误；

3）用户关闭应用通知；

4）用户已卸载等。

针对“3）展示到通知栏，并被系统折叠”，原因有：

1）通知的点击率；

2）应用在厂商处的权重；

3）推送的数量等。

针对“4）展示到通知栏，并被用户忽略”，原因有：

1）用户不愿意查看推送；

2）用户看到了推送，但是对内容不感兴趣；

3）用户在忙别的事，无暇处理。

总之：以上这些离线消息推送场景，对于用户来说感知度不高，我们也便称之为弱感知链路。

我们的弱感知链路分为3部分，即：

1）系统；

2）通道；

3）用户。

共包含了Hermes、agoo、厂商、设备、用户、承接页这几个环节。具体如下图所示。

从推送的产生到用户最终进入APP，共分为如下几个步骤：

步骤1 ：Hermes是闲鱼的用户触达系统，负责人群管理、内容管理、时机把控，是整个弱感知链路的起点。；

步骤2 ：agoo是阿里内部承接离线推送的中台，是闲鱼离线推送能力的基础；

步骤3 ：agoo实现离线推送依靠的是厂商的推送通道（如：苹果的 apns通道、Google的fcm通道、及国内各厂商的自建通道。；

步骤4 ：通过厂商的通道，推送最终出现在用户的设备上，这是用户能感知到推送的前提条件；

步骤5 ：如果用户刚巧看到这条推送，推送的内容也很有趣，在用户的主动点击下会唤起APP，打开承接页，进而给用户展示个性化的商品。

经过以上5个步骤，至此弱感知链路就完成了使命。

弱感知链路的核心问题在于：

1）推送的消息是否投递给了用户；

2）已投递到的消息用户是否有感知。

这对应推送的两个阶段：

1）推送消息是否已到达设备；

2）用户是否查看推送并点击。

其中：到达设备这个阶段是最基础的，也是本次优化的核心。

我们可以将每一步的消息处理量依次平铺，展开为一张漏斗图，从而直观的查看链路的瓶颈。

漏斗图斜率最大的地方是优化的重点，差异小的地方不需要优化：

通过分析以上漏斗图，弱感知链路的优化重点在三个方面：

1） agoo受理率：是指我们发送推送请到的数量到可以通过agoo（阿里承接离线推送的中台）转发到厂商通道的数量之间的漏斗；

2）厂商受理率：是指agoo中台受理的量到厂商返回成功的量之间的漏斗；

3） Push点击率：也就通过以上通道最终已送到到用户终端的消息，是否最终转化为用户的主动“点击”。

有了优化方向，我们来看看优化手段吧。

跟随推送的视角，顺着链路看一下我们是如何进行优化的。

用户的推送，从 Hermes 站点搭乘“班车”，驶向下一站： agoo 。

这是推送经历的第一站。到站一看，傻眼了，只有不到一半的推送到站下车了。这是咋回事嘞？

这就要先说说 agoo 了，调用 agoo 有两种方式：

1）指定设备和客户端，agoo直接将推送投递到相应的设备；

2）指定用户和客户端，agoo根据内部的转换表，找到用户对应的设备，再进行投递。

我们的系统不保存用户的设备信息。因此，是按照用户来调用agoo的。

同时：由于没有用户的设备信息，并不知道用户是 iOS 客户端还是 Android 客户端。工程侧不得不向 iOS 和 Android 都发送一遍推送。虽然保证了到达，但是，一半的调用都是无效的。

为了解这个问题：我们使用了agoo的设备信息。将用户转换设备这一阶段提前到了调用 agoo 之前，先明确用户对应的设备，再指定设备调用 agoo，从而避免无效调用。

agoo调用方式优化后，立刻剔除了无效调用，agoo受理率有了明显提升。

至此：我们总算能对 agoo 受理失败的真正原因做一个高大上的分析了。

根据统计：推送被 agoo 拒绝的主要原因是——用户关闭了通知权限。同时，我们对 agoo 调用数据的进一步分析发现——有部分用户找不到对应的设备。优化到此，我们猛然发现多了两个问题。

那就继续优化呗：

1）通知体验优化，引导打开通知权限；

2）与agoo共建设备库，解决设备转换失败的问题。

这两个优化方向又是一片新天地，我们择日再聊。

推送到达 agoo ，分机型搭乘厂商“专列”，驶向下一站：用户设备。

这是推送经历的第二站。出站查票，发现竟然超员了。

于是乎：我们每天有大量推送因为超过厂商设定的限额被拦截。

为什么会这样呢？

实际上：提供推送通道的厂商（没错，各手机厂商的自家推送通道良莠不齐），为了保证用户体验，会对每个应用能够推送的消息总量进行限制。

对于厂商而言，这个限制会根据推送的类型和应用的用户规模设定——推送主要分为产品类的推送和营销类的推送。

厂商推送通道对于不同类型消息的限制是：

1）对于产品类推送，厂商会保证到达；

2）对于营销类推送，厂商会进行额度限制；

3）未标记的推送，默认作为营销类推送对待。

我们刚好没有对推送进行标记，因此触发了厂商的推送限制。

这对我们的用户来说，会带来困扰。闲鱼的交易，很依赖买卖家之间的消息互动。这部分消息是需要确保到达的。

同样：订单类的消息、用户的关注，也需要保证推送给用户。

根据主流厂商的接口协议，我们将推送的消息分为以下几类，并进行相应标记：

1）即时通讯消息；

2）订单状态变化；

3）用户关注内容；

4）营销消息这几类。

同时，在业务上，我们也进行了推送的治理——将用户关注度不高的消息，取消推送，避免打扰。

经过这些优化，因为超过厂商限额而被拦截的推送实现了清零。

通过优化agoo受理率、厂商受理率，我们解决了推送到达量的瓶颈。但即使消息被最终送达，用户到底点击了没有？这才是消息推送的根本意义所在。

于是，在日常的开发测试过程中，我们发现了推送的两个体验问题：

1）用户点击Push有开屏广告；

2）营销Push也有权限校验，更换用户登陆后无法点击。

对于开屏广告功能，我们增加了Push点击跳过广告的能力。

针对Push的权限校验功能，闲鱼根据场景做了细分：

1）涉及个人隐私的推送，保持权限校验不变；

2）营销类的推送，放开权限校验。

以上是点击体验的优化，我们还需要考虑用户的点击意愿。

用户点击量与推送的曝光量、推送素材的有趣程度相关。推送的曝光量又和推送的到达量、推送的到达时机有关。

具体的优化手段是：

1）在推送内容上：我们需要优化的是推送的时机和相应的素材；

2）在推送时机上：算法会根据用户的偏好和个性化行为数据，计算每个用户的个性化推送时间，在用户空闲的时间推送（避免在不合适的时间打扰用户，同时也能提升用户看到推送的可能性）。

3）在推送素材上：算法会根据素材的实时点击反馈，对素材做实时赛马。只发用户感兴趣的素材，提高用户点击意愿。

通过以上我们的分析和技术优化手段，整体弱推送链路链路有了不错的提升，离线消息的到达率相对提升了两位数。

本篇主要和大家聊的是只是IM消息系统链路中的一环——弱感知链路的优化，落地到到具体的业务也就是离线消息送达率问题。

整体IM消息系统，还是一个比较复杂的领域。

我们在消息系统的发展过程中，面临着如下问题：

1）如何进行消息的链路追踪；

2）如何保证IM消息的快速到达（见《闲鱼亿级IM消息系统的及时性优化实践》)；

3）如何将消息的玩法和底层能力分离；

4）离线推送中如何通过用户找到对应的设备。

这些问题，我们在以前的文章中有所分享，以后也会陆续分享更多，敬请期待。

[1] Android P正式版即将到来：后台应用保活、消息推送的真正噩梦

[2] 一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践

[3] 一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等

[4] 一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等

[5] 从新手到专家：如何设计一套亿级消息量的分布式IM系统

[6] 企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等

[7] 融云技术分享：全面揭秘亿级IM消息的可靠投递机制

[8] 移动端IM中大规模群消息的推送如何保证效率、实时性？

[9] 现代IM系统中聊天消息的同步和存储方案探讨

[10] 新手入门一篇就够：从零开发移动端IM

[11] 移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”

[12] 移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结

[13] IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递

[14] IM消息送达保证机制实现(二)：保证离线消息的可靠投递

[15] 零基础IM开发入门(一)：什么是IM系统？

[16] 零基础IM开发入门(二)：什么是IM系统的实时性？

[17] 零基础IM开发入门(三)：什么是IM系统的可靠性？

[18] 零基础IM开发入门(四)：什么是IM系统的消息时序一致性？

（本文已同步发布于：）

Q3: Archsummit 2019重磅分享｜闲鱼Flutter＆FaaS云端一体化架构

作者：闲鱼技术－国有

国有，闲鱼架构团队负责人。在7月13号落幕的2019年Archsummit峰会上就近一年来闲鱼在FlutterFaaS一体化项目上的探索和实践进行了分享。

随着无线，IoT的发展，5G的到来，移动研发越发向多端化发展。传统的基于Native＋Web＋服务端的开发方式，研发效率低下，显然已经无法适应发展需要。

我们希望探索闲鱼这样规模的独立APP的高效研发架构。主要思路是围绕Flutter解决多端问题，并使Flutter与FaaS等无服务容能力打通，形成云端一体化的研发能力，支持一云多端的发展需要。在某些场景已经取得效果，希望分享过程中的思考，与大家交流。

闲鱼选择Flutter主要是出于高性能的考虑。Flutter高性能主要来源于2个原因：

更多比较：

没有银弹的解决方案，Flutter与RN各有优点。如何选择因素很多，关键看如何取舍，举个例子：

云端技术栈的打通，是减少协同的不错的解法。以往前端＋Node.js的一体化方案大家应该不会陌生，然而如果端侧使用了Flutter，那云侧Dart自然是第一选择。

FaaS的本质是运行在云端，那Dart适合用在云/Server上吗？

Dart语言早于Flutter，在最初的设计上，Dart就可以用于Web、Server。Dart具备一些服务端语言的特点：

闲鱼首先尝试将Dart作为普通的Server，替代传统的Java　Server，然后再将Dart容器嵌入到FaaS容器中。建立Dart Server能力是第一步，也是主要的工作量所在。

闲鱼在Dart　Server方面的建设思路：

开发期：

运行期：

上述内容实现了FlutterDart FaaS的技术栈的统一，但仅技术栈统一还远远不够，端、云的同学仍然无法真正互补和一体化打通，原因在于还有更多深入问题需要考虑：

面向这些问题，闲鱼的解法思路：

案例一，一体化在资源均衡方面的体现。在近期的一个项目中，云端一体化使原本2个月的项目时间，减少了20天。

案例二，一体化在业务闭环方面的体现。负责增长的一位开发同学，专注在增长业务上，在合适的情况下为合适的人投放合适的内容，以此带来用户的增长和活跃效果。一体化的方式下，可以统一云、端的切面，业务研发不再受云、端的限制。

一体化是建设高效研发框架的方向，并不是所有场景都需要一体化的开发，但一体化的Flutter、FaaS等技术组件，可以独立使用，也会带来效率提升，并且与原有的开发模式兼容。从一体化的思路去建设，可以使整体架构体系更加一致，也有机会做一体的架构沉淀。

未来闲鱼希望在一体化上做更多尝试和深入探索，包括一体化工具、一体化业务平台、数据化智能化等方向。

Q4: Flutter动态化方案调研

腾讯课堂14M

今日头条3M

闲鱼22M

百度贴吧13M

蚂蚁财富56.8M

百度网盘14M

手机淘宝15M

贝壳找房8M

由粗粒度小组件动态拼装出页面，Native端已经有很多成熟的框架，如天猫的Tangram。

开发语言：iOS、Android

适用场景：快速迭代的活动营销页面

优点：无侵入，更新简单

缺点：提前预埋，扩展性差，灵活性差

以webview作为容器的app，历史悠久，最早到2011年。

开发语言：HTML

适用场景：双端严格一致的银行类app，容器类的支付宝小程序等

优点：动态更新，跨平台

缺点：性能，加载速度

UI用Xml+JS表达，用Native View渲染。

开发语言：Xml+JS

适用场景：双端严格一致的银行类app，容器类的支付宝小程序等

优点：native组件，生态成熟

缺点：三方库crash，性能缺陷

UI用Dart表达，用Dart engine渲染。

Flutter官方不支持动态化。原因是Flutter在 Release 模式下构建的是 AOT 编译产物，在 Debug 模式下构建的是 JIT ，AOT 依赖的 Dart VM 和 JIT 并不一样， JIT Release 并不支持 iOS 设备。可行的方案是：AOT 需要一个编译后的 “Dart VM”。抽离一份 DartVM 独立编译，再以动态库的形式引入项目。

开发语言：Dart

适用场景：iOS、Android、Web、Desktop、Embed

优点：性能最佳

缺点：增大包体积 20MB+

大厂的主流方案。UI用JS表达，用Dart engine渲染。

开发语言：JS、类JS

适用场景：iOS、Android

优点：性能最佳

缺点：需要掌握JS、Dart两个语言和框架

大厂的主流方案。UI用Dart表达，用Dart engineX渲染。

开发语言：Dart

适用场景：iOS、Android

优点：性能最佳

缺点：需要改造Dart engine

1、美团外卖Flutter动态化实践

2、携程App 首页动态化探索

3、 Flutter 动态化在最右 App 中的实践

4、 Flutter 动态化热更新的思考与实践

5、 NOW直播Flutter动态搜索列表页实现

6、 Flutter动态化的方案对比及最佳实现-闲鱼

7、基于JavaScript 的MXFlutter

Q5: 开源精粹（二）！22个实用、有趣的开源项目

作为一名开源爱好者，发掘优秀的开源项目是一件非常有趣的事情。在第一期中，我分享了单页个人网站模板、组装式 Flutter 应用框架、PHP 客户端库、Java 诊断工具等一些实用的库和工具。本期依旧会为大家分享一些前端、后端、移动开发的相关工具，希望你能“淘”到适合自己的工具。

1.Vue-EasyTable

Vue-EasyTable 是一款基于 Vue2.x 的 table 组件，具备自适应、表头与列固定、自定义单元格样式、自定义 Loading 等功能。

2.React-Calendar

这是一款具备原生日期格式的日历组件。它不依赖 Moment.js，支持日期选择范围，涵盖了各国语言，开箱即用。

3.Matter

CSS 实现的 Material 组件合集项目，作者已将部分作品开源，效果可以在 CodePen 上查看。

4.Revery

Revery 是一款用于构建高性能、跨平台桌面应用的框架。它类似于加速版的原生 Electron，除了拥有类似 React / Redux 的库，还具备 GPU 加速渲染功能，其内置的编译器速度也相当快。

5.Web Accessibility Guide

这是一个精选了 Web 可访问性贴士、技巧和最佳实践的开源项目，你将会学习到一些改善 Web 可访问性的实用做法。

1.SOFAJRaft

SOFAJRaft 是蚂蚁金服开源的生产级 Java Raft 算法库，它基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景，易于使用。

2. Dragonwell

阿里开源了 OpenJDK 发行版 Dragonwell，它提供长期支持，包括性能增强和安全修复。在数据中心大规模 Java 应用部署情况下，可以大幅度提高稳定性、效率以及性能。

3.Lawoole

Lawoole 是一款基于 Laravel 和 Swoole 的高性能 PHP 框架。它兼具了 Laravel 的特点，还解决了其功能背后的性能问题。同时，你还能感受到与 Laravel 一样的编码体验。

4.AntNest

AntNest 是一个简洁、快速的异步爬虫框架。它仅有 600 行代码，基于 Python 3.6+.

5.PHP-Awesome

这个仓库汇集了 PHP 优秀的资源，供你查询和参考。

1.FlutterBoost

FlutterBoost 是闲鱼开源的新一代 Flutter-Native 混合解决方案。它能够帮你处理页面的映射和跳转，你只需要关心页面的名字和参数即可。

2.MyLayout

MyLayout 是一套 iOS 界面视图布局框架，可谓 iOS 下的界面布局利器。它集成了 iOS Autolayout、Size Classes、Android 的 5 大布局体系、HTML/CSS 的浮动定位技术以及 Flex-Box 和 Bootstrap 框架等主流的平台的界面布局功能，并提供了一套简单、完备的多屏幕尺寸适配的解决方案。

3.SegementSlide

SegementSlide 是一个 iOS UI 库，它具备完整的滑滚及切换组件，旨在解决多层 UIScrollView 嵌套滚动的问题。

1.DevHub

DevHub 是一款跨平台的 GitHub 通知管理客户端，支持 Android、 iOS、网页和桌面上使用，帮助你便捷的接收 GitHub 各类通知。

2.Reqman

Reqman 是一个帮助后端工程师进行 API 测试的工具，同时也是一个基于 Node.js 的爬虫工具。

3.FreeCodeCamp

说到 FreeCodeCamp，或许大家不会陌生，而这个项目就是他们建立的开源课程和相应的代码库。网站提供了 6 大认证课程，也涉及了全栈开发认证。如果你感兴趣，不妨了解下。

4.Gitter

Gitter 是 GitHub 小程序客户端，作者采用 Taro 框架 + Taro UI 进行开发，而小程序内数据则来自 GitHub Api V3.

5.Awesome Podcasts

这个项目收集了各类实用的播客，涵盖了主流的编程语言，希望对你提升技术水平有所帮助。