分类目录归档:技术分享

从 React Native 到 Flutter,移动跨平台方案的真相

作者:LeanCloud 工程师郑鹏

2018 年 12 月,Google 发布了 Flutter 1.0 正式版,似乎再次点燃了人们对移动跨平台开发的热情。上一次出现类似的情况,是在 15 年年初,Facebook 发布 React Native 的时候。四年不到的时间里,有两家大公司相继推出了自己的移动跨平台方案(当然还有 16 年的时候,微软收购了 Xamarin,不过没有前两个那么引人注目罢了),同时这些方案也受到了市场的追逐。这些现象,似乎预示着,跨平台开发才是移动开发的未来,或者说,跨平台开发才是一种更好的开发方式。

既然它是热点,那肯定有可以讨论的地方。不过,在说 React Native 和 Flutter 之前,我觉得要先谈一谈「跨平台开发」。

移动跨平台方案

那什么是「跨平台开发」呢?

通常意义上来说,如果你想在 iOS 以及 Android 系统里,提供有相同内容的 App,那么使用 Apple 提供的构建工具,开发一个 App,然后上架到 AppStore,同时使用 Google 提供的构建工具,开发一个 App,然后上架到 Google Play。这两个 App 的实现,除了使用的工具不同之外,大部分业务逻辑是相同的。你可以发现,在这个过程中,产生了「重复」。

在重构时,如果项目里有大量的重复代码,或者重复逻辑,我们一般会将这些代码或逻辑以函数,模块或库的形式做封装,这个过程最大化的消除了重复的代码,最终达到简化项目的代码这一目的。

所以在我看来,「跨平台开发」也是基于这个思想而产生的,人们想要一套减少甚至不用写重复逻辑的解决方案,然后市场给予了人们期望的方案。跨平台方案的最大特点,可以用 Sun 当年在推广 Java 时,所使用的一句口号:」Write once, run anywhere」 作为总结。这一句话,也被如今的 React Native 以及 Flutter 引用或继承。

React Native

React Native 是由 Facebook 所主导的跨平台方案,得益于 Javascript 以及 ReactJS 的流行,React Native 在推出时,便受到了大量的追捧。除了跨平台的特性,React Native 最大的特点就是,可以使用 Javascript 来构建移动应用,并且最终应用的表现形式,可以做到和使用原生开发套件开发的应用相差无几。

React Native 能做到这些的核心原理就是 JavaScriptCore,一个 JavaScript 虚拟机。通过 JavaScriptCore,Javascript 能和其它语言互相转义,同时 JavaScriptCore 能运行在 iOS,Android 以及其它平台上,这些可能性放在一起,就成为了 React Native 的基底。有了这个基底之后,Facebook 便在这个基础之上,封装了各平台的应用层接口,定义了 Javascript 和封装后的接口之间的通信协议,最终,实现了使用 JavaScript 在不同平台开发具有原生体验的应用。

从实现原理以及架构上来看,React Native 似乎是一个不错的跨平台方案,只要封装好各平台的 API,那么我们有理由去相信,人们能够使用 React Native 开发出品质优秀的应用。但是事实上,理想和现实,还是有差距的。在 18 年,Airbnb 以及 Udacity 相继发表了博文,声明全面放弃 React Native,转向原生应用的开发。他们在文章中,提到的最多的就是,React Native 是一个不成熟的方案,虽然它有许许多多的优点,但是这些并不足以去弥补它的缺点带来的损失。AirBnB 以及 Udacity 可能是因为各种预期的理由而放弃了 React Native,不过在我看到 Discord 团队发表的 Why Discord is Sticking with React Native 博文后,算是彻底打消了我在生产环境使用 React Native 的念头。整篇文章看下来,让 Discord 团队仍然继续使用 React Native 的最大原因,似乎就是项目已经使用了它,骑虎难下了。

JavaScriptCore 的局限性,Facebook 在项目管理上的不成熟,以及不断出现的放弃声明,最终让人们发现,React Native 是一个有趣的方案,但并不是一个成熟稳定的方案。

Flutter

就在 React Native 的人气不断下跌的时候,Google 在一个恰到好处的时机,推出了一套跨平台方案:Flutter,将人们的目光再次聚集到跨平台开发上面。

Flutter 使用 Dart 这门较为冷门的语言来做开发,底基引擎主要由 Skia 和 Dart runtime 构成。Flutter 通过 Skia 和各平台的底层图形库对接,同时提供丰富的基于 Skia 的控件,来实现跨平台的开发。React Native 采用的方式是封装各个平台的应用层接口,而 Flutter 则直接打造了一套跨平台的应用层的开发套件。对这两种不同的方式,我们可以有一个直觉上的判断,Flutter 在性能上是要优于 React Native 的。因为 Flutter 的这种实现方式,其实早已被大量并广泛的使用了,最明显的例子就是游戏引擎。

种种对比和迹象表明,似乎 Flutter 是一个比 React Native 更好的跨平台方案。目前 Flutter 仍旧处于一个上升的势头,也有如阿里巴巴这种大厂给 Flutter 背书,颇具野心的底基框架让开发者有理由相信,只要投入足够的人力,Flutter 可以做到和原生开发一样好。

然而,Flutter 的缺点,也是源于它自行打造了框架,在很多平台特性上,诸如密码管理,选择光标等,Flutter 目前并不能支持,未来能否支持也要打上大大的问号,平台的特性可能和原生组件深度绑定,且目前没有其它接口,所以 Flutter 在现在这种状态下,只能是放弃这些特性的支持。需要提一点的是,React Native 在这方面没有太大的问题。

尽管有一些问题,不过 Flutter 表现出的潜力,还是让人们觉得,这是一个值得一试的方案,只要 Google 给予足够的支持。所以 Google 会吗?

结语

那么,我该选择哪种方案呢?答案:It depends on you.

事实上就是,没有一个完美的方案,任何方案都有利弊和取舍。想使用 Javascript 开发应用,那么就使用 React Native;想构建高性能的跨平台应用,Flutter 是个不错的选择;想最大化平台特性,那自然是原生的开发方式。

除了跨平台方案之间的比较之外,跨平台方案也在和原生开发方式竞争,而且这种竞争往往是不平等的,跨平台方案在新特性的支持上,始终要慢于原生开发方式,所以在市场占有率方面,原生开发方式就有天然的先发优势,这种差距很难被抹平。最终,你可能会发现,也许原生开发方式才是最合适的,因为除了「重复」外,原生开发方式相比跨平台方案,没有其它缺点了。

附记:之前我在 2019 年 3 月的 RTC Dev Meetup 北京站交流过上面的想法,感兴趣的读者可以查看演讲视频和 slide。

题图:Chris Sabor

2019 前端框架对比及评测

Jacek Schae 原作,授权 LeanCloud 翻译。

我们将基于 RealWorld 示例应用对比前端框架。RealWorld 示例应用的特点:

  • RealWorld 应用

    比待办事项类应用更复杂。通常待办事项类应用不足以传达足够多的知识见解构建实际应用。

  • 标准化

    项目遵循特定规则。提供后端 API、静态标记语言、风格、API 规范。

  • 专业人士编写、审阅

    理想情况下,会是高一致性、高真实度的项目,由使用该技术的专业人士编写或审阅。

比较的库和框架

撰写本文时,RealWorld 示例应用仓库共包括 18 个 Conduit(Medium.com 克隆应用)实现。

本文不考虑框架的流行程度,RealWorld 仓库中列出的前端框架皆纳入对比范围。

RealWorld 前端框架

测度

性能

应用显示内容、可以使用需要花多久?

尺寸

应用有多大?我们只比较编译后的 JavaScript 文件大小。所有应用使用同样的 CSS 样式文件,CSS 文件加载自 CDN。所有应用使用的 HTML 也是一样的。这些框架都支持编译或转换为 JavaScript,所以我们仅仅测量 JavaScript 文件大小。

代码行数

根据规范创建 RealWorld 应用需要多少行代码?公平地说,某些实现的功能要略微多一点,但这应该没有什么显著的影响。我们仅仅测量每个应用的 src/ 目录。

性能

我们将使用 Chrome 的 Lighthouse Audit 测试性能。Lighthouse 返回 0 至 100 间的评分。0 为最低分。
继续阅读

LeanCloud 开源工单系统 LeanTicket 焕然一新

相信很多开发者已经注意到,LeanCloud 的工单系统 LeanTicket 改版了。新版的 LeanTicket 不仅更新了界面,采用了响应式的页面布局来适配移动端,并且添加了诸多新功能,如增加了更多的工单状态来更清楚地罗列工单时间线的变化和下一步行动、完善了统计报告、优化了系统响应速度等等。

继续阅读

LeanCloud 层层加固云端数据安全性之剖析

程序代码中的一个逻辑 bug 可能会引发数据错误、界面显示错乱,甚至是程序崩溃。作为开发者,谁摊上这事都恨不能赶紧修掉 bug,万不可拖到使用者们义愤填膺地来砸招牌。

可如果是一个数据安全性的问题呢?使用者还是能正常使用程序,没人知道这个问题的存在或隐患,包括开发者自己。直到某天使用者们突然收到很多骚扰邮件,他们在应用中的数据被人恶意篡改,甚至所绑定的信用卡信息也被窃取……此刻,开发者才幡然悔悟——数据安全性问题可不像之前提到的那类 bug 那样容易搞定,即使堵上了漏洞,使用者的信息也还是泄露了出去,被篡改的信息没那么容易恢复,经济上的损失更是难以估算。

LeanCloud 作为一个将各项服务的 API 直接开放给客户端,并拥有数以万计开发者和海量应用的 BaaS 服务,势必要提供针对数据安全的各种保障机制。但更重要的是,只有开发者们了解并掌握了这些数据安全机制的用法,才能根据实际需求来有效地为应用数据加上防护措施。

继续阅读

Apple 领头普及 HTTPS,你的应用可做好了准备?

Apple 在 WWDC 2016 Session 706 中提到,Apple 将在 2016 年结束时强制实施 ATS (App Transport Security)。这意味着什么呢?

先来说 ATS。ATS 是 Apple 为保证应用数据在网络中安全地传输而制定的规则,其核心是鼓励开发者使用安全的 HTTPS 协议与服务端进行通信。也许是考虑到大量应用还在使用 HTTP 协议的原因,Apple 刚刚推出时 ATS 并没有强制要求应用遵循它。可现在 Apple 明确表示在 2016 年结束时所有新提交的应用都必须遵循 ATS,否则审核时会被拒绝。

继续阅读

福利来了!快用 LiveKit 打造自己的直播传奇

leankit

直播,这种最新潮的社交模式,现在火得是一塌糊涂。像秀场、教育、健身、游戏、电商等类型的应用,都可以结合直播开发出独具匠心的产品体验,迅速提高用户量级。基本的直播功能包括视频流传输、聊天、弹幕、打赏等元素,鉴于业界目前还没有完整统一的解决方案,有需求的开发者只能自己去苦读文档,重新发明轮子。我们认为这种现状必须改变!

现在向大家隆重介绍 LiveKit 直播 UI 套件。它是基于 LeanCloud 实时通信服务七牛直播服务,由我们精心打造而成的 UI 套件,既包含直播、文字聊天、弹幕、送礼物等界面,又提供灵活的用户账户接入体系。开发者通过调用这些现成的 UI 和接口,可以快速地为自己的项目植入直播与聊天功能。

继续阅读

LeanCloud 推送支持 Cordova 了!

PhoneGap 被业界大佬 Adobe 收购之后又被转送给了 Apache 社区,现在换了个更洋气的名字 Cordova。尽管 PhoneGap 所推行的概念多年前就被推崇,但是得力于浏览器的发展以及前端框架的不停进化,很多大厂也开始重新审视 Cordova 的未来,微软已经在最新版本的 Visual Studio 2015 里面内嵌了 Cordova 的开发组件。

不久前有用户询问在 Cordova 项目中使用 LeanCloud 存储以及推送服务的接入方式,我们便对如何在 Cordova 上使用 LeanCloud 聊天服务进行了调研,结果发现有位热心用户早在两年前就开发了一款 Cordova 的推荐以及数据统计的插件,原地址为 Hybrid-Force/cordova-plugin-leancloud,而后另一位热心用户又对该组件进行了优化 BenBBear/cordova-plugin-leanpush 并补充了许多说明。

于是我们基于这两位用户的劳动成果,重新对部分逻辑进行了优化,并更新了关联的 Native 的 SDK 版本,这样 LeanCloud 推送支持 Cordova 的插件「cordova-plugin-leanpush」就诞生了。

欢迎大家试用并通过 Github 向我们反馈!

现在是切换到 Swift 的合适时机吗?

d0f9dd8d7be60c6eefe347899661b454_b

回答这个问题之前,让我们先来简要地回顾一下 Swift 的发展状况。

时间退回到 2014 年 6 月。那时 Swift 刚刚发布,开发者们普遍认为 Swift 还达不到生产环境的标准,再加上一些以偏概全的 benchmark,甚至有人认为 Swift 不过是个玩具。大家有理由相信经历了几十年考验的 Objective-C 将继续承担生产工具的重任。

2015 年 Apple 对 Swift 进行了一些针对性的改进,包括性能提升和语言方面的增强(引入了 Error Handling、Protocol Extension 等)。2015 年 8 月 Apple 发布了 Swift 2,并于同年将其开源。2016 年 Swift 延续了如火如荼的发展态势,Apple 也计划在今年秋季发布 Swift 3 的稳定版。就在写这篇文章的时候,Swift 3 语言的演变已经达到了最后阶段,一切都在良好有序地进行着。

下面我们来看看从 Objective-C 切换到 Swift 的利弊。

继续阅读

Python SDK 支持可选静态类型检查

LeanCloud Python SDK 在兼容 Python 3 之后仍然不断改进,现在已经支持 Python 3.5 的最新特性「类型提示」以及通过 Mypy 对 Python 代码进行类型检查了。

首先让我们了解一下什么是类型提示。动态语言的一大优势是在声明变量时不需要去指定变量类型,程序会在运行时候解析出变量的类型,这样能够减少一部分代码量,加快程序的编写速度。然而优势有时也是劣势。虽然不声明变量类型在编写程序时能带来方便,但很多时候却会降低程序的可读性。

继续阅读

这些年我们爱着的 Objective-C

obj-c

Objective-C 是开发 OS X 和 iOS 应用的标准语言。即便是天天跟它打交道的开发者,有些也会误以为 Objective-C 就是 Apple 公司创建出来的语言,但实际上它并不是 Apple 的亲骨肉,而是从别人家过继过来的孩子。

程序设计语言是一个规范,它可以有许多种实现。在历史的漫漫长河中也出现过其他 Objective-C 实现,下面我会主要以 Apple 的 Objective-C 实现来论述。

继续阅读