AsyncDisplayKit近一年的使用体会及疑难点

一个第三方库能做到像新产品一样,值得大家去写写使用体会的,并不多见,AsyncDisplayKit却完全可以,因为AsyncDisplayKit不仅仅是一个工具,它更像一个系统UI框架,改变整个编码体验。也正是这种极强的侵入性,导致不少听过、star过,甚至下过demo跑过AsyncDisplayKit的你我,望而却步,驻足观望。但列表界面稍微复杂时,烦人的高度计算,因为性能不得不放弃Autolayout而选择上古时代的frame layout,令人精疲力尽,这时AsyncDisplayKit总会不自然浮现眼前,让你跃跃欲试。

去年10月份,我们入坑了。

当时还只是拿简单的列表页试水,基本上手后,去年底在稍微空闲的时候用AsyncDisplayKit重构了帖子详情,今年三月份,又借着公司聊天增加群聊的契机,用AsyncDisplayKit重构整个聊天。林林总总,从简单到复杂,踩过的坑大大小小,将近一年的时光转眼飞逝,可以写写总结了。

学习曲线

先说说学习曲线,这是大家都比较关心的问题。

iOS两个客户端代码复用小技巧

一般一个App只有一个客户端,因此也只有一份代码仓库,也就无所谓复用不复用。但两个客户端也不是没有,美团、饿了么等就分商家版和买家版,贝聊App也分为老师版和家长版两个客户端。有两个客户端代码复用就在所难免,比如基本的工具类,比如一些共用的业务。本文就以贝聊App为例,分享当有两个客户端时代码复用的小技巧。

repository仓库划分

贝聊APP远程仓库划分为三个,一个家长端repository,一个老师端repository,一个两端共用的BLKit repository


《结构型设计模式》之iOS系统框架实践

结构型设计模式是从程序的结构上解决模块之间的耦合问题,主要包括适配器模式、桥接模式、组合模式、装饰器模式、外观模式、享元模式和代理模式等7种经典设计模式,在iOS系统框架中组合模式、装饰器模式和享元模式是有经典实现的,而适配器模式、桥接模式、外观模式和代理模式iOS系统框架中的实现并不明显,但在第三方框架或者贝聊(我所在的公司)的App是有用到的,为便于讲解,本文会挑选最恰当的例子。

本文是设计模式之iOS系统框架实践系列中的第二篇(总共三篇),如果您对《创建型设计模式》感兴趣,建议看看我的前一篇文章《创建型设计模式》之iOS系统框架实践

适配器模式(Adapter)

适配器模式是将一种接口,转换成另外一种接口,一般被适配的类的功能与外界所希望的一致,只是接口与外界所希望的不同,所以需要适配接口。一般需要新旧接口的转换时用到。

iOS触摸事件的流动

当指肚轻触屏幕,整个系统像沉睡的生灵突然被惊醒,然后经历过腥风血雨的一段奇幻旅行,最终又归于沉寂。

整个iOS触摸事件从产生到寂灭大致如下图:


如何在iOS开发中更好的做假数据?

当工期比较紧的时候,项目开发中会经常出现移动端等待后端接口数据的情形,不但耽误项目进度,更让人有种无奈的绝望。所以在开发中,我们常常自己做些假数据,以方便开发和UI调试。然而做假数据方法不同,效率和安全性都各不同,有时稍有不慎,还会产生很大的bug。因此本文拟结合我在贝聊的开发经验,讲一讲我们组在iOS开发中曾经用过的做假数据的方法及其优劣。

示例项目

为方便下文的说明,本文主要以贝聊家长版app发现首页的热门帖子列表的实现为例。热门帖子列表的样式如下图:

这是比较常见的列表,用常用的UITableView实现即可,但需要自定义一个的UITableViewCell的子类ExploreTableViewCell。项目中,ExploreTableViewCell并没有用xib实现(因为xib日后不好修改,且代码复用性差),而是通过SnapKit用纯代码布的局,具体的布局代码大致如下:

如何让pod update快到飞起?

想成为一个好的程序员,翻墙是必备技能,查个资料、搜个问题啥的,百度实在是渣(不是黑百度),可以说编程,不翻墙没法活。

至于如何翻墙,方法很多,有自己买VPN的,有公司自己配的,也有走代理的。个人最喜欢shadowsocks,可惜现在已经找不到正规的下载地址了,但只要用心找找,总还是有好人分享的。如果您用的是mac,实在下载不到,可以在评论中把邮箱留下,我发给你。

有了翻墙软件,固然神清气爽,但pod update等终端命令发起的网络请求却不能走代理,几乎停滞的下载速度让人窒息,有时候项目稍微大一点,一个pod update命令能跑一上午,这还编什么程序,如果pod update能快到飞起,那是怎样令人神往的感觉?

办法总是有的,这就是这个时代最迷人的地方。

前提

再说一遍前提,必须得先能翻墙,并且翻墙后的网速得比较快。

闭包捕捉(closure capture)浅析

根据Swift官方文档,闭包(closure)会自动捕捉其所在上下文中的外部变量,即使是定义这些变量的上下文已经消失。寥寥数字,其实已经将闭包捕捉说的足够清晰明了,只是其中隐含的诸如捕捉的具体含义、捕捉的时机、被捕捉变量的特性和捕捉列表的意义等细节,如不详加研究,使用闭包还是会错误百出,难以挥洒自如。

本文中所有代码均在playground中运行,若欲在实际项目中测试,需做部分修改,但基本逻辑和结论不变

——————— 本文部分结论和例子根据部分读者意见做了修正更新,感谢他们 ———————

捕捉的含义

闭包捕捉等同于copy

闭包捕捉某个变量就意味着copy一份这个变量,值类型的变量直接复制值,引用类型的变量复制引用。复制后的变量名同被捕捉的变量,复制后的变量仍为变量,常量仍为常量。

iOS并发(concurrency)概念浅析

在进行iOS开发过程中,我们常会遇到网络请求、复杂计算、数据存取等比较耗时的操作,如果处理不合理,将对APP的流畅度产生较大影响。除了优化APP架构,并发(concurrency)是一个常用且较好的解决方法,但并发涉及串行、并发、并行、同步、异步、多线程、GCD、NSOperation和NSOperationQueue等诸多容易混淆的概念,为求概念清晰明了,还请茗茶静坐,听我徐徐道来。

线程和任务

线程(thread) 和任务(task)是其他并发概念的基础,因此也是首要需理清的概念,以下是其要点,详细可参考Thread (computing)Task (computing))。

typealias理解小误区

alias在英语中是别名之意,那typealias,顾名思义,是指类型的别名。Swift的官方文档中对typealias关键词的演示,也是以赋值的形式,给一个现有类型取一个恰当的别名,便于在上下文中使用:

protocol Container {
    typealias ItemType
    //some other things
     …
}

struct IntStack: Container {
    typealias ItemType = Int
     //some other things
    …
}
Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×