APP是您的自定义代码和系统框架之间相互作用的结果。 系统frameworks提供了所有应用程序需要运行的基本基础架构，并提供了定制基础架构所需的代码，并为APP提供所需的外观和感觉。 为了有效地做到这一点，有助于理解一些关于iOS基础设施以及它的工作原理。
iOS框架在其实现中依赖于设计形态，例如模型、视图控制器、和代理。 了解这些设计形态对于创建成功的APP至关重要。 这也有助于熟悉Objective-C语言及其功能。 如果您不熟悉iOS编程，请阅读开始开发iOS应用程序（Swift），以了解iOS应用程序和Objective-C语言的介绍。
主函数
每个基于C的应用程序的入口点都是主函数，iOS应用程序也不例外。 与iOS应用程序不同的是，您不需要自己编写主函数。 相反，Xcode创建这个主函数作为你的基本项目的一部分。 清单2-1显示了这个函数的一个例子。 除了少数例外，你绝不应该改变Xcode提供的主函数的实现。
下面代码是ios app的主函数
#import <UIKit/UIKit.h>
#import "AppDelegate.h"
int main(int argc, char * argv[])
{
@autoreleasepool {
return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
}
}
关于主函数唯一要提及的是它的工作是将控制交给UIKit frameworks。 UIApplicationMain函数通过创建应用程序的核心对象，从可用的storyboard文件加载您的应用程序的用户界面，调用您的自定义代码，以便您有机会进行一些初始设置，并将应用程序的持续运行。 唯一必须提供的是storyboard文件和自定义初始化代码。
APP的结构
在启动过程中，UIApplicationMain函数设置了几个关键对象来启动APP运行。 每个iOS应用程序的核心都是UIApplication对象，其工作是促进系统和APP中其他对象之间的交互。 图2-1显示了大多数应用程序中常见的对象，而表2-1列出了每个对象所扮演的角色。 首先要注意的是iOS应用程序使用模型 - 视图 - 控制器体系结构。 这种模式将应用程序的数据和业务逻辑从数据的可视化表示中分离出来。 此架构对于创建可在不同屏幕尺寸的不同设备上运行的应用程序至关重要。
ios APP中的关键对象，如下图所示
这些对象在ios APP中扮演的角色
每个iOS APP的区别在于它管理的数据（以及相应的业务逻辑）以及它如何将该数据呈现给用户。 大多数与UIKit对象的交互不会定义您的应用，但可以帮助您优化其行为。 例如，您的应用程序委托的方法可让您知道应用程序何时更改状态，以便您的自定义代码可以做出适当的响应。
主运行循环
APP的主运行循环处理所有与用户相关的事件。 UIApplication对象在启动时设置主运行循环，并使用它来处理事件并处理基于视图的接口的更新。 顾名思义，主运行循环在应用程序的主线程上执行。 此行为可确保用户相关事件按其接收顺序连续处理。
下图显示了主运行循环的体系结构以及用户事件如何导致应用程序执行的操作。 当用户与设备交互时，与这些交互相关的事件由系统生成并通过UIKit设置的特殊端口传送到应用程序。 事件由应用程序在内部排队，并逐个派发到主运行循环执行。 UIApplication对象是第一个接收事件并对需要做什么做出决定的对象。 触摸事件通常分派给主窗口对象，然后将其分派到发生触摸的视图。 其他事件可能通过不同应用程序对象略有不同的路径。
下图为处理主运行循环中的事件
iOS应用可以提供多种类型的事件。 最常见的是下面的图表。 许多这些事件类型都是使用应用程序的主运行循环提供的，但有些不是。 一些事件被发送到委托对象或传递给您提供的block。 有关如何处理大多数类型的事件（包括触摸，遥控，动作，加速度计和陀螺事件）的信息，请参阅iOS事件处理指南
ios APP常见的事件类型
一些事件（如触摸和远程控制事件）由APP的响应对象处理。 响应者对象在您的APP中无处不在。 （UIApplication对象，view和view controller对象都是响应者对象的示例。）大多数事件针对特定的响应者对象，但如果需要处理事件，则可以将其传递给其他响应者对象（通过响应者链）。 例如，不处理事件的视图可以将事件传递给它的父view或viewcontroller。
在控件中发生的触摸事件（例如按钮）的处理方式与在许多其他类型视图中发生的触摸事件的处理方式不同。 通常只有有限数量的与控件交互的可能性，因此这些交互被重新打包成动作消息并传递给适当的目标对象。 此目标操作设计模式可以轻松使用控件来触发应用中自定义代码的执行。
APP的执行状态
在任何特定时刻，您的应用程序都位于表2-3中列出的其中一个状态。 系统会响应整个系统发生的操作将您的应用程序从一个状态转移到另一个状态。 例如，当用户按下主页按钮时，电话进入，或发生任何其他中断，当前正在运行的应用程序改变状态作为响应。 下图显示了从一个状态转移到另一个状态时应用程序所需的路径。
下图为状态改变示意图：
大多数状态转换都伴随着对APP的代理对象方法的相应调用。 这些方法是您以适当方式对状态变化作出反应的机会。 下面列出了这些方法，以及如何使用它们的摘要。
- application：willFinishLaunchingWithOptions： - 此方法是您的应用程序在启动时首次执行代码的机会。
- application：didFinishLaunchingWithOptions： - 此方法允许您在应用程序显示给用户之前执行任何最终的初始化。
- applicationDidBecomeActive： - 让您的应用程序知道它即将成为前台应用程序。 使用此方法进行最后一分钟的准备。在应用程序处于非活动状态时，重新启动已暂停（或尚未启动）的任何任务。 如果应用程序以前位于后台，则可以选择刷新用户界面。
- applicationWillResignActive：让你知道你的应用程序正在转变成前台应用程序。 使用此方法将您的应用程序置于静止状态。当应用程序即将从活动状态转移到非活动状态时发送。 对于某些类型的临时中断（例如来电或SMS消息）或用户退出应用程序并开始转换到后台状态时，可能会发生这种情况。
使用此方法可暂停正在进行的任务，禁用定时器并降低OpenGL ES帧速率。 游戏应该使用这种方法来暂停游戏。 - applicationDidEnterBackground：让您知道您的应用程序现在正在后台运行，并且可能随时暂停。使用此方法释放共享资源，保存用户数据，使计时器无效并存储足够的应用程序状态信息，以便将应用程序还原到其当前状态，以防稍后终止。
如果您的应用程序支持后台执行，终止操作应该在applicationWillTerminate：用户退出时。 - applicationWillEnterForeground：让你知道你的应用正在移出背景并回到前景，但它尚未激活。
- applicationWillTerminate：让你知道你的应用程序正在终止。 如果您的应用已被暂停，则不会调用此方法。当应用程序即将终止时调用。 如果适用，保存数据。 另请参阅applicationDidEnterBackground。
APP终止
应用程序必须随时准备终止发生，而且可能等不到保存用户数据或正在执行其他关键任务时发生终止。 APP的终止是应用程序生命周期的正常组成部分。 该系统通常会终止应用程序，以便它可以回收内存并为用户启动的其他应用程序腾出空间，但系统也可能会终止错误操作或未及时响应事件的应用程序。
挂起的APP在终止时不会收到通知; 系统杀死进程并回收相应的内存。 如果应用程序当前正在后台运行并且未挂起，系统会在终止之前调用APP委托的applicationWillTerminate：。 设备重新引导时，系统不会调用此方法。
除系统终止您的应用程序外，用户还可以使用多任务界面显式终止您的应用程序。 用户发起的终止与终止暂停的应用具有相同的效果。 应用程序的进程被终止并且没有通知被发送到应用程序。
线程与并发
系统创建您的应用的主线程，您可以根据需要创建其他线程来执行其他任务。 对于iOS应用程序，首选技术是使用Grand Central Dispatch（GCD），操作对象和其他异步编程接口，而不是自己创建和管理线程。 像GCD这样的技术可以让你定义你想要做的工作和你想要做的工作，但让系统决定如何在可用的CPU上执行这个工作。 让系统处理线程管理可以简化必须编写的代码，更容易确保代码的正确性，并提供更好的整体性能。
在考虑线程和并发性时，请考虑以下几点：
- 涉及视图，核心动画和许多其他UIKit类的工作通常必须在应用程序的主线程上进行。 这条规则有一些例外 - 例如，基于图像的操作通常可能发生在后台线程上 - 但是如果有疑问，假设工作需要在主线程上发生。
- 应该始终在后台线程上执行冗长的任务（或潜在的长度任务）。 涉及网络访问，文件访问或大量数据处理的任何任务均应使用GCD或操作对象异步执行。
- 在启动时，尽可能将任务从主线程移出。 在启动时，您的应用程序应尽可能快地使用可用的时间来设置其用户界面。 只有在主线程上执行有助于设置用户界面的任务。 所有其他任务应该异步执行，一旦准备就绪，结果就会显示给用户。