如何架构一个单独的代码核心模块:IOS Image Cache demo

本文对比分析了自定义图片缓存策略与开源库SDWebImage在在线视频直播应用中的应用,探讨了模块设计时考虑外部使用者方便的重要性,以及如何在模块设计中平衡通用性与维护性,避免过度复杂化。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

问题描述:

场景: 
公司项目开发一个IOS娱乐应用(在线视频直播应用),里面涉及到很多图片: 
( 用户头像、相册、直播活动预告图、直播视频聊天室封面图)

我的代码策略: 
在图片缓存方面,我根据人的想法做了一个smart image cache: 

( 用户头像——永远只更新——替换旧相册 
    用户相册——删掉已经不存在的相片,缓存新加入的用户相片 
    直播活动预告图——删掉14天之前的图片——一个活动顶多提前14天进行预告 ——类似于天气预报也有最多提前天数限制
    直播视频聊天室封面图——删掉1天之前的图片——没有哪个视频直播会超过24小时 ) 

这个是我根据数据的类型想的更新策略,并且实现了代码
(core data——类似于数据库的东西 + NSOperationQueue——封装好的线程队列器 + NSOperation——线程操作); 
然后我根据每次的数据网络请求,把每次网络请求的数据——一个数组传入smart image cache,每一批传入的数据我都起一个线程去下载、然后缓存这些图片,在每一批图片下载完成后,我会根据缓存的类型,执行缓存的清理策略。 
在多线程方面,考虑到移动设备的上行、下行带宽,我使用了以下2个策略: 
1.线程后进先执行,最新显示的需要数据的界面图片下载优先(有最大下载线程数目的限制,其实是移动网络的上行、下行带宽的考虑,毕竟现在移动设备的处理器都很牛的) 
2.同样的线程(根据外部使用者传入的线程name来识别),会使用最新的线程执行,而停止掉旧线程(主要用于用户在界面上:上拉刷新数据,外部异常重复请求的保护等) 
遇到的弊端就是,使用smart image cache时需要自己管理图片的显示、刷新,就是使用上稍微要麻烦些 

网上公开库的代码策略: 
我一个同事在网上下载了image cache的代码(SDWebImage:通用性image缓存),和我写的比较: 
1.缓存的清理是一次性清理(不是smart),如果用户一直不清理缓存,那么应用所占磁盘控件就会增长,清理掉了,所以的缓存都没了(符合清理缓存的意思) 
2.每个图片都会起一个NSURLConnection去下载图片,如果界面图片多,会起很多个 (网络上的代码库没有做限制)
3.需要自己手动的取消图片的下载(离开当前界面的时候)
4.由于该代码使用了UIImageView Category的方法(类似于:C++:用继承组合为已有类添加新的方法,扩展已有的类),所以使用上很方便(亮点,羡慕!我的代码由于涉及到缓存清理策略,故必须要使用批处理(数组)的方式,所以无法使用单个的请求,所以以我目前的经验无法使用UIImageView Category,这样没有方便外部的使用者) 

所以,在应该使用哪个图片缓存模块的问题上遇到了分歧,(我同事有点固执,不愿意使用我的代码,因为他觉得SDWebImage使用方便) 
以上是遇到问题的描述,我想问的问题是:
1.如果你是我们团队的leader,你使用哪个代码
2.在做一个模块设计的时候,是不是应该把外部使用者的方便放到第一位考虑
3.我现在设计一个模块代码的时候,总是想着外面的在使用这个模块代码的场景下会遇到什么样子的复杂逻辑,而这个逻辑是不是可以封装到我的模块里,这样使用者不需要没个人都去处理一些逻辑(比如说上文的重复数据下载请求,自己内部模块管理线程的优先级,使用者无需关心),但是如果老这样想,我发现模块的代码会越来越复杂,变得没有通用和维护性,变成了一个定制化的模块
4.总的问题:如何架构一个单独的代码核心模块

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值