兩天內對項目中的紅包展示邏輯及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: 紅包封裝
https://github.com/Huaida/TestFunction_OC

總結

以上是生活随笔為你收集整理的红包功能的开发总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。