UIScrollView里面嵌套UITableView这种结构是否合理?
类似网易新闻和lofter这种多标签滚动切换的效果,我以为是在scrollview上添加tableview来实现的, 但这样实现感觉会导致ViewController臃肿不堪, 实现delegate和datasource也比较混乱;想听听大家对于架构这种界面有什么样的建议,能提高代码的复用还有把代码剥离放到合适的地方;真的好想写出结构清晰美观的代码啊思密达!
回答：
每个标签对应的列表可以是一个viewController，它负责这个列表的内容和一切的交互。scrollView里装的是viewController.view。
scrollView所在的viewController可以称之为containerViewController，实际上起到了NavigationController之类的容器作用。而具体的内容，可以称之为contentViewController。
它的好处：
- 同一个contentVC可以在不同的容器中自由地拆下和装上，降低耦合，或者如题主所说“能提高代码的复用还有把代码剥离放到合适的地方”
- 可以做到动态地调整contentVC的数量，样式也可以各不相同，只要是vc即可，题主图中的网易新闻无疑是这么做的佼佼者
- 可以通过“两块木板过河”这样的原理，使用三个view来作为contentVC和scrollView的中间层，做到不论有多少个contentVC(比如网易新闻中添加很多标签)，同时加载在scrollView上的都只有3个
- 肯定还有，我一时没想到。。。
总的来说，这种结构可以称得上“清晰美观”，但也要看实现者的水准，做得不好反而会带来很多问题，做得好的。。。你看网易新闻多好用:)
回答：
首先你要知道，UITableView本来就从UIScrollView继承过来的。
所以你这样的思路一开始就不太正确噢。
系统可能会因为有两个UIScrollView而造成一些unexpected behaviors。
实现的话可以直接利用UIScrollView然后嵌套一个很多的画布。
又或者直接用UITableView。
具体的话要看需求咯。
回答：
又遇到小鱼哥啦，不过这次咱俩想法是基本一致的。（基本。。
针对你的提问回复一下：
类似网易新闻和lofter这种多标签滚动切换的效果,我以为是在scrollview上添加tableview来实现的,
是的，确实一般都是这么实现的，ScrollView的ContentSize的宽度为TableView的宽度乘以数目，然后通过Page分页进行切换。
但这样实现感觉会导致ViewController臃肿不堪, 实现delegate和datasource也比较混乱;
不会臃肿的，我又要传送了。。。更轻量级的VC这个介绍了一些VC瘦身的方法，后面的文章讲了关于把DataSource和Delegate抽离的思路。这个控件是我们UI库的一部分，容器是ScrollView，然后控制器是一个director类，专门负责委托方法，比如tableview的datasource什么的，而且和数据层无缝衔接之后代码量很少的，对于单个cell的简单情况，可以直接用基类。不过每个人的想法不一样，实现的思路也不同，多个VC也是一个解决方案。
想听听大家对于架构这种界面有什么样的建议,能提高代码的复用还有把代码剥离放到合适的地方;
我觉得如果设计的好，代码复用不是问题。不过这种设计本身个人感觉不是iOS的Style。。。有种从安卓飘过来的感觉。个人想法。
真的好想写出结构清晰美观的代码啊思密达!
那就写吧！可以上github看看别人写的代码，好的代码带来的提升很快的~
然后 @LucasHuang 一下，UITableView本来就从UIScrollView继承这个没错，多个UIScrollView混用容易出问题也是没错，但是嵌套并不一定会矛盾，横滑切换tab，竖滑浏览内容。
个人观点，如有理解错误还望指正。
回答：
uipageviewcontroller
回答：
我觉得你们反倒可以参考下Android上的viewpager组件的实现原理，和nsfish讲的很类似。
回答：
我上次做的这个别人是用pickviewcontroller实现的，原理我也不是很懂，但我觉得也可以用uicolltionview嵌套tableview这样的话创建的tableview始终只有两个，多余的都在内存池里面，cootionview大小就tableview大小，上部当时还有那种滑动的，我日现在想想上面也用个colltionview两个colltionview关联就蛮好
以上是 UIScrollView里面嵌套UITableView这种结构是否合理? 的全部内容， 来源链接： utcz.com/p/187455.html
