在日常开发中，我们经常会在 Debug 模式下打断点进行调试，并通过 LLDB 的 po 命令在控制台打印一些变量的值，以方便排查问题。
今天在 Release 模式下编译运行项目，发现要打印某一变量的值时（po xxx），报如下错误：
1 | error: Couldn't materialize: couldn't get the value of variable xxx: no location, value may have been optimized out |
大致意思是说，xxx 的值不存在，可能已经被编译优化了。而且在断点模式下当我们把鼠标的箭头移到某一变量上要进行快速浏览时，发现它们的值都是 nil。
当我们要做 App 日志上报时，需要考虑到一种行为：App 在启动时就崩溃闪退了，而且当遇到连续启动闪退（也就是每次打开 App 必崩）时，那几乎是灾难，但更可怕是，如果没有有效的监测手段，我们可能对已发生的这种线上严重问题毫不知情。
当我们的 iOS 工程要引用其它第三方开源库时，一般有以下几种方式：
（1）下载源代码直接拖拽到工程中；
（2）使用 CocoaPods 管理，当开启 use_frameworks! 标记时，第三方库会被编译成 .framework 引入工程，否则就会编译成 .a 静态库；
（3）使用 Carthage 管理，第三方库会被编译成 .framework 然后导入工程；
（4）直接下载作者编译好的 .framework 导入工程。
在小程序开发中，App(...) 和 Page(...) 是我们最熟悉也是最常用的两个函数，今天我们就来分析一下它们的内部实现，以及调用时的初始化流程。
前一段时间，我们公众号转载了有赞技术团队的《从源码看微信小程序启动过程》，这篇文章记录了小程序框架的基本代码结构，启动流程，以及程序实例化过程，非常值得反复阅读。你也可以把本文理解为是这篇文章的读后感或总结。
在日常开发中，我们通常会在 Debug 开发模式下写很多测试代码，或者引入一些测试专用的 .a 静态库或 .framework 动态库，也会通过 CocoaPods 引入一些第三方测试调试工具等；但我们往往不希望这些测试代码和测试用的库（Library/Framework）在 Release 正式包中被引用或导入，如何做到呢？
前两周我们发了一个小集「iOS 自带九宫格拼音键盘与 Emoji 表情之间的坑」，介绍了如何解决由于输入框限制 Emoji 表情的输入导致中文拼音也无法输入的问题。
后面我们又有了新需求：对输入框已输入的文本字数进行实时统计，并在界面上显示剩余字数，且不能让所输入的文本超过最大限制长度。但这个简单的功能仍然有不少小坑。
前段时间，我们知识小集公众号转载了有赞技术团队的《从源码看微信小程序启动过程》，这篇文章记录了小程序框架的基本代码结构，启动流程，以及程序实例化过程，非常值得反复阅读。猛戳此处！
当一个页面的 UIScrollView/UITableView 上有一个或多个输入框时，我们经常需要做一件事就是当列表拖拽/滑动时，就收起已经弹起的键盘。
