独立开发周记 #16：5月总结和优化之路
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/