我的首个盈利 Side Project

摘要：两个 Android 开发从 0 到 1 开发出一款工具应用并上架国内市场，盈利过万元的故事。

Idea 的诞生

2018 年初我在北京一家互联网公司任职 Android 技术专家，带领一个客户端开发团队。我有个前同事——以下称为乔峰——当时在另一家以产品打法凶猛著称，加班也不含糊的公司做 Android 研发工作。我们经常讨论各种 app idea，寻思业余时间做个 side project。正好那时答题很火，有天我在网上看到有程序员写了一个辅助答题的命令行工具发布到 GitHub 上，很多人关注。它是用 adb 命令截屏然后 OCR，再用搜索引擎匹配答案，原理很简单。我心想这样搜索出来的答案准确率不可能很高，没法靠这个去答题得奖金。过了几天我突然意识到，虽然准确率不高，没法凭此去赢答题活动的大奖，但是对普通用户来说，有这么一个工具辅助提高胜率，仍然有价值，甚至可能为此付费。我立刻和乔峰说，要不做一个辅助答题的 app。我们快速讨论了一下这里面涉及的技术，认为完全可行，当即决定启动。

第一行代码到上线

根据 Git 记录，乔峰在一个周六提交了第一行代码。从第一次提交到上线，我们用了 15 天。虽然 Android 应用开发我们是老手，但这是我们第一次脱离公司的基础设施，在国内市场独立发布一款 app。第一版硬编码支持了六个当时有答题活动的应用，用户在答题时可以通过悬浮窗查看推荐答案。没有用户登录体系，没有自己的后端接口，唯一直接发起的网络请求是调用百度搜索结果页。应用内升级和崩溃搜集靠免费的 Bugly。关于页面只留了一个客服 QQ。在酷安上架。

快速迭代

第一版很粗糙，上线后开始迭代。我们很快添加了答题活动时间轴，修复各种 bug 提高稳定性，把支持应用做成了下发配置。配置是个 JSON 文件，放在 GitHub 静态网页上。上线约三周后我们才在关于页面放了一个 QQ 群，吸收热心用户进群获取反馈。事后证明这个群的作用很大。

差点放弃

我们迭代了一段时间，QQ 群也进来了一些用户。但是此时我们动摇了，犹豫是否继续做下去。原因是不确定这东西是否有价值，未来是否能够盈利。我们在 QQ 群里发起了一个投票，询问用户觉得我们的产品怎么样，是否希望我们继续开发。大约只有十个人投了票，但有点意外的是大部分用户觉得产品用处很大，要求继续开发。这给了我们很大的动力，我们决定继续做。现在看当时那些用户格外宽容，原因之一是产品当时完全免费。从实际角度讲，激励开发者的有两件事：一是产品有盈利，持续产生收入；二是虽然不盈利，但是有用户用，有用户叫好。

打通支付渠道

我们决定继续做。考虑到工具应用的特点，我们没有使用广告变现，而想走应用内付费这条路。付费就需要接入支付渠道。最常见的应用内微信支付、支付宝支付个人无法申请，需要有公司。国内主流市场都开始要求软件著作权，对上架某些分类的应用也要求公司资质。在第一版上线两个月后，我们拿到了公司营业执照。然后去银行开户，因为没经验中间浪费了一些时间，等到最后接入支付宝又过去了两个多月。在接入支付前靠捐赠和开通 QQ 群付费入群有了一点收入。先后接入支付宝、微信支付后便关闭了其他收费渠道。此时答题热度已经衰退。在调整了首充价格和做了一些优化之后，不再更新。一直到现在每月能产生约 200 元被动收入。

技术细节

这款产品的核心功能是在用户参与答题时，尽可能实时获取到题干和选项文本，调用搜索引擎，根据搜索结果推荐答案。早期我们使用系统 AccessibilityService 获取题干和选项。此方案的优点是速度快，缺点是需要单独适配每一款应用。适配工作量巨大而且应用升级后可能需要重新适配。并且两种情况下无法获取：一、答题界面是网页；二、开发者专门调用相关 API 禁用了辅助服务。随着时间的推移我们发现越来越多的应用开始禁用辅助服务。不得已我们变更了方案，改为使用系统 MediaProjection API 截屏然后调用 OCR 服务识别出文本。获取文本方案的调整伴随着交互的调整，使用流程变得比原来复杂。我们使用的百度文字识别服务，免费账户的 QPS 为 10。看着已经不低了，但是我们的使用场景存在天然的高并发——大部分答题活动在整点同时开始。即使很少的用户数仍然会超过额定 QPS，导致识别失败从而无法获得推荐答案。我们随后解决了这个问题。

后端使用阿里云，由一个 ECS 加 RDS 组成。ECS 上跑 Golang 写的应用程序，RDS 使用 MySql。最后迭代的结果，用户使用微信登录后，服务器下发百度密钥，端上调用百度 API 识别出文本后再调用搜索引擎接口。用户可以购买时长或者次数。时长好处理，次数需要设计一个能够容错的上报方案。这个方案要能够处理单次使用、本地缓存、上报失败重试、有失败请求待上报时用户又购买更多次数等情况。一个简单的与后端同步的原子计数器不能满足这些要求。最后的方案完美解决了上述问题并且足够简单。

思考

答题是 2018 年初的热点。热点的特征是来的快去的也快。下图是『答题』的百度搜索指数。

可以看到指数从 2018 年 1 月开始几乎直线攀升到最高峰近 4000 点，然后迅速回落。围绕热点快速推出产品抢占市场，获取大量流量并变现，是一种常见的商业套路，俗称『蹭热点』。蹭热点的产品，速度是第一位。我们的产品上线、迭代速度还算可以。但是因为没有注册过公司，等到接入支付，热度已消退，流量红利丧失殆尽。如果快速接入支付，收入估计至少翻倍，因为流量高一个数量级。

有很多开发者想做自己的产品，真正做出盈利产品的人少之又少。从在公司上班给公司做产品盈利，到自己做产品盈利，中间似乎隔着一条鸿沟。如何跨越？这中间作为开发者最需要补齐的是『用户思维』。从用户的角度去想问题。首先要让你的产品触达尽可能多的用户。差不多的实现原理，做一个命令行工具发布到 GitHub 上，和做一个应用发布到市场，前者只能触达开发者，后者触达的是所有智能手机用户。其次要想办法了解你的用户。我们的产品用户大多在三线以下城市，因为一二线城市的人太忙，没空参与答题。而且这些用户大部分并不熟悉互联网。前期没有服务器的时候，我们的应用需要用户自己注册百度账号才能使用 OCR。然后我们发现很多用户完成不了这个步骤。有些用户连注册百度要填的电子邮箱是什么都不知道，对这个东西没概念。此时我才深刻理解为什么微信默认不提供电子邮箱登录。作为国民级应用，门槛必须尽可能低，你会发短信就会用微信。要求邮箱就是把过亿用户拒之门外。