@CommandZi 严重同意，Flutter 就算了吧哈哈哈

我现在依然使用 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 接口的封装。

首先排除 uni 和 Flutter ，然后...似乎没得选了

请问这个类似小程序码的图案叫什么？

@zxCoder 合法卖 Yín 罢了

换个角度看看也许会释然。

也许结婚不是大事，也可以不那么重要，也不一定是必须的。
也许不一定要买房。
也许婚姻不一定是全新的生活。

大家都第一次做人，没有啥绝对正确、必须的路线，开心就好了。

我记得顺丰海淘也差不多收了这个数。

不过现在是特殊时期，健康码没有黄，人没有被强制拉取隔离，取到手机之后还能上网发帖，还能有命活着...不错啦

打错，不需要个人实名认证信息

1. 端对端加密
2. 需要个人实名认证信息
3. 服务器不在中国大陆
4. 安装包体积小于 100M
5. 没有杂七杂八的功能

小公司、新业务的话推荐 TypeScript 。

- 前后端、移动端都可用，配合 TypeDoc 文档生成，多人协作不会有太大的坑。
- 需求不复杂的后端业务直接上函数计算，各个平台都支持 TypeScript
- 生态好、轮子多
- 好招人、上手成本低

16 Macbook Pro ，感觉这 M1 的本儿 Wi-Fi 比起手机、老得 MacBook Pro 差的不是一点半点，经常是 Wi-Fi 存在，其他设备都能扫描到，电脑无法扫描到，重启才可以。

聋哥不会听的... ...

@JellyDong
我会坚持至少 3 次态度比较好的沟通，能引导就引导，就事论事处理问题，并给出自己的建议。避免小人说我一开始就针对对方，必要的话就后台录音（对于个别人我是这样处理的）。

如果还不改，直接找直属领导或人事，谈让对方离职、辞退的事情，直接一点对大家都好。一旦确认双方不适合合作，并且是对方做事的基础态度问题，就不留任何面子了。

从事件一看，楼主的沟通方式或态度也有问题。

根据不同场景区分使用不同的文档工具，我是这样的：
- 团队内部需求和讨论文档：Confluence
- 代码文档：Markdown 生成 HTML 托管到 S3 ，平时写前端比较多，选的 TypeDoc 和 HonKit
- 个人工作日志、信息管理、朋友间分享信息、个人之间协作：Notion

我也是，感觉无奈。换 Google 全家桶 ing