复杂界面开发之所思
今天看到 iOS实现多个可变cell复杂界面的制作 这篇文章，大致看了一下源码。感觉没有真的解决问题，而且局限性很大，不能保证动态行高，性能也不是很好。今天结合我们自己的工程，谈谈使用tableView来构建复杂界面的局限性，换句话说，一旦视图足够复杂，我们就应该根据情况不同决定是否使用tableView,或者将固定的部分抽离出来,减少在tableView中的逻辑判断。
置顶：
WechatIMG19.jpeg
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,
};
在控制器中你可能这样做：
WechatIMG16.jpeg
对于复杂的View，你可以用storyboard或者xib进行布局，然后用类来绑定视图，把界面元素都划分为不同的类（利用storyboard、xib和代码），这样容易维护。
下边用项目中真实的例子，看一下究竟怎么做更加合理。
WechatIMG6.jpeg
WechatIMG7.jpeg
WechatIMG8.jpeg
分析界面元素如下：
- 1:顶部为滚动视图，展示产品相关信息。（固定）
- 2:轮次，浏览次数，关注都是固定的。打码的地方也是固定的，可以为一个或者是两个元素。（固定）
- 3:紧接下来的项目定位（不固定）、项目介绍（不固定）、核心竞争力（不固定），团队介绍（不固定）等等都是不确定是否存在的信息。每个点如果超过五行就必须有阅读更多的点击事件，展开相应的更多信息（不固定）。
- 4:更多信息，根据服务端返回的数据，确定是否展示。（不固定）
- 5:相关链接，可有可无。（不固定）
- 6:相似项目，可有可无。（不固定）
如此多的不固定因素，加之行高信息。那么使用tableView作为整体的大结构，显然是不适合的。为什么呢？ 因为行数不确定，行高不确定，内容不确定。这种条件下，如果使用tableView作为整体的大结构，需要做N多的逻辑判断。最后随着版本的迭代很难调整。为以后的产品更迭埋下了大坑。
那么怎么解决这个问题，解决思路的宗旨是：尽量减少逻辑判断。避免更多的耦合。
-
1:固定的视图进行封装，隔离出来。
-
2: 不固定的视图单独处理。设置约束信息等。
-
3:整体采用scrollView作为底视图，在其上进行视图的添加和移除操作。
-
4:鉴于产品还有一个特殊的功能：在向下滚动的时候，顶部的滚动视图是遮盖在- 滚上来视图的下边的，给人一种遮盖的效果。最上边需要固定一个View用于展示。
WechatIMG9.jpeg
这个对XIB 使用约束的要求相对高一点，必须熟练。然后理清楚视图和视图之间的关系之后就可以根据UI规范进行约束的调整了。
最后在config文件中，配置视图的一些信息。比如：
WechatIMG10.jpeg
在我上一家公司中，在订单界面，因为逻辑很复杂，而且需求变更比较频繁，所以也是采用这种方式去解决问题。最后我们需要改动的地方真的很少，除非是大动，否则只需要在xib中重新设置约束就可以了。
WechatIMG11.jpeg
