五月结束了，收入整体在下降。
除了 Admob ，其余的收入来源均是 2023 年目前的最低值，生意不好做啊～😭
唯一值得开心的是，整个五月里，国内安卓一笔退款都没有😎。
这周都在优化日记列表。
先说一下这个 app 的 Core Data 模型，因为图片的加入和改动，一共经历了五个版本。
刚上线的时候只有文字，没有图片。
日记加入了单张图片，图片存放的位置是 iCloud 云盘中，通过一个新的属性：imageUrl 来存储文件位置，但是这么做有三个缺点：
将图片作为一个属性保存到 Core Data 中，对应的新属性是一个 Binary Data：imageData 。
这么做完美地解决了版本二中的问题，唯一的麻烦就是需要将原来的旧图片导入到 Core Data 中。
日记加入了多张图片（最多九张），又新建了一个 Binary Data 属性：images ，用来保存图片数组的二进制。
至此，极简日记在图文展示上达到了最终形态，至少是我认为的。
但是很快就有用户反馈，有些同一标签下的日记列表，一点击进入就会崩溃，原因就是图片太多太大，内存爆了。
其实我也预料到这种情况随着用户日记数量的增多迟早会发生，只是没想到这么快，于是针对这种情况，做了两次优化。
日记列表采用分页，每一页 20 个，滑动到底部会出现一个手动的「加载更多」按钮。但是这样最终还是会崩溃，因为加载到内存里的数据还是会越来越多。
在分页的基础上，加入了一个内存预警功能。这个功能的原理就是，先计算出目前 20 条数据的平均所占内存和剩余内存，如果剩余内存少于 20 条数据的内存，那么下次加载就有可能会崩溃，这样下次加载前先释放掉顶部的 20 条数据。如果用户向上滑动到了顶部，会出现一个「下拉加载之前数据」的提示，下拉后会加载之前的 20 条，同时释放底部的 20 条。
这么做其实就是在分页的基础上还加入了类似于数据库查询的 offset ，目前来看效果还是可以的，没有再碰到这方面崩溃的反馈。但是这个方法还是有几个缺点：
有些图片比较多的日记在加载的时候会卡住 UI ，针对这方面我做了两处优化，一个正优化，另一个在现在看来是负优化了。正优化是减小图片体积，在加载的时候处理成缩略图。而处理缩略图又增加了加载日记的时间，于是我就把加载日记数据都改成了异步加载，这也是我第一次使用 Swift 的 async/await 。因为改动的是涉及到所有页面的底层数据，所以牵一发而动全身，几乎将整个项目关于日记数据的部分都重构了一遍。然而这么做除了增加代码复杂度，并没有什么明显的性能上的提升，这也为后来的优化工作埋下无数深坑。
之前的优化过程中也得到过肘子哥的帮助，后来在肘子哥的 Discord 中也有其他开发者讨论和我一样的问题，于是肘子哥专门写了一篇文章《 SwiftUI + Core Data App 的内存占用优化之旅》给出了一个终极的解决方案。
这周我的全部工作就是基于这篇文章来对 app 进行优化。
首先是将图片从日记中独立出来，单独放到一个与日记关联的 Entity 里面。数据模型的再次改变，导致接下来就又需要把之前所有关于图片的代码重写一遍，顺便将之前的异步留下的问题都解决。目前数据的 CRUD 都跑通了，内存问题也有了很大改善。
因为未来可能加入音频和视频，所以这次针对图片单独新建的 Entity ，特意添加了几个通用的属性，希望未来不再改动 Entity 。
这一年，我的 App 也凑个热闹，首次进行优惠促销。
促销价格从 6 月 1 日持续到 6 月 18 日 23:59 。
下周我分享一下这个 618 我都买了什么。
《 SwiftUI + Core Data App 的内存占用优化之旅》，https://www.fatbobman.com/posts/memory-usage-optimization/
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.