“互联网+”
技术服务解决方案提供商

18638179199
”互联网+“
技术服务解决方案提供商

移动端开发方案发展史

react nativereactjavascript
刘大可 2019-09-04T12:17:19.000Z
161 0 2

首先希望大家抱着轻松愉快的心情阅读本篇文章分享!不一定让自己学到什么,但多少或看到些自己感兴趣的字眼。

最近大家都开始走向全栈开发,但是现在各种开发框架群魔乱舞,这里就拿我自己懂得有理解的先写一篇文章,分析下各个移动端框架的优劣势,虽说不能让大家深入了解,但可以有一些前瞻,来针对以后的开发中的方向。

tip:下个月分析web端(这次准备不充足,不敢讲)

移动端开发到现在已经走过了十多年,其中开发方式也从开始的单一门路,发展到现在可以根据不同的需要选择合适的开发方式。其中一些方式利弊虽然很明显,但不了解原理就可能会被表象“蒙蔽”了双眼,导致自己开发之路越走越困难。尤其一些需要长期维护的项目,希望兼顾性能与开发效率,但这两者却常常对立。加之现在各种开发框架、跨平台轮子漫天飞舞,各家偏向都不同,免不得让人选择困难症无从下手。所以在立项之初,具体分析下自己当前的业务需求,再选择合适的开发框架就显得更重要。

主流架子总览

以下是移动端通用App相对主流的开发方案,还有一些野路子,就不列举上来了。
(例如:Cocoas2D、Unity3D来开发普通交互应用)

现在主流开发方式总体分为一下3+1种:

开发方式 实现途径 使用语言/上手难度 主流框架 支持团队 成熟程度/当前热度
原生OEM iOS/Android OC or swift、Java or Kotlin/五星 UIKit/android.view 苹果/谷歌 五星/理论上最火
翻译式框架 翻译式跨平台框架 js:仿web单页面应用写法、自定义桥接/三星 rn/weex facebook开源/Apache开源 三星/git 7w star
Web式App 单容器webview js:webview内嵌web单页面应用、js桥接/两星 Cordova/DCloud全家桶 Apache开源/国内团队 四星/不可描述
自定义widget 放弃OEM,自己渲染 Dart/四星 Flutter 谷歌 二星/git 8w star
由于国内web式跨平台框架很多,但原理基本一致,性能差距不大,所以这里作为一种来分析。

我知道大家都喜欢看表格,因为可以只选择自己喜欢的列重点看分类对比。是的,我也喜欢这么看~那就在来个表格对比下。
优劣势

图片源自网络。
image.png

图中的大部分内容我认为还是很有参考意义,不过前景这一栏内容仁者见仁智者见智(毕竟我大web天下无敌)。结论也总结的很客观,下面我就我自己的分析对条目进行些补充。

Native

Best:轮子最多,不存在你见到却无法实现的问题。性能最优丝丝顺滑。
Worst:无法轻量开发,简单模块却附带很大工作量。尤其是web开发人员上手会很难接受。环境配置相比web繁杂非常多,初入开发难以入门。

-----“我就加个按钮,添个背景图你告诉我要俩小时???”:来自某web开发的吐槽

翻译式框架

Best:轻量项目native开发人员的福音,用少量不影响使用的性能损耗偷取大量UI工作量。
Worst:乍一看没有什么缺点,属于对native雪中送炭之举。但我觉得rn最大问题在于占据了大量开源资源,但解决问题方向不彻底,翻译机制隔靴搔痒,并没有真正意义上解决跨平台开发。

Web式跨平台

Best:轻量快速开发,真正的write one run “anywhere”。
Worst:受限于native webview的发展,性能也受限于各家Web Foundation内核。开发质量天花板几项中最低。

自定义渲染

Best:,这个跨平台方向对了,自己写OEM,性能开发双兼顾,而且属于那种千呼万唤始出来,大厂牵头热度火,众人拾柴火焰高。
Worst:Flutter出生时间尚短,大量问题未解决。且从原理上讲,这条路线的孵化时间要远比翻译式跨平台长很多。未来如果大厂有合作意向后,会不会在成熟前就被其他几条碾压?到那时Flutter有没有活下来的必要都是个未知数。

小结

所有开放框架其实都有两面性,有利就有弊。性能与效率总是像鱼与熊掌般不可兼得,但是随着时间迭代,新框架总是能在这两者平衡间有新的突破。未来的开发之路肯定是越来越高效与便利,我们也应不停的去磨砺自己。永远不要停留在过去,永远不要!

具体开发方案推荐、如何选择

小型项目

适用场景--用户交互也不频繁、展示为主。但可能需要跨多平台。
Expo

基于react native二次封装的开发框架,相比rn更符合前端风格,前端团队可迅速切入,扫码安装、写react画页面、基本无感的native环境配置使它深受web人员喜欢。成品项目改写web版本相对容易,但暂不支持直接编译出web版本。

  • 特点:比web式的性能好交互佳、前端人员亦可快速上手且项目质量优于web。

  • 缺点:不支持web。所以需跨web直接弃用。

DCloud全家桶

DCloud是一个平台,汇集了国内主流基于webView的单页面应用式跨平台开发框架,类似Apache的Cordova,界面本质上还是webView承载的web单页面应用。可以直接跨所有web平台,DCloud里还有可以直接输出小程序的框架。所以如果是展示为主的多端应用是最好的选择。但由于是web,所以无论引擎多么优秀(被吹上天的v8也包含在内),js固有的交互消耗是逃不掉的,白屏时间久。UI响应固有消耗分平台差异消耗在0.2-0.4秒之间。在桥接和native接口方面比Expo少。
另外,还有个隐含的缺点,由于webview在各移动端都存在多多少少的内存问题,所以性能优化上基本无解(不过一般不影响)。

  • 特点:成本低、开发周期短,web通用,可输出小程序,小项目使用优势很大。

  • 缺点:强交互下很难受,且难与native高度混用来补偿劣势。

中小型项目

适用场景--用户操作敏感频繁,但没有高级功能的应用,且无需跨平台到web.
React native

翻译式跨平台开发首选,相似竞品有weex,不过由于类似所以使用最成熟的即可,篇幅内不再重复推荐weex。翻译式跨平台框架其实可以理解为自己写了一套js映射规则,将所有“web”组件映射成对应的native组件相比web式有更好的用户体验,自称媲美原生,但在重量级的页面实现上还是有明显差距,尤其在长列表和层级很多的复杂UI上。

整体框架单Application,纯react native实现,必须原生实现部分桥接处理。
因为是接下来主力使用的框架,稍微列举下具体的框架使用。

  • redux //数据驱动
  • react-navigation //路由管理
  • react-native-elements //UI
  • antd-mobile
  • react-native-animatable //基础动画库

上面这些都是是必备的组件,下面列举很有用但不是必要的

  • bindingX
  • camera
  • code-push
  • native-toast、MBProgress
  • catch-compress
  • sound-recorder

至于各个组件作用可以自行百度。有了这些组件,全rn项目的native硬件方面的壁垒就算基本打通了,开发也就会更加得心应手。
当然还是缺少两个组件,是对我们当前项目组来说很重要的东西

  • LiveStreamPlayer
  • SVGAPlayer

这其中直播播放器,是整个项目中的核心组件,需要桥接

中大型项目

有独立团队线路维护

使用原生开发,组件齐全,资料充裕,性能最优。除了开发量巨大外基本没有缺点。现在主流的大厂独立项目也都是原生为主要框架,搭载着各种混合开发的框架做试用。在有必要使用原生的模块完全使用原生开发,在简单交互的模块使用原生内嵌rn模块。
这个方向也是以后团队内主流的使用方向之一,所以稍微列举下。

  • iOS-DeepLinkKit+Android-DeepLinkDispatch //维持原生容器路由跳转
  • AFNetwork + OkHttp //网络基础库
  • rn bridge //rn模块注入、及与原生通信
  • native全家桶–SDWebImage、MBProgress等等
  • rn全家桶redux、navigation…

工具箱

公司转型做产品到现在大半年了,产品、方向这种事现在我还没什么深刻理解,也没有滔滔不绝的商业案例给大家安利,引导我们该如何发展巴拉巴拉的。
但有件事我倒是挺清楚的,缺乏基础工具和代码,和按照这些专业的工具制定的一套完整交付或者说发布完整功能的流程。
比如现在新来一个客户,需要李晓青或者销售那边整理用户的资料,然后挨个给到我们开发,我们再对着自己的代码来一个一个得出版本,补充数据等等一系列流程化得操作,但实际很多流程步骤能有第三方得开源技术平台来代替,而不用开发一个个去来回注释代码来回发布,费时费力还容易出问题。

vue:https://github.com/vuejs/awesome-vue

其实各个框架在git上都有相关的awesome合集,这里发出来不过抛砖引玉,希望大家之后能把很多好用的网站分享出来.

最后留一个问题,咱们公司内要不要组件一套内部管理的流程工具。举个例子来说:
VSCode开发插件统一及Snippets共享
内部库代码专人维护建内部git
打包交付部署Jenkins
至于saas化部署配置该怎么标准化管理或者说有什么工具暂时不知道,大家可以讨论下。

总之一个目的,以后销售和演示,每一步都有工具可用,不再每次都由开发来做代码层面的维护。

2
2

点击展开全文

0/200

全部评论

    查看更多