浅谈跨平台GUI方案,以及一些思路

之前一直想着写一篇这样的文章,结果都没有时间整理一下,现在Airbnb宣布逐渐放弃React Native,而微软前脚刚宣布用React Native重写Skype而不是Xamarin,想着也是时候该写一写了。

这篇文章不会深入去比较各大方案的pros&cons,仅是简要的分析目前方案存在的一些问题。

本文也不会讨论小程序等二级公民方案。

本文可能会是广告文。

感觉这一辈子都在和跨平台较劲。

你可以在网络上找到非常多的跨平台GUI方案,大大小小,有大公司鼎力推荐的,也有个人业余维护的,而总结来看,这些方案可以有如下几个分类

  1. 按所跨的平台进行分类,这样分类也许会有些不严谨,因为有些方案对一些平台的支持并不算完善,仅仅是“可以用”
    1. 移动跨平台:跨Android和iOS平台,例如
      • React Native
      • Weex
      • Flutter
      • Ionic
      • PhoneGap
    2. 桌面跨平台:跨Windows、macOS、Linux平台,例如
      • Electron
      • Gtk
      • Java Swing
      • JavaFX
    3. 跨全平台:同时支持Android、iOS、Windows、macOS、Linux平台,甚至有些还会支持小众平台如Tizen,例如
      • Xamarin.Forms
      • Qt
      • AvaloniaUI
  2. 按实现方式进行分类,我对于一些方案的了解不深,也许会有标识错误的
    1. 基于前端技术
      • React Native
      • Weex
      • Ionic
      • Electron
    2. 基于绘图引擎渲染
      • Flutter
      • AvaloniaUI
      • Gtk
      • Qt
      • Java Swing
    3. 基于控件映射
      • Xamarin.Forms

可以说大部分的跨平台方案都是为了一个目标:一次编写,处处运行。而实际操作大多也比较接近这个目标,但是总是会有几个令人不爽的痛点存在:

  • 生态不够成熟。目前生态比较好的方案例如React Native,或多或少的存在着生态没有Native开发成熟的问题,能够同时支持多平台的开源库并不是很多,即使有也可能会存在一些质量上的问题,使得许多东西甚至是基础设施需要自行实现,比如Airbnb提到React Native并没有一个成熟的crash monitoring,最后不得不自己实现。一些优秀的第三方Native开源库的引入将会是很麻烦的事情甚至是不可能。
  • 性能仅仅是刚及格甚至更差。目前除了基于绘图引擎渲染的之外,很多方案都不是与Native层有直接交互,这些方案往往也同时存在着一个或者多个VM,这在桌面平台上也许看不出性能上的问题,但是在资源相对吃紧的移动平台上就很容易产生性能问题,而面对复杂布局时就更容易产生性能问题。
  • 应用体积不好控制。Xamarin.Forms和React Native最终生成出来的包大小都远远大于Native开发生成出来的包大小,若是对于体积比较无所谓的话时不成问题,但是若是体积敏感就很头疼了。
  • 虽然说是跨平台但是实际开发仍然需要Native的知识技能,否则在Debug时很难定位问题,对于团队来说实际需要的知识量更多了。
  • 一些方案的冷启动速度很慢。
  • Debug并不是很友好。
  • 方案本身因为不成熟所带来的Bug。
  • Native版本升级新功能不会第一时间跟得上。

目前跨平台开发体验是大问题不多,而小麻烦不断,各种细节上的小问题使得开发体验不尽人意。如果你的产品并不是很复杂,或者设计上与平台相关的东西几乎没有,比起Native开发,跨平台的方案也是一个很好的选项。而如果你的产品对一些指标要求很严格,比如说应用体积、冷启动速度,那么跨平台方案就不适合作为备选方案之一了。

为了解决以上的跨平台开发的一些痛点,我在几个月前想出了一个折中的解决方案。

(以下大概是广告)

这个折中方案的思路是:通过一个DSL,生成对应的Native布局。而这个DSL,可以放在本地,也可以放在服务器。一切都是可以与Native层直接交互,存在的JavaScript Runtime也只执行简单的操作,并不会取代Native开发,而是可以与Native开发混合进行。

这东西目前先叫Shiba,文件扩展名可能是.sb,JavaScript文件扩展名可能是.sb.js(逃

Github: https://github.com/Tlaster/Shiba

这样的方案可以解决:

  1. 生态问题:完全的Native生态,你可以生成你想要的Native布局,与布局的交互和原来Native方式完全一致。
  2. 性能问题:除了首次生成/渲染之外,不存在更多的性能消耗。经过测试即使是长列表其表现也与Native表现一致
  3. 应用体积:你可以将布局的DSL放在服务器上,反而减小了应用体积。

很巧的是,这个思路和Airbnb现在的思路不谋而合。Airbnb提出了Server-Driven Rendering,简单说就是服务器保存布局DSL,而客户端来解析和渲染,不同之处是Airbnb或许是想要基于绘图引擎来进行渲染,类似Flutter那样的渲染机制,而并非生成Native布局。你可以在这里阅读更多

而这样的方案仍然还是会存在问题,比如说仍然需要学习一种新的技术,对于开发人员的要求并没有降低。

Shiba的定位并不是瑞士军刀,而是轻量级的解决方案,并且会着重于与Native的交互。prototype也已经完成,下一步就是开始整理和完成了。

简单的Roadmap:

2018 Q3:Android && Windows平台发布alpha版本

2019 Q1:iOS平台发布alpha版本

功能上要求:

  • 原生的MVVM Databinding
  • Databinding时可以执行Native方法或者JavaScript方法作为Converter
  • 事件(如click)可以直接调起Native方法或者JavaScript方法
  • 可以与Native混合开发,也可以只使用Shiba进行开发

alpha版本要求完成:

  • DSL解析
  • 布局生成核心
  • 基础布局生成
  • 基本JavaScript Runtime

beta版本要求完成:

  • 可选使用基于绘图引擎的渲染核心

希望最后可以完成这么一个东西,毕竟也是自己要用的。

发表评论

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据