Amazon的Fire Phone之于Android开发者
在上周Amazon也耐不住加入了手机竞争行列之中，发布了自己的Fire Phone，于是Android家族又多了一位变种成员，Android系统的碎片化程度也进一步加剧。因为工作的关系，我有幸在上个月就得到了一部工程机为其做提前开发，不过因为政策原因所以到现在才能来谈谈对这部新手机的看法。
对于Fire Phone的功能以及外观，官方网站和各家技术网站都有了详尽的介绍和报道，再者因为我拿到的是工程机，无法体现到完备的功能展现，因此本篇文章谈的主要是Fire Phone对于开发者而言所要面对的问题和状况。
Android的心，iPhone的型
和其他所有厂商自定义的Android Phone一样，Fire Phone也做出独有的特点来区别出自己，不然用户也就没有理由要购买一部同质的设别。首先在按键上讲，自3.0以后Android传统上无论是实体的还是虚拟的都保有3个按键：返回键(返回上一层页面)、主屏键(返回手机主屏)、任务键(查看最近使用任务列表)。而Fire Phone去除了返回键和任务键，只留下了主屏键，看起来就像是一台更大屏幕的iPhone。
这对于很多开发者来说是比较值得考虑的问题。因为有时候我们可能会假设所有Android设备都有返回键，因此在界面设计时，为了美观性和适用性等因素考略，而没有在界面上加上返回按钮。所以如果该程序放在Amazon的App Store上，用户可能就会被困在没有返回按钮的界面中。
不过后来我们被Amazon的人员告知，其实设备是有返回按钮的，只是并非实体按键，而是要从设备下方往上滑实现返回。如同从设备上方往下滑可查看系统消息一样。这对于新用户来说根本无从知晓，而只会责怪应用程序没有提供返回功能致使他们困在某个界面下。
另一方面Fire Phone没有任务键(可能它又是用什么手势打开，但是目前我依然没有发现)，也就是说用户无法在最近使用的任务栏里手动的将应用程序关闭。所以下次开启依然是进入那个无法返回的界面，于是用户可能就会厌烦这个程序而将其彻底删除。
浏览Fire APIs
一款移动设备的成功，很大原因在于它建立起来的生态环境：移动操作系统的拥有者不断优化系统的功能和性能，并提供便捷的开发套件给开发者生产相应的应用程序，进而吸引用户使用该设备，然后根据用户的消费和需求再进一步提升和完善。
Amazon的Fire Phone也是希望打造这样的生态环境，下图的表中就是Fire Phone所提供的开发接口，让开发者可以使用到Fire Phone与其他Android设备不同的的特性和功能。但是对于这些API，在使用中真的对其表示无奈和叹息：怎么能这么糟糕。
开发者可以在其网站上下载到这些API的文档与相关的列子。浏览API，可以发现其设计的接口大部分的参数和返回值都是int、String这样的基础数据或者已定义的Enum成员，而不是Android常用的Intent、BundleParcel类型的数据。这样的好处在于API非常容易理解的使用；坏处在于几乎完全无法自定义功能和界面，只能遵循其给出的类型中做出选择和使用。
比如其中的Home API，它是对应开发Fire Phone上的被其称为HeroWidget的控件。之前说了Fire Phone没有找到程序最近使用列表，另外它也没有传统Android设备的桌面，取而代之的是HeroWidget。应用程序按最近使用从左往右按carousel排列，每一个显示项目上程序的图标先占了大半个屏幕，剩下的一半留着呈现一些应用内容。如果没有对齐进行自定义开发，Amazon就会无耻的在上边做自己的App广告。
虽然本质上它应该就是Android的AppWidget，但呈现的方式只有Grid和List的两种，List下也是定义好的4种样式，完全无法自己定义，就连字体的颜色、大小都不能改变，还只能呈现大概20-30个英文字。完完全全就是为了Amazon卖东西用来展示商品的。
在原始的AppWidget里，可以通过PendingIntent来启动Activity、Service、BroadcastReceiver，Intent中可以存Action、Category、Data、Extra等等信息。但是HeroWidget只能构建HeroWidgetIntent或者HeroWidgetActivityStarterIntent来启动Service或者Activity，并且只能存放最长2048 bytes的String做为Extra数据。真是感觉又回到80年代，对于每个内存都要小心谨慎使用的日子。
其实Amazon的这个HeroWidget是非常好的设计，因为应用程序如同开店，也很注重回头率。而怎么让用户回头，每个开发者都在心力交瘁的思考，或者广告推广，或者邮件推送，或是系统消息召唤。Widget也是一种非常好的呈现新鲜事的途径可以让用户点击回到程序中。但是Amazon的样式限制则会导致程序间在其上呈现的差异太小，字数限制又导致一言难尽吸引力不足，存储数据的限制也导致开发时对字符串自行做额外的分析处理。一个好东西就砸在Amazon手上吧，也许Amazon本来主要就是想自己用，开放给开发者已经很客气了。
对于其他的API也有或多或少类似的问题，如果想为Fire Phone提供相应的支持，就要忍受Amazon的限制。但是对于很多功能对于绝大多数应用来说都是可无的功能。比如3D效果个人觉得只对游戏可能比较有意义，但是游戏开发大多都有自己的3D引擎基本不需要Amazon的伪3D；Motion Gestures和Head Tracking恐怕也只会跟Samsung眼球控制一样只是一个炫酷的功能，而非实用和常用的功能。想想看倾斜翻页确实很酷，但是真的用起来肯定还是比如手指翻页精准呢。
了解Amazon的Android SDK
不同于以往的Amazon发布的Kindle，这次发布的Fire Phone还提供了自己的略有不同的Android SDK。Fire Phone所实用的移动操作系统是基于Android 4.2.2，API Level 17深度定制的系统，所谓深度定制就是加上了上边的所提到的那个功能以及跟Amazon的一些服务进行绑定等等。一般发布到Google Play的应用程序只要支持Level 17就可以安装在Fire Phone上使用，得到Amazon的审批也能发布到其App Store上供更多用户下载安装。
但是要想使用之前提到的那些特别的API来支持Fire Phone特有的功能和特性，就必须使用Amazon提供的SDK来编译和发布了。Amazon上有提供文档教开发者如何安装Add-on，如何修改IED和配置文件来达到所需的编译要求。（如果没有Fire Phone实体机器做开发，Amazon也提供了一些Library和Apk来让普通的设备和模拟器变得可以支持HeroWidget展示，对于其他功能就必须要在实体机器上测试才是最好的。）
这一切都不难，问题在于它使Android 4.2.2，而最新的Android版本已经到了Android 4.4.2，API Level 19。有时候开发Android程序的时候会想用最新的功能但又要向后兼容，所以常常会用到Build.VERSION_CODES。在我们的程序中就用到了 Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT的比较来支持KitKat版本的功能。结果换到Amazon的SDK，因为是4.2.2所以在Build.VERSION_CODES下没有KITKAT的定义，所以全部变成Error。因此为了支持Amazon的新特性同时维护当前Android最新版本就免不了做相当大得改变，对于将来的长期维护投入也非常大。这也是Android碎片化所带来巨大的代价。
只能怪Amazon的定制太深入了，如果只是新增一些库，而不是需要用完全不同的SDK进行编译可能对开发者带来的麻烦就会小一些。但另一方面说来，要想在Android上做出差异来，这些就是难以避免的吧。
是否为Fire Phone做开发，这是个问题
Fire Phone现在刚刚出来，对于市场和用户是如何反应还没有结果。对于开发者而言是否要为其做开发也是很大的问题，因为如果能早一步进入受用户喜欢的市场，就能比其他人有一定的优势。如果iOS最早期的开发者都会觉得当时获得用户可要比现在简单多了。但是如果市场不接受这个设备，过早的投入其中也只是浪费时间和精力，比如Windows Phone。
我之前都在为iOS做开发，后来转到了Android，虽然对Java总保有缺憾感，但是Java和Android的开发性和代码的开源性是我非常喜爱的。对于开发中不明白的地方和API使用问题不在需要去猜测和试验，可以直接通过阅读源码来找到答案，也可以通过了解源码来熟悉整个系统代码规范和编码风格，这是非常有助于程序员成长的方式。但是Amazon的SDK并不是开放的，无法看到其源代码，因此对于API的解读只能从文档和实验中获取，这也让我非常不情愿对Fire Phone进行开发。
每个人都会对Fire Phone有不同的评价和期望，有人觉得会卖得好，有人觉得卖得贵，有人觉得卖不出去，但是真得怎么样也只有等到更多人真正体验之后才能知道。如同iPad以及iPad Mini刚出来的时候都觉得不会有好的市场结果后来证明这些尺寸却正是用户所需要的。也许Fire Phone的4个额外的摄像头的动作捕捉技术也会引领一个潮流也说不定。如果说以前使用触控笔是一种单点技术，那么使用手势就是二维技术，那么该是时候进入动作捕捉这样的设备三维技术了。
