导言

由于近一两月才上手iOS开发,对iOS开发相关的常识也仅是参与内部训练系统的学习了一个月罢了,期间整理并输出了一系列的文章:iOS 入门系列

可是,在真实上手项目开发后,我深深的体会到:短期的学习,确实让我了解了iOS 开发,可是真实开发的时候就会发现根底把握的不牢固,关于一些常识点的了解不是很清晰,或许直接说便是不知道

本篇文章的意图便是将我在开发过程中概念比较模糊的常识点罗列,并依照我的了解进行讲解,由于开发运用的是UIkit 结构,因此本篇文章是围绕其展开叙说的

根视图究竟是什么?

最近,被一个概念给搞懵了:根视图究竟是什么?开端我把它了解成栈的形式,最底端的那个视图便是根视图吧?其实,这样的了解是完全正确的,可是逐渐发现这个貌似又不太对……

在写了一个案例验证之后才发现:原来不是我了解的有问题,而是我对根底把握的不是太牢固

必备常识点

在了解根视图之前,先了解一下与根视图相关的一些常识点,所谓打好根底便是如此,了解了这些常识概念全部就会变得通俗易懂了~

UIApplication

UIApplication不直接办理视图,而是用于办理运用程序的生命周期、事情处理和办理运用程序等级的设置和协作等功能。它没有根视图,但它会创立运用程序的主窗口,并将根视图控制器(通常是一个UIViewController)添加到主窗口上。这个根视图控制器将成为运用程序的初始展现页面

UIApplication通过keyWindow特点供给了对主窗口 (UIWindow) 的拜访

UIWindow

UIWindow是一个表示运用程序的主窗口的类。每个iOS运用程序都有一个主窗口,它是运用程序中所有视图层次结构的顶级容器

UIWindow的首要作用是托管运用程序的视图层次结构,并供给一个可视化容器,用于显现运用程序的用户界面。它是视图控制器的容器,用于办理视图控制器的层次结构,并将其内容显现在屏幕上

根视图控制器 rootViewController

这是运用程序的初始展现页面,通常是一个UIViewController子类。它是整个运用的第一个视图控制器,用户将从这里开端运用程序的导航。根视图控制器可所以一个普通的视图控制器,也可所以一个容器视图控制器(如UITabBarControllerUINavigationController

标签栏控制器 UITabBarController

UITabBarController是一个容器视图控制器,用于办理多个子视图控制器,每个子视图控制器对应一个标签页。它的根视图是标签页中的一个,用户能够通过标签切换不同的子视图控制器

导航栏控制器 UINavigationController

UINavigationController也是一个容器视图控制器,用于完成导航仓库。它的根视图是仓库中的第一个视图控制器。用户能够从这个根视图导航到其他视图控制器,然后通过导航栏上的回来按钮回来到根视图

可视化解析

iOS 近期开发概念小结
如上图所示的视图结构,storyboard场景入口(在 iOS之UIkit 中有关于场景入口的介绍)是标签栏控制器(根视图控制器),然后它下面有两个子视图,其间导航栏控制器也是容器视图控制器,下面又接着两个子视图

好的,持续回到根视图这个论题,rootViewController只要一个,是程序的初始展现页面,能够通过主窗口拜访(例如:UIApplication.shared.keyWindow?.rootViewController),在上图中便是TabBarVC

关于标签栏控制器和导航栏控制器这两个容器视图控制器,它们也是存在根视图的,上图中的TabBarVC的根视图在我的程序中是NavigationVC,而NavigationVC的根视图能够很明确的看出是VC1

拓宽

UIApplicationUIWindow是UIKit结构中的两个中心组件,它们协同工作以完成运用程序的生命周期办理和用户界面的展现。UIApplication办理运用程序等级的事务,而UIWindow办理运用程序的用户界面的显现,我目前的了解:类似h5的main.jsindex.html

小结

根视图控制器担任运用程序的首要界面,能够包括其他视图控制器或视图;而容器视图控制器通常运用导航仓库来办理多个子视图控制器的切换,以便用户能够阅读和回来不同的页面。这种导航仓库的概念在UINavigationController中特别显着,由于它办理一个线性的视图控制器仓库

束缚又如何去了解?

好的,通过上面的描绘,关于根视图相关的概念大致都已经搞明白了,然后接下来便是涉及到页面布局的常识,这也是iOS 开发必须牢牢把握的根底常识,由于前端页面的开发页面布局的权重仍是比较高的

必备常识

要了解束缚,首要得知道UIkit中的常用的容器视图和视图有哪些,由于束缚便是发生在它们身上的

容器视图

容器视图是一种特别类型的视图,它能够包括其他视图(视图控件或容器视图)。容器视图的作用是将多个视图组织在一起,构成一个整体。容器视图能够控制其子视图的布局和摆放方法

常见的容器视图:

  • UIViewUIView本身也能够用作容器视图,将子视图添加到UIView中,并通过手动设置它们的方位和巨细来创立自界说布局
  • UIStackViewUIStackView是一个十分强壮的容器视图,用于完成堆叠布局,能够依照水平或笔直方向摆放其子视图
  • UIScrollViewUIScrollView是一个滚动容器,用于显现内容较多的视图,用户能够通过滚动来检查全部内容
  • UICollectionViewUICollectionView是用于创立杂乱布局的容器,特别合适显现类似网格的数据
  • UITableViewUITableView用于创立表格式布局,用于显现列表数据
  • UIPageViewControllerUIPageViewController用于创立页面切换的容器,适用于创立引导页、滑动图片阅读器等运用

视图

视图是 iOS 用户界面的根本构建块。它可所以按钮、标签、图画、文本框等等。每个视图都有自己的特点和行为,例如方位、巨细、布景色彩、文本内容等

常用的视图控件:

  • UILabel:用于显现文本标签
  • UIButton:按钮视图,用于触发操作或执行操作
  • UIImageView:显现图画或图标的视图
  • UITextFieldUITextView:文本输入视图,用于用户输入文本
    • UITextField合适需求单行文本输入的情况,例如:登录、搜索、注册表单等
    • UITextView合适需求多行文本输入的情况,例如:谈天运用中的音讯输入、日记编辑、评论框等

可视化解析

iOS 近期开发概念小结
如上图所示,在父容器视图UIView内部包括有三个子视图:UIViewUILabelUIButton,这些子视图之间能够通过束缚进行相对布局,也能够直接与父容器通过束缚进行相对布局。关于一个视图,它包括上下左右四个方向,与其他视图建立束缚时需求明确是哪个方向

然后在设置束缚时有insetoffset两种偏移方向,一个是内部偏移、一个是外部偏移,能够类比h5 布局的内边距(padding)和外边距(margin)

举例说明一下:UIButton的顶部与父视图UIView建立束缚,那么正常情况下便是UIButton的顶部与UIView的顶部构成束缚,这样UIView的高度便是主动布局而不是写死了,其他方向的束缚同理,这样就通过束缚完成了主动布局的作用

拓宽

当然,你可能会问:我想让UIButton的顶部和父视图UIView的底部构成束缚不行吗?非得顶部就和顶部建立束缚?

我的回答是当然能够,可是完全不主张,既然要和父视图底部建立束缚,用UIButton的底部不是更显而易懂?所以得出一个定论:在建立束缚时,主张是在同方向之间

小结

通过上面的描绘,大约也能了解束缚这个概念了吧?简略点来说便是通过束缚来完成父视图的主动布局以及子视图间的相对布局

至于我为什么会在这里卡住,大约是由于它和h5页面的布局写法差别有点大,再加上触摸不久吧,用习惯了就不难了解了~

delegate 便是一个特点?

前语

delegate(在 Swift 那些特有的语法结构 中的协议处有关于署理的介绍)在iOS 开发中应该属于重要而且相对难了解的常识点之一了吧

在我刚触摸到署理以及触摸了一段时间后,它给我的直观感触便是:这是类的一个特点?在通过一番查阅后,我发现它并不是看起来那么简略……

首要,能够将它了解为是一个特点,可是它是实例特点,由于不同的实例其值能够不同;然后,它的类型也比较特别,类型是一个协议

在这些界说好之后,就能够给类实例的delegate 特点进行赋值了。当然它赋值的目标也比较特别,得是一个遵从了与之相同协议的实例目标

后续

说实话,刚开端我不是很了解,由于在iOS 开发中协议就类似于接口,那不是直接完成接口(遵从协议)即可?为什么还要加一个署理?有什么差异吗?在某一次灵光一闪,画了一张图之后,我感觉我有些悟了,哈哈哈,然后回过头去看运用它的一些优点,也慢慢的了解到了

下面附上我所说的图:

iOS 近期开发概念小结
上图中,我还将承继也给画了出来,尽管不是很相关,仅仅差异一下其与接口罢了;首要的仍是看接口和协议署理的差异:署理其实便是完成接口的拓宽版,更具模块化了,当协议需求修改时,只需求改动遵从协议的类即可,然后署理给需求运用的原始类,不管协议如何修改,原始类都不会受到影响

协议的优点:

  • 松懈耦合:署理形式允许目标之间的联系愈加松懈,一个目标能够托付其它目标来处理某些使命,而不需求了解详细的完成细节
  • 单一责任准则:署理形式有助于遵从单一责任准则,即每个目标应该只担任一项使命。通过将使命托付给署理目标,原始目标能够专心于其首要责任,而署理能够专心于处理托付的使命
  • 模块化和可保护性:署理形式使代码更具模块化,易于保护和扩展。新的署理目标能够轻松地添加,而不会影响到原始目标
  • 接口阻隔:署理形式有助于阻隔接口,使得客户端目标只需知道署理的接口而不需求了解详细完成