你写了一个iOS应用,不满足,还要写一个watchOS应用。你写好了watchOS的应用,不满足,还要写个表盘小部件。终于全都写好了。实际运行时,你发现,小部件它竟然不按照你设计的更新。好的欢迎你入坑watchOS,下面咱们来讨论一下究竟发生了什么。
伪实时的表盘小部件
做为一个watchOS的用户是幸福的,看着表盘上那些显示最新数据的各个小部件,一种掌控感油然而生——"I am the King of the world!"
但是,作为一名watchOS开发者,你必须知道,表盘小部件是伪实时的。苹果限制你实时地更新它。苹果设想的小部件的数据是这样的,你提前就知道某个时间会发生什么,然后在小部件初始化时,一次告知watchOS,watchOS会在相应的时间到来时,更改表盘的内容,这样,在用户看来,表盘就是实时变化的了。
可是如果实际内容发生了变化怎么办?根据变化的类型,你可以选择重新加载时间片,或者扩展时间片。二者的区别是前者作废旧数据,而后者是在旧数据的基础上添加新数据。
这么做就可以了吗?
怎么会?苹果会让你那么舒服?上面提到的两个操作,你的程序在计算时,苹果会拿着小本本记录你消耗了多少时间。一旦消耗时间过多,超过了苹果允许的范围,那么苹果就会立即终止你的计算。并且你再申请,也会无视你。直到,直到第二天的到来。
为什么苹果要这么做?
一切为了电池!Apple Watch的电池小,一旦没电,大家全完蛋。
因此,苹果认为不好用的小部件,也比没有电强太多。而重新计算小部件的行为,被视作是耗电行为。需要加以限制。
如何应对?
在讨论如何应对之前,我们先看看watchOS面对的复杂情况。说复杂,是因为相比于iOS,watchOS经常会遇到资源竞争的情形。
我们先假设你的苹果手表开启了多个表盘,你制作的程序叫A,它支持小部件,并且在这些表盘中,有的表盘添加了A的小部件,有的表盘则没有。并且,每个表盘上A的小部件数量至多只有一个。那么……
手表启动篇
当苹果手表启动后,会自动运行dock中的程序,以及当前表盘上的小部件。此时,就有可能对于相同的资源同时进行访问,从而产生问题。要解决这个问题,可以采用的最优策略是,不在程序的主界面运行可能资源占用冲突的代码,而只让表盘小部件运行。
为什么说这个是最优的策略?因为表盘的小部件运行苹果会记录时间,如果你采用信号量的方式,那么主程序独占资源运行的时间,会被一同记录到表盘的小部件运行的时间(虽然这时小部件没有运行,而是在等待资源独占结束),这样就会产生超时错误。
当然,你也可以使用Timer
来延迟主程序的运行,但是这个延迟运行的延迟时间不好掌握。太短了不起作用,会产生同样的问题。太长的话,如果用户此时打开了主程序,会发现界面一直不动,这样程序用起来也还是有问题。
表盘切换篇
当你通过滑动屏幕切换手表的表盘时,如果新表盘有相应的小部件。那么系统会根据情况刷新小部件。因此,你需要根据数据的新鲜程度来决定是否要刷新小部件,还是沿用旧的数据。
另外,如果该表盘没有小部件,那么就没有后台刷新小部件的必要。这样可以节省电量。
后台任务的种类(表盘小部件、Dock以及远程通知)
如果你想要定期后台更新程序的内容,那么有三种情况可以做到。
- 程序在当前的表盘有相应的小部件。这样可以保证你的程序每小时至少可以后台运行一次。至多运行的次数,在于当前表盘有多少个小部件。如果其它小部件有没使用自己的次数的,那么你可以占用它们节省的次数。
- 如果你的程序没有小部件,又需要后台刷新,那么你的程序需要在Dock中存在。在Dock中保留的程序每小时至少可以运行一次。至多可以运行10次,这取决于Dock中其它程序是否使用了它的次数,因为是大家共用这10次。
- watchOS 3.x比较简单,直接选择固定该程序在Dock就可以。
- 但是到了watchOS 4.0,苹果画蛇添足的增加了两种模式的Dock,并且将新模式作为了默认。新模式被称为近期(recent),即你最近运行的程序被固定在Dock上,新运行的会逐渐顶掉旧的,但是这个没有鸟用。因为你近期运行的程序很可能不需要后台刷新,而需要的则可能被挤到外面去了。
- 这时,就要引导用户开启Dock的另外一个模式,最爱模式(favorite)。这个其实就是watchOS 3.x中原本的模式。用户可以选择哪些程序常驻Dock。
- 远程通知。远程通知是通过苹果推送服务器,将远程消息推送到用户的iPhone,iPhone在30秒内处理完成后,将结果发到苹果手表上。苹果手表接到结果,再进一步处理,之后刷新表盘小部件或向用户发出通知。
各种后台任务运行时的区别
- 小部件和Dock中运行后台刷新的方式,属于本地刷新,可以通过
WKExtension.scheduleBackgroundRefresh(withPreferredDate:userInfo:scheduledCompletion:)
的方法来进行安排。时间到了,系统会调用WKExtensionDelegate.handle(_ backgroundTasks: Set<WKRefreshBackgroundTask>)
方法,执行后台任务。
- 优点:
- 本地操作。实现简单。
- 可以直接运行异步的调用。异步调用结束时,调用
task.setTaskCompletedWithSnapshot(Bool)
即可
- 缺点:
- 时间不稳定。根据苹果的文档,虽然你可以指定后台任务运行的时间。但是这个时间watchOS只是用来参考,系统会在它认为适当的时机进行调用。可能比设定的时间早,也可能晚。实际运行中,我发现只可能晚,还没发现有早于设定时间的情形。
- 计算量存在限额。苹果很奇葩的规定了计算量的限制,计算量是一个很抽象的概念。不同于计算时间,计算量是一个确定的量,但是苹果并未公开这个量具体是多少。只是说当后台任务运行时,它会记录,如果超出了,就会终止。直到重新分得配额。这个不是以天为单位的,而是动态的。如果你的计算量较大。就很可能出现表盘不更新的问题。
- 远程通知的方式,属于远程刷新,需要配置调用苹果的推送服务器。远程通知到来时,必须先经过iOS,调用
UIApplicationDelegate.application(_:didReceiveRemoteNotification:fetchCompletionHandler:)
,然后调用WCSession.transferCurrentComplicationUserInfo(_:)
给苹果手表发送信息。最终手表端会调用WCSessionDelegate.session(_:didReceiveUserInfo:)
函数,执行最终的任务。
- 优点:
- 准时。苹果的远程推送,只要不是批量推送,而是推动到指定设备或指定账户的设备。还是很准时的。延迟在几秒到几分钟。
- 计算量充裕。远程通知在iOS端最多可以后台运行30秒。因为iPhone速度远快于Apple Watch,因此有充裕的计算量来进行计算。此外,在传递到watchOS后,相应地还可以继续进行后台计算。这个也没有文档说有计算量的限制。
- 缺点:
- 次数限制。虽然远程通知没有计算量的限制,但是由于规定远程通知必须先经过iOS,然后由iOS唤醒watchOS,即
WCSession.transferCurrentComplicationUserInfo(_:)
这个函数,这个函数每个程序每天有50次的调用限制。超出限制后,调用会自动降级到WCSession.transferUserInfo(_:)
相同的待遇,即必须手动打开Apple Watch上的对应程序,才会接收相应的数据。
- 连接性问题。不同于本地任务,是在手表本地运行的。远程通知必须有网络才能收到。同时,由于通知先传到iOS,处理后再传到Apple Watch。如果此时手表与手机距离较远,会导致相应的数据在iOS排队。而这个队列在手表与手机重新连接后不会主动发送。而是需要手工开启iOS上相应的程序才会发送。我认为这个行为属于bug,已经向苹果进行了提交。
WCSessionDelegate.session(_:didReceiveUserInfo:)
不能直接处理异步程序。如果你的代码里包含异步程序,那么你就需要增加额外的代码。比如使用信号量来限制函数不要一下跑完。如果函数执行完毕了,很有可能异步程序还没处理完,手表程序就被系统睡眠了。
- 实现复杂。远程通知不仅需要申请通知权限,还可能需要使用第三方的推送服务。以及申请http的特定域名的解禁。因为苹果目前默认只能运行https的域名,还必须是特定加密等级之上的。
- watchOS 3.x存在bug。早期的watchOS 3.x会在iOS端调用
WCSession.transferCurrentComplicationUserInfo(_:)
之后,自动刷新表盘小部件,然后再调用WCSessionDelegate.session(_:didReceiveUserInfo:)
。这个是有很大的问题的。因为表盘小部件在数据到来之前就刷新了。而且是每次都刷新,而不是先判断是否有必要进行刷新。大概半年前,我向苹果提交了这个问题的的错误报告。目前4.0解决了这个问题,不会直接刷新表盘,而是由开发者来判断是否需要刷新表盘。我不清楚3.x的后续版本是否也解决了这个问题。有需要的可以自己测试一下。
虽然有以上的缺点,但是如果你的计算量太大,本地后台任务经常超时,那么远程通知是唯一的选择。
多个小部件
如果你的表盘有你的程序的多个小部件,那么小部件之间也会产生资源冲突的问题。但是这个情况一般很少见。因为除非用于测试,用户一般不会在屏幕上放两个一样的小部件。因此,这个问题可以暂时忽略。
系列文章
为什么说只有远程通知才是最吼的!
为什么说只有远程通知才是最吼的!(续)
为什么说只有远程通知才是最吼的!(续+1)