在工作和散步时，我经常听背景音乐。 我曾经使用称为Jango的网络广播，该广播几乎适用于所有人，但以下方面除外：
- 几乎每天在森林中散步时都无法访问（即没有Internet连接）。
- 需要在不同的频道之间切换以改变音乐的流派。 换句话说，Jango的听众几乎没有机会发现新的音乐流派。
有一天，这个想法提出了一种用于听音乐的移动应用程序，该程序在大多数情况下都可以在没有Internet（即缓存音乐）的情况下自动检测用户的音乐成瘾情况。 我还没有看到这样的东西（也许我看上去很糟？），所以我决定自己实现它。 现在，在闲暇时间进行了几个月的编码之后，我发布了第一个，虽然还很原始，但是已经可以使用的Android应用程序版本。
我想用一个非常简单直观的界面（实际上只有两个按钮：“暂停”和“跳过”）来实现一个应用程序，但是要使用足够先进的内部逻辑来分析音乐喜好（基于收集有关跳过之前收听曲目持续时间的统计信息）和缓存轨道。 由于我不想为不同的平台复制逻辑，因此决定以C ++（对于iOS和Android是“共同点”）实现它。
为了存储有关曲目的元数据以及用户首选项，我选择了SQLite。 专辑和音乐封面文件存储在基于哈希的三级目录树中（类似于它在Git中的工作方式）。
512 MiB选择了缓存大小（当然，可以配置这些和其他任何数字）。 轨道旋转的逻辑如下：每次更新迭代下载20条轨道。 用户至少听了两次曲目之后，将启动新的更新。 删除平均收听时间低于指定限制的曲目，并从服务器下载新曲目的元数据，然后开始下载。
播放逻辑如下。 曲目的平均收听时间越长，播放的频率就越高。
作为一名经验丰富的C ++开发人员，我在实现上述逻辑时没有遇到任何特殊的困难（尽管实际上它有些复杂）。 但是，由于没有为Android编写应用程序的经验，我不得不花费大量时间和精力来实现适当的软件层（尤其是UI）。 我敢肯定，现在很多事情都没有以最佳方式实施。
我决定在Kotlin中编写一个Android包装器。 实际上，Java没有任何优势，因为您仍然必须弄乱JNI（在iOS中，情况会有所不同，在与本机核心逻辑代码集成方面，Objective-C比Swift方便得多）。
我使用Fuel来下载JSON元数据，并使用Fetch来下载文件（令我惊讶的是Fuel无法有效地下载文件）。 顺便说一下，对于第二个图书馆，我抱怨工作的稳定性。
服务器代码是用Golang编写的，并通过改革使用了PostgreSQL。 当前的元数据数据库是通过索引Free Music Archive建立的 ，将来我还计划索引其他开放源代码。 服务器上的轨道尚未存储以节省空间（我在主机上保存），但直接引用了源存储库。
服务器收集每个用户收听曲目的统计信息。 因此，为每种音乐类型分配了一个偏好分数，该分数会影响旋转过程中选择合适乐曲的可能性。
如果您尝试我的申请，我将很高兴。 突然，您会喜欢它。 当然在使用过程中，您会遇到错误（程序仍然是原始的）。 他们改正的速度将直接取决于我的工作需求。