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框架，开发者只要去负责实现特殊需求模块就可以，尽可能的减少重复劳动。

‍

本文由阿里闲鱼技术团队祈晴分享，本次有修订和改动，感谢作者的技术分享。

1、内容概述

本文总结了阿里闲鱼技术团队使用Flutter在对闲鱼IM进行移动端跨端改造过程中的技术实践等，文中对比了传统Native与现在大热的Flutter跨端方案在一些主要技术实现上的差异，以及针对Flutter技术特点的具体技术实现，值得同样准备使用Flutter开发IM的技术同行们借鉴和参考。

学习交流：

- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》

- 开源IM框架源码：>

（本文同步发布于：>2、闲鱼IM现状

闲鱼IM的移动端框架构建于2016至2017年间，期间经过多次迭代升级导致历史包袱累积多，后面又经历IM界面的Flutter化，从而造成了客户端架构愈加复杂。

从开发层面总结闲鱼IM移动端当前架构主要存在如下几个问题：

1）研发效率较低：当前架构涉及到Android/iOS双端的逻辑代码以及Flutter的UI代码，定位问题往往只能从Flutter UI表相倒查到Native逻辑层；2）架构层次较差：架构设计上分层不清晰，业务逻辑夹杂在核心的逻辑层致使代码变更风险大；3）性能测试略差：核心数据源存储Native内存，需经Flutter Plugin将数据源序列化上抛Flutter侧，在大批量数据源情况下性能表现较差。

从产品层面总结闲鱼IM移动端当前架构的主要问题如下：

1）定位问题困难：线上舆情反馈千奇百怪，测试始终无法复现相关场景，因此很多时候只能靠现象猜测本质；2）疑难杂症较多：架构的不稳定性造成出现的问题反复出现，当前疑难杂症主要包括未读红点计数、iPhone5C低端机以及多媒体发送等多个问题；3）问题差异性大：Android和iOS两端逻辑代码差异大，包括埋点逻辑都不尽相同，排查问题根源时双端都会有不同根因，解决方案也不相同。3、业界的移动端跨端方案

为解决当前IM的技术痛点，闲鱼今年特起关于IM架构升级项目，重在解决客户端中Andriod和iOS双端一致性的痛点，初步设想方案就是实现跨端统一的Android/iOS逻辑架构。

在当前行业内跨端方案可初步归类如下图架构：

在GUI层面的跨端方案有Weex、ReactNative、H5、Uni-APP等，其内存模型大多需要通过桥接到Native模式存储。

在逻辑层面的跨端方案大致有C/C++等与虚拟机无关语言实现跨端，当然汇编语言也可行。

此外有两个独立于上述体系之外的架构就是Flutter和KMM（谷歌基于Kotlin实现类似Flutter架构），其中Flutter运行特定DartVM，将内存数据挂载其自身的isolate中。

考虑闲鱼是Flutter的前沿探索者，方案上优先使用Flutter。然而Flutter的isolate更像一个进程的概念（底层实现非使用进程模式），相比Android，同一进程场景中，Android的Dalvik虚拟机多个线程运行共享一个内存Heap，而DartVM的Isolate运行隔离各自的Heap，因而isolate之间通讯方式比较繁琐（需经过序列化反序列化过程）。

整个模型如下图所示：

若按官方混合架构实现Flutter应用，开启多个FlutterAcitivty/FlutterController，底层会生成多个Engine，对应会存在多个isolate，而isolate通讯类似于进程通讯（类似socket或AIDL），这里借鉴闲鱼FlutterBoost的设计理念，FlutterIM架构将多个页面的Engine共享，则内存模型就天然支持共享读取。

原理图如下：

4、闲鱼IM基于Flutter的架构设计

41 新老架构对比

如下图所示：是一个老架构方案，其核心问题主要集中于Native逻辑抽象差，其中逻辑层面还设计到多线程并发使得问题倍增，Android/iOS/Flutter交互繁杂，开发维护成本高，核心层耦合较为严重，无插拔式概念

考虑到历史架构的问题，演进如下新架构设计：

如上图所示，架构从上至下依次为：

1）业务层；2）分发层；3）逻辑层；4）数据源层。

数据源层来源于推送或网络请求，其封装于Native层，通过Flutter插件将消息协议数据上抛到Flutter侧的核心逻辑层，处理完成后变成Flutter DB的Enitity实体，实体中挂载一些消息协议实体。

核心逻辑层将繁杂数据扁平化打包挂载到分发层中的会话内存模型数据或消息内存模型数据，最后通过观察者模式的订阅分发到业务逻辑中。

Flutter IM重点集中改造逻辑层和分发层，将IM核心逻辑和业务层面数据模型进行封装隔离，核心逻辑层和数据库交互后将数据封装到分发层的moduleData中，通过订阅方式分发到业务层数据模型中。

此外在IM模型中DB也是重点依赖的，个人对DB数据库管理进行全面封装解，实现一种轻量级，性能佳的Flutter DB管理框架。

42 DB存储模型

Flutter IM架构的DB存储依赖数据库插件，目前主流插件是Sqflite。

其存储模型如下：

依据上图Sqflite插件的DB存储模型会有2个等待队列：

一个是Flutter层同步执行队列；一个是Native层的线程执行队列。

其Android实现机制是HandlerThread，因此Query/Save读写在会同一线程队列中，导致响应速度慢，容易造成DB SQL堆积，此外缺失缓存模型。

于是个人定制如下改进方案：

Flutter侧通过表的主键设计查询时候会优先从Entity Cache层去获取，若缓存不存在，则通过Sqflite插件查询。

同时改造Sqflite插件成支持sync/Async同步异步两种方式 *** 作，对应到Native侧也会有同步线程队列和异步线程队列，保证数据吞吐率。但是这里建议查询使用异步，存储使用同步更稳妥，主要怕出现多个相同的数据元model同一时间进入异步线程池中，存储先后顺序无法有效的保证。

43 ORM数据库方案

IM架构重度依赖DB数据库，而当前业界还没有一个完备的数据库ORM管理方案，参考了Android的OrmLite/GreenDao，个人自行设计一套Flutter ORM数据库管理方案。

其核心思想如下：

由于Flutter不支持反射，因此无法直接像Android的开源数据库方式 *** 作，但可通过APT方式，将Entity和Orm Entity绑定于一身， *** 作OrmEntity即 *** 作Entity，整个代码风格设计也和OrmLite极其相似。

参考代码如下：

44 IM内存数据模型

基于Flutter的IM移动端架构在内存数据模型主要划分为会话和消息两个颗粒度：

1）会话内存数据模型交托于SessionModuleData：会话内存数据有一个根节点RootNotice，然后其挂载PSessionMessageNotice（这里PSessionMessageNotice是ORM映射的会话DB表模型）子节点集合。2）消息内存数据模型交托于MessageModuleData：消息内存数据会有一个MessageConatiner容器管理，其内部挂载此会话中的PMessage(PMessage是ORM映射的消息DB表模型)消息集合。

依据上一章节，PSessionMessageNotice设计了一个OrmEnitity Cache，考虑到IM中会话数是有限的，因此PSessionMessageNotice都是直接缓存到Cache中。

这种做法的好处是各地去拿会话数据元时候都是缓存中同一个对象，容易保证多次重复读写的数据一致性。而PSessionMessageNotice考虑到其数量可以无限多的特殊性，因此这里将其挂载到MessageContainer的内存管理中，在退出会话的时机会校验容器中PMessage集合的数量，适当缩容可以减少内存开销。

模型如下图所示：

45 状态管理方案

基于Flutter的IM移动端架构状态管理方案比较简单，对数据源Session/Message维度使用观察者模式的订阅分发方式实现，架构类似于EventBus模式，页面级的状态管理无论使用fish-redux、scopeModel或者provider几乎影响面不大，核心还是需保留一种插拔式抽象更重要。

架构如下图：

46 IM同步模型方案

当前现状的消息同步模型：

如上图所示是，模型中存在ACCS Thread/Main Thread/Region Thread等多线程并发场景，导致易出现多线程高并发的问题。

native的推送和网络请求同步的隔离方案通过Lock的锁机制，并且通过队列降频等方式处理，流程繁琐且易出错。整体通过Region Version Gap去判断是否有域空洞，进而执行域同步补充数据。

改进的同步模型如下：

如上图所示，在Flutter侧天然没多线程场景，通过一种标记位的转化同步异步实现类似Handler消息队列，架构清晰简约了很多，避免锁带来的开销以及同步问题。

5、本次改造进展以及性能对比

1）针对架构层面：

在基于Flutter的IM架构中，重点将双端逻辑差异性统一成同一份Dart代码，完全磨平Android/iOS的代码差异性带来的问题。

带来的好处很明显：

1）降低开发维护、测试回归、视觉验收的一半成本，极大提高研发效率；2）架构上进行重构分层，实现一种解耦合，插拔式的IM架构；3）同时Native到Flutter侧的大量数据上抛序列化过程改造程Flutter引用传递，解决极限测试场景下的私聊卡顿问题。

2）针对线上舆情：

1）补齐UT和TLog的集团日志方式做到可追踪，可排查；2）针对于很多现存的疑难杂症重点集中专项解决，比如iphone5C的架构在Flutter侧统一规划；3）未读红点计数等问题也在架构模型升级中修复；4）此外多媒体音视频发送模块进行改造升级。

3）性能数据对比：

当IM架构的逻辑层和UI层都切换成Flutter后，和原先架构模式初步对比，整体内存水位持平。

其中：

1）私聊场景下小米9测试结构内存下降40M，功耗降低4mah，CPU降低1%；2）极限测试场景下新架构内存数据相比于旧架构有一个较为明显的改观（主要由于两个界面都使用Flutter场景下，页面切换的开销降低很多）。6、未来展望

JS跨端不安全，C++跨端成本有点高，Flutter会是一个较好选择。彼时闲鱼FlutterIM架构升级根本目的从来不是因Flutter而Flutter，是由于历史包袱的繁重，代码层面的维护成本高，新业务的扩展性差，人力配比不协调以及疑难杂症的舆情持续反馈等等因素造成我们不得不去探索新方案。

经过闲鱼IM超复杂业务场景验证Flutter模式的逻辑跨端可行性，闲鱼在Flutter路上会一直保持前沿探索，最后能反馈到生态圈。

总结一句话，探索过程在于你勇于迈出第一步，后面才会不断惊喜发现。

（原文链接：点此进入，本次有修订和改动）

附录：更多文章汇总[1] 更多阿里团队的文章分享：

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

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

《阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史》

《阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路》

《来自阿里OpenIM：打造安全可靠即时通讯服务的技术实践分享》

《钉钉——基于IM技术的新一代企业OA平台的技术挑战(视频+PPT) [附件下载]》

《阿里技术结晶：《阿里巴巴Java开发手册(规约)-华山版》[附件下载]》

《重磅发布：《阿里巴巴Android开发手册(规约)》[附件下载]》

《作者谈《阿里巴巴Java开发手册(规约)》背后的故事》

《《阿里巴巴Android开发手册(规约)》背后的故事》

《干了这碗鸡汤：从理发店小弟到阿里P10技术大牛》

《揭秘阿里、腾讯、华为、百度的职级和薪酬体系》

《淘宝技术分享：手淘亿级移动端接入层网关的技术演进之路》

《难得干货，揭秘支付宝的2维码扫码技术优化实践之路》

《淘宝直播技术干货：高清、低延时的实时视频直播技术解密》

《阿里技术分享：电商IM消息平台，在群聊、直播场景下的技术实践》

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

[2] 更多IM开发综合文章：

《新手入门一篇就够：从零开发移动端IM》

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

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

《从客户端的角度来谈谈移动端IM的消息可靠性和送达机制》

《现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》

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

《移动端IM开发需要面对的技术问题》

《开发IM是自己设计协议用字节流好还是字符流好？》

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

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

《如何保证IM实时消息的“时序性”与“一致性”？》

《一个低成本确保IM消息时序的方法探讨》

《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》

《IM群聊消息如此复杂，如何保证不丢不重？》

《谈谈移动端 IM 开发中登录请求的优化》

《移动端IM登录时拉取数据如何作到省流量？》

《浅谈移动端IM的多点登录和消息漫游原理》

《完全自已开发的IM该如何设计“失败重试”机制？》

《通俗易懂：基于集群的移动端IM接入层负载均衡方案分享》

《微信对网络影响的技术试验及分析（论文全文）》

《开源IM工程“蘑菇街TeamTalk”的现状：一场有始无终的开源秀》

《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》

《子d短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》

《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》

《自已开发IM有那么难吗？手把手教你自撸一个Andriod版简易IM (有源码)》

《融云技术分享：解密融云IM产品的聊天消息ID生成策略》

《IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！》

《适合新手：从零开发一个IM服务端（基于Netty，有完整源码）》

《拿起键盘就是干：跟我一起徒手开发一套分布式IM系统》

《适合新手：手把手教你用Go快速搭建高性能、可扩展的IM系统(有源码)》

《IM里“附近的人”功能实现原理是什么？如何高效率地实现它？》

《IM“扫一扫”功能很好做？看看微信“扫一扫识物”的完整技术实现》

《IM消息ID技术专题(一)：微信的海量IM聊天消息序列号生成实践（算法原理篇）》

《IM消息ID技术专题(二)：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》

《IM消息ID技术专题(三)：解密融云IM产品的聊天消息ID生成策略》

《IM消息ID技术专题(四)：深度解密美团的分布式ID生成算法》

《IM消息ID技术专题(五)：开源分布式ID生成器UidGenerator的技术实现》

《IM消息ID技术专题(六)：深度解密滴滴的高性能ID生成器(Tinyid)》

《IM开发宝典：史上最全，微信各种功能参数和逻辑规则资料汇总》

《IM开发干货分享：我是如何解决大量离线消息导致客户端卡顿的》

《零基础IM开发入门(一)：什么是IM系统？》

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

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

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

《IM开发干货分享：如何优雅的实现大量离线消息的可靠投递》

《IM开发干货分享：有赞移动端IM的组件化SDK架构设计实践》

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

《IM扫码登录技术专题(一)：微信的扫码登录功能技术原理调试分析》

《IM扫码登录技术专题(二)：市面主流的扫码登录技术原理调试分析》

《IM扫码登录技术专题(三)：通俗易懂，IM扫码登录功能详细原理一篇就够》

《理解IM消息“可靠性”和“一致性”问题，以及解决方案探讨》

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

>> 更多同类文章 ……

本文已同步发布于“即时通讯技术圈”公众号。

同步发布链接是：>

物联卡与普通SIM卡的主要区别在于材质不同、号码位数不同、特性不同，具体如下：

一、材质不同

1、物联卡：物联卡由于要在物联网设备等使用，一些还要在户外等环境下使用，风吹日晒雨淋，所以使用的材质要比普通SIM卡强。

2、普通SIM卡：普通SIM卡应用在手机这个环境中，相对温湿度等比较理想，普通使用PVC、ABS等材质进行封装。

二、号码位数不同

1、物联卡：物联网卡使用13位号码，号码资源更丰富。

2、普通SIM卡：普通SIM卡使用11位号码。

三、特性不同

1、物联卡：物联卡通常需要物联网卡管理平台，在平台里你可以查询流量使用情况、设备是否在线、充值等功能；物联卡增加了嵌入式MS卡，采用焊接工艺，前置在物联设备中，抗震指标好，确保数据传输稳定。

2、普通SIM卡：普通SIM卡不需要管理平台；普通SIM卡主要是插入式MP卡。

参考资料来源：

百度百科-物联卡

百度百科-SIM卡

以上就是关于Flutter浪潮下的音视频研发探索全部的内容，包括:Flutter浪潮下的音视频研发探索、做混合的话Uniapp和Flutter我应该学哪个啊、中国移动物联卡什么意思，和普通卡有什么区别等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！