1. 基本需求场景 h5 需要一些只能在 app 端获取的参数、数据
- 产品的需求不能在 h5 端独立实现
2. 进阶需求场景
- 同样的需求，在做好设备适配情况下，在 h5 端实现能够节省人力成本（一套代码运行在两种设备上）
- 在 h5 端实现的需求，版本控制较为灵活，不依赖应用平台（应用审核等方面原因）
- 如果有可能，在 h5 端实现一套代码逻辑适配两种设备能够进一步提升开发效率（无需分别与 app 两端联调）
3. 社区流行方案
| 名称 | github stars | 地址 | 最近更新时间 | 注 |
|---|---|---|---|---|
| JsBridge | 7.2k | https://github.com/lzyzsd/JsBridge | 9 days ago | 最为流行，但 h5 端未实现统一 api，因为本身就是两个项目，只是两端分别最流行的方案的组合，近期也未有更新 |
| WebViewJavascriptBridge | 12.8k | https://github.com/marcuswestin/WebViewJavascriptBridge | 2 years ago | |
| DSBridge-Android | 2.0k | https://github.com/wendux/DSBridge-Android | 10 months ago | h5 端有统一 api，近期有更新，但不够流行 |
| DSBridge-IOS | 1.1k | https://github.com/wendux/DSBridge-IOS | 1 year ago | |
| quickhybrid | 0.3k | https://github.com/quickhybrid/quickhybrid/ | 2 years ago | 形成了一套设计理论，较为全面，可提供理论支持，但不够流行，最近更新时间也较久远 |
4. 目前我们的解决方案
- 较为混杂，一般为采用 WebViewJavascriptBridge 和 JsBridge
5. quickhybrid 中的设计理论
6. 理想状态
- 因为社区并没有一个较为理想（流行度、实时性、统一性）的综合解决方案，所以理想状态还是应该基于我们自己的实际需求，设计并三端实现一套自己的框架，类似于小桔猫社区中发贴规则的自定义协议实现