有什么亮点和失望的地方？苹果的设计是否在扁平化大潮中有属于自己的风格？如何看待明显的借鉴/抄袭 Android、Windows Phone 等其他移动 APP 和越狱插件的（大杂烩）倾向？以及对界面以外的其他功能、特性的评价。
亮點：最大亮點，是蘋果決定了iOS用戶需要放棄「扶助輪」－－放棄iOS 6以往大量的擬真效果，只保留部份，帶領用戶早日適應扁平使用環境，以獲取觸控螢幕的最大硬件優勢。有很多網友花心機去摘文iOS 7的新界面不濟、如何不及舊的。可惜大部份作品都有同一個問題：用舊思維去看新世界。iOS 6跟iOS 7的分別並不止於表面風格，而是藏於骨子裡的根本思維分別。iOS 7作為一操作系統，本身並不存在對錯，因為它是一套對該生態系統的全盤改變，它要盈造的是一個新的使用世界。就好像、我們今天的地球長這樣子，所以我們人類就要長這樣子；假若地球上本來就沒有太陽照射，地表上的生物就會像今日的模樣，或許不會覺得沒眼睛是錯的。iOS 7帶來的改變，對使用者、UX設計師的改變就是類近這層次。扁平化也一種視覺概念，它本身就不會有對錯之分，反之，未來UI、UX設計師如何去詮釋、演繹它就是最有待大家去解決的問題。我們預計，隨著時日該系統不斷改善、用戶亦日漸適應，情況會一直改進。就是不少網友利用UI、UX的知識大肆批評iOS 7的設計，又如Dribbble上有大把大把「提案」iOS 7該要如何用舊方法做，可惜歸納這些做法最終目的只是要將新提案拉回舊世界，用舊想像掩飾新想法的不安而已。當年Aqua界面推出的時間，就有不少人用OS 9的設計語言去批評新界面的做法。經過十多年發展，Aqua界面當年具爭議性的用戶面處理方法卻已經成為UX界的金科玉律－－就是這麼一回事。事實上蘋果與App developers、Dribbble用戶提倡扁平化地位大不同。前者是要引領大眾進入新世界，因為它是硬件和平台的擁有者，也遊戲規則創造者；後者則只有製造潮流的份兒，因為他們是跟著遊戲規則去玩。今天Apple提出新的發展環境，就是為UI/UX設計師又再次帶來新挑戰，那麼你看到的是問題還是機遇？就由閣下去判斷。失望：沒有失望，因為iOS 7從零到沒有，時間大概只有7-8個月時間（但看互動animation的成熟程度，iOS 7必定早於這時間開始開發），甚至有「超額完成」的感覺。感覺上iOS 7更像一個繼往開來角色（如當年OS X Cougar），除了為設計師和用戶帶來巨大變革、機遇和新體驗外，就是更期待iOS 7後的版本如何發展得成熟－－要知道所有新事物也得需要時間摸索的。作為忠實用戶，卻也自iOS 3用起，太習慣舊有界面而生厭，所以很樂見這次改革。至於方向對錯，則要看UX業者如何發揮。我們或許太習慣於蘋果近年Incremental updates的習慣，不曾記得蘋果一直是勇敢大刀闊斧的改革者。苹果的设计是否在扁平化大潮中有属于自己的风格？首先我並不認同「扁平化」是一種潮流。反之我覺得這是用戶面設計的合理進化階段。怎麼說，從九十年代Mac OS透過滑鼠、鍵盤進行原始互動，進展到Aqua的擬真風格，及後iOS的觸控屏幕互動＋擬真，到最新的扁平化，就是一步步帶領用家與屏幕硬件進行更全面而合理的互動。滑鼠並非與電腦硬件最好互動方式，因為經鼠標操控畫面，失真程度最高，令人與硬件軟件的互動程度處於低水平。至擬真風格出現，令用戶對互動形式更有親切感，卻需要在平面上製造立體假像，沒有以最佳方法利用好新界面；以至iOS、Retina Display的出現，一步步拉近人與屏幕平面的距離。經過七年學習，也是一個合理時間向用戶提議更多可能性。觀乎Windows Metro的用戶面風格，不可叫做「平面化」，而是、以「平面」作設計出發點。該用戶面設計於要設計的時候明顯沒有想過界面與用者如何互動，反之更像要向用者演示WM用戶面要與其他操作系統界面不同－－就是要與別不同而已，所以其互動效果明顯沒有考慮與人觸碰產生的感覺。是次iOS 7扁平化則嘗試將用戶帶進另一個空間，除了大有進步的互動效果外，由以往「將擬真實物放在屏幕上」改變成「一塊塊薄膠片貼在螢幕」，加上「Depth」的新效果，明顯仍然是由人類的觸感、視感出發，然後用全新方式演繹，與WM的反人類設計不同，這點不可以混淆。如何看待明显的借鉴/抄袭 Android、Windows Phone 等其他移动 APP 和越狱插件的（大杂烩）倾向？我對於這種做法表示失望，但若果從大環境去看，更希望蘋果是從其他系統取靈感，而非直接抄取，即使說所有移動操作系統的發展也是互相影響而成。以及对界面以外的其他功能、特性的评价。老實說本人沒有安裝試用版本，作為End-Users也對半製成品沒興趣（也因此所有細節討論在我來說也是沒有價值），反之更有興趣於討論iOS 7帶來的新思維、新衝擊和新機遇，我更不明白是為甚麼開發者、設計師都表示不安，新系統表示他們可以得到更多新機會呢。
做这期Shawn Talk，其实就是受这个问题的启发，这里把我视频的原稿贴在这里，当做这个问题的答案。回答的最后附有视频链接。大家可以根据喜好来选择。第一段IOS7的发布了，风头甚至盖过了神州十号，顿时让整个科技圈都倍儿有存在感，或许是最有存在感的一回了。我们团队的熬夜看完了发布会，集体感觉很久没有这么满足的开心过了，好像看过了一场酣畅淋漓的球赛一样。大会之前我发了微博说“这次WWDC 很重要，因为苹果要证明自己是否依然能够think different”其实这里边包含着几层意思。首先从内部来说，苹果高层在政治斗争后，Jonny Ive急需通过产品证明自己。其次IOS从3.0版本之后就已经没有明显的进化了，消费者的新需求已经不能有效满足了，必须自我蜕变增加竞争力。最后，自从进入后乔布斯时代以来，我们还没看到，未来苹果产品风格将会走向哪里，能否依旧保持创新，创新的方向会怎样，这次的大会会是一个风向标。所以它备受瞩目也就不难理解了，然而没想到的是iOS7刚一发布，就成了网络舆论攻击的重灾区。究竟大家都在喷什么呢？第二段一切其实都要从UI设计的扁平化开始讲起，发布会验证了之前的传言，在Johnny Ive的操刀下，IOS确实完全抛弃了拟物的方向，采用了扁平化、非常简洁的设计。其实扁平化的设计方式一直都是Johnny Ive的风格方向，早期iphone的原型界面当中它就采用了这种风格，只不过乔布斯当年选择了拟物化的设计方案，使得johnny ive的一直没有机会向大家展示，而这次终于摆在人们面前，收到反馈却是截然不同的两种声音，有的叫好，有的吐槽，吐槽的人当中有一个非常具有代表性的群体，就是专业设计师。 首先说，我个人是很喜欢这次IOS7带来的新变化，但是网上吐槽的这么多，有的人根本没用过为了喷而喷，有的则又非常有道理，所以我们接下来是理性的来给大家讲讲专业人士吐槽的原因。 吐槽的声音几种在几个方面，首先是这个风格本身，扁平极简的风格在近几年，已经被谷歌跟微软比较广泛的运用到产品当中了，而在你要明白，在设计师心中苹果可是风向标，它向来是设立标准，引导潮流的，结果这次苹果却是跟随潮流。被人们视作为对主流审美的屈服，一种后乔布斯时代苹果在设计上的倒退。（空隙）但无论是创造潮流还是随波逐流，这毕竟都有着强烈的主观感情的色彩，如果单是设计师们情感上过不去，也不至于招致这么大的不满，那么除了这点以外，技术上引来大家不满或者吐槽的地方，在于苹果违背了一些设计上的常识，与自己一贯的原则，让大家接受不能。其中被吐的最狠的就是的图标，比如这个safari，虽然IOS7整体我非常喜欢，但这个图标也却是把我震了一下，可能你看了之后也想说，我靠这怎么能是苹果干的出来的事，我们来做一个简单的对比你就明白问题在什么地方了，按照以前的风格来判断，新图标中间图案所占的比例过大了，新的safari 跟app store图标里边的圆圈太大，就直接给图标的边框造成压迫的感觉，让人看起来很肥，而原来老的图标，构图空间分配更加适中，比例看起来更加协调，而从图标的设计本身来说，新图标采用的元素跟信息密度都比原来高了很多，不够简洁，原来典型的拟物图标，造型更是变化非常大，比如指南针，Newstand，等等。所以不仅把老的拟物风格抛弃了，而且还改变了苹果建立起来的构图跟设计原则也给抛弃了，一下子大家都看不懂了，不知道什么叫美了，所以遭吐槽是难免的。我们看到网上有设计师对新的IOS7图标，以老的构图原则进行了优化之后，立刻有了不一样的感觉，我们看到“照片”，“设置”，“safari”，等图标的构图都做了收缩，视频图标的过饱和的颜色得到了还原，newsstand的信息做了简化，你还别说，整体看起来确实多了几分熟悉的感觉，所以说设计是个很神奇的活儿。另外一个非常违背设计常识的地方就是，相同功能的东西在系统当中表现不一致，比如，系统中大范围的采用了毛玻璃的半透明的效果，一方面让背景适当的渗透到前端，来给人微妙的通透感，同时模糊背景，让信息更凸显。但是不同情况下，底色跟透明度却有很大的不同，当底色为灰色时，可以很好的将背景物体的颜色控制住，前端显示的内容就会非常和谐，而当底色太浅，背景过饱和的色彩就会大量的渗透，干扰前端内容的识别，视觉上非常分散注意力，就造成效果时好时坏的现象。键盘也是有同样情况，时而灰色底，时而白色透明底，很不一致，虽说设计是一门艺术活，并非要求处处严格一致，但是苹果作为设计界的风向标，这样的尺度难免让人摸不到头脑。是ive本身的问题，还是手下找了两个临时工干的呢？除此之外，系统颜色很多过饱和色的运用很容易让眼睛产生疲劳感，可能是beta版本的原因，一些文字的排版也极度的让人忍受不能，甚至有些地方三个按钮的大小都不一致。类似这样的细节上的瑕疵在这次的IOS7里边还是很多的，设计是一个扣细节的活，苹果交出这样的作业，让这些天天以抠细节为生，以苹果为榜样的设计们如何接受这残酷的现实，颇有恨铁不成钢的感觉。当然还有一种可能，就是大家都错了，苹果又要颠覆大家的审美。然而无论是图标设计不理想也好，还是不够连贯统一也好，其实这些都还是停留在苹果主观上的问题，更大规模的挑战是第三方应用如何跟得上这大跨度的风格转变。越简单的设计越难做，这次IOS7的主体设计“重内容，轻页面”，系统状态栏，顶部的标题栏，跟内容展示部分的界限都给模糊了，不再有老版本当中明显的区域划分，这就使界面的角色则退到了相对靠后的位置，使得内容得到了凸显，比如safari，音乐，信息的界面，你进来第一眼看到的是内容，不是明显的屏幕分段。这种转变也注定了开发者会经过一段混乱时期，才能跟上这种变化，我们看到开启某些应用，很明显风格是格格不入的。当然这还有一个很崩溃的东西，就是很多设计是英文本位思想的产物，就是无法照顾到多语言的环境下的协调性，这界面在中文界面下是否好看就非常挑战了。在发布会之后我们紧接着就发起了投票，得到了12000位网友的参与，其中65%人表示喜欢IOS7， 35%表示不喜欢。证明消费者的观察角度确实非常不同，就好像当我把镜头眩光的照片给一些人看的时候，居然有人惊呼好漂亮，却完全忽略了这是镜组质量差的体现。就像我们投票结果显示的那样，可能以上我们谈到的细节对于消费者来说都根本不是问题。我们引用一位设计师的话来总结UI 这部分，IOS 7整体的设计是非常棒的，很多细节非常不禁让人叫好，新图标当中也不乏优秀的作品，但不能因为其他方面的优秀就忘掉或者无视launcher icon的丑陋，同样不能由于普通用户审美没有跟上，没发现这些丑陋，从业者就掩耳盗铃的当它不存在。总而言之，它可以做的更好，我们来期待正式版吧。设计就像时尚，随着时代不停的变化，人们的审美也是一样，所以谁也不能保证未来的趋势会不会被苹果掰弯， 或许两年三年后我们再来看IOS7会得到更加公允的答案。第三段当然除了最简单最直接UI方面的变化，其实苹果在交互UX上边的改动，下手也是非常的狠。很多地方值得我们充分肯定的。那么它带来了哪些改变，那些影响呢？首先是控制中心，它的出现在我看来是有着破冰般的意义，证明苹果终于承认，过去的系统当中已经有些过时了。而他的出现也是出于用户迫切的需求，在2007年，第一代iphone真正重新定义了现代智能手机的时候，那时候消费者大多还不懂得如何去使用智能手机，不知道如何去运用这么大的触摸屏幕，所以选择拟物设计，让大家降低学习门槛，所以很多功能都只有单一入口，没有快捷方式，没有小工具，极度简化操作逻辑，相当长的时间内这种坚持确实效果很好，但可惜却没能与时俱进。就像我们小时候老师在教我们四则运算的时候，首先教的一定是加法列等式，它固然最简单，但是当你熟练之后，你就会发现有些时候你需要更加高效方法来计算，可这个老师，它就是不教你乘法，不停的告诉你加法最简单，终于你忍不住了，在别人那学会乘法了，这老师又说，行，学会就学会了吧，我是不想搞糊涂你。（黑场）Control center的第一个重要的意义当然还是提高操作效率，举个简单的例子，当我正在开网页，突然发现，哎，好像有wifi可以用，老的IOS需要至少五步才能做到打开wifi回到应用的全过程，而新的ios只需要两三步，且是在不离开当前运行应用的前提下做到的，使得操作流程没有中断，用户感受是一个非常大的提升。同时这个control center还客观上降低了大家使用home键的频率。原来你换歌，调亮度，切换程序，什么都要双击，现在除了任务切换以外，全部都被摘出来了，通过滑动激活的方式， home键的寿命相信也会得到改善，功能可视化程度高了，隐藏的不那么深了。所以从功能性上来说这个功能是个100%的加分功能，但这功能加分的实现是以鲜血为代价的，对于iOS 这样体量的平台，分分钟创造机会，动动手指也能断了你的财路。一个control center底部呼出的方式，立刻越狱插件的意义变小了，手电筒的快捷方式，手电筒应用死了，airdrop一下子局域网分享软件死了，加入了拦截电话跟短信的功能，垃圾广告商也死了。小功能不能幸免，大公司也有不同程度的冲击，比如skype，instagram等等。所以这故事教育我们做app功能太单一有被割喉的风险。第四段另一个我们想单独拿出来讲的功能就是多任务的界面，采用了卡片预览，可视化强了，滑动关闭的操作方式，省去了长按关闭应用的困惑。这给用户带来的价值是毋庸置疑的。但也是也带出了很多关于抄袭的讨论。也想谈谈我的看法首先我觉得如果你非常较真的来研究抄袭的话，你会发现这些大公司的东西没几个是100%自己发明的。所以这样就很容易陷入徒劳的争论当中。如果我们换一个角度，将开创某种交互方式的开创者看成领导者，而把其他人作为跟随者。并且把这项交互的普及不看做是无耻的抄袭，而看做是人机交互趋利避害的自然选择，我相信会一切都会容易理解很多。比如webos开创的卡片式浏览方式，被安卓借鉴，被windows phone借鉴，被黑莓借鉴，现在连苹果也借鉴，安卓的下拉式的通知中心，被苹果借鉴，传说中windows phone未来也会采用这种方式作为统一的信息中心，而苹果被其他系统借鉴的例子当然也有很多。所以如果我们跳出某一个厂家的视角，以整个行业的角度和更长的时间线去看待这些演化，你会得到一个不同的结论，智能机的人机交互发展其实还是很短的时间，真正的蓬勃发展也就是最近几年的事情，可以说大家仍然处在一个探索的阶段，没有一个系统可以每个方面都做大尽善尽美，而某一个系统逐渐一个方面做的很好，并得到消费者的验证，就成了一种交互模式的领导者，比如安卓的通知中心，比如黑莓的信息中心等，其他人跟随他们探索出来的成功经验，成为了跟随者。屏幕就那么大，从用户感受的角度出发，好的方法就那么几种，大家都选择使用，这其实是行业进化，交互方式优胜劣汰的体现，是好事。Palm 死了，难道就应该让卡片式管理跟着一起陪葬么？这样是不是太过可惜，也太过狭隘了点？而且，基本的交互方式互相借鉴，走向融合带来的直接好处就是，每个操作系统之间基本逻辑差异越来越小，用户适应起来跨度越来越小，这就是行业的进步，消费者知道两个图标重叠就是创建文件夹，知道顶部下滑就是看通知，这又什么不好么？所以我们倾向于不去纠结一个谁先做出这个功能，而是谁能把这功能的用户价值最大化。屏幕就这大，智能手机的交互方式除了界面上的调整之外，对于手势，边缘的运用都仍然在摸索当中。有些公司做了很好的表率，比如twitter的下拉刷新专利，就公开表示不会用它去攻击别人，希望大家都能用来提升用户感受，尊重知识产权，把我好度，这种是我们提倡的健康的模式，任何利用专利当武器让竞争偏离了产品竞争的轨道，都是不利于推动行业发展的。所以某些公司自己对号入座啊。近几年我们看到苹果在越来越多的方面做了跟随者，你当然可以把它归结为苹果的创新势头慢了，但是相对于数落苹果，我们更愿意花时间去看其他的系统在那些方面的创新更加成熟了，对行业在交互上有了哪些新贡献。第五段iOS 7 总体是一个很棒的产品，整体的用户感受有着显著的加强，当成熟的智能机用户拥抱庆祝变化的时候，不要忘了iPhone是一个主流市场的产品，覆盖的人群非常复杂，这里并不是指它的年龄段，而是对于智能机的熟悉程度的参差，如此大的转变一定会带来相当程度的学习成本，用户学习成本，加上开发者的适配成本，是这次升级的核心风险所在了。对于它的设计，无论今天有多少设计师跟消费者骂它，也没有一个设计师感保证永远不被苹果带的跑偏，或许两年后我们再来看IOS7的设计会得到更加公允的评价。对于它的交互，我更愿意把它说成是一个新时代的标志，在这个时代里，你会看到苹果以更友好，更开放的姿态面对消费者，会少了上一个时代当中的乔布斯式的孤傲与偏执。变得友好开放并不是一种倒退，而是不同时代的特征与符号，也证明苹果在“后乔布斯时代”有了鲜明的方向。在乔布斯的年代，他的方式被证明是非常有效的，但是没有人可以把他的思维方式发挥的比他自己还好，所以不仅苹果需要停止去想乔布斯喜欢什么，关注苹果的粉丝、消费者也要停止质问乔布斯会不会做这个，乔布斯会不会做那个。告别了乔布斯的影子，无论是苹果还是Johnny Ive都进入了一个更加自由的新时代，只是对于苹果跟对于Johnny Ive来说，这是事业新的高潮的开始，还是下坡的转折点只有时间才知道了。以下为视频
「ZEALER 出品」Shawn Talk 第三期 iOS 7 的「槽点」跟观点
/v_show/id_XNTcxMjE2NDAw.html
王自如ZEALER中国 | 创始人
0. 感受和感受Designing something requires focus. The first thing we ask is what do we want people to feel？前天中午升级了 iOS 7，很新鲜很兴奋。朋友问我，「如果用一个词来形容 iOS 7，你的选择是？」我沉默一会儿，说「通透」。朋友追问，「为什么？」我答不上来，「就是感觉。」是的，通透，这是我对 iOS 7 下意识的感觉，但并不知道为什么，直到我又看到 iOS 7 官方宣传片中的这张图：我认为这就是 iOS 7 中最基本最隐藏的变化，也是之所以我感觉「通透」的原因：iOS 7 所有的层级（layer）有且只有 3 层：底层：壁纸中间层：锁屏信息、桌面图标、文件夹、应用本身、多任务管理顶层：通知栏、控制中心、对话窗口、Siri具体地说：1. 底层：壁纸、摄像头取景底层大多情况下是壁纸。为了强化底层和中间层的区分，转动手机，壁纸会动，就像你转动茶杯时水面晃荡。不过比较有趣的是 Facetime 的背景，底层并非是壁纸，而是摄像头的实时取景画面。2. 中间层：锁屏信息、桌面图标、文件夹、应用本身、多任务管理从锁屏到桌面，锁屏信息使用基本图形和文字，没有多余元素，侧滑时从右侧消失，桌面图标铺满壁纸，动画极其轻量，感受上是同一层。（严格意义上，这只在锁屏壁纸和桌面壁纸使用同一张图片时感受明显，但我认为，锁屏壁纸的变化不属于层的变化。）从桌面到文件夹，zoom in & zoom out 的动画切换，还是在一层。从应用图标到应用本身，继续 zoom in & zoom out 的动画，感受上还是在同层。应用间的切换是同一层间的平移。卡片式多任务管理，这是最能说明桌面和应用是同一层的界面。某些时候，为了强化应用内部是中间层，会通过穿透图层或者虚化图层的方式让底层出现。例如拨号界面按下数字键会透出背后的底层壁纸。应用内部的页面切换使用左右侧滑的动画和手势，使得感受上很稳定，感觉上仍然还处于中间层中。总之，桌面、文件夹、应用本身，三者组成了一张细节丰富的「纸」，通过 zoom in & zoom out 动画将用户需要的细节呈现出来，同时可以随时感知自己当前所在位置。补充：桌面图标和应用本身是同一层的另一例证是，图标的设计框架（grid）和应用本身的设计框架是一致的。图片来源及更多详情：3. 顶层：通知栏、控制中心、对话弹窗、Siri由手势或系统触发，在需要时出现。使用毛玻璃效果，用户当前界面在背后若隐若现，有安全感。锁屏收到通知，锁屏界面会毛玻璃化，这是因为通知是顶层内容，所以会覆盖使用毛玻璃覆盖中间层的锁屏。弹出对话框是顶层，此时触发的键盘也是毛玻璃效果。提醒下，iOS 6 中弹窗的输入键盘也是深色调，但没有 iOS 7 中层的概念这么明显。4. 为什么通透？当我理顺了这 3 层的关系，当我多次重复滑开锁屏、进入桌面、打开文件夹、进入应用，侧滑，后退的时候，我终于明白为什么这是通透的。Distinct function layers help establish hierarchy and order.如果使用「层」这个纬度去对比同时代的移动操作系统（设计的纬度很多，不一定是「层」，所以这样的对比严格说来是不对等的），你会发现很有趣的是，这些系统在层级上并不「扁平」，层级偏多。一个例子是，视觉上极度「扁平」的 Windows Phone，在页面切换中大量使用瓷砖动画，导致每进入一个新页面从感受上都是进入一个新的层。 5. 为什么是这个样子？We have always thought of design, as being so much more than just the way something looks.It's the whole thing. The way actually works on so many different levels.Design defines so much of our experience.There is a profound and enduring beauty in simplicity, in clarity, in efficiency. True simplicity is derived from so much more than just the absence of clutter and ornamentation—it’s about bringing order to complexity.设计，并不仅仅是看上去的样子，而是关乎整体。真正的美，存在于简洁、透明和效率当中。6. 最后The mobile OS from a whole new perspective.这是 iOS 7 的 slogan，但至于这个 whole new perspective，见仁见智。你可以单纯的认为这只是一次视觉上的 redesign，或者也可以相信这是为迎接未来更多材料和产品的可能性而做的铺垫，局外人的猜测从来都是虚妄，时间会证明一切。两天时间，到目前为止，我是很喜欢 iOS 7，缺点和 bug 很多，重启也很多，但我感受到这背后的勇气和诚意。美或者不美，从来都不是真正的问题。结答。引用：iOS 7 官方宣传片
中文字幕：iOS 7官方介绍视频完整版
/v_show/id_XNTY5NDk2NTAw.html
Intention - Designed by Apple in Carlifornia
Apple WWDC 2013:Designed by Apple in Carlifornia
/v_show/id_XNTY5MjU0NTQ0.html
歡迎關注瀚文堂。/hmttypography云大附中网站/云南大学附属中学网站 » T客邦 (3179 未读)
云大附中网站/云南大学附属中学网站 » T客邦
26352 条 (26349 未读) 共 10 源
(1663 未读) [|]
(131 未读) [|]
(570 未读) [|]
(5643 未读) [|]
(5243 未读) [|]
(2997 未读) [|]
(57 未读) [|]
(6849 未读) [|]
(17 未读) [|]
(3179 未读) [|]
只显示未读
已读和未读
T客邦 (50 未读)IOS&6&自动布局&入门
大胆尝试constraint
也许你已经注意在canvas里面到有些T型状对象看上去比其他的要粗一点。这些加粗的，我们称之为user
constraints，你删除它们后的效果和删除细的是不同的。当你删除一个user
constraints，Interface
Builder经常会自动在删除的地方放置一个不可删除的constraint来代替之。我马上就会讲到为什么会这样。
在文档概要图中，user constraint有一个蓝色按钮：
选中 Vertical Space (40) constraint 然后按一下键盘上的删除按钮。
在两个按钮之间的T形状对象消失了，取而代之的是一个新的直接连接屏幕底部的Vertical Space constraint ：
新的constraint有一个紫色的按钮，并且图中它的线没有被加粗，这也就代表着它是不可删除的。现在这两个不再在垂直方向连接在一起了。尽管由于Leading
Alignment constraint 而依然左边对齐着。
为什么会发生这种事情？ 为什么 Interface Builder对按钮发出了一个新的 Vertical Constraint ,
甚至你还没有告诉它要删除这么一个constraint？答案是：
对于每一个view都必须要有足够的constraints来对其进行位置以及大小的控制。
当用到 Auto Layout时，这是一条最重要的规则。如果对于一个view没有足够的 constraints, 它的 Auto
Layout 将不能决定它的位置以及大小。 这种布局是被认为无效的。待会你会看到几个无效布局的例子。
Builder会尽量帮你避免布局无效。这两个按钮的尺寸是可以知道的因为他们根据他们包含的文本，背景图以及其他的一些东西-固定尺寸内容是可以确定下来他们的尺寸，还记得不？所以这不会是一个问题，上方按钮的X-位置也可以通过它的左边界与下方按钮的左边界对齐来获取，而下方按钮又一直保持着底部居中。现在唯一不确定的就是它的Y-位置。
之前的话，这两个按钮用一个 Vertical Space相连。这个条件足够能推导出上方按钮的Y-位置。但如果你删除了Vertical
Space，上方按钮就没有依据来定位它在view里的垂直位置了。因为Auto
Layout不知道如何决定它的Y位置，所以它不能在屏幕中显示出来。
为了避免这种情况发生，Interface Builder需要重新在view中找一个离按钮底部边界最近的地方“pin”它。
有趣的是，当你重新运行程序并且转动屏幕至景观方向时，还是之前的效果嘛。这也是正常的，但你的设计确实从根本上就不同了：这两个按钮现在都与窗体的底部相连。这也就意味着，当下方按钮移动时，上方的按钮不会跟着它一起动了。（注意这个解决方案也不算很好，好不好取决于和你理想的效果是否相同。在这个例子中，你明显是希望这两个间有一个vertical
connnetion。）
我们证明一下，选中底下那个按钮的和屏幕底边的一个Vertical Space constraint，然后到Attributes
inspector ，它的常量现在是“Auto”，目前它是一个标准尺寸，现在把它改为40。
因为这两个按钮选择没有链接，所以现在只有下方的按钮往上面移动了；上方的按钮还是保持原位:
注意当改变 constraint常量值时会将它提升为一个 加粗的 “user” constraint。
现在让我们把两个按钮在再次连接在一起。目前为止你通过把按钮拖进canvas来得到了一些constraints，你可以在稍后做这些。按住Cmd键然后同时选中它们，在Editor菜单,
然后选择PinVertical
你也可以通过右下角的小面板菜单来做这个constraint：
它会弹出如下菜单：
先不管你选择了哪种方法, 这个操作在两个按钮之间添加了一个新的constraint：
这个新的constraint是一个有常量为20 points的Vertical Space
。这仅仅是因为当你把两个按钮连接起来的时候，他们之间的距离是20 points。
注意原来从上方按钮到屏幕底部的Vertical Space还是存在的。这个constraint是Vertical
Space（104）- 现在已经不需要，所以删了它吧。
之前当你删除一个蓝色constraint的时候，一个紫色会出现并且取代它。现在这种事情不会发生了，因为剩下的constraints已经足够表达清楚所有view的位置。只有在现有constraint不够的情况下，Interface
Builder才会添加新的constraint。
现在你的constraints应该如下所示：
选中底部的 Vertical Space (通过在canvas上点击) 然后把它的constant
40的值改回为标准值。这步不仅仅应该把下方按钮往下移，上方的按钮也该移动。因为现在他们又被连接在一起了。
一个动态运行小测试
现在你知道的一点基础知识有：如何使用guides来放置控件，如何使他们相连对齐，如何在空间之间设置空白空间。在这篇教程后，你也会了解到Align
and Pin 菜单的其他选项。
使用Interface Builder 来鼓捣constraints是非常不错的,
但现在让我们来看看，在程序运行的时候这个是如何工作的。在?ViewController.m&中加入如下方法:
- (IBAction)buttonTapped:(UIButton *)sender
if ([[sender titleForState:UIControlStateNormal] isEqualToString:@"X"])
[sender setTitle:@"A very long title for this button"
forState:UIControlStateNormal];
[sender setTitle:@"X" forState:UIControlStateNormal];
这个方法解释为通过触发按钮事件来简单的切换按钮标题的长短。从Interface
Builder里面给这两个按钮连接方法：对每个按钮按住Ctrl拖至File’s Owner 然后在组里面选择buttonTapped:
运行程序看看这会怎么样。并且同时在景观方向和肖像方向设置测试。
不论你触碰的是哪个按钮，现在的页面布局总是能够符合你提出的contraints：
在水平方向，下方的按钮总是在窗口中水平居中。
下方的按钮总是和窗口的底部保持20 points距离。
上方的按钮总是和下方的保持左边界对齐。
这是你设置的整个用户界面的规范。
你可以为了乐趣，同时在Interface Builder选中两个按钮，然后从Align菜单选择Right
Edges。然后运行程序注意观察这其中的区别。
重复地,但现在请选择AlignHorizontal
Centers。这会使上方的按钮中心和下方的按钮的中心对齐。现在运行程序看看这些按钮是如何工作的。
Pin 菜单有一个 Widths Equally选项。 如果你的两个view设置了这个constraint，那么Auto Layout
会一直保持两个view的宽度相等，这个宽度值取决于较宽的那个view。让我们来对这个做一个实验。
选中这两个按钮然后在菜单里选择?PinWidths
Equally。?这步操作为两个按钮添加了一个新的constraint：
提示:&如果两个按钮的任意一个与superview有一个你不想要的constraint，那么请再次同时选中两个按钮然后执行
AlignHorizontal Centers选项。
在这系列教程的第一部分，你其实是已经见识过了这类constraint。这个看上去和普通的T型状对象类似，但其实在这T型状对象的中间有一个圈，圈里是有一个等于号的。
看，在文档概要图里又多了一个 ?Equal Widths constraint：
现在改变其中一个按钮的标签内容也会同时改变到另外个按钮的尺寸了。
把下方按钮的标签内容改至 “X”，让它足够小。你可以注意到上方按钮的尺寸不在兼容它的内容了：
那么Interface Builder是如何知道要选用哪个按钮的尺寸的呢？ 如果你足够细心的话，你会发现有一个, Width
constraint 被加到了上方按钮：
Interface Builder 强制上方按钮变小，为了满足Equal Widths constraint这个限制条件。
很明显这不是你想要的结果，所以请选择上方按钮然后在Editor菜单里为它选择Size
to Fit Content（或者按快捷键&Cmd
=）。现在，按钮里面的文本又能全部看到了 &
&或者更科学的说，这个按钮能够根据包含的文本而调整大小了 & 另外它的Width
constraint也消失了。
运行程序然后点击按钮。现在两个按钮一直保持相同宽度了，不论哪个按钮的长度比较宽：
当然当两个按钮都变得非常短时，他们还是会一起缩小到相等宽度。除非有个constraint来做限制，不然的话按钮控件是会根据他自己包含的内容来不多不少的调整自己的尺寸到一个恰当的大小。这个叫什么功能呢？对的，这就是固有内容尺寸。
固有内容尺寸
在 Auto Layout功能出现之前,
你通常会设置你的各种控件该有多大，或者在通过定制他们的frame、bounds属性来改变大小，或者直接在Interface
Builder来改变他们的大小。 但目前的情况是大部分的控件完全有能力基于它们的内容来计算出自生所要占的空间大小。
一个label能够通过设置在它上面的文本长度以及文本字体来计算出自己的宽和高。类似地，button,可以通过在它带有背景的文本以及一些圆角的填充来计算出适合自己的宽和高。
这也适用于很多分段控件，如一些progress
bars，还有许多的其他控件，尽管有一些是有一个预定义的高，但是它宽还是可以设置的。
这就是所谓的&固有尺寸内容,
在Auto Layout这是一个重要的概念。在按钮的操作中你已经见识到了吧。. Auto Layout
会先问你的空间他们有多大，然后在基于空间给出的信息将他们展示到屏幕上去。
你也可以不使用它，但你要明确设置这个空间的Width 或者 Height constraint。如果你这么做了，那么
Interface Builder
为自动生成一个你设置的constraint。如果想要再次恢复固有内容尺寸的话，你只需重新使用Size
to Fit Content&操作, 另外之前你设置的 Width
or Height constraints会自动消失.
通常来说，你使用固有内容尺寸功能就够了，但有些情况下这功能还是不尽如人意的。想象一下，当你需要在UIImageView上设置一个image的时候，如果那个image要比屏幕大的多，你通常会给image设置一个合适的宽度以及高度来适应UIImageView的内容尺寸，除非你想让imageview来自动帮你重新设置image的dimensions。
如果对一个按钮设置一个固定的 Width constraint，情况会怎么样？
虽然按钮能够计算自己的尺寸，但是你能通过给他设置一个固定的尺寸来使它的计算无效。选中上方的按钮然后在菜单选择PinWidth。&看，按钮上方有了一个固定的T型状对象了：
因为这类的constraint只应用于按钮本身，而不是它的superview，它被列在文档概要图中的按钮对象下方。就像你刚才所做的，现在这个按钮的固定尺寸被设为了73
运行程序然后点击按钮，看看发生了什么？按钮的文本内容改变了，它不再全部显示内容了因为缺少足够多的空间：
因为上方按钮有个固定的尺寸又因为两个按钮被要求是同一尺寸，所以他们不会再缩小和放大了。
提示：&你通常的设计理念是不会对一个按钮设置Width
constraint & 最好的情况是让按钮使用它自己的固有内容尺寸 &
但当你遇到过一个你希望控件自动改变尺寸而它没有改变的布局问题时，那么最好请多次确认一下Interface
Builder里面有没有一个固定的 Width constraint。
还是多玩一会这个东西吧以便于你真正掌握 对view对象的pinning 以及aligning
。因为不是所有的现象都很明显，所以你最好对它有一种感觉。但是请你记住，对于必须要有足够多的constraints，&&Auto
Layout&才能对所有的view判断出位置以及尺寸。
现在你应该对constraint是什么以及知道如何在不同view之间建立关系来构造你的布局。 接下来，你将会看到如何使用 Auto
Layout 以及 constraints 来创造一个符合现实世界场景的布局。
假设你要制作一个关于你最喜欢的程序员的图库应用，在景观和肖像方向，它看上去应该如下图所示:
这个屏幕现在被分成了4块大小相同的部分。每个部分有个imageview以及一个label。你怎么样来做到这个呢?
让我们重新开始这个程序。你可以使用你现存的“constraints”项目通过把里面的按钮全部删光。
或者，你可以重新创建一个新项目，用 Single View Application
模板然后你随便给他取一个名字你喜欢的名字。比如说，“画廊”。这里面只需要使用nib文件，所以请禁用掉storyboards
从对象库打开ViewController.xib文件,
把一个普通的view放到canvas上。把它的宽设为160 points，高设为230 points， 然后把背景改为你喜欢的某种颜色
(我把它改为绿色)：
这个view在它的空间内有4个constraint。不像一个button或者label，一个普通的UIView&没有固有内容尺寸功能。所以它必须要有足够的constraints来判定它的位置以及大小，所以现在这个view需要constraints来决定它需要的尺寸大小。
你可能想知道，这些尺寸的constraints在哪里？在这种情况下，这些view的尺寸通过他们superview的尺寸来得到。在这个布局中，有两个Horizontal
Spaces 以及两个Vertical Spaces，并且这些都有固定尺寸。你可以在文档概要图中看到这些：
绿色view的宽度可以通过这个公式 “superview的宽度 减去(109 + 51)” 来计算得到，类似的它的高度可以通过
“superview的高度 减去(153 + 77)”。
因为这些空白constraints被固定了，所有view本身没有机会来改变大小。但当你转动应用时，superview的尺寸从320&460变为480&300。把这新的宽度以及高度放到公式中，你会得到一个新的绿色view的尺寸。
你可以通过运行程序并且转动至景观模式看到这个现象，但你也可以直接在 Interface Builder里直接模拟这种情况。
选择nib文件里最顶层的view 然后到 Attributes inspector里去看，在 Simulated Metrics
部分里, 把方向改为景观模式：
这里可以看到 nib 文件在景观方向的直接布局现实。这个绿色view为了要满足 Horizontal and Vertical
Space constraints 而重新改变了它的尺寸。
再切回到肖像方向。
提示：现在有两个理由解释在nib文件上你为什么要用一个普通的UIView&：
a) 你将要用它来做其他view的容器，使用它可以帮助你组织你nib文件的内容。； b)
这对于一个定制的view或者control来说是一个占位标志，你可以把它类属性设置为你自己写的&UIView或者&UIControl的子类。
有时当设备转动时你不是总希望你的UIView&重新改变大小，
所以现在我们通过 constraints 来定制view的固定宽度/或者高度。我们来动手做一下。
选中绿色view然后在&Pin&菜单，
选择Width。同样地再次选中绿色view然后在菜单里选择&PinHeight。
你现在可以对view添加两个新的constraint，一个160 point的Width constraint 和一个230
point Height constraint：
因为宽度和高度只适用于这个view，在文档概要图中，他们处在view自身的目录下。通常来说，cnostraints只表现为两个view之间的关系
& 比如说，在绿色view和它的灰色superview之间有 Horizontal 和 Vertical Space
constraints 这个关系 & 但你也可以认为 Width 和Height constraints
是view和它自身的关系。
现在运行程序。恩！在肖像方向看上去不错。 现在把view翻转至景观方向。擦！ 它的样子不仅不是你想要的 & 它自身的尺寸又改变了 &
而且Xcode也报了一个令人讨厌的错误信息：
Gallery[68932:11303] Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don' (2) find the code that added the unwanted constraint or constraints and fix it. (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)
Will attempt to recover by breaking constraint
Break on objc_exception_throw to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in &UIKit/UIView.h& may also be helpful.
是否还记得我说过对于view来说必须要有足够多的constraint，那么Auto
Layout才能计算出所有view的位置以及尺寸？那么，现在这个例子的情况是它有太多的constraints了。无论何时当你得到错误
“Unable to simultaneously satisfy constraints”时，
这在暗示你的constraints在某些地方起冲突了。
让我们再来看看那些contraints:
对于这个绿色view，目前有6个constraint。四个之前你见过，另外两个新的&Width
和Height 是你刚加上去的。那么冲突起在哪里呢?
那么, 在肖像模式中数学的计算是没有问题的。superveiw的尺寸是320
points。如果你把绿色view的宽度再加上Horizontal
Space的长度，那么你应该得到320这个值。我定位绿色view的方式是：51 + 160 + 109 =
320。类似地，垂直vertical constraints 应该加到 460。
但当你转到设备至景观模式时，主窗口 (也就是它的superview)是 480 points 宽。这意味着 51 + 160 +
109 + ? = 480。 在这等号的左边还需要一个160 points但是Auto
Layout却不知道去哪里得到它。类似地，垂直坐标也是这个情况。
现在我们遇到的冲突为以下两种情况中的一种，要么view的宽度是固定的但是它对应的页边必须是可以改变大小，要么它对应的页边是固定的但是它的宽度可以改变大小。
在上面的例子中，你想要这个view在两个方向保持相同的宽度，所以后面的Horizontal Space 必须要删除掉。
把右边的 Horizontal Space删除以及把底部的Vertical Space删除。现在 nib
文件应该看上去这样了：
现在这个view已经有恰当数量的constraint来决定它的尺寸以及位置。不多也不少。再次运行程序，可以看到xcode报错信息已经没有了，这个view也在屏幕转动后保持了相同尺寸。
提示：&尽管 Interface Builder
已经很努力的帮你避免掉无效的布局了，但是它不是万能的。 可是至少Auto
Layout会为你报出一个详细的错误信息当你有些设置是错误的时候。 在&这本书里的”Intermediate Auto
Layout”你可以学到更多关于如何分析错误信息以及如何诊断布局问题的介绍。
把肖像画出来
在绿色view中拖进一个label。 注意现在的guides是在绿色view中出现了，因为它是label的superview。
根据guides把label放到绿色view的左上角。这会给label在绿色view中添加两个 Space constraints
来定位自己：
注意这两个新的 Horizontal and Vertical Space constraints
是被列在绿色view的contraints目录下面而不是main view下。
现在稍微把绿色view移动一点。你可以看到只有在绿色view和它的superview之间constraints改变了。而不是label的那些。
这个label会根据绿色view一直待在同一个相同的地方。
选中label然后把它移动到绿色view的底部边缘，并使它中心对称。然后在nib里拖进去一个新的imageview，使布局看上去如下图所示：
把这imageview固定在顶部，以及它superview的左右两个边界。但它的底部是通过一个标准spacing与底部标签相连。
下载&&然后解压文件。在里面你会找到一个&Images&文件夹
& 把它加入到你的项目中去。设置&Ray.png&作为你imageview的image，
然后把 image view的模式改为Aspect
Fit并且设置它的背景颜色为白色。接着把label的text写为“ray”。
你的布局现在看上去应该是这样的了：
请注意现在Interface Builder 已经在label上设置一个 Height
constraint了。这发生在你为你的image view设置image的时候。
Interface Builder已经尝试在避免某种含糊的布局的情况发生。如果image
view或者label都没有一个固定高度的话，那么Auto
Layout是不知道如何重新设定他们的高度的当绿色view变化时。(对于现在而言Interface
Builder似乎会忽略设置在绿色view上面的固定Height constraint)。
让我们来假设在某种情况下你app里的绿色view变高了100 points。那么现在这多出来的100
points在imageview和label当中是如何分配的呢？是不是imageview也变高了100
points而label保持原样呢？或者说是label变高了而imageview保持原样？或者说他们是对半分的，25/75分，46开？，或者其他某种分法？
Auto Layout是不会做这些假设的，所有只有Interface
Builder来通过给定label一个固定尺寸“帮助”我们解决这问题。当然它也可以给imageview一个固定尺寸，但是给label是更有意义的。
对于此刻来说, 让我们姑且先使用label上面的Height constraint。
提示：&对小布局设计来说一个比较恰当的解决方法是改变label的“Content
Compression Resistance
Priority”。这点你以后会学到。如果你等不及了想使用的话，那么请直接到label的Size inspector for the
label然后设置vertical Content Compression Resistance
Priority到751。可以到看到label上的 Height constraint会消失掉的。
加入其他头像
把绿色view移动到main view的左上角，是否还记得绿色view的Horizontal Space 以及 Vertical
Space constraints
判定了它在superview中的位置。依然还是那些constraints，但是他们现在的值被设为了0 －
蓝色线条的就是他们(有白色边界的) 在window的左上角：
虽然这个view是完全在角落里的，但它还是需要constraints来把它定位在那里。就把他们想象成边缘值为0吧。
选中绿色view然后按&Cmd-D&复制。把复制品移到右上角去：
再分别复制他们把他们移动左下角以及右下角。
把屏幕设计成如下所示:
这几位是比较帅的程序员 :-)
运行程序，可以看到肖像方向，界面看上去还不错，但是在景观方向就不尽如人意了：
这应该很明显可以看出错在哪里了：
你已经对4个view容器设置了固定的宽和高，所以他们会一直保持这那些尺寸，无论它的superview的尺寸如何变化。
选中4个view里面的 Width (160) and Height (230) constraints
然后删除他们。现在运行程序试试，你会得到下图所示，还是不尽如人意：
这个问题看上去有点像我们之前在介绍里面解决过的问题，所以让我们回想一下当时是如何解决的，你应该记得我们是给view设置相同的宽和高来解决的。
选中所有4个view然后做&PinWidths
Equally操作。再次重新选中然后再做PinHeights
Equally操作。
再次运行程序并且把之转到景观方向。嗯….它还是和之前的一样嘛。这是为什么呢？
好吧，如果你仔细观察上面的截图，你会发现其实每个view确实都有相同的高度，并且他们的宽度似乎也相同（只不过绿色的和棕色被黄色和蓝色部分遮盖住了），所以我们的contraints是对的，是的被满足的。现在的问题仅仅是宽度和高度不是你想要的。如果这是这样，那么肯定还有其他constraints在其中起作用了。
100%肯定，如果你仔细看这些view的constraints，你会看到他们同样的有Horizontal 以及 Vertical
Space constraints来强迫他们定位自己的位置。&(请看main
view的constraints，而不是4个子view的）：
更加悲剧的是，你都不能删除这些 constraint，main view的T型状对象不是蓝色粗体，所以可以推断出 Interface
Builder 把他们放在那里是为了避免某种布局问题的。
它为什么要这么做呢？
目前只能这么解释，所有的4个view都必须拥有相同的尺寸大小是不足以决定他们确切的的尺寸应该是多少的，因为Auto
Layout是不知道他们几个是如何连接在一起的。在我们设计上，他们是边和边的连接在一起，但是他们之前却没有这种constraints。所以Auto
Layout不会知道它需要把“Ray” and “Matthijs” 块宽度上需要分开。
如果Auto Layout不能通过自身才推断出这层意思的话，那你就只能自己来告诉他了。
选中 Ray 和 Matthijs 块然后选择&PinHorizontal
Spacing操作。因为这些块是边与边相连的，所以在他们之间需要添加一个尺寸为0的Horizontal
Space constraint，有了这个， Auto Layout 就知道他们是如何关系的了。
重要提示:&Interface
Builder不会自动帮你删除黄色view和superview之间的主导Horizontal
Space限制(就是上一张截图所示的)，但它会将它升级为一个user constraint(比较粗的T状对象)。
你现在可以把它删了。如果你不删的话，你会得到一个“Unable to simultaneously satisfy
constraints”的错误当你把应用转至景观方向时。
运行程序，看看现在是什么效果了：
这个看上稍微好一点了。现在四个view是相同宽度，但高度还是不对的。解决方案和之前的类似：在Ray和Dennis
Ritchie之间放一个 Vertical Space然后把Dennis的view和window顶部之间的Vertical
Space删除。
再次运行程序，现在看上去应该是这样了：
请注意“Dennis Ritchie”
label并不在它imageview的下方正中心。这件事最开始发生在当我想要在label里输入文字的时候。这个label初始化时是放在view的中间的，但Interface
Builder还是觉得把这个中心constraint替代为一个Horizontal
Space效果会更好。如果你也有这个问题，那么请选中这个label然后进行AlignHorizontal
Center in Container操作来修复它。
请再次注意下这些imageview：他们是延伸出来的，因为你没有给他们设置一个固定尺寸。你可能还不知道这一点，但设置他们确实是你的义务。：）
在景观方向下，这些view是不会自动修复的。但是，如果你想要一个imageview保持它原来的比例的话，那你就不是那么走运了。如果你不使用Interface
Builder来做一点修改的话，你是不可能得到下图的效果的：
不幸的是， Interface
Builder目前不提供一些能保持view原始比例的constraints。要做那个效果，你需要通过代码自己创建以及设置constraints。在里面有一章”Intermediate Auto Layout”是介绍具体怎么做的。
小贴士:你之前可能已经知道了你可以通过在Simulated
Metrics来设置方向以便于你预览用户界面。你也可以直接Interface Builder里面测试各种view的缩放行为。
选中main view，在Simulated
Metrics下，把尺寸设置为Freedom。现在你能nib文件添加缩放处理，你可以把它设置成你想要的任何型状。顺便也请放心，Auto
Layout会马上重新为你计算出新的布局的：
然后，你也要对此警惕。因为有时候当你重新设置尺寸时 Interface Builder
会给它自己添加新的constraints。就像现在这儿的右下角有一个新的Horizontal
Space一样。当然这也可能会删除现有的constraints，当你把nib文件放大出它原来的bounds的时候。
接下来去哪？
如果你从头看到这里了，那么恭喜！- 你现在已经知道了关于Auto
Layout的所有事情，并且已经对基础知识做了实践！但是在这方面还是有许多需要你去学习…
现在这份教程也就是你刚读的只是&&这本书里&Beginning
Auto Layout chapter章节的前半部分。后半部分会教到如何使用 Auto Layout来创建更多
“现实世界”的屏幕布局，以及有关同时使用Auto Layout 和Interface
Builder&的所有技巧。
和其他视觉设计工具一样， Interface Builder
有它自己的限制但是有时候如果它和&NSLayoutConstraint对象一起使用的话是会效果更好。&iOS
6教程书对于这个主题投入了一整个的章节- Intermediate Auto
Layout.。所以如果你想要对此刨根问底的话，&！
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。