2023 ，0529-0604

五月结束了，收入整体在下降。

iOS 减少 18%
国内安卓减少 7.2%
Google Play 减少 20%
Admob 涨了 3%

除了 Admob ，其余的收入来源均是 2023 年目前的最低值，生意不好做啊～😭

唯一值得开心的是，整个五月里，国内安卓一笔退款都没有😎。

极简日记 iOS (App Store)

这周都在优化日记列表。

数据模型

先说一下这个 app 的 Core Data 模型，因为图片的加入和改动，一共经历了五个版本。

版本一

刚上线的时候只有文字，没有图片。

版本二

日记加入了单张图片，图片存放的位置是 iCloud 云盘中，通过一个新的属性：imageUrl 来存储文件位置，但是这么做有三个缺点：

加载图片慢，如果图片没有在本地的话，还需要从 iCloud 中先下载到本地才可以显示出来
用户可能会误删这些在 iCloud 云盘中的图片文件
需要开启 iCloud 云盘功能才可以保存这些图片

版本三

将图片作为一个属性保存到 Core Data 中，对应的新属性是一个 Binary Data：imageData 。

这么做完美地解决了版本二中的问题，唯一的麻烦就是需要将原来的旧图片导入到 Core Data 中。

版本四

日记加入了多张图片（最多九张），又新建了一个 Binary Data 属性：images ，用来保存图片数组的二进制。

至此，极简日记在图文展示上达到了最终形态，至少是我认为的。

优化之路

但是很快就有用户反馈，有些同一标签下的日记列表，一点击进入就会崩溃，原因就是图片太多太大，内存爆了。

其实我也预料到这种情况随着用户日记数量的增多迟早会发生，只是没想到这么快，于是针对这种情况，做了两次优化。

优化一

日记列表采用分页，每一页 20 个，滑动到底部会出现一个手动的「加载更多」按钮。但是这样最终还是会崩溃，因为加载到内存里的数据还是会越来越多。

优化二

在分页的基础上，加入了一个内存预警功能。这个功能的原理就是，先计算出目前 20 条数据的平均所占内存和剩余内存，如果剩余内存少于 20 条数据的内存，那么下次加载就有可能会崩溃，这样下次加载前先释放掉顶部的 20 条数据。如果用户向上滑动到了顶部，会出现一个「下拉加载之前数据」的提示，下拉后会加载之前的 20 条，同时释放底部的 20 条。

这么做其实就是在分页的基础上还加入了类似于数据库查询的 offset ，目前来看效果还是可以的，没有再碰到这方面崩溃的反馈。但是这个方法还是有几个缺点：

内存计算不准确
需要维护 offset ，还多出了一个下拉的操作
在加载和释放数据的时候，列表会出现错位的动画

优化三

有些图片比较多的日记在加载的时候会卡住 UI ，针对这方面我做了两处优化，一个正优化，另一个在现在看来是负优化了。正优化是减小图片体积，在加载的时候处理成缩略图。而处理缩略图又增加了加载日记的时间，于是我就把加载日记数据都改成了异步加载，这也是我第一次使用 Swift 的 async/await 。因为改动的是涉及到所有页面的底层数据，所以牵一发而动全身，几乎将整个项目关于日记数据的部分都重构了一遍。然而这么做除了增加代码复杂度，并没有什么明显的性能上的提升，这也为后来的优化工作埋下无数深坑。