这是一个创建于 797 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题，重构 App 可选的方案太多了，不知道如何下手。 Jetpack MVVM ？ Compose ？ Kotlin flow ？ 准备选一个当前最流行的架构，大佬们有没有模板项目推荐的？
第 1 条附言 · 2022-02-11 15:28:37 +08:00
附：RN在我们项目中存在一些没法避免的缺陷，所以直接上原生会是一个更好的方案，这个内部已经决定好了
第 2 条附言 · 2022-02-11 17:16:20 +08:00
大家不要走偏了哈🤣我只需要一个当前最流行的原生 Android 技术栈，因为快两年没有写原生了，感觉自己的技术栈有些滞后，所以来请教大家一下。不过看到大家这么多推荐跨平台框架的，我在怀疑是不是自己走偏了……
 |
1
815979670 2022-02-11 12:24:34 +08:00
不是应该看你们公司员工技术栈吗
|
 |
2
silencelixing OP  1
@815979670 #1 我们公司之前是 RN 开发，技术栈基本算是完全不相关，反正都是重新来，不如选一个主流的技术栈从头开始学习
|
 |
3
lxiian 2022-02-11 12:49:57 +08:00 via iPhone
同求一个方案
|
 |
4
redtech 2022-02-11 12:52:22 +08:00
有跨端需求 问就是 flutter
|
 |
5
ByePrd 2022-02-11 12:54:49 +08:00 2
架构选择 Jetpack MVVM 吧，配合 Jetpack 的其他库及 Kotlin coroutine 和 flow （替代 RxJava ）。
现在也有一个 MVI 的架构。Compose 有待考验，不推荐使用在生产环境中，部分模块用它尝鲜还行。 |
 |
6
thtznet 2022-02-11 13:12:02 +08:00
MAUI 了解一下，还未发布正式版，应该是属于未来的"架构"，不关注一下么？
|
 |
7
ren2881971 2022-02-11 13:17:29 +08:00
公司项目重构还是应该侧重于员工能够 hold 的技术吧，一味的追求新技术带来的风险你们部门能承受得住么。
|
 |
8
Chism 2022-02-11 13:40:35 +08:00
最流行不就是 uniapp 吗
|
 |
9
z42514 2022-02-11 13:41:17 +08:00 1
有 java 、kotlin 基础么，有的话就用 Google 的架构方案吧，最近刚刚又更新了一版。
我 21 年底刚尝试用 MVVM kotlin flow 新开发了两个项目，如果有 java 和 kotlin 基础的话，迁移难度不大 |
 |
11
RickyC 2022-02-11 13:45:58 +08:00
react native
|
 |
12
i979491586 2022-02-11 13:53:14 +08:00
2022 年 有跨端需求 问就是 flutter
|
 |
13
imtianx 2022-02-11 13:54:57 +08:00
compose 写起来很不错，但是觉得如果用了 compose ，还不如直接上 flutter
|
 |
14
masterclock 2022-02-11 13:55:32 +08:00
react native -> flutter
|
 |
15
haaro 2022-02-11 14:03:46 +08:00
现在官方已经再推 MVI 了
|
 |
16
KuroNekoFan 2022-02-11 14:07:57 +08:00
比较感兴趣你们在 rn 上遇到什么问题
|
 |
17
jingslunt 2022-02-11 14:20:46 +08:00 1
wasm
|
 |
18
beisilu 2022-02-11 14:30:57 +08:00
flutter 是真的香
|
 |
19
weithl 2022-02-11 14:32:22 +08:00
看业务复杂度吧 复杂点就 rx + mvvm 两端都如此。业务简单就无所谓了 基础组件 模块拆分做好就行
|
 |
20
66beta 2022-02-11 14:35:00 +08:00
为什么不是团队坐下来一起讨论一下？
|
|
21
silencelixing OP @KuroNekoFan #16 遇到的问题刚刚贴在附言里了
|
|
22
silencelixing OP @ren2881971 #7 哈哈没有追求新技术，只是需要一个主流的技术方案，稳定没 Bug 能上手就行
|
|
23
silencelixing OP @imtianx #13 其实界面没有很炫酷，就是 native 相关的功能太多，上 flutter 我觉得应该和 RN 没有很大区别，那样就没有重构的必要了
|
 |
24
Helsing 2022-02-11 15:35:54 +08:00 via iPhone
MVVM + Clean
|
|
25
silencelixing OP @Chism #8 uniapp 之前有写过，性能还不如 RN ，更像是一个 webview 的操作体验，这次其实跨平台的技术方案都不考虑了。
|
 |
26
fyooo 2022-02-11 16:18:53 +08:00
谢谢楼主分享，附录的都是干货啊，哈哈，外网介绍 RN 的文章都是千篇一律的夸，很少遇到这么高密度的实战经验干货
|
|
27
KuroNekoFan 2022-02-11 16:24:13 +08:00
附录很赞😄
|
 |
28
iovekkk 2022-02-11 16:28:01 +08:00
去年花了老大力气把组里的几个项目都从 mvp 转成了 mvvm
看来今年又得转 mvi |
 |
29
loginbygoogle 2022-02-11 16:33:03 +08:00
原生开发直接 Jectpack Compose/SwiftUI
|
 |
30
aabbcc112233 2022-02-11 16:35:02 +08:00
一年多没写安卓, 已经不懂什么 mvi jetpack compose 了......真的学不完, 还是写 flutter 舒服
|
|
31
loginbygoogle 2022-02-11 16:38:23 +08:00
现在 Flutter 在 Android 端的性能已经可以媲美原生了，但在 iOS 上还需要继续优化
|
|
32
imtianx 2022-02-11 16:46:24 +08:00
@silencelixing 那还是老老实实用原生写，现在原生写着也很舒服
|
 |
33
z1113456051 2022-02-11 17:03:54 +08:00
根据我的经验，没事别乱动，不动就不会有问题。
|
 |
34
ykrank 2022-02-11 17:05:04 +08:00
重 native 特化逻辑的 app ，一开始选择跨端方案就是个错误。跨端的目的都是抹平各端，意味着是一个各端交集，注定只能自己实现各端的特化特性。主要适合重 UI 和业务逻辑的 app
|
 |
35
whyrookie 2022-02-11 17:10:10 +08:00
这个附录确实很赞
|
 |
36
iweus 2022-02-11 17:10:29 +08:00
公司项目还是原生开发吧，MVC 能满足大部分需求，别整那些虚的，维护起来还麻烦，稳定为主
|
 |
37
SmiteChow 2022-02-11 17:13:13 +08:00
这怕是重写不是重构
|
 |
38
xieren58 2022-02-11 17:25:27 +08:00
Jectpack Compose
|
 |
39
CommandZi 2022-02-11 17:30:09 +08:00 6
求不要用 Flutter 祸害 iOS 的体验。
闲鱼、懂车帝在 iOS 端都是屎一般的体验。 |
 |
40
Bijiabo 2022-02-11 18:10:14 +08:00 18
我现在依然使用 RN 方案来做公司主要业务开发，也服务过一些中小客户（项目金额大概 10-100W 之间）。针对楼主附言提到的问题，我认为大部分都是不是 RN 自身的问题，是团队的开发方式需要优化，不应该把锅甩给框架。
我一条条列一下我的观点： 1. 百度移动统计每次都需要手动埋点，无法实现自动埋点 自己的 RN 业务一般要自行封装导航路由和公共组件，完全可以实现自动埋点，梳理一下内部规范即可。我们现在用 AppCenter 来做的，相比原生差不了多少。 2. 很多三方的 SDK 都只有原生端接入，没有 RN 接入方式，需要自己封装一层 native 接口供 JS 调用 分开说： - Native Module 一般工作量不大，主要接口调用，一次性工作。 - Native UI Component 相对复杂一些，最好 Native UI 封装完再套一层 React Native Component 封装，但对于整体工作量来说，比两端纯 Native 开发还是会小不少的（大部分场景） 3. 很多参数，例如：设置页面参数，通道参数，都是写在 RN 层，与原生层交互需要多一层逻辑 多的这层逻辑指的是 Native Module 封装，实际会影响性能和体验么？这样业务层 Android 、iOS 只写一遍岂不是更好？ 4. RN 写的界面，没办法实现复杂的手势操作逻辑，例如：坐标定位不方便，无法解决兼容性问题。还有 手势传递、冲突等一系列问题也没有很好的解決方案。 这确实是个问题，对于高要求的复杂手势和动画来说有一些实现难度，可能封装 Native UI 会更好。对于一般手势交互效果，基本 react-native-gesture-handler + animated2 都能应对。 5. RN 本身也是一个框架，存在很多 Bug ，用原生写则不会有这些 Bug 。每次升级 RN 的版本都会是一个 大动作，不敢轻易升级，因为每次升级都会出现新问题，现在 RN 仍然有几百个 Bug 没有解决。 0.60+ 之后比较稳定了，目前没有遇到特别卡壳的问题 6. 一些界面没办法用 RN 实现，或者说在 RN 上找不到实现方案，例如 Android 的悬浮窗，ios 的画中画 功能。 这部分通过封装 Native Module 模块来解决就可以，一般都是特殊场景，特殊处理 7. RN 的性能、体积问题。性能问题：FlastList 列表渲染在有大量数据刷新，或者有复杂的列表功能时， 渲染卡顿，发热，用原生的 RecycleView 则不会有这些问题。RN 的 apk 包会比原生的大。RN 多了一 层 JS 与 Native 之间的一层 Bridge ，这层桥接也会影响性能。 我们有在业务场景中遇到过列表显示大量监控数据时的卡顿问题，换原生 TableView/RecycleView 也卡，主要还是数据处理上下功夫，通过优化渲染逻辑的方式可以解决。对于 RN 多的 Bridge ，新的版本有 JSI ，性能提升还是很显著的。 8. 三方支持库不如原生的多，＃且基本上不怎么维护了，质量参差不齐，不少需求都需要自己造轮子 我认为原生库的封装成本不高，我们之前的业务就是从原生切到 RN 的，总体开发成本下降非常多，周期和质量都有显著提升。 9. 国际化问题：如果一些界面是原生写的，这些界面也需要国际化文本，那么文案要么在 native 做一套单 独的，这样就需要维护 json 和 xml 两套文本了，要么就需要从 RN 层传到 native 来显示。 这个可以同一套...写个脚本 XML 转 JSON ？ 10. 测试同时没办法写自动化测试，因为 RN 界面的元素、控件，全部没有 ID ，无法定位。 我们有些 RN 业务界面室友做自动化测试覆盖的，可以使用 Detox 。对于 ID ，我想你说的是 testID ，在 0.5x 的版本中确实有一定问题，对于现在 0.60+ 来说，可以直接添加 testID 属性，文档地址： https://reactnative.dev/docs/view#testid 11. 和 native 强相关的功能，基本起不到什么作用：例如 IM 、OTA 升级，各种 so 库、蓝牙、SPP 通信。 没做过 IM 的业务，我知道极光有 RN IM SDK 。对于 OTA 升级、蓝牙通信，使用 RN 开发应用在业界是非常普遍的，比如小米的米家、涂鸦智能的涂鸦 app ，他们做物联网业务的必备功能。我这里自己接了几个出海项目，也有包涵这些特性，出货都没什么问题。RN 解决的是跨端界面的交互开发，就算用其他跨端方案，也是需要 Native 接口的封装。 |
 |
42
cora1n 2022-02-11 18:21:27 +08:00 3
可以参看下官方的 MAD 相关文章，我最近刚用 MAD 重写了一个老旧的 Android 项目，用到了以下技术栈，感觉蛮好的，有兴趣可以加 vx 讨论下，VzY2MTc5OTI=。
1. Lang: Kotlin 2. UI: JetPack Compose 3. DI: Hilt 4. Arch: MVI + Domain 5. Async: Coroutine + Flow |
|
43
silencelixing OP 2
@Bijiabo #40 一看就是专业 RN 开发了，说的很到位。我谈到的一些问题确实也可以找到解决方案，不过寻找解决方案也需要成本。之前选择 RN 作为技术方案是历史遗留问题，这次因为要重写 App ，布局交互全部是崭新的一套，考虑到项目的 native 功能较多，扩展性和人员的专业性，可以重新选择技术方案的情况下，我们才决定用原生。
|
 |
44
Hanggi 2022-02-11 18:41:26 +08:00 2
@CommandZi
闲鱼垃圾跟 Flutter 有什么关系？ 你访问了一个 java 写的网站很卡你是不是要说 java 垃圾？ 你街上看到一个人在你面前吐痰是不是要说天朝人垃圾？ 你要说屎得说到点上，拿几个垃圾 App 举例明显没啥说服力。 |
 |
45
mxT52CRuqR6o5 2022-02-11 20:06:48 +08:00 2
我看了看楼主罗列的 RN 开发遇到这些问题，all in native 这个决策没什么问题的，不过罗列的有些理由其实 RN 是有好的解决方案的
RN 手势的话有 react-native-reanimated 和 react-native-gesture-handler 可以弥补原生提供的手势&动画能力不足的问题，开发出原生性能的手势&动画，不过抽象的比较蛋疼，复杂的效果写起来相当耗费心智，建议有复杂手势&动画需求还是用 RN 以外的方案 体积的问题据说当界面多到一定程度，RN 对体积是有正收益，不过我也没什么具体概念 说 RN 元素控件没有 id 是不对的，RN 的原生控件每一个都有 testID 属性，就是专门供测试使用的 像 RN 、Flutter 这种跨端框架要么就 all in （没提供的 native 能力就封装好，不要混用），要么就不要用，native 和跨端框架共存开发起来是很痛苦的 |
 |
46
BigDogWang 2022-02-11 20:10:13 +08:00
@Hanggi 不过 flutter 在 iOS 上的体验确实有点糟糕。我就是 flutter 开发者。UI 上很多细节跟原生差很多。不过能用就是了
|
 |
48
MakHoCheung 2022-02-11 20:50:39 +08:00
根据原生遇到的坑肯定比跨端的少，Jectpack Compose/SwiftUI 加起来的开发效率应该跟 Flutter 差不多？
|
 |
49
toacnme 2022-02-12 00:45:00 +08:00 1
@Bijiabo 说的都在点上，随便再插一句，上面说的缺陷现在已经解决了很多，很多都不是问题。
比如，第四点手势和动画这方面，现在使用 react-native-gesture-handler + react-native-reanimated 基本可以完全可以解决。第七点长列表的话，也有个 recyclerlistview 的 js 实现，https://github.com/Flipkart/recyclerlistview ，实测性能还是不错的。 涉及与原生端通信的话，在 RN Fabric 新架构之后，已经很少有和宿主平台进行 JSON 序列化的通信了，都是用 JSI 直接获取，而且如果你们团队有会 C++ 的话，那就再合适不过了，直接用 JSI 和 C++ 通信，速度真的不比原生差很多，具体可以体验一下 https://github.com/mrousavy/react-native-vision-camera 这个库，你会满意的。 |
|
50
toacnme 2022-02-12 00:51:59 +08:00
@CommandZi 每次用 iOS 打开 Flutter 的软件，分分钟想关掉，到现在应该不支持高刷，ScrollView 的 bounce 效果感觉每个 App 体验都不一样。
闲鱼现在正在用原生改以前 Flutter 留下的坑，吹 Flutter 的还是不少。 |
|
51
Hanggi 2022-02-12 01:34:39 +08:00
@CommandZi
不是举例的问题，你就算用过 100 个 Flutter 做的 App 都很屎，也无法得出 Flutter 垃圾的结论。 你可以说你用 Flutter 做的 App 遇到过哪些问题，让你的体验不太好。 而且 Flutter 生成的就是原生 App ，体验不好大概率还是开发问题。 虽然 github star 数不是绝对的，但是 13 万 star 说明他还是收到人很多人的认可。 就像很多人骂 Vue 抄袭，但是 10 几万 star 也能说明，他确实对很多人受用。 |
 |
52
wobuhuicode 2022-02-12 02:02:11 +08:00
跨端框架无非就两个用处：KPI 和外包。
|
|
53
Bijiabo 2022-02-12 02:21:17 +08:00 via Android
@Hanggi Flutter 是基于 Skia 绘制，控件不是使用的原生控件。我作为一个用户的感觉，Flutter 的 ScrollView 的惯性和 bounce 效果令我感到不舒适，与系统体验不一致，非常明显。
|
 |
54
zpf124 2022-02-12 11:10:04 +08:00 1
看到最后一条楼主的附言我说一句，不是楼主走偏了，而且强 native 功能依赖的如今属于小众需求了。
而互联网范围内 app 的功能大多只需要替代网页访问就好。使用不到太多的 native 功能。包括外国的 fb 、twitter 、也一样，大多数 app 都是内容展示类的，他们需要的 native 功能主要就是摄像头和定位。 比如我曾经接触的一个组，他们是给学校卖物联网教学方案的，定制开发板镶嵌一个屏，装了安卓系统，但应用实际全是 c++写的。界面都是 qt 。因为他们天天搞的熟悉的就是那些，并且还会有一些红外烟感光感之类的非手机硬件设备需要写代码调用。 |
|
55
zpf124 2022-02-12 11:10:45 +08:00
而且强 native -> 而是强 native
|
 |
56
moshou 2022-02-12 13:07:06 +08:00
我觉得 Flutter 好一些，用了 1 年多，开发成本低很多，效率也不错，bug 也少。
看到楼上有反驳说 Flutter 体验不好的，这个还是看你侧重点了。 我看举的例子是闲鱼和懂车帝不行，但 App 下载量 /注册量的增加和减少，是因为用了 Flutter 吗。 |
 |
57
matatabi 2022-02-12 14:20:12 +08:00
首先排除 rn ，跨端首选 flutter ，没有跨端需求上原生
|
 |
58
bclerdx 2022-02-12 14:55:20 +08:00
用原生开发吧。
|
 |
59
SmaliYu 2022-02-12 15:16:00 +08:00
回到原来的问题上，这两年 Android 框架流行的也就两三种吧，公司的项目还在用 MVP ，其他人 MVVM 带或不带 databinding 都有用，个人项目 MVC 也没啥问题。kt 和 compose 目前依然不是主流，虽然个人用起来很爽，但不建议带到公司项目里。总而言之降低项目学习和维护成本，便于调试，少给自己找事儿才是正解。
|
 |
60
KainyGuo 2022-02-12 23:51:07 +08:00
具体还是看业务场景吧。。
|
 |
61
bleaker 2022-02-13 10:30:03 +08:00 via iPhone
Flutter 和 RN 的思路是恶心用户但是满足开发者，十年前这都是和主流价值观相悖的，现在成了标配，也算是德匹下了
|
 |
62
ychost 2022-02-13 11:39:08 +08:00
人力够建议直接原生，或者原生+小程序 /H5 的混合开发
|
 |
63
2NUT 2022-02-27 23:50:01 +08:00
你们原先的 跨端方案 遇到了什么 技术问题? 性能?
|
 |
65
yilindoudou 2022-04-25 16:32:20 +08:00
@loginbygoogle compose 能直接上生产 app 么? 目前小团队, 就我一个人, 一直在纠结用 compose 还是 xml
|
|
66
silencelixing OP @reply all. 谢谢大家的评论，回复所有人：
目前我们公司的重构框架已经搭建完成了，结合了目前公司人员的技术掌握程度，未来发展趋势，框架稳定性，以及市面上的开发人员技术掌握情况等等因素，综合考虑，最终选定了如下技术架构： 语言：Kotlin 架构：MVVM （ JetPack 全套）+ 组件化（ Arouter 通信，模块接口下沉） 界面：主布局采用 ViewBinding+xml ，简单静态界面使用 JetPack Compose 依赖注入：JetPack Hilt 异步数据流：Kotlin 协程+Jetpack LiveData 再次感谢大家！！比心❤️ |
Select Language