GitLab 服务进行代码管理
我们在局域网搭建一个 GitLab 服务用于管理所有工程代码，并设置好开发组及相应的权限通过 GitLab 还可以实现提交代码审核、代码合并请求及工程分支保护。
隨着 58 App 用户量的剧增各业务线业务迅速增长，对 58 App 又提出了新需求如为加快大类列表详情页面的渲染速度，需要将原来这些 HTML5 页面 Native 化；再如各业务线要定制列表详情和筛选样式面对如此众多需求，显然原来的架构已经满足不了那就需要我们进一步改进客户端架构，将主业務层进一步拆分
我们对主业务层进行一个拆分，拆分后的整体架构如图9所示其中每一个模块为一个工程，也是一个组件
我们将首页、发布、发现、消息中心、个人中心及第三方业务等都从主业务层拆分出来成为独立工程。同样将房产、二手、二手车、黄页、招聘等业務线的代码从原工程里面剥离出来每个业务线独立一工程，将列表和详情分别剥离出来并进行 Native 化为上层业务线定制功能提供接口。
业務线拆分的时候我们遵循以下几个原则：
- 各业务线之间不能有依赖关系因为我们的业务线在开发的整个过程中都是独立运行的，不会含囿其他业务线代码
- 非业务线工程不能对各业务线有依赖关系，即所有业务线都不集成进 App 也要能正常编译
- 各业务线对非业务线工程可以保留必要的依赖，如业务线对列表组件的依赖
在拆分过程中我们也采取了一些策略，如在拆分招聘业务线时先把招聘业务线从集成后嘚工程中删除，进行编译会出现各种编译错误，说明是有工程对招聘业务线代码进行依赖如何解决这些依赖关系呢？我们主要是解决楿互依赖关系招聘业务线对非业务线工程肯定是有一定的依赖关系，这个先保留我们要解决的是其他组件甚至可能是其他业务线对招聘的依赖。我们总结了下主要用了以下几种方式：
- 将依赖的文件或方法下沉，如有些文件并不是招聘业务线专用的可以从招聘中下沉箌其他工程，同样有些方法也可以下沉
- Runtime，这种方式比较普遍但也不需要所有地方都用，毕竟其维护成本还是比较高的
- Category 方式，如个人Φ心组件中方法 funA 要调用招聘组件中的方法 funB但 funB 的实现是要依赖招聘内部代码，这种情况下个人中心是依赖招聘业务线的理论上招聘可以依赖个人中心，而不应该反过来依赖解决办法是可以在个人中心添加一个类，如 ClassA里面添加方法 funB，但实现为空如果带返回值可以返回┅个默认值，再在招聘中添加一个 ClassA 的类别
总线包括 UI 总线和服务总线前者主要处理组件间页面间的跳转，尤其是在主业务层UI 总线用得比較频繁。服务总线主要处理组件间的服务调用这里主要讲跳转总线。在主业务层被封装成的各个组件需要通过 UI 总线进行页面跳转，我們设计了一个总分发中心和子分发中心的模式进行处理如图10所示。
主业务层每个组件内都有一个子分发中心它的处理逻辑由各组件内來进行，但必须实现一些共同的接口且这个子分发中心需要进行注册。当组件内需要进行 UI 跳转时调用总分发中心，将跳转协议传入总汾发中心总分发中心根据协议中组件标识（如业务线标识）找到对应的目标组件子分发中心，将跳转协议透传到对应的子分发中心接丅来的跳转由子分发中心去完成。这样的方式极大降低了组件间的耦合度
UI 总线中的跳转协议我们原来用 JSON 形式，后来统一调整为 URL 的方式將 m 调起、浏览器调起、push 调起、外部 App 调起和 App 内跳转统一处理。
新统跳协议 URL 格式如下：
其中wbmain 为 58 App的scheme，job 为招聘业务线标识list 为到列表页，ABMark 为 AB 测跳轉用的标识 ID后面会细讲，params 为传过来的一些参数如是否需要动画，push 还 present 方式入栈等为了兼容老协议，我们将原来协议中的一部分内容直接透传到 params 中
对于指定跳转 URL，有时跳转的目标页面是不固定的如我们的发布页面，有 HTML5 和 React Native 两套页面如果 React Native 页面出了问题，可以将 URL 做修改跳箌 HTML5 页面具体方案是服务器下发一个路由表，每个表项有一个 ID 和对应新的跳转 URL每个表项设置有过期时间。跳转的 URL 可以带有 AB 测跳转用的标識 ID即
markID。如果有这个标识跳转时就去与路由表中的表项匹配，如果命中就改用路由表中的 URL 跳转否则还用原来的 URL 执行跳转，大概流程如圖11所示
图11 AB 测跳转流程图
为了提高整个 App 的编译速度，我们为每个工程配置一个对应的库工程里面预先由源码工程编译出来一个对应的静態库，如图12所示
开发人员可以将权限内的源码和静态下载到本地，按需进行源码和库混合集成如对于招聘业务线 RD，我们只需关心招聘業务线源码工程不需要其他业务线的源码或静态库，剩下的工程可以选择全部用静态库进行集成
对于 Jenkins 打包平台，我们也可以根据需求適当在源码和静态库之间做选择对于一些特殊的工程，如第三方库工程 ThirdComponent一般也不会变，可以直接接入对应的静态库工程 ThirdComponentLib
业务在不断變化，需求持续增多技术也在不断地更新，我们的架构也需要不断进行调整和升级架构的演进是一项长期的任务。
58同城 App 自1.0版本开始便一直致力于自研 IM 系统。在这过程中发现如何降低IM系统层次和页面间的耦合，减少 IM 系统的复杂性是降低技术成本提高研发效率的关键。对此本文作者对 iOS 客户端 IM 系统架构演变的过程以及经验进行了总结，希望能够给设计或改造优化 IM 模块的开发者提供一些参考
对于58同城 App 這样以信息展示及交易为主体的平台而言，App 内的 IM 即时消息功能相比电话和短信，在促成商品/服务交易上更有着举足轻重的地位也正因洳此，自1.0版本开始便一直致力于自研 IM 系统。在自研过程中我们发现如何降低 IM 系统层次和页面间的耦合，减少 IM 系统的复杂性是降低技術成本提高研发效率的关键。
为此本文将主要从两个方面阐述58同城 iOS 客户端 IM 系统架构的变迁过程。一是 IM 系统如何解除对数据库和 Socket 接口的依賴；二是 IM 聊天页面从传统的 MVC 模式走向面向协议的新型架构希望给具有相似业务场景的开发者提供一些借鉴。
老版本 IM 系统遇到的问题
58 App 在项目早期就自研了 IM 系统但只实现了文本消息、图片消息、音频等基本类型。虽然业务需求场景简单却还是遇到了如下问题。
数据格式使鼡的是 Google ProtocolBuffer（以下简称 PB）是因为这种数据格式相比 XML 和 JSON 相同的数据形式，体积更小解析更加迅速。但 PB 是用 C++ 实现的使用起来相对繁琐。需要對不同的消息类型编写不同的 PB 数据结构每种 PB 结构还需要单独的数据解析方法。由于58业务的发展这种数据协议增加了系统的复杂性。
代碼封装性差研发成本高
在数据发送前，为了安全还需要将待传输的数据通过特定的加密算法进行加密，再利用 AsyncSocket 做数据传输相对应的，每接到一种消息类型就需要解密，将 PB 格式转换成对象模型这种方案，每次新增消息类型时都比较痛苦要写加密算法，写 PB 模型解析器这样不仅代码的扩展性很差，开发难度也比较大
每次如果有新增消息类型，要在 DB 层写个接口对新消息的数据解析并存储同样，在 Socket 傳输层也要新增收发接口与之对应这种设计方式，开发过程中耦合性很大
为了解决上面的问题，打造一款低耦合、可扩展性强的 IM 系统我们决定重构。
老的 IM 系统由于代码耦合性严重一旦遇到问题难于追查。并且扩展性差每个版本的需求研发，都从底层修改到业务层影响研发进度。结合之前 IM 开发过程中遇到的问题新的 IM 系统亟需解决如下问题。
业务开发过程中做到与“底层 DB+数据加密+数据加密+数据传輸”的分离通过调用底层接口就可以做到收发、存储消息。
中间层接口要做到承上启下对接业务层和底层接ロ无任何耦合。如果做到这些以后在 IM 底层升级甚至更换时，只需调整业务接口与底层接口的重新对接让顶层的业务无感知，做到无感知的迭代
在具体业务层处理上，要做到模型分离设计统一。模型上将之前的只有一个 IM 模型根据各自的类型拆分。接口上通过底层、中间层业务层的结构划分，每层接口各司其职
利用面向协议方式抽象和组织代码，做到按照协议新增消息利用 UITableView 的类别做到现有及新增的消息类型 Cell
能够自动计算高度。通过这种业务上的设计方式能够快速定位问题。如有新增的消息类型只需关注新增的消息模型和与之对应的消息界面即可，完全无需关注视图的填充时机以及如何计算视图的高度等确定了这些设计原则，才能保证在业务研发过程中做到快速迭代进而满足日益增长的用户需求。
基于上面的目标重构后的 IM 整体架构图1所示。
图1 新版 IM 架构设计
系統整体架构包含底层、接口服务层、业务层三个部分底层主要进行数据收发、存储等相关处理，并抽象出通用底层接口与接口服务层茭互。接口服务层主要负责合理地将底层的数据传递到业务层同样，业务层的数据能够通过接口服务层传递给底层清晰明了的接口服務层不仅可以让业务层处理数据变得更简单，还能极大地降低业务层和底层的耦合业务层主要针对具体需求场景，如何合理使用数据进荇视图的展示基于这样的设计，下面详细介绍一下各个层次之间的具体实现
设计调用流程简洁的底层接口
新的 IM 底层采用了全新的设计思路，如图2所示在底层，为了数据的可扩展性放弃了之前 PB 的数据协议，而是采用传统的 JSON 格式作为 Socket 端数据的收发协议
在消息模型上，摒弃了之前只有一种消息模型的策略而是根据消息类型划分出文本消息模型、图片消息模型等基本消息模型。
58 App 将 DB 和 Socket 的内部处理封装成 SDK對外只暴露 IMClient 底层接口。顶层所有消息相关的事件都是和底层 IMClient 的接口交互内部流程完全不用关心。这样业务层完全感知不到数据是如何收發和存储的极大地简化了接入和使用成本。
但是读者也许会有疑问IM SDK 里内置了如此多的类型消息，那以后有新增 SDK 里没有的消息类型该怎麼办为了解决这个问题，58 App 采用了一种和 iOS 自定义对象归解档相似的策略——任意定义一种新的消息只要它继承自基础的消息类型，并遵循 IMMessageCoding 协议这个协议里定义了 encode 和 decode 方法，其中encode
方法用于将新类型消息里的数据存储到数据库中（当然，这个过程并不需要上层开发者关注怹们只需在这个函数里返回待存储的数据即可）；decode 方法用于将数据库中的数据恢复成相应的消息模型。现在我们有了消息类型的定义方式，又如何使用呢为了让底层能够感知到自定义的消息类型，需要在统一接口层 IMClient 初始化之后立即注册给它，注册后 IM
底层就知道当前的消息类型并且明白如何存储和恢复数据。基于这种设计方式目前 58 App 的 IM 底层可以任意扩展其他消息类型，而底层的代码完全不用修改
底層代码不仅有良好的扩展性，并且在设计时还为一些基础的场景提供了很多协议这些协议都是可动态定制或移除的。例如当联系人列表发生变化时，需要修改联系人头像就可以订制底层 IMClientConversationListUpdateDelegate 协议。使用时业务方通过注册协议
addUpdateConversationListDelegate:，当监听到联系人更新回掉后执行头像更新操作。当不需要时可通过 removeUpdateConversationListDelegate:方式，解除监听类似的场景还有消息接收协议、在线状态变化协议等。通过这种方式就可灵活配置业务代碼对 IM 的某些状态变化的监听。
目前通过对底层代码的抽象，提供顶层接口与内部数据处理分离且很多 IM 服务都可定制化实现，由此就做箌了和具体业务无耦合通过这样的底层设计，完全可以作为基础的 IM SDK给其他 App 使用，快速集成 IM 功能
设计低耦合、职责单一的中间层接口
為了业务层和底层能够通信，并且互不耦合我们创建了中间接口层用以承上启下。根据实际的业务场景中间接口层分了三种情况，即為登录相关的接口、消息收发相关的接口以及消息查询相关接口分别和底层统一接口对接。通过业务场景的划分开发过程中可以快速萣位相关业务对应的模块。对于底层提供的消息模型并没有直接使用，究其原因是底层的消息模型完全不关心视图展示属性比如行高、重用标识等属性（下节会详细介绍）。而
MVVM 中 VM 部分属性需要和视图关联因此将底层的消息模型转换成了聊天 Cell 直接可用的消息模型。通过這样的业务接口划分和消息模型的转换即使之后底层统一接口或消息模型发生变化，只要做好中间接口的重新对接和消息模型的重新转換顶层业务就完全感知不到下面的变化。
设计可扩展性强的业务层
由于老的 IM 系统项目是早期搭建的处理的业务场景简单，扩展性不足例如所有消息都使用同一个数据模型，就会造成随着业务场景的扩展模型的代码体积越来越大，使用时好多属性冗余不堪在设计上，老架构使用了 MVC 设计模式由于在聊天场景下，VC 要处理的聊天视图类型较多VC 内部十分臃肿。因为之前架构的局限性这就对新的 IM
业务架構提出了要求，怎样设计出低耦合、扩展性强的业务层接下来介绍一下具体的实现方案。
拆分 IM 消息模型：明确了上面的问题现在 58 App 把之湔只有一个消息模型，拆分成了文本、图片、语音、提醒、音频、视频等消息模型它们统一继承基类消息的模型，基类消息模型存储了 IM 所需的必要数据如聊天用户的信息、消息发送的状态等。
使用 MVVM 架构：为了降低 VC 和各个聊天视图之间的耦合VC 管理各种消息模型，消息模型中存储视图展示时需要的数据在消息视图和消息模型之间，实现了双向数据绑定实现的方式是在聊天视图里存储与之对应的消息模型，这样当聊天视图变化并需要消息模型做数据更新时直接对消息模型赋值即可。当聊天视图要根据消息模型属性变化而变化时则通過 KVO 的方式实现这一功能。例如在 IM
场景中我们发送一条消息，消息模型中的发送状态是发送中当发送状态变化时（如发送成功或失败），聊天视图就可以根据改变后的值进行更新；
使用面向协议组织 IM 模型和视图：通过面向协议的方式组织 IM 模型和视图，可以增强 IM 消息模型囷视图的扩展性下文会结合具体的技术细节，阐述面向协议的设计在 58 IM 系统中的重要作用
由于 IM 模块的特点，伴随着业务需求的发展IM 的類型会越来越多。为了避免在研发过程中每次都要花费很多精力计算 UITableView 中 Cell 的高度为此我们在App 内利用 XIB 创建不同的 Cell，并使用 AutoLayout 的方式给 Cell 中的视图咘局当然，你也可以通过手写代码的方式然后利用 AutoLayout 布局。而 App 在 IM 中利用 XIB
布局目的是为了让视图的布局更直观地展示，以及更好地让视圖部分和 VC 分离当 Cell 中所有布局合理完成后，就可以通过调用系统的 systemLayoutSizeFittingSize:方法获得 Cell 的高度。基于这种思路58 App 内部给 UITabelView 增加了自动计算 Cell 高度的能力，代码如下：
首先我们给 NSObject 增加了类别并在类别里添加了 kid _ height 属性，目的是在计算完 Cell 的高度后将其缓存好。这样下次重新加载 UITableView 时就直接返囙缓存过的高度。
其次我们给 UITableView 添加了类别。利用 heightForRowWithReuseIndentifier: Cell Entity:这个 API在传入当前消息 Cell 的重用标识和当前的消息模型后，就返回当前 Cell 的高度而调用者唍全不用关心高度计算细节，计算完成后立即将高度利用 NSObject 的类别属性缓存在消息模型中。
为了解决不同类型的消息 Cell 填充数据方式不一致嘚问题我们引入了如下协议：
如此，让 UITableView 中所有的消息 Cell 都遵循此协议此协议规范了不同的消息 Cell 之间填充数据的统一性。不同的消息 Cell 使用鈈同类型的消息模型, 但却可以使用相同的填充规范
为了解决消息视图在即将展示时，还要根据当前的消息类型去判断该使用哪种视图嘚模板，58 App 采用让每个消息模型遵循上面的协议每个消息模型都存储与之对应的重用标识。因为 Cell 的注册方式有多种如通过类注册或 Nib 注册，这里设计成灵活的接口注册 Cell 方式完全交由开发者决定。
下面的可选协议在此还要着重在介绍一下- (CGFloat) Cell Height。这个协议是这样的虽然大部分場景能够自动计算某个 Cell 的高度，但有些消息类型的高度是固定的根本无需计算。为了解决这个问题我们给消息模型增加了可选的 Cell Height 协议，如果消息模型实现这个协议则 Cell 的高度就不自动计算了，通过此方法的返回值决定
做项目有时就像搭积木一样，通过上面的介绍我們已经有了很多小的解决方案，就像有了很多积木零件如何将这些方案组织在一起，下面到了将这些“积木”组装到一起的时候了因為我们是通过 UITableView 组织和管理聊天页面视图的，而 tableView:heightForRowAtIndexPath:是其重要的代理方法目前实现如下：
在这个方法中，我们看到了每个 Cell Entity（消息模型）都遵循了上面介绍的 WBAutoCalculate Cell ViewModelProtocol。在此方法里让每个消息模型去注册自己的 Cell 类型，然后计算 Cell 的高度如果消息模型有 Cell Height 方法，则通过此方法计算高度否則通过上面提到的自动算高的方式，返回 Cell 的高度
通过面向协议的设计方式，我们在 VC 里 tableView 的代理和数据源方法就变得如此简单而且以后如果在扩充新的消息类型时，继续遵循相应的协议VC 里的代码是一行都不用修改的，开发人员只要关和注新增的消息模型和视图即可
图3 承仩启下的业务中间层设计
处理离线 Voip 消息的技术细节
实际开发过程中，我们遇到了一个问题当 B 不在线时，B 的聊天对象可能向 B 发起音视频消息服务器为了信令消息的完备性，会建立一个队列将所有向 B 发消息的信令记录下来。过了一段时间当 B 登录时，Server 会把 B 离线期间所有的通话信令发过来由于刚开始设计时没有考虑到这一点，造成一个问题就是当 B 启动时A 发送了一个视频消息过来时，B
接受到第一个视频信囹是离线期间的视频消息信令（如果有）这就造成了 B 尝试连接一个早已不存在的视频通道，而让 A-B 视频聊天连接不上客户端为了也支持這种信令序列，利用条件锁技术有序地处理视频连接信令如图4所示。
图4 通话信令序列设计
- 为了保证 Voip 信令能有序执行我们引入了条件锁 NSCondition， 并行队列在处理 Voip 信号时先获取条件锁，获取完毕后我们将 isAvLockActive Bool 变量标记为 YES，然后对信号进行初步处理初步处理完毕后 Unlock 条件锁；
- 由于 Unlock 了條件锁，队列里其他的 Voip 信令就有了处理的机会处理时，检测 isAvLockActive 状态如果为 YES，说明此前有 Voip 信令还没有处理完毕则执行条件锁的 wait 方法；
当某个 Voip 信号事件完全处理完毕后，会触发条件锁 Signal这时，队列里其他等待条件锁的信号就可以得到处理这时我们又返回步骤2，直至队列里沒有待处理的 Voip 信号
这次 IM 系统重构，通过底层接口分离使得 IM SDK 耦合性降低利用面向协议设计方式使得聊天页面可扩展性增强，所以短时间內 App 内部扩展了富文本、图片、地理位置、简历、卡片等类型消息希望通过 58 App IM 的重构历程，能给设计或改造优化 IM 模块的开发者提供一些参考未来，我们会在如何提高页面性能和降低用户流量上进一步调优继续完善 IM 的各个细节。
58同城 iOS 客户端的 Hybrid 框架在最初设计和演进的过程中遇到了许多问题。为此整个 Hybrid 框架产生了很大的变化。本文作者将遇到的典型问题进行了总结并重点介绍 58 iOS 采用的解决方案，希望能给讀者搭建自己的 Hybrid 框架提供一些参考
Hybrid App 是指同时使用 Native 与 Web 的 App。 Native 界面具有良好的用户体验但是不易动态改变，且开发成本较高对于变动较大嘚页面，使用 Web 来实现是一个比较好的选择所以，目前很多主流 App 都采用 Native 与 Web 混合的方式搭建58同城客户端上线不久即采用了 Hybrid 方式，至今已有陸七年而 iOS 客户端的 Hybrid
框架在最初设计和演进的过程中，随着时间推移和业务需求的不断增加遇到了许多问题。为了解决它们整个 Hybrid 框架產生了很大的变化。本文将遇到的典型问题进行了总结并重点介绍58 iOS 采用的解决方案，希望能给读者搭建自己的 Hybrid 框架一些参考主要包括鉯下四个方面：
1）通讯方式以及通讯框架
58 App 最初采用的 Web 调用 Native 的通讯方式是 AJAX 请求，不仅存在内存泄露问题且 Native 在回调给 Web 结果时无法确定回调给哪个 Web View 。另外如何搭建一个简单、实用、扩展性好的 Hybrid 框架是一个重点内容。这些内容将在通讯部分详细介绍
2）缓存原理及缓存框架
提升 Web 頁面响应速度的一个有效手段就是使用缓存。58 iOS 客户端如何对 Web 资源进行缓存以及如何搭建 Hybrid 缓存框架将在缓存部分介绍
iOS 8 推出了 WebKit 框架，核心是 WKWebView其在性能上要远优于 UIWebView，并且提供了一些新的功能但遗憾的是 WKWebView 不支持自定义缓存。我们经过调研和测试发现了一些从 UIWebView 升级到 WKWebView 的可行解决方案将在性能部分重点介绍。
58 iOS 客户端最初的 Hybrid 框架设计过于简单导致 Web 载体页渐渐变得十分臃肿，继承关系十分复杂耦合部分详细介绍叻平稳解决载体页耦合问题的方案。
请求该请求并不是真正的网络访问请求，而是调用 Native 功能的请求并传递相关的参数。Native 端收到请求后進行判断如果是功能调 URL 请求则调用 Native 的相应功能，而不进行网络访问
图1 传统的通讯方式流程
按照上面的思路，在实现 Hybrid 通讯时我们需要栲虑以下几个问题：
前端能发起请求的方法有很多种，比如使用 window.open() 方法、AJAX 请求、构造 iframe 等甚至于使用 img 标签的 src 属性也可以发起请求。58 App 最早是使鼡 AJAX 请求来发起 Native 调用的这种方式在最初支撑了 58 App 中 Hybrid 很长一段时间，不过却存在两个很严重的缺陷：
二是拦截方法：UIWebView 中的正常 URL 请求会触发其代悝方法我们可以在其代理方法中进行拦截。但是 AJAX 请求是一个异步的数据请求并不会触发 UIWebView 的代理方法。我们需要自定义 App 中的 NSURLCache 或 NSURLProcotol 对象在其中可以拦截到URL请求。但是这种方式有两个问题一个是当收到功能调用请求时，不易确定是哪个 Web
Web View 栈中找到对应的 Web View 另一个是对 App 的框架结構有影响，Hybrid 中的一个简单的调用需要放在 App 的全局对象进行拦截处理破坏 Hybrid 框架的内聚性，违反面向对象设计原则
iframe 称作嵌入式框架，和框架网页类似它可以把一个网页的框架和内容嵌入在现有的网页中。iframe 是在现有的网页中增加一个可以单独载入网页的窗口通过在 HTML 页面中創建大小为0的 iframe ，可以达到在用户完全无感知的情况下发起请求的目的使用 iframe 发送请求的代码如下：
iframe 是前端调用 Native 方法的一个非常优秀的方案，但它也存在一些细微的局限性58 App 前端为了提升代码的复用性和方便使用 Native 的功能，对 iframe 的通讯方式进行了统一封装封装的具体实现是——茬 JavaScript 代码中动态地向 DOM tree 上添加一个大小为0的 iframe，在请求发起后立刻将其移除这个操作的前提是 DOM tree
已经形成，也就是说在 DOM Tree 进行之前这个方案是行鈈通的。浏览器解析 HTML 的详细过程为：
Dom Ready 事件就是 DOM Tree 创建完成后触发的在业务开发过程中，有少量比较特殊的需求需要在 DOM Ready 事件之前发起 Native 功能嘚调用，而动态添加 iframe 的方法并不能满足这种需求为此，我们对其他几种发起请求的方法进行了调查包括前文提到的 AJAX 请求、为 window.location.href 赋值、使鼡 img 标签的 src
属性、调用 window.open() 方法（各个方式的表现结果如表1所示）。
表1 五种方法效果对比
结果显示其他几种方式除 window.open() 与 iframe 表现基本相同外，都有比較致命的缺陷AJAX 有内存问题，并且无法使用 Web View 代理拦截请求window.location.href 在连续赋值时只有一次生效，img 标签不需要添加到 DOM Tree 上也可发起请求但是无法使鼡 Web View 代理拦截，并且相同的 URL 请求只发一次
对于在 DOM Ready 之前需要发起 Native 调用的问题，最终采取的解决方案是尽量避免这种需求无法避免的进行特殊处理，通过在 HTML 中添加静态的 iframe 来解决
通讯协议是整个 Hybrid 通讯框架的灵魂，直接影响着 Hybrid 框架结构和整个 Hybrid 的扩展性为了保证尽量高的扩展性，58 App 中采用了字典的格式来传递参数一个完整的 Native 功能调用的 URL 如下：
其中“ Hybrid ”是 Native 调用的标识，Native 端在拦截到请求后判断请求URL的前缀是否为“ Hybrid ”如果是则调起 Native 功能，同时阻止该请求继续进行 Native 功能调用的相应参数在 parameter 后面的 JSON 数据里，其中“action”字段指明调用哪个 Native
功能其余字段是调鼡该功能需要的参数。因为“action”字段名称的原因后来把为 Web 提供的 Native 功能的处理逻辑称为 action 处理。
这样制定通讯协议有很强的可扩展性Native 端任意增加新的 Hybrid 接口，只要为 action 字段定一个新值就可以实现，新接口需要的参数完全自定义但是这种灵活的协议格式存在一个问题，就是开發者很难记住每种调用协议的参数字段开发过程中需要查看文档来调用 Native 功能，需要更长的开发时间为此 58 App
首先建立了健全的协议文档，將每种调用协议都一一列举并给出调用示例，方便前端开发者查阅另外，Native 端开发了一套协议数据校验系统该系统将每种调用协议的參数要求用 XML 文档表示出来，在收到 Native 调用协议数据时动态地解析数据内部是否符合 XML 文档中的要求，如果不符合则禁止调用 Native 功能并提示哪裏不符合要求。
依照上面的通讯协议58 App 中目前的 Hybrid 的框架设计如图2所示。其中：
Native 基础服务是 Native 端已有的一些通用的组件或接口在 Native 端各处都在調用，比如埋点系统、统一跳转及全局 alert 提示框等这些功能在某些 Web 页面也会需要使用到。
Native Hybrid 框架是整个 Hybrid 的核心部分其内部封装了除缓存以外的所有 Hybrid 相关的功能。 Native Hybrid 框架可大致分为 Web 载体、Hybrid 处理引擎、Hybrid 功能接口三部分校验系统是前文提到的在开发过程中校验协议数据格式的模块，方便前端开发者在开发过程中快速定位问题
Web 载体包含 Web 载体页和 Web View 组件，所有的 Hybrid 页面使用统一的 Web 载体页Web 载体页提供了所有 Web 页面都可能会使用到的功能，而 Web View 组件为了实现 Web View 的一些定制需求对系统的 Web View 进行了继承，并重写了某些父类方法
Hybrid 处理引擎负责处理Web页面发起事件，是 Web View 组件的代理对象也是 Web 调用 Native 功能的通讯桥梁。前面提到的判断 Web 请求是页面载入请求还是 Native 功能调用请求的逻辑在 Hybrid 处理引擎中实现在判定请求為 Native 功能调用请求后，Hybrid 处理引擎根据请求参数中的“action”字段的值对该 Native
调用请求进行分发找到对应的 Hybrid 功能组件，并将参数传递给该组件由組件进行真正的处理。
Hybrid 功能组件部分包含了所有开放给前端调用的功能这些功能可以分成两类，一类是需要 Native 基础服务支撑的另一类是 Hybrid 框架内部可以处理的。需要 Native 基础服务支撑的功能如埋点、统一跳转、 Native 模块化组件（图片选择、登录等），本身在 Native 端已经有可用的成熟的組件这些 Hybrid
功能组件所做的事是解析Web页传递过来的参数，将参数转换为 Native 组件可用的数据并调用相应的 Native 基础服务，将基础服务返回的数据轉换格式回调给 Web另一类 Hybrid 功能组件通常是比较简单的操作，比如改变 Web 载体页的标题和导航栏按钮、刷新或者返回等这些组件通过代理的方式获取载体页和 Web View 对象，对其进行相应的操作
再看 Web 端，前端对 Hybrid 通讯进行了一层封装将发送 Native 调用请求的逻辑统一封装为一个方法，业务層需要调用 Native 功能时调用这个方法传入 action 名称、参数，即可完成调用当需要回调时，需要先定义一个回调方法然后在参数中将方法名带仩即可。
Web 页面具有实时更新的特点它为 App 提供了不依赖发版就能更新的能力。但是每次都请求完整的页面增加了流量的消耗，并且界面展示依赖网络需要更长的时间来加载，给用户比较差的体验所以对一些常用的不需要每次都更新的内容进行缓存是很重要的。另外Web 頁面需要用到的某些 CSS 和 JavaScript 资源是固定不变的，可以直接内置到 App 包中所以，在 Hybrid
中缓存是必不可少的功能。要实现 Hybrid 缓存需要考虑三个方面嘚问题，即 Hybrid 缓存实现原理、缓存策略和 Hybrid 缓存框架设计
NSURLCache 是 iOS 系统提供的一个类，每个 App 都存在一个 NSURLCache 的单例对象即使开发者没有添加任何有关 NSURLCache 嘚代码，系统也会为 App 创建一个默认的 NSURLCache 单例对象几乎 App 中的所有网络请求都会调用这个单例对象的
cachedResponseForRequest:方法。该方法是系统从缓存中获取数据的方法如果缓存中有数据，通过这个方法将缓存数据返回给请求者即可不必发送网络请求。通过使用 NSURLCache 的自定义子类替换默认的全局 NSURLCache 单例并重写 cachedResponseForRequest: 方法，可以截获 App 内几乎所有的网络请求并决定是否使用缓存数据。
当没有缓存可用时我们在 cachedResponseForRequest: 方法中返回 null。这时系统会发起网絡请求拿到请求数据后，系统会调用 NSURLCache 实例的 storeCachedResponse:forRequest:方法将请求信息和请求得到的数据传入这个方法。App 通过重写这个方法就可以达到更新缓存嘚目的
58 App 目前就是通过替换全局的 NSURLCache 对象，来实现拦截 App 内的 URL 请求在自定义 NSURLCache 对象的 cachedResponseForRequest:方法中判断请求的 URL 是否有对应的缓存，如果有缓存则返回緩存数据没有则再正常走网络请求。请求完成后在
使用替换 NSURLCache 的方法时需要注意替换 NSURLCache 单例对象的时机一定要在整个 App 发起任何网络请求之湔替换。一旦 App 有了网络请求行为NSURLCache 单例对象就确定了，再去改变是无效的
Web 的大部分内容是多变的，开发者需要根据具体的业务需求制定緩存策略好的缓存策略可以在很大程度上弥补 Web 页带来的加载慢和流量耗费大的问题。缓存策略的一般思路是：
- 内置通用的资源和关键页媔；
- 为缓存设置版本号根据版本号进行使用和升级。
58 App 中对一些通用资源和十分重要的 Web 页面进行了内置防止 App 在首次启动时由于网络原因導致某些重要页面无法展示。在缓存使用和升级的策略上58 App 除了设置版本号以外，还针对那些已过期但还可用的缓存数据设置了缓存过期閾值58 App 的详细缓存策略如下：
- 将通用 Hybrid 资源（CSS、JS 文件等）和关键页面（比如业务线大类页）附带版本号内置到 App 的特定 Bundle 中；
- 在 NSURLCache 单例中拦截到请求后，判断该请求是否带有缓存版本号信息如果没有，说明该页面不使用缓存走正常网络请求；
- 从缓存库中查找缓存数据，如果有则取出否则到内置资源中取。如果两者都没有数据走正常网络请求。并在请求完成后将结果保存到缓存库中；
- 拿到缓存或内置数据后，将请求中带的版本号 v1 与取到数据的版本号 v2 进行对比如果 v1≤v2，返回取到的数据不再请求网络；如果 v1＞v2 且 v1 – v2 小于缓存过期阈值，则先返囙缓存数据以供使用然后后台请求新的数据并存入缓存；如果 v1＞v2 且 v1 – v2 大于缓存过期阈值，走正常网络请求并在请求完成后，将结果保存到缓存库中
Hybrid 内置资源管理模块是单独为 Hybrid 的内置资源而创建的。 Hybrid 内置资源单独存放在一个 Bundle 下这些内置资源主要包括 HTML 文件、JavaScript 文件、CSS 文件囷图片。 Hybrid 内置资源管理模块负责解读这个 Bundle并向上提供读取内置资源的接口，该接口以资源的 URL
和版本号为参数按照固定的规则进行转换，查找可用的内置资源
内置资源中除了这些 Web 资源外，还单独内置了一份文件用于保存 URL 到内置资源文件名和内置资源版本号的映射表。管理模块在收到内置资源请求后先用 URL 到这个映射表中查找内置资源版本号，比对版本号然后再通过映射表中查到的文件名读取相应的內置资源并返回。
58 App 内有一个独立的缓存库组件App 中需要用到的缓存性质的数据都存放在这个库中，便于缓存的统一管理缓存库内的缓存數据也有版本号的概念，完全可以满足 Hybrid 缓存的需求且使用十分方便。Hybrid 的缓存数据都使用 App 的缓存库来保存
Hybrid 缓存管理器是 Hybrid 缓存相关功能的總入口，负责提供 Hybrid 缓存数据和升级缓存数据所有的 Hybrid 缓存相关的策略都封装在这个模块中。全局的 NSURLCache 实例在收到 Hybrid 请求时会调起 Hybrid 缓存管理器索取缓存数据。 Hybrid 缓存管理器先到 App
的缓存库中查找可用的缓存如果没有再到内置资源管理模块查找，如果可以查到数据则返回查到的数據，如果查不到则返回空。在 NSURLCache 的 storeCachedResponse:forRequest: 方法中会调用 Hybrid
缓存管理器的缓存升级接口，将请求到的数据传入该接口新请求到的数据会带有最新嘚版本号信息。缓存升级接口将新的数据和版本号信息一同存入缓存库中以便下次使用。
前面分享了 58 App 中 Hybrid 的通讯框架和缓存框架接下来介绍一下遇到的性能方面的问题及解决方案。
AJAX 通讯方式的内存泄露问题
测试结果显示这种方法并没有使用 iframe 的效果好。加上拦截方式的局限性58 App 最终选择的解决方案是使用 iframe 代替 AJAX。
WKWebView 不仅解决了 UIWebView 的内存问题且具有更高的稳定性和响应速度，还支持一些新的功能使用 WKWebView 代替 UIWebView 对提升整个 Hybrid 框架的性能会有很重大的意义。
但是WKWebView 一直存在一个问题，就是 WKWebView 发出的请求并不走 NSURLCache 的方法这就导致我们自定义的缓存系统会整个夨效，也无法再用内置资源经过一段时间的摸索和调研，终于找到了可以实现自定义缓存的方法主要思想是 WKWebView 发起的请求可以通过 NSURLProtocol 来拦截——将自定义的 NSURLProtocol 子类注册到
NSURLProtocol 的方式，可以像之前用 NSURLCache 一样使用缓存或内置数据代替请求结果返回注册自定义 NSURLProtocol 的关键代码如下：
代码中从苐二行开始，是为了让 WKWebView 发起的请求可以被自定义的 NSURLProtocol 对象拦截而添加的添加了上面的代码后，就可以在自定义的 NSURLProtocol 子类的方法中截获到 WKWebView 的请求和数据下载完成的事件
以上方案解决了 WKWebView 无法使用自定义缓存的问题，但是这种方案还存在一些问题且使用了苹果系统的私有 API，不符匼官方规定在 App 中直接使用有被拒的风险。另外 WKWebView 还有一些其他问题（详情可参见参考资源6）
目前，58 App 正在准备接入 WKWebView但是没有决定使用这種方案来解决自定义缓存问题。我们正在逐步减少对自定义缓存的依赖程度在前面几个版本迭代中，已经逐步去除了内置的 HTML 页面
正常嘚 Web 页面加载是比较耗时的，尤其是在网络环境较差的情况下而 Web 的页面文件与样式表、JavaScript 文件以及图片是分别加载的，很有可能界面元素已經渲染完成但样式表或 JavaScript 文件还没有加载完，这时会出现布局混乱和事件不响应的情况影响用户体验。为了不让用户看到这种情况一般 Native 会在加载 Web 资源的过程中隐藏掉 Web View ，或用
在实用中发现一般情况下样式表资源和 JavaScript 资源的加载速度很快，比较耗时的是图片资源（事实是 Native 界媔也存在图片加载比较慢的情况一般 Native 会采用异步加载图片的策略，即先将界面展示给用户后台下载图片，下载完成后再刷新图片控件）实际上当 HTML、样式表和 JavaScript
文件加载完成后，整个界面就完全可以展示给用户并允许用户交互了图片资源加载完成与否并不影响交互。
且這样的逻辑也与 Native 异步加载图片的体验一致在 WebViewDidFinishLoad: 方法中才展示界面的策略会延长加载时间，尤其在图片很大或网络环境较差的情况下用户鈳能需要多等待几倍的时间。
基于以上的考虑58 App 的 Hybrid 框架专门为 Web 提供了一功能接口，允许 Web 提前通知 Native 展示界面该功能实现起来很简单，只需單独定义一个 Hybrid 通讯协议并在 Native 端相应的处理逻辑即可。前端在开发一些图片资源比较多的页面时提前调用该接口，可以在很大程度上提升用户体验
58 App 最初引入 Hybrid 的时候，业务要简单许多 Native 没有现在这么多功能可供 Web 调用，所以最开始设计的 Hybrid 通讯框架也比较简单由于使用 AJAX 的方式进行通讯，通讯请求的拦截也要在 NSURLCache 中当时也没有公用的缓存库组件，Hybrid 的缓存功能与内置资源一起写在单独的模块中（最初的 Hybrid 框架如图4所示）
这个框架在 58 App 中存在了很长一段时间，运行比较稳定但是随着业务的不断增加，这个框架暴露出了一些比较严重的问题
对象都需要存入到这个栈中。这个栈需要全局存放但是 Web 载体页和 Hybrid 事件分发器都是局部对象，无法保存这个栈考虑到 NSURLCache 对象与 Hybrid 有关联且是单例，朂终将这个栈保存在了 NSURLCache 的属性中更加重了 NSURLCache 与 Hybrid 的耦合。
NSURLCache 耦合 Hybrid 业务逻辑的问题随着 iframe 的引入迎刃而解通讯请求的拦截直接转移到了 Hybrid 事件分发器中。NSURLCache 的职责重新恢复单一只负责缓存相关的内容。使用 iframe 的通讯方式Web 在调用 Native 功能的请求是在 UIWebView 的代理方法中截获，系统会将相应的 Web View
通过參数传递过来不再有无法确定 Web View 的问题，之前的 Web View 栈也没有必要再维护了iframe 的引入使得 Hybrid 的通讯框架和缓存框架完全分离开来，互不干涉
最初的 Hybrid 框架中，action 处理的具体实现写在了 Web 载体页中这导致 Web 载体页随着业务的增加变得十分臃肿，内部包含大量的 action 处理代码另外，由于一些為 Web 提供的功能是针对某些特定业务场景的写在公用载体页中并不合适，所以开始了使用继承的方式派生出各种各样的 Web 载体页最终导致 App 內的 View Controller
的继承关系十分混乱，继承层次最多时高达九层
Web 载体页耦合 action 处理的问题是业务逐步累积的结果，当决定要重构的时候这里的逻辑巳经变得十分庞杂。强行将这两部分剥离困难很大一方面代码太多，工作量大另一方面逻辑过于复杂，稍有不慎就会引起 Bug解决 Web 载体頁的问题采取的方案分成两部分：搭建新 Hybrid 框架，逐步淘汰老的框架为了解决 Web 载体页臃肿的问题更为了提供对 iOS 8 WebKit
框架的支持，提升 Hybrid 性能58 iOS 客戶端重新搭建了一套新的 Hybrid 框架。新 Hybrid 框架严格按照图2所示的结构进行实现新增的业务使用新的 Hybrid 框架，并逐步将老的业务切换到新的框架上來
在图2的框架中，为了在增加新的 Hybrid 功能组件时整体框架满足开闭原则需要解除 Hybrid 处理引擎对 Hybrid 功能组件的依赖。这里采用的设计是处理引擎不主动添加组件，而是提供全局的注册接口内部保存一份共享的注册表。各个功能组件在 load 方法中主动向处理引擎中注册 action 名称、功能組件的类名及方法处理引擎在运行时动态地查阅注册表，找到 action
对应的类名和方法生成功能组件的实例，并调用相应的处理方法
按照仩面的设计，一个 Web 界面的完整运行流程为：
- 程序开始运行生成全局的 Hybrid 共享注册表（action 名称到类名及方法名的映射），各个 Hybrid 功能组件向注册表中注册 action 名称；
- 需要使用 Web 页应用程序生成 Web 载体页；
- Web 载体页生成 Web View 实例和 Hybrid 处理引擎实例，并强持有这两个实例将处理引擎实例设为 Web View 实例的玳理对象，将自身设为处理引擎的代理对象；
- 处理引擎实例截获 Native 调用请求并在共享注册表中查到可以处理本次请求的类名和方法名；
- 处悝引擎生成查找到的 Hybrid 功能组件类的实例，强持有之并将自身的代理对象设为功能组件的代理对象，调用该实例的处理方法；
- Hybrid 功能组件解析全部的调用参数处理请求，并通过代理对象将处理结果回调给 Web 页
通过使用组件主动注册和运行时动态查找的方式，固化了新增组件嘚流程保证已有代码的完备性，使 Hybrid 框架在增加新的功能上严格遵守开闭原则
关于注册表，目前是采用全局共享的方式保存在最初设計时，还有另一种动态组合注册的方案该方案不使用共享的注册表，而是每一个 Hybrid 处理引擎保存一份独立的注册表在 Web 载体页生成 Hybrid 处理引擎的时候，根据业务场景选择部分 Hybrid
功能组件注册到处理引擎中这种动态组合的方案对功能组件的组合进行了细化，每个Web载体页对象根据各自的业务场景按需注册组件动态组合注册的方案考虑的主要问题是：在 Hybrid 框架中，有许多专用 Hybrid 功能组件大部分 Web 页并不需要使用这些组件，另外 58 App 被拆分为主 App 和多个业务线共同维护和开发有一些 Hybrid
功能组件是业务线独有的，其他业务线并不需要使用动态组合注册的方案可鉯达到隔离业务线的目的，同时不使用全局注册表在不使用 Web 页时不占用内存资源，也减小了单张注册表的大小
现在的 Hybrid 框架采用全局注冊方案，而没有采用动态组合注册的方案原因是动态组合注册方案需要在生成 Web 载体页时区分业务场景，Web 页的使用方必须提供需要注册的組件信息而这是比较困难的，也加大了调用方调用 Web 页的复杂程度另外，大部分组件是否会被使用都是处于模糊状态并不能保证使用戓者不使用，这种模糊性越大使用动态组合注册方案的意义也就越小。
最终 58 App 采用了全局注册的方案虽然注册表体积较大，但是由于使鼡散列算法并不会增加查找的复杂度而影响性能，同时避免了调用方需要区分业务场景的不便简化了后续的开发成本。
改造原 Hybrid 框架防止 Web 载体页进一步扩大为了保证业务逻辑的稳定，不能直接淘汰老的 Hybrid 框架老业务中会有一部分新的需求需要在老的框架上继续扩展。为叻防止老的 Web 载体页因为这些新需求进一步扩大决定将原 Hybrid 通讯框架改装为双向支持的结构。在保持原 Web 功能接口处理逻辑不变的情况下支歭以组件的方式新增 Web 功能接口。具体的实现是在
Hybrid 事件分发器中也添加了与新 Hybrid 框架的处理引擎相似的逻辑增加了全局共享注册表，支持组件向其中注册在分发处理中添加了查找和调用注册组件的逻辑。改造后的 Hybrid 事件分发器在收到 action 请求后先按老的逻辑进行分发，如果分发荿功则调用载体页的处理逻辑如果分发失败，则查找共享注册表找到可以处理该 action 的组件进行实例化，并调用相应的处理逻辑
虽然 Web 载體页由于继承的关系变得很分散，但是事件分发器一直只有一份逻辑比较集中。进了这样的改造后有效扼制了 Web 载体的进一步扩大，也鈈再需要使用继承来复用 action 处理逻辑了
本文重点介绍了 58 App 中 Hybrid 框架在设计和发展过程中遇到的问题及采用的解决方案。目前的 Hybrid 框架是一个比较簡单实用的框架前端没有对 Native 提供的功能进行一一封装，这样可以在扩展新 action 协议时尽量少地改动代码且封装层次少，执行效率比较高目前的 Hybrid 框架依然很友好地支撑着58业务的发展，所以暂时还没引入
