关于iOS的布局主要有两种方式，分别是AutoResizing和AutoLayout。其中AutoResizing作为一种旧的布局方式，在AutoLayout被推广之后已经很少被使用。为了更加清晰的了解iOS的布局方式，本篇针对于这两种布局方法进行简要的总结。 一.AutoResizing 我们在使用AutoResizing进行布局的时候，其主要思想就是设置子视图跟随父视图的frame变化而变化。具体的情况，我们可以设置左跟随，右跟随等等。下面是AutoResizing在代码中的使用。 //父视图 UIVi
autoresizing是iOS中传统的界面自动布局方式，通过它，当父视图frame变换时，子视图会自动的做出相应的调整。
[toc] 1 屏幕适配简介 1.1 屏幕发展历史 手机型号 |屏幕大小 | 分辨率 ------------ | ------------- 4, 4S |3.5 | 320480 5,5C,5S | 4 | 320568 6,6S , 7 | 4.7 | 375667 6Plus, 6S Plus, 7 Plus | 5.5 | 414736 iPAD | 9.7 | 7681024 iPAD Pro | 12.9 | 10241366 1.2 适配技术发展史 iOS版本 | 适配技术
Autoresizing是苹果早期屏幕适配的解决办法，当时iOS设备机型很少、屏幕尺寸单一、APP界面相对简单，屏幕适配并没有现在这么复杂，所有的UI控件只要相对父控件布局就可以了，Autoresizing就是一个相对于父控件的布局解决方法
iPhone自诞生以来，随着其屏幕尺寸不断的多样化，屏幕适配的技术一直在发展更新。目前，iOS系统版本已经更新到9.3，XCode的最新版本已经是7.3，仅iPhone历史产品的尺寸就已经有4种：3.5英寸、4.0英寸、4.7英寸、5.5英寸。最近，iPhone家族又诞生一款iPhoneSE，鉴于这款iPhoneSE的屏幕尺寸和iPhone5S的尺寸一模一样——同样是4.0英寸，广大iOS开发者可算是松了口气，不然iOS的屏幕尺寸真的是越来越让人眼花缭乱。 按照时间顺序，屏幕适配是这样发展的：纯代码计算frame-> autoresizing(早期进行UI布局的技术，仅适用于约束父子控件之间的关系)->AutoLayout(iOS6/2012年、iPhone5被引入，比autoresizing更加高级，旨在替代autoresizing，可以设置任何控件之间的关系)->sizeClass(iOS8出现，用于解决越来越多的屏幕尺寸的适配问题)。 在iPhone3gs时代，手机的屏幕尺寸有且只有一种，也就是3.5英寸。开发app的时候，根本不用考虑同一个视图在不同尺寸的屏幕上显示的问题。iOS开发者完全可以用纯代码的方式把一个控件的frame写死。 后来apple公司推出了4.0英寸的iPhone5和iPhone5S，所以，针对于不同尺寸的屏幕，再把控件的frame写死就不可取了。（其实也不是不可取，很多iOS开发者做屏幕适配的时候不是用的autoresizing或autolayout，而是以代码的方式动态获取屏幕的尺寸，然后根据屏幕的尺寸来写死子控件的frame。使用这种方式你会在代码中无辜增加很多if...else... 的条件判断语句。另一种方式是获取到屏幕的尺寸后，按照控件和屏幕的比例来设置控件的frame，其本质上也是写死frame。所以这两种方式都不可取，毕竟将来会回出现越来越多的屏幕尺寸。从开发的角度，重复繁琐的代码会牵绊住开发者的进度；从程序设计角度，这样的设计思路不够高级，且日后不易于拓展和维护。）
一般情况下，我们说iPhone 8的屏幕是4.7寸屏，就是指iPhone 8的屏幕对角线为4.7英寸。 屏幕的单位是以英寸为单位，换算关系：1 inch = 2.54cm = 25.4mm。 2. 分辨率 历代iPhone的分辨率：
在上一篇博客中介绍了传统的布局方式：autoresizing。随着iphone型号的越来越多，屏幕的标准也更加多样化，通过autoresizing已经不能满足开发的需求，而进行两套布局或者动态代码控制又大大增加了开发者的工作量，autolayout的出现拯救个这一切，它让动态布局变的十分简单便捷。
1.1 先选中MasterViewController.xib，重新调整view 的尺寸和排列内部的各个控件，（以你喜欢的方式）让控件看起来更协调，而且能够全部显示，它可能看起来像下面这样样子：
注意：想要保持左右间距不变，那宽一定要可变，除了要勾选左右两个选项，中间表示宽可变的也得勾选。倘若中间不勾选，这时候宽不可变，其实际效果相当于只勾选了左边间距不变，右边勾选相当于无效选项。
AutoLayout旨在替代Autoresizing，所以在同一个项目中，AutoLayout和Autoresizing是不能共存的，二者只能选其一，如果你选择了AutoLayout，那么Autoresizing自动被屏蔽掉；如果你选择了Autoresizing，那么AutoLayout自动被屏蔽掉。XCode5及其之后的版本，默认新建的项目就是使用AutoLayout
Incrementally Adopting Auto Layout是什么意思呢？在我们IB里面布局我们的View的时候，我们并不需要一次性就添加好所有的constraints。我们可以一步步的增加constraints，简化我们的步骤，而且能让我们的设置起来更加灵活。
Autolayout Autolayout是一种“自动布局”技术，专门用来布局UI界面的 Autolayout自iOS6开始引入，由于Xcode4的不给力，当时并没有得到很大推广自iOS7（Xcode5）开始，Autolayout的开发效率得到很大的提升 苹果官方也推荐开发者尽量使用Autolayout来布局UI界面 Autolayout能很轻松地解决屏幕适配的问题 Autolayout的2个核心概念 参照 约束 与 Autoresizing 区别 在Autolayout之前，有Autoresizing可以
在iphone开发中，最基本的布局方式是通过frame，将控件的位置和大小固定在屏幕上，后来，由于手机屏幕的尺寸有了略微变化，有了autoresizing的布局框架，我们可以设置子视图随父视图的改变做一些相应的变化，再后来，iphone的尺寸与分辨率也越来越多，适配各个屏幕也成为了iOS开发者遇到的新的问题，幸运的是，autolayout机制的出现，大大减小了开发者在适配方面的成本。以上提到的两种布局方式，在以前博客中有讨论：
子类可以重写此方法，因为需要更精确执行他们子视图的布局。只有当 autoresizing 和基于约束的行为的子视图不提供你想要的行为，应重写此方法。
1.系统适配：针对不同版本的操作系统进行适配 2.屏幕适配：针对不同大小的屏幕尺寸进行适配
3、 设置view的Frame会触发layoutSubviews，当然前提是frame的值设置前后发生了变化。
可是是用initWithFrame 进行初始化时，当rect的值不为CGRectZero时,也会触发
但是是用initWithFrame 进行初始化时，当rect的值不为CGRectZero时,也会触发
学习了一下UIView的setNeedsDisplay和setNeedsLayout方法。首先两个方法都是异步执行的。而setNeedsDisplay会调用自动调用drawRect方法，这样可以拿到UIGraphicsGetCurrentContext，就可以画画了。而setNeedsLayout会默认调用layoutSubViews，就可以处理子视图中的一些数据。 宗上所诉，setNeedsDisplay方便绘图，而layoutSubViews方便出来数据。 \
最近项目中需要实现视频监控功能，于是就用了某企业旗下的一款视频监控产品，在集成官方Dome中的监控画面播放的功能时，发现整个项目都是通过StoryBoard搭建的，然而我的项目是没有使用StoryBoard，纯代码开发，如果我用纯代码重写里面的功能逻辑当然也是行的，只是花费的时间和精力可想而知，这酸爽，谁试谁知道。
这个方法，默认没有做任何事情，需要子类进行重写 。 系统在很多时候会去调用这个方法：
第1章 Interface Bundle 概要 ---- Bundle 一种标准化的层次结构，保存了可执行代码及代码所需要的资源。 nib Next Interface Builder Interface Builder 的优点 开发和维护效率高 减少大量的 UI 代码和“胶水代码” 适配变得十分简单 IB 也可以做一些非 UI 的事情 利用 IB 学习控件可以达到事半功倍的效果 Interface Builder 的缺点 IB 的执行效率没有纯代码高 使用 IB 开发的过程中容易出现一些小问题 有一定的学
Window是UIWindow class下的实例并且处理了总体的application的UI的展现。大部分来说，app的window不会有变化。 View是在CALayers之间的连接处工作，去渲染和变换view的内容。所有UIKit的view背后都有一个layer对象（通常是CALayer 的class），这些layer对象是存储views和处理view相关的动画。 CALayer对象的作用对性能有很大的提升。实际view对象的drawing代码调用越少越好，并且当代码被调用，结果会被Cor
关于界面布局，apple的策略已经趋于成熟，autolayout的优势在开发中也已经展现的淋漓尽致。除了使用storyBoard进行布局约束的拖拽，有时我们也需要在代码中进行autolayout的布局设置，Masonry库可以方便的创建约束属性，实际上，我们也没有必要再使用系统原生的代码来创建和设置约束，这篇博客只作为使用的方法备忘。前几篇布局介绍的链接如下：
每年iOS升级，都会带来一些坑，这次iOS9也不例外。本文总结了微信在适配iOS9上遇到的问题和解决方案。 一、iOS9问题汇总 1. 编译问题（Bitcode） 大部分人升级到Xcode7后，首先遇到的问题是编译不过，错误提示大致是 xxx does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated libra
布局想必大家都知道，在iOS 中我们使用代码计算屏幕宽高布局，使用Autoresizing和AutoLayout进行布局。在web中的布局一般都是依靠CSS的盒子模型，09年W3C提出了一种新的布局方案，Flex布局。ReactNative就是选用了这种布局方式。下面我们来看下FlexBox布局吧。
Masonry的核心依然是使用原生的NSLayoutConstraint类来进行添加约束，通过统一的封装和链式函数式编程的方式让开发者添加约束布局更加方便。
前言 UI布局是整个前端体系里不可或缺的一环。代码的布局是设计语言与用户视觉感受沟通的桥梁，不论它看起来多么简单或是琐碎，但不得不承认，绝大部分软件开发的问题，都是界面问题。那么，如何高效的完成UI开
不管你信与不信，这都不是真的。 因为最近公司的项目要上二版，然而我还没有提前完成他的决心，所以，你懂得。
UI布局是整个前端体系里不可或缺的一环。代码的布局是设计语言与用户视觉感受沟通的桥梁，不论它看起来多么简单或是琐碎，但不得不承认，绝大部分软件开发的问题，都是界面问题。那么，如何高效的完成UI开发，也是软件行业一直在克服的问题。
先前写到的一篇Masonry心得文章里已经提到了很多AutoLayout相关的知识，这篇我会更加详细的对其知识要点进行分析和整理。
在iOS中，您可以使用windows和views在屏幕上显示应用程序的内容。 Windows本身没有任何可见的内容，但为应用程序的views提供了一个基本的容器。 views定义了您想要填充某些内容的windows的一部分。 例如，您可能具有显示图像，文本，形状或其组合的views。 您还可以使用views来组织和管理其他views。
Swift-MVVM 简单演练(二) Swift-MVVM 简单演练(三) Swift-MVVM 简单演练(四) 前言 最近在学习swift和MVVM架构模式，目的只是将自己的学习笔记记录下来，方便自己日后查找，仅此而已！！！ 本来打算一篇全部搞定的，但是简书每篇文章只能写大约不超过15000字的内容，因此只能分开写了。 如果有任何问题，欢迎和我一起讨论。当然如果有什么存在的问题，欢迎批评指正，我会积极改造的！ ---- 这篇文章都写啥 自定义NavgationBar 抽取便利构造函数 初步的下拉刷新/上
一个时间轴的组成 使用一个块级元素包裹内容，并未块级元素设置边框 定义圆形或者菱形等元素标签，子元素设置偏移或者定位元素将图标定位到边框上 使其中的内容不溢出，自动换行，内容自动撑高 英文自动换行：word-wrap:break-word;word-break:break-all 时间轴样式部分 使用时需要注意可能继承的样式会给li:after等伪类元素设置样式而造成效果异常 css中定义了一个圆形的图标class="yuan"，一个菱形的图标class="diamond" <style>
网上有很多LaTeX软件，在线编辑器推荐Overleaf。但是我个人还是更喜欢离线写东西，所以尝试过各种编辑器，例如VSCode等等，这些编辑器都需要自己搭环境才能用，反正对于我们这种初学者而言门槛较高，而且浪费时间，所以下面介绍一个LaTeX组合可以让你直接上手体验LaTeX，而不需要挣扎在LaTeX的门口。
Cheddar/cheddar/cheddar-messaging/src/main/java/com/clicktravel/cheddar/infrastructure/messaging/MessageSender.java
rocketmq-all-4.6.0-source-release/remoting/src/main/java/org/apache/rocketmq/remoting/netty/NettyRequestProcessor.java
正值如今这信息爆炸的年代，如何能从中汲取精华，于有限时间内，成为更高效的学习者，从而在激烈的竞争中更具优势，是当下每个人或企业都该思虑的问题；先前创立的 Web 应用：「倾城之链」，就是为改善这一困扰的探索尝试，具体可参见关于 | 「倾城之链」。这份为前端开发者而精心维护的超棒列表，就是为解决信息过剩问题的具体实践：旨在为前端学习，技能提升，视野扩展，资料查找等提供价值性参考。目前选择性收录优质仓库近百个，涉及 Web 前端、后台、流行技术以及其他魔力清单。
test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test t
本文主要研究下spring mvc的No thread-bound request found异常
执行test_Demo1模块里的TestDemo1类里的test_case1方法；
本文主要研究一下openmessaging的MessagingAccessPoint
既然资源的加载是通过 Resource 类，如果想要获取另一个 apk 中的资源文件，那么自己实例化一个 Resource 进行加载可以吗？
Cheddar/cheddar/cheddar-tx/src/main/java/com/clicktravel/cheddar/infrastructure/messaging/tx/MessageAction.java
之前几篇文章，主要围绕着身份认证的相关内容，今天主要讨论一下认证状态的保持，由于HTTP协议是无状态的，因此在认证成功之后，为了让后续的请求可以继续保持住这个认证状态，避免每次请求都要重新发起认证过程，就需要对认证结果进行持久化，然后在新的请求到达时查询并还原回来对应的认证状态，通常有两种实现方案，一种是经典的cookie-session方案，即在服务端的session属性中存取认证信息，优点是实现方法比较简单，另一种是token令牌方案，利用一些算法对认证信息进行编码和解码，优点是无需落地，有效地减轻服务端存储的压力，本文主要介绍Spring Security框架中基于session的认证及常用的管理机制。
在上一篇，求知 | 聊聊Android资源加载的那些事 - 小试牛刀 中，我们通过探讨 Resource.getx() ,从而解释了相关方法的背后实现, 明白了那些我们日常调用方法的背后实现。
上一篇文章主要介绍了如何使用SpringSession，其实SpringSession的使用并不是很难，无非就是引入依赖，加下配置。但是，这仅仅只是知其然，要知其所以然，我们还是需要深入源码去理解。在看本文先我们先想想，下面这些问题Session是啥时候创建的呢？通过什么来创建的呢？创建之后如何保存到Redis？又是如何把SessionId设置到Cookie中的呢？带着这一系列的问题，今天就让我们来揭开SpringSession的神秘面纱，如果读者朋友们看完本文之后能够轻松的回答上面的问题，那本文的作用也就达到了。当然，如果您已经对这些知识了若指掌，那么就不需要看本文了。 看源码的过程真的是一个很枯燥乏味的过程，但是弄清楚了其调用过程之后，又是很让人兴奋的，话不多说，直接进入正题。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/164436.html原文链接：https://javaforall.cn
本文只是一个基本的统计策略baseline，分数一般，可以继续优化或者作为融合的一部分。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
