前两个月做了一个项目，彩票玩家，但是因为政策问题，无法上架。那就从技术的角度来聊一下这个产品。彩票玩家的规划是一个可以查看开奖信息，可以管理自己想要的彩票号码，可以查看历史开奖信息的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 了，其实也还好，够用，毕竟已经死透了，即使没有死透，前期也够用。
然而
项目虽然死透了，但是服务器方面学习到的东西，也用在下一个项目上。这个项目在做的时候也考虑过可能上不了架，但是没有想太多，就直接做了，客户端部分投入的时间和精力基本上算是浪费了，服务器方面的积累是有用的。