写点什么

探讨 React Native 的未来:它可能不再是最佳选择

作者:Standard Notes

  • 2023-03-14
    北京
  • 本文字数:1914 字

    阅读完需:约 6 分钟

探讨 React Native 的未来:它可能不再是最佳选择

多年以来,Standard Notes 的代码库不断发展:在 2016 年的首次发布时,我们拥有三个代码库,即网页应用(其中包括我们的 Electron 桌面应用)、原生 Swift iOS 应用,以及原生 Kotlin 安卓应用。这种形式很快便无以为继,跨三个平台的问题修复就已经很难协调了,在此基础上再要新增功能?天方夜谭。我们不得不给应用打上“简约风”的标签,因为我们真的没办法再做别的了。不过讽刺的是,这个标签可能真的有点道理。

 

从三到二的代码库

 

我们在 2017 年将移动端应用过渡到了 React Native,让代码库数量从三降为二。在那段时间我们仿佛是到了仙境,无论什么时候想加新功能,比如图片和文字加密功能,我们都只用写两遍代码,是不是很美好?不尽然。的确,最大化代码库的使用让我们不再需要重写关键业务逻辑,但这种方式也会有局限:我们需要重写两遍底层加密的 C 函数,因为我们的网页端和移动端的加密库不通用。

 

但即使最大化地榨干了业务逻辑,对于小团队来说,协调两套代码库中的新增 UI 功能也是双倍的工作量。移动端和网页端所遇到的问题不同,工作的时间线也不同,一个仅出现在移动端的问题可能会需要两天时间来修复,导致移动端和网页端双方都长期处于不同的波段上。同步网页端和移动端的新功能永远是个难题,而一般来说,网页端的开发速度总会快与移动端,从而导致移动端总是处于落后状态。由此导致的后果是,无论是移动还是网页,我们都看不到明显的新功能出现势头。

 

React Native 的构建永远会需要大量第三方库。其本身的程序包便是个品种独特的庞然大物,因为 React Native 包的作者本人也是会需要重写两遍代码的人:一次写 iOS 的代码,一次写安卓的代码(当然也包括 JavaScript 的 wrapper)。其后果就是大量库的弃用和稳定性问题的急剧出现。另外,保持自己的包与最新版本的 React Native 同步这件事是想想就头疼,毕竟 React Native 是出了名的难以保持更新。

 

终于有一天我们受够了折磨,两个代码库对我们来说还是太多了。要是能只写一遍代码该多好,我们的发布速度能有多快,所有的质量和关注中心都将集中在一处,我们再也不用马后炮似地对待移动设备,再也不用为将新功能额外同步给移动端而发愁,再也不会因为移动端新增功能的困难重重和不切实际的双倍工作量而被迫放弃想要的功能。在一个代码库里加功能就足够了。

 

一个代码库

 

在我们完成两到一的代码库迁移后,我们只恨没早点这么做。如今的 Standard Notes 只有一个代码库,移动端应用程序变成了网页程序的一部分,区别在于后者可以访问原生的移动功能,且运行效果比我们想象中要好很多。目前网页端功能已经可以一比一同步移动端应用,这在我们的旧配置中是完全不可能达成的,不仅如此,网页端应用也能访问到本地原生移动端钥匙串(keychain)、生物识别、本地存储、摄像头,等等。

 


移动端应用学院

 

从 React Native 中移除 React

 

我们的迁移过程其实很简单,主要在于桥接网页环境和移动环境的落差。我们全新的移动应用依旧使用 React Native,但只包含用于渲染网页视图(webview)的函数这一个组件。网页视图通过 postMessage 进行网页与移动环境之间的消息传递,当网页端试图访问设备的钥匙串时,其会向原生环境发送一则消息,而原生环境则回复以一个原始值。

 

但无论原生环境还是网页环境都完全无需担心“消息传递”的细节,这些不过只是函数调用。网页环境不用知道自己的函数调用会在后台被转换为 postMessage 调用,就像使用其他异步函数调用一样,网页端只用 await 回复即可。我们不想在文章里包含太多技术细节,但从更高层次来说,我们的架构中所包含的各个平台都仅仅需要在应用示例中提供一个叫 DeviceInterface 的类,这个接口让应用程序可以在任何平台上运行,哪怕是命令行都行。设备接口会提供对如数据库、钥匙串、摄像头等设备 API 的访问。

 

构建移动应用的实用方法

 

别误会,React Native 还是有很多闪光点的,它的社区和包的生态系统非常活跃,甚至可能是超越其他生态系统的活跃度。但如果你也遇到了两个代码库对小型团队而言嫌多的情况,不妨试试这个方法。不用把网页应用的 UI 完全推翻重写成 React Native,只需要利用 React Native 当作桥梁,从网页应用的核心访问本地系统功能。因此,我们的新移动应用预计会比一直在吃半原生应用尾气的旧版强上无数倍,自己试试吧!

 

如果你想立刻动手,欢迎采用与我们类似的方法,或者也可以参考Capacitor之类的库,不过后者没有像是 React Native 这种拥有丰富第三方包的生态系统。

 

原文链接:

https://standardnotes.com/blog/react-native-is-not-the-future

相关阅读:

React Native 框架与小程序混编的方案

React Native 跨端框架与小程序混编的方法

React-Native 开发实用指南

为什么有人会更喜欢 React Native,而不是其他跨端框架 ?

2023-03-14 14:494814

评论

发布
暂无评论
发现更多内容

ARTS打卡Week 10

teoking

学了那么多技术,为何依然成不了架构师

菜根老谭

架构设计原则

BGP、OSPF、MPLS路由协议RFC分享

Phantasm

ARTS-WEEK10

一周思进

ARTS 打卡计划

微服务、DDD

chenzt

十年一梦,小米的原罪得到救赎了吗?

脑极体

那些不可貌相的代码规范

废材姑娘

代码质量

《Java并发编程的艺术》读书笔记1:说说并发编程

Jason

多线程 并发

【API进阶之路】帮公司省下20万调研费!如何巧用情感分析API实现用户偏好调研

华为云开发者联盟

反馈 API 华为云 API Explorer平台 用户调研

Android 原生 SQLite 数据库的一次封装实践

vivo互联网技术

sqlite android 数据库

热潮-区块链的价值能够体现在哪些方面?

CECBC

区块链技术 标准化 应用价值

ARTS打卡 第11周

引花眠

ARTS 打卡计划

应用开发基础之-并发编程

superman

ARTS 打卡(20.07.20-20.07.26)

小王同学

Java 常见的几种 OOM

hepingfly

Java OOM

面试这么撩准拿offer,HashMap深度学习,扰动函数、负载因子、扩容拆分,原理和实践验证,让懂了就是真的懂!

小傅哥

Java 面试 hashmap 负载因子 扰动函数

一次好的聊天可以超过自己努力啃几周的书籍

良知犹存

程序人生

品质网络的迭变之路,以及运营商的未来之匙

脑极体

当实证资产定价遇上机器学习

分析101

人工智能 学习 金融科技 金融 资产定价

Suricata-流的处理

Phantasm

网络安全 suricata flow

“云”上教与学,让教育不止步于课堂

Geek_116789

吃灰的旧显示器别扔!

小匚

学习 随笔杂谈

求刚好大于当前数组组合,Code Review最佳实践,JVM框架原理,JVM垃圾回收原理 John 易筋 ARTS 打卡 Week 12

John(易筋)

Code Review ARTS 打卡计划 JVM虚拟机原理 JVM垃圾回收原理 Array算法

十多位全球技术专家,为你献上近十个小时的.Net微服务介绍

newbe36524

容器 微服务 .net core netcore

计算机网络基础(十六)---传输层-可靠传输的基本原理

书旅

计算机网络 网络 协议族 网络层

云图说 | 3分钟创建一个游戏类工作负载

华为云开发者联盟

Docker 容器 华为云 工作负载 2048游戏

如何让区块链技术能够更好赋能数字社会建设

CECBC

区块链 数字经济

深化区块链技术的应用 体现其价值产业发展良机

CECBC

区块链技术 数字经济

边云协同!EM-BOX视频分析盒加速安全生产场景落地AI应用

百度大脑

人工智能 人脸识别 图像识别 百度大脑 人体识别

设计模式之——JDK动态代理的源码分析

诸葛小猿

动态代理 cglib 代理模式 Proxy

程序的机器级表示-控制

引花眠

计算机基础

  • 扫码添加小助手
    领取最新资料包
探讨 React Native 的未来:它可能不再是最佳选择_语言 & 开发_InfoQ精选文章