(IOS)从UIApplication到runLoop

本文深入探讨了iOS应用启动过程中的关键步骤,包括main函数的工作原理、引用计数的实现方式、autoreleasePoolPage的设计特点以及弱引用变量的管理机制。同时,文章还介绍了iOS中的事件循环(RunLoop)机制。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1.main函数中执行了一个UIApplicationMain, return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
arc表示传入的参数的个数,一般是1,有些情况当用户需要输入一些参数的时候,比如脚本语言./sh main.sh numberOne numberTwe ,此时arc就会等于3,因为额外的增加了两个参数。
argh是具体的参数列表,是一个二维数组,存储字符串,默认的第一个是程序文件的路径位置。
第三个参数指定程序的类名,该类必须是UIApplication(或者子类),如果为nil,则使用UIApplication类作为默认值。
第四个参数指定程序的代理类,该类必须遵守UIApplicationDelegate协议。
UIApplicationMain 函数会根据第三个参数创建一个UIApplication对象,根据第三个参数创建一个delegate对象,并将该delegate对象赋值给UIApplication对象中的delegate属性,接着会建立一个应用程序的Main Runloop(事件循环),进行事件的处理(首先会在程序完毕后调用delegate对象的application:didFinishLauchingWithOptions:方法),程序正常退出的时候UIApplication函数才会返回。
这里写图片描述
小插曲之1ios引用计数的实现特点
按照我们一般的思路就是一个内存变量的头部会记录一个count值,初始化的时候会默认count=1,没次遇到别的指针指向这里的时候就会把引用计数加1,当没次释放一个指针引用的时候就把count减1,这种思路在boost开源库里面有大量的实践,里面的shared_ptr等实现皆都是这种原理,可是我们的苹果的实现却独树一帜,比较有意思。
这里写图片描述
总结一下:
1.额外的开辟了一片空间来保存引用计数的值,增加了代码的复杂度。
2.对象用内存来分配的时候无需考虑内存的头部,单独的维护一个散列表,可以直接对内存的详细使用情况有一个比较的了解与控制,对内存的泄漏也容易检测。

小插曲之2autoreleasePoolPage的实现特点
这里写图片描述
总结一下:
1.自动释放池是可以嵌套的,这就可以让局部的大量占用内存的变量在出了作用域会得到及时的释放。
2.整块整块的空间开辟,每块空间又用栈的方式存储,设计思路就是为了减少寻址性能消耗。

小插曲之3IOS main 函数中为何要包着 @autoreleasepool ?
这里写图片描述
应该从ARC开始讲起吧。在ARC中,系统自动帮对象调用了autorelease方法,然后就会把对象扔进池里面,等第一次runloop结束,这个池会被系统销毁,池里面的对象也就跟着被销毁了。跟MRC的release方法比较就是延迟了对象的销毁的时间。综上,它就是一个管理对象销毁的容器。

小插曲之http协议介绍
http://mp.weixin.qq.com/s?__biz=MzAxNDI5NzEzNg==&mid=2651157036&idx=1&sn=9616b9c6e383a68e15322ef176bec6a5&scene=1&srcid=0826Jxe58001Vy7D9tljftd7#rd

小插曲之weak变量的特点
释放对象时,废弃谁都不持有的对象的同时,程序的动作是怎么样子的呢?
1.objc_release
2.因为引用计数为0所以执行dealloc
3._objc_rootDealloc
4.object_dispose
5.objc_destructInstance
6.objc_clear_deallcation
对象被废弃的时候最后调用objc_clear_deallocating函数的动作如下:
(1)从weak表中获取废弃对象的地址为键值的记录。
(2)将包含在记录中的所有附有__weak修饰变量的地址,赋值为nil。
(3)从weak表中删除该记录。
(4)从引用计数表中删除废弃对象的地址为键值的记录。
如果大量的使用weak变量会消耗相应的CPU资源,所以在没有必要的时候我们就应该选择不要使用weak,在十分必要的时候例如在需要避免循环引用的时候使用__weak修饰符号。

在UIApplicationMain()函数中,这个方法会为main thread设置一个NSRunLoop对象,此刻开始的一个do while循环开始。
对于其它的线程而言,run loop默认是没有启动的,如果你需要更多的线程交互则需要手动配置和启动,如果线程只是去执行一个长时间的已确定的任务则不需要了。
NSRunLoop *runloop = [NSRunLoopcurrentRunLoop];来获取当前的线程run loop。
Cocoa中的NSRunLoop类并不是线程安全的。
Run loop同时也负责autorelease loop的释。
run loop就是一个事件处理循环,用来不停的监听和处理输入事件并将其分配到对应的目标上面进行处理。
run loop可以使线程在有工作的时候工作,没有工作的时候就休眠,可以大大的节省系统资源。

思考1:
代码风格1,尽量使用NSInter代替int,使用CGFloat代替float等等标准的类型代替c语言遗留的风格。

### 关于 `UIApplication` 的用法及其在 iOS 18 中的变化 #### 背景介绍 自 iOS 系统发布以来,`UIApplication` 类一直是开发者用于管理应用生命周期的核心工具之一。它提供了访问全局对象的方法以及处理事件循环的功能。随着 iOS 不断更新迭代,苹果公司也在逐步调整该类的行为和接口设计。 #### iOS 18 中的关键变化 尽管官方文档未明确指出 `UIApplication` 在 iOS 18 中的具体改动,但从开发者的实践经验来看,以下几点值得注意: 1. **隐私与安全增强** 苹果公司在 iOS 18 继续加强了对用户数据保护的要求。对于通过 `sharedApplication` 获取实例并调用某些方法的情况,可能需要额外声明权限或遵循新的沙盒机制[^4]。这意味着任何涉及敏感操作(如网络请求、设备状态查询)的代码都需要重新评估合规性。 2. **弃用 API 替代方案** 随着时间推移,部分旧版 API 已经被标记为废弃。例如,在较早版本中提到过的 `wantsFullScreenLayout` 属性已被替代[^3]。虽然这并非直接影响 `UIApplication` 自身,但它反映了整个框架向现代化方向演进的趋势——鼓励开发者采用更灵活的设计模式来实现相同目标而不依赖特定属性配置。 3. **多窗口支持改进** 尽管全面意义上的 iPadOS 多任务特性是在后续版本才正式推出,但在 iOS 18 上已经可以看到一些铺垫工作。具体表现为当应用程序处于分屏或多任务环境下时,如何正确响应尺寸变更通知变得尤为重要。此时可以利用 `UIApplicationDelegate` 协议中的回调函数配合 `UIWindowSceneDelegate` 来适配不同场景下的行为逻辑。 4. **后台执行限制收紧** 对于那些试图绕过系统规定延长后台运行时间的应用程序来说,iOS 18 加大了监管力度。如果发现违规现象,则可能导致 AppStore 提交失败或者遭到下架处罚[^5]。因此建议仅限必要情况下申请适当类型的 Background Task 并严格控制其持续周期。 以下是展示如何获取单例对象并与之交互的一个简单例子: ```swift if let window = UIApplication.shared.windows.first { print("Main Window Frame:", window.frame) } ``` 此片段展示了怎样安全地访问当前活动窗口的信息而无需担心潜在崩溃风险。 --- ### 总结 综上所述,虽然表面上看似乎没有针对 `UIApplication` 做出特别显著的大规模重构动作;但实际上围绕安全性考量所做的种种微调却足以影响日常编码实践。务必密切关注最新指南说明以免无意间触犯政策底线造成不必要的麻烦。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值