58App业务中有城市和县域两个首页，两者中间有一个过渡选择页，用户通过点击该页面下的条目内容可以切换到对应条目的首页；比如：点击“北京”会跳转到北京（市）的首页，点击“大兴”则会跳转到大兴（县）的首页。

除了用户直接通过上述提及的选择页切换城市和县域外，58App内还有另一种切换首页的方式——基于位置变化的弹窗式引导切换。当用户的定位城市及县域与当前选择的城市或县域有差异时，此时App会主动弹出一个窗，提示用户将首页切换到当前定位的城市首页或者是县域首页。

具体引导切换到城市首页还是县域首页，是通过服务端下发开关配置进行控制的。需要注意的是，App同时只能存在一个首页，当位置变化后，切换到城市首页和县域首页的可能性都存在，如果服务端将这两种开关同时打开的话，势必会造成客户端弹窗引导切换冲突的问题。

当用户所处的位置在某市下的某县时，APP此时出现了弹窗冲突：

如何避免上述弹窗引导切换时发生冲突呢？

一开始，弹窗是这样处理的：

产品方面

1. 通过产品经理人工分析总结可能存在引导切换城市和县域的场景（弹窗）；

2. 同时靠人力分析每个场景（弹窗）之间存在的冲突情况；

3. 运营在下发不同配置开关引导首页切换分发流量时，思考是否会产生冲突（多个弹窗）。

打开指定开关引导特定场景首页切换；同样，关闭开关暂时阻断特定场景的切换。

开发方面

1. 程序开发者通过产品经理总结的多场景分别进行处理；

2. 程序开发者针对产品经理分析出的场景冲突进行解决。

3. 每个场景对应各自的开关配置，每个开关对应不同的逻辑处理、对应各自的弹窗、对应各自的文案；

开发者此时在不停地解决QA反馈的弹窗冲突；因为产品经理也没有想到会出现“这样和那样”的场景冲突!!!

上述方案人为把控点多，场景错综复杂，人为干预每个环节出错率很高，同时对开关的配置也没有纠错和验证能力；除此，客户端处理的场景很多，解决的必要问题就一个，但是非必要问题很多。开发侧一直处于被动执行的情形，此时补的逻辑越多、错的地方就更多。以为是一个简单的弹窗需求，结果变成处理花式弹窗冲突的大坑。

引导切换场景中到底有多少场景是冲突的？整个引导过程中又有多少种切换场景呢？ 这个问题此时很难有人说得具体。

针对如此难解问题，作者思考做了一套模型：模型完整地罗列了一张58App中所有基于位置变化后城市与县域互相切换的场景表；更直观的是，此模型直接表达出了所有切换场景间存在的冲突项。

2.1 模型方案产出

知道了上述的需求背景和开发痛点后，首先把方案设计要解决的问题和事项加以罗列：

1. 如何全面产出城市和县域首页互相切换存在的各种场景；

2. 如何分析得出上述各种场景可能存在的冲突项；

3. 终通过分析出的①场景和②冲突项，合理制定一套高效准确无冲突的开关配置协议，满足产品运营需求。

模型思考设计：

1. 使用面向对象思维，将城市和县域两个实体分别用两种变量表示。

2. 两种不同的变量切换其实是一种交换关系，交换包括与自己交换和与非己交换。

3. 城市和县域本身存在上下级关系，涉及到下级的交换时要考虑上级是否也存在交换关系。

4. 用变量表示出所有的交换项，这些变量交换项便是带有上下级关系的全部切换场景。

5. 分析上述全部变量交换项，找出存在包含与被包含的交换项，出现包含关系的两个交换项则认为存在冲突关联——互斥的事件即不会同时发生——有交集才会有冲突。

6. 通过步骤4和5的结果，确定开关配置协议（用于控制不同场景下的切换弹窗）。

模型的思路可以用简单的几个关键词表达：变量、交换(切换)、上下级、交集(冲突)

具体模型推演：

1. 城市用变量X表示，县域用变量Y表示。

2. 城市与城市的交换表示为：X->X’，城市与县域的交换表示为：X->Y；县域与县域的交换表示为：Y->Y’，县域与城市的交换表示为：Y->X。

3. 城市属于上级，用单个X变量表示即可；县域属于城市下级，单纯的变量Y在这里表示县域不再充分，这里在原来县域变量Y前面加上城市变量X来表示带有所属关系的县域XY更准确。

4. 加入上下级关系后，城市与己因为没有下级关系，所以互相交换还是用X->X’ 表示；城市与县域的交换则需要考虑目标县域是否与当前城市相同与否的情况，相同用X->XY表示，不同则用X->X’Y表示。同理，县域与己的交换也要考虑目标县域是否与当前县域所在的城市相同与否的情况，相同用XY->XY’ 表示，不同则用XY->X’Y’ 表示；县域与城市的交换考虑的则是目标城市是否与当前县域所在的城市相同与否的情况，相同用XY->X表示，不同则用X’Y->X表示。整张关系表如下：

   

5. 上述交换项中可以看出：城市切换时，存在X->X’被X->X’Y包含的情况（X->X’ ∩ X->X’Y = X->X’）；县域切换时，存在XY->XY’包含XY->X的情况（XY->XY’ ∩ XY->X = XY->X），XY->X’Y’包含XY->X’ 的情况（XY->X’Y’ ∩ XY->X’ = XY->X’）。

6. 步骤4中的结果一共有7个交换项，这7项中又包含步骤5中的3个关联交集；也就是说，考虑关联交集(冲突)后，能够同时存在的交换项个数多是4个（因为其它3个与这4个有冲突）。

协议开关配置：

如此，协议开关配置时变得很简单了，只要按模型校验逻辑即可。

方案详解：

1. 服务端下发开关配置协议时，从全量派发改为按需下发，原来要下发7个全场景，现在只按引流需求下发。7种引导场景，择需下发；选择时如果出现冲突，模型算法可以提示和排除冲突（开关多下发不会超过4个）。

2. 客户端处理弹窗逻辑时，不再考虑弹窗冲突的问题，逻辑仅体现在选择和定位的城市或县域信息不一致的处理上。原来要为7个配置开关设置7个逻辑弹窗，引入模型后，只需处理4个逻辑，也就是推演步骤2中的四种场景，即选择的城市或县域和定位的城市或县域的两两组合。假设，用户选择了X市首页，当前定位在X’市，这时候只需遍历下发的开关中是否存在“引导从城市切换到其他城市首页”的开关即可；如果有，则弹窗；否则，不弹窗。弹窗文案同时可以模板化——“当前浏览的是X市(县)，是否切换到X’Y县(市)”。

经过这样的模型算法，其实已经筛选了服务端存在冲突的协议开关；同时，客户端也会将多种场景经过定位数据筛选终匹配到多一种开关设置的场景。

通过以上设计思路演进和步骤实现，终产出的模型可以完整、高效、准确、无冲突地解决城市与县域互相切换的开关配置问题。

使用本方案，只需一套标准模型算法即可解决多种场景下的错综弹窗问题，多场景问题得到了归一处理。解决了服务端下发协议考虑冲突的难题；同时，减轻了客户端处理多个场景的逻辑负担。

总结

1. 通过模型，产出了城市与县域互相切换的场景表；又通过模型算法，计算出了这些场景表中存在的冲突项；后，通过服务端下发排除了冲突项后的场景开关配置，可以准确控制App弹窗引导切换城市和县域首页。

2. 比传统人工分析会具有理论价值意义，且更具备系统性，逻辑简单，产生的结果更全面准确，排除了人为分析出错的可能，减少了客户端对多种情况的弹窗和逻辑判断处理负担，客户端弹窗逻辑维护成本低，分析出的冲突关系也更具完善性和精准性。

3. 这套理论模型基本可以应用到一切带有上下级关系互换位置的逻辑分析和处理，理论应用场景广泛。