“应用即是电视的未来。”Tim Cook在2015年9月9日苹果发布会的产品展示中一语惊人——这是苹果对未来电视的愿景——被动的观看将成为历史，用户会在五彩缤纷的电视应用中畅游，享受前所未有的动态体验。 而未来的成功归根结底是由开发者能否充分利用tvOS决定的——这样的理念几乎跟Tim的那句话一样让人战栗不已。 在苹果眼中，电视的未来取决于应用，那么，tvOS会为应用带来新的春天吗？ 我们 之前在演讲中谈论的那些最前沿科技，不论是汇聚到示例应用里，还是测试程序库与新平台是否兼容，势必会遇到很多局限和问题。乐观者为未来新的发展潜力激动不已，而悲观者眼中则仅剩暗淡的前景——这纯粹是视角的问题。 无本地缓存tvOS并不提供稳定的本地缓存，这恐怕是我们关心的头等大事了。也难怪，设备内存仅有32GB或64GB那么大，虽不比iPhone小，但大部分1080p HD电影都在4-6GB左右，尽量留一些空间也无可厚非。 没有了本地缓存，开发者就必须用CloudKit或其他云端数据服务来存储应用下载的内容。会担心是正常的，但实际上，遇到这个问题是Realm的“内存模式”（in-memory mode）能忙不少忙。不过依旧需要多多少少进入硬盘来协调内部同步。在文件目录下打开Realm时会立刻遇到这一问题： open() failed: No such file or directory 对文件系统评估之后，我们意识到并没有可用的文件夹，只有NSCachesDirectory和NSTemporaryDirectory可以写入内容。所以，使用Realm搭建的tvOS应用默认使用缓冲目录，而不是文件目录的标准默认设置。 应用200MB上限tvOS的应用大小强制规定最大为200MB，势必会阻碍一些应用。有些游戏由于包含静态资产，大小更是在1GB以上。虽然苹果已经用 App Thinning和On-Demand Resources解决了这一问题，但200MB的上限实在让人膈应得慌。 无Mach信息Mach信息是一个在不同进程间传递信息的底层内核技术，用于在Realm和内置的加密支持模块建立关联。总览tvOS SDK后，发现mach.h头文件列出要发送的函数，并接收mach信息，就像watchOS一样设置为不可使用状态。 __WATCHOS_PROHIBITED __TVOS_PROHIBITEDextern void mach_msg_destroy(mach_msg_header_t *);__WATCHOS_PROHIBITED __TVOS_PROHIBITEDextern mach_msg_return_t mach_msg_receive(mach_msg_header_t *);__WATCHOS_PROHIBITED __TVOS_PROHIBITEDextern mach_msg_return_t mach_msg_send(mach_msg_header_t *); 看起来很合理，因为tvOS难以像iOS或OSX实现多任务处理，所以不得不禁用tvOS上的加密功能。 无命名管道跟mach信息相似，命名管道（ named pipe）是进程间的一种通信方式。Realm为进程间通知添加了支持，以满足Cocoa上多进程间的Realm文件无缝共享。因此，Realm浏览器能用来检测漏洞，也能实现iOS以及Watch扩展对主要应用Realm文件的共享。这些通知是通过命名管道来传递的，所以当写入事务出现后，Realm数据库更新的通知也会发往其他进程。 最开始，Realm并不提供此类支持。要让Realm在tvOS上正常工作，只要复原到仅在同一进程中发送通知的 源代码即可。 无粘贴板APItvOS既没有mach信息，又没有命名管道，无粘贴板API也就不足为奇了。粘贴板是进程间的顶级通信形式，使iOS和OSX实现复制/粘贴功能。归根结底，粘贴板就是使用mach信息在进程间前后传递数据，没有了它，tvOS就无法复制/粘贴。 无网页视图无网页视图为应用开发者带来了最为艰巨的挑战之一。网页视图在iOS应用中很常见，对于并不局限于iOS平台的应用开发者而言，非关键因素可以通过网页视图来展现，从而简化开发过程。 再者，即使应用已经发布，网页视图也可以进行后续更新，从而大大增加了功能测试的灵活性。不过tvOS若没有网页视图，那么总的网页浏览就不可能了。比如拿OAuth协议基础上的第三方授权应用举例，开发者需要专门为tvOS设计一个“登陆流程”。 苹果也有自家的替代品，它以TVML形式呈现。TVML是XML的一种形式，让开发者可以设计应用的视图，再通过JavaScript APIs结合TVJS来创建完整的客户端-服务器应用。虽能在应用发布后重新调整其内容，但要重建已经存在的视图，可选择的技术只有这一项。 无内置PiP在构建Realm TV应用时，我们想在展示中将幻灯片和视频结合起来使用，于是遇到了这一问题。iOS 9在iPad上增加了PiP（picture-in-picture，画中画）功能，我们以为tvOS也有内置PiP，结果却想错了。新的PiP只局限于iOS系统，且 只能在iPad上使用。因此，我们最后只能调整 AVPlayerViewController的视图层次来实现PiP效果。 观众可以在Apple TV遥控器上长按，来在3种PiP模式间转换。虽然现在的版本没什么问题，但希望tvOS以后能够添加内置的PiP。 无可定制化视频播放器无内置PiP让人有点儿伤心，后来发现AVKit内置的视频播放器也无法定制化，我们更失望了。没错，可以用AVFoundation来构建自己的视频播放器，但会遇到Apple TV独有的功能支持的问题，比如顶端导航栏下滑来调整音频偏好。Apple TV的主旨是媒体消费，所以给予开发者定制化的自由、创造独特体验的权力尤为必要。 无ReplayKit看了看tvOS SDK，我们惊讶地发现ReplayKit跟PiP一样不能使用。ReplayKit框架主要是让玩家将自己破纪录的游戏视频在线分享给其他玩家。Apple TV不仅仅是媒体消费设备，也是一台大游戏机。介于这一点，开发者用不了ReplayKit实在让人匪夷所思。一种猜测可能是硬件还不足以强大到同时处理1080p游戏和画面渲染。 无照片获取途径iOS系统通过UIKit的 UIImagePickerController类向用户显示照片选择，或从iOS 8开始通过 Photos框架来完成选择。两种方法均不适用tvOS，也就是说应用无法获取用户的照片——听上去不合常理，那设备为什么会支持在iCloud上浏览储存的照片呢？ 无日历/通讯录/iMessage通讯录和EventKit框架均不可用，所以应用不能置入iCloud上的任何信息。再者，MessageUI框架也不可用，所以无法发送iMessages。新的Apple TV遥控器包含了一个Siri键，算是做了一些补偿。 无多点连接tvOS也没有多点连接（ Multipeer Connectivity）框架。该框架主要通过Wi-Fi来识别iOS设备，按照顺序在设备间进行Wi-Fi或蓝牙数据传输。它完美适用于多玩家游戏，但在tvOS上的缺席意味着可以利用tv和iPhone/iPad/iPod分屏的游戏需要通过iCloud同步数据，或需要另外一台设备。对多玩家扑克游戏这一大类比较凑效，但其他低延迟请求可能就无法满足了。 这对于tvOS和iOS又意味着什么呢？就应用开发而言，tvOS看样子并不会引领一条新的大道。当初watchOS费了好大功夫来吸引开发者，但其本质上能做的太少；相比之下，tvOS的情况没有那么窘迫，虽然对开发者还是有很大限制。 考虑到OAuth协议的普及度，网页视图的缺席实在让人难以接受。虽然TVML/TVJS跟原生开发略有不同，填补了网页视图的空缺，但其专有格式仍然限制着开发团队改写现存网页内容。放弃网页视图支持可能也反映了苹果全新的长期定位，想象他们当初拒绝了Flash，不是挺正确的嘛？iOS 9之后就开始了对Safari的内容管制，看情况苹果在不断向原生应用靠近。 其他局限性似乎只是产品首个版本不够成熟才遇到的问题，未来可以在视频播放器定制化以及多点连接上进一步改进。 总而言之，为了挖掘更大的机会，必须要平衡一些局限性。在美国，平均每人每天在电视上花费 2.8个小时，相比智能手机的 1.3小时要长很多。基于这一点，tvOS为开发者打开了新的机会之门，以后超越iOS也不是不可能。 （翻译/张新慧） |
