tripleCC的技术博客

ʕ•̫͡•ʔ-̫͡-ʕ•͓͡•ʔ-̫͡-ʕ•̫͡•ʔ-̫͡-ʕ•͓͡•ʔ-̫͡-ʔ

让CocoaPods组件支持Carthage打包

虽说 CocoaPods 有 cocoapods-packager 这个插件可以生成二进制版本,但这个库的维护者似乎并不活跃,很多 issue 和 pr 过了一两年还堆积着没处理。于是我决定试试 Carthage ,不过不利用 Cartfile 生成依赖,还是用的 CocoaPods 那一套。

要让组件支持 Carthage ,工程里只需要有一个 shared framework target 即可。针对 CocoaPods 生成的工程,我们先在 Podfile 里面设置 use_frameworks! ,来满足 framework target

编写自己的cocoapods插件

经过对旧项目持续地拆分,组件库已经初具规模,组件粒度也变得越来越小,管理组件的成本也逐渐显现出来。目前团队采用的方式是,每个组件由特定的负责人进行管理,只有责任人才拥有 master 分支的访问权限,并且打 tag、发布组件版本都需要由负责人操作。

当一个特性涉及到的组件库不多时,直接在钉钉上通知相关负责人升级下组件版本即可,然后将各个组件的新版本重新写入 Podfile。刚开始我会查下负责人是谁,然后在群组里罗列他需要升级的组件。但是修改的组件一多就比较麻烦了,如果直接把涉及的所有组件名往群组里一扔,组员有时候也会看漏了。

于是我就有了下面的想法:
用脚本获取 Podfile 指向分支的组件名,然后去本地私有源获取组件的作者,再匹配本地存储的组员名,最后将负责人和所负责的组件发送到钉钉群组中。

组件化之组件生命周期管理

在没有实行组件化的项目中,经常会在 AppDelegate 看到各类初始化代码,这一部分代码一般用以配置某些 key 以及 secret ,或者开启某些服务,常见的有第三方推送、统计分析、IM服务等。当然,也有可能是开启一些自身的服务,比如 log 日志、 数据库初始化等。当一个 App 达到一定体量后, 未经整理的 AppDelegate 可能会变得臃肿。那么在实行组件化之后,该如何处理这部分代码呢?

C 表达式中 Float 精度提升问题

对于这个问题的思考,起源于云风的这篇文章 浮点运算潜在的结果不一致问题,其中有几个评论我比较在意:

1
2
3
4
5
6
7
8
9
10
11
12
13
stirp:
刚刚被小伙伴提示默认情况下float相乘是自动提升精度到double的,因此第一次输出就应该是对double取整的。

x87 浮点运算的效果是float相乘结果还是float么?本地不支持387,没法测试。

Cloud:

C 语言规范:表达式里最高精度是 float ,那么表达式的值精度就是 float 。没有相乘提升到 double 的说法。

第一个写成 (int)((float)(x * 0.01f)) 也是一样的,并不是对 double 取整的问题。

stirp:
多谢dwing,原来C89/90就已经不提升精度了。

用 Block 实现委托方法

Block 和 Delegate 是对象间传递消息的常用机制,这两个机制可以说是各有千秋。 Delegate 可以很方便把目标动作的执行过程划分为多个方法,以展现不同时间节点下特定的操作; Block 则擅长处理一个回调多个落点的情况,并且它可以通过捕捉上下文信息,来达到减少创建额外变量,集中消息处理逻辑的目的。

结合以上两种通信方式的特点,我们可以添加一些额外的桥接处理,让 Delegate 机制也能享有 Block 机制所拥有的部分优点。桥接处理的核心就是用 Block 实现委托方法。

Objective-C 消息转发应用场景摘录

说起 Objective-C runtime 在实际项目中的应用,可能很多人第一时间联想到的是黑魔法 method swizzling 、 associated objects 、 KVC / KVO 以及各种灵活的 runtime api 。这几种技术在开发过程中或多或少都会涉及到 ,也的确为开发者立下了汗马功劳,尤其在解决一些棘手问题时,屡试不爽。不过同样是 runtime 重要组成部分的消息转发却较少听人提及,这篇文章就来扒一扒它在不同应用场景中的精彩表现。

闲谈 IGListKit

IGListKit 是 Instagram 在 16 年出品的一款针对 UICollectionView 的数据驱动框架,旨在帮助开发者更加快速、灵活地构建列表页面。

现存的绝大部分 Objective-C 框架,在集成进 Swift 项目中后,编写的代码依然会透出一股浓浓的 Objective-C 味,总感觉不纯正。而 IGListKit 虽然使用 Objective-C/C++ 开发,但是很好地照顾到了日渐增多的 Swift 开发者,不仅提供了大量 Swift 编写的 Demo (绝大部份),而且在 3.0.0 版本之后去除了 IG 前缀,更好地兼容了现版本 Swift 简洁的代码风格。所以,不管是 Swift 项目,还是 Objective-C 项目,引入 IGListKit 都是个不错的选择, 一来方便分离业务代码以降低复杂度,再者可以更好地编写粒度更大的复用单元目的,更多好处,只能在使用中体验了。

CocoaPods和Localization

一直没有很好地理清 CocoaPods 对图片、NIB等资源的管理方式,趁着跟进 “智齿” 国际化失效问题,摘录下浏览的相关资料。另外吐槽下 “智齿”, 这家的 iOS SDK 是我目前集成的所有 SDK 中,对开发者最不友好的了。

问题来了:在使用 CocoaPods 集成“智齿”后,“智齿”的国际化信息就一直显示英文版本,即使系统语言设置成中文。但是如果不通过 CocoaPods,直接把 SDK 拉进工程中,国际化信息就又生效了。在咨询其开发人员无果后,只能自己慢慢排雷了。由于问题只在 “通过 CocoaPods 引入 SDK” 这种情况下出现,所以要想彻底解决这个问题,就需要明确 CocoaPods 是如何对国际化资源进行管理的。

玩玩逆向之拦截钉钉消息已读状态

流光容易把人抛,红了樱桃,绿了芭蕉

一个月前的某一天,百无聊赖的我在整理房间的时候,偶然翻开了一本积灰的“小黄书”,看到首页作者的赠语,眼前不禁浮现两年前,几经波折辗转到上海的我兴致勃勃勃勃地拜托小锅让他的直属老大狗神 (本书作者之一) ,给刚买的这本《iOS应用逆向工程》签名的场景,百味杂陈。说来惭愧,我一直都没有好好地看过这本书,等回过头来,不知不觉已经过去两年了。这篇文章致那个曾经那个能够静心看书的少年。