需求内容是这样的：
1、从H5向NA页面跳转时，支持H5传递某些参数，以表明此跳转来自于该H5；
2、NA页面也层层传递此参数，并在与Server交互时，上报到服务端；
举例：从积分跳转到自营销界面（点击事件），传递参数“来自积分”；在自营销模块中创建活动，每级页面都带着参数，最终点击“创建活动”button时，与服务端交互，将此参数上报给服务端；进而，服务端可判断，这个营销活动是由积分模块引流而来。

普通方案：
H5的参数传给NA页面（通过Intent），NA页面跳转到后续NA页面依然通过Intent传递该参数。在某个NA页面与server交互的时候就能够提交该参数。
那么问题来了，如果NA页面调到后续的可能的NA页面较少，或者跳转路径很浅，或许可以这么考虑。但是一旦NA页面较多，路径可能会非常深，怎么办？这对于原有业务逻辑是具有毁灭性的。更加灾难的一点是，使得页面之间的耦合性过于严重，无法单独开启。

普通方案示意图

进阶方案：
我们仔细分析一下需求会发现，要做的事无非就是全程携带一个标记，表示当下的页面来自于哪个H5页面，由于不用考虑H5页面内部跳转，因此此标记具有唯一性，即一旦标记参数诞生，也就同时意味着当前页面将立刻进入某个na页面，你将无法在不关闭na页面的同时修改H5来源，除非从H5跳转到的所有页面都关闭，当你回到该H5页面时，才能进行其他（跳转）操作。因此，这里面用到了一个常识：Activity栈。见下图：

H5开启的Activity栈

由于H5标示具备唯一性和这种类似于栈的特性，我们可以考虑从第一个H5页面显示开始，就初始化并维护一个“标记栈”。这个标记栈生命周期随着H5壳界面而存在，每新打开一个H5页面，则栈顶就会压如一个参数结构,记录当前H5的“标记参数”。

标记栈与页面关系、网络请求参数对应示意图

由此方法即可在对原有页面内部逻辑无修改的情况下，统计从H5跳过来的标记。