BOSS预约-技术方案

目标平台：ios、ipad、android、android pad

考虑的技术分案：

• native + flutter 混合开发
• native + h5 混合开发
• native

一、native + flutter 混合开发

flutter 2.0 稳定版发布后平台技术相对成熟、提供较多的第三方组件库支撑，使用体验方面更接近原生，通过Redux状态治理，代码相对会更规范、有实战项目经验，在多目标平台上，相对会更得心应手；

劣势：

• flutter 只是解决一套代码（Dart）来降低Android/IOS的资源成本问题，在数据更新这块，并不能做到动态发布；
• flutter 容器不是共享内存，在混合 native 页面超过一定量时，内存会有过大问题；（官方未来新版本，会解决该问题）
• flutter 与 native 交互需要Android/IOS人员编写插件支撑

二、native + h5 混合开发

Vue2 在国内市场占有率相对较高，也有提供成熟的移动端UI框架（cube-ui滴滴、vant有赞、nutUI京东），大部分可以实现和原生类似效果；最重要是可动态更新页面，方便用户去验证各类项目方案；

劣势：

• 输入框的适配，没有有效完整解决方案；

  • 产品在设计H5页面中使用输入框时，对摆放的位置尽可能和开发提前达成方案共识；

• 关于首次加载页面慢的问题；（已解决最大问题，后续可在持续优化）

  • 对通用的资源脚本、通过技术拦截，本地加载资源，优化整体加载时间；

  • 对动态的资源脚本、通过首次远程加载完成后，进行本地化缓存，提高后续加载进度；

• h5 与 native 交互需要Android/IOS人员编写JS脚本支撑；

三、native + h5 对比 native + flutter 主要优势体现：

• 页面资源动态更新，对需求调整、BUG修复等不需要更新应用；
• 方便验证不确定的需求场景；

四：BOSS预约 在选型时，需要考虑的方案和风险：

• 能力展示新增 BOSS预约 模块，为何不继续使用 native ?

  • 主要考虑是可动态更新资源，方便验证目标，且在调整需求和修复BUG上，不需要更新app；

• 能力展示新增 BOSS预约 模块，为何选用 h5 而不是 flutter ?

  • flutter 工程和现有的 native 工程环境差异较大，需要对整个能力展示项目工程重构，未知风险太大；

  • h5 主要依赖原生控件 WebView/WKWebView 加载远程地址，对现有工程影响较小；

  • h5 打包部署后，app可以响应最新的动态内容，flutter 暂不支持；

• Pad 端为啥不考虑 flutter ？

  • 不能动态更新；

  • 迭代需要两拨人员进行维护升级，资源成本消耗较大，涉及计划工期、需求理解、开发联调、修复BUG等都需要同步；

  • pad 工程将在基础页使用 native，业务使用 h5；

• h5 在的体验和适配上一些未知风险是否有考虑？

  • 体验方面，在3月份移动端成员通过开发【天联共创 H5版本】，进行一系列验证，在大部分场景下能正常适配效果，部分界面可能在体验上相比原生会差一点，但总体来看大部分可以满足现有的公司需求；
  • 针对 h5 首次载入比较慢的问题，在 第二点 中有做了介绍；
  • 移动端人员对 h5 开发的经验相对比较薄弱，对未知问题除了主动研究解决方案，也会通过咨询前端人员寻求帮助；

附. 现有公司APP端的技术：

• 天联共创

  • native 纯原生开发；
  • api 域名统一；
  • token 唯一，同账号登录互踢；

• 能力展示

  • native 纯原生开发；
  • api 域名，根据动态模块下发；
  • token 并存，相互不影响；

• 小牛制造

  • flutter 开发；

  • api 域名统一；

  • token 唯一，同账号登录互踢；

• 关注事项（早期项目）

  • app flutter 开发；
  • pad native 原生开发；
  • api 域名统一；
  • mqtt 消息长连；
  • 消息数据同步；