跨端开发逻辑（跨终端开发）

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

本文目录一览：

• 1、程序开发的逻辑思维要怎么样培养呢？
• 2、Flutter浪潮下的音视频研发探索
• 3、web前端未来将会有什么样的发展趋势？
• 4、web前端的行业趋势是什么？
• 5、客户端开发的成长思考
• 6、移动APP开发框架盘点2：Web移动前端框架大全

程序开发的逻辑思维要怎么样培养呢？

逻辑思维的培养对软件工程非常重要，思维快的能快速编写逻辑代码。可以从一下几个方面进行慢慢培养。
第一：明确学习目的
逻辑思维学习编程对多数IT业人员来说都是非常有用的。学编程，做一名编程人员，从个人角度讲，可以解决在软件使用中所遇到的问题，改进现有软件，可以为自己找到一份理想的工作添加重要得砝码，有利于在求职道路上谋得一个好的职位；从国家的角度，可以为中国的软件产业做出应有的贡献，一名优秀的程序员永远是被争夺的对象。学习编程还能锻炼思维，使我们的逻辑思维更加严密；能够不断享受到创新的乐趣，将一直有机会走在高科技的前沿，因为程序设计本身是一种创造性的工作。知识经济时代给我们带来了无限的机会，要想真正掌握计算机技术，并在IT行业里干出一番事业来，有所作为，具有一定的编程能力是一个基本条件和要求。
第二打好基础，学好基础知识对我们开发也很重要学编程要具备一定的基础，总结之有以下几方面：
首先是数学基础 从计算机发展和应用的历史来看计算机的数学模型和体系结构等都是有数学家提出的，最早的计算机也是为数值计算而设计的。因此，要学好计算机就要有一定的数学基础，出学者有高中水平就差不多了。
其次是逻辑思维能力的培养 学程序设计要有一定的逻辑思维能力，“逻思力”的培养要长时间的实践锻炼。要想成为一名优秀的程序员，最重要的是掌握编程思想。要做到这一点必须在反复的实践、观察、分析、比较、总结中逐渐地积累。因此在学习编程过程中，我们不必等到什么都完全明白了才去动手实践，只要明白了大概，就要敢于自己动手去体验。谁都有第一次。有些问题只有通过实践后才能明白，也只有实践才能把老师和书上的知识变成自己的，高手都是这样成材的。最后是选择一种合适的入门语言 面对各种各样的语言，应按什么样的顺序学呢？程序设计工具不外乎如下几类： 1）本地开发 应用软件开发的工具有：Visual Basic 、Delphi 、VC++ ( C++ Builder ) 等；数据库开发工具有：Visual Foxpro 、Oracle Developer 、Power Builder 等。 2）跨平台开发 开发工具如 Java 等。 3）网络开发 对客户端开发工具如：Java Script 等；对服务器开发工具如：PHP 、ASP 、JSP 、ISAPI 、NSAPI 、CGI 等。 以上不同的环境下几种开发工具中 VB 法简单并容易理解，界面设计是可设化的，易学、易用。选 VB 作为入门的方向对出学者是较为适合的。
第三：注意理解一些重要概念
一本程序设计的书看到的无非就是变量、函数、条件语句、循环语句等概念，但要真正能进行编程应用，需要深入理解这些概念，在理解的基础上应用，不要只简单地学习语法、结构，而要吃透针对这些语法、结构的应用例子，做到举一反三，触类旁通。
第四：掌握编程思想，编程思想使用较多的就是oop编程思想
学习一门语言或开发工具，语法结构、功能调用是次要的，最主要是学习它的思想。例如学习 VC 就要学习 Windows 的内在机理、什么是线程......；学习 COM 就要知道VTALBE 、类厂、接口、idl......，关键是学一种思想，有了思想，那么我们就可以触类旁通。
第六：多实践、多交流，一切思维来自项目开发的积累
掌握编程思想必须在编程实际工作中去实践和体会。编程起步阶段要经常自己动手设计程序，具体设计时不要拘泥于固定的思维方式，遇到问题要多想几种解决的方案。这就要多交流，各人的思维方式不同、角度各异，各有高招，通过交流可不断吸收别人的长处，丰富编程实践，帮助自己提高水平。亲自动手进行程序设计是创造性思维应用的体现，也是培养逻辑思维的好方法。
第七：养成良好的编程习惯
编程入门不难，但入门后不断学习是十分重要的，相对来说较为漫长。在此期间要注意养成一些良好的编程习惯。编程风格的好坏很大程度影响程序质量。良好的编程风格可以使
程序结构清晰合理，且使程序代码便于维护。如代码的缩进编排、变量命令规则的一致性、代码的注释等。
第八：上网学编程
在网上可以学到很多不同的编程思想、方法、经验和技巧，有大量的工具和作品及相关的辅导材料供-
8.加强计算机理论知识的再学习
思维培养学编程是符合“理论→实践→再理论→再实践”的一个认识过程。一开始要具有一定的计算机理论基础知识，包括编程所需的数学基础知识，具备了入门的条件，就可以
开始编程的实践，从实践中可以发现问题需要加强计算机理论知识的再学习。程序人人皆可编，但当你发现编到一定程度很难再提高的时候，就要回头来学习一些计算机科学和数
学基础理论。学过之后，很多以前遇到的问题都会迎刃而解，使人有豁然开朗之感。因此在学习编程的过程中要不断地针对应用中的困惑和问题深入学习数据结构、算法、计算机
原理、编译原理、操作系统原理、软件工程等计算机科学的理论基础和数理逻辑、代数系统、图论、离散数学等数学理论基础知识。这样经过不断的学习，再努力地实践，编程水平一定会不断提高到一个新高度。

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

web前端未来将会有什么样的发展趋势？

趋势一：更加移动优先
响应式设计显然是目前Web前端开发领域的主要趋势之一，并且这一趋势在未来还将持续一段时间。虽然现在的响应式设计大部分还是以PC版优先，然而如果有一天我们把PC版放到比移动版次要的位置上，也没有什么好奇怪的。因为，目前许多Web前端开发者已经开始转向以移动优先方案来做他们的响应式设计和开发，这就象征着一个重大转变，值得我们跟进的。
趋势二：更多使用快速原型开发工具
众多Web前端开发者从2016年开始尝试使用快速原型开发工具，而在2018年将是这种技术真正爆发的一年。“UXpin、Webflow、Invision以及其它许多快速原型开发工具，让设计师不用写一行代码，就能为网站和服务快速创建低保真和高保真原型，便于设计师衡量它们的可用性和美观性。” Web设计师Jamie Leeson says如是说，“许多工具也允许你在浏览器中设计原型并从工具里真正启动网站自身。”
不管未来前端发展方向如何，可以肯定的是未来前端人才需求依旧很大。想学前端开发专业的机构也很多，你可以去线下试听课程了解一下，例如北大青鸟、南京中博软件学院、南京课工场等等都有试听课程的！

web前端的行业趋势是什么？

web前端就是用代码的形式，还原UI设计师设计的界面，并实现各种交互效果。web前端工程师是程序员里面入行门槛较低的一个职业，就前端应用开发框架而言，已经形成了HTML5、CSS3、《Ecmascript 6》标准规范。

要学的内容主要有：

①计算机基础以及PS基础

②前端开发基础（HTML5开发、JavaScript基础到高级、jQuery网页特效、Bootstrap框架）

③移动开发

④前端高级开发（ECMAScript6、Veu.js框架开发、webpack、前端页面优化、React框架开发、AngularJS 2.0框架开发等）

⑤小程序开发

⑥全栈开发（MySQL数据库、Python编程语言、Django框架等）

⑦就业拓展（网站SEO与前端安全技术）

互联网行业目前还是最热门的行业之一，学习IT技能之后足够优秀是有机会进入腾讯、阿里、网易等互联网大厂高薪就业的，发展前景非常好，普通人也可以学习。

想要系统学习，你可以考察对比一下开设有相关专业的热门学校，好的学校拥有根据当下企业需求自主研发课程的能力，能够在校期间取得大专或本科学历，中博软件学院、南京课工场、南京北大青鸟等开设相关专业的学校都是不错的，建议实地考察对比一下。

祝你学有所成，望采纳。

客户端开发的成长思考

作为客户端开发程序员，首当其冲就是完成业务迭代，服务好产品用户和业务团队。服务好产品用户是业务团队存在的价值，服务好业务团队是客户端开发存在的价值。业务发展要考虑变现，要考虑增长，要考虑留存等等，最终落地的环节往往需要客户端开发来实现。
除了业务迭代，根据业务特色和客户端开发团队特点，会围绕高效研发体系和稳定研发质量不断做优化，也有的会尝试跨端能力建设、新技术探索落地。在更大一点的公司还会关注团队的技术影响力输出，以及不可忽视的安全和合规能力。
为了更好的衡量客户端质量，往往会用卡顿、卡死、crash等基础指标来评估质量，同时也会不断做包大小优化、启动优化、磁盘和流量监控、流畅度优化、cpu和电量优化等等来提升基础体验。同时还要关注研发过程中的效率提升，比如说研发流程优化、编译优化、自动化测试等等。
客户端能做的事情非常多，有服务于用户的业务方向，也有保障质量的基础方向，还有提供各种通用能力的中台方向，还有从事各种跨端建设、音视频处理、网络建设等等 。从供需关系来看，智能手机的市场规模是客户端开发岗位需求的天花板，全球接近40亿的智能手机就是客户端开发这个行业的未来保障。至于脉脉“客三消”理论鼓吹的大前端取代客户端开发，是典型的杞人忧天。从事过客户端开发的程序员都知道客户端原生Native开发是不可能被跨端的技术完全取代。RN、flutter等是在某些特定环境下会有不错应用收益，但不管是交互体验、研发体验，各项性能指标都比不上原生开发语言。

客户端开发是移动互联网快速发展的产物，本身也有一些从事的风险点，从我的经历来看，主要有以下问题：

客户端的很多日常工作是需求开发，需求开发主要是由各种业务逻辑、各类界面的实现。最常见的现象是 一年经验用三年，三年经验用十年 。由于客户端所见即所得的特点，很多开发者在度过前期的上手期之后，就一直重复使用类似的思考模式去解决问题。如果没有环境压迫，也没有自己主动去思考突破，会在日复一日的劳作中迷失成长。时间较长之后，往往会陷入能力增长的瓶颈期。

客户端开发的求职者和招聘者之间，现在有一种相互矛盾的现象： 求职者感觉外面客户端开发的需求量在不断的变少，招聘者一直在苦恼招不到人。
客户端开发的岗位减少是由于移动互联网的基建越来越成熟，相比流量成本和维护成本都更高的App，很多小公司选择使用了更加便捷的小程序、公众号、抖音短视频等等大公司提供的基础平台，导致了客户端开发的岗位需求量在不断减少。
招聘者苦恼的是招聘不到优秀的开发者，由于互联网行业常年有长期唱衰客户端开发的现象（从以前的PC开发到现在是移动端开发），再加上最近几年兴起的算法岗位和数据分析岗位竞争，越来越少的优秀毕业生投身到客户端的这个行业上，导致优秀的开发者供不应求。

“中年危机”是悬在程序员头上的达摩克里斯之剑，这不仅仅是客户端开发会面临的问题，这是所有大龄程序员都必须面对的互联网从业现状。由于前面提到的互联网基建成熟带来了的客户端岗位需求减少问题，客户端开发在中年危机这个问题显得更有压力。
但是如果觉得从事前端开发或者后台开发就不用面对中年危机，就是太过于乐观了。设想一下，一个公司为了节省成本都不做App了，他还会去招一个40的前端开发或者后端开发吗？
互联网行业在快速发展，薪酬待遇也在不断提升，这也带来源源不断的新人。 当一个新人和老人能力相差不大时，性价比更高的新人往往更容易胜出。 想要避免中年危机，唯有不断锻炼自己的能力，思考自己的不足之处，提升自己在市场的竞争力。

根据自己的粗浅认知，我觉得有下面几个方向可以努力。

大部分公司的官方回答永远是弹性工作制，事情干完就可以走。但是事情永远不可能做完，事情可以做完的公司还有市场竞争力？
我的看法是顺应潮流，合理安排时间。优先完成工作的事情，然后利用多余时间来进行学习。尽量不要把工作安排的满满当当，这样疲于奔命会让生活非常疲惫；也不要夸大工作难度、浑水摸鱼，摸鱼是对自己最大的不负责。按公司提倡的工作时间，合理安排工期，如果还有一些时间可以放松下心态，花点时间学习和成长。

可以从下面几个方向去探索：

学习如何从重复工作中学习和成长是必须的，因为再新的工作也会变成旧的工作。
学习的方向可以是做事、技术、思考、规划、团队等等，找一个当下最需要成长的能力开始锻炼。合理使用环境的压力，形成自己的学习和成长动力；偏技术侧需要自己拆分目标，逐步实现目标，这是非常重要的自驱力。
成长的过程很简单，制定目标，实现目标。目标需要有一定的量化标准，模棱两可让目标变得不可触碰。制定目标也要考虑目标的指引作用，对个人而言，目标描述的过程会比结果更加重要。
努力学习换来好结果，好结果继而激励产生进步动力，建立一个良好的正向反馈循环。

一个职业的未来，要看行业的发展前景。 移动互联网的发展规模，注定客户端在短期内仍然是刚需。至于长期发展之后，移动互联网被新的时代取代，那么也会有新的岗位延伸出来，到时再紧跟时代潮流即可。
另外要把业务和技术分开，技术只是一个工具。在前期确实需要积累客户端的知识和相关技术，但是随着时间的推移，慢慢会接触更多的知识。不要给自己设限制，在适当的时机技术栈可以扩大到后端。假如某个人只做某一个模块，那么也需要去接触这个模块的前因后果，数据的产生消费。眼界如果局限在客户端，那么只能知其然不知其所以然。重点是在于人，人才是解决问题的核心，具体的技术只是工具。

移动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.cnblogs.com/windfic/p/16019457.html

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

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