189 8069 5689
最近在做的一个项目，项目的前期采用Weex开发。但是随着交互复杂度的增加，Weex一处开发多处多处运行的特征并没有很好的体现，相反很多时候我们还是需要做IOS和Android的适配。如今火热的Flutter相比Weex和Rn来说，给出了更好的跨平台解决方案。所以我们设计了一套基于Weex实现，底层跑在Flutter Engine上的框架。
创新互联是一家集网站建设,白河企业网站建设,白河品牌网站建设,网站定制,白河网站建设报价,网络营销,网络优化,白河网站推广为一体的创新建站企业，帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿，时刻以成就客户成长自我，坚持不断学习、思考、沉淀、净化自己，让我们为更多的企业打造出实用型网站。
底层的Runtime采用isolate engine,框架业务逻辑，Dom的解析逻辑和Render逻辑都跑在这里。
渲染引擎采用Flutter的Skia，彻底剥离了Android和IOS的差异性.
将Weex VirsualDom的解析都替换成Flutter Widget.
设计基于Weex2Dart的Brider,使JS和Dart可以相互调用
weex-demo的性能展示
release环境下采用AOT模式，性能会有质的飞跃。
Android-Release版本只有10m大小
相比Weex和Rn具有更好的性能，同时具有更好的跨平台性
相比Flutter，具有动态部署的能力（Flutter Release采用AoT模式并没有动态部署的能力，即使Debug版本也只是开发环境下才有动态化能力并没有可以实施项目的能力）
只需要会Weex开发或则Rn开发就可以，不需要额外学习Dart，已有的Weex项目可以无缝切换。
推荐：
uni-app
uni-app 是一个使用 Vue.js 开发所有前端应用的框架，开发者编写一套代码，可发布到iOS、Android、H5、以及各种小程序（微信/支付宝/百度/头条/QQ/钉钉）等多个平台。
即使不跨端，uni-app同时也是更好的小程序开发框架。
Taro
Taro 是一套遵循 React 语法规范的 多端开发 解决方案。
现如今市面上端的形态多种多样，Web、React-Native、微信小程序等各种端大行其道，当业务要求同时在不同的端都要求有所表现的时候，针对不同的端去编写多套代码的成本显然非常高，这时候只编写一套代码就能够适配到多端的能力就显得极为需要。
使用 Taro，我们可以只书写一套代码，再通过 Taro 的编译工具，将源代码分别编译出可以在不同端（微信/百度/支付宝/字节跳动/QQ小程序、快应用、H5、React-Native 等）运行的代码。
文/陈炉军
整理/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框架，开发者只要去负责实现特殊需求模块就可以，尽可能的减少重复劳动。
说在前面，面试时最好不要虚报工资。本来字节跳动是很想去的，几轮面试也通过了，最后没offer，自己只想到几个原因：1、虚报工资，比实际高30%；2、有更好的人选，这个可能性不大，我看还在招聘。我是面试Android开发的，3年经验，下面是面试流程：
1.插件化。启动activity的hook方式。taskAffity。
2.okhttp支持HTTP2？http2的功能有哪些？tcp方面拥塞控制？tsl的握手和具体的非对称加密算法。非对称名称
3.handler的post(Runnable)如何实现的。callback，runnable，msg的执行优先级。
4.阻塞是怎么实现的？为什么不会阻塞主线程？
5.求二叉树中两个节点之间的最大距离。
6.206含义，未修改资源是哪个，302含义，301含义
7.多进程通信问题。binder优势。aidl生成的java类细节。多进程遇到哪些问题？
8.动态代理传入的参数都有哪些？非接口的类能实现动态代理吗？ASM的原理
9.Application和Activity在Context的继承树上有何区别？二者使用上有何不同？
10.任意一颗二叉树，求最大节点距离
1.设计一个日志系统。
2.内存泄露的分类。怎么查看内存泄露的问题
3.touch事件源码问题。
4.组件化的问题。module和app之间的区别。moduler通信是如何实现的。
5.native奔溃的日志采集，怎么处理？
6.注解实现一个提示功能：如果int的值大于了3需要提示。
1.介绍下flutter的启动流程
2.介绍下flutter与weex的区别
3.组件化介绍一下
4.webview中与js通信的手段有哪些？
5.介绍下flutter_boost的原理
1.适配器和装饰模式各自特点和使用场景
2.视频编解码是怎么做的
3.三色球排序
1.询问了除字节跳动以外，还在看其他工作机会么？分别是什么
2.字节、XXX公司、XXX公司，你的优先级是什么，为什么？
3.之前薪资待遇是多少？你期望的薪资是多少？
4.平时有什么爱好？
5.了解职位需求吗？
6.有没有想问的？
在介绍如何面试之前，这里先从公司的角度来分析：”到底什么样的候选者是公司所需要的技术人才？“就我在现在这家公司的一些面试官经验来说，一个具有如下特征的Android程序员是我们所需要的：
在上面的四条中，其中第3条是最为重要的，即技术，技术是决定能否通过面试的最重要最直接的原因。一般来说，越是大公司，其对技术的要求就越高，尽管部分岗位并不需要那么好的技术，但是为了对候选者做出区分，其面试过程仍然会面试一些稍微深入的话题，相信大家都有所体会。
除了技术以外，良好的沟通和协作能力也是比较重要的。也许很多人觉得这个比较抽象，心里会想：”你怎么知道我有没有良好的沟通和协作能力呢“？其实这个问题并不难，面试过程就是一次沟通过程，如果不能和面试官很好地沟通，这就说明候选者的沟通有问题。如何很好地和面试官沟通呢？给如下几点建议：
下面对学历和工作经验做一些说明，学历并不是一个硬性要求，即使候选者学校不怎么好也是有可能通过面试的，这就要求候选者技术非常扎实。而工作经验，之所以是2年以上，这是因为社会招聘的对象一般都是有一定工作经验的，而1年工作经验略短了点，拿百度来说，社招的最低级别一般为T4，差不多刚好就是2年经验左右。
这里做下总结，理想的候选者应该是这样的：
基本来说，满足1和2就能通过面试，3和4都是次要条件，但是一般来说不满足3就很难满足1，不要说特例，木有参考意义。
由此可见，技术是面试结果的决定因素。那么到底技术掌握到什么程度才能比较轻松地通过面试呢？说了那么多，好像和Android没有一点关系，下面就开始以Android为例来分析下面试过程所需的技术。
下面的所有技术知识点详细内容都整理在了开源项目 【GitHub】 ,有需要的可以自取。
别无捷径，刷题，但是刷题的时候，要按照题的类型去总结。
基础知识：看一下对于 计算机网络 ，重点是网络分层模型、TCP/UDP、HTTP/HTTPS。
按照23种网络模型、三个分类进行总结，每种设计模式包含以下三个方面，至少要准备常用的几个：
有用到的可以看看。
音频、视频播放。
ReactNative、Flutter：没学过的可以了解一下思想。
调用实现方式。
所有的知识点都整理在了开源项目【GitHub】,有需要的朋友可以评论领取。
首先你面到 HR 了，说明你基本已经成为备选人之一了。这时候 HR 会和你聊很多问题，这些问题都是为了了解你的一些个人情况的。比如说性格啦、反应能力、情商等等。另外大部分公司的 HR 并没有一票否决权，面试没有成功多半是有更好的备选人而不是因为 HR 把你卡掉了。
然后说到谈钱的一个问题。首先以最少的工资招到需要的人肯定是 HR 的考核之一，所以压价是很正常的一个事情。并且上家公司的薪资也是一个很重要的参考，一般来说涨薪幅度在 30% 以上是很牛逼的事情了，通常都在 20% 左右。
你的开价一般就是 offer 的上限了，考虑到压价的情况，你可以在原本期望薪水上上浮 1K 左右，然后可以根据面试的情况来有选择性的开价。
如果你想去一家不错的公司，但是目前的硬实力又不到，我觉得还是有必要去努力一下的，技术能力的高低能决定你走多远，平台的高低，能决定你的高度。
如果你通过努力成功进入到了心仪的公司，一定不要懈怠放松，职场成长和新技术学习一样，不进则退。
大多数的应用都会在一个weex容器中进行页面跳转，这种场景下使用navigator就能比较好地实现（页面切换）。但是在实际混合开发场景中，会碰到更为复杂的跳转逻辑，如原生页面A跳转Weex页面，再从B跳转远程页面C，继而再从C跳转Weex页面D……再加上还会有跳转H5页面等等，这样对于后退栈的管理就会比较复杂。目前我们采用的解决方案是：为每一个weex页面单独使用一个容器（对于H5也是一样），这样页面的跳转就能交给原生系统的后退栈来管理。当然这么做也会有性能开销，但是综合来说，这种场景不多，因此从性价比考虑这么做是目前最合适的。
然而这么做又会来带新的问题，那就是weex所提供的消息机制只能是在单容器内使用，按照官方的说法即这是一个实例级别的事件而不是应用级别的。那么就需要我们自己来做一套消息通知机制供应用级别使用，来解决多weex容器实例以及连通weex、native以及H5。其实这套机制并不复杂，因为原生已经有很多消息机制可以供我们选择了，包括EventBus、LocalBroadcast等等。这里可以详见我的之前有关消息机制实现的文章（传送门： ）
之前说到大多数的weex使用场景是单容器（或者说是单实例）的，因此一般的实现也都是在一个Activity中（以安卓为例，下同）只有一个WXSDKInstance。然后有时候需求就是这么坑爹，在某些原生页面中希望可以内嵌一个甚至多个Weex的容器，那么这时候用来实现Weex容器的就不能再是Activity而是View了。我们需要自定义一个View来实现IWXRenderListener接口，并且在该View内部来维护一个WXSDKInstance，虽然初始化WXSDKInstance时候传入的Context还是Activity，但是好在instanceId是自增的，因此在一个Activity中有多个Weex的View，它们还是可以通过id来区分的。另外在使用View做容器的时候，也需要自己hook Activity的生命周期，来与WXSDKInstance中相应的方法绑定，不然在自定义Module等应用场景中将无法正确拿到Activity的生命周期回调。
想必很多团队在接触或者决定使用weex的时候，所在的项目已经是开发甚至是上线一段时间了，并且大多项目一定会用到WebView承载的H5页面，那么在开发H5相关页面时自然而然会定义很多通用的Bridge能力，比如账号登录机制、通用的loading组件、网络请求代理等等。然而我们在开发weex页面时候则不希望再重复实现这套Bridge，因此我们就需要实现一个适配器，通俗地说就是通过定义一个weex的Module去实例化H5的Bridge并且调用实例的方法。这套机制核心需要关注的是H5的Bridge需要怎么样的环境，我们通过哪种方法来实例化H5的Bridge（大多数情况下会需要用到反射）。此外，这种做法由于无法完全在weex容器中还原一个H5的环境，因此也并不是能100%复用H5的Bridge能力，对于无法复用的，我们还是需要基于weex重新开发一套。
在深度使用weex的时候，weex官方提供的组件会逐渐变得无法满足当前需求，这时就需要我们来做一些自定义的组件。当然这块并不需要用到什么黑科技，weex官方就提供了这类扩展，也就是WXComponent以及WXVContainer。常规的独立组件继承WXComponent即可，类似写一个原生的自定义View，具体的属性以及方法定义也可以参考官方文档（ ）。对于View的容器组件则需要继承WXVContainer，然后你就可以自定义各种cell，并且通过addSubView方法拿到加进去的cell。
weex官方提供了playground app，帮助你在设备上调试。但对于依赖自己项目环境的功能，就必须在项目内提供一个调试工具了，核心类似playground app，即提供一个扫码功能，能进入weex页面进行调试，对于调试这块功能，我会在后续的文章中详细讲解。
小程序平台现在已经成为一款应用不可或缺的阵地，因此跨端方案自然不能少了小程序这个平台。目前核心做法还是依赖于babel，并且需要在小程序端预先实现一套相对应的组件。详细的内容也将在后续文章中详细展开。
跨端方案既然是以提高效率为目的，那么自然需要有足够的数据来做支撑，因此我们需要在weex的几个生命周期内做好埋点，来统计各种耗时。另外在业务上也会有数据需求，一般也是通过埋点的形式来做统计
多端融合一定是未来移动端开发的一个方向，它除了解决一部分体验问题之外还能提高人效，因此未来各大企业也会越来越多地依赖这项技术。至于具体的方案选型，诸如weex、rn或者flutter，还是需要根据具体的业务场景来选择，目前并没有完美的方案，当然基于这些开源方案来二次开发，从而补足这些方案存在的不足则是更好的了。
对于我个人而言，自身的技术规划加上公司业务需求，有幸在这个时间点能学习到前端知识并且落地这套方案。因此我打算开一个文章系列，记录一下这套方案不断演进过程中的点点滴滴。
这段时间经历了很多事情，说是一夜长大也不为过吧。但是没有时间再自怨自艾了，找对方向，就算再难受爬着也要向前。失去的东西总会回到我们身边，虽然有时并不是以我们希望的方式。