滤镜最早应用在电视影视业,对剧和电影作品后期进行调色效果。如今拍照、修图都离不开滤镜效果。我们在微博、朋友圈、电视、影院里看到的照片视频,无一没有滤镜的效果,滤镜已经深入我们生活的方方面面。
这里浅略地揭秘一下当前图像处理中滤镜底层的原理。
滤镜最早应用在电视影视业,对剧和电影作品后期进行调色效果。如今拍照、修图都离不开滤镜效果。我们在微博、朋友圈、电视、影院里看到的照片视频,无一没有滤镜的效果,滤镜已经深入我们生活的方方面面。
这里浅略地揭秘一下当前图像处理中滤镜底层的原理。
据不完全统计,全世界每隔3秒就有一个人上传自己的自拍照,甚至不少人在P图上所花的时间都超过了化妆时间。
从十多年前“美图秀秀”的横空出世,再到近年来的实时美颜。到今天,美颜功能已经嵌入到各类手机系统当中,帮助大家实现完美自拍。有玩笑说,中国的P图术、韩国的整容术和日本的化妆术瓜三分天下。此秘术自诞生以来教众不断,但受用者,可瞬间变成天仙下凡,号称“传说中的3大东方神秘力量”。由此可见,随着朋友圈、微博等自拍社交越来越盛行,拍个美美的照片已经是人们的刚需了。
其实磨皮算法最底层的本质就是一种降噪算法,也可以说是模糊算法。即通过对脸部的模糊,把各种面部瑕疵模糊掉,以达到磨皮的效果。
The WWDC25 week has come to a close, marked by its central theme: Cross-Platform Consistency. The announcement of their new design system, Liquid Glass, is undoubtedly what most people will be talking about, alongside the version number for all platforms matching the year, but what we might miss when focusing on this shining update is all the work that made it possible and how it has reflected on the evolution of the platforms, leading us to this moment.WWDC25周已经落下帷幕,其核心主题是:跨平台一致性。宣布的全新设计系统Liquid Glass无疑将成为大多数人讨论的焦点,此外所有平台的版本号都与年份一致,但当我们关注这个闪亮的更新时,可能会忽略所有使其成为可能的工作,以及它如何反映平台的演变,带领我们走到这一步。
There are many updates to the foundational frameworks that app developers use to bring their apps to life and they are spread across the over 100 videos made available through the developer portal.许多基础框架都进行了更新,应用开发者用来赋予应用生命的基础架构,这些更新散布在开发者门户提供的超过100个视频中。
Pager为Kuikly页面的入口类,类似iOS UI中的VC, Pager也有类似VC的生命周期:
1 | // 已创建 |
Kuikly是基于Kotlin MultiPlatform(KMP)构建的跨端开发框架, 支持Android、iOS、HarmonyOS和H5/小程序等多个平台, 据 PCG 开发团队的报告, Kuikly 可以提升团队 85%的开发效率.
这里记录一些我自己使用 Kuikly 遇到的一些坑, 希望后面能少点踩坑吧.
SDWebImage 是iOS 开发最流行的异步图片加载框架, 其中的缓存模块 SDImageCache
有一个很精巧的设计弱引用缓存, 源码参考
1 | @property (nonatomic, strong, nonnull) NSMapTable<KeyType, ObjectType> *weakCache; // strong-weak cache |
在我们的项目中引入了这个小修改, 整体的缓存命中率有1%左右的提升,
是否开启 | 内存缓存命中率 | 磁盘缓存命中率 | 下载命中率 |
---|---|---|---|
开启弱引用缓存 | 67.99% | 21.36% | 10.67% |
不开启弱引用缓存 | 66.76% | 21.99% | 11.25% |
在 GitHub 上确实有不少优秀且实用的 iOS 图片编辑相关的开源项目和 Demo。这些项目覆盖了基础编辑(裁剪、旋转、调整)、滤镜应用、涂鸦、贴纸添加、高级特效等功能。以下是一些值得关注的项目,适合学习和集成:
TOCropViewController
YPImagePicker
最近遇到一个问题, 需要定位到 TableView 的某一行, 历史代码是使用
1 | - (CGRect)rectForRowAtIndexPath:(NSIndexPath *)indexPath; |
获取到对应的cell 在 TableView 上的位置, 然后再根据业务做了一些简单的计算, 最后使用
1 | - (void)setContentOffset:(CGPoint)contentOffset animated:(BOOL)animated; |
跳转到最终的位置.
但是由于这个业务比较复杂, 为了性能, 开启了预估行高(estimatedHeightForRowAtIndexPath
), 实际上, TableViewCell 的高度也根据业务各不一样, 预估值也与实际情况出入较大, 导致上面的 setContentOffset
跳到了不正确的行高.