? ? ? ?隨著產(chǎn)品的不斷迭代，功能的不斷完善诞仓，我們的項目的中會給用戶分成區(qū)域呈現(xiàn)出越來越多的東西缤苫。咕咚的精選給用戶一種信息廣場的概念，讓用戶可以快速的抵達我們感興趣的點墅拭。既然如此活玲，那么每一個項目的綜合信息的頁面經(jīng)常會被改動。出現(xiàn)位置的調(diào)整帜矾，出現(xiàn)新的模塊的增加翼虫，出現(xiàn)模塊的刪減等等。那么我們就一定要思考我們該如何構建我們這一部分的代碼屡萤，在一次次的更改后可以用最短的時間完成產(chǎn)品的需求珍剑。最大限度的提高我們的工作效率。
下面我們通過咕咚的精選頁面來思考一下具體的實現(xiàn)思路
我們看到這個圖片的時候先思考一個問題死陆，這么多個分區(qū)到底有多少請求接口招拙？ 有小伙伴可能說這不是一個接口完成的么？ 然后變成一個很復雜的json返回給客戶端措译，然后在慢慢的做解析别凤，我想這樣的做法，這個界面每一次更改服務端和客戶端都要經(jīng)歷一次代碼的拆分领虹，要改很多的東西规哪，這對于兩端的開發(fā)人員一定是不友好的，我也順手用charles抓了咕咚的包塌衰，驗證了我的想法诉稍，他們這個界面確實是多個接口組成的。那多個接口能給我們帶來什么好處呢最疆？
現(xiàn)在請大家思考一下杯巨，如果產(chǎn)品會在下個版本中添加一個模塊，調(diào)整兩個模塊之間的順序努酸，之后還會刪減部分模塊服爷，甚至出現(xiàn)改變多個分區(qū)的順序的情況的更改？我們?nèi)绾巫鲂薷牟拍茏畲蠡臏p少我們的代碼邏輯呢获诈，減少我們的工作量呢仍源？
我們的項目最近在做相似模塊的重構，我的tableview界面現(xiàn)在每一個分區(qū)的位置完全可以根據(jù)運營的數(shù)據(jù)在服務端進行動態(tài)的調(diào)整位置舔涎，可以根據(jù)運營的數(shù)據(jù)镜会，在不改變客戶端的代碼的情況下動態(tài)的去刪除一些模塊。這又是如何完成的呢终抽？
這里我做的一件事就是動態(tài)的綁定 戳表，我給每一分區(qū)的數(shù)據(jù)整體添加一個固定的identifier此外服務器返回給我一個數(shù)據(jù)塊的排序桶至，我通過這兩點生成我tableview的數(shù)據(jù)源即可。下面是部分實現(xiàn)代碼 匾旭，最近我也會寫一個小demo放在github上分享給大家镣屹，一起高效的完成我們的工作。
首先是請求代碼价涝，當然只是偽代碼女蜈，希望大家主要去了解一種解決方案和思路。使用dispatch_group并發(fā)多個請求 在所有請求完成之后完成界面對應的刷新的工作色瘩。
將每一個部分看成一個請求即可伪窖，我們會把每一個模塊的請求結果緩存在本地，下一次請求的時候如果此時數(shù)據(jù)請求失敗居兆，會從本地讀取上一次的數(shù)據(jù)覆山。然后我用偽代碼來寫一下我和服務器之間約定的返回的基本形式
每一個請求服務器在返回的數(shù)據(jù)格式中都會告訴我這三個數(shù)據(jù)。這三個數(shù)據(jù)就為我模塊順序調(diào)整和動態(tài)刪除的關鍵泥栖。這個時候我就先使用適配器模式給每一個返回書籍模型添加固定屬性identifer簇宽，因為請求數(shù)較小我就用了快排的方式將返回的數(shù)據(jù)轉(zhuǎn)換成數(shù)據(jù)模型后根據(jù)sort和isUser兩個維度創(chuàng)建了我tableview的數(shù)據(jù)源。
這樣在tableView中我們看到的形式就變成了下圖的樣子 我們完全可以根據(jù)identifier動態(tài)的去部署我們的每一cell 同理可以設置高度等相關的內(nèi)容 吧享，這個大致思路就是如此魏割，最近會寫一個小demo，有這個整體一些的代碼钢颂。
