我正在考虑将React Native用于新的Web应用程序。是否可以使用它同时发布iOS和Android应用程序?
我知道这是在路线图上,但是我不清楚这将是一个单独的开源项目(例如,React Android与React Native)还是一个(例如,React Native)。
TLDR :很有可能。但这取决于您的用例。
您可以实现约 80〜99 +%的代码复用率 (取决于您使用的Android / iOS本机视图/模块的数量,例如,您是否具有自定义图形代码或低级TCP网络代码;这些只能在本机代码中完成) ;并以API的形式向您的JS代码公开。特定于平台的JS代码的数量实际上很少。此外,您还可以使用平台检查if (Platform.OS === 'android'){}以解决该问题)的代码重用,这非常不错。Dropbox和其他公司也做了类似的项目:使用c 在iOS和Android项目之间构建一个“共享”组件,同时在本机iOS(Objective- c或swift)和Android(java)中实现大多数UI代码。但是现在您正在使用Java和Objective-C或Swift来进行C ,需要掌握更多的语言,更多的复杂性和更多的精力。为了使不同的本机代码在iOS和Android上都能工作,还需要进行一些调试工作,这非常艰难。
if (Platform.OS === 'android'){}
React Native使得 使用JavaScript编写几乎所有内容变得容易得多 。但是有一个陷阱,只能共享大约80%的JS代码。在可预见的将来,您仍然需要为Android和iOS版本编写“特定于平台”的JS代码。
这就是为什么FB表示他们的目标是 “学习一次,在任何地方编写代码”, 而不是“在 任何地方 运行”。
但是除了代码重用以外,它还是非常不错的(与维护2个完全不同的版本相比,代码重用 80%以上 仍然是一个很大的进步:Android和iOS,是吗?)
Cmd + R刷新应用程序可极大提高开发速度。 等待一个大项目进行编译只会使您感到自己快要死了。
由于使用React,您可以免费获得声明式UI。 这是另一个很大的优点!由于您不再需要“挖掘”特定的UI代码。资料变了吗?只需“刷新”它,UI就会相应更新。没有浪费脑汁。
我 只是将不太复杂的Android React Native App移植到iOS 。我花了 3天时间 。对于App的要求和iOS版本的请求是突然而没有计划的。因此,如果我也为iOS设计了Android计划,那肯定会更快。 巨大的胜利:)
另一个巨大的好处是能够执行 热代码推送, 而无需经历可怕的1周应用商店审查过程。因此,不再有其他问题,“是的,我们的应用程序已获批准。让我们发布吧。噢,什叶派。严重的错误和我们的应用程序不断崩溃(至少在修复生效前一周会发生)。而且您必须乞求苹果加快速度进程”。这是可能的,因为代码库的主要部分将使用JS编写,并使用诸如AppHub或CodePush之类的工具,您几乎可以立即将代码部署到用户。Apple 有条件地 允许这样做。
3.3.2应用程序不得下载或安装可执行代码。如果所有脚本,代码和解释器都打包在应用程序中而不下载,则解释的代码只能在应用程序中使用。前述的唯一例外是由Apple的内置WebKit框架下载并运行的脚本和代码,但前提是这些脚本和代码不会通过提供与预期目的和广告目的不符的功能来改变应用程序的主要目的。提交给App Store的应用程序。
最后,作为一个开源项目, 项目寿命 往往是一个问题。对于React Native来说不是问题。内部由(FB Ads Manager)使用,并由FB(十几个FB工程师?)支持,并由Facebook支持,拥有 近500位贡献者和25k星 ,React Native充满生机。眼见为实:)(https://github.com/facebook/react- native)
编辑1
我意识到我似乎有点 偏见,只谈论了 有关React Native 的好东西 。因此,请查看https://productpains.com/product/react- native/和Github问题以了解完整情况。绝对 不是灵丹妙药 。话虽如此,它可以满足我的大多数用例,而且我很快就看不到使用本机iOS或Android。
编辑2 被Facebook发布在Facebook的F8大会上的应用程序(废话..)100%开源的,他们有一个非常好的教程,告诉你怎么可能有 两个 iOS和Android原生的经验(90%为好,因为原生?)同时实现了85%的代码重用。检查出来-> https://makeitopen.com
编辑3 您可能还想查看Flutter及其优点和缺点:)