FIR.im 真的是一家产品节奏很快的公司,创始人王猛虽然一直说自己不善言表但是当我问到每一个功能规划或者细节都能有很清晰的答复。我曾经在 WISE 1.0 大会上问到他们的功能,现在几乎全都实现了。
“FIR.im 从来不把自己定位成一个应用发布渠道,它应该是一系列围绕应用开发者的深度服务”,这是 FIR.im 市场负责人石争妍在一开始告诉我,最后被创始人王猛印证的一句话。由于是氪空间第一个入驻团队,fir.im 现有的基础功能已经无需多做赘述。他们近期在原有的 FIR.im 应用测试平台中上线了测试用户访客密码、历史版本和数据统计功能。
访客密码是对原有用户权限管理体系的增强。对于创业公司或中小开发团队而言,要实现测试用户和项目负责人、开发人员的对接就需要尽可能将他们放在同一个平台内。用户分级机制是实现内外部人员联系、管理的基础,外部测试用户获取对外可对外发放或需要重点测试单独功能的版本,内部人员则可以获取更细分的迭代版本从而进行测试或参与相关工作。在这些基础的分类之上,还可以进行进一步的小范围测试、大规模公测用户分类。
很自然地,访客密码和历史版本也是基于同一需求的上层功能。在 FIR.im 允许将应用的 Android 和 iOS 版本合并到同一个下载地址之后,再一次简化了开发者在发布应用、更新时的步骤。此前开发者需要逐个收集、添加参测用户的账户、邮箱,把它们添加到测试列表当中。访客密码上线后,开发者只需要将地址和访问密码发放给允许参加测试的用户,用户就能通过地址直接下载测试应用。至于针对测试地址的访客数量、过期时间等权限控制细节会在后续完善上线。另一方面,历史版本允许开发者在上传的多个构建中挑选适合发布的几个开放给用户下载,同时在控制板中保持对所有上传、更新构建的管理。
环节简化还不止这些,依靠同时上线的数据统计功能,开发者已经可后台看到测试应用覆盖的设备数,每个设备的型号、系统版本,以及用户 UDID。用户在申请测试时,开发者只需要添加用户的 FIR.im 账户,系统就会自动关联这个用户的 UDID。
我之前一直对 FIR.im 不太理解的一点在于,虽然他们一直强调自己是一家开发者服务公司,但之前的功能似乎都专注于测试分发、管理等这类靠近终端用户的功能 —— 在我认识王猛之前。FIR.im 在开放 API 之外还上线了 FIR.im CLI (由 Ruby 编写)的命令行工具,开发者可以通过它直接将本地应用上传至 FIR.im 后台并发布、配置全局设置、获取应用信息,或对应用包进行签名。
王猛曾经在 GitHub 上开源过一个名为 Xtodo 的 Xcode 项目管理插件,他们说的使用量和其他开发者提交量我在访客页面并无法看到。但对于 一个个人开发者制作的插件而言,近千次 Star,近百次 Fork 应该是不错的成绩。接下来他们会考虑将 Xtodo 类似的功能与 FIR.im CLI 一并制作成 Xcode、Eclipse 插件。
“当我们的工具接入 IDE,就能基于代码为开发者实现很多服务”,王猛说。比如,很多开发者在频繁的更新过程中可能会忽略 Changelog (更新日志)的编写,而编译器插件可以通过抓取开发者标识的注释自动生成 Changelog,甚至可以根据应用此前错误报告关联代码的更改自动识别生成 Changelog,若此次更新在后续发放中被证明仍未修复问题,FIR.im 也会自动在当前版本的 changelog 中删除相应说明。
提到错误报告,也就是 BugHD 这项服务存在的原因。FIR.im 专门为 BugHD 服务设立单独域名,供开发者使用这个服务。BugHD 包含崩溃分析、用户反馈 SDK 和后台数据查看功能。
BugHD SDK 集成入应用后最终占用的大小在 100k 左右,供开发者手机崩溃信息和用户反馈。关于用户反馈的具体实现形式王猛并没有细说,只告诉我会“改变现在简单的填表式用户反馈”。在数据后台,应用的 Android 和 iOS 版本并未放在一处统计,而是分别以单独应用形式展示数据,统计数据包含用户设备、系统版本、所处网络环境(细化到 2G、3G)、涉及的具体方法。未来配合 IDE 插件,还可能实现基于崩溃信息的错误代码定位和常见修复建议。
作为工具类服务,集成化、可定制化和平台化是对开发者这个硬派理科生群体而言更理想的方式。FIR.im 和 BugHD 都选择了开放 API,并与 Teambition 和 Worktile 实现对接,让开发者可以打通项目管理、用户反馈等环节。另外,FIR.im 还有一个双向消息体系,这个体系可以接入不同平台、工具,开发者对其进行定制后可以在常用项目管理工具上实时获取所需消息或发送远程指令。
最后,FIR.im 现在很缺运营方面的人手,感兴趣的读者尽快通过广场的各种渠道联系他们吧。