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。因为改动的是涉及到所有页面的底层数据，所以牵一发而动全身，几乎将整个项目关于日记数据的部分都重构了一遍。然而这么做除了增加代码复杂度，并没有什么明显的性能上的提升，这也为后来的优化工作埋下无数深坑。
终极优化
之前的优化过程中也得到过肘子哥的帮助，后来在肘子哥的 Discord 中也有其他开发者讨论和我一样的问题，于是肘子哥专门写了一篇文章《SwiftUI + Core Data App 的内存占用优化之旅》给出了一个终极的解决方案。
版本五 + 优化四
这周我的全部工作就是基于这篇文章来对 app 进行优化。
首先是将图片从日记中独立出来，单独放到一个与日记关联的 Entity 里面。数据模型的再次改变，导致接下来就又需要把之前所有关于图片的代码重写一遍，顺便将之前的异步留下的问题都解决。目前数据的 CRUD 都跑通了，内存问题也有了很大改善。
因为未来可能加入音频和视频，所以这次针对图片单独新建的 Entity，特意添加了几个通用的属性，希望未来不再改动 Entity。
618 大促
这一年，我的 App 也凑个热闹，首次进行优惠促销。
- 极简时钟 Android 版，pro 价格 18 元 ➡️ 12 元
- 极简日记 iOS 版，终身 Pro 价格 98 元 ➡️ 68 元
促销价格从 6 月 1 日持续到 6 月 18 日 23:59。
下周我分享一下这个 618 我都买了什么。
引用链接：
《SwiftUI + Core Data App 的内存占用优化之旅》，https://www.fatbobman.com/posts/memory-usage-optimization/