感谢大家的帮助，我们最后选择了 uniapp+自定义安卓基座的方式。我并不直接负责该项目，我只是做前期调研。
经过一年的使用，将结论写下来，让更多的人在遇到相似的问题时有所参考。
# 需求如下：
1. 跨平台
2. 会涉及硬件（蓝牙）调用
3. 业务逻辑较为复杂

结论：
# 无法应对如此复杂的场景。
首先是硬件调用，我们需要连接蓝牙外设，uniapp 的蓝牙 API 非常不好用。
蓝牙状态的回调会重复进行，搜寻广播信息会失败，断开后无法重连等问题。
虽然有些问题不致命，但是这会让开发者对框架产生不信任的感觉，起码我们在开发中经常产生“这框架是不是有问题？”、“卧槽蓝牙掉了？咋肥四啊？硬件组你们固件更新了啥？”，诸如此类的浪费时间的行为。
——————我是分割线——————
在进行了大半年的 uniapp+原始基座开发后，我们将蓝牙的连接全部放到了自定义安卓基座上面，即调用硬件的代码交由原生安卓编写，uniapp 端负责业务逻辑的实现。
目前情况就是这样，在此向所有回复的朋友道一声感谢，也向未来遇到技术选型的朋友建议，尽量选择原生框架进行开发，或者跨平台框架选择中，尽量选择可以加入原生代码的框架。