深蓝合作开发规划
背景
技术背景
- 反射架构的完成。一键适配成功率达到百分之九十五以上,颠覆传统的patchrom方案,适配效率提高.由于反射架构的是以后的更新和维护可以达到批量更新的水平,而无法投入太多的人力更新维护.
- 无线刷机方案的日益完善,用户刷机难度降低,利于推广,而且无线刷机后台编译服务器可以提供给民间开发者使用,可以帮助开发者后台更新与升级.
- 双卡sdk的完善,给开发者提供了更广的选择.兼容高通4.4方案,和高通5.1方案.
公测背景
从tos社区和官方微博的反馈来看反馈良好,但是从公测机型日活跃量和增长的速度来看,不太乐观,用户流失较多,其中一加4.3累计用户最多但是日活跃量减少,三星系列留存量还算乐观,小米系列数据比较保守,因为我们是以民间名义发了MI3两款机型。大神F2努比亚双卡的留存量还好,但是刷机量并不大,其中大神F2暴露很多问题,这些问题主要是由于官方特色功能较多改动较大双卡的原因,从tos社区论坛反馈的问题可以看出用户还是很支持TencentOS.
市场背景
从一开始刷机只是为了解决性能问题,到刷机为了增添功能,如今用户最想用的也就是稳定简洁的ROM,从TOS设计理念中可以看出力争简洁试用清新风格,针对的是一般用户,用户刷机只是为了得到更高的用户体验.而非狂热的刷机用户,再加上刷机APP的完善,降低刷机门槛。所以有利于TOS品牌的推广.
TOS合作开发者原则问题
针对本次公测机型暴露出来的问题。特提出以下几点原则.
- 取舍原则
- 更新原则
- 测试原则
取舍原则
取舍就是底包扩展功能的保留,和底包修改的功能的统一问题.考虑改原则主要是为了提高用户体验,减少用户在使用过程中的疑惑,打造好的口碑.尤其是反编译适配中,需要适当的取舍.这样才能保证用户不因特定的功能而流失.
- 对于原厂和谷歌原生都有的功能,但是原厂有改动或者扩展,应该遵循的原则.
- 原厂特色功取舍原则.
拿大神F2在公测中暴露的几个问题来分别说明这两个原则.以下列出在TOS社区用户反馈的问题.
第一个问题是大神F2针对灭屏幕时间采取策略,策略一是在不充电试用过程中灭屏时间遵循原生,充电过程中默认的灭屏时间为30秒,并且在原厂设置中有设置选项,但是适配好的TOS却没有改入口,所以用户在试用过程中,充电的情况下设置灭屏不生效的的问题,这是底包扩展AOSP的功能,从实现方法来说,不需要太多底层硬件的支持,第二个问题是因为大神F2修改了USB调试界面,修改其中的逻辑如果想打开USB调试必须先打开MTP大存储模式,也是略微对框架功能机型微调,所以当遇见底包对AOSP机型扩展或者略微修改的情况下,切不需要太多底层硬件支持,仅在框架层实现的功能,应该与AOSP保持一致.
第三个问题,其实是底包对原生功能的扩展,需要底层硬件的支持,是一些特色功能.对于这些实用切使用频率搞的功能建议保留,只要和TOS设计思维一致,不冲突.就需要适当的保留.因为用户早已习惯这些功能,而且从适配的角度来说增加高级设计就可以保留.所以这里要取.原则如下 需要底层硬件支持,切有设置选项的,再适配中应适当保留
更新原则
TOS针对的用户群体是一般用户,所以更新的频率不应该太高,两周一更新就可以满足用户的需求,但是这次公测遇见一个平台型问题,官方修复略显迟钝,就是淘宝全线Crash问题,所以应快速给予修复与推送.民间开发者也可以给据问题的严重性给予适当的推送与修复.对应明显影响使用的bug,应该修复后给予立即推送.
测试原则
TOS刚公测,前期要严格把控ROM质量,所以不能像以前的推广模式,由开发者随意外发ROM.应该对系统APP用专业测试脚本进行测试,先看下公测机型的Crash统计,如图1-1所示.主要测试策略如下先列出如下几点.
- 对系统APP进行压力测试,用专业Monkey测试脚本对做好的TOS进行压力测试,时长为12小时,找出系统中明显的Crash问题.
- 对设置中核心功能进行手动测试,测试是否设置有效
- 对CSP进行重点测试,因为这是用户使用频率很高的,会直接影响用户的使用.
- 对应用市场TOP-20应用进行压力测试,使做出的ROM满足大众用户的日常使用.
技术支持
主要是双卡方面的支持,以及平台性问题的支持,双卡适配难度较高,而且各个厂家的方案各异,民间开发者在没有源码的情况下很难适配双卡,所以需要官方支持,平台性问题,由FT支持.
- CSP支持。
- 平台性问题支持
从图2-1 ROM App crash 率横向对比图可以看出民间Phone app crash率最高 ,这个主要是因为厂商对Phone进行了扩展,TOS Phone并没有实现改接口,再加上双卡适配难度较高,需要官方提供支持.官方应该开放双卡SDK,公布实例机型让民间开发者参考.
平台性问题由官方推动解决.
基于以上背景,深蓝合作开发推行精英计划,开发者限定特定厂商机型,专心维护某品牌。
其原因基于以下几点考虑.
- 一般特定厂商的机型在适配机型中,问题基本上一致,这样开发者只要做好一款典型机型就可以轻松适配其他机型,这样同时保证适配机型ROM的质量.
- 把控开发者开着数量,这样才能把控适配ROM的品质.
- 前期只做代表机型打造口碑,不易做太多的机型.
从公测后的刷机App的刷机数据可知,刷机APP刷机成功率达到百分之百,但是由于校验太过苛刻,很多用户手机使用的系统被无法真确匹配,所以最终用户用上TOS系统甚少,其实早期刷机APP公测去除了部分开发者能够使用的功能,比如通过无线刷机APP来适配TOS.只要开发者适配相关机型的ROM,用户使用无线刷机APP的时候就会自动匹配到相关ROM,进行刷机,最终转换成TOS用户.
首先可以分析TOS深蓝合作开发的必要性.
- 官方已经完善了TPS 无线刷机APP,现在正处于TOS1.0 版本到 TOS 2.0版本的迭代时期,官方需要精心打磨产品,无需要在机型适配上投入过多精力,只用做几款代表,打造口碑.
- 刷机APP已经做的基本上可以供开发者使用,但是后台可供用户刷机使用的ROM有限,继续补充适配,才能大范围的推广TOS.需要通过部分推广打造刷机APP的高成功率,低成”砖” 口碑,使普通用户不用担心刷机的风险,愿意更换TOS系统.让换用户体验到刷TOS如同安让应用一般简单无风险.
- 未来推广民间合作开发必定超过官方.民间适配是推广的主流.如今官方已经完善了相关开发工具供民间使用,官方可以减少开发人员在推广环节的投入,更专注与TOS产品本身.
官方需要提供支持:
- 提供编译服务器,让开发提交用TPS适配好的TOS工程目录到官方编译服务器,由官方编译服务器自动迭代升级民间适配TOS.
- 提供Web界面供开发者配置适配机型的安卓版本号 基带版本,本机型ROM是否放开校验进行升级. 提供后台编译好的ROM的下载地址让民间来验证,服务器自动迭代版本是否能用,并由开发者决定外发某个版本的ROM,并且由民间验证无线刷机APP的可行性,并配置刷机APP应该校验的属性,已经匹配成功后的ROM推送地址.
- 提供Web界面,让开发提交补丁,以及提交工程文件.
- 官方提供开着能够启动自己维护机型的构建权限.
民间开发者应做到:
- 及时验证服务器自动迭代版本的ROM是否能正常使用.如果出现问题及时修复,并提交补丁文件到后台.
- 决定上线服务器自动迭代的ROM.
- 验证无线刷机APP的可靠性,与成功率.