让APP自由穿梭在Native和H5中

公司的项目核心业务都在H5，为了提高APP的使用体验，这段时间在重构部分功能业务到Native。重构过程持续了4期（一期1~2周），天天工作量杠杠的（因为追求速度，线上质量打了折扣，现在放慢脚步正在稳固，我才得以写这篇文章，接下来还要继续下一期的重构,又期待又紧张）。在重构过程中，收获到了挺多Native与H5之间交互和一些动态配置的体会，就在这记录下这些风雨历程吧。

ps: 文中不涉及具体代码，主要记录实现的机制和逻辑，之后将代码方案抽离项目后会添加demo地址

功能需求

扯一扯：
公司现在版本的APP的主业务在H5端，那么我们Native重构的页面就避免不了跟H5之间的交互。这是最基本的需求，完成这个需求的方案已经比较稳定，我们使用自己定义的协议对需要交互的功能进行拦截实现H5到Native的交互。Native到H5的话就直接在控制器内加载指定地址的webView。

很显然，在Native到H5这一步有很大的优化空间。老大提出了这样的要求：

• 所有跳转的H5地址都需要能够在服务端动态配置，下文称：DymaticH5方案
• 所有的Native页面能够被H5调起，不管在应用内还APP外，下文称：NativeScheme方案

另外一位H5同事附加提出了一套线上容错方案(拯救了两次线上bug)

• 所有(有需求)的Native页面都能够通过服务端配置随时替换成H5， 下文称：SwitchPage方案

方案探索

DymaticH5方案

首先介绍下环境：

我们的在线环境配置文件都放在自己实现的静态接口平台下面称tms，由我们前端部门的同学自己管理，可以方便及时地配合客户端和H5的迭代和更新。

• 首先我们将所有需要动态化配置(由Native跳到H5)的H5地址页面地址整理放到tms的配置文件中，例如:

{
    home : https://www.baidu.com,
    mine : https://www.mine.com,
    news : https://www.news.com
}

• 工程项目中添加与tms配置文件格式相同的plist文件,用于存储当tms上没有配置动态H5地址时的默认H5地址。

• 整个项目中的H5地址由URLCenter工具类集中管理，获得H5地址后存储在DynamicH5Model中。

  • DynamicH5Model职责：

    • 获取plist中的H5地址给model赋值
    • 读取tms返回的H5地址给model重新赋值

  • URLCenter职责：

    • 读取DynamicH5Model中的H5地址
    • 获取调用者传入H5地址所需要带的参数
    • 拼接参数返回调用者需要的完整的H5地址

我们来看一张简单的流程图：

APP启动程序先读取plist中的默认H5地址赋值到model，在请求tms配置文件之后，再获取tms中配置的H5地址赋值到model，这样可以保证每个H5地址都可以有值，并且都是我们所需要的最新的地址。如此，即使在线上，不用发版本我们的APP也可以自如地控制和更新每个功能模块跳转的H5页面内容。

当然，每个H5地址需要什么参数还是得调用者自己知道，然后将参数赋值到URLCenter中。

NativeScheme方案

取名叫NativeScheme，当然这个方案跟sheme有关，但也不仅仅是使用sheme。

先说明这个方案最终达到的效果吧：

APP中的部分功能模块点击跳转指向本地的哪个页面由服务端控制，不再需要本地固定。可以随时切换功能模块跳转到对应的H5页面还是对应的Native页面，当然前提是这两者页面都有实现。

例如：

在这样的功能块中，每个功能模块点击后通过服务器返回的NativeScheme判断跳转到本地的对应页面。

实现原理：

• 服务器给每个功能块添加一个nativeScheme的字段, 如 myApp://jakeApp/home

  其中 myApp为APP的info.plist配置文件中的URL Scheme

  若部分页面初始化时有些必要的参数需要指定，NativeScheme可以附加必要的参数，如myApp://jakeApp/home?homeType=1

• 工程项目中创建一个nativeScheme.plist，其中存储的是每个nativeScheme对应的本地控制器的名字和控制器初始化的方式（storyboard或xib或frame）

  如：

  {
      myApp://jakeApp/home : {
       class : HomeViewController,
       type  : storyboard
      },
      
      myApp://jakeApp/mine : {
          class : MineViewController,
          type  : xib
      }
  }
  
  

• 整个项目的控制器跳转由URLRouter控制，可传入H5地址或者NativeScheme地址获得将要跳转到的控制器

  • URLRouter职责:
    • 传入navtiveScheme格式的地址，则从本地navtiveScheme.plist中获取对应控制器并初始化传入从地址中获得的参数
    • 传入H5地址则获得完整的H5地址(若有使用第一节中的DynamicH5方案可以将其传入URLCenter获得地址)，创建webView跳转

• APP可通过 URL Scheme唤起，在AppDelegate对应的方法中使用URLRouter跳转到对应的Native页面

方案扩展使用：

我们还可以在nativeScheme判读环节添加一个动态的节点(根据需求)，以实现点击功能块后是跳转到H5页面还是跳转本地的页面(此逻辑不同于本章第三节 “SwitchPage方案”)。可以给每个功能块分别添加 本地scheme地址 和 H5地址 两个字段，用于分别是跳向哪种界面。判断规则可以根据自己的需求来定。

附上NativeScheme的简单流程图：

此方案部分参考：https://github.com/DarielChen/DCURLRouter 感谢作者

SwitchPage方案

这套方案的存在，在某种意义上是一套线上的紧急备用方案----当重构的Native页面出现问题，可以通过此方案将该Native页面替换为H5页面。此方案，可以说是对我们项目现状比较适用，在其他项目中或许存在的意义没有那么大。但是这套原理可以拿来做参考，毕竟SwitchPage可以将任意一个Native页面替换为任意一个H5的页面。

实现原理：

实现逻辑也比较简单，

• tms上配置需要替换的控制器名字和需要替换成的H5地址的绝对路径，如：

{
    HomeViewController : https://www.baidu.com
}

• 重写本地的Nativgation的push方法， 在此方法调用super之前，判断将要跳转的控制器名称在tms请求返回的数据中是否存在，如果存在则跳转webView控制器，不存在则按照原来方法跳转。（可结合NativeScheme方案使用，在URLRouter中实现此逻辑）

附上简单流程图：

总结

不足：NativeScheme方案中的参数传递比较地生硬，若是需要跳转的Native控制器需要制定的参数需要额外处理，则无法通过shceme后带参数的方式在URLRouter中直接给要返回的控制器添加参数

上面三套方案可以在项目中一起使用，相互之间不会影响，也可以单独使用其中的某一套方案。

demo地址：即将出现