个人从零开发一款 Android 应用、上线并盈利 | 项目复盘

2021-03-20 本文已影响0人开发者如是说

未标题-1.png

最近个人开发的一款应用言叶刚刚发布了 1.4.0，至此，我想要开发的大部分功能已经完成了。本来我也想做一次复盘，刚好趁这个机会分析下并发出来。在这篇文章中，我想分析的并不仅仅是技术，除此此外，我也会分析下这个产品、开发过程中有哪些做得好和不好的地方以及接下来的打算。

1、项目背景

这个应用是一款笔记应用。其实，一开始要做它，我也是拒绝的。

因为我觉得这类应用门槛和天花板都比较低，同类和类似的应用都比较多，花费功夫做一个收益也不会太大。后来打算做是出于几个原因：

第一，我大概写了三周的电商爬虫并部署到三台服务器上，Python 写得有点吐，想换个心情写写 Kotlin；
第二，对于很多互联网项目，在项目初期是很难盈利的，而达到收支平衡更需要一定的时间，所以我就想开发一款应用赚点“快钱”；
第三，我前些时间又翻了翻周鸿祎的互联网方法论，其中有说到，如果一个项目能够解决几个用户痛点就值得做，我深以为然，于是就设计并开发了这个应用。

这个应用所解决的用户痛点是，跨平台写作的问题。的确，有很多笔记应用是可以跨平台的，但是这类笔记一般收费比较高而且对开发者来说回报也不高，比如印象笔记、有道笔记等。这类应用存在一个问题，他们的文件格式基本是自己定义的，因此就不容易做到通用。而如果我使用 Markdown 语法以文件目录形式管理笔记，使用相对目录在笔记内部进行文件引用，同时提供云同步来实现多端协作。那么我就可以做到：

首先，解决了用户多端写作的问题，毕竟移动端编辑不方便，我们可以在编辑完成之后将笔记同步到手机上，进行阅读、校对或者继续编辑等。
其次，通过内容和管理方式的规范，我就没必要编写其他平台（比如 PC 或者 iOS）的客户端了。毕竟术业有专攻，就算我开发一个其他平台的应用，不熟悉环境不说，用户体验也不见得比现有的好。
最后，用户可以通过 WebDAV 或者其他手段进行数据同步，那么我就没必要自己搭建服务器存储用户的笔记数据了。

基于以上几点以及之前的技术沉淀，我估摸着就算开发一个也不会花费太长的时间。最后，从设计、开发（客户端+服务器）用了大概一个多月的时间。不过，随后我发现随着自己想做的事情越来越多，就又投入了几个月进去。当然，这个应用一上线就有用户购买的，这有几个原因：

第一当然是应用本身的设计。因为之前我也开发过一款类似的开源应用，对用户的需求以及同类的产品比较熟悉，那么，在他们之上结合我自己的 UI 设计理念和对用户痛点的把握，不论应用性能还是外观做得都不错。
其次，购买我的产品的用户大多来自于某平台，这个平台具备一定的社交属性，而我有不多的关注，这使得我的产品一上线就有受到一定的关注。这也说明，通过粉丝或者其他途径（做自媒体等），维护一个个人的品牌对开发者或者创业者来说好处是非常多的。

2、实践经验

因为项目本身是个人开发，所以我负责了从 UI 设计到产品到客户端到后端以及部分网页的所有工作。

2.1 UI 设计

对于应用的 UI 设计，因为这次开发写得非常顺，所以所有的 UI 都是打腹稿完成的。当然，也会借助手绘来梳理 UI 和业务逻辑，有时候也会直接使用产品原型工具，比如 Axure，直接绘制产品原型。使用产品原型工具好处是，可以直接预览设计效果，不好的地方是，因为本身只是个人开发，产品原型更多的是设计和开发之间交流的工具，省略了这个步骤可以减轻开发的难度。

对于图标、应用内部的图片选择则是我通过其他网站精心挑选的。这并不容易，尤其是你对应用细节有要求的时候。下面是我常用的一些免费网站，

Icons8：免费，用来获取应用内各种图标，这个网站对图标的设计风格都有所区分
Unsplash：免费，可以用来下载免费的壁纸和应用内部的图片等
Dribbble：设计师常逛的网站，可以用来捕捉一些设计灵感
以及两个用来下载 PNG 图片的网站：pngtree 和 cleanpng，这两个国外的网站，还是很良心的，可以免费下载，使用 PNG 之后我们只需要通过组合就可以设计出好的应用宣传图了

关于应用的 UI 设计的一些总结：

图标风格要统一，比如如果用 Material Design 风格，那么应该全部统一成 Material Design 风格；如果 Material Design2 风格，就应该全部统一成 Material Design2 风格的图标。对于图标的设计风格，Icons8 网站里都会有对应的区分，自己选择下载即可。
对于应用的宣传图，我目前上架的所有的市场都要求尺寸为 1080*1920，所以按照这个尺寸设计即可。另外，个别商店要求如果宣传图里面有手机外壳，要用自家的手机，所以设计的时候不加外壳就可以了。
其他的还有一些，一时想不起来了，以后慢慢补充吧。

2.2 客户端

1. 开发工作

客户端部分主要包含客户端业务逻辑开发、客户端底层加密以及笔记浏览器样式定制几个部分的工作。

对于客户端业务逻辑，使用 Kotlin 开发即可。因为我经常开发自己的应用，为了避免经常 Copy 各个模块，所以开源了很多的框架。也是借助于这些框架，才使得我能够快速开发并上线一个应用。经过这个项目以及其他项目的迭代，我逐渐将一些具备通用性的设计沉淀到了底层的库中，也使得这些库能够不断开发完善。对于客户端部分，我之前很多文章介绍过这些库以及如何提升开发效率的方法了，这里不多说了，感兴趣的看之前的文章即可。

对于底层加密部分，主要使用 C++ 在加固之上继续做应用的加密、用户购买和会员信息加密以及与服务器通信加密等。之前我有一款应用，加固，上线，之后被别人破解。然后，我自己根据逆向的结果增加了一层安全措施。这个我之前也分析过，这里不多写了。当然，之前的文章里面也会有所保留，毕竟写出来了就相当于把自己的安全方案说出来了。对于应用与后端通信加密，这个容易理解，就是说，通信的时候通过客户端和后端的约定规则，如果客户端的参数不符合这个规则，后端就拒绝处理。为了安全性考虑，这部分逻辑当然最好通过 native 的 C++ 来完成。

而对于笔记浏览器配置，因为我使用 WebView 展示解析后的 Markdown 结果，因此客户端部分要做些 CSS 和 JavaScript 完成对笔记浏览器样式的定制。这里目前用到的还只是比较基础的 JS 和 CSS 知识，以为了增加更多的 features 可能会增加更多的功能。

之前的相关的文章链接如下。因为之前写得比较多了，这里就不啰嗦了：

2. 其他的

这里稍微介绍下客户端开发之外的工作——用户统计。我在应用内部用户信息统计和埋点使用的是友盟的 SDK. 之前我更多用 Twitter 的 Fabric. 不过后来被整合到 Google 的 Firebase 之后就没有再用过。友盟是免费的，不过确实存在一些问题：

有时候崩溃上报不上来，为此我当时甚至一度开始考虑自己设计崩溃日志上传的系统。
用户新增统计也不完全准确，跟我后台统计存在偏差。

不过整体而言友盟还是值得一用的，它还是可以大致描绘用户信息，这便于以后做用户画像，并根据统计信息进一步优化自己的应用。

如果你打算开发一款自己的应用的话，我觉得信息统计和用户行为埋点还是值得一提的，因为一个产品的成功不仅仅是把产品开发和上线就为止了的，很多时候一个产品的成功取决于运营的工作。

此外，这个应用还用到了我的多语言翻译等各种工具。也可以这么说吧，按照我的习惯，一个工作重复三次以上就应该考虑使用工具来优化了，毕竟我们是程序员，程序员怎么能做程序的工作呢？

2.3 后端开发

后端的工作包括通用服务器开发和服务器运维两个部分。

1. 服务器开发

为什么开发这个通用服务器呢？因为当时我手上还有三台服务器，两台中等配置的，一台期限比较长，另一台是为另一个项目准备的，还有一台是新用户服务器。所以，为了充分利用这台期限较长的应用，我准备开发一台通用服务器，即为我现在已经将来要开发的应用提供基础服务。比如用户反馈收集、应用配置定义和个性化的下发、设备管理、用户管理、图床以及将来也可以考虑集成一些有趣的功能进来等等。

当然，在开发这个应用之前我也是做了技术调研的。因为我之前就有计划开发几个应用，将来还可能开发更多。毕竟，有技术，有想法，看到一些好玩的东西，总是手痒，按捺不住要做一个的冲动。所以，当时微服务架构比较火，我对此也做了调研。不过，最终我没用采用微服务，而是设计成单体的应用。因为，显然的，架构的设计不仅和要做的事情相关，跟自己当时的实际情况也相关的，当然还要考虑将来的拓展。而以我目前的形状而言，我只有一个人开发，因此采用微服务和管理微服务都会增加成本。另外，对于微服务的部署问题，我当然不会购买更多的服务器来支持微服务。而所谓的微服务还是单体，无非就是看你从哪个维度来进行划分：

          功能 1      功能 2      功能 3
应用 1  ----+-----------+-----------+------------->
应用 2  ----+-----------+-----------+------------->
应用 3  ----+-----------+-----------+------------->

如上所示，简单理解：如果你从功能模块角度划分，这就是微服务；如果你从应用的角度划分，这就是一个个单体。不过我是将所有的应用通过一个单体维护的，这还是跟当前实际情况相关：新用户的用户量不大，没必要各自单独开发一个应用，并且个人维护多个应用和服务器成本比较高，而假如某一天某个应用用户数量增多，这当然是一种幸福的烦恼，此时可以将数据迁移出来单独开发和优化。

后端开发相关的文章我之前也写过，自己看往期的文章就好了：

当时因为要支持国际化，所以为了做系统设计还是花费了些功夫，要导致工期稍微长了一些。我个人觉得这个服务器设计还是很妙的，比如可以给指定的用户发送消息，虽然不是即时消息，但这便于将一些信息传递给用户，将来也可以借助它设计运营和推广活动。以后做用户增长的话，我也可以在这个服务器上面做些工作，来辅助进行用户画像。

2. 服务器运维

既然搭建一个服务器，那么服务器安全问题自然是不容忽视的。对于服务器，一方面要通过各种配置增加服务器的安全性，这包括修改各种常用端口，修改 rm 指令等。此外，还需要使用 cron 任务做 MySQL 和 Redis 数据库的定时备份等等。

这方面好在我之前搭建服务器的时候就整理了很多的笔记，所以，才能够做到每次搭建服务器的时候能够快速完成：

QQ截图20210320160014.png

2.3 产品

虽然我工作是程序员吧，但我对产品的兴趣不亚于代码。最初我选择这个行业也是希望有一天能够做出来自己的产品。当初刚毕业的时候还阴差阳错地差点做了产品……不过，我希望自己开发自己的产品，至少目前是这样（出于成本、风险和兴趣的考量）。

做产品没那么容易，我一直觉得，一般的产品经理关注的是产品本身，高级的产品经理关注的是市场。如果你对产品感兴趣的话下面这些书可以帮到你：

《俞军产品方法论》：俞军作品，没必要多说了，大神级作品，眼界很高
《幕后产品：打造突破式产品思维》，作者王诗沐，网易云音乐背后核心人物

另外还有《增长黑客实战笔记》、《一个广告人的自白》和《文案训练手册》啥的，杂七杂八，之前看了很多，但主要分为个方向：产品、运营和市场。

3、总结

好吧，洋洋洒洒地写了很多的东西，一篇文章很难面面俱到，但是梳理一下总归有一些收获，以后也应该多进行复盘，形成自己的方法论。下面说我觉得做得好和不好的地方以及接下来的打算。

3.1 好的地方

首先，在技术上，

不论客户端还是后端能够逐渐沉淀出自己的框架，这将大大降低后续开发的成本；
此外，能够通过工具化，比如 Python 翻译工具、自动生成代码等，减轻开发的压力；
能够通过开发的记录和日志输出文档，为以后开发做铺垫。

在产品上，产品的 UI 设计不错 & 能够抓住用户的一两个痛点

3.2 不好的地方

仍然需要一个团队，目前仍是孤掌难鸣的境地，假如可以各司其职，做自己擅长的领域，效果会好得多。当然，这个是不强求的，因为就目前的产品而言，上限不高。另外，我目前也没有找到好的方向。
就笔记产品而言，天花板低、门槛低、上手易、竞品多 -> 行业赛道不好。
产品 LOGO 设计不够国际化（带中文），产品定价策略可能存在问题 -> 产品调研做得不够。
追求完美的拖延症，特别强调做事的先后顺序，结果导致事情一拖再拖 -> 前期调研做充分，过程中应该增强执行力。

3.3 接下来 ...

就这个产品而言，

尝试做产品推广，结合短视频等做下尝试，看看效果，了解短视频行业。
利用友盟后台统计结果，搭配自己的服务器做些配置，参考增长黑客的做法，将理论落实到通用服务器上面，做用户画像，分析，并尝试做用户增长，搭建运营系统。
搭建服务器后台管理系统（现在仍然在使用 Python 脚本和直接操作数据库的方式变更各种配置）以充分利用服务器的能力。

就个人技术提升而言，

其他技术领域的拓展。单就整个前端而言，前端、小程序、客户端，很难说哪个更好，也不存在一个替代另一个，各有各的应用场景。我们做产品的时候当然要根据产品的性质选择对应的一端。但不可否认的是，小程序让产品多了一个选择，间接让客户端失去了部分市场。如果希望自己的职业生涯之树常青，只做客户端显然是不够的。
应该对产品、运营（文案、推广、增长等）两块的内容做一次梳理并逐渐形成自己的方法论。

就大环境而言，

就目前情况来看，已经到了互联网红利的末期，这当然不是说没有机会，但我觉得像目前这样浅尝辄止肯定是不行的。白岩松有句话说，三十岁之前要努力做加法，多尝试；三十岁之后做减法，聚焦。所以，我觉得接下来应该多尝试和了解不同行业，然后选择一个自己感兴趣并且前景好的行业持续积累，这样才能形成自己的竞争优势。

现在的确不是自己做事情的好时候，但如果换一个角度思考，正因为很多人抱着这种看法，所以这个时候竞争压力反而小得多，反而适合好好打磨自己的产品。当然，如果成本太高的话就算了，因为现在经济大环境确实不好，以后往左还是往右走还分不清~

每个人身份和背景不同，看问题的角度可能不一样，也应该多认识一些人，交换想法，这样双方都有收获。所以，总结下来：多走，多看，多思考，多尝试，多认识一些人。