共 8 篇相关文章
这篇讲的是如何利用Storyboard的可视化特性，去掉iOS开发中一些重复又琐碎的UITableView编码工作。作者从两个高频场景切入：一是在非UITableViewController里，手动添加UITableView后那两行必须写的代理设置代码（delegate和dataSource），其实可以通过在Storyboard中连线直接省掉，让代码更干净。二是处理“数据不足时隐藏空白行”这个需求，作者指出了常见的tableFooterView = UIView()写法可能引发刷新浪费和崩溃的隐患，并提出了一个更稳健的可视化方案：直接在Storyboard里为表格放一个占位cell和一个同级空view。通过调整空view的高度，不仅能达到隐藏效果，还能灵活控制底部边框的显示与否，甚至可以用于实现表格底部固定视图这种特殊UI，避免了许多额外编码。本质上，这是在用Xcode的界面工具代替手写样板代码，让开发更直观健壮。
这篇讲的是如何用Swift从零搭建一个类似支付宝首页的无限循环图片轮播组件。作者从界面搭建入手，详细演示了如何使用`UIScrollView`配合`UIPageControl`，并利用Auto Layout完成基础布局。 实现无限轮播的核心思路非常巧妙：在真实图片序列的首尾各拼接一张额外的图片。当用户滑动到最前或最后这张“辅助图”时，代码会在`scrollViewDidScroll`代理方法中，悄无声息地将`contentOffset`重置回真实图片序列的起始位置，从而在视觉上创造出可以一直朝一个方向滑动的错觉。文章也具体展示了如何通过计算滑动偏移量来同步更新底部小圆点的指示位置，并解决了由此带来的小圆点错位问题。 文章最后附有完整的代码示例和最终效果GIF，思路清晰，步骤具体，对于想要理解滚动视图高级用法或实现自定义轮播组件的iOS开发者来说，是一份非常实用的实战指南。
这篇是 iOS 开发 UI 构建方式系列文章的开篇，主要聚焦于如何有效使用 Storyboard。作者首先点明了 Storyboard 的核心价值：它不仅仅是一个描述页面布局的 XML 文件，其更深层的作用是让多个页面及其关系可视化，并通过 Segue 提供一种直观的跳转管理方式。 文章随后分享了一个经典的“踩坑”经历：新项目运行后页面全黑。其根因在于未正确设置 Storyboard 的初始窗体（Initial View Controller），导致 APP 启动后无法加载界面。作者通过截图和简单设置清晰地展示了解决方案。 为了避免单个 Storyboard 文件变得臃肿难维护，作者重点推荐了“多 Storyboard 最佳实践”。他以实际项目重构为例，讲解了如何按功能模块（如登录、考试）划分独立的 Storyboard 文件，并详细说明了在代码中如何通过 `UIStoryboard` 类实例化并调用另一个 Storyboard 中的窗体，无论是作为初始窗体还是通过 Storyboard ID 定位。 最后，文章点出 Storyboard 与 Auto Layout 天作之合的特性，并预告了下一篇将深入探讨另一种 UI 构建方式——xib，为读者对比不同方案的优劣和适用场景做好了铺垫。
这篇讲的是如何在 iOS 开发中为 UIView 的任意角设置圆角。作者从最常见的全圆角需求出发，指出虽然一句 `cornerRadius` 就能搞定四个角，但当我们只想让某些角变圆时，就得动用 `layer.mask` 与 `UIBezierPath` 这一组合。 文章核心在于利用 `UIRectCorner` 枚举精准控制哪些角需要圆角处理。通过枚举值，开发者可以灵活组合左上、右上、左下、右下四个角。作者展示了一个实际代码示例：在 `layoutSubviews` 中创建一个 `CAShapeLayer`，将其路径设置为一个由 `bezierPathWithRoundedRect:byRoundingCorners:cornerRadii:` 方法生成的贝塞尔曲线，最后将这个 shapeLayer 作为视图的遮罩。运行效果显示，一个视图的三个角（除了右下角）被成功设置成了圆角。 整个过程清晰展示了从发现问题（需要局部圆角）到提供具体实现方案的思路，对于需要精细化 UI 处理的 iOS 开发者来说，这是一个非常实用的小技巧。
这篇实战记录，正是一位开发者在面对“APP保持竖屏，但特定页面需横屏打开”这一需求时，从踩坑到解决的全过程。文章从最基础的`UIDevice.currentDevice().setValue(...)`方法实现页面旋转切入，但很快遭遇了方向被锁死、退出页面后异常横屏的典型BUG。 作者没有停留在表面，而是深入研究了`shouldAutorotate`、`supportedInterfaceOrientations`等系统回调的运作机制。关键在于，对于`TabBarController`包裹`NavigationController`这类常见复杂架构，系统判断屏幕方向的依据并非当前页面，而是根控制器。文章最终给出了自定义`TabBarController`并覆写相关方法的终极方案，并提供了完整的代码仓库供参考。对于需要精细控制屏幕方向的iOS开发者，其中对系统机制的分析和分层解决方案具有直接的实用价值。
这篇讲的是 iOS 开发中几个容易被忽略的图片处理细节，作者从实际编码经验出发，给出了不少实用技巧。 比如保存 GIF 动图，直接用 UIImageWriteToSavedPhotosAlbum 会转码成 PNG，正确做法是通过 ALAssetsLibrary 的 writeImageDataToSavedPhotosAlbum 来保留原始动图格式。保存 UIImage 到磁盘时，用 NSKeyedArchiver 其实是性能最差的方案，对于不含透明像素的图片，用 UIImageJPEGRepresentation(0.9) 压缩保存反而在编码速度和文件体积上都更优。 文章还深入解释了 UIImage 的缓存机制。通过 imageNamed 创建的图片，其解码数据在第一次显示时才会生成，并缓存在全局缓存中，通常只在 App 退后台或收到内存警告时清空。即使使用 imageWithData 创建图片，底层也会启用缓存。想要避免缓存，可以手动调用 CGImageSourceCreateWithData 并关闭缓存参数，或者更常见地，将图片绘制到画布再取出数据——这也是很多网络图片库采用的做法。 此外，文章还介绍了如何直接获取图片解码后的原生数据、快速判断文件图片类型，以及如何利用 CGImageSource 的 Incremental 方式实现像浏览器那样边下载边显示图片的效果，并对比了 PINRemoteImage、YYWebImage 与 SDWebImage 在这方面的实现差异。
这篇深度解析从 iOS 屏幕显示原理入手，剖析了界面卡顿的根源。文章详细拆解了 VSync 机制下，CPU 与 GPU 协同工作的流程，并指出当任一方未能及时完成渲染时，掉帧便会发生。作者系统性地列举了 CPU 侧的对象创建与销毁、布局计算（尤其是 Autolayout 的性能陷阱）、文本渲染等常见开销来源，也涵盖了 GPU 侧的渲染与合成问题。 在剖析原理的基础上，文章重点介绍了 AsyncDisplayKit 框架。作者阐述了其图层预合成、异步并发操作等核心设计，以及如何利用 Runloop 进行任务分发，从而将主线程从繁重的布局和渲染任务中解放出来。 文章更提供了极具实践价值的参考：一个完全仿照微博、Twitter 的开源列表 Demo。通过预排版、预渲染、异步绘制等优化技巧的组合运用，该 Demo 即使在 iPhone 4S 上快速滑动，也能稳定保持 50-60 FPS 的流畅度。这不仅仅是理论分析，更是一份可供验证、对比和直接使用的性能优化方案指南。
这篇讲的是iOS产品团队如何通过定期复盘提升决策质量——作者从“朝花夕拾”这一日常隐喻出发，指出产品总结就像一面镜子，能帮助团队清晰看到当前状态的真实投入产出比。文章没有堆砌高深理论，而是直指一个常见痛点：很多简单有效的总结方法大家“都知道，但没有正视”，或“没真心用过”。 作者强调，这种复盘的价值在于建立清晰的反馈循环，让团队在下一次迭代中能基于数据与反思做出更精准的判断，避免重复踩坑。文章的核心观点是，定期、诚实地回顾过往，不是为了归咎责任，而是为了让“下次迈开步子时”的步伐更稳、方向更准。这种对执行细节的审视与归纳，恰恰是产品能力迭代中容易忽视却至关重要的环节。
