两天内对项目中的红包展示逻辑及UI做了大调，总结下其中的经验以及发现的编程中的问题：
先说下问题：
多余时间消耗的原因以及解决方案：
两天时间中，除去编码、调试以及优化外，其中有三处耗时的地方可以优化
1，前期的交互逻辑模糊。
在没有准确明确各个页面如何跳转，每个页面跳转携带什么数据，页面展示需要请求什么数据，回调会传递会什么数据前，匆忙编码，导致过程中逻辑大量修改。
2，没有准备好测试工具。
调试中，多次错过仅此一次的测试机会，导致在特有条件下没有捕获流程，状态信息。
现在的红包测试依赖于真实的付费，以及多账号之间的切换。测试过程复杂耗时。
在只针对于逻辑、UI的调整，不涉及接口的情况下，应对各个状态的model进行持久化存储，便于调试时随意选择要展示的状态。
3，程序中细节可以记录，调整。
比如case的排序，常查看的方法所在行数。在大量代码的文件中查找方法、刚刚的代码位置也是比较麻烦的。
还要熟练配合快捷键以及多tab的切换。
tab页 排列方式：
从左到右依次是小控件 封装View 控制器 配置页
快捷键：
搜索 “iOS开发快捷键,看这一篇就足够了” 比较全
红包展示逻辑（从点击红包开始）：
1，准备红包展示需要的基础数据，红包类型，红包状态
- 基础数据存在于点击控件中，头像，名称，祝福语等
- 红包类型存在于点击控件中 ，一般也在基础数据中，比如随机红包，平均红包，名片红包等
- 红包状态需要临时获取，这样才能取到最新的状态，包括：可以抢，已抢，被他人抢完了，已过期 只有这四个
2，展示红包
- 普通红包的展示仅仅需要基础数据，类型和状态
- 名片红包在基础数据外，还需要单独获取名片的信息（名片的信息需要通过红包ID 获取）这里的逻辑是，先展示View的整体，对内部view的数据临时获取，这样可以提高外层view的展示速度。
3，回调的处理，代理的方式要优于block
- 设置代理不需要在协议类中，但是block一般要在view的添加类中，否则需要类之间的调用传递消息。
- block不宜多层嵌套，这样逻辑代码糅合在一起不易理解。
- delegate中一个方法处理一个逻辑更清晰。多协议比多block更容易维护。
4, 抢红包动作的处理。
- 最终抢红包结果基于状态，因此触发抢红包动作时，需要请求最新状态，根据最新状态进行展示
- 对于名片红包，抢之前需要判断自己的名片信息，如果没有名片还需要编辑，有完整信息后才可以获取红包，交换名片。
发红包规则(对微信的学习，并做了调整) ：
优先级：
个数，单个红包区间，金额
单个红包在0.01~200之间
三种提示语：
一次最多发100个红包（个数提示）
单个红包金额不可超过200元（金额提示）
单次支付总额不可超过20000元（金额提示）
输入限制
1，金额
不得大于99999
不得 0X、0.X. 、.X
2，个数
不得先输入0
不得大于999
合规性判断
1，编辑金额时：
无个数{
金额 不得大于20000
}
有个数{
优先判断个数的合规
if(个数不合规){// 个数的优先级要高于金额
提示个数错误
}else{
单个金额 不得大于200 or 小于 0.01 合规性判断针对金额
}
}
2，编辑个数时：
if(个数 <= 100){
无金额{
}else{
// 有金额
单个金额 不得大于200 or 小于 0.01 合规性判断针对金额
}
}else{
// 个数 大于 100
提示个数的 超过100
}
对于合规性判断的处理是比较复杂的，在逻辑没有梳理清楚后会出现很多问题并且不宜维护
于是我设计了另一种报错的策略，保持权重最大的错误：
给每个错误设置权重，保持权重最大的错误，在所有逻辑判断完成后，统一进行提示。
该策略逻辑清晰，最终输出统一，容易控制。
测试代码稍后上传github: 红包封装