移动端混合开发的接入

android 混合开发

平台

目前针对移动平台的混合开发接入，主要分为Android和iOS两大阵营，相比Android平台来说，iOS端的WebView相对稳定，且前后变动不大，只需要关注业务逻辑即可。但是Android平台中WebView存在严重的碎片化问题，而且对于js的调用在Android 4.2以前存在远程执行js的漏洞，相对而言，在Android平台中要更多的考虑安全问题。

技术路线

• 纯Web层面

  • React Native
    React框架为基础，兼容Android、iOS，官方号称70%的代码可复用，相对稳定，插件丰富。
  • Weex
    Vue框架为基础，兼容Android、iOS，经过大厂验证。
  • ionic+cordova
    Angular框架为基础，ionic专注前端渲染，cordova封装系统层调用信息，可跨平台多，学习成本高。
  • mui
    偏前端展示，效果类同原生控件，配合HBuilder进行开发，快速高效。
  • apicloud
  • AppCan

• 非Web层面

  • Flutter
    独立渲染，接近原生，新出，目前生态不是很完善，可能需要自己编写插件，但是大厂实践多，可参考内容多。

开发层面来讲，我更倾向于mui+Weex/Flutter的方式。也就是mui做一些更新比较频繁的页面，比如抽奖、秒杀这样的活动页面前端，Flutter/Weex做业务性的内容，同原生交互比较多的内容。

WebView依赖

• 原生WebView
  iOS中，原生WebView相对稳定，不需要考虑太多情况。
  Android中，存在WebView碎片化的问题，而且需要做的兼容性工作比较多。再考虑到Android碎片化的问题，在不同的手机上，显示差别大，性能差别大！
  所以如果在Android端采用原生WebView，推荐使用AgentWeb框架。

• 腾讯X5浏览内核
  腾讯X5浏览内核，针对Android WebView的问题产出，兼容性良好，但是开发成本高，存在暗坑，并非开源项目，容易造成开发成本过高的问题。不支持cordova框架！

• CrossWalk
  cordova官方出品，Android/iOS均可用，性能最佳，但是引入包高达18MB，引入后App体积爆炸。

开发方式

• Web页面嵌入
  
  • 业务层面
    
    1. 需要考虑URL拦截的问题，拦截规则和跳转规则。
    2. 处理下载问题
  • 活动页面更新
    直接更新URL即可
• 与原生交互
  
  • 使用JsBridge调用原生api
  • 处理下载、文件选择等问题
• Web侧更新策略
  
  • 业务层面
    考虑Web侧热更新问题
  • 活动页面
    直接下发更新URL
• 热更新/热修复
  待更新

安全

• Web侧安全
  
  • Web页面劫持
• 通信接口
  
  • js和原生代码交互

总结

接入混合开发，需要同时考虑Web侧和原生侧的问题，如何编织使其发挥各自优势，是我们需要认真考虑的问题！