与之前买燃油车后的感受不同，特斯拉真的是一辆拥有之后能够时刻带来新鲜感的真正属于信息时代的车。
首先是短短提车两个月，车子就经历了两次大的OTA更新：
- 2019 年 12 月 10 日特斯拉开始大规模推送 2019.40.2.1 版本的软件，新版本软件中一共有三项更新：自动雨刷改进、自动辅助变道改进、新增车牌限行、导航指引视图改进。
- 圣诞节前夕发布了2019.40.50版本软件，带来了智能召唤、星露谷物语、露营模式，以及对更多道路信息的识别。例如红绿灯、垃圾桶、车道指示、警示牌等。甚至在升级的时候，很骚的将字段改成了“拆礼物ing”。
- 明年年初，已经预告会添加斗地主、搓麻将、B站、优酷、天气预报等新的娱乐和本地化功能。
而在这一年内，已经推送了10次大的更新，例如哨兵模式、自动变道、单踏板模式，甚至还有功率和续航提升。可以说同一辆车，在年初和年尾已经不是同一辆车了。这种迭代的速度和方式，都与传统的燃油车形成了鲜明对比，更印证了我在前一篇购车决策文章提到的全功能OTA的颠覆性。
除此之外，特斯拉进一步挖掘了新型商业模式的潜力，除了流量开始收费，还推出了一款2000美元的加速内购。让我这款四区长续航的百公里加速可以从4.4秒进一步提升到3.9秒。
除此之外，由于特斯拉开放了获取车辆信息与控制车辆的api，所以用户可以通过官方和三方的app对这辆车进行各种操作。不过各家在体验上来讲就一言难尽了，对最新接口的支持，平台设备的全面性，以及安全性等都无法得到保障。
不过前几天碰巧在论坛上看到老外们利用iOS的捷径直接利用特斯拉开放的api，顿时眼前一亮。（reddit）
下了几个之后参考特斯拉公开的api就开始自己魔改。
要注意的是，这两个api介绍网站都不是官方的，而是根据app和车机软件逆推出来的。所以在实时性上可能并不能做到第一时间。
Is this API official? Absolutely not. These endpoints are a result of reverse engineering Tesla's mobile applications and vehicle software.
iOS上的捷径
在此之前手机上的捷径我其实用的不多，从少数派（捷径商店）下了几个现成的尝鲜之后，就只留下了导航和米家的场景。不过米家的东西怎么说都是直接用他们家的“小爱同学”控制比较方便，通过捷径再去第三方软件转一转其实挺影响体验的，经常会失败。
这一点在特斯拉第三方app的使用上也有体现。所以直接利用捷径的网络功能调用特斯拉的api，在成功率和实用性上其实是更进一步的。也可以趁此机会，研究一下捷径所谓图形界面编程的深入使用。不需要跳转三方软件，在苹果生态圈就可以全平台覆盖，不论是Apple Watch还是HomePod，只需要一个指令调用一些预置的基础网络功能，就能够反馈车辆信息或者对车辆进行操控。
捷径设置思路
利用开放的api其实只需要掌握几个最关键的捷径组件。
- 网络控件，设置url和参数进行post或者get通讯；
- 获取需要的变量，并对它命名、计算、变换、显示；
- 简单的逻辑，让指令可以根据不同条件分别执行；
- 信息的展示和录入，例如对话框和提醒栏，甚至还有震动。
这四个是最重要的组件，会不断的反复利用、相互嵌套。其他还有一些例如日期、时间、计算等处理特定信息的部件，则可以根据需要，看看提示和说明来试用。（感觉就像编程的时候查文档）
当然，这虽然是非常初级的编程，但为了做出一个有效、可靠的捷径成品。我们需要基础的编程思维，也就是使用条件判断：是、非、或、且。以及运用一些基础的数学能力，例如剩余充电时间1.45小时，并不是1小时45分钟，我们需要能够进行换算。以及在设置条件的时候也需要统一单位进行比较。
此外对于api本身，也需要反复实验，确定不同字段的意义和指令的真正作用。
下面我聊一聊其中几个捷径设置的思路。
唤醒车辆
为了省电，车辆在驻车一段时间之后会进入睡眠时间，就像所有其他电子产品那样。为了进一步操作，我们需要将车辆唤醒。
唤醒的操作很简单，其实就是简单的发送一段执行的代码。但在刚开始我会发现，发送之后状态的提示还是offline。查询了车辆唤醒的逻辑，其实是发一条短信，那就很好理解了。短信的实时性并没有网络传输那么高，但胜在可靠性和接收器待机时的低功耗。
甚至在车辆没有信号的情况下也能够先发送短信，等车子到了有信号的地方再接收短信。不过等有人去开车了，车子就自动被唤醒了，并不需要远程唤醒。
总而言之，唤醒的指令发一条就够了。
下雨时关窗
关窗是一项非常近期才开放的api，出于安全的考虑，原先只有开窗通风的选项，并无法远程关闭窗户。即使现在开放了，也需要在发送指令的过程中同时发送位置信息。根据api的介绍，我发现假如位置和车辆位置相隔太远，该指令也会失败。
搞定后我又发现在捷径里面预置了一些与天气有关的组件，例如可以查询当前位置的天气状况。所以在后期又加了一个判断当前是否下雨，并根据天气状况关窗的条件。
做完之后我觉得这样太没有实用性了，所以就干脆提前加了个信息获取，先判断车窗关了没有。假如没关，再读取天气信息，根据是否下雨智能提示关窗。已经关了的话就可以让车主安心。
至此，就非常接近一个正常的程序逻辑了。
只不过在最后一步改造的时候，我发现了iOS捷径的一些局限。当然，对于功能限制这件事，一开始我就有心理准备，能做到这样的复杂程度已经大大出乎我的意料了。
具体就是在关窗这个捷径中，由于判断条件太多，需要重复执行同一个功能。为了节省代码和减少与服务器握手的次数，我用了常用的编程方式——复用一个实现单一功能的捷径。只不过虽然有该功能，但限制比较多，使用已有捷径只能传入一个变量。此外对分享也不是很方便。
不得已最后还是复制了同样的步骤到不同的条件中，不过复制和移动竟然不能复选，这也太不方便了。
锁门与解锁
在实车调试的阶段，我发现所有的指令在车辆在休眠的时候是无法执行的。除此之外，假如停在了没有信号的地方，也无法发送指令。根据编程思维中的节省原则，除了唤醒的指令外，我在所有的捷径中加入了判断车辆离线状态的条件。一旦发现车辆离线，剩下的部分就不再执行了。
确认车辆在线后，就可以获取锁车的状态。状态有两种，一种是已锁，一种是没有锁。那程序就可以根据不同的情况提供不同的选项，例如锁了之后就会询问是否要解锁，反之亦然。当然因为有选项，作为车主完全可以在查看状态后不进行任何操作。
有了这样的逻辑链条，捷径的实用性会得到大大增加。
结论
捷径可以算是一种在专业性和易用性之间不断寻找平衡一款应用，虽然现在还有不少限制，有功能上的，也有系统层面的。但不管怎么说，这种自动化的尝试，让手持设备离生产力又更近了一步。像这次对特斯拉api的利用，思路可以用于任何其他开放api的系统。
基于原生应用的待遇，在Apple Watch或者Mac端、HomePod，都可以用Siri来使用各种捷径。可以预见，捷径还会进一步的添加功能，在不同的平台有更好的表现。
对于特斯拉，即便其他什么都不论，单单依靠这种开放性的表现，就给了这辆车无限的可能性。想象一下，起床后除了智能音箱可以告诉你天气和日程，还能够获取车辆信息。并且根据日程安排提前热车、开空调、设置导航。更重要的是，我们不需要等待车企龟速的支持，只需要自己动动手，就像我们对树莓派或者我的世界做的那样。
最后是喜闻乐见的分享时刻，这里我贴几条文章里提过的典型捷径，供大家参考和进一步修改。