“不要「恶意」揣测老大哥的需求...不要「恶意」理解”

感谢楼主提出这个现象，看来以后微信里面发链接都要特别注意了

标题里面是不是忘记打「中国」两个字了？

感觉过于花里胡哨... ...

推荐 GitLab 全家桶，比如可以 GitLab + Confluence ，团队内部不止要做好代码开发，内部开发文档可以一整套搞起来。

看了有提 PR 的冲动，这种项目太有意义了！

要是还带指纹的话挺心动的

我们折腾了几个月...最后买了个 200 多的蒲公英路由器，开启旁路由模式，每个人开了蒲公英 VPN 的账号解决。
总共十来个人花了几千块，好处是不用再折腾了，这边电信间歇性封杀端口。

"不能怪我抄袭，都是中国有墙。"
“我们原来也花了很多钱用 Notion 的，但我们不会翻墙。”
“感谢防火墙，我们会继续努力抄的！”

@FaiChou

关于这个问题： 这是使用 RN 创建的项目, 里面只有一个 rootViewController. 它是如何(在哪里)实现 `将 NavigationController 的 View 作为 child view` 的? 是不是在编译 .h .m 时候给替换掉了? 具体是怎么完成的?


看到你的问题顺手看了一下 react-native-screens ，目前初步判断是这样的，可能不够准确。可以在 `RNSScreenStack.m` 中看到：

- 具体实现应该是对应此文件 249 行的 `[self addSubview:controller.view];`
- 这个 Native UI Component 封装实现了 `- (void)insertReactSubview:(RNSScreenView *)subview atIndex:(NSInteger)atIndex` 这个方法，可以拿到 JSX 中嵌套的子组件，渲染在 UINavigationController 中的子 controller 中

------

数据传输应该不会受到影响，目前还没遇到这方面的明显问题。看到现在新的 Fabric 布局引擎是基于 JSI 来做通讯的，不需要通过走 Bridge 的方式复制大量数据了。

关于生命周期这块不是看的很清楚（没仔细看，先做家务去 T_T...），应该是在 Native UI Component 首次渲染的时候设定为 child view 的。

将 NavigationController 的 View 作为 child view ，可以仔细分析一下 react-native-screens 中的 `RNSScreenStack.m`

在 SDK 中将继承自 `UINavigationController` 的 `RNScreensNavigationController` 作为原生导航管理用途，将 RNScreensNavigationController 的 View 作为 RNSScreenNavigationContainer 的 Native UI Component 的子 View ，大概是这样的。

能改善就太好了！电脑上主要使用 Safari ，平时用的一些服务对 Safari 的兼容不怎么好，希望能尽快改善。

对于新时代 IE 这个说法严重认同，特别是调试某个版本 Safari 浏览器兼容性还要安装特定版本 macOS 这种蛋疼的设计，太坑了...

@Hanggi Flutter 是基于 Skia 绘制，控件不是使用的原生控件。我作为一个用户的感觉，Flutter 的 ScrollView 的惯性和 bounce 效果令我感到不舒适，与系统体验不一致，非常明显。

设备量 500 太少了，EMQ X 肯定满足需求。
置于 MQTT 协议的选择，取决于设备端的特性和支持程度，不同的设备类型、芯片原厂 /方案商提供的 MQTT SDK 会有一些差异，或者你们同事自己移植，与他们讨论一下吧。

@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 ，然后...似乎没得选了