• 暗黑模式方案

  • 明確需求: 不會(huì)增加除系統(tǒng)暗黑模式外的其他模式
  1. 系統(tǒng)暗黑模式方案:
     • 優(yōu)點(diǎn):
       • 系統(tǒng)Assets資源支持動(dòng)態(tài)色，動(dòng)態(tài)圖史飞，原生支持，代碼侵入性最小
       • 默認(rèn)支持系統(tǒng)更換模式時(shí)已經(jīng)創(chuàng)建的頁(yè)面實(shí)時(shí)刷新效果，不需要銷(xiāo)毀根控制器重新創(chuàng)建
       • Assets創(chuàng)建動(dòng)態(tài)色卫病，動(dòng)態(tài)圖完美支持xib警医，不需要額外適配
     • 缺點(diǎn):
       • 僅支持iOS 13+系統(tǒng)
       • 僅支持日間暗黑兩種模式亿胸，無(wú)法新增其他主題
       • layer層級(jí)需要自己控制刷新粒度
  2. SwiftTheme方案:
     • 優(yōu)點(diǎn):
       • 可以服務(wù)器動(dòng)態(tài)下發(fā)個(gè)性化主題，方便增加除暗黑模式外的其他主題
       • 不受系統(tǒng)版本限制
     • 缺點(diǎn):
       • 系統(tǒng)控件的color预皇，image等相關(guān)屬性全都不能用侈玄，必須全部替換成theme_color，theme_image等擴(kuò)展屬性吟温，才能實(shí)現(xiàn)更換主題時(shí)已經(jīng)創(chuàng)建的頁(yè)面實(shí)時(shí)刷新效果序仙，否則必須銷(xiāo)毀根控制器重新創(chuàng)建
       • xib適配方案有兩種:
         1. 通過(guò)擴(kuò)展給xib擴(kuò)展新屬性設(shè)置color，image等相關(guān)鲁豪，設(shè)置擴(kuò)展屬性時(shí)通過(guò)選中主題設(shè)置對(duì)應(yīng)顏色潘悼，不能直接設(shè)置控件的color，image等原生屬性
         2. 將xib中的控件關(guān)聯(lián)到代碼中呈昔，通過(guò)代碼設(shè)置theme_color挥等，theme_image等擴(kuò)展屬性
       • 代碼侵入性太強(qiáng)
  • 最終方案選擇: 系統(tǒng)暗黑模式方案(需求明確不會(huì)新增除暗黑模式外的其他模式更優(yōu))

• 多語(yǔ)言國(guó)際化方案

  • 明確需求: app內(nèi)提供更換語(yǔ)言功能, 在app內(nèi)更改語(yǔ)言后，已經(jīng)創(chuàng)建的頁(yè)面及時(shí)刷新堤尾，不能銷(xiāo)毀根控制器重新創(chuàng)建肝劲。
  • 難點(diǎn):
    • 跟app關(guān)聯(lián)的語(yǔ)言國(guó)際化，只能通過(guò)代碼控制郭宝，xib怎么國(guó)際化辞槐？
    • 不銷(xiāo)毀根控制器重新創(chuàng)建，已經(jīng)創(chuàng)建的頁(yè)面怎么刷新粘室？如果是每個(gè)頁(yè)面加通知榄檬，那每個(gè)頁(yè)面需要刷新的部分怎么抽取衔统？對(duì)業(yè)務(wù)代碼邏輯影響多大鹿榜？是否有明確規(guī)范，新人接替是否好維護(hù)锦爵？
    • 跟語(yǔ)言關(guān)聯(lián)的有靜態(tài)頁(yè)面控件刷新舱殿，業(yè)務(wù)邏輯刷新(如banner圖上有文字，語(yǔ)言改變后banner圖也需要刷新)
    • 怎么控制刷新粒度险掀，如果棧里的靜態(tài)控件太多沪袭，業(yè)務(wù)邏輯刷新太多，一次性全部刷新是否會(huì)影響性能樟氢？還是分批刷新冈绊？
  1. 切換根控制器方案: 切換語(yǔ)言直接重新創(chuàng)建根控制器
     • 優(yōu)點(diǎn):
       • 邏輯簡(jiǎn)單侠鳄，代碼0浸入
     • 缺點(diǎn):
       • 必須退回根控制器重新加載，不能停留在當(dāng)前頁(yè)面實(shí)時(shí)刷新
  2. 通知方案: 每個(gè)頁(yè)面監(jiān)聽(tīng)語(yǔ)言改變來(lái)刷新需要刷新的控件和邏輯
     • 優(yōu)點(diǎn):
       • 已經(jīng)創(chuàng)建的頁(yè)面能實(shí)時(shí)刷新
     • 缺點(diǎn):
       • 每個(gè)頁(yè)面都需要監(jiān)聽(tīng)通知
       • 語(yǔ)言改變時(shí)所有創(chuàng)建的頁(yè)面控件和邏輯都同時(shí)刷新死宣，會(huì)影響一定性能
       • 寫(xiě)業(yè)務(wù)代碼需要關(guān)心哪些控件需要刷新伟恶，剝離出來(lái)刷新，不太友好
  3. i18n自定義方案: 向每個(gè)控件注入一段block,語(yǔ)言改變時(shí)調(diào)用十电，也可以在改變時(shí)做標(biāo)記知押，在頁(yè)面將要出現(xiàn)的時(shí)刷新
     • 優(yōu)點(diǎn):
       • 已經(jīng)創(chuàng)建的頁(yè)面能實(shí)時(shí)刷新
       • 寫(xiě)業(yè)務(wù)代碼不需要關(guān)心哪些控件需要刷新
       • 靜態(tài)控件統(tǒng)一規(guī)范，統(tǒng)一寫(xiě)法鹃骂，業(yè)務(wù)邏輯刷新單獨(dú)控制
     • 缺點(diǎn):
       • 代碼中設(shè)置text台盯，title，attributedText等文本的地方都需要加前綴.i18n.text來(lái)設(shè)置畏线，浸入性較大
  4. 觸發(fā)生命周期函數(shù): 語(yǔ)言改變時(shí)將當(dāng)前棧里的控制器銷(xiāo)毀并替換新的,讓控制器重新走生命周期函數(shù)
     • 優(yōu)點(diǎn):
       • 已經(jīng)創(chuàng)建的頁(yè)面能實(shí)時(shí)刷新
       • 邏輯簡(jiǎn)單静盅，代碼0浸入
     • 缺點(diǎn):
       • 需要明確當(dāng)前棧結(jié)構(gòu)，遍歷移除舊的寝殴，創(chuàng)建新的替換蒿叠，需要明確創(chuàng)建新控制器依賴(lài)的參數(shù)，絕對(duì)不能更改棧層級(jí)結(jié)構(gòu)和控制器類(lèi)型蚣常，
       • 如果每個(gè)控制器的子控制器太多市咽，怎么處理？如果子控制器也重新創(chuàng)建抵蚊，那么子控制器布局呢施绎？
       • 沒(méi)有好的思路明確上述依賴(lài)
  • 最終方案選擇: i18n自定義方案

• 資源管理方案(R.swift)

  • 優(yōu)點(diǎn):
    • 解決圖片名稱(chēng)，國(guó)際化key贞绳，字體名稱(chēng)等字符串硬編碼問(wèn)題谷醉，轉(zhuǎn)成強(qiáng)類(lèi)型方便排錯(cuò)，方便寫(xiě)代碼聯(lián)想
  • 缺點(diǎn):
    • 為了保持統(tǒng)一性冈闭，都在R結(jié)構(gòu)體文件中生成對(duì)應(yīng)字符串映射的值俱尼，導(dǎo)致R文件過(guò)大，打開(kāi)反應(yīng)遲鈍

• 模塊解耦方案

  • 明確需求: 后續(xù)進(jìn)行組件化

  1. 路由方案(URLNavigator):

     • 優(yōu)點(diǎn):

       • 極高的動(dòng)態(tài)性萎攒，適合h5跳轉(zhuǎn)
       • 方便地統(tǒng)一管理多平臺(tái)的路由規(guī)則
       • 易于適配 URL Scheme
       • 因?yàn)槁酚杀泶嬖谟霭耍Y(jié)構(gòu)清晰

     • 缺點(diǎn):

       • 傳參方式有限，無(wú)法利用編譯器進(jìn)行參數(shù)類(lèi)型檢查耍休，所有的參數(shù)都只能從字符串中轉(zhuǎn)換而來(lái)
       • 依賴(lài)于字符串硬編碼刃永，難以管理
       • url 的"注冊(cè)"、"使用"必須用相同的字符規(guī)則

  2. Target-Action方案(CTMediator): 利用分類(lèi)為路由工具添加新接口羹应，在接口中通過(guò)字符串獲取對(duì)應(yīng)的類(lèi)，再用runtime創(chuàng)建實(shí)例次屠，動(dòng)態(tài)調(diào)用實(shí)例的方法

     • 優(yōu)點(diǎn):
       • 利用分類(lèi)可以明確聲明接口园匹，進(jìn)行編譯檢查
       • 實(shí)現(xiàn)方式輕量
     • 缺點(diǎn):
       • 需要在 mediator 和 target 中重新添加每一個(gè)接口雳刺，模塊化時(shí)代碼較為繁瑣
       • 在分類(lèi)中仍然引入了字符串硬編碼，內(nèi)部使用字典傳參裸违，一定程度上也存在和 URL 路由相同的問(wèn)題
       • 無(wú)法保證所使用的模塊一定存在掖桦，target 模塊在修改后，使用者只有在運(yùn)行時(shí)才能發(fā)現(xiàn)錯(cuò)誤
       • 過(guò)于依賴(lài) runtime 特性供汛， 在 Swift 中擴(kuò)展 mediator 時(shí)枪汪，無(wú)法使用純 Swift 類(lèi)型的參數(shù)
       • 創(chuàng)建過(guò)多的 target 類(lèi)

  3. protocol 匹配方案(BeeHive): 將 protocol 和對(duì)應(yīng)的類(lèi)進(jìn)行字典匹配，之后就可以用 protocol 獲取 class怔昨，再動(dòng)態(tài)創(chuàng)建實(shí)例

     • 優(yōu)點(diǎn):

       • 利用接口調(diào)用雀久，實(shí)現(xiàn)了參數(shù)傳遞時(shí)的類(lèi)型安全
       • 直接使用模塊的 protocol 接口，無(wú)需再重復(fù)封裝

     • 缺點(diǎn):

       • 由框架來(lái)創(chuàng)建所有對(duì)象趁舀，創(chuàng)建方式有限赖捌，例如不支持外部傳入?yún)?shù)，再調(diào)用自定義初始化方法
       • 用 OC runtime 創(chuàng)建對(duì)象矮烹，不支持 Swift
       • 只做了 protocol 和 class 的匹配越庇，不支持更復(fù)雜的創(chuàng)建方式和依賴(lài)注入
       • 無(wú)法保證所使用的 protocol 一定存在對(duì)應(yīng)的模塊，也無(wú)法直接判斷某個(gè) protocol 是否能用于獲取模塊
  • 最終方案選擇: 路由(URLNavigator)方案

• 空頁(yè)面占位視圖方案

  • 明確需求: 空數(shù)據(jù)奉狈，頁(yè)面加載失敗默認(rèn)展示占位視圖
  1. DNZEmptyDataSet:
     • 優(yōu)點(diǎn):
       • tableView卤唉，collectionView自動(dòng)顯示隱藏
     • 缺點(diǎn):
       • 不支持普通view
       • 不能覆蓋父視圖，如果父視圖有其他控件仁期，需要單獨(dú)隱藏
       • 網(wǎng)絡(luò)加載失敗時(shí)不能顯示
  2. 自定義YLEmptyDataSet:
     • 優(yōu)點(diǎn):
       • 支持普通view, 覆蓋父視圖, 不需要對(duì)父視圖的其他控件進(jìn)行單獨(dú)隱藏
       • tableView桑驱，collectionView自動(dòng)顯示隱藏 - 提供網(wǎng)絡(luò)加載失敗默認(rèn)視圖
       • 缺點(diǎn):
         - 加到普通view上必須手動(dòng)隱藏
  • 最終方案選擇: 自定義YLEmptyDataSet

• 狀態(tài)管理方案

  • ReactorKit

• 網(wǎng)絡(luò)層方案

  • Moya/RxSwift + HandJson

• App緩存方案

  • 基于緩存庫(kù)再次封裝Cache

• Loading+Toast方案

  • 自定義HUD

• 代碼格式化

SwiftLint （程序靜態(tài)分析）方案
安裝：可以使用homebrew進(jìn)行全局安裝:
需要在已經(jīng)安裝了homebrew 前提下:
打開(kāi)終端輸入: brew install SwiftLint