项目旧改 原生 -> React Native

[darkengine]

如题，维护两套原生代码实在太累。

对于从原生迁移到 RN ，大佬们有最佳实践可以分享吗？

混编还是完全重写？

[NonClockworkChen]

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

[C603H6r18Q1mSP9N]

完全重写吧

[janus77]

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

[Charod]

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

[hai046]

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

[adminharlem]

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

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

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

[darkengine]

@adminharlem AI 大哥求放过

[darkengine]

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

[fkthiswordw]

开倒车啊

[okakuyang]

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

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

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

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

[darkengine]

@fkthiswordw 此话怎讲？

[darkengine]

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

[GreatAuk]

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

[Bijiabo]

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

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

[darkengine]

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

[musi]

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

[cnhongwei]

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

[cairnechen]

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

[okakuyang]

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

[Ashore]

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