iOS面试题与核心基础之定时器

常用的就这三种

  • NSTimer
    适用于准确度要求没那么高的场景

  • CADisplayLink
    run loop在完成UI刷新后会调用CADisplayLink,使其调用频率跟屏幕刷新率相同。
    适用于UI刷新相关的功能,如视频渲染,高精度动画。(短信重发倒计时,轮播就算了,秒级别没必要用牛刀)

  • GCD定时器
    适合精度要求非常高的场景
    NSTimer 和 CADisplayLink 需要添加到RunLoop才会执行,因其本质上是由RunLoop触发。
    GCD定时器不需要,其由内核的dispatch触发。
    run loop 不可靠,繁忙的时候就不理你,所以要求精确就只能用GCD。


NSTimer 和 CADisplayLink被添加到RunLoop之后还有两个坑。
  • RunLoopMode
    如果只被添加到 RunLoopDefaultMode ,那么在界面滚动的时候主线程的RunLoop会切换到 UITrackingRunLoopMode用于跟踪界面滚动,那么定时器将不会触发

  • 循环引用问题
    使用-invalidate方法将定时器从run loop移除,再设置为nil销毁定时器能解决循环引用问题。但是-invalidate不能写在target对象的delloc里面(),因为在timer销毁之前target没有销毁的机会。新的block创建方式可以不引用target了,遗憾的是iOS10+才能用。
    使用全局的定时器(包含单例持有定时器)也能解决不持有target。
    不持有定时器也能解决循环引用,但是这时候就无法销毁定时器了,内存泄露。

关于invalidate方法的官解阐释
Stops the receiver from ever firing again and requests its removal from its run loop
This method is the only way to remove a timer from an NSRunLoop object

如果你要适配低版本,还有个中间代理弱引用的方式。
直接看代码

#import <Foundation/Foundation.h>

@interface ALProxy : NSObject
+ (instancetype)proxyWithTarget:(id)target;
@property (weak, nonatomic) id target;
@end

@implementation ALProxy

+ (instancetype)proxyWithTarget:(id)target
{
    MJProxy *proxy = [[MJProxy alloc] init];
    proxy.target = target;
    return proxy;
}

- (id)forwardingTargetForSelector:(SEL)aSelector
{
    return self.target;
}

@end

self.timer = [NSTimer scheduledTimerWithTimeInterval:1.0 target:[ALProxy proxyWithTarget:self] selector:@selector(timerTest) userInfo:nil repeats:YES];


定时器都有后台不执行的问题

解决方案也得看业务的具体需求

  • 第一种是记录进入后台和返回前台的时间差,然后相关统计时间扣掉这个时间。
    适用于时间统计类的
  • 第二种就是要保持后台也不断执行,需要开启background mode
    适用于不断上报定位、发送心跳包等这一类型。
如果你是个懒人,想复制粘贴就解决以上问题,还想多个定时器并存,那给你吧

希望你读完了,发现哪里有问题能反馈一下
啥? 不会Swift?那无能为力了,这都swift 5+ 了

/// 全局定时器
class TimerManager {
    /// 定时器缓存
    private var timers: [String: Any] = [:]
    /// 定时器key缓存
    private var timerKeyCache: [String] = []

    /// 因为涉及到多线程同时读写,为了避免出现错误,执行数据变更时需要加锁操作
    private let semaphore = DispatchSemaphore(value: 1)

    static let shared = TimerManager()

    /// 定时器
    /// - Parameters:
    ///   - timerKey: 定时器唯一key
    ///   - target: target
    ///   - selector: Selector 要执行的方法
    ///   - start: DispatchTime 开始时间
    ///   - interval: TimeInterval 延时时长 默认1s
    ///   - repeats: 是否重复
    ///   - async: 是否异步
    /// - Returns: 是否开启定时器成功
    func schedule(timerKey: String, target: NSObject, selector: Selector, start: DispatchTime = .now(), interval: TimeInterval = 1, repeats: Bool = true, async: Bool = true) -> Bool {
        guard !timerKey.isEmpty || start.rawValue <= 0 || interval <= 0 else {
            return false
        }

        if timerKeyCache.contains(timerKey) {
            return false
        }

        let timerQueue = async ? DispatchQueue.global() : DispatchQueue.main
        let timer = DispatchSource.makeTimerSource(queue: timerQueue)
        semaphore.wait()
        timers[timerKey] = timer
        timerKeyCache.append(timerKey)
        semaphore.signal()
        timer.schedule(deadline: start, repeating: interval)
        timer.setEventHandler { [weak self] in
            if target.responds(to: selector) {
                target.perform(selector)
            }
            if !repeats {
                _ = self?.cancelTimer(forKey: timerKey)
            }
        }
        timer.resume()
        return true
    }

    /// 取消定时器
    /// - Parameter timerKey: 定时器唯一key
    /// - Returns: 是否关闭成功
    func cancelTimer(forKey key: String) -> Bool {
        guard !key.isEmpty else {
            return false
        }

        guard let timer = timers[key] as? DispatchSourceTimer else {
            return false
        }

        timer.cancel()
        semaphore.wait()
        if let index = timerKeyCache.firstIndex(of: key) {
            timerKeyCache.remove(at: index)
        }

        timers.removeValue(forKey: key)
        semaphore.signal()
        return true
    }
}
面试题
  1. iOS 为什么把NSTimer对象以NSDefaultRunLoopMode(kCFRunLoopDefaultMode)添加到主运行循环以后,滑动scrollview的时候NSTimer却不动了?

主线程的 RunLoop 里有两个预置的 Mode:kCFRunLoopDefaultMode 和 UITrackingRunLoopMode。这两个 Mode 都已经被标记为”Common”属性。DefaultMode 是 App 平时所处的状态,TrackingRunLoopMode 是追踪 ScrollView 滑动时的状态。当你创建一个 Timer 并加到 DefaultMode 时,Timer 会得到重复回调,但此时滑动一个TableView时,RunLoop 会将 mode 切换为 TrackingRunLoopMode,这时 Timer 就不会被回调,并且也不会影响到滑动操作

  1. 定时器切到后台就不走了,如何解决这个问题?
### 构建任务失败解决方案 当遇到 `Execution failed for task ':app:shrinkReleaseRes'` 错误时,这通常意味着资源压缩过程中出现了问题。此错误可能由多种原因引起,包括但不限于配置不正确、依赖冲突或特定于项目的其他因素。 #### 可能的原因分析 1. **ProGuard 或 R8 配置不当** ProGuard R8 是用于优化混淆代码以及减少 APK 大小的工具。如果这些工具的配置存在问题,可能会导致资源无法正常处理[^1]。 2. **重复资源** 如果项目中有多个模块定义了相同的资源名称,可能导致冲突并引发该错误。检查是否存在重名的 drawable、string 等资源文件[^2]。 3. **第三方库兼容性** 某些第三方库可能当前使用的 Gradle 插件版本或其他库存在兼容性问题,从而影响到资源打包过程中的行为[^3]。 4. **Gradle 缓存问题** 有时旧缓存数据会干扰新编译的结果,尝试清理本地仓库重新同步项目可以帮助排除此类潜在障碍[^4]。 #### 推荐的操作方法 为了有效解决问题,建议按照以下步骤逐一排查: ```bash # 清理项目构建目录 ./gradlew clean # 删除 .gradle 文件夹下的所有内容以清除缓存 rm -rf ~/.gradle/caches/ ``` 调整 `build.gradle` 中的相关设置也是一个重要环节: ```groovy android { ... buildTypes { release { minifyEnabled true // 是否启用代码缩减 shrinkResources true // 是否开启资源压缩 proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' // 尝试禁用 shrinkResources 来测试是否为资源压缩引起的错误 // shrinkResources false } } } ``` 此外,在 `proguard-rules.pro` 文件内添加必要的保留规则,防止关键类被意外移除: ```text -keep class com.example.yourpackage.** { *; } # 替换为你自己的包路径 -dontwarn androidx.**,com.google.** # 忽略警告信息 ``` 最后,确保所使用的 Android Studio 版本是最新的稳定版,并且已经应用了所有的补丁更新。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值