最近个人开发的一款应用 言叶 刚刚发布了 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 可能会增加更多的功能。
之前的相关的文章链接如下。因为之前写得比较多了,这里就不啰嗦了:
- 拥抱新的交互方式,在 Android 中应用 MVVM
- 个人开源库的一些更新,兼谈Jetpack和Kotlin给Android开发带来的变化
- 2020 年,我这样在项目中使用 MVVM
- 加固了就安全了?几个措施让你的 Android 应用更安全
2. 其他的
这里稍微介绍下客户端开发之外的工作——用户统计。我在应用内部用户信息统计和埋点使用的是友盟的 SDK. 之前我更多用 Twitter 的 Fabric. 不过后来被整合到 Google 的 Firebase 之后就没有再用过。友盟是免费的,不过确实存在一些问题:
- 有时候崩溃上报不上来,为此我当时甚至一度开始考虑自己设计崩溃日志上传的系统。
- 用户新增统计也不完全准确,跟我后台统计存在偏差。
不过整体而言友盟还是值得一用的,它还是可以大致描绘用户信息,这便于以后做用户画像,并根据统计信息进一步优化自己的应用。
如果你打算开发一款自己的应用的话,我觉得信息统计和用户行为埋点还是值得一提的,因为一个产品的成功不仅仅是把产品开发和上线就为止了的,很多时候一个产品的成功取决于运营的工作。
此外,这个应用还用到了我的多语言翻译等各种工具。也可以这么说吧,按照我的习惯,一个工作重复三次以上就应该考虑使用工具来优化了,毕竟我们是程序员,程序员怎么能做程序的工作呢?
2.3 后端开发
后端的工作包括通用服务器开发和服务器运维两个部分。
1. 服务器开发
为什么开发这个通用服务器呢?因为当时我手上还有三台服务器,两台中等配置的,一台期限比较长,另一台是为另一个项目准备的,还有一台是新用户服务器。所以,为了充分利用这台期限较长的应用,我准备开发一台通用服务器,即为我现在已经将来要开发的应用提供基础服务。比如用户反馈收集、应用配置定义和个性化的下发、设备管理、用户管理、图床以及将来也可以考虑集成一些有趣的功能进来等等。
当然,在开发这个应用之前我也是做了技术调研的。因为我之前就有计划开发几个应用,将来还可能开发更多。毕竟,有技术,有想法,看到一些好玩的东西,总是手痒,按捺不住要做一个的冲动。所以,当时微服务架构比较火,我对此也做了调研。不过,最终我没用采用微服务,而是设计成单体的应用。因为,显然的,架构的设计不仅和要做的事情相关,跟自己当时的实际情况也相关的,当然还要考虑将来的拓展。而以我目前的形状而言,我只有一个人开发,因此采用微服务和管理微服务都会增加成本。另外,对于微服务的部署问题,我当然不会购买更多的服务器来支持微服务。而所谓的微服务还是单体,无非就是看你从哪个维度来进行划分:
功能 1 功能 2 功能 3
应用 1 ----+-----------+-----------+------------->
应用 2 ----+-----------+-----------+------------->
应用 3 ----+-----------+-----------+------------->
如上所示,简单理解:如果你从功能模块角度划分,这就是微服务;如果你从应用的角度划分,这就是一个个单体。不过我是将所有的应用通过一个单体维护的,这还是跟当前实际情况相关:新用户的用户量不大,没必要各自单独开发一个应用,并且个人维护多个应用和服务器成本比较高,而假如某一天某个应用用户数量增多,这当然是一种幸福的烦恼,此时可以将数据迁移出来单独开发和优化。
后端开发相关的文章我之前也写过,自己看往期的文章就好了:
- 从零搭建基于 Java 的服务器生产环境
- 为你的应用集成谷歌结算(客户端集成+服务端校验)
当时因为要支持国际化,所以为了做系统设计还是花费了些功夫,要导致工期稍微长了一些。我个人觉得这个服务器设计还是很妙的,比如可以给指定的用户发送消息,虽然不是即时消息,但这便于将一些信息传递给用户,将来也可以借助它设计运营和推广活动。以后做用户增长的话,我也可以在这个服务器上面做些工作,来辅助进行用户画像。
2. 服务器运维
既然搭建一个服务器,那么服务器安全问题自然是不容忽视的。对于服务器,一方面要通过各种配置增加服务器的安全性,这包括修改各种常用端口,修改 rm 指令等。此外,还需要使用 cron 任务做 MySQL 和 Redis 数据库的定时备份等等。
这方面好在我之前搭建服务器的时候就整理了很多的笔记,所以,才能够做到每次搭建服务器的时候能够快速完成:
2.3 产品
虽然我工作是程序员吧,但我对产品的兴趣不亚于代码。最初我选择这个行业也是希望有一天能够做出来自己的产品。当初刚毕业的时候还阴差阳错地差点做了产品……不过,我希望自己开发自己的产品,至少目前是这样(出于成本、风险和兴趣的考量)。
做产品没那么容易,我一直觉得,一般的产品经理关注的是产品本身,高级的产品经理关注的是市场。如果你对产品感兴趣的话下面这些书可以帮到你:
- 《俞军产品方法论》:俞军作品,没必要多说了,大神级作品,眼界很高
- 《幕后产品:打造突破式产品思维》,作者王诗沐,网易云音乐背后核心人物
另外还有《增长黑客实战笔记》、《一个广告人的自白》和《文案训练手册》啥的,杂七杂八,之前看了很多,但主要分为个方向:产品、运营和市场。
3、总结
好吧,洋洋洒洒地写了很多的东西,一篇文章很难面面俱到,但是梳理一下总归有一些收获,以后也应该多进行复盘,形成自己的方法论。下面说我觉得做得好和不好的地方以及接下来的打算。
3.1 好的地方
首先,在技术上,
- 不论客户端还是后端能够逐渐沉淀出自己的框架,这将大大降低后续开发的成本;
- 此外,能够通过工具化,比如 Python 翻译工具、自动生成代码等,减轻开发的压力;
- 能够通过开发的记录和日志输出文档,为以后开发做铺垫。
在产品上,产品的 UI 设计不错 & 能够抓住用户的一两个痛点
3.2 不好的地方
- 仍然需要一个团队,目前仍是孤掌难鸣的境地,假如可以各司其职,做自己擅长的领域,效果会好得多。当然,这个是不强求的,因为就目前的产品而言,上限不高。另外,我目前也没有找到好的方向。
- 就笔记产品而言,天花板低、门槛低、上手易、竞品多 -> 行业赛道不好。
- 产品 LOGO 设计不够国际化(带中文),产品定价策略可能存在问题 -> 产品调研做得不够。
- 追求完美的拖延症,特别强调做事的先后顺序,结果导致事情一拖再拖 -> 前期调研做充分,过程中应该增强执行力。
3.3 接下来 …
就这个产品而言,
- 尝试做产品推广,结合短视频等做下尝试,看看效果,了解短视频行业。
- 利用友盟后台统计结果,搭配自己的服务器做些配置,参考增长黑客的做法,将理论落实到通用服务器上面,做用户画像,分析,并尝试做用户增长,搭建运营系统。
- 搭建服务器后台管理系统(现在仍然在使用 Python 脚本和直接操作数据库的方式变更各种配置)以充分利用服务器的能力。
就个人技术提升而言,
- 其他技术领域的拓展。单就整个前端而言,前端、小程序、客户端,很难说哪个更好,也不存在一个替代另一个,各有各的应用场景。我们做产品的时候当然要根据产品的性质选择对应的一端。但不可否认的是,小程序让产品多了一个选择,间接让客户端失去了部分市场。如果希望自己的职业生涯之树常青,只做客户端显然是不够的。
- 应该对产品、运营(文案、推广、增长等)两块的内容做一次梳理并逐渐形成自己的方法论。
就大环境而言,
就目前情况来看,已经到了互联网红利的末期,这当然不是说没有机会,但我觉得像目前这样浅尝辄止肯定是不行的。白岩松有句话说,三十岁之前要努力做加法,多尝试;三十岁之后做减法,聚焦。所以,我觉得接下来应该多尝试和了解不同行业,然后选择一个自己感兴趣并且前景好的行业持续积累,这样才能形成自己的竞争优势。
现在的确不是自己做事情的好时候,但如果换一个角度思考,正因为很多人抱着这种看法,所以这个时候竞争压力反而小得多,反而适合好好打磨自己的产品。当然,如果成本太高的话就算了,因为现在经济大环境确实不好,以后往左还是往右走还分不清~
每个人身份和背景不同,看问题的角度可能不一样,也应该多认识一些人,交换想法,这样双方都有收获。所以,总结下来:多走,多看,多思考,多尝试,多认识一些人。
文章来源于互联网:个人从零开发一款 Android 应用、上线并盈利 | 项目复盘