跨端开发（跨端开发的未来趋势）

本篇文章给大家谈谈跨端开发，以及跨端开发的未来趋势对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享跨端开发的知识，其中也会对跨端开发的未来趋势进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、跨端开发面面谈之基于WebView的Hybrid开发模式
• 2、移动APP开发框架盘点2：Web移动前端框架大全
• 3、阿里跨终端的H5游戏开发解决方案——Hilo
• 4、Flutter浪潮下的音视频研发探索
• 5、跨平台桌面开发，Electron还是WebView2 （中篇）
• 6、“端手互通”趋势出现，WeGame想帮更多开发者站上新风口

跨端开发面面谈之基于WebView的Hybrid开发模式

跨终端移动开发是近期准备总结的一个主题，作为这一系列的开始，首先简单说说基于WebView的Hybrid混合开发模式。

有过混合应用开发经验的同学，对基于WebView的Hybrid开发模式应该不会陌生。借助于原生端各平台的WebView组件，可以实现Native和JavaScript的双向通信，从而将Web App与Mobile App融合起来，开启混合开发的新模式。

基于WebView的Hybrid开发模式到如今已经非常成熟，不再是一个实验性新技术，而是广泛应用在各大厂商的平台型应用如微信、手Q中。

JSBridge作为连接Native和JavaScript的桥梁，是基于WebView的Hybrid开发模式中的关键点。
在了解其通信原理后，再来看JSBridge究竟是什么。从前端角度来看，可能会把JSBridge理解为业务开发过程中，以全局变量注入到WebView中，帮助调用原生API的JavaScript工具库。这样的理解不够准确，按照我的理解，JSBridge不是一个标准的规范，基于原生系统为WebView组件提供的能力，已经可以建立起WebView JavaScript bridge，即使不再做更高程度的封装，也可以完成从Native到JavaScript的双向通信了。

我们所说的JSBridge，是对底层通道的抽象封装，这一过程包括了原生和JavaScript两侧内容，在原生端需要考虑系统API差异，对上层调用提供统一接口，在JavaScript端需要考虑调用方式，请求管理等内容。JSBridge的设计实现已经是成熟技术了，其设计可以参考 In-depth Profiling of JSBridge 、 Hybrid APP架构设计思路 ，一个安卓端完整JSBridge实现可以参考 JsBridge实现 。

目前，基于WebView的Hybrid开发模式非常成熟，广泛应用于各类平台型App中。实现一个完善的JSBridge是在现有App中集成使用Hybrid开发模式的基础，在完成这一基础设施建设后，大家继续在各个方向深挖，在不同的维度不断优化性能和体验。

多数App的Hybrid部分做到上面部分，已经有了还不错的体验。在我的了解中，空间团队在上面基础上继续优化给出的是当前做的更好的方案。其主要流程如下图所示，详细内容可以参考 QQ空间前端工程师如何做首屏优化
除了在现有App中集成使用这一开发模式，还可以使用这一技术开发独立App。早期的PhoneGap、Cordova、现在的Ionic，是这一领域较为知名的开发框架。

我司前端技术栈曾以Angular为主，一些App也由前端团队基于Angular技术栈选型Ionic。初入团队曾维护过基于Angular 1.x的Ionic App，用于我司投资顾问服务客户的以IM为主、综合一些其他业务，可以算一个比较复杂的应用。

前端技术背景的同学，采用Ionic框架开发App的学习成本不高。开发过程中仍在沿用前端技术，写的仍是Web App,跑在原生WebView容器中。采用Ionic提供的组件库，可以快速搭建项目界面。其扩展原生的机制也比较方便，如有原生能力的需求，并且没有现成实现的，可以自行封装使用，不过这个过程就需要原生开发同学的参与了。在我们的上述App开发中，主要是安卓端消息推送模块由原生开发同学提供了支持，其余对原生能力的需求如拍照、相册访问等常见需求，都有现成方案。

然而，采用Ionic完成上述应用，也有明显不足的地方。首先是聊天列表方面，我们知道，如微信和QQ聊天窗口，这是一个异构的无限滚动长列表，在进入聊天界面时，一般只加载最近的一屏聊天数据，然后通过滚动加载历史消息。在原生端完成这一需求有各种常见手段，而仅靠Web端技术，在各种折腾后，效果都不尽如人意。其次是动画，这里的动画包括了换页动画和其他动画，流畅程度一般。最后是前端开发通病，要处理浏览器兼容性问题，crosswalk只是一个理论解决方案，其体积限制了几乎不会被采用。

Ionic不断迭代，新的版本中依赖新的Angular。新的Angular与Angular 1.x开发体验已经完全不同，如果你还不了解，可以阅读我们团队书籍 揭秘Angular 2 。新的Ionic的开发体验，相比以往也有提升，在其工具链中，提供了拖拽式项目生成工具
同时，Ionic pro提供的开发者工具，为应用整个生命周期提供了完善的支持平台，包括了以下功能，不过，使用需要付费。

站在当下来看，对于前端技术背景开发者来说，如果已有Angular基础，不希望引入过高学习成本，需要快速开发一个复杂程度不算太高、或者对应用性能不是特别敏感的跨终端App，选择Ionic依然是一个可行方案。

然而，既然你已经身在前端领域这样一个技术更迭日新月异的圈子里，还是应该使劲的折腾，关注跨端开发这个主题新的技术热点，接下来我也会继续谈谈在NativeScript、React Native、Flutter的一些体验，可以保持关注。

移动APP开发框架盘点2：Web移动前端框架大全

开源项目其实有一个成熟周期，这个周期大概是三年左右，自React框架在2013年发布并引爆了前端框架的大潮，这个属于前端的周期就此开始了。

之后在2015年5月开源的React Native又开启了属于Web移动前端的周期，15-16年，18-19年，21-22年正好就是属于移动前端的三个爆发点。

三年前，在第一个成熟收获期，我盘点了移动开发框架。在这第二个成熟收获期，理所当然要来盘点一波。

不过，当我点开github项目的code-frequency时，还是被这个准到吓人的周期猜想惊呆了，先给你们看一波，剩下的自行验证。

1、https://github.com/youzan/vant/graphs/code-frequency

2、https://github.com/quasarframework/quasar/graphs/code-frequency

再来说第二个比较有意思的发现，停止维护的项目绝大多数是Vue框架项目。

盘点开始的时候我还觉得React框架处于绝对劣势，到完成时我发现React无论在选择面还是成熟度上都超过了Vue。

原因我这里就不分析了，反正大家都有自己的看法。

网页类框架就是前端组件框架，这一次虽然有大量项目停止维护，但是也有很多项目坚持了下来，而且还涌现出了一批新项目。

大厂占了主导，因为这些年大厂在移动开发上的需求，远高于其它方面。个人项目要坚持确实不易。

本来是想要做一个验证项目，把所有框架都试用一遍并给出推荐度的。由于进度太慢，还是下一次再发吧。

这次的重点是渐进类框架，就是所谓多端同构框架（小程序框架）。这几年国内的重点的各种小程序平台，所以多端框架的需求很是旺盛。

不过大多数先行者都没挺过来还是让我很意外，只有Taro成功了，想想还是有很多让人唏嘘的东西。

在这里还是先预测一波吧，因为这一类框架最变化最大，最终还是有很多框架要出局的。

渐进类框架是一个过渡性的产品，最终会变成桥接类框架的一部分，所以，与桥接类框架协同才是框架的出路。

这个赛道基本全是大厂了。

腾讯新一代跨端开发框架Hippy

Hippy一看就是淘宝Weex的对标项目，Kpi功能全面压制。所以官方支持 React 和 Vue 两种主流前端框架。在Weex2019年实质停更后发布，要不要这么卷？

Hippy 2.x 架构主要分成三层，UI(JS) 层 Hippy-React 和 Hippy-Vue 负责驱动 UI 指令生成；中间层 C++ HippyCore 负责抹平平台差异性和提供高性能模块；渲染层 Android 和 iOS 负责提供终端底层模块、组件，并与布局引擎通信。

对Weex惨遭遗弃，我上次就说过：「ReactNative提供工具，Weex提供框架，将平台差异化屏蔽（Write Once, Run Everywhere）。所以Weex则注定功能相对弱小，并且坑比较多。」Weex最终下马也是必然的，淘宝又发布升级版北海，为了实现（Write Once, Run Everywhere），它采用自绘，而且是基于Flutter自绘。

所以Hippy3.x就一如既往的Kpi功能层层加码，很有腾讯风格。在未来的 3.x 中业务与渲染层中的具体实现可根据用户实际场景进行切换：业务层上不再局限于 JS 驱动，还可选择（如：DSL/Dart/WASM 等）其它语言进行驱动；在渲染层中，渲染引擎除了支持现有原生（Native）渲染之外，还可以选择其他渲染 Renderer，如 Flutter(Voltron) 渲染。

「Kraken 北海」是一款高性能Web渲染引擎。底层基于 Flutter 进行渲染。

Kraken 不限制上层开发者使用的框架，无论你是使用 Vue 、Rax 还是 React 都可以开发 Kraken 应用。

Kraken 的 runtime 通过 JS Engine Binding 的方式提供了一系列 Web 标准的 API 接口，调用相应 API 会执行相关逻辑并创建一系列需要发送给 Dart 层处理的指令。

Kraken 其实就是一个小程序平台，而且追求全平台完全一致。我虽然认为各平台不一致是很自然的事情，但是也表示理解，毕竟别人吹牛有当真的传统（KFC表示认同）。

Kraken 现在也是一个小号浏览器，所以它的主要工作就是抠标准，毕竟它是一款基于 W3C 标准的高性能渲染引擎。

最后，我劝淘宝领导定Kpi要理智些，毕竟Hippy4我还蛮期待的。

滴滴出品的超轻量级动态化跨端开发框架，主打轻量和实用。

Hummer 以 JS 引擎为基石，目前已支持 JavaScriptCore、Hermers、QuickJS 等业内知名 JS 引擎（这里本来还有个V8的，我删除了，源码里面没有，Kpi需要）。再配合经过调优的 Yoga 布局引擎，抹平了两端视图布局差异（性能更佳的自研布局引擎开发中）。顺便提一下，Hippy采用V8（功能更强）自研布局引擎（性能更佳）。

Hummer 的特点是抛弃了业界其他动态化跨端框架普遍使用的DSL层和VDOM层，因此原生 Hummer 不具备前端开发常用的响应式编程的能力，但同时换来的是接近原生开发的体验和性能。再以原生 Hummer 为基础，在此之上开发了一套基于MVVM架构的开发框架 —— Tenon ，通过 Tenon，可以把使用 Vue/React 编写的代码，转换成原生 Hummer 的代码。

Hummer也是一个小程序平台，而且超轻量。如果想要无限提升自己APP的能力，可以考虑嵌入Hummer。

Web移动前端框架正在迎来第三个高速发展期，各类框架得到极大繁荣。

个人在具体项目的贡献已经微乎其微了，创新、架构创新是唯一制胜的手段，这也是我看好React的根本原因。

最后，还是想做点微不足道的 探索 ，现在前端组件库层出不穷，更换组件库带来的代价有点大。想创建一个框架，来实现上次说的组件公约数和公倍数，无缝切换组件库。理论上支持所有组件库 ，也能为后来者提供弯道超车的机会。我想大厂可能没有需求，也不会愿意发布这种框架，毕竟都是平台部门说了算。

这个库就是useMobile，当然分为useMobileReact和useMobileVue。下次先发布useMobileReact。等我发布后，再来填上面表中缺的推荐度。

原文地址： https://www-blogs.com/windfic/p/16019457.html

阿里跨终端的H5游戏开发解决方案——Hilo

Hilo是由阿里巴巴集团开发的一款 HTML5 跨终端 游戏 解决方案，可以帮助开发者快速创建 HTML5 游戏 。有以下特征：独立模块设计，支持多种模块范式的包装版本;面向对象程序化开发;多重渲染模型，其中包括 Canvas，DOM 和 WebGL 等;兼容多台台式机和移动浏览器；使用 Flash Shim 来支持 IE ;支持物理扩展： Chipmunk；支持骨骼动画扩展： DragonBone！
1、Hilo 支持多种模块范式的包装版本，包括AMD，CMD，COMMONJS，Standalone多种方式接入。另外，你可以根据需要新增和扩展模块和类型；
2、极精简的模块设计，完全面向对象；
3、多种渲染方式, 提供DOM，Canvas，Flash，WebGL等多种渲染方案（目前已经申请专利）；
4、全端浏览器的支持和高性能方案，独有的Flash渲染方案，即使在低版本IE浏览器下也可以跑起来“酷炫” 游戏 ； DOM渲染方案能显著解决低性能手机浏览器遇到的性能问题；
5、物理引擎支持——Chipmunk，支持自扩展物理实现；骨骼动画支持——DragonBones，同时内建骨骼动画系统——Tahiti（目前内部使用）；
6、案例丰富，框架成熟，已经经历多届阿里巴巴双十一，年中大促互动营销活动考验；
舞台Stage是一个各种图形、精灵动画等的总载体。所以可见的对象都要添加到舞台或其子容器后，才会被渲染出来。

Stage构造函数接收一个参数properties，此参数包含创建stage的各种属性。

舞台Stage上的物体的运动等变化，都是通过一个定时器Ticker不断地调用Stage.tick()方法来实现刷新的。

舞台上的一切对象都是可视对象，可以是图片、精灵、文字、图形，甚至DOM元素等等。Hilo提供了一些基本的可视类供您使用，比如添加一个图片到舞台上：

要想舞台上的图形、精灵动画等对象能响应用户的点击、触碰等交互事件，就必需先为舞台开启DOM事件响应，然后就可以使用View.on()来响应事件。

接下来，您就可以开始利用hilo提供的各种可视类来创建各种图形、精灵动画，尽情发挥您的创造力，开始您的HTML5 游戏 之旅吧！

Hilo对于开发H5 游戏 的开发者和对Web端渲染感兴趣的小伙伴来说值得一看，Hilo有诸多案例可供参考，如果你想继续深入了解它，可移步官方文档或者Github一探究竟！

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

跨平台桌面开发，Electron还是WebView2 （中篇）

这一周继续聊跨平台桌面开发这个事情。

在这篇文章中，我暂时会放下Electron与WebView2的一个对比，而聊一聊跨平台这个对于程序员群体来说不陌生的词。

一个趋势是：跨平台开发几乎是在各个技术方向都会持续发展的

跨平台这个词，对于程序员来说，应该是不陌生的。因为这个概念不只在某一端存在，后端，前端，移动端，桌面端几乎所有方向都对跨平台有需求。

在后端，Java是跨平台的，当你用Java来编写后端服务时，并不需要考虑操作系统，因为它几乎支持主流的操作系统。现在，编写一个后端服务，选用Java仍是主流。虽然可能它的跨平台特性已经不是程序员最在意的点了。

而在移动端，类似React Native，Flutter也是非常有名的跨平台移动开发，它们与移动原生开发方式之间一直是竞争与共存。

而前端因为依托于浏览器，天然就是跨平台的。事实上，很多应用或服务早期纷纷选择从原生应用迁移至前端WEB方式的一个非常重要的原因就在于它是跨平台的。

桌面操作系统很长一段时间一直是Windows一家独大，所以桌面开发一直是Windows独占，直至现在为止，很多专业级的软件仍然是Windows独占的。

而Linux桌面操作系统与MacOS桌面操作系统，早些年几乎可以忽略不计，压根不需要考虑这两种系统。但随着近些年它们的慢慢流行，特别是苹果的MacOS的以其杰出的工艺，流畅的体验，叠加苹果手机的流行，其市场份额增长非常之快，在特定的诸如编程，设计等行业人群中使用范围较广，这使得开发支持MacOS系统这个点变得越来越重要。

所以，在桌面开发领域，跨平台的需求也越来越高。

这也是Electron及早期的NW.js能迅速发展起来并得到非常广应用的原因所在。

无论是哪一端，跨平台技术之所以频繁出现与不断发展，其根本原因就在于编程的一个重要痛点在于：

为了让同一个服务能在所有设备上运行，程序员不得不编写与维护非常多不同版本的程序

每一个程序或软件后面的服务，都有一个非常迫切的需求，就是期望它的用户无论何时，无论何地，无论使用任何设备，都能方便友好的使用这个服务。

也是因为这个原因，Web发展起来了，因为Web的优势就在这，只要你的设备上有浏览器，就能访问。

但Web毕竟性能有限，且浏览器这种形式并不利于用户忠诚度的培养，它存在天然的弱点。一些简单的操作服务使用Web并无问题，但稍微有点要求的，Web可能就并不是非常适合。

所以，一种趋势不可避免地流行起来：

对不同设备或系统进行抽象，基于某一种特定的编程语言，编写出能与原生程序相媲美的，又能跨平台的技术便层出不穷了

对吧，Java是使用JVM来抽象不同的操作系统，React Native则是使用虚拟DOM以及转换成原生控件的方式来实现跨平台，而Electron则是通过性能较好的Chrome内核+NodeJS原生调用能力的搭配来实现跨平台桌面开发。

总而言之，这种跨平台的技术不会消亡，只会有新的技术层出不穷，而它们与原生开发一定是相互竞争，配合与共存的。相互之间无法取代。

那再回到跨平台技术上来说，一个良好的跨平台开发的技术或框架，重点是什么。

或者换种方式说，哪些特性使得它更易于流行起来？

我个人认为有以下的几个点：

跨平台开发技术能不能流行起来的一个非常重要的点就在于，使用了什么样的编程语言。

以移动端跨平台开发技术来说明，一个React Native，一个Flutter，这两个是比较知名主流的跨平台移动开发技术。React Native使用的是前端React技术，而Flutter则是Google的D语言。

显而易见的是，虽然Flutter是使用skia引擎在底层重绘一套UI，其性能相比React Native这种模式更佳，但React Native更易于被接受。

在流行度上，React Native始终比Flutter更流行，一个最重要的原因也在于：

使用已熟知的前端编程语言，比起重新学习一个D语言更易于被接受，维护成本更可控。

这个问题在跨平台桌面开发中也是类似，跨平台桌面开发技术也不是Electron最开始出现，比如著名的QT很早就有了，但比起Electron这种使用前端编程技术来说，显然在编程语言的门槛上和程序员群体上都存在困难，这也是Electron能后来居上的原因所在。

因为，大多数程序员群体，相比较另外学习一门什么语言去做什么，使用自己熟悉的语言来做什么是更容易，意愿也更高。

而从公司或团队的考量上看，选择偏门的小众语言存在成本上的顾虑，比如人员招聘是否容易？

跨平台技术在尝试解决不同平台不一致，它或多或少会损耗性能。这也决定了几乎没有任何一个跨平台技术能取代原生开发。

这是一个取舍的问题，对于一个程序来说，究竟性能有多重要。对于比较看重性能的程序来说，原生开发可能是最优选择。

但跨平台的性能损耗也有高低之分，并不在同一水平线上。

其实，无论是Electron，或是WebView2，都是基于浏览器内核+前端技术的跨平台桌面解决方案，这也是为什么要把它们放在一起聊的原因。

Electron是先行者（当然，严格说来，NW.js出现的更早，但今天它的流行度已远远落后于Electron了），而WebView2则是后来者。

那做为后来者的WebView2究竟做了哪些改进？它又有多大的能力来挑战Electron呢？

下一篇，继续聊。

“端手互通”趋势出现，WeGame想帮更多开发者站上新风口

2021 ChinaJoy如火如荼之际，行业对WeGame的认知又一次被刷新了。

7月31日，2021WeGame开发者大会在上海如期举行，会上WeGame产品负责人梁凌骁宣布，WeGame品牌全面升级，Slogan也由过去的“发现更大的 游戏 世界”更改为“与 游戏 人同行”，深耕行业的决心可见一斑。

这次大会围绕国内PC 游戏 市场探讨了不少课题，而最让业界关注的，莫过于许多从业者已经明显感知到的一大趋势——“端手互通”类 游戏 正在不断涌现。

所谓“端手互通”，即一款 游戏 有PC和手机等多个版本，多版本之间数据互通。其实这个概念不算新鲜，从几年前在海外爆火的《堡垒之夜》，近期席卷全球的《原神》，到越来越多的大厂宣布立项多平台新作。这样的行业趋势也让从业者开始认真思考：“端手互通”越来越火，其背后原因究竟是什么。

为什么说“端手互通”是当今行业的大趋势？

NewZoo今年7月发布的《2021年全球 游戏 市场报告》指出，随着产品在不同平台不断融合交互，创新发展迭代演进，主机、PC与移动 游戏 间的界限正逐渐模糊，跨平台趋势加速发展。尤其是《原神》等跨端精品 游戏 的出现，加速了“端手互通”的发展。

事实上，“端手互通”趋势背后的逻辑不难想象。

就市场层面而言，2020年仅72款新品端游获得版号，与此同时1.2亿的中国PC玩家贡献了约560亿元的收入；相较6.6亿移动 游戏 玩家可游玩1200款移动新作， 中国PC 游戏 市场显然更缺少新内容 ，适合的移动 游戏 增加PC端版本，是填充市场的一大优质内容源头。

WeGame产品负责人梁凌骁分享PC市场现状

而对拥有优质内容的 游戏 厂商来说，他们已不再满足于仅仅满足部分场景的玩家胃口， 而是希望借助于不同平台，触达不同圈层的更加多元的玩家。并且，PC端相比传统的移动端渠道分成更低，开发者的利润率也更高。

此外，“端手互通”还可以依托于高品质的产品定位，为市场宣发造势，更容易塑造IP，进而面向全球市场。因此这两年，紫龙、莉莉丝、完美世界、游卡等国内厂商陆续将旗下的拳头产品覆盖多端场景，甚至有的从立项之初就确定了PC端和手机端同步开发，足以体现出行业主流厂商们对这股趋势的认可和重视。

各大厂商旗下端手互通产品

那么，是不是只要厂商直接把手游简单移植，甚至是模拟器的方式，就能占领市场了呢？现实并没有这么容易。WeGame在本次大会上公布的数据显示，一款“端手互通” 游戏 的PC版本用户活跃可能占总活跃的10%~50%，而占比高低取决于PC版本是手游模拟器体验还是原生端游操作体验。

站在玩家角度来看， 追求多元化内容，对 游戏 体验产生多场景、多形式诉求已是大势所趋 ——如果说移动端满足的是他们碎片化的 娱乐 需求，那么花在PC端上的 游戏 时间，则是为了进一步地享受更好的画质，更具沉浸感的体验。 玩家对于“端手互通”产品的认知，已经从单纯的“手游模拟器”升级为追求“原生端游操作”的体验。

简单来说，单纯的手游移植无法真正挖掘“端手互通”市场的潜力，瞄准PC端场景打造专属的高品质版本，才能满足玩家需求。WeGame平台产品和发行总监王伟光也在群访环节表示，“就算是一个纯手游产品，在服务于PC玩家时也需要做一些体验上的提升，因为如果单单是手转端模拟器体验的话，可能很难去击中PC用户。”

WeGame产品和发行总监王伟光

拿米哈游的《崩坏3》来说，这款3D动作 游戏 非常注重战斗打击感和剧情沉浸感。其PC版本自登陆WeGame以来，已经收获了超80%的玩家推荐率，市场反响相当不错。

而另一款WeGame上线的多端 游戏 《三国杀》，其制作人刘子镕透露，作为一款“端手互通”产品，同时游玩PC版和移动版的玩家占《三国杀》总用户量的一半以上。他同时指出，《三国杀》在产品上线之初，就确定了长线运营目标。而最终结果也证明，通过PC版和移动端沉淀玩家、积累用户，《三国杀》实现了较好的活跃和付费同步增长。

《三国杀》制作人刘子镕在会上分享

政策、引擎、平台多方助力，为“端手互通”类产品加速

一种行业趋势的发展，离不开多方的助力和时机的把握。而“端手互通”这股趋势，已经隐隐间具备了“天时地利人和”。

首先在政策上， 游戏 端手版本同时送审同步审核，有机会一次性获得PC端及移动端版号 ，大大减少了各自送审的时间成本。从过去一年的版号下发情况来看，能发现已经有不少产品的多端版本能同时过审。

其次在技术上，Unity、UE4等业内广泛应用的 游戏 引擎均支持多平台开发，开发者可以无障碍地为“端手互通”产品做适配。 更重要的是，越来越多的引擎方注意到了 游戏 多平台发布的行业趋势，并着力为 游戏 厂商提供跨端移植服务。

以Unity为例，目前他们已成立了一支专门服务于开发者的跨端移植团队，该团队将通过优化渲染算法、改善引擎效率等方式，对 游戏 在新平台的性能表现进行调优处理，保证最大程度移植 游戏 效果的同时解决性能难题。据了解，Unity的跨端咨询服务涵盖了人才培养、开发适配、测试上架，帮助开发者以较低成本实现工业化、规范化的多平台快速发布和多端数据互通。

另一大 游戏 开发引擎UE4同样具备不俗的多平台适配能力。拿Epic使用UE4开发的《堡垒之夜》来说，该作不仅在移动端拿出了媲美主机端的画面品质及操作手感，更早早打通平台隔阂，让不同终端的玩家在同一服务器内社交 娱乐 、畅快 游戏 。

目前，祖龙、莉莉丝等国内 游戏 厂商已相继开始使用UE4开发移动 游戏 ，随着手游重度化趋势加快，未来会有越来越多的 游戏 研发商使用UE4引擎，其跨端开发的门槛必然也将在无形中降低。

最后在平台角度，WeGame也将为“端手互通”产品提供多种助力。梁凌骁提到，针对“端手互通”同步首发 游戏 ， 除了更多的分成让利以及更多的流量倾斜和扶持，WeGame还将凭借WeGame App和腾讯二级渠道资源，帮助手游版本做推广宣发。

此外，WeGame还将在商店页开设更为垂直的“端手互通”专区，为产品导入精准流量。计划接入该专区的 游戏 包括《三国杀》、《崩坏3》、《狼人对决》和《天涯明月刀》手游互通版，以及腾讯光子自研的生存新作《黎明觉醒》及《妄想山海》PC版等产品。假以时日，WeGame“端手互通”专区或形成规模化效应。

总的来说，政策、引擎、平台给予 游戏 开发者的支持，细致入微地覆盖了 游戏 CP自团队搭建、立项、产品立项研发、宣发推广、上架发售等一系列研运环节，而在他们的助力下， 游戏 厂商自然可以抛却后顾之忧，轻装上阵大胆尝试“端手互通”，在新趋势中找到新机遇。

结语

始终考虑着玩家需求，携手更多合作伙伴，不断向开发者靠拢……近两年来，WeGame陆续公布了“翼计划”、“千万不分成”等形式不一的扶持举措，让利于 游戏 CP，助力行业 健康 繁荣地生长。在此之上，WeGame还把准时代脉搏，洞悉行业前沿趋势，推出多项举措助力开发者站上“端手互通”这一新风口。

如今，WeGame又站到了一个全新的起点前。正如梁凌骁所说：“我们确信我们已经发现了更大的 游戏 世界，那么接下来我们希望与 游戏 人同行，共同 探索 整个行业的美好未来。”

从“发现更大的 游戏 世界”到“与 游戏 人同行”

相信在WeGame “与 游戏 人同行”的过程中，越来越多的“端手互通”类 游戏 将出现在市场上， 游戏 的未来将拥有更多可能。

关于跨端开发和跨端开发的未来趋势的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 跨端开发的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于跨端开发的未来趋势、跨端开发的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。