肇鑫 / Owen Zhao

Ubuntu在14.04以后，支持更新内核之后动态更新的技术。但是需要激活。步骤如下：

1. 到https://auth.livepatch.canonical.com申请一个token。
2. 然后安装命令操作。

问题

执行第二行命令的时候，遇到了错误。

2019/08/30 01:46:55 error executing enable: cannot enable machine: this machine ID is already enabled with a different key or is non-unique. Either "sudo canonical-livepatch disable" on the other machine, or regenerate a unique /etc/machine-id on this machine with "sudo rm /etc/machine-id /var/lib/dbus/machine-id && sudo systemd-machine-id-setup": {"error": "Conflicting machine-id"}

解决

rm -f /etc/machine-id
rm /var/lib/dbus/machine-id
dbus-uuidgen --ensure=/etc/machine-id
dbus-uuidgen --ensure

> 注意：上面的操作有风险，需要先备份你的系统。

然后再执行第二行的命令。

参考资料

• This machine ID is already enabled with a different key or is non-unique

最近在研究带参数的捷径。因为是SiriKit相关，需要把Realm放在应用组里。这样就不能通过Xcode下载容器了。几天时间里，已经有了两次不小心删除掉数据库，而不得不通过备份恢复手机的经历。我开始研究一下如何导出和恢复数据。

思路

因为目的只是为了方便开发，而不是交给用户操作，过程简便，代码容易是重点。

首先想到的是通过长按某个按钮实现导出，然后出了问题就将导出的数据库放在应用里，应用启动时检测是否有数据，如果有，就替换，然后再正常启动。

实现

具体实现的时候，遇到了一个问题，分享出来的URL，并没有写成文件，而是写成了纯文本。

@objc private func exportRealm(_ sender:Any) {
    let sourceURL = Realm.Configuration.defaultConfiguration.fileURL!
    
    // copy realm to cache and rename it to current date and time
    let fm = FileManager.default
    let filename = { () -> String in
        let df = DateFormatter()
        df.dateFormat = "yyyy.MM.dd_HH.mm.ss"
        return "any_counter_2.backup.at.\(df.string(from: Date())).realm"
    }()
    let cacheFolderURL = fm.urls(for: .cachesDirectory, in: .userDomainMask).first!
    let destinationURL = URL(fileURLWithPath: filename, isDirectory: false, relativeTo: cacheFolderURL)
    
    do {
        try fm.copyItem(at: sourceURL, to: destinationURL)
    } catch {
        return
    }

    // export
    let activityViewController = UIActivityViewController(activityItems: [destinationURL], applicationActivities: nil)
    activityViewController.completionWithItemsHandler = { (_, isCompleted, _, activityError) -> Void in
        guard activityError == nil || (activityError! as NSError).code == 3072 else { // Error Domain=NSCocoaErrorDomain Code=3072 \"操作已被取消。\"
            fatalError("\(activityError!)")
        }

        // clear cache after success
        try? fm.removeItem(at: destinationURL)
    }
    present(activityViewController, animated: true, completion: nil)
}

这个问题花费了我不少时间去寻找解决方案。最后我突发奇想解决了。实际上，就是和URL有关。将12行

let destinationURL = URL(fileURLWithPath: filename, isDirectory: false, relativeTo: cacheFolderURL)

替换为

let destinationURL = URL(fileURLWithPath: cacheFolderURL.path + "/" + filename, isDirectory: false)

，问题解决。

类似的事情很早就遇到过，比如

import Foundation

let folder = "/foo"
let file = "bar"

let folderURL = URL(fileURLWithPath: folder, isDirectory: true)
let u1 = URL(fileURLWithPath: file, isDirectory: false, relativeTo: folderURL)
print(u1.path) // /foo/bar

let u2 = URL(fileURLWithPath: folder + "/" + file, isDirectory: false)
print(u2.path) // /foo/bar

print(u1 == u2) // false
print(u1.path == u2.path) // true

即两个path相同的URL，仅仅是因为构造方法的不同，它们就不相等。这其实是很不直观的，人们在没遇到之前，可能就会认为path相等的两个URL就是相等的，但是实际上系统认为不是。

这里也是这样，通过relativeTo构造的URL，iOS系统仅能将它存成一个纯文本。但是直接构造的URL就没有这个问题。

我虽然不认同，但是只能记住。

之前的三个坑都是很久远的事情了。今天要填一个新坑。

我们知道，Realm.objects(_)返回的值是Results<T>，由于Realm自身的特性，Results<T>是很有用的，它是lazy和动态的。因此，在使用Realm的时候，我们更喜欢使用Results<T>而不是Array。

但是Results<T>有一个问题，就是它的排序功能十分有限。它最基本的排序只有一个函数，即sorted(byKeyPath:ascending:)。也就是说，Results<T>只能按照Realm对象的动态属性排序，而不能使用我们经常用到的closure排序。

分析

这就使得我们在有些时候，为了排序的方便，要么增加磁盘占用，添加额外的动态属性；要么，就只能使用Array类型。

值得一提的是，有时，如果是涉及到当前时间这一类的排序变量，即便我们使用额外的动态属性，也是不能排序的。因为这个值一直在变。因此就只能使用Array类型。

didSet不执行的问题

特别的，我们需要注意，在Realm的动态属性中，didSet是不会执行的，这应该是和Objective-C的运行时相关。因此，如果需要使用didSet，就需要改成其它的方式。

参考资料

• Swift ObjectMapper not calling didSet

相关

• Realm的坑（一）
• Realm的坑（二）
• Realm的坑（三）
• Realm的坑（四）

前两天用咕唧分享照片的时候，我发现分享出去的照片，与我查看时的角度不一致，被转了90°。这是一个需要解决的问题。

分析问题1

一开始，我以为是咕唧的隐私保护功能导致的。为了保护隐私，咕唧默认会移除照片中的GPS信息和Exif信息。此外，用户可以在设置中，选择分享这些信息。

我们知道，平常拍照片，你的手机可能是横着拍，也可能是竖着拍，偶尔可能倒过来拍。但是不管你拍照时，手机处于何种角度，系统在显示该照片的时候，都会正确的显示该照片为当时你在屏幕上见到的样子。因为系统会读取照片属性中的方向信息，从而知道你拍照时手机的状态，这样就能正确的显示。

我首先就是认为Exif信息被咕唧删除了，系统没有了参照，只能按照默认的方式处理，因而与实际的方式造成了偏差。

解决问题1

我创建了一个测试项目，然后将那张出问题的照片作为资源，做同样的缩小操作，之后查看照片属性。结果我发现其实方向Orientation属性并没有保存在Exif信息，而是在图片的属性中。也就是说，事实上，咕唧缩小的图片是包含这个信息的。之前的分析是错误的。

那么是什么原因导致了包含了正确方向信息的照片，实际显示的反而是错误的呢？

分析问题2

排除了一切不可能，剩下的就是唯一的可能。

我们知道，系统在读取照片的时候，会根据方向Orientation做正确的处理。也就是说，CGImageSourceCreateImageAtIndex(_:_:_:)获得的照片本身就是正确方向的。那么这个方向正确的照片。在通过CGImageDestination重新保存时，就应该改变Orientation值为默认值，而不是继续保存原始值。

解决问题2

如果上面的分析正确，思路就很简单了。保存之前，检查方向Orientation是否为默认值，如果不是，则修改为默认值。

注意：是只要CGImageSource加载了图片，就会造成这个问题。因此，不仅缩小照片有这个问题，仅仅是去除Exif或者GPS信息，都会存在这个问题，同样需要修改方向Orientation为默认值。

思考

我在想要不要把这个问题，作为bug报告给苹果。思考的结果是不要。因为如果苹果修复了这个问题，将新照片变成与原始照片的方向一致。那么之前有做过特殊处理的应用，照片的方向就又都会从正确变成错误。这相当于是API不延续了。

为了保证之前的兼容性，好多时候，只能遗留不正确的代码。这个就是API设计出问题的代价。

参考资料

• 如何处理iOS中照片的方向
• CGImageDestination写入属性时的架构

模型

• UISplitViewController拥有两个视图控制器，在故事版中分别对应主视图控制器和细节视图控制器，在编码中对应为viewControllers属性，主视图控制器在前，细节视图控制器在后。
• 开发者通过preferredDisplayMode推荐想要的模式，通过displayMode获得当前的模式。
• 在iPhone中，横屏、和竖屏都是allVisible，此时可以通过UISplitViewControllerDelegate的splitViewController(_:collapseSecondary:onto:)方法来告诉系统默认是显示哪个视图控制器。
• 在iPad中，横屏是allVisible，竖屏是primaryHidden。此时如果想要默认显示主视图控制器，需要在UISplitViewControllerDelegate的splitViewController(_:willChangeTo:)方法，设定preferredDisplayMode为primaryOverlay。

UISplitViewController

• displayMode
  • 这是一个只读属性。
  • 它代表的是UISplitViewController当前的具体模式。
• preferredDisplayMode
  • 开发者只能通过displayMode了解到UISplitViewController当前的模式。如果开发者不满意这个模式，想要手动调节，就可以通过修改preferredDisplayMode来实现。
  • 值得注意的是，这个是开发者的推荐，并不是完全的设定，系统仅会在条件允许的情况下，优先使用这个推荐。如果系统认为可视面积过小，就会忽略这个推荐，而使用系统认为最适合的模式。

UISplitViewController.DisplayMode（按照rawValue的数值排列）

• automatic
  • 自动模式是默认的模式，完全由系统进行判断，开发者没有任何推荐。
  • 注意：这个自动模式，只在preferredDisplayMode中有效，displayMode实际显示的，只会是下面三个模式。
• primaryHidden
  • UISplitViewController包含两个视图控制器，主视图控制器和细节视图控制器。primaryHidden表示优先显示细节视图控制器，而将主视图控制器隐藏起来。用户需要使用手势或者是后退按钮显示主视图控制器。
  • iPad在竖屏时默认会是这个模式。
• allVisible
  • 同时显示主视图控制器和细节视图控制器。
  • 需要注意：这个模式虽然叫allVisible，却不是一定都能同时显示。如果不能，就会需要告诉系统，优先显示哪个视图控制器。
  • iPad在横屏时默认会是这个模式。此时会全部显示。
  • iPhone 6s Plus在竖屏和横屏时都是这个模式。竖屏时，因为实际上不能全部显示，就还需要考虑UISplitViewControllerDelegate的splitViewController(_:collapseSecondary:onto:)方法。
• primaryOverlay
  • 与primaryHidden类似。但是会优先显示主视图控制器，叠加在细节视图控制器之上。
  • 如果我们要特别提示用户主视图控制器的存在，就可以使用这个选项。

UISplitViewControllerDelegate

splitViewController(_:collapseSecondary:onto:)方法

当UISplitViewController.DisplayMode为allVisible，且可显示的面积不能同时容纳显示主视图控制器和细节视图控制器时，系统会调用UISplitViewControllerDelegate的splitViewController(_:collapseSecondary:onto:)方法。

这个方法返回true代表显示主视图控制器，返回false代表显示细节视图控制器。

splitViewController(_:willChangeTo:)方法

当你需要在系统选择了primaryHidden时，就更改为primaryOverlay。使用此方法。

最初的代码在这里。作者自己的说明。

最初的作品已经很好用了。只是细节需要改动一下。

更改

1. 原代码低于Swift 4.0，Xcode 11 beta 5无法编译。此次，先将Swift改成4.0。发现一切正常，没有需要改动的地方。
2. 原代码不支持暗模式，可以在故事版中将颜色重新选择为支持暗模式的。特别的，在资源中新建颜色资源AlertBackgroundColor，获得模拟器中UIAlertController.view在亮/暗模式下的背景颜色。并指定为Alert View的背景色。
3. 原代码ViewController.swift第55行使用了.overCurrentContext，这个在master/detail模式的布局中，如果detail中弹出自定义的警告窗口，之后旋转屏幕或者更改显示模式（比如由亮改暗），警告窗口就会出现问题。此处需要改成.overFullScreen。
4. 原代码CustomAlertView.swift第23行alertViewGrayColor使用了自定义颜色，注释掉掉。在第35行插入let alertViewGrayColor = UIColor.systemGray2。
5. CustomAlertView.swift第36行插入let lineThickness:CGFloat = 0.5，并且将第37-39行的width: 1.0改成width: lineThickness。

小结

经过以上的改动，就可以获得一个支持iOS 13 beta的自定义AlertController了。剩下的你只需要根据自己的需求，继续填充就可以了。

Realm模型升级（一）中讲了对象添加了新属性之后要如何升级。最近我又遇到了新的问题，要将对象改名。

新问题

因为业务的需要，必须将代码

class Item:Object {
    static let calendar = Calendar(identifier: .gregorian)
    
    @objc dynamic var title = ""
    @objc dynamic var addedDate:Date = Date()
    @objc dynamic var relatedItem:Item? = nil
    let records = List<Record>()
    
    override class func primaryKey() -> String? {
        return "title"
    }
}

class Record:Object {
    static let dateFormatter:DateFormatter = {
        let df = DateFormatter()
        df.locale = Locale(identifier: "zh")
        df.dateStyle = .medium
        df.timeStyle = .none
        
        return df
    }()
    
    @objc dynamic var id:Int = 1
    @objc dynamic var addedDate:Date = Date()
}

更改为

class ACItem:Object {
    static let calendar = Calendar(identifier: .gregorian)
    
    @objc dynamic var title = ""
    @objc dynamic var addedDate:Date = Date()
    @objc dynamic var relatedItem:ACItem? = nil
    let records = List<ACRecord>()
    
    override class func primaryKey() -> String? {
        return "title"
    }
}

class ACRecord:Object {
    static let dateFormatter:DateFormatter = {
        let df = DateFormatter()
        df.locale = Locale(identifier: "zh")
        df.dateStyle = .medium
        df.timeStyle = .none
        
        return df
    }()
    
    @objc dynamic var id:Int = 1
    @objc dynamic var addedDate:Date = Date()
}

即原来的类的名称之前，需要添加AC字样。更改了代码之后运行，发现数据不见了。

分析

打开数据库文件查看（如图）。原来，虽然代码中的类变了，但是数据库中的类还是原来的名字，需要手动迁移。

解决方案

23-39行，利用之前的Item对象，生成ACItem对象；利用Item对象中的records属性，生成ACRecord对象。需要注意的事，因为代码中此时已经没有了Item类和Record类，我们没法使用Item.className()，而只能直接使用"Item"。

41-43行，删除掉旧数据。

let config:Realm.Configuration = {
    // update realm
    let config = Realm.Configuration(
        fileURL: destinationURL,
        
        // Set the new schema version. This must be greater than the previously used
        // version (if you've never set a schema version before, the version is 0).
        schemaVersion: 3,
        
        // Set the block which will be called automatically when opening a Realm with
        // a schema version lower than the one set above
        migrationBlock: { migration, oldSchemaVersion in
            // We haven’t migrated anything yet, so oldSchemaVersion == 0
            if (oldSchemaVersion < 1) {
                // Nothing to do!
            }
            
            if (oldSchemaVersion < 2) {
                // Nothing to do!
            }
            
            if (oldSchemaVersion < 3) {
                migration.enumerateObjects(ofType: "Item") { (oldObject, _) in
                    let acItem = migration.create(ACItem.className())
                    acItem["title"] = oldObject!["title"]
                    acItem["addedDate"] = oldObject!["addedDate"]
                    
                    guard let list = acItem["records"] as? List<MigrationObject>,
                        let oldList = oldObject!["records"] as? List<MigrationObject> else {
                        fatalError()
                    }
                    
                    oldList.forEach { o in
                        let acRecord = migration.create(ACRecord.className())
                        acRecord["id"] = o["id"]
                        acRecord["addedDate"] = o["addedDate"]
                        list.append(acRecord)
                    }
                }
                
                // delete
                migration.deleteData(forType: "Item")
                migration.deleteData(forType: "Record")
            }
    })
    
    return config
}()

总结

1. 代码中对象的改名，意味着数据库中数据的迁移。
2. MigrationObjectEnumerateBlock中的oldObject，实际上一个词典，我们通过键来进行数据的查找。

咕唧在iPad浮屏时，既屏幕右侧向里滑动弹出咕唧，有时会出现全部头像闪动一下的问题。这个问题没什么规律，如果立即你把它划回去，再重新滑出来，它就又没有这个问题了。另外，我在iOS 12的时候也没有遇到过这个问题。

我认为这可能是iOS 13 beta独有的一个问题。

我尝试解决这个问题。

方案一

因为视图是UITableView，我尝试减少reloadData()的次数。仔细阅读代码，修改了几处限定条件，减少了reloadData()。并且出于调试目的，我在预期不应该发生的位置，插入fatalError()强制结束应用。

测试结果

方案一减少了重新加载表格视图的次数，但是对于解决该问题无效。测试中发现，偶尔还是会出现重新加载头像的问题，并且，应用没有崩溃，也就是说，我预期不会执行的部分，也的确没有执行。

方案二

因为问题是和头像有关，于是着重查看头像部分的代码。

cell.imageView?.image = profileImage
            
DispatchQueue.main.async {
    ProfileImageHelper.decorate(cell.imageView!, for: accountCore.type)
}

这段代码使用了异步代码，在UI队列里执行了对于UIImageView的装饰。这里必须使用的原因是cell.imageView是只读属性，不能直接替代。并且，当cell.imageView?.image = profileImage之后，如果立即装饰图片视图，图片视图的尺寸还是0，必须在下一个事件循环才能获得实际尺寸。

上图是咕唧账户头像的部分截图。照片原本是正方形，在实际显示时，被处理为圆形。并且，根据账户类型的不同，加上了颜色不同的圆圈。

我们知道，异步的代码，与同步不同，是分成两次执行的。因此，存在一种可能，既第一部分的代码执行了之后，很久，第二部分才执行。这在显示上，就会出现先显示方形的头像，然后才变成圆形和圆圈，就像看幻灯片那样。

须要将此部分的代码由异步改为同步。

此前采用异步的原因是无法立即知道图片视图的大小，改成同步，就必须修改代码，手动指定视图的大小。我们知道，这在平时其实是一种不好的行为。代码写死了，就失去了灵活性。但是这里，我们不得不把它写死。

通过调试，我们知道这里目前的大小是48.0点。（点，point，是苹果使用的相对大小的尺寸单位）。

cell.imageView?.image = profileImage
ProfileImageHelper.decorate(cell.imageView!, for: accountCore.type)

测试结果

这次的测试很成功，之后没有发现再次出现这个问题。

方案三

虽然问题解决了，但是写死代码还是不够灵活。思考了一下，虽然图片视图的尺寸不能立即知道，但是图片的尺寸是可以知道的。因此，将写死的代码，改为使用图片的尺寸。这样问题就彻底解决了。

思考

虽然这个问题很有可能是iOS 13 beta引入的，但是解决掉这个问题，还是有收获的。我们在实际编程中，应该尽量减少异步代码的使用。因为，有时，异步代码会带来意想不到的问题。