如题,维护两套原生代码实在太累。
对于从原生迁移到 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 324 天前
@darkengine hello,大佬,我们项目目前也遇见了这个问题,能方便交流下吗,你们最终采用的啥方案呀
|
53
darkengine OP @gogolts 主项目还是选择用原生重写了,去年年底新开的小项目选择了 flutter ,目前第一版正在收尾阶段,如果团队里有会 flutter 的开发可以考虑用,不然应该快不了多少。
|
54
gogolts 322 天前
@darkengine 看大哥之前的描述你们之前不就是原生嘛,然后又用原生再重写。是因为迁移到 RN 的途中遇见了啥问题吗?我目前也只看见了官方文档给了个整合原生的文档: https://reactnative.dev/docs/integration-with-existing-apps?language=java
|