今天看啥 热点：
storyboard和xib之间功能比较差异1、如果是xib，则可以用initNibName绑定。& & &数据传递，可以直接自动一个protocol－delegate，不同界面之间实现数据传递。2、如果是storybord，则需要用［segue identifier］确定所跳转的下一个界面。& & 数据传递，需要用 performSegueWithIdentifier 和 perpareSegueWithIdentifier结合实现，来进行数据的传递。3、ipad和iphone的切换视图有所不同。xcode5中storyboard与之前的xib差别与联系？storyboard 是xib的集合 &一个storyboard可以是一个项目，可以再storyboard中一个个的创建对应UIViewController的一个xib，以及他们之间的一个走向。??在ios开发中使用2者要如何选择和注意事项??storyboard??是一种趋势，??因为它的功能更强大，可以同时管理几个scene和segue,可以很方便地实现界面之间的切换。做应用来说，storyboard相当方便，网上教程也有不少，而且比较好理解，可以完全不用看IB。??????假如多人共同开发一个应用，是不是还是得采用以前的xib方式??会比较好一点。
如果对人开发，用以前的方式是比较好，因为storyboard是一个文件，同时改起来难免会出现一些问题。??& ??&界面代码写还是xib还是storyboard代码最直观 好管理 但是个个view之间的关系看起来没有那么直观 xib用的不多 试图之间的关系没有storyboard直观 管理上也要比代码容易管理storyboard 试图间关系一目了然 ， 各个controller之间的关系也可以看的很明白 个人比较喜欢 当然和xib一样 试图的各种属性不够明显 改错时比较抓狂.更多storyboard和xib知识拓展：代码手写UI，xib和StoryBoard间的博弈
&最近接触了几个刚入门的iOS学习者，他们之中存在一个普遍和困惑和疑问，就是应该如何制作UI界面。iOS应用是非常重视用户体验的，可以说绝大多数的应用成功与否与交互设计以及UI是否漂亮易用有着非常大的关系。而随着iOS开发发展至今，可以说在UI制作上大家逐渐分化为了三种主要流派：使用代码手写UI及布局；使用单个xib文件组织viewController或者view；使用StoryBoard来通过单个或很少的几个（关于这点稍后会进行展开）文件构建全部UI。应该使用哪种方式来制作UI已经是iOS开发中亘古不变的争论话题了，或许永远不会有一个统一的结论。但是首先需要知道的是三种方式各有优劣，所以也各有自己最适用的场合，而不会有完全的孰优孰劣。对于初学iOS开发来说，一时间其实是很难判定最适合自己的UI架构方式的。在这篇文章里我希望能够通过自己的经验给出一些意见，以期能帮助入门者来挑选最适合自己应用场景的方案。对于老鸟的话，也不妨对照自己平日的使用习惯和运用场景，看看有没有可以改进或变化的地方。最后，因为我本人现在最习惯和喜欢的是用Interface Builder(之后简称IB)及xib来做UI，所以文末附上了一些IB使用时候的小技巧，算是做个总结。&代码手写UI这种方法经常被学院派的极客或者依赖多人合作的大型项目大规模使用。Geek们喜欢用代码构建UI，是因为代码是键盘敲出来的，这样可以做到不开IB，手不离开键盘就完成工作，可以专注于编码环境，看起来很cool很高效，而且不到运行时大家都不知道会是什么样子，也显出了程序员这一职业的高大上及神秘气息（这个真的不是在黑..想想大家一起在设计师背后指点江山的场景吧）。大型多人合作项目使用代码构建UI，主要是看中纯代码在版本管理时的优势，检查追踪改动以及进行代码合并相对容易一些。&另外，代码UI可以说具有最好的代码重用性。如果你的目的是写一些可以高度重用的控件提供给其他开发者使用，那毫无疑问最好的选择应该是使用代码来完成UIView的子类。这样进一步的修改和其他开发者在使用时，都会方便不少。使用代码也是最为强大的，会有xib或者StoryBoard做不了的事情，但是使用代码最终一定能够完成所要的需求。&但是代码手写UI的劣势同时也是最明显的，主要就是一个字：慢。首先相比可视化的IB来说，完成一个并不太复杂的界面，你可能需要写上数百行的UI代码。不论是初始化一个Label，还是设定一个frame或者添加一个target-action，都需要写代码，这不仅在前期极为浪费时间，在之后维护时代码定位和寻找也会很痛苦。其次，因为你无法直观地看到你能得到的结果，所以你很可能需要不断地Cmd+R/Cmd+.来修改各个视图的位置大小。即使你用上了Reveal或者RestartLessOften之类的工具，也还是无法特别方便地完成需要的布局。另外加上如果需要利用AutoLayout来进行尺寸适配的话，使用代码进行约束就更加头疼了。很多时候一个无法满足的约束的问题就够来回运行修改调试很长时间了。&Xibs相对于代码，使用IB和xib文件来组织UI，可以省下大量代码和时间，从而得到更快的开发速度。如果你曾经受到过微软家Visual Basic或者其他Visual系的可视化界面的荼毒与残害，因此怀疑Interface Builder的纯正血统和工作能力，。另外，不妨打开你的Mac上的Application文件夹中或者iPhone上Apple家的各种应用。你会惊奇地发现，IB远比你看到的要强大：小至计算器取色器这类小工具，大至iWork三件套，Aperture或Final Cut这样的专业级应用，无一不是使用IB来完成UI制作的。&其实IB和xib是从iOS SDK初次面世开始就是捆绑在开发者工具套装内的内容了，而到了Xcode 4之后更被直接集成到了Xcode中成为了IDE的一部分。xib设计的一大目的其实是为了良好的MVC：一般来说，单个的xib文件对应一个ViewController，而对于一些自定义的view，往往也会使用单个xib并从main bundle进行加载的方式来载入。IB帮助完成view的创建，布局和与file owner的关系映射等一些列工作。对于初学者来说，牢记xib的文件都是view的内容，有助于建立起较好的MVC的概念，从而在开发中避免或少走弯路。&xib文件之前一大被诟病的问题是文件内容过于复杂，可读性很差，即使只是简单打开没有编辑也有可能造成变化而导致合并和提交的苦难。在Xcode 5中Apple大幅简化了xib文件的格式，使其变得易读易维护。可以说现在对于xib文件在版本管理上其实和纯代码已经没有太大差异，只要仔细看过一遍xib的文件内容，自然能理解绝大部分，并很好地追踪并查找过往的修改记录了。&当然xib也不是完美的。最大的问题在于xib中的设置往往并非最终设置，在代码中你将有机会覆盖你在xib文件中进行的UI设计。在不同的地方对同一个属性进行设置，这在之后的维护中将会是噩梦般的存在。因为其实IB还是有所局限的，它没有逻辑判断，也很难在运行时进行配置，而反之使用代码确是无所不能的。在使用xib时，辅以部分代码来补充和完成功能几乎是不可避免的。关于这点在开发时应该予以高度重视，如果选择xib，那么要尽量将xib的工作和代码的工作隔离开来：能够使用xib完成的内容就统一使用xib来做，而不要说三个Label其中两个在xib设置了字体而另一个却在代码中完成。尽量仅保持必要的、较少的IBOutlet和IBAction会是一个好方法。&StoryBoardiOS5之后Apple提供了一种全新的方式来制作UI，那就是StoryBoard。简单理解来说，可以把StoryBoard看做是一组viewController对应的xib，以及它们之间的转换方式的集合。在StoryBoard中不仅可以看到每个ViewController的布局样式，也可以明确地知道各个ViewController之间的转换关系。相对于单个的xib，其代码需求更少，也由于集合了各个xib，使得对于界面的理解和修改的速度也得到了更大提升。减少代码量就是减少bug量，这也是程序开发中的真理之一。&在Xcode5之后，StoryBoard已经成为新建项目的默认配置，这也代表了Apple对开发者的建议和未来的方向。WWDC2013的各个Sample Code中也基本都使用了StoryBoard来进行演示。可以预见到，之后Apple必定会在这方面进行继续强化，而反之纯代码或者单个xib的方式很可能不会再得到增强。&如果不考虑iOS版本的支持（其实说实话现在已经很少还见到要从iOS4开始支持的app了吧），现在StoryBoard面临的最大问题就是多人协作。因为所有的UI都定义在一个文件中，因此很多开发者个人或企业的技术负责人认为StoryBoard是无法进行协作开发的，其实这更多的是一种对StoryBoard的陌生所造成的误解。虽然Apple并没有在WWDC明确提及，但是没有人规定整个项目只能有一个StoryBoard文件。一种可行的做法是将项目的不同部分分解成若干个StoryBoard，并安排开发人员对自己的部分进行负责。简单举例比如一个有4个tab功能相互独立的基于UITabBarViewController的应用，完全可以使用4个StoryBoard来分别代表4个tab，并在相互无干扰的情况下完成开发。这样一来就不会存在所谓的冲突问题了。StoryBoard的API是如此简单，现在的SDK中一共方法数量一只手就能数过来，所以具体方法在这里就不再罗嗦了。&StoryBoard的另外的挑战来源于ViewController的重用和自定义的view的处理。对于前者，在正确封装接口以及良好设计的基础上，其实StoryBoard的VC重用与代码的VC重用是没有本质区别的，在StoryBoard中添加封装良好需要重用的Scene即可解决。而对于后者，因为StoryBoard中已经不允许有单个view的存在，因此很多时候我们还是需要借助于单个的xib来自定义UI。这一点可以说是由于StoryBoard的设计思路所造成的，StoryBoard更强调的是一种层次结构，是在全局的视角上来组织UI设计和迁移。而对于单个的view，更多的会注重于重用和定制，而与整个项目的流程没有太大关系。相信抓住这一要点，就能很好地了解什么时候使用xib，什么时候使用StoryBoard。&关于StoryBoard最后要说的是，现在会有一些对于StoryBoard性能上的担忧。因为相对于单个xib来说，StoryBoard文件往往更大，加载速度也相应变慢。但是其实随着现在设备的更新换代，在iPhone4都难觅的今天，这点性能上的差距几乎可以忽略了。而再之后的设备，不论读取还是解析，只会越来越快。所以性能上的问题完全是没有担心的必要的。&我的观点和选择我入门的时候是使用xib的，因为那时候还没有StoryBoard，而我也不是喜欢代码的学院派Geek。到现在，三种方式我都有尝试过，并分别得到了一些可能还并不是特别深刻体会。对于现在的我来说，xib是我的奶酪，也是我在自己的一些项目里一直使用的方式，我可以在极短短时间内用xib架起一套包括自定义要素和良好部件重用性复杂UI。但是在我尝试了几次使用StoryBoard制作demo之后，我已经决定在之后的项目转向使用StoryBoard。一方面因为确实是未来方向（每次新工程删StoryBoard很讨厌..），现在的StoryBoard专有的preview功能，以及之后AutoLayout的进一步改进等都很值得期待；另一方面也觉得奶酪放一个地方太久了会不好，趁着iOS7的大变革，也更新一下自己的观念和方式，把奶酪换个地方摆摆，也许会对以后大有裨益。&对于初心者来说，我并不建议上手就直接使用代码来进行UI制作和布局，因为冗长的UI代码确实非常乏味无趣。尽快看到成品，至少尽快看到原型，是保持兴趣，继续深入和从事职业的有效动力。所以如果有可能有条件，在老鸟的指导下选择StoryBoard来进行快速构建（或者如果是单个人开发的话，可以不用考虑多个StoryBoard协作，就更容易），会是入门的好选择。而最新的教程和文档已经开始逐渐偏向StoryBoard，关于StoryBoard的问题在SO上关注度也会更高，这样在入门时会有更多的资料可以进行参考。&这并不是说不需要关心代码UI或者xib，因为使用StoryBoard的时候在只能使用代码以及自定义单个view时，还是不可避免地需要接触它们的。这里想给的一点建议就是，虽然你不依赖代码来进行UI制作，但是了解并掌握如何使用纯代码来从头构建UI还是非常必要的：包括从新建Window开始，到初始化ViewController，添加必要的view，设定它们的property，以及添加和处理它们的各种响应及responser链等内容。现在iOS开发入门非常容易，Xcode和xib/StoryBoard帮助开发者隐藏了太多的细节，但是很多时候如果你不明白underhood到底是些什么，为什么这些xib/StoryBoard会这样运作的话，经常会出现卡在一些很可笑的和初级的bug上找不着北，这其实会是对时间的巨大浪费，很不值得。&一些IB小技巧最后分享一些IB使用上的小技巧作为结束吧。其中很多方法也可以用在StoryBoard上，所以在向我自己之前xib使用者生涯致敬的同时，也算是一点小的备忘总结吧。&同时添加多个outlet在IB中，选中一个view并右键点击，将会出现灰色的HUD，可以在其上方便地拖拉或设定事件和outlet。你可以同时打开多个这样的面板来一次性添加所有outlet。右键点击面板，随便拖动一下面板，然后再打开另一个。你会发现前一个面板也留下来了，这样你就可以方便地进行拖拽设定了。&多个Outlet HUD当然，对于成组和行为类似的IBOutlet，应该直接使用IBOutletCollection来进行处理会更方便。&可视化坐标距离IB最烦人的问题就是对其。用代码的时候我们可以明确地指定x,y坐标，但是换到IB的时候我们更多的时候是靠拖拽UIView来布局。比如需要三个间隔相同的label，除了用强大的肉眼来估测距离是否相等以外，难道只能乖乖分别选中三个label，记下它们的坐标然后打开计算器来做加减法么？&显然不要那么笨，试试看选中一个label，然后按住option键并将鼠标移动到其他label上试试？你可以发现view之间的距离都以很容易理解的方式显示出来了。不仅是同层次的view，被选中view与其他层次的view之间的距离关系也可以同样显示。&&显示View之间的距离在一组view层次中进行选择对于一些复杂的view层级关系，我们往往直接在IB中选择会比较困难。比如view相互覆盖时，我们很难甚至不能在编辑视图中选中底层的view。这时候一般的做法是打开左侧的view层级面板，一层层展开然后选择自己需要的view。其实我们也有更简单的方法：按住Cmd和Shift，然后在需要选择的view上方按右键，就可以列出在点击位置上所有的view的列表。藉此就可以方便快速地选中想要的view了。&在编辑视图中选则底层view添加辅助线这么高大上的技巧必须放在最后啊…在左边的层级列表中双击某个view，然后Cmd+_或者Cmd+|即可在选中的view上添加一条水平或者垂直中心的辅助线。当然这个辅助线是可以随意移动的。如果干过设计的同学肯定明白这个的意义了，在之后的对其和设计变更的时候都有重要的参考价值。&为IB添加辅助线来源：
暂无相关文章
相关搜索：
相关阅读：
解决方案最近更新StoryBoard+AutoLayout实战开发小技艺 - 移动开发当前位置:& &&&StoryBoard+AutoLayout实战开发小技艺StoryBoard+AutoLayout实战开发小技艺&&网友分享于：&&浏览：0次StoryBoard+AutoLayout实战开发小技巧& 使用xib、storybard、纯代码开发项目，这三种方法本人都尝试过。纯代码格式写的好，非常容易读、理解。合作开发也确实比storyboard方便，不需要像xib、storyboard那样经常切换几个界面，经常为了一个属性连线而报错，或者连线错误，纯代码编写易控制，易读。xib一般都是与代码混合编写，多用于自定义单元格之类的视图。使用storyboard整个应用流程，结构显得非常清楚，开发迅捷，但是自定义视图不是特别方便，比如自定义一个遮罩HUD视图。storyboard开发非常快，特别配合sizeclass、autolayout来适配6.0、7.0、8.0各种系统版本，4、5、6、6p各种屏幕尺寸非常之简单。强烈推荐使用storyboard+autolayout来开发，苹果的意愿也是如此。这里说一些storyboard和autolayout上的一些使用小技巧，也是对我前面部分工作的总结吧。
一、storyboard上的小技巧：
1、同时添加多个outlet
在IB中，选中一个view并右键点击，将会出现灰色的HUD，可以在其上方便地拖拉或设定事件和outlet。你可以同时打开多个这样的面板来一 次性添加所有outlet。右键点击面板，随便拖动一下面板，然后再打开另一个。你会发现前一个面板也留下来了，这样你就可以方便地进行拖拽设定了。
2、多个Outlet HUD&
当然，对于成组和行为类似的IBOutlet，应该直接使用IBOutletCollection来进行处理会更方便。
3、option键的妙用
（1）、可视化坐标距离
选中一个label，然后按住option键并将鼠标移动到其他label上试试？你可以发现view之间的距离都以很容易理解的方式显示出来了。不仅是同层次的view，被选中view与其他层次的view之间的距离关系也可以同样显示。
（2）、控件复制
选中一个label，然后按住option键，并用鼠标按住它拖动到另一个位置，结果有了两label，新的label和原来label属性相同，比cmd+c、cmd+v好用吧。
4、添加辅助线
双击某个view，然后Cmd+Shift+-或者Cmd+Shift+|即可在选中的view上添加一条水平或者垂直中心的辅助线。当然这个辅助线是可以随意移动的。如果干过设计的同学肯定明白这个的意义了，在之后的对其和设计变更的时候都有重要的参考价值。
5.添加自定义视图
如图这样，把它当做xib来处理就行了。不用额外创建xib了，方便实用吧。
6.User Undefined Runtime Attributes妙用
例如在storyboard上设置这类属性，圆角。
keypath写上你想要设置的属性，根据名字就知道它支持访问对象的指定属性的字符串序列，type就是属性的类型，value还支持颜色哦。
7.使view的size与view的content相适应
选中任意的一个view，然后Editor-&Size to Fit Content，或者简单的按
接着就会按照下面的规则对选中view的Size做出与之Content对应的适应：
（1）ImageView/Button的size会设置为图像的原始size(最常见的用法)。
（2）Label/Button的size会被设置为与当前text内容相当的尺寸。
（3）parent container view会与其subviews的frames相适应。
8.Editor-&Embed In View,UnEmbed
你是不是对此素手无策呢：你希望将已有的一些subviews放入到不同的parent view中，甚至是不同的.xib文件中，但是当你把一些view重新设置之后，它们为自动的位于新的parent view中心？
如图所示，你怎么把1-12个数字label保持原有的样子放入到scrollView中呢？
点击选中12个label，再选择editor中的embed in view：
把view拖到scrollview中去，再次点击scrollView的unembed：
OK，大功告成，很Esay是不，赶紧尝试吧。
9.对不在最上面的视图进行位置移动。
一般做法就是先将非最上面的view临时设置到最上面，移动好位置之后，在设置回去。费时费力不讨好。
最简单的方法：
在document
outline上双击view，就可以用箭头移动view了。
10.编辑出界的scrollView、tableview内容。
当scrollView、tableview中控件超出了它们的frame，怎么编辑控件呢？
点击控件，然后滑动滑轮，直到把目标控件给滑动出来。
二、Autolayout上的小技巧：
1.ScrollView上添加约束。
很多人都会遇到这种报错：
这是因为ScrollView的ContentSize没有确定。
contentSize在布局中实际上是scroll view的子view :content view的宽和高实现的。往往对于scrollview中的子view，我 们同样也可以将其放在同一个父的container view中，然后将这个container view作为scrollview的子view也即content view，这样我们对scroll
view 的布局就可以简化为对content view的布局，而content view里面的子view相对于content view的布局就是普通的布局了，剩下的只需要我们解决好scroll view和content view的布局即可。
这时有个奇怪的现象：
ContentView上下距离约束怎么不与其高度约束冲突呢？
原来content view和scroll view的top, bottom, leading和trailing contstraints，这四个约束的使用在scroll view中做了变化：它不再是确定content view尺寸的依据，而是帮助scroll view中content view四周的边界（or你可以理解为留白），进而确定scroll view的contentSize属性。
2.UILabel添加约束
Label只需要添加top, leading约束即可，宽度会根据文字内容多少自动适应。
假若把Label的height再次固定，则高度会自动适应。
比如：银行名称与尾号左对齐，并且尾号一直在名称的底部。这里切记勾选上label的preferred width 。不然iOS8.0以下程序会crash掉。
3.TableViewCell高度自适应
(1)设置好布局约束条件，使得cell子视图的边缘固定(pin)到cell的contentView的边缘（最重要的是要有顶部和底部的边距约束条件），这样cell就能确定自己的高度了。
(2)高度代理协议heightForRowAtIndexPath:千万别实现它。
tableview.rowheight=UITableviewAutomaticD
tableview.estimatedRowheight=44;
(3)设置好正确的preferredMaxLayoutWidth &
[super layoutSubViews];
_contentLbl.preferredMaxLayoutWidth=_contentLbl.frame.size.
&[super layoutSubViews];
4、动画处理
把滑动视图的高度减小，_bgScrollViewHeightLayout定义在这里：
@property (weak,nonatomic) IBOutLet NSLayoutConstraint *bgScrollViewHeightL
[_bgScrollView layoutIfNeeded];
_bgScrollViewHeightLayout.constant=kScreenHeight-64-
[UIView animateWithDuration:duration animations:^{
[_bgScrollView layoutIfNeeded];
5、约束调试：
我们在iOS中遇到不可满足的约束条件，我们只能在输出的日志中看到视图的内存地址。尤其是在更复杂的布局中，有时很难辨别出视图的哪一部分出了问题。然而，在这种情况下，还有几种方法可以帮到我们。
首先，当你在不可满足的约束条件错误信息中看到NSLayoutResizingMaskConstraints时，你肯定忘了为你某一个视图设定translatesAutoResizingMaskIntoConstraints为NO。Interface Builder中会自动设置，但是使用代码时，你需要为所有的视图手动设置。
如果不是很明确那个视图计算问题，你需要通过内存地址来辨认视图。最简单的方法是使用调试控制台。你可以打印视图本身或它父视图的描述，甚至递归描述的树视图。这通常会提示你需要处理哪个视图。
(1)使用po 命令
(2)一个更直观的方法是在控制台修改有问题的视图，这样你可以在屏幕上标注出来。比如，你可以改变它的背景颜色：
&span style=&font-size:12&&(lldb) expr ((UIView *)0x7731880).backgroundColor = [UIColor purpleColor] &/span&
确保重新执行程序后改变不会在屏幕上显示出来。还要注意将内存地址转换为（UIView *），以及额外的圆括号，这样我们就可以使用点操作。另外，你当然也可以通过发送消息：
&span style=&font-size:12&&(lldb) expr [(UIView *)0x7731880 setBackgroundColor:[UIColor purpleColor]] &/span&
(3)另一种方法是使用Instrument的allocation模板，根据图表分析。一旦你从错误消息中得到内存地址（运行Instruments时，你从控制台中获得的错误消息），你可以将Instrument切换到Objects List的详细视图，并且用Cmd-F搜索那个内存地址。这将会为你显示分配视图对象的方法，这通常是一个很好的暗示（至少找到创建视图对象的代码了）。
(4)你也可以在iOS中弄懂不可满足的约束条件错误，这比改善错误消息来的更简单。我们可以在一个category中重写NSLayoutConstraint的描述，并且将视图的tags包含进去：
&span style=&font-size:12&&@implementation NSLayoutConstraint (AutoLayoutDebugging) 
#ifdef DEBUG 
- (NSString *)description 
NSString *description = super. 
    NSString *asciiArtDescription = self.asciiArtD 
    return [description stringByAppendingFormat:@& %@ (%@, %@)&, asciiArtDescription, [self.firstItem tag], [self.secondItem tag]]; 
#endif 
@end &/span&
如果是整数的属性标签信息是不够的，我们还可以得到更多新奇的东西，为视图类增加我们自己命名的属性，然后可以打印到错误消息中。我们甚至可以在Interface Builder中，使用identity inspector中的 “User Defined Runtime Attributes”为自定义属性分配值。
&span style=&font-size:12&&@interface UIView (AutoLayoutDebugging) 
- (void)setAbc_NameTag:(NSString *)nameT 
- (NSString *)abc_nameT 
@end 
  
@implementation UIView (AutoLayoutDebugging) 
- (void)setAbc_NameTag:(NSString *)nameTag 
    objc_setAssociatedObject(self, &abc_nameTag&, nameTag, OBJC_ASSOCIATION_RETAIN_NONATOMIC); 
  
- (NSString *)abc_nameTag 
    return objc_getAssociatedObject(self, &abc_nameTag&);
@end 
@implementation NSLayoutConstraint (AutoLayoutDebugging) 
#ifdef DEBUG 
- (NSString *)description 
NSString *description = super. 
    NSString *asciiArtDescription = self.asciiArtD 
    return [description stringByAppendingFormat:@& %@ (%@, %@)&, asciiArtDescription, [self.firstItem abc_nameTag], [self.secondItem abc_nameTag]]; 
#endif 
@end &/span&
通过这种方法错误消息变得更可读，并且你不需要找出内存地址对应的视图。然而，对你而言，你需要做一些额外的工作以确保每次为视图分配的名字都是有意义。
12345678910
12345678910
12345678910 上一篇：下一篇：文章评论相关解决方案 1234567891011 Copyright & &&版权所有