这是一个创建于 727 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题，维护两套原生代码实在太累。
对于从原生迁移到 RN ，大佬们有最佳实践可以分享吗？
混编还是完全重写？
 |
1
NonClockworkChen 2022-12-05 10:22:07 +08:00
如果你的项目涉及很多原生模块，相机、视频播放，且要定制化。 那么跨平台并没有解决问题。
再招个人维护原生，才是最优解。 其次是离职。 |
 |
2
C603H6r18Q1mSP9N 2022-12-05 10:22:31 +08:00
完全重写吧
|
 |
3
janus77 2022-12-05 10:24:35 +08:00
怎么混编啊，你现在不是已经 2 个项目了吗，混编还要分平台考虑编译配置和集成之类的东西，肯定是起干净项目啊
|
 |
4
Charod 2022-12-05 10:50:21 +08:00
你原生迁移 RN, 你 RN 一样要维护两套，虽然不想原生差异化大，但多多少少有差异，再招个人维护吧，实在不行，跑路吧
|
 |
5
hai046 2022-12-05 10:58:39 +08:00
原生先为主，一步一步的迁移，迁移后的用 RN ，没迁用原生， 逐步用 RN 替代 原生。
另外话说你怎么不用 flutter ？比 RN 好多了 |
 |
6
adminharlem 2022-12-05 11:03:30 +08:00
对于从原生迁移到 RN ，大多数开发者通常都会选择混编的方式。混编意味着将原生代码和 RN 代码混合在一起，形成一个统一的应用。这样做的好处是可以更好地利用原生代码的优势，同时也能够更快速地完成迁移。
相比之下，完全重写意味着将原有的应用完全用 RN 代码来重新实现。这样做的好处是可以更好地利用 RN 的优势，并且可以统一应用的技术栈。但是，完全重写的过程通常比较耗时，并且还可能会导致一些潜在的问题。 对于从原生迁移到 RN ，不同的项目会有不同的最佳实践。如果您想要了解更多信息，可以咨询更多的专家或查阅相关文献，以便找到适合您项目的最佳方案。 |
 |
7
darkengine OP @adminharlem AI 大哥求放过
|
|
8
darkengine OP @hai046 一个是我们依赖的第三方 SDK 有些没有 flutter 的，第二个是人不好招，内部转化需要的时间长。
|
 |
9
fkthiswordw 2022-12-05 12:25:38 +08:00 via iPhone
开倒车啊
|
 |
10
okakuyang 2022-12-05 12:35:13 +08:00  1
React Native 你如果只是部分迁移，一部分页面用 RN ，大部分用原生。实际上操作可能需要你建两个工程的。
正常 RN 开发你可能也需要两个工程。简单的说就是两边依赖的版本可能不一样，安卓可能某个依赖能工作，但是 iOS 那边不行，你得切换版本。如果你不想切换的时候重新 yarn 安装依赖。你可能需要建两个工程。 就算你在一个工程里做双端的，你也是 xxx.android.js xxx.ios.js 这种分开处理的时候会比较多。两边好处是逻辑代码大部分一样，但是具体代码还是要分开来修改的。 但是相比原生的每次修改都需要编译才能看效果，RN 的动态预览将效率提升了太多。而且因为你用的是 js ，不用每次都编译，电脑也会凉快不少。如果是 iOS 那种预览，电脑得卡的要死，而且超过一定的代码量，就不给你预览了。 如果你决定了用 RN ，千万不要马上使用 RN 的“新架构”，现在坑还很多。 |
|
11
darkengine OP @fkthiswordw 此话怎讲？
|
|
12
darkengine OP @okakuyang 多谢解答，RN 的“新架构” -- 指的是 0.7x 版本的 RN 吗？
|
 |
13
GreatAuk 2022-12-05 13:25:55 +08:00
可以在原生应用里集成 RN, 然后慢慢一个页面一个页面的迁移，如果有的功能通过 RN 实现太复杂或实现不了，可以直接在原生项目实现。
|
 |
14
Bijiabo 2022-12-05 13:37:58 +08:00
笑死我了，都 2022 年年末了还有人推荐 Flutter ，嫌凉的不够快啊...
建议先尝试迁移一部分功能试一下，混编靠谱一些，直接上来重写可能会走一些弯路。很多已有的逻辑和组件可以简单封装一层复用的。 |
|
15
darkengine OP |
 |
17
cnhongwei 2022-12-05 14:36:56 +08:00
这个都看你们的页面量，和对 RN 的熟悉情况。如果技术熟悉，页面不多的话，直接完全重写。否则，还是混编比较好。
|
 |
18
cairnechen 2022-12-05 14:40:30 +08:00
@Bijiabo Flutter 咋了，不是用的人越来越多了吗？
|
|
19
okakuyang 2022-12-05 14:51:26 +08:00
@darkengine 对。0.7 之后模版默认开启新架构，但是你可以不用 turbo native modules 和 fabric 相关的功能就行。用了之后一些第三方库还没适配会出错，浪费时间。
|
 |
20
Ashore 2022-12-05 14:56:01 +08:00
插个题外话，这里面有 AI?
|
|
21
darkengine OP @Ashore 我觉得 adminharlem 是
|
|
22
darkengine OP @okakuyang 怪不得了！我照着 RN 官方的“Integration with Existing Apps”操作，都需要一步一 stackoverflow 😭
|
|
23
GreatAuk 2022-12-05 15:26:11 +08:00
@Bijiabo 感觉现在 flutter 应该是比 RN 火的，RN 现在处于不温不火的状态。不过我还是选 RN, 因为我只会前端...
|
 |
25
christin 2022-12-05 15:52:02 +08:00
rn 装环境装两三天还装不上，flutter2.30 分钟就行了。
|
 |
26
dazuijuren004 2022-12-05 15:54:59 +08:00
@Bijiabo 首先表态 完全没有任何抵抗心态，单纯发问。
为什么说 flutter 要凉？我司现在 app 的主要开发语言就是 flutter |
 |
28
liuzhedash 2022-12-05 17:00:18 +08:00
原生到 RN 其实必然要重写啊，如果原生代码现在没有严重的问题，完全没必要迁移到 RN ，而是应该把部分页面用 RN 来实现。
https://reactnative.dev/docs/integration-with-existing-apps |
 |
29
deng81416754 2022-12-05 17:25:12 +08:00
RN 在低端鸡上，性能不太行
|
 |
30
xiaoshan5733 2022-12-05 18:08:05 +08:00 via iPhone
可以尝试下 expo ，跨端开发成本很低
|
 |
31
palxie 2022-12-05 18:12:52 +08:00
必然重写啊
|
 |
32
yikyo 2022-12-05 18:54:18 +08:00 via iPhone
提个建议，新功能可以尝试 rn 开发，评估收益，成本，风险
再决定下一步怎么走，如果完全走 rn ，也需要客户端开发人员，提供基础 api 给 Rn |
 |
33
ragnaroks 2022-12-05 20:40:26 +08:00
说实话 react-native 不太行，倒不如学淘宝那样直接 webview
|
 |
34
cktsun 2022-12-05 21:02:50 +08:00 via Android
Discord 就是這樣啊
原生轉 rn |
 |
35
wingkwanli888 2022-12-05 22:49:42 +08:00
@ragnaroks webview 現在不是不給上架？
|
 |
36
smallthing 2022-12-06 00:04:51 +08:00
@dazuijuren004 flutter 都城开发语言了？
|
 |
37
hyyou2010 2022-12-06 00:33:28 +08:00
我觉得这只能是最后的选择。我会优先考虑把两端相同的东西往服务器那边挪，再添加一些 Web 页面来实现共用。
就怕你费劲半天，省了一些工作，但又多出一些活，不值得。除非从零开始，否则我会怕麻烦。 |
 |
38
wobuhuicode 2022-12-06 00:33:39 +08:00
UI 肯定是重写的了，本来两套都是原生 UI 没法复用，虽然说部分可以做成 RN 的 native 组件，但是后续维护还是两套。还不如直接 UI 重写。
|
 |
39
Manweill 2022-12-06 08:31:24 +08:00
只要不是超高性能要求的应用我觉得 RN 都还是没问题的，RN 在大部分原生模块上都没什么问题，都有很好用的开源模块，包括相机，多媒体，蓝牙，NFC ，AI 等等等等。当然 RN 需要有人对 React 的开发把关，他不像 vue 一样那么好上手。
|
|
40
darkengine OP @Manweill 我们有两个 ReactJS 研发，比较担心的原有原生代码集成了很多第三方 SDK 例如 firebase, Square/Stripe 这种，怕在 RN 上有坑。性能倒不是主要的考量。
|
 |
41
9ki 2022-12-06 09:26:57 +08:00
@darkengine 我在用 firebase sdk, 用 RN 集成还是挺方便的, 不过 firebase 本身挺多坑, 你们应该遇到过.
|
|
42
Manweill 2022-12-06 09:58:25 +08:00
@darkengine firebase sdk 有官方支持的。而且很活跃 。stripe 没用过，不发表。不过个人角色海外大厂一般都有提供官方的 RN 组件，不想国内的 BAT...
|
|
43
darkengine OP @Manweill 调研了 Stripe/Square 的 RN 库，是第三方封装的，基本落后原生库几个小版本。
|
|
44
hai046 2022-12-06 10:08:55 +08:00
@Bijiabo ???怎么凉的快，3.x 我们用的挺好的啊，做海外社交游戏分发平台，6 个人做双端轻松的很，很多插件都已经很完善了，比以前好用多了，效率高，速度快。 最近我们上了一个国外的，提审还有什么的不要太好。
flutter 做海外生态真的不错。 |
|
45
hai046 2022-12-06 10:12:38 +08:00
RN 我们 19 年时候搞过一个 B 端的，现在还在用，主要用他的热更。不过效率不咋的
现在有的项目用原生，拿出来一个项目团队用 flutter ，查发比 RN 好多了，原生同学在人带的情况下，2 天内就开始开发熟悉，只要不是太笨，1 周绝对能学成 [应该会更快] ，可以试一下了解一下。特别是 dart 语言在 app 移动开发真的特别适合，就是 ui 控件名字记不住其他的都很好。 |
|
46
Manweill 2022-12-06 10:33:40 +08:00
@darkengine 落后几个小版本，那应该问题不大？三方的话，难免作者会弃更或者 SDK 版本落后，到时候只能自己改。例如 aliyun 推送的 sdk ，我们就是自己包的。这些只是调用 SDK 的包装还是比较简单的。
|
 |
47
DingJZ 2022-12-06 11:05:38 +08:00
看业务，我这几个 app ，第一年把壳子封装完之后基本上一年能更新一次 native ，所以对原生没有需求，招人只招前端
|
 |
48
yuxizhe 2022-12-06 23:25:24 +08:00
RN 只负责做 UI 部分，客户端内的固定底层的功能和模块可封装成原生 RN 组件，RN 简单调用即可。后续用 RN 还可以同构 H5 和小程序。
|
|
50
hai046 2023-01-06 18:01:45 +08:00
@checkz 因为我们嵌入 unity 游戏，unity 组目前没适配 iOS ，苹果这个预计年后才开始上，后面我们上线了在回复你，不过 android 10 个月我们还是很不错的
|
 |
51
nobodyknows 2023-01-16 14:53:41 +08:00
然后发现要维护三套代码
|
 |
52
gogolts 312 天前
@darkengine hello,大佬，我们项目目前也遇见了这个问题，能方便交流下吗，你们最终采用的啥方案呀
|
|
53
darkengine OP @gogolts 主项目还是选择用原生重写了，去年年底新开的小项目选择了 flutter ，目前第一版正在收尾阶段，如果团队里有会 flutter 的开发可以考虑用，不然应该快不了多少。
|
|
54
gogolts 310 天前
@darkengine 看大哥之前的描述你们之前不就是原生嘛，然后又用原生再重写。是因为迁移到 RN 的途中遇见了啥问题吗？我目前也只看见了官方文档给了个整合原生的文档： https://reactnative.dev/docs/integration-with-existing-apps?language=java
|
Select Language