肇鑫的技术博客

肇鑫 / Owen Zhao

独立开发者,主要开发 iOS、watchOS、macOS 应用。

目前在维护 SleepTapRooster Time,以及 Markdown Writer 相关工具。

最新文章

iOS、watchOS应用用户设置相关问题的答案

watchOSiOS

最近在写咕唧2,对于iOS应用与配套watchOS应用之间的设置的相关问题有了一些心得。记下来,备查。

问题与答案

1. 创建的Settings.bundle文件放在哪里?

无论iOS还是watchOS的,都放在iOS应用下。

2. iOS应用的设置,为什么watchOS应用不能直接读了?

这是一个历史遗留问题。1代的手表系统,当时还不叫watchOS,上的应用只有一种,叫瞥一眼(glance)。生成机制是所有的一切都在手机上生成,然后传到手表上显示。因此,当然手机应用和手表应用实际上都在手机上运行。因此,直接通过分享组(share group),手表应用就能读取手机应用的设置。

watchOS 2开始,手表应用改在手表上运行了。而手表上的共享组和手机上的共享组之间不自动同步,所以手表和手机之间的设置不能直接读了。

3. iOS应用如何获得watchOS应用的设置?

不能直接读。因为苹果规定,手表应用可以唤醒手机应用,反之则不行。

4. watchOS应用如何获得iOS应用的设置?

通过session的sendMessage方法唤醒手机,然后手机发送设置给手表。

5. 如何设置watchOS应用的设置?

通过手机端的手表应用。这个应用虽然在手机上,但是可以直接读手表应用的设置。并且会写回去。

一张图

iOS与watchOS的设置同步

参考资料

自定义UITableViewCell的选中背景

iOS

默认情况下,UITableViewCell的选中效果如图。单独选中的效果给人的感觉不是那么可靠。

但从编程角度看,使用选中状态比较简单。不使用选中,而采用标记替代选中比较麻烦。因为这个对号是属于UITableViewCellaccessoryType属性。它并不是和选中状态同步的。需要单独、小心地处理,稍有不慎,就会出现各种错误。

解决思路

创建一个背景透明的对号标记

我最初的想法是创建一个背景透明的对号标记。然后把它应用在UITableViewCellselectedBackgroundView属性上。

这条路不好走。因为一旦制定了selectedBackgroundView。表格之间的分隔线就没有。解决方案有利用各种方式画分隔线的。比较麻烦。

在我采用默认的表格,并允许多选时,我发现苹果的默认选中,就是没有分割线的,只不过它用了有颜色的背景。这在单选时不明显,一旦有多选,就很明显。

创建一个有背景色的对号标记

创建好的图片如图。

checkmark_background@2x

用1x的语言描述,背景:宽320,高44。对号:宽16,高32,水平居中,右边距16。

难点来了

我们知道,不同格式设备的宽度是不一样的。那么对于320这个iOS设备的最小宽度,这个图片在遇到更宽的设备时是需要拉伸的。

关于如何拉伸图片,我们可以看这篇:UIImage图片拉伸平铺(resizableImage)

看着不难,实际上全是坑。因为思维习惯不是直接的,是间接的。

简述一下拉伸图片的原理

如图,如果有一个图片,被分成1-9共9个部分。那么它的四个角的1、3、7、9图形保持不变。我们通过定义2/上、4/左、8/下、6/右的方式,来确定5的范围,然后选择拉伸5。这个就是定义图片拉伸的原理。

1 2 3
4 5 6
7 8 9

下面应用这个原理,放大上面的带对号的背景图。

checkmark_background 1-9@2x

因为我们需要保证对号的位置不变,所以要把它画在3的位置。这是唯一的限制。根据这个限制我们可以计算出。

  • 上:
    • 上边距 = (背景高 - 对号高) / 2 = (44 - 32) / 2 = 6
    • 上 = 上边距 + 对号高 = 6 + 32 = 38
  • 右 = 对号宽 + 右边距 = 16 + 16 = 32

至于下和左,我们因为要尽量保证5越大越好,就都取1。

最终代码如下:

override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
    let cell = tableView.dequeueReusableCell(withIdentifier: "sampleCell", for: indexPath)
    
    // 获得背景图
    let image = #imageLiteral(resourceName: "Checkmark_background")
    // 指定拉伸范围
    let edgeInsets = UIEdgeInsetsMake(38, 1, 1, 32)
    // 获得拉伸图片
    let resizableImage = image.resizableImage(withCapInsets: edgeInsets, resizingMode: .stretch)
    // 生成图片视图,大小与表格项相同
    let imageView = UIImageView(frame: cell.bounds)
    // 指定图片
    imageView.image = resizableImage
    // 指定表格项选中时的背景视图
    cell.selectedBackgroundView = imageView
    // 设定文字
    cell.textLabel?.text = "条件\(indexPath.row)"

    return cell
}

最终效果

如图:

fina

UIImageView异步加载导致问题的解决

iOS

UIImageView加载了一张图片之后,如果再加载另外一张图片,然后立即删除第二张图片。则UIImageView会变黑。

演示代码如下:

import UIKit

class ViewController: UIViewController {
    lazy var image = { () -> UIImage? in
        guard let path = Bundle.main.path(forResource: "poster_icon_mac_1024", ofType: "png") else {
            return nil
        }
        
        return UIImage(contentsOfFile: path)
    }()
    
    lazy var replaceImage = { () -> UIImage? in
        guard let path = Bundle.main.path(forResource: "Miss Devil 恶魔人事·椿真子.Miss.Devil.Jinji.no.Akuma.Tsubaki.Mako.Ep05.Chi_Jap.HDTVrip.1280X720-0001", ofType: "png") else {
            
            return nil
        }
        
        return UIImage(contentsOfFile: path)
    }()
    
    lazy var saveImageURL = { () -> URL in
        let baseURL = FileManager.default.urls(for: .cachesDirectory, in: .userDomainMask).first
        let fileName = UUID().uuidString + ".jpg"
        
        return URL(fileURLWithPath: fileName, isDirectory: false, relativeTo: baseURL)
    }()
    
    var latestImage:UIImage? = nil

    override func viewDidLoad() {
        super.viewDidLoad()
        // Do any additional setup after loading the view, typically from a nib.
        
        addImage()
        
        DispatchQueue.main.asyncAfter(wallDeadline: .now() + .seconds(2)) { [unowned self] in
            self.createImage()
            self.loadImage()
            self.changeImageViewToLatestImage()
            self.removeLatestImage()
        }
    }

    override func didReceiveMemoryWarning() {
        super.didReceiveMemoryWarning()
        // Dispose of any resources that can be recreated.
    }

    @IBOutlet weak var imageView: UIImageView!
    
    func addImage() {
        imageView.image = image
    }
    
    func changeImage() {
        imageView.image = replaceImage
    }
    
    func createImage() {
        let imageData = UIImageJPEGRepresentation(replaceImage!, 1.0)
        FileManager.default.createFile(atPath: saveImageURL.path, contents: imageData!, attributes: nil)
    }
    
    func loadImage() {
        latestImage = UIImage(contentsOfFile: saveImageURL.path)
    }
    
    func changeImageViewToLatestImage() {
        imageView.image = latestImage
    }
    
    func removeLatestImage() {
        try! FileManager.default.removeItem(at: saveImageURL)
    }
}

分析与解决

这个问题的造成,是因为为了性能,UIImageView其实是异步加载的。在它加载完成之前,如果图片被删除了,就会加载不到,变黑。

有人提出,可以将图片通过Data类型,加载到内存中,然后将内存中的图片加载到UIImageView的方式,来绕过这个问题。这个思路的确能解决这个问题,但是毕竟多占用了内存。不算是最好的方式。

其实,我们知道了原理,就等UIImageView加载完成之后,再删除图片就好了。虽然苹果并没有告诉我们图片何时加载好。但是我们知道,类似更新UI的这种操作,必然是在UI线程完成的,即main线程。那么我们只需要在main队列排队一下就可以了。

将代码

DispatchQueue.main.asyncAfter(wallDeadline: .now() + .seconds(2)) { [unowned self] in
    self.createImage()
    self.loadImage()
    self.changeImageViewToLatestImage()
    self.removeLatestImage()
}

改成

DispatchQueue.main.asyncAfter(wallDeadline: .now() + .seconds(2)) { [unowned self] in
    self.createImage()
    self.loadImage()
    self.changeImageViewToLatestImage()

    DispatchQueue.main.async { [unowned self] in
        self.removeLatestImage()
    }
}

思考

为什么上面的代码会成功呢?这是因为第一段代码的运行顺序是

DispatchQueue.main.asyncAfter(wallDeadline: .now() + .seconds(2)) { [unowned self] in
    self.createImage()
    self.loadImage()
    self.changeImageViewToLatestImage() // 异步操作,押后运行
    self.removeLatestImage() // 先删除了图片,之后才进行的图片加载
}

而修改之后的代码是

DispatchQueue.main.asyncAfter(wallDeadline: .now() + .seconds(2)) { [unowned self] in
    self.createImage()
    self.loadImage()
    self.changeImageViewToLatestImage() // 异步操作1,押后运行

    DispatchQueue.main.async { [unowned self] in // // 异步操作2,押后运行
        self.removeLatestImage()
    }
}

由于main队列是一个包执行完成之后,才会执行下一个。因此实际上修改后的代码是在图片加载完成之后才删除图片的。这就避免了这个问题。

循环结构中异步代码实现灵活退出(下)

Swift

循环结构中异步代码实现灵活退出(上)

上一篇中,我们实现了基本结构。但是如果每次都这么做,会比较麻烦。这一篇中,我们尝试将代码封装起来,这样以后我们再做时,只需调用一次就可以了。

首先,我们将之前的代码变成closure。

import Cocoa

class ViewController: NSViewController {
    private let semaphore = DispatchSemaphore(value: 0)
    private let concurrentQueue = DispatchQueue.global()
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        concurrentQueue.async {
            self.run()
        }
    }
    
    private func run() {
        for i in 1...10 {
            print(i)
            
            if shouldBreak(i, withClosure: { (result) in
                DispatchQueue.main.async {
                    self.textView.string += "\(i)\n"
                }
                
                if i == 5 {
                    result = true
                }
            }) {
                break
            }
        }
    }
    
    private func shouldBreak(_ i:Int, withClosure closure: @escaping (inout Bool) -> ()) -> Bool {
        var result = false
        let delayInSeconds = Int(arc4random() % 3)
        
        concurrentQueue.asyncAfter(wallDeadline: .now() + .seconds(delayInSeconds)) {
            closure(&result)
            
            self.semaphore.signal()
        }
        
        semaphore.wait()
        
        return result
    }

    @IBOutlet var textView: NSTextView!
}

接下来,我们新建一个文件RangeEnumerator.swift,扩展Sequence

import Foundation

extension Sequence {
    public func breakableForEach(closureWithCondition: @escaping (Element, inout Bool)->()) {
        let semaphore = DispatchSemaphore(value: 0)
        
        DispatchQueue.global().async {
            for e in self {
                if self.shouldBreak(semaphore, e, withClosure: closureWithCondition) {
                    break
                }
            }
        }
    }
    
    private func shouldBreak(_ semaphore:DispatchSemaphore, _ e:Element, withClosure closure: @escaping (Element, inout Bool) -> ()) -> Bool {
        var result = false
        let delayInSeconds = Int(arc4random() % 3)
        
        DispatchQueue.global().asyncAfter(wallDeadline: .now() + .seconds(delayInSeconds)) {
            closure(e, &result)
            semaphore.signal()
        }
        
        semaphore.wait()
        
        return result
    }
}

之后,最初的代码就可以简化为。

class ViewController: NSViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        
        (1...10).breakableForEach { (i, result) in
            DispatchQueue.main.async {
                self.textView.string += "\(i)\n"
            }

            if i == 5 {
                result = true
            }
        }
    }
    
    @IBOutlet var textView: NSTextView!
}

另外,由于扩展中不能创建存储变量,所以,之前的信号量和队列,就必须放在函数里了。

循环结构中异步代码实现灵活退出(上)

Swift

在同步代码时,循环要提前退出十分简单。

for i in 1...10 {
    print(i)
    
    if i == 5 {
        break
    }
}

但是在异步代码中,要灵活退出就不那么容易了。比如,在调用RestAPI时,如果一切正常,就执行下一次循环,如果出错,则进行提示用户,进行重试或者退出。这个就属于异步操作。

import Cocoa

class ViewController: NSViewController {
    private let concurrentQueue = DispatchQueue.global()
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        run()
    }
    
    private func run() {
        for i in 1...10 {
            print(i)
            
            if shouldBreak(i) {
                break
            }
        }
    }
    
    private func shouldBreak(_ i:Int) -> Bool {
        var result = false
        let delayInSeconds = Int(arc4random() % 3)

        concurrentQueue.asyncAfter(wallDeadline: .now() + .seconds(delayInSeconds)) {
            if i == 5 {
                result = true
            }
        }
        
        return result
    }
}

由于采用了异步,shouldBreak(_ i:Int) -> Boolresult是先于DispatchQueue.main.async中的代码执行的。因此输出始终是1-10

为保证执行的顺序,需要使用信号量。

import Cocoa

class ViewController: NSViewController {
    private let semaphore = DispatchSemaphore(value: 0)
    private let concurrentQueue = DispatchQueue.global()
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        run()
    }
    
    private func run() {
        for i in 1...10 {
            print(i)
            
            if shouldBreak(i) {
                break
            }
        }
    }
    
    private func shouldBreak(_ i:Int) -> Bool {
        var result = false
        let delayInSeconds = Int(arc4random() % 3)

        concurrentQueue.asyncAfter(wallDeadline: .now() + .seconds(delayInSeconds)) {
            if i == 5 {
                result = true
            }
            
            self.semaphore.signal()
        }
        
        semaphore.wait()
        
        return result
    }
}

代码执行正确。下面我们加入改变UI的部分。添加一个NSTextView,让它显示每次的i

import Cocoa

class ViewController: NSViewController {
    private let semaphore = DispatchSemaphore(value: 0)
    private let concurrentQueue = DispatchQueue.global()
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        run()
    }
    
    private func run() {
        for i in 1...10 {
            print(i)
            
            if shouldBreak(i) {
                break
            }
        }
    }
    
    private func shouldBreak(_ i:Int) -> Bool {
        var result = false
        let delayInSeconds = Int(arc4random() % 3)

        concurrentQueue.asyncAfter(wallDeadline: .now() + .seconds(delayInSeconds)) {
            DispatchQueue.main.async {
                self.textView.string += "\(i)\n"
            }
            
            if i == 5 {
                result = true
            }
            
            self.semaphore.signal()
        }
        
        semaphore.wait()
        
        return result
    }
    
    @IBOutlet var textView: NSTextView!
}

代码执行后,我们会发现,textView中的i,不是一行一行显示的,而是一开始不显示,然后一下子都显示出来。这和我们期望的不符。

这是什么原因造成的呢?其实,这是因为视图控制器中的代码,默认运行在图形线程,因此semaphore.wait()其实每次都阻塞了图形线程。这导致textView一直没法刷新。直到循环跳出后,界面才成功刷新。

知道了原因,解决办法就有了。将代码从默认的图形线程中移除即可。最终代码:

import Cocoa

class ViewController: NSViewController {
    private let semaphore = DispatchSemaphore(value: 0)
    private let concurrentQueue = DispatchQueue.global()
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        concurrentQueue.async {
            self.run()
        }
    }
    
    private func run() {
        for i in 1...10 {
            print(i)
            
            if shouldBreak(i) {
                break
            }
        }
    }
    
    private func shouldBreak(_ i:Int) -> Bool {
        var result = false
        let delayInSeconds = Int(arc4random() % 3)

        concurrentQueue.asyncAfter(wallDeadline: .now() + .seconds(delayInSeconds)) {
            DispatchQueue.main.async {
                self.textView.string += "\(i)\n"
            }
            
            if i == 5 {
                result = true
            }
            
            self.semaphore.signal()
        }
        
        semaphore.wait()
        
        return result
    }
    
    @IBOutlet var textView: NSTextView!
}

循环结构中异步代码实现灵活退出(下)

AVMovie始终显示视频时长为0问题的分析、解决

macOS

推特仅支持0.5秒到140秒之内长度的视频,因此上传前要先检验视频的长度。测试时,我发现,Finder分享的视频时长始终为0。

我查询了一下,最初看到的说法是,AVAssetAVMovie的父类)的加载是异步的,不能够立即获得时长,而需要用键值观察的方法,注册通知来观察duration这个属性何时变化。昨晚看到这里,我就睡了。

今天再看,发现有协议AVAsynchronousKeyValueLoading,可以用来异步处理键值。方法loadValuesAsynchronously(forKeys:completionHandler:)会在加载完成后执行completionHandler。这样就不用我们自己手动注册键值观察的通知了。

但是,我测试这个方法不好用。Finder传来的视频,无论是否使用这个异步方法,时长都始终为0。

我不用Finder,采用照片应用进行调试,发现无论是不是用这个异步方法,都能获得正确的时长。

结合上一篇Finder分享视频到共享扩展的一些限制的小结。我产生了新的想法,经过测试,我的猜想是正确的。

那就是,AVMovie在读取URL的时候,会正确获得时长,如果是Data的话,则不可以。想测试也很简单,把URL变成Data,再创建AVMovie;或者把Data写入到URL,再创建AVMovie。就可以证实了。

我不清楚这个是苹果API的错误,还是特性。但是这个至少是没有注明的。

Finder分享视频到共享扩展的一些限制的小结

macOS

通常,我们使用NSItemProviderloadItem(forTypeIdentifier:options:completionHandler:)方法来加载对应类型的对象。但是Finder提供的信息有问题。不能使用推荐的类型来获得想要的对象。

比如分享mp4文件时,Finder提供的NSItemProvider是这样的。

<NSItemProvider: 0x6000000bfa40> {types = (
    "public.file-url",
    "public.url",
    "public.mpeg-4"
)}

你用"public.mpeg-4"作为类型来获取数据,不能获得视频文件对应的URL。这是很罕见的。因为大部分情况下,比如通过照片应用来获得视频时,都可以通过这种方式获得URL。

Finder提供给"public.mpeg-4"实际上是一个Data。但是这个Data用在这里实际上是有问题的。苹果不应该这么做。为什么呢?因为相比于其它类型的文件,比如图片或者声音之类的,视频文件可以是很大的。如果你要使用这个视频文件,那么通过Data来加载,就会占据大量的内存。实际上,苹果自己就在加载视频的文档中写到,不要全部加载到内存。

apple data warning

因为存在这个限制,Finder实际上传来的Data可能是不完整的。比如我尝试分享一个4GB的视频时,实际获得的Data的大小是415MB,并不完整。

结论,既然Data既占内存,又可能不完整,为什么Finder还要提供呢?只能说,苹果做错了。

临时的处理办法是这样的,先用"public.mpeg-4"尝试获取URL,如果获取失败。那么就看NSItemProvider是否支持URL。如果支持就再用"public.url"尝试获取URL。如果还不行,那就认为是没法处理。为什么不反过来呢?因为大部分的情况,都是第一种方式就能直接处理。Finder这么做实际上是错误的。但是为了适应它,才需要调整我们的代码。

为什么说只有远程通知才是最吼的!(续)

watchOS

这篇文章会根据我的体验和理解进行增补和删减

如果是新增,那么内容会直接添加。
如果是修改或删减。我会将原有的段落标记加上删除线。然后再写上新段落。
如果出现多次修改和删减。我会添加版本的提示。如果没有提示,那么相邻的删除线的段落,就是同一个版本的。

简析远程推送服务的解决方案

苹果不承诺远程通知的可靠性。所以远程通知在实际使用中,经常有延迟,甚至丢失的情况。这时,你有两个选择。PushKit或调教苹果的apns服务器。

苹果不承诺远程通知的可靠性。并且由于我们在使用远程通知时,往往会使用第三方的推送服务。因此,一旦通知出现延迟甚至丢失,那么既有可能是苹果的问题,也可能是第三方服务的问题。就目前我自己的感受来说,苹果的服务要比第三方服务更可靠一些。

如果你的程序对于实时性要求较高。那么可以使用收费的第三方服务,这样可以保证你的推送的质量。或者使用自己的推送服务器。更进一步,你还可以使用PushKit

PushKit

PushKit是苹果伴随iOS 8推出的特殊通知,它针对的是一般远程通知的缺点。最初的设计目标是提供给VoIP的app以实时的通知。iOS 9的时候,苹果又增加了对于手表表盘上小部件的推送。

一般远程通知的缺陷

  1. 苹果不保证远程通知一定能到达。苹果会根据它的apns服务器的情况,动态来处理你的推送请求。也就是说,你的请求可能被执行,也可能会延迟,甚至被忽略(忘记)。
  2. 苹果的apns服务器最多只保留最后一条的推送请求。比如用户设备离线的情况下,你发出了多条通知,那么最终用户至多只能收到最后一条。
  3. 如果用户通过呼出任务管理,并且上滑移除app。那么该app的远程推送,将不能唤醒该app到后台,直到用户手动打开该app,或重启手机并解锁进入。
  4. 远程通知注册的token,隔一段时间会自动变化。这时如果还按照旧的申请,就会收不到消息。

苹果的处理方式

  1. 针对问题1。苹果保证PushKit通知会即时到达。看其他人写的评测,基本上延迟只有1秒。因为VoIP是类似打电话的功能,这个延迟高了,服务就没法用了。
  2. 用户设备可以在收到远程通知后,向自己的服务器,苹果称之为Provider,进行反馈。由于通知是即时的,服务器在“向要求苹果apns的服务器发出通知”的命令发出后,如果在特定时间没有收到用户设备的反馈,就可以认定用户的设备是离线的。这之后如果还需要给用户设备发通知,就可以先缓存起来,而不要发送到苹果的apns服务器。服务器可以在确认用户设备启动之后,再一次性将缓存的通知发出,这样,用户就可以得到在设备离线期间缓存的所有信息。
  3. PushKit的通知仍可以唤醒程序。
  4. PushKit的token是不变的。

PushKit的缺点

  • 实现比远程通知更为复杂。除了远程通知的要实现之外,还要向Provider做出反馈。
  • 国内没有现成的第三方服务,需要使用国外的第三方服务。或者自己编写Provider

调教苹果的apns服务器

如果你不想实现PushKit,那么你可以采用下面的比较脏的方式来调教苹果的apns服务器。

我的程序每小时通知一次设备。但是我发现,这个通知有时候会丢失,每天大概会丢个两回左右。

更进一步研究,我发现,如果通知没有及时到达,那么我可以在一段时间之后,补发一个通知。由于我没有实现PushKitProvider服务器不知道上一个通知到达了没有,因此我必须每小时发送两次通知。iOS端如果收到了第一个通知,那么可以做下标记,第二个通知到来时,就直接忽略,不要向Apple Watch传送就可以了。

这个调教的方式的原理是这样的。当apns服务器繁忙时,我猜测苹果采用了一个典型的美国式公平的策略。即大家都丢一些,而不是规定一个资源上限,占用资源多的丢,占用少的不丢。这导致一个现象,就是爱哭的孩子有糖吃。比如我的程序,原本每小时只需要一次推送。但是由于苹果的apns服务器会偶发的抛弃其中的1-2个通知。那么我为了保证通知的必须到达,就需要每小时发两次。实际上这导致苹果apns服务器的负载增加了一倍。但是我没有办法,因为只有这样,才能保证我的程序每小时至少刷新一次。

这个方法相对于PushKit,优点是实现简单。缺点也很明显,不考虑苹果apns的服务器负载增加的损失。只考虑开发者自己这边,最主要的缺点是通知到来的时间不稳定。既可能在第一次的时间到来,也可能是第二次。如果是对于通知到来时间,有特定要求的程序,那就不能用这种方式,而必须使用PushKit

系列文章

为什么说只有远程通知才是最吼的!
为什么说只有远程通知才是最吼的!(续)
为什么说只有远程通知才是最吼的!(续+1)