我做了一个无法上架的彩票App

前两个月做了一个项目,彩票玩家,但是因为政策问题,无法上架。那就从技术的角度来聊一下这个产品。彩票玩家的规划是一个可以查看开奖信息,可以管理自己想要的彩票号码,可以查看历史开奖信息的App。

这个项目目前的状态是,只上架了 Google Play,但这和没有上架区别不大。

AppStore审核通不过,第一次拒绝原因是关于数据版权问题。修改Apple Store Connect产品信息页的一些配置,改了一点Bug,又提交了一次,还是被拒绝,但这次似乎不是因为产品了,收到苹果的删号警告,说违反了苹果的开发者协议,也不知道为什么,然后提交了申诉,现在也还没有收到答复。

软件著作权的申请被要求提交彩票中心授权或合作开发的文件,无解。目前关于上架相关的情况就是这样,从产品的角度出发,死透。

接下来就只能聊一下技术实现方面。

客户端

客户端这一块,还是用Unity做的。至于为什么不用原生,主要因为是我不会。其次,用Unity实现,也并没有什么不妥(对于这个App来说)。无论从开发效率,还是跨平台,还是产品的表现效果,都还不错。再加上之前的能用模块代码的积累,对于我来说使用 Unity 开发这个 App 是最优的选择。我觉得从产品的角度出发,一个产品到达用户手中,只要各方面好用,那用什么技术做出来的,对于用户来说就不是那么重要了。

客户端有一个更新模块,启动后会拉取版本配置信息,对比版本号,如果远程配置的版本号比较大,就会弹出强制或非强制更新弹窗,点击更新后会跳转到AppStore。是的,这个模块只对iOS有效。对于国内Android来说,由于没有统一的市场,因为成本问题我也不想购买第三方存储服务,所以就直接在Android上关掉了这个功能。

产品本身已经内置了彩票的大部分开奖数据,从上架那天之前的。由于彩票的开奖时间基本上是固定的,所以客户端会有一个协程,每隔1分钟判断系统时间是否大于配置的开奖时间,如果大于,并且当前缺少本期的开奖数据,就会向服务器请求。这样做,对于服务器的压力也比较小。

客户端向服务器的请求内容,使用了 aes 加密,一定程度上防止了请求内容被破解。

广告方面,使用了 Unity 的广告,经过测试,现在的填充还可以。

推送方面,Android 没有加,因为太麻烦了,国内Android手机各个厂商都不统一,Google的firebase在国内又用不了。国内有第三方的推送服务,要收费,也不太想用。iOS版本使用了OneSignal插件,当然也需要在他们后台配置苹果的证书相关的东西。

对于界面的设计,谈不上什么设计。就是找其他看起来设计不错的App,进行参考,很少有某个App的设计是可以完全拿来抄的,基本只能从形上参考一下,然后多找几个综合来考虑。先把布局确定好,然后颜色上因为是App,也不用太多的色彩。

产品的具体逻辑就没什么好说的了,对于Unity来说就是UI的管理,以及UI的搭建。

服务器

服务器方面,使用了 Rust 来写的,终于把 Rust 用在了项目上。即使写的很烂,但是能跑,能满足需求,目前来说足够了。

服务器主要就是两方面,一个是官网获取开奖数据,然后存入数据库。另一方面就是处理客户端的数据请求。从官网获取开奖数据使用了 reqwest。处理客户端请求使用了 actix-web。

数据库方面使用了 diesel 和 PostgreSQL,这一块也折腾了好久,基本上现学现用。因为能满足最开始的需求,就没有上 Redis。

客户端和服务器之间通信的请求数据使用了 aes 加密,服务器收到请求后,会先解密请求内容,如果解密不了,就直接抛弃。经过压力测试,在不加密的情况下,我那一年108块的垃圾服务器可以处理 70 req/s,但是加上加密,就只能处理 40 req/s 了,其实也还好,够用,毕竟已经死透了,即使没有死透,前期也够用。

然而

项目虽然死透了,但是服务器方面学习到的东西,也用在下一个项目上。这个项目在做的时候也考虑过可能上不了架,但是没有想太多,就直接做了,客户端部分投入的时间和精力基本上算是浪费了,服务器方面的积累是有用的。

Author: Moeif Studio

Permalink: http://blog.moeif.com/2021/07/11/unlisted-lottery-project/

任何技术问题,可加微信交流,微信: ifloop

搜索并关注微信公众号 [ 萌一小栈 ] 可及时订阅最新技术文章

Comments