juejin.im
获得徽章 5
- 面试必考题
：为什么圆角和裁剪后iOS绘制会触发离屏渲染？
答：默认情况下每个视图都是完全独立绘制渲染的。而当某个父视图设置了圆角和裁剪并且又有子视图时，父视图只会对自身进行裁剪绘制和渲染。当子视图绘制时就要考虑被父视图裁剪部分的绘制渲染处理，因此需要反复递归回溯和拷贝父视图的渲染上下文和裁剪信息，再和子视图做合并处理，以便完成最终的裁剪效果。这样势必产生大量的时间和内存的开销。解决的方法是当父视图被裁剪和有圆角并且有子视图时，就单独的开辟一块绘制上下文，把自身和所有子视图的内容都统一绘制在这个上下文中，这样子视图也不需要再单独绘制了，所有裁剪都会统一处理。当父视图绘制完成时再将开辟的缓冲上下文拷贝到屏幕上下文中去。这个过程就是离屏渲染！！所以离屏渲染其实和我们先将内容绘制在位图内存上下文然后再统一拷贝到屏幕上下文中的双缓存技术是非常相似的。使用离屏渲染主要因为iOS内部的视图独立绘制技术所导致的一些缺陷而不得不才用的技术。展开评论20 - 今天一个群友和我交流起一个问题：“说看了我的一篇博客很受用，问我怎么能够监控程序中那些泄漏的对象被哪些闭包强持有。” 我回答说：“我只是负责生产砖块，具体房子你们去搭”。后来想了想又告诉他我的另外一篇文章，然后提供了一下思路，然后结合起来也许能解答问题。
然后又想起前一阵子抖音发的一篇火爆互联网的二进制重排文章。其中的block的拦截部分则是应用了我的某一篇文章中介绍的技术。抖音这个也算是建了一座房子。
其实现实中也是这样的：做砖的总是没有建房子的收入多！ 人们更多的是关注那些造房子的人。但是总要有人去做砖。
其实我是来卖砖的，欢迎大家关注我的block四重奏：
1. 一种查看Block中引用的所有外部对象的实现方法
juejin.im
2. iOS调试Block引用对象无法被释放的一个小技巧juejin.im
3. 运行时Hook所有Block方法调用的技术实现juejin.im
4. 深入解构iOS的block闭包实现原理juejin.im 展开26 - Android开发比较流行MVP框架，然后看了几篇相关的文章，感觉有几点很奇怪：
1.在实现上把Activity以及布局统一当做V来看待，而把事件逻辑部分移植到所谓的P层。其实这个P就是一个从Activity层中抽象出来的一部分逻辑。
2.这样设计的原因还是和Activity的生命周期和实现有关。Activity设计的太过重了，两个Activity之间进行通信还需要进行封包和解包处理。他本来设计是可以用来跨进程之间相互调用，但是实际中大部分Activity是在一个进程内被使用所以两个Activity之间通信成本就太高了。当然解决的方法是用Fragment。另外还有一个原因是Activity还有建立、销毁的生命周期问题导致一些状态值的存储成本太高。而抽象出来的P层则跳出了上述的两个约束。
3.其实我不认同的观点是MVP中把Activity+布局当做V来看待。感觉解决的方法还是一个根的Activity并加众多的Fragment加布局来实现应用程序。也就是还是原本的MVC框架。展开74 - 对于MVP和MVC的区别，我也一直在尝试着去了解他们之间的差异。可能是我理解有限，目前我自己得出的结论就是二者的差别在于M和V是否可以直接通信可以就为MVC，不可以就为MVP，但我觉得这种区别来划分是否过于绝对。这个其实可以讨论一下。68
- 当年facebook的RN出来后国内掀起一阵RN改造和学习的狂潮，然后各大厂家都在争相建设自己的RN平台。现在Google的flutter出来后国内又掀起一阵flutter改造和学习的狂潮，然后各大厂家都在争相的建设自己的flutter平台。这种现象再次暴露了中国程序员只会做应用而不会做技术的短板。只会做1到1.5而不会做0到1的不争事实。也许我孤陋寡闻，但是我觉得美国那几家顶级的软件公司是肯定不会这样做的。呼吁BAT能有一家站起来担负起做出一个0到1的真牛框架。展开5133
- 在release模式下编译swift的代码发现其中很多函数和方法都被编译链接为内连函数，而且对多态的实现用的是硬编码判断。我想这也是swift应用包要比oc应用包尺寸大但是运行速度快的一个原因之一吧。评论5
- 现在一些开发人员大量用第三方开源库，比如masonry,afnetworking。结果本来的auto layout相关类和函数以及nsurlsession相关的知识却一窍不通。这是好事还是坏事呢？这个现象让我想起了一个典故：邯郸学步。1410
- mac os上的终端命令行中的四个快捷键：
ctrl+a 命令行首
ctrl+e 命令行尾
option+command+右箭头 下一个单词
option+command+左箭头 上一个单词220
