您所在的位置:小祥子 » 编程 » 程序猿 » 正文

移动开发中的那些见闻轶事

时间:2015-06-10 编辑:佚名 来源:本站整理

作者:Lucida  微博:@peng_gong  豆瓣:@figure9

博客地址:http://lucida.me/

“移动开发的那些事”是一系列文章,我在开发移动应用时经历的见闻轶事,每篇文章由若干个移动开发相关的小故事组成。


                                                    移动开发的那些事--1:序曲
这系列文章不是技术文章——但我打赌你会从中看到一个很不一样的移动开发——或者说是一个具有中国特色的移动开发——并且能学到不少东西——不信的话就继续阅读。 

  • 入坑

  • 刷榜

  • 人造用户

入坑

我在读研时很幸运:不同于其他研究生导师,我的导师 张莉 老师给了我充足的时间让我做各种自己感兴趣的事情。因此我既阅读了大量计算机书籍(程序员必读书单 这篇文章中的大部分书籍都是我在读研时阅读的),也阅读了不少经典计算机论文。

当然还做了很多移动应用,这才是这篇文章的重点。

其实本来我的读研生活应该是就这样读书读论文然后找工作(当时我真的连找实习的念头都没有),直到我参加了一次豆瓣读者书友会。

在研一下学期的一次 Jeffrey Richter 读者书友会 中,我误打误撞(原定的翻译因病缺场,因此我就自告奋勇上台了)的为 Jeffrey Richter 进行了 现场口译 ,由于我翻译的还不错,所以引起了书友会的另一位嘉宾方敏(当时是微软的 Principle Testing Manager)的注意,在他的鼓励下,我得到了微软的实习机会。

微软的实习环境很宽松,于是我一边做实习任务,一边在微软阅读各种计算机书籍和经典论文论文,并顺便翻译了一本 JavaScript 小书(JavaScript修炼之道)。

之后,由于研究生开题和实习时间冲突,我离开了微软。然而花了两周时间准备好开题之后我又闲了下来,但由于已经有了实习经历使得我根本闲不下来——巧合之下,受朋友的邀请,我加入了一个小创业公司 OctInn 制作 iOS 应用,尽管在这家公司我只待了不到一个月,但创业公司的文化让我大开眼界——从零开始制作产品,进行市场推(Shuā)广(Bǎng),根据用户反馈快速迭代,从而打造用户需(Tāo)要(Qían)的产品。

从而正式跳入了移动应用开发这个大坑。

刷榜

刷榜算是移动开发界公开的秘密——因为做一款应用容易,但如果想把应用推到排行榜前列(尤其是 Apple 的 AppStore)就没那么容易了。每个应用市场都有自己的排行榜算法,但无外乎是下载量+评论量+打分,其中评论和打分的权重相当高(所以你会看到很多应用都在无时无刻的乞求你打个好评)。

下载量很难在短期积累起来(没有那么多的 itunes 账号),但评论和打分就要容易很多(2011 年时 1000 个好评就足以把一款新应用推到 AppStore 排行榜前十名)。这也就催生了各式各样的刷榜服务——印象里当时淘宝搜刷榜可以搜到上百个结果,一条评论的价格从两毛到一块,千条以上的评论可以再打个八折,此外还有包周包月服务(例如保证你的应用在这周内一直是前 10 名),一应俱全,无比贴心。


所以故事是这样的:我朋友的一个朋友在做 iPhone 应用,为了推广应用,他在刷榜上就花了上万元,但效果还是不理想。

苦逼了数日后,他突然开了窍——既然刷榜这么贵,我帮别人刷榜岂不更赚!?于是他注册了几个邮件服务器,搞了几十台旧电脑,写脚本注册了一万多个 itunes 账号,然后架网站开网店提供刷榜服务。

结果第一周他就把之前做应用(包括刷榜)的成本收了回来。

两个月后换了一辆崭新的宝马7系。

我无法证实这个故事的真实性,但我倾向于相信它:一方面因为当时的刷榜确实是铺天盖地,另一方面因为我自己也做与过类似刷榜的活,这就是下一个故事。

人造用户

严格来说我做的并不算是刷榜,而是一个严肃的算法问题 –_–#

  • 刷榜的第一步是需要制造大量的用户;

  • 注册用户的第一步是提供用户名;

  • 所以说刷榜的第一步是制造出大量的用户名;

  • 而这正是我要解决的问题。

估计你的第一反应是,生成一个用户名还不简单,一个前缀加一串随机数不就行了嘛!没错,事实上不少国内互联网公司在早期“积攒”用户量时就会用这种方式,生成一堆诸如「手机用户1879102471829」或「老鼠爱大米52178903729」之类的诡异用户。

但并非所有公司都这么没追求——比如一些有追求有信仰的公司认为「手机用户1879102471829」这样的用户名太 low 逼——尼玛这也假的太明显了吧!

于是我就接到了一个这样的神奇私活,要求生成五百万个中文用户名,五百万个英文用户名,用户名不重复,且不能假的太明显。

英文用户名很容易生成,因为英文就26个字母,元音就是 AEIOU 辅音就是剩下的 BCDFHGHJKLMNPQRSTVWXYZ,再加上一些诸如ui,ae,en,ia之类的组合元音和 Kn,Ch,Rh,Cz 之类的组合辅音,我很快就有手工打好了一个元音表和一个辅音表,接下来把元音和辅音交替相连,就可以生成诸如「Rhonada」,「Knaemia」,和「Yoshida」之类的「逼真」英文名。

举个例子

随机选一个辅音——得到“Z”;

随机选一个元音——得到“oe”;

随机选一个辅音——得到“d”;

随机选一个元音——得到“ah”;

程序终止——返回“Zoedah”。

中文用户名的生成就没有那么容易了——因为汉字实在太多,但好在网上有各式各样的姓名库,于是我扒了几个姓名库合并了下然后枚举组合很快就凑齐了五百万个中文用户名。

这下任务就完成了!我发了部分用户名给客户,客户表示很满意英文用户名,但他同时表示中文用户名真的有点太假——因为很多中国人起名时并不会使用自己的真名,而是起一些流行语/数字/明星之类的名字(比如「卷福爱花生」或是「李敏镐521」之类的用户名)。

仔细想想,客户说的话很在理——于是我又重新调整了程序——这次的生成代码要复杂很多,它会首先选择一个分类(动物/动漫人物/明星/地名/动词)下的一个词,根据选中的分类,它会再从随机从下一个相关分类中选一个词,然后一定概率停止,一定概率继续选择。

再举个例子

  • 随机选一个分类——得到地名;

  • 在地名分类下随机选一个词——得到「加州」;

  • 随机选一个和地名相关的分类——得到菜名;

  • 在菜名分类下随机选一个词——得到「红烧肉」;

  • 程序终止——得到「加州红烧肉」。

客户这次终于满意了,在付清了余款后,我就把剩余的「千万用户」发给他,他表示很满意很 Happy。

然后没过多久我就在网易新闻看到某国内知名互联网企业宣称自己用户量突破千万。

好吧也许是巧合。


移动开发的那些事——2:探索

上文提到,我只在 OctInn 待了不到一个月。尽管创业公司的文化很有趣,但我一方面想自己做点东西,另一方面我个人不太喜欢 Apple 的那套东西——尤其是 Objective-C 翔一般的语法和 XCode 翔一样的体验。由于之前在微软实习,加上自己搞 C# 也有不短的时间,我把目光放在了 Windows Phone (下文简称 WP)上。

这里顺便讲一下 WP 当时的情况:WP 在 2011 年是一个极度小众的系统(印象里市场占有率不到 2%,当然现在 WP 也很小众),但考虑到 WP 背后是微软,加上一些站长眼红一些移动论坛(例如 威锋网)的成功,所以建立了各种 WP 论坛,酷七网和 智机网 就是在这个时期出现的。总的来说,WP 在这当时势头还不错。

讲完了背景,继续回(Tǔ)忆(Cáo)。

学生计划

尽管 WP 当时的势头还不错,但应用实在太少——为了增加应用数量,微软搞出了一个学生计划(印象里叫什么春风计划,大致是提交3个应用就可以获得 Nokia Lumia 800 手机一部)鼓励学生开发应用,配合微软的 DreamSpark (即为学生免费提供开发者账号,Visual Studio 开发工具),学生可以不花一分钱就提交 WP 应用到市场上,非常方便。

学生计划的本意很好,但微软忽略了一点——数量不等于质量。在这个学生计划之后,WP 市场上出现了一大批垃圾『单页(Single Page)应用』——只有一个页面,点两下就崩溃,毫无实用价值。

我印象比较深的一个『单页应用』叫做「省份简称查询」。它是做什么的呢?查询中国省份简称 –_–||

一个页面,一个按钮,两个文本框。

输入『冀』,输出『河北』;

输入『京』,输出『北京』;

输入『加州』,程序崩溃。

另外一个我印象很深的应用叫『计数器』。

怎么计数呢?点屏幕。屏幕上有个数字,点一下这个数字就加 1。

需要注意的是,这个应用不支持两位数——因为到了两位数第二位会跑到屏幕外面去。

很难想象这些应用是怎么通过审核的。我猜测微软当时是把应用数量当成 KPI——不管质量,只管数量。先凑够十万个应用再说。

后来很多人诟病 WP 应用的质量,取笑 WP 应用都是学生开发的 low 逼应用。

几个月后,微软又搞了个『夏日计划』——提交5个应用就可以获得NOKIA手机一部。

–_–||

科学计算器

扯完 WP,回到主题——我当时打算做一个移动应用,这个移动应用应该:

1.能够做出来;

2.有技术含量;

在这两条『需求』的指引下,很快我做出了第一个作品——科学计算器。

和手机内置的计算器应用不同,这个科学计算器接收的是一条完整的表达式,而非一个数字一个运算符那样的计算。你可以直接输入1 + 2 * (3 + 4)然后算出结果,而传统的计算器在碰到括号时就会很麻烦。

由于计算器没有什么 UI ——无非就是一堆按钮加上一个文本框,所以它满足需求 1;由于需要计算完整的数学表达式并检查其语法,所以它满足需求 2。我当时对这个应用很有信心——毕竟又有技术含量,又比同类应用强大,没理由不火。

理想很丰满,现实很骨感,这款科学计算器应用到最后的用户也不到10个——评价是1星半——大多数用户都不知道怎么使用。

当时我一度认为用户都是傻逼——不会用难道你们不会学吗!郁闷之余我去中关村图书大厦闲逛,无意中读到了 触动人心:设计优秀的iPhone应用 这本书。

读过这本书我才意识到,不是用户傻逼,而是我自己二逼——二逼到去做一个没有任何用户需求的『产品』,二逼到把技术难度等价于产品价值,二逼到要让用户去学习怎么用一个手机应用。

花了两天读完 触动人心,我开始着手下一个应用。

WP 101

科学计算器的失败除了让我意识到用户需求是关键,还让我意识到自己的 WP 知识实在不足。于是我开始寻找 WP 开发书籍,这时我发现了一本绝好的 WP 开发书籍—— 101 Windows Phone 7 Apps,它从零开始由浅入深,通过 50 个实例介绍了 WP 的风格,控件,以及具体应用,并提供了示例代码以便参考。

我从这本书里学到了大量的 WP 知识,但这本书的作者做梦也没想到,这本书的示例代码变成了 WP 垃圾应用的一大源头。

前面提到微软为了增加应用数量所以搞了个学生计划(5 个应用换 NOKIA 手机),而这本书的实例代码正好就是 50 个完整的应用——于是大量的机(Dòu)智(Bī)学生直接把这本书的示例代码换了换文字,提交到 WP 应用市场以换取 NOKIA 手机,更加逗逼的是微软居然让这些应用上了架——保守估计,当时 WP 市场里有上千个应用都是这本书示例代码的『Fork』版。

决定器

阅读了 触动人心 和 101 Windows Phone 7 Apps 之后,我开始着手制作下一个应用。

由于还是把握不准需求,于是我很鸡贼的把目光移到 iPad 上——反正想不到什么好点子,不如向 iPad App Store 排行榜前十名取经——Steal like an artist。

一番调研后,我发现有个转盘应用还不错,排名很高(第 6 名,不过当时我还不知道有刷榜这一说 –_-),而且做起来也很容易(就是一个大转盘,里面有 ABCDE 几个选项,转到 A 就得做 A,转到 B 就得做 B)。于是我花了两天时间把这个应用『移植』到 WP 上,取名为『Smart Decider』(当时 WP 还没有中文市场)。

现在再看,这个应用非常弱智——由于当时不熟悉 WP 上的动画,于是我连动画都省掉了 –_–#

首先是应用介绍:

创建一个新『项目』:

点击开始做『决定』:

得到『决定』:

也可以从创建/已有的『项目』选择:

尽管很粗糙,但它在上架之后一周就收获了 200 多名用户,而且得到了全五星评价(好吧只有两个评价,但确实是全五星)。它让我重新找回了信心,并试图做一个更『大』的应用——既然这种应用都能拿到 200 个用户,那我再认真些是不是能搞定 2000 个用户?


                                                            移动开发的那些事--3:从零到一万

所以我打算做一个『大用户量』的应用(见上文),那么从哪里下手呢?
我的想法很直接——只有解决用户的『根本』问题,才有可能得到大用户量。
说来也巧,这时我正好在 WP 论坛看到大量 WP 用户吐槽 WP 的通讯录反人类。考虑到手机通讯录是打电话和发短信的出口,而打电话和发短信又是每个手机用户不可或缺的日常任务(也就是前面提到的『根本』问题),我决定以通讯录作为入口,打造我的第一个『大用户量』应用。

考虑到很多童鞋都没有接触过 WP,所以这里有必要先介绍下 WP 的通讯录是如何反人类:

WP 通讯录

我们知道,通讯录一般是以姓/名做索引。但为了找到某个人我们并不需要输入他的全名,更快捷的方式是输入他的姓/名首字母(也就是 Initials),例如查找『张晓明』,理想的情况是输入『ZXM』进行匹配,而不是输入『ZHANGXIAOMING』或是『张晓明』。

然而 WP 只支持两种匹配——第一种是前面提到的颇为二逼的全称匹配;第二种则是简单粗暴的姓首字母匹配——『安』姓在『A』下,『章』姓在『Z』下,依次类推。WP 还用了一个颇为炫酷的控件(LongListSelector)实现快速跳转:

姓首字母匹配看似快捷,但实际使用起来更加麻烦——因为中文姓氏并不是均匀分配的,常见姓氏集中在『L』(刘,陆,连,李),『W』(王,万,汪,闻),和『Z』(张,赵,章,郑,钟)这几个首字母下。以之前提到的『张晓明』为例,由于 WP 只支持定位到 Z 下,这意味着用户每次都需要在 Z 分类下的几十个甚至上百个联系人里面线性查找,以我自己的通讯录为例,每次我都需要滑动四五秒才能找到这个张姓少年。

这个操作不是一般的傻逼,加上当时不少 WP 用户有不少来自 NOKIA,他们用惯了 Symbian 下面的 T9 模糊匹配,更加无法忍受这种反人类的操作。以至于当时的 WP 论坛里要求微软更新通讯录程序的呼声一片高过一片。

考虑到 Symbian 和 T9 离我们已经很遥远,我在这里再简单介绍下 T9 联系人匹配:


还是以『张晓明』为例,在 T9 模糊匹配中,『ZXM』,『ZHANGXM』,『ZXMING』,『996』(不是 996 加班哈,在九宫格键盘中,『996』分别对应『ZXM』),以及『9426486』(对应『ZHANGXM』)都可以匹配『张晓明』。可以看出这种搜索方式的先进性——既不需要打出全称,也可以迅速的在大量联系人中匹配到需要的联系人。

短信群发

你可能觉得 WP 的联系人匹配已经够二逼,但它和 WP 的短信群发相比则是小巫见大巫。为什么这么说呢?因为 WP 在 8.0 之前没有联系人多选。

这和 WP 的自带通讯录简直是天作之合——我在这里举个例子,我的手机里有 300 多个联系人,我需要给『刘明』,『李伟』,和『张明』三个人群发短信,我需要这么做:

  • 编辑短信内容;

  • 添加联系人,进入通讯录界面;

  • 在『L』分类下滑动三四秒之后找到『刘明』;

  • 回到短信界面;

  • 继续添加联系人,进入通讯录界面;

  • 在『L』分类下滑动三四秒之后找到『李伟』;

  • 回到短信界面;

  • 继续添加联系人,进入通讯录界面;

  • 在『Z』分类下滑动三四秒之后找到『张明』;

  • 回到短信界面;

  • 发送短信。

更要命的是,不知道微软出于什么考虑,短信界面里的『添加联系人』按钮不是一般的小=以至于我每次都要点好几次才能『点中』(下图右上角的圆圈加号)。

也就是说,群发短信选择 3 个联系人,我需要点击屏幕近 30 下,滑动近 20 秒,而这在我原来的 NOKIA 直板手机上 3 秒之内就能搞定,能把触屏手机做的比键盘手机还难用,我怀疑微软的 UX 在哪里。

快速原型

貌似吐槽 WP 太多了 –_–#,回到正题——『大用户量』应用。

应用的需求很明确——解决前面提到的 WP 中的两个二逼点:

  1. 提供快速便捷的联系人定位;

  2. 提供快速便捷的短信群发。

对于需求 1,我可以照搬 Symbian 上的 T9 匹配;对于需求 2,我决定扩展 WP 自带的 ListView 即让其支持多选。

有了需求,接下来就是『紧张』但愉悦的开发工作:

第一天

  • 上午搞定 UI;

  • 下午搞定联系人导入/拼音转换/构建/搜索;

  • 晚上搞定需求 1;

第二天

  • 上午搞定带多选的 ListView ;

  • 下午搞定需求 2;

  • 晚上写好宣传文案和截图,然后在主流 WP 论坛上发布『内测版』;

第一版是这个样子:

联系人选择(注意支持多选):

拨打电话(请自动忽略我奇诡的审美 –_–#):

设置(提供了一些额外选项,例如精确搜索,短信前提示等等)

帮助:

以及软件Logo和作者信息:

左右互搏

在主流 WP 论坛上发布了拨号助手的『内测版』之后,我在第一天就收获了 300 余名用户,但到了第二天新用户就只有不到 100 名,我查看了论坛帖子之后发现我的帖子沉的很快,以至于很多论坛用户都没有察觉到我的应用的存在。

我希望自己的帖子被更多的人看到,但如果不停的在论坛里顶贴又显得太 low,于是我决定采用另一个看起来不那么 low 的『办法』——我把它称为左右互搏。

我是在 社交网络 学到的这个方法:电影中 Mark Zuckerberg 为了应对艺术鉴赏作业,他把待鉴赏的艺术图片发到 Facebook上,然后注册了两个账号发表对立且激进的评论,很快他就收到了他人的评论,然后他通过这些评论完成了作业。

参考 Zuckerberg 的套路,我在每个论坛上注册了五个账号,然后人为的为这些账号建立『性格』属性——小白型,喷子型,粉丝型,教学型,以及理智型。接下来的流程大致是这样:

  • 用小白账号发表无知言论;

  • 用喷子账号黑小白账号;

  • 用粉丝账号黑喷子账号;

  • 用教学账号解答小白账号的问题;

这个过程就像是点火——刚开始需要一点点耐心,但后来激烈的争论燃起来了想停都停不住——所以我注册了一个理智型账号,适当的调整讨论的热度,以至于帖子不至于成为对骂贴或是群嘲贴。

于是,我的帖子成为当时 WP 论坛的超热门贴,在论坛首页停留了一个多月之久,而我的应用在正式上架之前用户量就突破 4000,两倍于我之前的预期。

行进中开火

但不要以为我的应用是靠前面的『左右互搏』得到的用户——『左右互搏』只能把帖子提到首页,但真想要用户买账还是得拿出让用户满意的东西。

一句话:把用户搞 High,你的用户量就会 High。

编写移动应用,我当时奉行的是 行进中开火(参考 Joel Spolsky 的 Fire and Motion 一文)原则,一边修 Bug,一边加功能,一边做文案,三线齐进。

为了收集用户的需求,我一边搞了一个 QQ 群,一边搞了一个邮件列表,每天把需求收集到一起,然后综合需求的强烈程度和实现的难度,选择需求添加到下一个版本中。

键盘音

用户需要加键盘音,从市场上找到一个带声音的应用,反编译出声音文件,然后三行代码搞定。

号码所在地

用户想要号码所在地,于是从 CSDN 拿到一个还算新的手机号码所在地数据库,存到 SQLite 然后每次导入联系人时算一遍所在地,搞定。

但之后很快就有用户反映导入联系人太慢,我检查了下发现 SQLite 在 WP 上效率很差,以至于算 300 个号码的所在地就需要 15 秒左右。于是我去掉了 SQLite,把号码所在地数据库整理成内存中的三层哈希表,从而可以在 0.1 秒内搞定 1000 个号码所在地,搞定。
前缀拨号
一些用户使用 IP 拨号:所以需要使用前缀号码,几行代码搞定。

浅色模式

一些用户希望使用浅色背景:上 MSDN 上扒了一段示例代码,搞定。

常用短信

不少用户希望能有短信模板:用 Python 写了一个小爬虫爬了几千条带分类的节日短信,搞定。

一键拨号

一些 NOKIA 老用户习惯一键拨号,即长按某个数字键拨打绑定的电话,于是加了一段 UI 和逻辑,搞定。

极速更新

我把应用分为两个版本,『内测版』(即论坛的 xap 版)和『市场版』(即微软的官方市场版本),其中:

  • 『内测版』每天更新一次,有时甚至一天更新两次,尽管不稳定,但会引入尽可能多的 Feature,以探测效果和用户的反应;

  • 『市场版』每周更新一次,相对稳定,以修复 Bug 为主,以增加 Feature 为辅。

在这样『合理』但『极速』的更新频率下,到了第三周,我的应用用户量突破了一万;并进入了 WP 工具应用前五名。

一人,三周,从零到一万。

况且还是小众的 WP。

200万个号码

编写应用时我碰到各种各样的 Bug,其中大多数源自把 T9 『移植』到 WP 上:一方面是多音字(比如说『曾』应该是『ZENG』而非『CENG』),另一方面是做字符串模糊匹配时出现的各种奇怪问题。

所以刚开始做『内测』时,每天都有几十个用户反映应用出错或崩溃,这时我会问他们要他们是在操作哪个联系人时出的问题,然后一个联系人一个联系人的修复。

但应用正式上线后这种方式就行不通了——我既没有用户的联系方式,即便有,也不太可能问他要一份完整的通讯录过来——为了便于改善应用质量,我在应用里面加了一段代码,用于上传资料(包括用户的所有联系人信息)和异常信息,这样我就可以快速便捷的重现/定位问题。

我当时还没意识到这样做有什么问题,直到之后和朋友聊天提到这件事,他惊讶的来了一句:『那你岂不是掌握了几乎所有 WP 用户的联系人信息?

这时我才反应过来,我可能拿到了一些我不该碰的数据——回到宿舍,我把后台的数据下载到本机,cat grep 了下,我意识到我手上有二百多万人的联系信息。而且这二百万人并不仅仅是一个号码列表(list),而是一个信息量很大的图(graph)——打个比方,通过这些数据,我可以得知:

  • WP 用户的姓名

  • WP 用户的职位

  • WP 用户的父母兄弟姐妹朋友的联系方式以及职位

  • WP 用户在 xx 公司工作

  • WP 用户的生日

  • 甚至 WP 用户在 yy 网站的密码(一些用户把网站密码明文存储在通讯录中)

这里就不一一列举,你可以想象下如果这些资料落在经验丰富的骗子手里会发生什么事情。

出于对犯罪的恐惧(我可不想像某『疯狂的程序员』那般疯狂到监狱里 –_–#),我在接下来的版本删除了上传资料的那段代码,并清除了用户的数据。

但从此之后,我开始担心移动应用带来的安全隐患——如果像我这样普通的个人开发者都可以通过编写应用获取上百万用户的个人信息,那国内那些没有节操的大公司会怎么做呢?

这也是我反感/鄙视 Android 的原因——无论什么应用,小到阅读器,大到社交应用,每个应用都恨不得把所有权限(这自然也包括联网,读取短信,和读取联系人信息)搞到手。

装个官方微博要读联系人和短信

装个官方多看阅读也要读联系人和短信

装个第三方壁纸尼玛还是要读联系人和短信

去尼玛的 Android。只恨当年乔教主剿匪不力,留下 Android 这个祸胎。

I will spend my last dying breath if I need to, and I will spend every penny of Apple’s $40 billion in the bank, to right this wrong. I’m going to destroy Android, because it’s a stolen product. I’m willing to go thermonuclear war on this.

Steve Jobs

2.0 效应

尽管拥有一万多个用户让我感到很有成就感,但频繁的更新和没日没夜(每天都要写到三四点)的写代码让我疲惫不堪,寒假过后,在完成了 1.7 版之后,我决定停下这个应用,回微软继续实习。

说来也巧,当时微软正好要招几个开发 WP 的实习生,所以我很轻松就进去了。

然而实习了一段时间之后,我又开始手痒了,这次我打算做一个大幅更新,解决之前所有的问题,也就是 2.0 版。

中文拼音库

前面提到中文存在多音字问题,我在应用的第一版并没有去解决这个问题,而是手动的标注多音汉字。

在 2.0 版中,我决定支持多音字,尽管存在一个很全很完整的 微软拼音库 ,但它无法在 WP 下运行,而且速度很慢,于是我花一个晚上把 微软拼音库 移植到 WP 上,又花了一天调整了下效率,这也是 Lucida拼音库 的前身。

改进的模糊匹配

旧版拨号应用的速度很慢,尤其在联系人上千之后就会感受到明显的卡顿,于是我在新版中更换了数据结构和查询算法,速度是上去了,但代码变的异常复杂,暗坑遍地。

重写 UI

大键盘

不少用户反映旧版拨号应用的键盘很小,于是我在 2.0 版中按照 WP 的系统拨号键盘的大小重新制作了大号键盘:

但我又发现另一个问题,大号键盘太占地方,以至于一次只能看到 2 条联系人信息,为了能够显示尽可能多的信息,我引入了侧键盘——把大号键盘滑下去,侧键盘就会从屏幕左边弹出来。

我自己认为这个 UI 很炫酷,但我的 UX 朋友非常犀利的指出这个功能过于隐晦,恐怕不会有人用,事实上也是如此。 –_–||

下滑手势

大键盘带来的另一个问题是我没法使用任务栏(即 App Bar),不然就没有空间显示搜索结果了。

既然不要能用任务栏,那么设置页面的入口应该放在哪呢?

2012年初正好是 iOS 5 发布不久,而iOS 5 引入了下滑 通知中心,受到它的影响,我很自然的把设置页面放在了下滑页中:

内置输入法

尽管 T9 模糊匹配已经很方便,但我还是在想能不能把它做的更便捷——因为一些用户反映在面对『张』,『王』这些姓氏时还是需要敲好几下屏幕(『张』,『王』都在『9』下面,所以需要进一步区分)

花了几天,推翻了各种方案,我决定把联想输入法引入拨号应用,我的思路是这样的,把用户的联系人构建成词库,然后以这个词库进行联想输入,从而提高匹配的精度。

由于找不到可以直接用的输入法库,于是我就照着 WP 输入法的样式写了一个输入控件,效果是这样的:

这样的好处在于可以更加快捷的指定联系人,以『杨晓玉』为例:

  • 使用 T9 模糊匹配需要输入『999』,但仍需要在『张小云』,『王小云』,以及『张志勇』等可能的匹配项中进行选择;

  • 使用联想输入法则只需要输入 『9』 –> 『杨』 –> 『99』 即可匹配。

第二版效应

我几乎把我所有能想到的改进都写进了 2.0 版中,而每一个改进又会引入几个新的问题(例如大键盘的引入导致我加入了侧键盘和下滑设置页面),加上我当时还在微软实习,能自由支配的时间并不多,所以整个这个过程耗费了大量的时间,从开始编写到完工,足足用了三个半月。

2.0 版并没有达到预期效果:由于 2.0 版的改动过大,一方面导致各种各样的新 Bug,另一方面导致一些老用户的流失(不知道如何使用),同时市场上出现了一款更好用的拨号应用 瞬手拨,从而我的应用很快就失去了之前的领先位置,逐渐淡出了 WP 市场。

现在回想下,这正是 Fred Brooks 在 人月神话 中提到的 第二版效应 的典型示范:

The second-system effect proposes that, when an architect designs a second system, it is the most dangerous system he will ever design, because he will tend to incorporate all of the additions he originated but did not add to the first system due to inherent time constraints. Thus, when embarking on a second system, an engineer should be mindful that he is susceptible to over-engineering it.

总之,这个拨号应用最后还是失败了。但它为我上了一堂异常珍贵的软件工程课——这是读多少本书都学不到的。

未完待续

下篇:移动开发的那些事——4:非常格调

关键词: