一水

前段时间看到一个关于AppDelegate瘦身的文章 AppDelegate瘦身指南。想起来自己在这方面做得一些事情，拿出来一起分享一下。我写了一个单独的类库来处理这个问题： MRAppDelegateComponents。 使用可以直接： 关于AppDelegate碰到的问题…

作为 Coder 就需要往后思考，业务可能会怎么变，当前程序结构是否足够灵活，方便调整。当业务需求调整的时候，能够以最小的代价来满足。而这就是『冗余性』思考。针对变化进行设计而不只是针对需求。

个人一直觉得对于搞 IOS 开发来说自己实现一遍 TableView 就像是一种成人礼一样。你能够通过实现一个 UITableView 来深入的理解 UIKit 的一些技术细节，对 IOS UI 编程所使用到的工具，有比较深入的了解。这样，写程序的时候才不会捉襟见肘。

这一次来说一下在日常的开发中最常见的两个问题： 一个是样式，颜色、背景、font。。。。 一个是布局管理 其中的成果自然也是搞成了类库方便使用（Talk is cheap show me the code.）：StyleSheet 和 DZGeometryTools。

这边的产品需求，需要在某些场景下进行清场操作，将所有的 ViewController 堆栈清空，页面回滚到首页。我们内部的页面都能够完成这个操作。但是有些第三方的页面，怎么都搞不掉。比如支付宝的页面。因为是引入的 SDK，没有代码，所以第一方案，向支付宝侧提出需求，要求提供一个函数接口，能够清退他们的界面，但是他们说不能满足该需求。所以，我们只能开始了黑科技之旅

使用宏定义来简化输入，提高输入的效率。同时提高输入准确性。

该系列文章是2016年折腾的一个总结，对于这一年中思考和解决的一些问题做一些梳理和总结 上一篇文章iOS架构设计解耦的尝试之模块间通信中提到要说一下全局UI堆栈是怎么维护的。要写的时候发现，这个东西背后还有一个更有意思的东西：使用AOP对VC的业务逻辑进行切割。在DZURLRo…

iOS架构设计解耦的尝试之模块间通信 改系列文章是2016年折腾的一个总结，对于这一年中思考和解决的一些问题做一些梳理和总结。 前两篇文章主要是说了业务逻辑接口还有模块化的事情。随着系统内部逻辑单元（可能是模块，也可能是为了解耦拆解出来用来承载职责的类等常见的实现）的增多。势必…

以 Cocoapods 为核心工具，将每个子模块拆解成 podspec。主工程中只有配置文件，没有代码，代码通过 cocoapods 的开发模式相对引入到的主工程中。每个子模块同时也都是一个 git repo。通过 Google Repo 来管理多个 git repo。