现状在 iOS 中我们常常会使用NSError来封装错误信息，相比于单纯的错误码，NSError包含更多的信息。主要有domain 错误发生域code 错误码userInfo 详细信息但这也意味着它的使用更繁琐些，一个简单的NSError初始化方法往往是这样NSError*error=[NSErrorerrorWithDomain:NIMLocalErrorDomaincode:NIMLocalErrorCodeInvalidParamuserInfo:nil];这里我们定义了自己的字符串常量NIMLocalErrorDomain来表示错误发生域和NIMLocalErrorCode枚举表示对应的错误码。但一个懒得要死的程序员显然对这种繁琐的初始化方法不感冒，然后就引入了宏定义使自己少写几行代码：#define NIMLocalError(x) ([NSError errorWithDomain:NIMLocalErrorDomain \ code:(x) \ userInfo:nil])这样我们就可以使用NSError *error = NIMLocalErro ...继续阅读 (6)

前言Instagram在去年年底开源了基于数据驱动的UICollectionView框架IGListKit。整个框架通过Adapter将过去直接暴露的CollectionViewDatasource和Delegate实现进行包装，并通过它关联Model和IGListSectionController。这使得上层用户只需要继承并实现所需要的IGListSectionController接口即可，很好地进行了代码解耦。整个思路比较新颖又很简洁，即使不直接使用这个框架，也可以按照思路依葫芦画瓢做出自己的简易版方案。不过今天要讲的并不是IGListKit本身，而是扒一扒它里面的IGListDiff实现。相比于前端各种各样Virtual DOM diff实现，移动端在这方面较为欠缺。在UITableView和UICollectionView的使用上，一旦同时发生数据删除，更新，添加时，我们的做法往往是手动计算出变化NSIndexPaths并调用批量刷新，甚至简单粗暴地调用reloadData做一次全刷新。而IGListKit的IGListDiff正是为这种场景而生：当数据变化产生后，通过调用IGListDiff自动计算前后两次的差值，为后续批量刷新提供数据。整个算法的复杂度为 O(n)，相当高效。IGList Diff算法介绍IGListDiff使用一个额外的哈希表和两个新旧哈希列表hash ...继续阅读 (15)

前言众所周知，在iOS端做持久化无非两种方式 （习惯性忽略CoreData）文档存储数据库存储前者以plist，NSUserDefautls，NSKeyedArchiver等为代表，优点是使用简单，但序列化和反序列化时往往需要操作整个文件，性能较差，且不适合大量数据存储。后者以SQLite为代表，优点是性能高，适宜大数据和复杂结构的存储，缺点是使用较繁琐，拓展和兼容老数据时较为复杂。而目前iOS社区对这种情况的改进方向无非是提供性能不错的NoSQL存储，如Realm，简易KeyValueStore。而后者就是今天探讨的重点。问题一个简易的KeyValueStore，如YTKKeyValueStore刨去其具体实现细节，核心就是使用SQLite创建一张只有Key(TEXT，主键) 和Value(BLOB/TEXT) 的数据库表。思路很简单，能够适应很多场景，但也有它的局限性：无内建缓存存储信息无法分类额外信息无法存储 (非特例化的额外数据)不支持复杂查询解决方案内建缓存缓存永远是加速I/O请求的最快途径，这毋庸置疑，关键问题是怎么做。从理论上来讲，SQLite其实已经提供了缓存支持，但问题在于他提供的缓存内容是裸数据：上层使用时不可避免的需要做反序列化的操作。出于对业务方调用友好和性能考虑，最好的做法自然是在I/O读取Value时自动将NSData转换为对应的Model。然而数据库并 ...继续阅读 (16)

前言众所周知，在iOS端做持久化无非两种方式 （习惯性忽略CoreData）文档存储数据库存储前者以plist，NSUserDefautls，NSKeyedArchiver等为代表，优点是使用简单，但序列化和反序列化时往往需要操作整个文件，性能较差，且不适合大量数据存储。后者以SQLite为代表，优点是性能高，适宜大数据和复杂结构的存储，缺点是使用较繁琐，拓展和兼容老数据时较为复杂。而目前iOS社区对这种情况的改进方向无非是提供性能不错的NoSQL存储，如Realm，简易KeyValueStore。而后者就是今天探讨的重点。问题一个简易的KeyValueStore，如YTKKeyValueStore刨去其具体实现细节，核心就是使用SQLite创建一张只有Key(TEXT，主键) 和Value(BLOB/TEXT) 的数据库表。思路很简单，能够适应很多场景，但也有它的局限性：无内建缓存存储信息无法分类额外信息无法存储 (非特例化的额外数据)不支持复杂查询解决方案内建缓存缓存永远是加速I/O请求的最快途径，这毋庸置疑，关键问题是怎么做。从理论上来讲，SQLite其实已经提供了缓存支持，但问题在于他提供的缓存内容是裸数据：上层使用时不可避免的需要做反序列化的操作。出于对业务方调用友好和性能考虑，最好的做法自然是在I/O读取Value时自动将NSData转换为对应的Model。然而数据库并 ...继续阅读 (7)

前言新开的一个项目，后台童鞋提议使用gRPC，于是默默上了gRPC这条贼船。目前行使平稳，有些小颠簸，但可以克服。gRPC 概述gRPC是由Google与2015年开源的一套主要面向移动应用开发的RPC框架。 相对于其他RPC框架而言，它有两个显著的特点：基于HTTP/2协议标准设计移动网络高延迟，低带宽，高丢包率的状态，使得我们需要进行大量的网络调优。而HTTP 1.1的一些特性使得它并不能很好的适应移动网络，一方面使用文本协议和无法复用HTTP头使得HTTP 1.1的流量消耗较大，另一方面HTTP 1.1的请求是有序堵塞的，使得head-of-line blocking问题十分严重，即使采用多连接和pipelining效果仍有限。但HTTP/2则可以用比较有效解决这些问题:采用二进制协议，完全多路复用，报头压缩，更能主动推送消息到客户端。强大的IDL特性默认情况下，gRPC使用protobuf作为IDL(Interface Definition Language)来定义服务（当然也可以使用json等）：给定相应服务的.proto文件，gRPC可以通过插件生成相应的客户端和服务器调用过程代码，使得客户端和服务器不再需要关心具体的请求装配，收发，解析过程，而更专注于相应的业务逻辑。使用gRPC作为RPC框架的典型开发流程如下后端定义服务，生成.proto文件后端通过插件生成服务器接 ...继续阅读 (11)

前言Unit test is like teenage sex: everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it。 (所以说，你们都没做过么？)单元测试的困境单元测试在实际工作无法推进的原因，无外乎以下两点：缺乏实施动力和缺少实战经验。动力的缺乏往往是因为对事物的理解不够彻底。举例来说，我们从来不会怀疑写代码的 80/20 原则，即需要使用 80% 的时间思考，用 20% 的时间进行真正的编码工作，这一点对于绝大多数程序员来说都是不言而喻的真理。但是对于单元测试，哪怕是科班出身的程序员都会质疑：在开发如此紧张的状态下，真的有必要去投入很大一块精力去进行单元测试么，投入产出比真的有这么大么？另一方面更加重要的原因是，即使是多年的开发工程师（尤其是前端开发）在国内这种环境熏陶下，极度缺乏单元测试经验，使得他们往往无法有效构建一个合理的单元测试环境，使得单元测试变成一种安慰剂，而不是真正起到它所应该起到的作用。试想一下，你学习 iOS，网上有各种各样的教程教你从入门到精通，从网络到动画，多维度多层次的教程帮你提升，而一到单元测试这一方向，就只有最初级的测试框架简 ...继续阅读 (11)

源起在移动 IM 模块中，最核心最复杂的模块莫过于登录模块。一个没有经过很好优化的登录模块往往耗时久且浪费流量：一次登录短则数十秒，长则几分钟，同时同步下几百 KB 甚至几 M 的数据。一个简单的登录步骤可以分为如下几步请求 lbs连接 link收发登录请求同步 IM 数据而这里的每一步都是有优化的可能性。(事实上下面的很多思路都是普适的，别不是只有 IM APP 才用得到)优化 lbs 请求在 PC 时代，我们往往将请求 lbs 和连接服务器做一个串联，毕竟只有先请求完毕 lbs 才能够拿到真正的 link 服务器地址，从而进行连接操作。在具体操作上，一般 lbs 请求就是一次 HTTP 请求，这里的耗时可想而知。所以一个朴素的优化想法就是从登录流程中移除这个环节。然而直接粗暴去除 lbs 请求并不可取，如果我们直接内置域名或 ip，带来最大问题自然是无法做负载均衡。所以更推荐将 lbs 请求异步化：不在登录时做 lbs 请求，而在网络空闲和发生变化时进行请求并缓存，每次登录则直接从本地缓存获取 link 地址。DNS 优化使用 TCP 时不可避免会碰到 DNS 解析的问题，毕竟我们不可能一直使用 IP 作为服务器地址。在 PC 时代，DNS 解析几乎不费事。但进入无线时代后，DNS 相关问题越来越严重。一方面，在移动网络下，DNS 解析速度无比龟速，一次 DNS 解析的时间甚至 ...继续阅读 (48)

源起在移动 IM 模块中，最核心最复杂的模块莫过于登录模块。一个没有经过很好优化的登录模块往往耗时久且浪费流量：一次登录短则数十秒，长则几分钟，同时同步下几百 KB 甚至几 M 的数据。一个简单的登录步骤可以分为如下几步请求 lbs连接 link收发登录请求同步 IM 数据而这里的每一步都是有优化的可能性。(事实上下面的很多思路都是普适的，别不是只有 IM APP 才用得到)优化 lbs 请求在 PC 时代，我们往往将请求 lbs 和连接服务器做一个串联，毕竟只有先请求完毕 lbs 才能够拿到真正的 link 服务器地址，从而进行连接操作。在具体操作上，一般 lbs 请求就是一次 HTTP 请求，这里的耗时可想而知。所以一个朴素的优化想法就是从登录流程中移除这个环节。然而直接粗暴去除 lbs 请求并不可取，如果我们直接内置域名或 ip，带来最大问题自然是无法做负载均衡。所以更推荐将 lbs 请求异步化：不在登录时做 lbs 请求，而在网络空闲和发生变化时进行请求并缓存，每次登录则直接从本地缓存获取 link 地址。DNS 优化使用 TCP 时不可避免会碰到 DNS 解析的问题，毕竟我们不可能一直使用 IP 作为服务器地址。在 PC 时代，DNS 解析几乎不费事。但进入无线时代后，DNS 相关问题越来越严重。一方面，在移动网络下，DNS 解析速度无比龟速，一次 DNS 解析的时间甚至 ...继续阅读 (20)

源起在移动 IM 模块中，最核心最复杂的模块莫过于登录模块。一个没有经过很好优化的登录模块往往耗时久且浪费流量：一次登录短则数十秒，长则几分钟，同时同步下几百 KB 甚至几 M 的数据。一个简单的登录步骤可以分为如下几步请求 lbs连接 link收发登录请求同步 IM 数据而这里的每一步都是有优化的可能性。(事实上下面的很多思路都是普适的，别不是只有 IM APP 才用得到)优化 lbs 请求在 PC 时代，我们往往将请求 lbs 和连接服务器做一个串联，毕竟只有先请求完毕 lbs 才能够拿到真正的 link 服务器地址，从而进行连接操作。在具体操作上，一般 lbs 请求就是一次 HTTP 请求，这里的耗时可想而知。所以一个朴素的优化想法就是从登录流程中移除这个环节。然而直接粗暴去除 lbs 请求并不可取，如果我们直接内置域名或 ip，带来最大问题自然是无法做负载均衡。所以更推荐将 lbs 请求异步化：不在登录时做 lbs 请求，而在网络空闲和发生变化时进行请求并缓存，每次登录则直接从本地缓存获取 link 地址。DNS 优化使用 TCP 时不可避免会碰到 DNS 解析的问题，毕竟我们不可能一直使用 IP 作为服务器地址。在 PC 时代，DNS 解析几乎不费事。但进入无线时代后，DNS 相关问题越来越严重。一方面，在移动网络下，DNS 解析速度无比龟速，一次 DNS 解析的时间甚至 ...继续阅读 (6)

源起做云信一年多以来，每隔两星期会兼职一次技术支持，回答客户的各种问题。也经常会碰到些较真的技术人员询问技术细节，如云信如何做心跳，如何保证消息必达，如何加快文件上传等。因为接客量巨大(臣妾忙不过来啊)，往往只能简略介绍，并不能具体展开，于是决定写成博客，也有了移动 IM 问题详解系列。WHAT在使用 TCP 长连接的 IM 服务设计中，往往都会涉及到心跳。心跳一般是指某端(绝大多数情况下是客户端)每隔一定时间向对端发送自定义指令，以判断双方是否存活，因其按照一定间隔发送，类似于心跳，故被称为心跳指令。WHY那么问题就随之而来了：为什么需要在应用层做心跳，难道 TCP 不是个可靠连接吗？我们不能够依赖 TCP 做断线检测吗？比如使用 TCP 的 KeepAlive 机制来实现。应用层心跳是目前的最佳实践吗？怎么样的心跳才是最佳实践。好吧，是不是以前从来没有仔细考虑过这些问题，仅仅只是个简单的心跳而已啊！(一脸懵逼)对于客户端而言，使用 TCP 长连接来实现业务的最大驱动力在于：在当前连接可用的情况下，每一次请求都只是简单的数据发送和接受，免去了 DNS 解析，连接建立等时间，大大加快了请求的速度，同时也有利于接受服务器的实时消息。但前提是连接可用。如果连接无法很好地保持，每次请求就会变成撞大运：运气好，通过长连接发送请求并收到反馈。运气差，当前连接已失效，请求迟迟没有收到反馈直到超 ...继续阅读 (74)

源起做云信一年多以来，每隔两星期会兼职一次技术支持，回答客户的各种问题。也经常会碰到些较真的技术人员询问技术细节，如云信如何做心跳，如何保证消息必达，如何加快文件上传等。因为接客量巨大(臣妾忙不过来啊)，往往只能简略介绍，并不能具体展开，于是决定写成博客，也有了移动 IM 问题详解系列。WHAT在使用 TCP 长连接的 IM 服务设计中，往往都会涉及到心跳。心跳一般是指某端(绝大多数情况下是客户端)每隔一定时间向对端发送自定义指令，以判断双方是否存活，因其按照一定间隔发送，类似于心跳，故被称为心跳指令。WHY那么问题就随之而来了：为什么需要在应用层做心跳，难道 TCP 不是个可靠连接吗？我们不能够依赖 TCP 做断线检测吗？比如使用 TCP 的 KeepAlive 机制来实现。应用层心跳是目前的最佳实践吗？怎么样的心跳才是最佳实践。好吧，是不是以前从来没有仔细考虑过这些问题，仅仅只是个简单的心跳而已啊！(一脸懵逼)对于客户端而言，使用 TCP 长连接来实现业务的最大驱动力在于：在当前连接可用的情况下，每一次请求都只是简单的数据发送和接受，免去了 DNS 解析，连接建立等时间，大大加快了请求的速度，同时也有利于接受服务器的实时消息。但前提是连接可用。如果连接无法很好地保持，每次请求就会变成撞大运：运气好，通过长连接发送请求并收到反馈。运气差，当前连接已失效，请求迟迟没有收到反馈直到超 ...继续阅读 (30)

源起做云信一年多以来，每隔两星期会兼职一次技术支持，回答客户的各种问题。也经常会碰到些较真的技术人员询问技术细节，如云信如何做心跳，如何保证消息必达，如何加快文件上传等。因为接客量巨大(臣妾忙不过来啊)，往往只能简略介绍，并不能具体展开，于是决定写成博客，也有了移动 IM 问题详解系列。WHAT在使用 TCP 长连接的 IM 服务设计中，往往都会涉及到心跳。心跳一般是指某端(绝大多数情况下是客户端)每隔一定时间向对端发送自定义指令，以判断双方是否存活，因其按照一定间隔发送，类似于心跳，故被称为心跳指令。WHY那么问题就随之而来了：为什么需要在应用层做心跳，难道 TCP 不是个可靠连接吗？我们不能够依赖 TCP 做断线检测吗？比如使用 TCP 的 KeepAlive 机制来实现。应用层心跳是目前的最佳实践吗？怎么样的心跳才是最佳实践。好吧，是不是以前从来没有仔细考虑过这些问题，仅仅只是个简单的心跳而已啊！(一脸懵逼)对于客户端而言，使用 TCP 长连接来实现业务的最大驱动力在于：在当前连接可用的情况下，每一次请求都只是简单的数据发送和接受，免去了 DNS 解析，连接建立等时间，大大加快了请求的速度，同时也有利于接受服务器的实时消息。但前提是连接可用。如果连接无法很好地保持，每次请求就会变成撞大运：运气好，通过长连接发送请求并收到反馈。运气差，当前连接已失效，请求迟迟没有收到反馈直到超 ...继续阅读 (6)

早上去爱康国宾做了次体检，不出意料的继续是轻度脂肪肝，体重也超过了70公斤大关，不得不感慨荒废跑步带来的影响还是巨大的，翻翻Nike+，记录惨不忍睹：几乎没有一个月的跑步量超过20公里。索性看书这事并没有荒废，2015年还是看了不少好书，值得一记。《异类》这本书可以被称为2015年对我影响最大的一本书，书中的各种观念都是直接刷三观。仅仅花了两个晚上就读完了这本书，获益匪浅：环境和机遇对人生的影响往往大大超过我们的预想。《人类简史 从动物到上帝》一本介绍人类历史的书，很多角度都非常新颖，比如决定智人成功的最大原因并不是智力因素而是八卦的才能。唯一不对我胃口的叙述略微拖沓，导致我花了很长时间才读完这本书。《编码：隐匿在计算机软硬件背后的语言》客观地讲这是一本比较有趣的书，从二进制开始介绍了计算机的原理，某些段落读起来很是有趣。但是对于我而言等于是复习了一次计算机组成原理而已。《程序员的呐喊》好吧，现在我已经几乎完全忘记书里的内容，由多篇吐槽文组成，有趣，但又仅止于有趣而已。《当我跑步时 我谈些什么》村上春树的书，从这书中获取了无数次跑步的动力，然而我跑得最扎实的一个月的成绩(100公里)也仅是村上春数一个星期的运动量而已，无比惭愧。《iOS应用逆向工具》一本关于越狱逆向的书，然而我早已过了那个爱折腾的年龄，更多的时候是把它当成一本工具书，而网上有更详细的教程，这本书的意义并不大。《阿弥 ...继续阅读 (22)

早上去爱康国宾做了次体检，不出意料的继续是轻度脂肪肝，体重也超过了70公斤大关，不得不感慨荒废跑步带来的影响还是巨大的，翻翻Nike+，记录惨不忍睹：几乎没有一个月的跑步量超过20公里。索性看书这事并没有荒废，2015年还是看了不少好书，值得一记。《异类》这本书可以被称为2015年对我影响最大的一本书，书中的各种观念都是直接刷三观。仅仅花了两个晚上就读完了这本书，获益匪浅：环境和机遇对人生的影响往往大大超过我们的预想。《人类简史 从动物到上帝》一本介绍人类历史的书，很多角度都非常新颖，比如决定智人成功的最大原因并不是智力因素而是八卦的才能。唯一不对我胃口的叙述略微拖沓，导致我花了很长时间才读完这本书。《编码：隐匿在计算机软硬件背后的语言》客观地讲这是一本比较有趣的书，从二进制开始介绍了计算机的原理，某些段落读起来很是有趣。但是对于我而言等于是复习了一次计算机组成原理而已。《程序员的呐喊》好吧，现在我已经几乎完全忘记书里的内容，由多篇吐槽文组成，有趣，但又仅止于有趣而已。《当我跑步时 我谈些什么》村上春树的书，从这书中获取了无数次跑步的动力，然而我跑得最扎实的一个月的成绩(100公里)也仅是村上春数一个星期的运动量而已，无比惭愧。《iOS应用逆向工具》一本关于越狱逆向的书，然而我早已过了那个爱折腾的年龄，更多的时候是把它当成一本工具书，而网上有更详细的教程，这本书的意义并不大。《阿弥 ...继续阅读 (29)

早上去爱康国宾做了次体检，不出意料的继续是轻度脂肪肝，体重也超过了70公斤大关，不得不感慨荒废跑步带来的影响还是巨大的，翻翻Nike+，记录惨不忍睹：几乎没有一个月的跑步量超过20公里。索性看书这事并没有荒废，2015年还是看了不少好书，值得一记。《异类》这本书可以被称为2015年对我影响最大的一本书，书中的各种观念都是直接刷三观。仅仅花了两个晚上就读完了这本书，获益匪浅：环境和机遇对人生的影响往往大大超过我们的预想。《人类简史 从动物到上帝》一本介绍人类历史的书，很多角度都非常新颖，比如决定智人成功的最大原因并不是智力因素而是八卦的才能。唯一不对我胃口的叙述略微拖沓，导致我花了很长时间才读完这本书。《编码：隐匿在计算机软硬件背后的语言》客观地讲这是一本比较有趣的书，从二进制开始介绍了计算机的原理，某些段落读起来很是有趣。但是对于我而言等于是复习了一次计算机组成原理而已。《程序员的呐喊》好吧，现在我已经几乎完全忘记书里的内容，由多篇吐槽文组成，有趣，但又仅止于有趣而已。《当我跑步时 我谈些什么》村上春树的书，从这书中获取了无数次跑步的动力，然而我跑得最扎实的一个月的成绩(100公里)也仅是村上春数一个星期的运动量而已，无比惭愧。《iOS应用逆向工具》一本关于越狱逆向的书，然而我早已过了那个爱折腾的年龄，更多的时候是把它当成一本工具书，而网上有更详细的教程，这本书的意义并不大。《阿弥 ...继续阅读 (7)

最近做了一个截图拼接的小玩具，实现聊天记录/朋友圈截图的自动拼接，感觉还是比较有趣，所以记上一笔和大家分享。缘起经常有这样的场景：需要将微信的聊天记录/网页转发给其他人，内容很长，所以不得不一段一段地截图发送，麻烦又常有乱序送达的情况发生。于是在 App Store 上找了款自动拼接截图的 App (截图拼接)，很是好用，却有一天只能保存一次的限制。于是自己写了一个玩，花了一天写算法验证可行性，又花了一天将界面和流程整理好，比那个 App 快上数倍，很是满足。不过想想 2 天的工资怎么也超过那个 App 的价格了...实现要实现两张截图的自动拼接，首要问题是找到它们的重复内容。简单粗暴的想法就是对两张图片进行逐行扫描并比较每一行的像素点以确定当前行是否匹配，然后找出连续匹配的最大行数即可。但简单推演一下，iPhone 6 的截图分辨率为750 * 1334,进行上述操作至少需要上万亿的匹配，计算量和效率可想而知。所以需要些小技巧减少计算量。提取图片指纹对于判断图片任意两行是否一致来说，行内每个像素点信息其实并没有什么意义，我们更关注的是整行的数据信息。一张宽为 750 的图片，每行都有 3KB 字节数据，逐一比对显然数据量过大。所以第一步就是将行数据进行"压缩"，用比较高大上的词来说就是“提取图片指纹”。最简单的方式是计算这一片数据的 MD5。这种方式既可以将 ...继续阅读 (26)

最近做了一个截图拼接的小玩具，实现聊天记录/朋友圈截图的自动拼接，感觉还是比较有趣，所以记上一笔和大家分享。缘起经常有这样的场景：需要将微信的聊天记录/网页转发给其他人，内容很长，所以不得不一段一段地截图发送，麻烦又常有乱序送达的情况发生。于是在 App Store 上找了款自动拼接截图的 App (截图拼接)，很是好用，却有一天只能保存一次的限制。于是自己写了一个玩，花了一天写算法验证可行性，又花了一天将界面和流程整理好，比那个 App 快上数倍，很是满足。不过想想 2 天的工资怎么也超过那个 App 的价格了…实现要实现两张截图的自动拼接，首要问题是找到它们的重复内容。简单粗暴的想法就是对两张图片进行逐行扫描并比较每一行的像素点以确定当前行是否匹配，然后找出连续匹配的最大行数即可。但简单推演一下，iPhone 6 的截图分辨率为750 * 1334,进行上述操作至少需要上万亿的匹配，计算量和效率可想而知。所以需要些小技巧减少计算量。提取图片指纹对于判断图片任意两行是否一致来说，行内每个像素点信息其实并没有什么意义，我们更关注的是整行的数据信息。一张宽为 750 的图片，每行都有 3KB 字节数据，逐一比对显然数据量过大。所以第一步就是将行数据进行”压缩”，用比较高大上的词来说就是“提取图片指纹”。最简单的方式是计算这一片数据的 MD5。这种方式既可以将 3KB 的数据压缩至几十 ...继续阅读 (15)

最近做了一个截图拼接的小玩具，实现聊天记录/朋友圈截图的自动拼接，感觉还是比较有趣，所以记上一笔和大家分享。缘起经常有这样的场景：需要将微信的聊天记录/网页转发给其他人，内容很长，所以不得不一段一段地截图发送，麻烦又常有乱序送达的情况发生。于是在 App Store 上找了款自动拼接截图的 App (截图拼接)，很是好用，却有一天只能保存一次的限制。于是自己写了一个玩，花了一天写算法验证可行性，又花了一天将界面和流程整理好，比那个 App 快上数倍，很是满足。不过想想 2 天的工资怎么也超过那个 App 的价格了…实现要实现两张截图的自动拼接，首要问题是找到它们的重复内容。简单粗暴的想法就是对两张图片进行逐行扫描并比较每一行的像素点以确定当前行是否匹配，然后找出连续匹配的最大行数即可。但简单推演一下，iPhone 6 的截图分辨率为750 * 1334,进行上述操作至少需要上万亿的匹配，计算量和效率可想而知。所以需要些小技巧减少计算量。提取图片指纹对于判断图片任意两行是否一致来说，行内每个像素点信息其实并没有什么意义，我们更关注的是整行的数据信息。一张宽为 750 的图片，每行都有 3KB 字节数据，逐一比对显然数据量过大。所以第一步就是将行数据进行”压缩”，用比较高大上的词来说就是“提取图片指纹”。最简单的方式是计算这一片数据的 MD5。这种方式既可以将 3KB 的数据压缩至几十 ...继续阅读 (8)

最近在做一个iOS IM SDK，内测版已出炉，详见http://netease.im。在内部试用的阶段，不断有兄弟部门童鞋和合作伙伴过来问各种技术细节，所以写一篇文章记录，统一介绍下一个IM APP的方方面面，包括技术选型(包括通讯方式,网络连接方式,协议选择)和常见问题。通讯方式选择IM通讯方式无非两种选择:设备直连(P2P)和通过服务器中转。P2PP2P多见于局域网内聊天工具，典型的应用有:飞鸽传书，天网Maze(你懂的)等。这类软件在启动后一般做两件事情进行UDP广播:发送自己信息和接受同局域网内其他端信息开启TCP监听:等待其他端进行连接详细的流程可以参考飞鸽传书源码。但是这种方式在有种种限制和不便:一方面它只适合在线的点对点消息传输，对离线，群组等业务支持不够。另一方面由于NAT的存在，使得不同局域网内机器互联难度大大上升，在某些网络类型(对称NAT)下无法建立连接。服务器中转几乎所有互联网IM产品都采用服务器中转这种方式进行消息传输，相对于P2P的方式，它有如下的优点:能够支持更多P2P无法支持或支持不好的业务，如离线消息，群组，聊天室服务方便业务逻辑的拓展和新旧版本的兼容当然它也有自己的问题:服务器架构复杂，并发要求高。网络连接方式IM主流网络连接方式有两种:基于TCP的长连接基于HTTP短连接PULL的方式后者常见于WEB IM系统(当然现在很多WEB IM都是基 ...继续阅读 (52)

最近在做一个iOS IM SDK，内测版已出炉，详见http://netease.im。在内部试用的阶段，不断有兄弟部门童鞋和合作伙伴过来问各种技术细节，所以写一篇文章记录，统一介绍下一个IM APP的方方面面，包括技术选型(包括通讯方式,网络连接方式,协议选择)和常见问题。通讯方式选择IM通讯方式无非两种选择:设备直连(P2P)和通过服务器中转。P2PP2P 多见于局域网内聊天工具，典型的应用有:飞鸽传书，天网 Maze (你懂的)等。这类软件在启动后一般做两件事情进行 UD P广播:发送自己信息和接受同局域网内其他端信息开启 TCP 监听:等待其他端进行连接详细的流程可以参考飞鸽传书源码。但是这种方式在有种种限制和不便:一方面它只适合在线的点对点消息传输，对离线，群组等业务支持不够。另一方面由于NAT的存在，使得不同局域网内机器互联难度大大上升，在某些网络类型(对称NAT)下无法建立连接。服务器中转几乎所有互联网IM产品都采用服务器中转这种方式进行消息传输，相对于 P2P 的方式，它有如下的优点:能够支持更多 P2P 无法支持或支持不好的业务，如离线消息，群组，聊天室服务方便业务逻辑的拓展和新旧版本的兼容当然它也有自己的问题:服务器架构复杂，并发要求高。网络连接方式IM 主流网络连接方式有两种:基于 TCP 的长连接基于 HTTP 短连接 PULL 的方式后者常见于 WEB I ...继续阅读 (4)

最近在做一个iOS IM SDK，内测版已出炉，详见http://netease.im。在内部试用的阶段，不断有兄弟部门童鞋和合作伙伴过来问各种技术细节，所以写一篇文章记录，统一介绍下一个IM APP的方方面面，包括技术选型(包括通讯方式,网络连接方式,协议选择)和常见问题。通讯方式选择IM通讯方式无非两种选择:设备直连(P2P)和通过服务器中转。P2PP2P多见于局域网内聊天工具，典型的应用有:飞鸽传书，天网Maze(你懂的)等。这类软件在启动后一般做两件事情进行UDP广播:发送自己信息和接受同局域网内其他端信息开启TCP监听:等待其他端进行连接详细的流程可以参考飞鸽传书源码。但是这种方式在有种种限制和不便:一方面它只适合在线的点对点消息传输，对离线，群组等业务支持不够。另一方面由于NAT的存在，使得不同局域网内机器互联难度大大上升，在某些网络类型(对称NAT)下无法建立连接。服务器中转几乎所有互联网IM产品都采用服务器中转这种方式进行消息传输，相对于P2P的方式，它有如下的优点:能够支持更多P2P无法支持或支持不好的业务，如离线消息，群组，聊天室服务方便业务逻辑的拓展和新旧版本的兼容当然它也有自己的问题:服务器架构复杂，并发要求高。网络连接方式IM主流网络连接方式有两种:基于TCP的长连接基于HTTP短连接PULL的方式后者常见于WEB IM系统(当然现在很多WEB IM都是基 ...继续阅读 (11)

最近在做一个iOS IM SDK，内测版已出炉，详见http://netease.im。在内部试用的阶段，不断有兄弟部门童鞋和合作伙伴过来问各种技术细节，所以写一篇文章记录，统一介绍下一个IM APP的方方面面，包括技术选型(包括通讯方式,网络连接方式,协议选择)和常见问题。通讯方式选择IM通讯方式无非两种选择:设备直连(P2P)和通过服务器中转。P2PP2P多见于局域网内聊天工具，典型的应用有:飞鸽传书，天网Maze(你懂的)等。这类软件在启动后一般做两件事情进行UDP广播:发送自己信息和接受同局域网内其他端信息开启TCP监听:等待其他端进行连接详细的流程可以参考飞鸽传书源码。但是这种方式在有种种限制和不便:一方面它只适合在线的点对点消息传输，对离线，群组等业务支持不够。另一方面由于NAT的存在，使得不同局域网内机器互联难度大大上升，在某些网络类型(对称NAT)下无法建立连接。服务器中转几乎所有互联网IM产品都采用服务器中转这种方式进行消息传输，相对于P2P的方式，它有如下的优点:能够支持更多P2P无法支持或支持不好的业务，如离线消息，群组，聊天室服务方便业务逻辑的拓展和新旧版本的兼容当然它也有自己的问题:服务器架构复杂，并发要求高。网络连接方式IM主流网络连接方式有两种:基于TCP的长连接基于HTTP短连接PULL的方式后者常见于WEB IM系统(当然现在很多WEB IM都是基 ...继续阅读 (7)

最近用AFNetworking替换掉了工程里的ASIHttpRequest，结果陆续碰到很多问题：如何统一地添加全局的HTTP头(不仅仅是UA而已)如何优雅地进行流量统计对特定的地址进行CDN加速(URL到IP的替换)怎么实现HTTP的同步请求前三个需求对于ASIHttpReqeust来说都不是问题，只需要在几个统一的点进行修改即可。而使用AFNetworking后就没有那么容易了：一方面AFNetworking中生成NSURLRequest的点比较多，并没有一个统一的路径。其次工程中会有部分直接使用NSURLConnecion的场景，无法统一。经cyzju提醒发现了NSURLProtocol这个大杀器，可惜对应的文档过于简略，唯一比较详细的介绍就只有RW的这篇教程而已，掉了很多坑，值得记上一笔。NSURLProtocol概念NSURLProtocol也是苹果众多黑魔法中的一种，使用它可以轻松地重定义整个URL Loading System。当你注册自定义NSURLProtocol后，就有机会对所有的请求进行统一的处理，基于这一点它可以让你自定义请求和响应提供自定义的全局缓存支持重定向网络请求提供HTTP Mocking (方便前期测试)其他一些全局的网络请求修改需求使用方法继承NSURLPorotocl，并注册你的NSURLProtocol[NSURLProtocolregist ...继续阅读 (80)

最近用 AFNetworking 替换掉了工程里的 ASIHttpRequest，结果陆续碰到很多问题：如何统一地添加全局的 HTTP 头(不仅仅是 UA 而已)如何优雅地进行流量统计对特定的地址进行 CDN 加速( URL 到 IP 的替换)怎么实现 HTTP 的同步请求前三个需求对于 ASIHttpReqeust 来说都不是问题，只需要在几个统一的点进行修改即可。而使用 AFNetworking 后就没有那么容易了：一方面 AFNetworking 中生成 NSURLRequest 的点比较多，并没有一个统一的路径。其次工程中会有部分直接使用 NSURLConnecion 的场景，无法统一。经cyzju提醒发现了 NSURLProtocol 这个大杀器，可惜对应的文档过于简略，唯一比较详细的介绍就只有RW的这篇教程而已，掉了很多坑，值得记上一笔。NSURLProtocol概念NSURLProtocol 也是苹果众多黑魔法中的一种，使用它可以轻松地重定义整个 URL Loading System。当你注册自定义 NSURLProtocol 后，就有机会对所有的请求进行统一的处理，基于这一点它可以让你自定义请求和响应提供自定义的全局缓存支持重定向网络请求提供 HTTP Mocking (方便前期测试)其他一些全局的网络请求修改需求使用方法继承 NSURLPorotocl，并注册你的 ...继续阅读 (4)

最近用AFNetworking替换掉了工程里的ASIHttpRequest，结果陆续碰到很多问题：如何统一地添加全局的HTTP头(不仅仅是UA而已)如何优雅地进行流量统计对特定的地址进行CDN加速(URL到IP的替换)怎么实现HTTP的同步请求前三个需求对于ASIHttpReqeust来说都不是问题，只需要在几个统一的点进行修改即可。而使用AFNetworking后就没有那么容易了：一方面AFNetworking中生成NSURLRequest的点比较多，并没有一个统一的路径。其次工程中会有部分直接使用NSURLConnecion的场景，无法统一。经cyzju提醒发现了NSURLProtocol这个大杀器，可惜对应的文档过于简略，唯一比较详细的介绍就只有RW的这篇教程而已，掉了很多坑，值得记上一笔。NSURLProtocol概念NSURLProtocol也是苹果众多黑魔法中的一种，使用它可以轻松地重定义整个URL Loading System。当你注册自定义NSURLProtocol后，就有机会对所有的请求进行统一的处理，基于这一点它可以让你自定义请求和响应提供自定义的全局缓存支持重定向网络请求提供HTTP Mocking (方便前期测试)其他一些全局的网络请求修改需求使用方法继承NSURLPorotocl，并注册你的NSURLProtocol[NSURLProtocolregist ...继续阅读 (16)

最近用AFNetworking替换掉了工程里的ASIHttpRequest，结果陆续碰到很多问题：如何统一地添加全局的HTTP头(不仅仅是UA而已)如何优雅地进行流量统计对特定的地址进行CDN加速(URL到IP的替换)怎么实现HTTP的同步请求前三个需求对于ASIHttpReqeust来说都不是问题，只需要在几个统一的点进行修改即可。而使用AFNetworking后就没有那么容易了：一方面AFNetworking中生成NSURLRequest的点比较多，并没有一个统一的路径。其次工程中会有部分直接使用NSURLConnecion的场景，无法统一。经cyzju提醒发现了NSURLProtocol这个大杀器，可惜对应的文档过于简略，唯一比较详细的介绍就只有RW的这篇教程而已，掉了很多坑，值得记上一笔。NSURLProtocol概念NSURLProtocol也是苹果众多黑魔法中的一种，使用它可以轻松地重定义整个URL Loading System。当你注册自定义NSURLProtocol后，就有机会对所有的请求进行统一的处理，基于这一点它可以让你自定义请求和响应提供自定义的全局缓存支持重定向网络请求提供HTTP Mocking (方便前期测试)其他一些全局的网络请求修改需求使用方法继承NSURLPorotocl，并注册你的NSURLProtocol[NSURLProtocolregist ...继续阅读 (6)

知乎上看到一个问题《一百行以下有那些给力代码》，几乎所有回答都是用100行实现的某个小功能，有趣归有趣，但对实际工作并没有什么帮助。翻了翻自己的M80Kit，里面也有些比较有趣且实用的辅助类都是一百行左右，可以拿出来秀下。M80MulticastDelegate一个从XMPP框架中抽离出来的类，提供同步的一对多delegate机制。在很多场景下，往往多个对象会依赖于某个核心对象。使用M80MulticastDelegate就能够很好地进行解耦：不需要定义过多正式的protocol或者notification进行通信。巧妙地利用OC的消息转发机制，当发一个不认识的消息给当前MulticaseDelegate时，它就会自动进行转发：遍历已注册的delegate node，找到能够响应当前selector的node并执行。@interfaceM80DelegateNode:NSObject@property(nonatomic,weak)idnodeDelegate;+(M80DelegateNode*)node:(id)delegate;@end@implementationM80DelegateNode+(M80DelegateNode*)node:(id)delegate{M80DelegateNode*instance=[[M80DelegateNodealloc]init];i ...继续阅读 (35)

知乎上看到一个问题《一百行以下有那些给力代码》，几乎所有回答都是用 100 行实现的某个小功能，有趣归有趣，但对实际工作并没有什么帮助。翻了翻自己的 M80Kit ，里面也有些比较有趣且实用的辅助类都是一百行左右，可以拿出来秀下。M80MulticastDelegate一个从 XMPP 框架中抽离出来的类，提供同步的一对多 delegate 机制。在很多场景下，往往多个对象会依赖于某个核心对象。使用 M80MulticastDelegate 就能够很好地进行解耦：不需要定义过多正式的protocol 或者 notification 进行通信。巧妙地利用 OC 的消息转发机制，当发一个不认识的消息给当前 MulticaseDelegate 时，它就会自动进行转发：遍历已注册的 delegate node，找到能够响应当前 selector 的 node 并执行。@interfaceM80DelegateNode:NSObject@property(nonatomic,weak)idnodeDelegate;+(M80DelegateNode*)node:(id)delegate;@end@implementationM80DelegateNode+(M80DelegateNode*)node:(id)delegate{M80DelegateNode*instance=[[M80Del ...继续阅读 (10)

知乎上看到一个问题《一百行以下有那些给力代码》，几乎所有回答都是用100行实现的某个小功能，有趣归有趣，但对实际工作并没有什么帮助。翻了翻自己的M80Kit，里面也有些比较有趣且实用的辅助类都是一百行左右，可以拿出来秀下。M80MulticastDelegate一个从XMPP框架中抽离出来的类，提供同步的一对多delegate机制。在很多场景下，往往多个对象会依赖于某个核心对象。使用M80MulticastDelegate就能够很好地进行解耦：不需要定义过多正式的protocol或者notification进行通信。巧妙地利用OC的消息转发机制，当发一个不认识的消息给当前MulticaseDelegate时，它就会自动进行转发：遍历已注册的delegate node，找到能够响应当前selector的node并执行。@interfaceM80DelegateNode:NSObject@property(nonatomic,weak)idnodeDelegate;+(M80DelegateNode*)node:(id)delegate;@end@implementationM80DelegateNode+(M80DelegateNode*)node:(id)delegate{M80DelegateNode*instance=[[M80DelegateNodealloc]init];i ...继续阅读 (20)

知乎上看到一个问题《一百行以下有那些给力代码》，几乎所有回答都是用100行实现的某个小功能，有趣归有趣，但对实际工作并没有什么帮助。翻了翻自己的M80Kit，里面也有些比较有趣且实用的辅助类都是一百行左右，可以拿出来秀下。M80MulticastDelegate一个从XMPP框架中抽离出来的类，提供同步的一对多delegate机制。在很多场景下，往往多个对象会依赖于某个核心对象。使用M80MulticastDelegate就能够很好地进行解耦：不需要定义过多正式的protocol或者notification进行通信。巧妙地利用OC的消息转发机制，当发一个不认识的消息给当前MulticaseDelegate时，它就会自动进行转发：遍历已注册的delegate node，找到能够响应当前selector的node并执行。@interfaceM80DelegateNode:NSObject@property(nonatomic,weak)idnodeDelegate;+(M80DelegateNode*)node:(id)delegate;@end@implementationM80DelegateNode+(M80DelegateNode*)node:(id)delegate{M80DelegateNode*instance=[[M80DelegateNodealloc]init];i ...继续阅读 (8)