项目旧改 原生 -> React Native

如果你的项目涉及很多原生模块，相机、视频播放，且要定制化。 那么跨平台并没有解决问题。
再招个人维护原生，才是最优解。 其次是离职。

完全重写吧

怎么混编啊，你现在不是已经 2 个项目了吗，混编还要分平台考虑编译配置和集成之类的东西，肯定是起干净项目啊

你原生迁移 RN, 你 RN 一样要维护两套，虽然不想原生差异化大，但多多少少有差异，再招个人维护吧，实在不行，跑路吧

原生先为主，一步一步的迁移，迁移后的用 RN ，没迁用原生， 逐步用 RN 替代 原生。
另外话说你怎么不用 flutter ？比 RN 好多了

对于从原生迁移到 RN ，大多数开发者通常都会选择混编的方式。混编意味着将原生代码和 RN 代码混合在一起，形成一个统一的应用。这样做的好处是可以更好地利用原生代码的优势，同时也能够更快速地完成迁移。

相比之下，完全重写意味着将原有的应用完全用 RN 代码来重新实现。这样做的好处是可以更好地利用 RN 的优势，并且可以统一应用的技术栈。但是，完全重写的过程通常比较耗时，并且还可能会导致一些潜在的问题。

对于从原生迁移到 RN ，不同的项目会有不同的最佳实践。如果您想要了解更多信息，可以咨询更多的专家或查阅相关文献，以便找到适合您项目的最佳方案。

@adminharlem AI 大哥求放过

@hai046 一个是我们依赖的第三方 SDK 有些没有 flutter 的，第二个是人不好招，内部转化需要的时间长。

开倒车啊

React Native 你如果只是部分迁移，一部分页面用 RN ，大部分用原生。实际上操作可能需要你建两个工程的。
正常 RN 开发你可能也需要两个工程。简单的说就是两边依赖的版本可能不一样，安卓可能某个依赖能工作，但是 iOS 那边不行，你得切换版本。如果你不想切换的时候重新 yarn 安装依赖。你可能需要建两个工程。

就算你在一个工程里做双端的，你也是 xxx.android.js xxx.ios.js 这种分开处理的时候会比较多。两边好处是逻辑代码大部分一样，但是具体代码还是要分开来修改的。

但是相比原生的每次修改都需要编译才能看效果，RN 的动态预览将效率提升了太多。而且因为你用的是 js ，不用每次都编译，电脑也会凉快不少。如果是 iOS 那种预览，电脑得卡的要死，而且超过一定的代码量，就不给你预览了。

如果你决定了用 RN ，千万不要马上使用 RN 的“新架构”，现在坑还很多。

@fkthiswordw 此话怎讲？

@okakuyang 多谢解答，RN 的“新架构” -- 指的是 0.7x 版本的 RN 吗？

可以在原生应用里集成 RN, 然后慢慢一个页面一个页面的迁移，如果有的功能通过 RN 实现太复杂或实现不了，可以直接在原生项目实现。

笑死我了，都 2022 年年末了还有人推荐 Flutter ，嫌凉的不够快啊...

建议先尝试迁移一部分功能试一下，混编靠谱一些，直接上来重写可能会走一些弯路。很多已有的逻辑和组件可以简单封装一层复用的。

@GreatAuk
@Bijiabo 现在的计划就是这样的，登录、设置相关的页面用 RN 重写，支付等关键业务流程用原生

@Bijiabo #14 怎么说，flutter 到 2022 年年末还是不可用状态？

这个都看你们的页面量，和对 RN 的熟悉情况。如果技术熟悉，页面不多的话，直接完全重写。否则，还是混编比较好。

@Bijiabo Flutter 咋了，不是用的人越来越多了吗？

@darkengine 对。0.7 之后模版默认开启新架构，但是你可以不用 turbo native modules 和 fabric 相关的功能就行。用了之后一些第三方库还没适配会出错，浪费时间。

插个题外话，这里面有 AI?

@Ashore 我觉得 adminharlem 是

@okakuyang 怪不得了！我照着 RN 官方的“Integration with Existing Apps”操作，都需要一步一 stackoverflow

@Bijiabo 感觉现在 flutter 应该是比 RN 火的，RN 现在处于不温不火的状态。不过我还是选 RN, 因为我只会前端...

@okakuyang 感觉现在 RN 热度不够，很多第三方库都不跟进新架构。新架构还是出的晚了点

rn 装环境装两三天还装不上，flutter2.30 分钟就行了。

@Bijiabo 首先表态 完全没有任何抵抗心态，单纯发问。
为什么说 flutter 要凉？我司现在 app 的主要开发语言就是 flutter

@GreatAuk 新架构主要解决性能方面的问题，问题是 RN 就不是一个主打性能的方向，RN 能挖掘的深度也有限。

原生到 RN 其实必然要重写啊，如果原生代码现在没有严重的问题，完全没必要迁移到 RN ，而是应该把部分页面用 RN 来实现。
https://reactnative.dev/docs/integration-with-existing-apps

RN 在低端鸡上，性能不太行

可以尝试下 expo ，跨端开发成本很低

必然重写啊

提个建议，新功能可以尝试 rn 开发，评估收益，成本，风险
再决定下一步怎么走，如果完全走 rn ，也需要客户端开发人员，提供基础 api 给 Rn

说实话 react-native 不太行，倒不如学淘宝那样直接 webview

Discord 就是啊
原生 rn

@ragnaroks webview 在不是不上架？

@dazuijuren004 flutter 都城开发语言了？

我觉得这只能是最后的选择。我会优先考虑把两端相同的东西往服务器那边挪，再添加一些 Web 页面来实现共用。

就怕你费劲半天，省了一些工作，但又多出一些活，不值得。除非从零开始，否则我会怕麻烦。

UI 肯定是重写的了，本来两套都是原生 UI 没法复用，虽然说部分可以做成 RN 的 native 组件，但是后续维护还是两套。还不如直接 UI 重写。

只要不是超高性能要求的应用我觉得 RN 都还是没问题的，RN 在大部分原生模块上都没什么问题，都有很好用的开源模块，包括相机，多媒体，蓝牙，NFC ，AI 等等等等。当然 RN 需要有人对 React 的开发把关，他不像 vue 一样那么好上手。

@Manweill 我们有两个 ReactJS 研发，比较担心的原有原生代码集成了很多第三方 SDK 例如 firebase, Square/Stripe 这种，怕在 RN 上有坑。性能倒不是主要的考量。

@darkengine 我在用 firebase sdk, 用 RN 集成还是挺方便的, 不过 firebase 本身挺多坑, 你们应该遇到过.

@darkengine firebase sdk 有官方支持的。而且很活跃 。stripe 没用过，不发表。不过个人角色海外大厂一般都有提供官方的 RN 组件，不想国内的 BAT...

@Manweill 调研了 Stripe/Square 的 RN 库，是第三方封装的，基本落后原生库几个小版本。

@Bijiabo ???怎么凉的快，3.x 我们用的挺好的啊，做海外社交游戏分发平台，6 个人做双端轻松的很，很多插件都已经很完善了，比以前好用多了，效率高，速度快。 最近我们上了一个国外的，提审还有什么的不要太好。
flutter 做海外生态真的不错。

RN 我们 19 年时候搞过一个 B 端的，现在还在用，主要用他的热更。不过效率不咋的

现在有的项目用原生，拿出来一个项目团队用 flutter ，查发比 RN 好多了，原生同学在人带的情况下，2 天内就开始开发熟悉，只要不是太笨，1 周绝对能学成 [应该会更快] ，可以试一下了解一下。特别是 dart 语言在 app 移动开发真的特别适合，就是 ui 控件名字记不住其他的都很好。

@darkengine 落后几个小版本，那应该问题不大？三方的话，难免作者会弃更或者 SDK 版本落后，到时候只能自己改。例如 aliyun 推送的 sdk ，我们就是自己包的。这些只是调用 SDK 的包装还是比较简单的。

看业务，我这几个 app ，第一年把壳子封装完之后基本上一年能更新一次 native ，所以对原生没有需求，招人只招前端

RN 只负责做 UI 部分，客户端内的固定底层的功能和模块可封装成原生 RN 组件，RN 简单调用即可。后续用 RN 还可以同构 H5 和小程序。

@hai046 现在 flutter 有热更方案吗？
RN 热更方案，AppStore 没啥问题吧？

@checkz 因为我们嵌入 unity 游戏，unity 组目前没适配 iOS ，苹果这个预计年后才开始上，后面我们上线了在回复你，不过 android 10 个月我们还是很不错的

然后发现要维护三套代码

@darkengine hello,大佬，我们项目目前也遇见了这个问题，能方便交流下吗，你们最终采用的啥方案呀

@gogolts 主项目还是选择用原生重写了，去年年底新开的小项目选择了 flutter ，目前第一版正在收尾阶段，如果团队里有会 flutter 的开发可以考虑用，不然应该快不了多少。

@darkengine 看大哥之前的描述你们之前不就是原生嘛，然后又用原生再重写。是因为迁移到 RN 的途中遇见了啥问题吗？我目前也只看见了官方文档给了个整合原生的文档： https://reactnative.dev/docs/integration-with-existing-apps?language=java