首先第一点，我们要以平和的心态面对这些需求（贫穷使我平和）！！！
随着一个程序的迭代发展，APP首页总会被设计出越来越多的弹框：
（1）常见的有系统级的“请求获取用户网络”，“请求给用户发通知”，“请求获取用户定位”，“请求同意协议”等权限要求弹框。
（2）还有提示“APP版本更新”，“新手引导”，“绑定其他账号”，“账号异常退出登录”等通用提示弹框。
（3）更有想提醒（引诱）用户进行一些升级操作的，比如“满100-99优惠券”，“年度超值大礼包”，“恭喜您被选中”，“快去确认账单领积分”，“快去参加活动抽大奖”，“您的好友邀请您xxx”等业务弹框。
如果这些弹框的业务代码全被写在首页的控制器里面，会导致代码越来越臃肿，后续维护起来越来越费力，如果产品经理随便提出调整一些“小需求”，比如修改一下这几十个弹框里边的其中几个业务和弹出顺序，着实令开发人员头大。
困难总是有的，但是有句话说的好，“老板花钱把你找来是为了解决问题的，不是让你提出问题的！”，下面我们就来讲讲如何处理这个问题。
首先为了保证一个良好的用户体验，我是这样想的，当用户进入程序之后，先保证用户能看到首页内容，再保证用户能操作，最后再做弹框提示处理！具体操作如下：
进入首页后，先从本地数据库取出一部分数据渲染界面，让用户先看到一部分缓存内容，但禁止用户操作，再弹出loading图，开启异步线程组，同时请求多个展示数据所需要的接口，加载完之后关闭loading图，再次刷新界面，此时已可以让用户进行滑动和点击按钮等操作，然后加载弹框业务有关的接口，等需要的数据全部加载完之后进行统一汇总处理。如果用户此时还在当前页，就直接弹出所需提示的弹框，如果用户已经离开了当前页，就等用户再次返回首页的时候再弹出所需提示的弹框。
接下来就讲讲如何汇总处理弹框的业务，首先我们想想需要达到一个什么效果，我认为以下需求肯定都是必不可少的：
（1）弹框肯定不能一下全部弹出，那会丑爆的，必须一个一个弹出，
（2）顺序一定要灵活配置，产品的不同发展阶段，不同业务的弹框提示顺序肯定不会相同，
（3）耦合度不能太高，不能改了这个影响那个，
（4）扩展性也得好，要不面对后续“小需求”怎么办，
（5）统一处理的时候也得方便，比如某些特殊情况全部不让展示。
明确了目的之后，我们就开始设计吧
从视图层面考虑，为了降低耦合度，我们肯定要把每一个弹框都设计为一个自定义视图，然后只暴露出来这个视图对应的一个模型供传递参数使用，但为了方便统一管理弹框和设置一些通用属性，比如背景透明度，颜色，弹出动画，关闭弹框方法等，我们就要先建立一个自定义的父类视图，让这些弹框都继承自这个父视图。
然后从数据层面考虑，因为弹框的数量众多，又随时可能增加减少调整顺序，我们就在本地建立一个专门处理弹框数据的类，在这个类里边请求弹框所需的所有网络数据，获取所有数据之后，根据数据生成一个模型数组，和这个弹框列表形成映射关系，在每一个模型上增加一些属性，包括弹框id，弹框名称，弹框是否需要弹出，弹框所需的Jason参数等属性。等数组建立完之后，就单独写一个遍历这个数组的方法，遍历数组内的每一个模型，如果这个模型的弹框是否需要弹出属性是YES,就弹出对应的弹框，当关闭这个弹框时，就将弹框是否需要弹出属性改为NO，然后从上一个模型的位置开始继续朝下遍历，直到数组内所有的模型的是否需要弹出属性全部变为NO为止。
这样处理完之后，如果产品经理想整体换个背景透明度，颜色，弹出动画等，直接在父视图的一个地方调整就行，想单独调整某个弹框样式，就单独改某个子视图弹框样式。想要加减弹框或调整顺序，就只需要修改我们本地生成的模型数组就可以了，除非加新的弹框，否则其他地方都可以不怎么改动就行。
一番折腾完之后，希望大家遇到同样问题再也不用担心被产品经理怼了：
网友评论