掘友等级
坚持原创 以造轮子为乐。
Adhere to the original To build the wheels。 获得徽章 5
面试必考题:为什么圆角和裁剪后iOS绘制会触发离屏渲染?
答:默认情况下每个视图都是完全独立绘制渲染的。而当某个父视图设置了圆角和裁剪并且又有子视图时,父视图只会对自身进行裁剪绘制和渲染。当子视图绘制时就要考虑被父视图裁剪部分的绘制渲染处理,因此需要反复递归回溯和拷贝父视图的渲染上下文和裁剪信息,再和子视图做合并处理,以便完成最终的裁剪效果。这样势必产生大量的时间和内存的开销。解决的方法是当父视图被裁剪和有圆角并且有子视图时,就单独的开辟一块绘制上下文,把自身和所有子视图的内容都统一绘制在这个上下文中,这样子视图也不需要再单独绘制了,所有裁剪都会统一处理。当父视图绘制完成时再将开辟的缓冲上下文拷贝到屏幕上下文中去。这个过程就是离屏渲染!!所以离屏渲染其实和我们先将内容绘制在位图内存上下文然后再统一拷贝到屏幕上下文中的双缓存技术是非常相似的。使用离屏渲染主要因为iOS内部的视图独立绘制技术所导致的一些缺陷而不得不才用的技术。
Android开发比较流行MVP框架,然后看了几篇相关的文章,感觉有几点很奇怪:
1.在实现上把Activity以及布局统一当做V来看待,而把事件逻辑部分移植到所谓的P层。其实这个P就是一个从Activity层中抽象出来的一部分逻辑。
2.这样设计的原因还是和Activity的生命周期和实现有关。Activity设计的太过重了,两个Activity之间进行通信还需要进行封包和解包处理。他本来设计是可以用来跨进程之间相互调用,但是实际中大部分Activity是在一个进程内被使用所以两个Activity之间通信成本就太高了。当然解决的方法是用Fragment。另外还有一个原因是Activity还有建立、销毁的生命周期问题导致一些状态值的存储成本太高。而抽象出来的P层则跳出了上述的两个约束。
3.其实我不认同的观点是MVP中把Activity+布局当做V来看待。感觉解决的方法还是一个根的Activity并加众多的Fragment加布局来实现应用程序。也就是还是原本的MVC框架。
对于MVP和MVC的区别,我也一直在尝试着去了解他们之间的差异。可能是我理解有限,目前我自己得出的结论就是二者的差别在于M和V是否可以直接通信可以就为MVC,不可以就为MVP,但我觉得这种区别来划分是否过于绝对。这个其实可以讨论一下。
当年facebook的RN出来后国内掀起一阵RN改造和学习的狂潮,然后各大厂家都在争相建设自己的RN平台。现在Google的flutter出来后国内又掀起一阵flutter改造和学习的狂潮,然后各大厂家都在争相的建设自己的flutter平台。这种现象再次暴露了中国程序员只会做应用而不会做技术的短板。只会做1到1.5而不会做0到1的不争事实。也许我孤陋寡闻,但是我觉得美国那几家顶级的软件公司是肯定不会这样做的。呼吁BAT能有一家站起来担负起做出一个0到1的真牛框架。
在release模式下编译swift的代码发现其中很多函数和方法都被编译链接为内连函数,而且对多态的实现用的是硬编码判断。我想这也是swift应用包要比oc应用包尺寸大但是运行速度快的一个原因之一吧。
现在一些开发人员大量用第三方开源库,比如masonry,afnetworking。结果本来的auto layout相关类和函数以及nsurlsession相关的知识却一窍不通。这是好事还是坏事呢?这个现象让我想起了一个典故:邯郸学步。
很多时候一种所谓的新技术就是一门新发布的语言来实现老语言中的某个框架库。就像用中文翻译一篇莎士比亚的经典剧作一样。
这些所谓的新技术就是可以理解为某英文书籍的中文版一样。
mac os上的终端命令行中的四个快捷键:
ctrl+a 命令行首
ctrl+e 命令行尾
option+command+右箭头 下一个单词
option+command+左箭头 上一个单词
这也是我不太喜欢Java的原因,当然这和语言本身无关,而是应用这们语言的人太过于执着于设计模式了。
下一页