前言
（注意，这篇帖子不是软件开发与创新的作业帖。）
前阵子由于PM决策失误，我们项目的前端架构直接推倒重来了。
作为后端，我忍不住骂了这人三千字，不带脏字那种。
素材摆着，今天就讲安卓前端框架，以儆效尤。
一个后端已经被PM的框架选型气得想重新面试了。
PM：“这个框架很火，我们用这个吧。”
后端：“你用过吗？”
PM：“我看别人在用。”
后端：卒。
PM要是瞎选框架，否则推倒重构有你受的。
尤其是前端兼职PM，最好配个架构师顾问，别自己莽。
第一部分：为什么要选框架？（给真·萌新扫盲）
一句话人话版：
框架是你的代码的地基和脚手架。选对了，盖楼又快又稳；选错了，盖到一半发现地基是斜的，只能炸了重盖。
技术人话版：
前端框架是预先封装好的UI组件、状态管理、生命周期、网络请求等能力的集合，决定了项目的开发效率、维护成本和上限。
没有框架的App：
- 每个按钮都要自己写点击监听
- 每个页面切换都要自己管理栈
- 每个网络请求都要自己处理线程
- 你好，1995年的问候
有框架的App：
- 声明式UI，数据变页面自动变
- 组件化复用，一个组件到处用
- 生命周期管理，避免内存泄漏
- 2026年的人类文明
第二部分：安卓前端框架图鉴
Android原生三巨头
| 框架 | 特点 | 适用场景 | 学习曲线 |
|---|---|---|---|
| XML + Java/Kotlin | 传统写法，ViewBinding/DataBinding | 老项目维护、简单页面 | 低 |
| Jetpack Compose | 声明式UI，Kotlin原生，谷歌亲儿子 | 新项目、现代化App | 中 |
| XML + Kotlin + MVVM | 混合模式，大部分项目的现状 | 过渡期项目 | 中 |
跨平台方案（萌新PM最爱乱选的）
| 框架 | 特点 | 适用场景 | 坑位 |
|---|---|---|---|
| React Native | 写JavaScript/TypeScript，渲染原生组件 | 需要快速双端上线、团队有React经验 | 性能、原生模块桥接 |
| Flutter | 写Dart，自绘引擎，也是谷歌亲儿子 | 需要高一致性UI、不在乎包大小 | 包体积大、Dart生态 |
| Uni-app | 写Vue，国内常用 | 小程序为主、顺便做App | 复杂交互支持弱 |
| Ionic/Capacitor | 写Web技术，套WebView | 纯展示类App、企业内部工具 | 性能差、原生能力弱 |
第三部分：框架选型翻车现场（核心吐槽）
操作1：PM拍脑袋：“这个火，用这个”
场景：PM看到网上说Flutter很火，二话不说定了Flutter。团队没人会Dart，现学现卖。
后果：开发效率减半，遇到坑没人能解，上线时间延期两个月。
老鸟内心：你买衣服看别人穿好看就买，回来发现穿不下。怪衣服？怪你自己不看尺码。
操作2：为了“跨平台”牺牲一切
场景：PM觉得“一次编写，处处运行”很美好，选了跨平台方案。结果App需要调用很多原生硬件能力（蓝牙、NFC、摄像头复杂处理）。
后果：跨平台框架的原生桥接写得比原生还复杂，性能还跟不上。简而言之就是：亏本买卖。
老鸟内心：你暑假为了省一张机票钱，选择坐绿皮火车回家。到了是到了，你的屁股得疼死了。
操作3：不看团队技术栈
场景：团队全员Kotlin/Android原生经验，PM非要上React Native。全员转写JavaScript/TypeScript，bug满天飞。
后果：原生的优势没发挥，跨平台的优势也没享受到。
老鸟内心：你让川菜厨师去做寿司。不是做不出来，是味道不对。
操作4：过度追求“最新”
场景：PM觉得“Compose出了，旧的不香了”，强行把稳定项目迁移到Compose。
后果：迁移成本巨大，Compose生态还不完善，一些第三方库还没有Compose版本。
老鸟内心：你iPhone 15用得好好的，非要去换iPhone 18工程机。为啥是工程机？你现在2026年5月买得到正式版的18？三天两头死机，你开心了？
操作5：不考虑维护成本
场景：PM选了个小众框架，觉得“性能最优”。半年后，框架不维护了，社区死了，招不到人。
后果：项目没人能接，只能重写。
老鸟内心：你买了个小众牌子的车，坏了找不到配件。最后只能报废，再买一辆。
操作6：只看开发速度，不看长期成本
场景：PM选了开发最快的方案（比如低代码平台），前期确实快。后期需求复杂了，平台能力跟不上，被卡脖子。
后果：要么花钱等平台更新，要么推倒重来。
老鸟内心：你租了个毛坯房，觉得便宜。住进去发现没水没电，自己拉水管接电线。租约到期，房东收回，你的装修全白费。
操作7：后端替前端做决定
场景：后端觉得“XX框架很好用”，强行推荐给前端。前端不会用，又不敢说。
后果：前端硬着头皮写，写出来的代码一堆坑。
老鸟内心：你让外科医生给你做理发。不是不会，是不专业。
操作8：不写Demo直接上项目
场景：PM定了框架后，没有写Demo验证，直接开工写业务代码。
后果：写了一半发现框架有致命缺陷（比如性能问题、打包问题、兼容性问题）。
老鸟内心：你没试婚就结婚，结了发现不合适。离婚？可以，分家产吧（重构代码）。
第四部分：框架选型铁律（什么该做）
铁律1：先看团队技术栈
- 团队会什么，优先选什么
- 新框架可以学，但要评估学习成本
- 不要为了“新”而“新”
铁律2：先写Demo验证
- 正式开工前，用候选框架写一个完整的功能模块
- 验证：开发体验、性能、打包体积、第三方库支持、调试体验
- Demo没写就上项目=赌博
铁律3：跨平台不是万能药
- 需要复杂原生能力 → 慎选跨平台
- 纯展示类App → 可以选跨平台
- 跨平台省的是“双端开发”，不省“原生调试”
铁律4：生态很重要
- 社区活跃度、第三方库丰富度、招聘市场认可度
- 小众框架 ≈ 风险
- 你不想成为那个“招不到人维护”的项目吧？
铁律5：PM可以建议，但别替技术做决定
- PM提需求，技术定方案
- 本末倒置 = 项目翻车
- 冤种前端：你选框架，你来写代码？
铁律6：考虑长期维护成本
- 框架停更怎么办？
- 团队成员离职怎么办？
- 写代码一时爽，维护火葬场
第五部分：决策树——选框架前问自己
问题1：团队会什么？
├─ 会原生 → 问题2
└─ 会跨平台 → 问题3问题2：需要双端吗？
├─ 只需要安卓 → 原生（XML/Jetpack Compose）
└─ 需要双端 → 问题3问题3：原生能力复杂吗？
├─ 复杂（蓝牙/NFC/摄像头） → 原生
└─ 简单（展示/表单/网络请求） → 可考虑跨平台问题4：有Demo验证过吗？
├─ 有 → 可以定
└─ 没有 → 先去写Demo！！！
第六部分：老鸟内心精选（框架选型受害者版）
PM：“这个框架很火，我们用这个吧”
老鸟内心：
火？你冬天烤火更火。你咋不去烤火？
火≠对，更≠适合你。你当年还说比特币火呢，你买了吗？
PM：“跨平台可以省成本”
老鸟内心：
省成本？省的是开发成本，加的是调试成本、维护成本、性能优化成本。
你省的是一块钱，花的是十块钱。
数学是体育老师教的？还是你不关心长期投资？？
PM：“我看别人在用这个”
老鸟内心：
别人用，关你什么事？别人吃屎你也吃？
你做决策靠“看”？那我去公园看柯洁下围棋，是不是就能跟他过两招了？
萌新前端：“PM定的框架，我不会用怎么办？”
老鸟内心：
你开会的时候干嘛去了？不会用要说话。
你不是在帮PM擦屁股，你是在给自己挖坟。
啥也别说了，现在！立刻！马上！gank他！！
萌新后端：“我觉得这个框架不错”
老鸟内心：
你是后端。前端的框架，你凑什么热闹？
你去理发店，理发师问你剪什么发型，你说“我觉得这个炒菜不错”？
理发师语：开我玩笑？？
(不过你倒是可以帮着去gank一下PM，帮上面那个可怜的前端出出气。)
第七部分：总结
萌新 vs 老鸟 框架选型对比
| 维度 | 萌新/糊涂PM | 老鸟 |
|---|---|---|
| 选型依据 | “我看别人在用”“很火” | 团队技术栈 + Demo验证 |
| 跨平台态度 | 万能药 | 看场景，慎选 |
| 技术决策者 | PM拍脑袋 | 技术团队定 |
| Demo验证 | 不写，直接开工 | 必须先写 |
| 维护成本 | 不考虑 | 重点考虑 |
| 生态 | 不管 | 必须评估 |
最后一句人话：
选框架不是选衣服，不是“好看就行”。
马哲有云，看问题要辩证、多方面地分析。
你要是片面看待问题，那叫形而上学。“这个框架很火”是PM的借口，不是技术的理由。
“火就是能用”？说明PM不懂辩证思维，思政课在摸鱼。
下次PM再说“很火”，你问他：“你买基金也看‘很火’吗？亏了谁赔？”框架选型，技术说了算。
PM可以提需求，但不能替技术做决定。
如果非要替，那代码也你来写？
附：第十五期自测题
问自己三个问题，有一个“否”你就还是框架萌新：
- 你选框架前写过Demo验证吗？
- 你选的框架，团队有人会吗？（没有=你一个人维护到死）
- 你考虑过这个框架3年后还有人维护吗？
三个“是”才及格。少一个，回去重新选。