V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
silencelixing
V2EX  ›  Android

公司准备重构 App,请问一下现在最流行的架构是什么?

  •  2
     
  •   silencelixing · 236 天前 · 10370 次点击
    这是一个创建于 236 天前的主题,其中的信息可能已经有所发展或是发生改变。

    如题,重构 App 可选的方案太多了,不知道如何下手。 Jetpack MVVM ? Compose ? Kotlin flow ? 准备选一个当前最流行的架构,大佬们有没有模板项目推荐的?

    第 1 条附言  ·  236 天前

    附:RN在我们项目中存在一些没法避免的缺陷,所以直接上原生会是一个更好的方案,这个内部已经决定好了 RUNOOB 图标

    第 2 条附言  ·  236 天前
    大家不要走偏了哈🤣我只需要一个当前最流行的原生 Android 技术栈,因为快两年没有写原生了,感觉自己的技术栈有些滞后,所以来请教大家一下。不过看到大家这么多推荐跨平台框架的,我在怀疑是不是自己走偏了……
    67 条回复    2022-05-15 10:42:43 +08:00
    815979670
        1
    815979670  
       236 天前
    不是应该看你们公司员工技术栈吗
    silencelixing
        2
    silencelixing  
    OP
       236 天前   ❤️ 1
    @815979670 #1 我们公司之前是 RN 开发,技术栈基本算是完全不相关,反正都是重新来,不如选一个主流的技术栈从头开始学习
    lxiian
        3
    lxiian  
       236 天前 via iPhone
    同求一个方案
    redtech
        4
    redtech  
       236 天前
    有跨端需求 问就是 flutter
    ByePrd
        5
    ByePrd  
       236 天前   ❤️ 2
    架构选择 Jetpack MVVM 吧,配合 Jetpack 的其他库及 Kotlin coroutine 和 flow (替代 RxJava )。

    现在也有一个 MVI 的架构。Compose 有待考验,不推荐使用在生产环境中,部分模块用它尝鲜还行。
    thtznet
        6
    thtznet  
       236 天前
    MAUI 了解一下,还未发布正式版,应该是属于未来的"架构",不关注一下么?
    ren2881971
        7
    ren2881971  
       236 天前
    公司项目重构还是应该侧重于员工能够 hold 的技术吧,一味的追求新技术带来的风险你们部门能承受得住么。
    Chism
        8
    Chism  
       236 天前
    最流行不就是 uniapp 吗
    z42514
        9
    z42514  
       236 天前   ❤️ 1
    有 java 、kotlin 基础么,有的话就用 Google 的架构方案吧,最近刚刚又更新了一版。

    我 21 年底刚尝试用 MVVM kotlin flow 新开发了两个项目,如果有 java 和 kotlin 基础的话,迁移难度不大
    z42514
        10
    z42514  
       236 天前
    @z42514 #9 kotlin 协程那一套真的很香,已经放弃 rxjava 了
    RickyC
        11
    RickyC  
       236 天前
    react native
    i979491586
        12
    i979491586  
       236 天前
    2022 年 有跨端需求 问就是 flutter
    imtianx
        13
    imtianx  
       236 天前
    compose 写起来很不错,但是觉得如果用了 compose ,还不如直接上 flutter
    masterclock
        14
    masterclock  
       236 天前
    react native -> flutter
    haaro
        15
    haaro  
       236 天前
    现在官方已经再推 MVI 了
    KuroNekoFan
        16
    KuroNekoFan  
       236 天前
    比较感兴趣你们在 rn 上遇到什么问题
    jingslunt
        17
    jingslunt  
       236 天前   ❤️ 1
    wasm
    beisilu
        18
    beisilu  
       236 天前
    flutter 是真的香
    weithl
        19
    weithl  
       236 天前
    看业务复杂度吧 复杂点就 rx + mvvm 两端都如此。业务简单就无所谓了 基础组件 模块拆分做好就行
    66beta
        20
    66beta  
       236 天前
    为什么不是团队坐下来一起讨论一下?
    silencelixing
        21
    silencelixing  
    OP
       236 天前
    @KuroNekoFan #16 遇到的问题刚刚贴在附言里了
    silencelixing
        22
    silencelixing  
    OP
       236 天前
    @ren2881971 #7 哈哈没有追求新技术,只是需要一个主流的技术方案,稳定没 Bug 能上手就行
    silencelixing
        23
    silencelixing  
    OP
       236 天前
    @imtianx #13 其实界面没有很炫酷,就是 native 相关的功能太多,上 flutter 我觉得应该和 RN 没有很大区别,那样就没有重构的必要了
    Helsing
        24
    Helsing  
       236 天前 via iPhone
    MVVM + Clean
    silencelixing
        25
    silencelixing  
    OP
       236 天前
    @Chism #8 uniapp 之前有写过,性能还不如 RN ,更像是一个 webview 的操作体验,这次其实跨平台的技术方案都不考虑了。
    fyooo
        26
    fyooo  
       236 天前
    谢谢楼主分享,附录的都是干货啊,哈哈,外网介绍 RN 的文章都是千篇一律的夸,很少遇到这么高密度的实战经验干货
    KuroNekoFan
        27
    KuroNekoFan  
       236 天前
    附录很赞😄
    iovekkk
        28
    iovekkk  
       236 天前
    去年花了老大力气把组里的几个项目都从 mvp 转成了 mvvm
    看来今年又得转 mvi
    loginbygoogle
        29
    loginbygoogle  
       236 天前
    原生开发直接 Jectpack Compose/SwiftUI
    aabbcc112233
        30
    aabbcc112233  
       236 天前
    一年多没写安卓, 已经不懂什么 mvi jetpack compose 了......真的学不完, 还是写 flutter 舒服
    loginbygoogle
        31
    loginbygoogle  
       236 天前
    现在 Flutter 在 Android 端的性能已经可以媲美原生了,但在 iOS 上还需要继续优化
    imtianx
        32
    imtianx  
       236 天前
    @silencelixing 那还是老老实实用原生写,现在原生写着也很舒服
    z1113456051
        33
    z1113456051  
       236 天前
    根据我的经验,没事别乱动,不动就不会有问题。
    ykrank
        34
    ykrank  
       236 天前
    重 native 特化逻辑的 app ,一开始选择跨端方案就是个错误。跨端的目的都是抹平各端,意味着是一个各端交集,注定只能自己实现各端的特化特性。主要适合重 UI 和业务逻辑的 app
    whyrookie
        35
    whyrookie  
       236 天前
    这个附录确实很赞
    iweus
        36
    iweus  
       236 天前
    公司项目还是原生开发吧,MVC 能满足大部分需求,别整那些虚的,维护起来还麻烦,稳定为主
    SmiteChow
        37
    SmiteChow  
       236 天前
    这怕是重写不是重构
    xieren58
        38
    xieren58  
       236 天前
    Jectpack Compose
    CommandZi
        39
    CommandZi  
       236 天前   ❤️ 6
    求不要用 Flutter 祸害 iOS 的体验。
    闲鱼、懂车帝在 iOS 端都是屎一般的体验。
    Bijiabo
        40
    Bijiabo  
       236 天前   ❤️ 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 接口的封装。
    Bijiabo
        41
    Bijiabo  
       236 天前
    @CommandZi 严重同意,Flutter 就算了吧哈哈哈
    cora1n
        42
    cora1n  
       236 天前   ❤️ 3
    可以参看下官方的 MAD 相关文章,我最近刚用 MAD 重写了一个老旧的 Android 项目,用到了以下技术栈,感觉蛮好的,有兴趣可以加 vx 讨论下,VzY2MTc5OTI=。

    1. Lang: Kotlin
    2. UI: JetPack Compose
    3. DI: Hilt
    4. Arch: MVI + Domain
    5. Async: Coroutine + Flow
    silencelixing
        43
    silencelixing  
    OP
       236 天前   ❤️ 2
    @Bijiabo #40 一看就是专业 RN 开发了,说的很到位。我谈到的一些问题确实也可以找到解决方案,不过寻找解决方案也需要成本。之前选择 RN 作为技术方案是历史遗留问题,这次因为要重写 App ,布局交互全部是崭新的一套,考虑到项目的 native 功能较多,扩展性和人员的专业性,可以重新选择技术方案的情况下,我们才决定用原生。
    Hanggi
        44
    Hanggi  
       236 天前   ❤️ 2
    @CommandZi
    闲鱼垃圾跟 Flutter 有什么关系?
    你访问了一个 java 写的网站很卡你是不是要说 java 垃圾?
    你街上看到一个人在你面前吐痰是不是要说天朝人垃圾?

    你要说屎得说到点上,拿几个垃圾 App 举例明显没啥说服力。
    mxT52CRuqR6o5
        45
    mxT52CRuqR6o5  
       236 天前   ❤️ 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 和跨端框架共存开发起来是很痛苦的
    BigDogWang
        46
    BigDogWang  
       236 天前
    @Hanggi 不过 flutter 在 iOS 上的体验确实有点糟糕。我就是 flutter 开发者。UI 上很多细节跟原生差很多。不过能用就是了
    CommandZi
        47
    CommandZi  
       236 天前
    @Hanggi 能举个用 Flutter 开发的优秀的 iOS App 例子吗?
    MakHoCheung
        48
    MakHoCheung  
       235 天前
    根据原生遇到的坑肯定比跨端的少,Jectpack Compose/SwiftUI 加起来的开发效率应该跟 Flutter 差不多?
    toacnme
        49
    toacnme  
       235 天前   ❤️ 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 这个库,你会满意的。
    toacnme
        50
    toacnme  
       235 天前
    @CommandZi 每次用 iOS 打开 Flutter 的软件,分分钟想关掉,到现在应该不支持高刷,ScrollView 的 bounce 效果感觉每个 App 体验都不一样。
    闲鱼现在正在用原生改以前 Flutter 留下的坑,吹 Flutter 的还是不少。
    Hanggi
        51
    Hanggi  
       235 天前
    @CommandZi
    不是举例的问题,你就算用过 100 个 Flutter 做的 App 都很屎,也无法得出 Flutter 垃圾的结论。
    你可以说你用 Flutter 做的 App 遇到过哪些问题,让你的体验不太好。
    而且 Flutter 生成的就是原生 App ,体验不好大概率还是开发问题。

    虽然 github star 数不是绝对的,但是 13 万 star 说明他还是收到人很多人的认可。
    就像很多人骂 Vue 抄袭,但是 10 几万 star 也能说明,他确实对很多人受用。
    wobuhuicode
        52
    wobuhuicode  
       235 天前
    跨端框架无非就两个用处:KPI 和外包。
    Bijiabo
        53
    Bijiabo  
       235 天前 via Android
    @Hanggi Flutter 是基于 Skia 绘制,控件不是使用的原生控件。我作为一个用户的感觉,Flutter 的 ScrollView 的惯性和 bounce 效果令我感到不舒适,与系统体验不一致,非常明显。
    zpf124
        54
    zpf124  
       235 天前   ❤️ 1
    看到最后一条楼主的附言我说一句,不是楼主走偏了,而且强 native 功能依赖的如今属于小众需求了。
    而互联网范围内 app 的功能大多只需要替代网页访问就好。使用不到太多的 native 功能。包括外国的 fb 、twitter 、也一样,大多数 app 都是内容展示类的,他们需要的 native 功能主要就是摄像头和定位。

    比如我曾经接触的一个组,他们是给学校卖物联网教学方案的,定制开发板镶嵌一个屏,装了安卓系统,但应用实际全是 c++写的。界面都是 qt 。因为他们天天搞的熟悉的就是那些,并且还会有一些红外烟感光感之类的非手机硬件设备需要写代码调用。
    zpf124
        55
    zpf124  
       235 天前
    而且强 native -> 而是强 native
    moshou
        56
    moshou  
       235 天前
    我觉得 Flutter 好一些,用了 1 年多,开发成本低很多,效率也不错,bug 也少。

    看到楼上有反驳说 Flutter 体验不好的,这个还是看你侧重点了。

    我看举的例子是闲鱼和懂车帝不行,但 App 下载量 /注册量的增加和减少,是因为用了 Flutter 吗。
    matatabi
        57
    matatabi  
       235 天前
    首先排除 rn ,跨端首选 flutter ,没有跨端需求上原生
    bclerdx
        58
    bclerdx  
       235 天前
    用原生开发吧。
    SmaliYu
        59
    SmaliYu  
       235 天前
    回到原来的问题上,这两年 Android 框架流行的也就两三种吧,公司的项目还在用 MVP ,其他人 MVVM 带或不带 databinding 都有用,个人项目 MVC 也没啥问题。kt 和 compose 目前依然不是主流,虽然个人用起来很爽,但不建议带到公司项目里。总而言之降低项目学习和维护成本,便于调试,少给自己找事儿才是正解。
    KainyGuo
        60
    KainyGuo  
       234 天前
    具体还是看业务场景吧。。
    bleaker
        61
    bleaker  
       234 天前 via iPhone
    Flutter 和 RN 的思路是恶心用户但是满足开发者,十年前这都是和主流价值观相悖的,现在成了标配,也算是德匹下了
    ychost
        62
    ychost  
       234 天前
    人力够建议直接原生,或者原生+小程序 /H5 的混合开发
    2NUT
        63
    2NUT  
       219 天前
    你们原先的 跨端方案 遇到了什么 技术问题? 性能?
    2NUT
        64
    2NUT  
       219 天前
    @2NUT #63 刚才图片没加载出来,看到了^
    yilindoudou
        65
    yilindoudou  
       163 天前
    @loginbygoogle compose 能直接上生产 app 么? 目前小团队, 就我一个人, 一直在纠结用 compose 还是 xml
    silencelixing
        66
    silencelixing  
    OP
       162 天前
    @reply all. 谢谢大家的评论,回复所有人:

    目前我们公司的重构框架已经搭建完成了,结合了目前公司人员的技术掌握程度,未来发展趋势,框架稳定性,以及市面上的开发人员技术掌握情况等等因素,综合考虑,最终选定了如下技术架构:

    语言:Kotlin
    架构:MVVM ( JetPack 全套)+ 组件化( Arouter 通信,模块接口下沉)
    界面:主布局采用 ViewBinding+xml ,简单静态界面使用 JetPack Compose
    依赖注入:JetPack Hilt
    异步数据流:Kotlin 协程+Jetpack LiveData

    再次感谢大家!!比心❤️
    IsNotGood
        67
    IsNotGood  
       143 天前 via iPhone
    @cora1n 老哥你是不是在 b 站也发过
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2174 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 55ms · UTC 12:39 · PVG 20:39 · LAX 05:39 · JFK 08:39
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.