原文地址

背景

在iOS开发过程中，是否经常遇到这样的场景：简单修改几行代码，想要立刻看到效果，却需要重新增量编译，苦苦等待编译、链接、安装、运行这个漫长的过程；特别是在中大型项目(如手Q)中，增量编译耗时也要60s甚至更多，非常影响开发效率。

为了解决增量编译，业界上也有IPAPatch及InjectionIII方案：

IPAPatch 是基于编译子工程，链接为动态库打包到宿主工程，需要改变代码依赖逻辑，使用局限性大且效果并不理想。

InjectionIII 也是基于dylib注入原理实现的iOS热重载能力，但是不支持真机以及dylib注入时仅简单处理函数替换，热重载的能力存在比较大的局限性，如存在对release版本静态库或动态库依赖的代码文件或存在被hook的类的实现代码文件进行热重载，要么无法支持，要么可能出现循环调用而导致应用出现Crash，且对Swift、C++代码的热重载支持也非常有限。如果基于InjectionIII的基础上进行开发，后续如果InjectionIII更新则不利于迭代。

上述两个方案均不能满足我们的需求，因此我们决定在基于dylib注入的原理基础上对热重载实现进行探索实现。

滤镜最早应用在电视影视业，对剧和电影作品后期进行调色效果。如今拍照、修图都离不开滤镜效果。我们在微博、朋友圈、电视、影院里看到的照片视频，无一没有滤镜的效果，滤镜已经深入我们生活的方方面面。

这里浅略地揭秘一下当前图像处理中滤镜底层的原理。

原文地址

据不完全统计，全世界每隔3秒就有一个人上传自己的自拍照，甚至不少人在P图上所花的时间都超过了化妆时间。

从十多年前“美图秀秀”的横空出世，再到近年来的实时美颜。到今天，美颜功能已经嵌入到各类手机系统当中，帮助大家实现完美自拍。有玩笑说，中国的P图术、韩国的整容术和日本的化妆术瓜三分天下。此秘术自诞生以来教众不断，但受用者，可瞬间变成天仙下凡，号称“传说中的3大东方神秘力量”。由此可见，随着朋友圈、微博等自拍社交越来越盛行，拍个美美的照片已经是人们的刚需了。

其实磨皮算法最底层的本质就是一种降噪算法，也可以说是模糊算法。即通过对脸部的模糊，把各种面部瑕疵模糊掉，以达到磨皮的效果。

翻译自wwdc-2025-whats-new-for-the-apple-community

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个视频中。

参考链接

Kuikly - 组件

Pager

Pager为Kuikly页面的入口类，类似iOS UI中的VC, Pager也有类似VC的生命周期：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

// 已创建
override fun created() {
    super.created()
        
}
 
// 页面在屏幕上可见
override fun pageDidAppear() {
    super.pageDidAppear()
   
}

// 页面在屏幕上消失
override fun pageDidDisappear() {
    super.pageDidDisappear()

}

// 页面即将消失
override fun pageWillDestroy() {
    super.pageWillDestroy()

}

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%左右的提升,

在 GitHub 上确实有不少优秀且实用的 iOS 图片编辑相关的开源项目和 Demo。这些项目覆盖了基础编辑（裁剪、旋转、调整）、滤镜应用、涂鸦、贴纸添加、高级特效等功能。以下是一些值得关注的项目，适合学习和集成：

🛠 一、功能较全的图片编辑框架

1. TOCropViewController

   • 简介：专注图片裁剪（支持圆形、矩形、自定义比例），代码简洁高效，被广泛使用。
   • 链接：https://github.com/TimOliver/TOCropViewController
   • 特点：轻量级、支持缩放、旋转, 动画流畅。

2. YPImagePicker

   • 简介：类似 Instagram 的图片选择+基础编辑（裁剪、滤镜）库。
   • 链接：https://github.com/Yummypets/YPImagePicker
   • 特点：集成拍照/录像、多选、滤镜和裁剪，Swift 编写。

最近遇到一个问题, 需要定位到 TableView 的某一行, 历史代码是使用

1

- (CGRect)rectForRowAtIndexPath:(NSIndexPath *)indexPath;

获取到对应的cell 在 TableView 上的位置, 然后再根据业务做了一些简单的计算, 最后使用

1

- (void)setContentOffset:(CGPoint)contentOffset animated:(BOOL)animated;

跳转到最终的位置.

但是由于这个业务比较复杂, 为了性能, 开启了预估行高(estimatedHeightForRowAtIndexPath), 实际上, TableViewCell 的高度也根据业务各不一样, 预估值也与实际情况出入较大, 导致上面的 setContentOffset 跳到了不正确的行高.