今天看到 iOS實現多個可變cell復雜界面的制作 這篇文章，大致看了一下源碼。感覺沒有真的解決問題，而且局限性很大，不能保證動態行高，性能也不是很好。今天結合我們自己的工程，談談使用tableView來構建復雜界面的局限性，換句話說，一旦視圖足夠復雜，我們就應該根據情況不同決定是否使用tableView,或者將固定的部分抽離出來,減少在tableView中的邏輯判斷。
置頂：
1> 如何隱藏顯示的視圖？
// 因為你不知道是一個button，還是什么，所以傳入id使用id類型，避免警告??
- (void)hiddenView:(id)view constant:(NSLayoutConstraint)viewConstant{
viewConstant.constant = 0.0f;
view.hidden = YES;
}
2>五行文本如何展開和隱藏？
推薦一個第三方庫 TLAttributedLabel。注意： 該庫有很多內存泄漏的問題，請使用的同志自行修正。
3>類似iOS實現多個可變cell復雜界面的制作 博主這樣的，既然都是行高，也不用動態計算的，我建議這樣用：
如果界面有很多都是可以固定下來的。你比如說商品的圖片，商品的名稱，商品價格，商品是否減價等等信息。為何不單獨出來成為一個視圖。那就不需要加入到tableView的邏輯判斷里了。剩下就是評論了，評論可以單獨用tableView來處理，
為何不用枚舉，在創建之初，就對數據進行處理，確定總共需加載的類型，最后就確定可能要加載cell的類型。對數據提早進行處理，能讓開發人員在后期處理越舒服。 前期你做的越多，后期越好判斷。無非是組合判斷。
typedef NS_ENUM(NSInteger, NIMKitTeamCardRowItemType) {
TeamCardRowItemTypeCommon,
TeamCardRowItemTypeTeamMember,
TeamCardRowItemTypeRedButton,
TeamCardRowItemTypeBlueButton,
TeamCardRowItemTypeSwitch,
};
在控制器中你可能這樣做：
對于復雜的View，你可以用storyboard或者xib進行布局，然后用類來綁定視圖，把界面元素都劃分為不同的類（利用storyboard、xib和代碼），這樣容易維護。
下邊用項目中真實的例子，看一下究竟怎么做更加合理。
分析界面元素如下：
- 1:頂部為滾動視圖，展示產品相關信息。（固定）
- 2:輪次，瀏覽次數，關注都是固定的。打碼的地方也是固定的，可以為一個或者是兩個元素。（固定）
- 3:緊接下來的項目定位（不固定）、項目介紹（不固定）、核心競爭力（不固定），團隊介紹（不固定）等等都是不確定是否存在的信息。每個點如果超過五行就必須有閱讀更多的點擊事件，展開相應的更多信息（不固定）。
- 4:更多信息，根據服務端返回的數據，確定是否展示。（不固定）
- 5:相關鏈接，可有可無。（不固定）
- 6:相似項目，可有可無。（不固定）
如此多的不固定因素，加之行高信息。那么使用tableView作為整體的大結構，顯然是不適合的。為什么呢？ 因為行數不確定，行高不確定，內容不確定。這種條件下，如果使用tableView作為整體的大結構，需要做N多的邏輯判斷。最后隨著版本的迭代很難調整。為以后的產品更迭埋下了大坑。
那么怎么解決這個問題，解決思路的宗旨是：盡量減少邏輯判斷。避免更多的耦合。
1:固定的視圖進行封裝，隔離出來。
2: 不固定的視圖單獨處理。設置約束信息等。
3:整體采用scrollView作為底視圖，在其上進行視圖的添加和移除操作。
4:鑒于產品還有一個特殊的功能：在向下滾動的時候，頂部的滾動視圖是遮蓋在- 滾上來視圖的下邊的，給人一種遮蓋的效果。最上邊需要固定一個View用于展示。
這個對XIB 使用約束的要求相對高一點，必須熟練。然后理清楚視圖和視圖之間的關系之后就可以根據UI規范進行約束的調整了。
最后在config文件中，配置視圖的一些信息。比如：
在我上一家公司中，在訂單界面，因為邏輯很復雜，而且需求變更比較頻繁，所以也是采用這種方式去解決問題。最后我們需要改動的地方真的很少，除非是大動，否則只需要在xib中重新設置約束就可以了。
