close
当前位置: 物联网在线 > 技术文库 > ios >

BeeHive,一次 iOS 模块化解耦实践

在天猫App的快速发展过程中,人员不断壮大,业务不断复杂,代码量随之增多,带来的是协作开发中遇到各种各样的问题。

你是否曾在这样的环境下艰难开发?畏手畏脚地边做需求边改BUG。

同时iOS的工程代码的耦合可能是这样的:

BeeHive,一次 iOS 模块化解耦实践

AppDelegate中包含大量库的init以及其他操作,少则几百行,多则上千行,无关代码堆积在其中,维护成本极高,不同库的调用逻辑互相交错,如下图所示:

BeeHive,一次 iOS 模块化解耦实践

面条式的耦合,导致上层业务受限于底层基础库的依赖影响,BUG排查缓慢、新功能增加效率随代码量递增而不断递减。

1.1 开发中主要问题

开发过程中总结了以下App开发中遇到的问题:

功能代码之间的依赖复杂,可维护性差

协同开发过程中,并行开发存在block情况

功能界限不清晰,基础功能模块变动,会导致上层业务受到影响

各团队负责功能模块,在主工程中有耦合代码

上层业务会出现反向提供功能给底层情况

性能分析优化,随代码增加变得困难

1.2 App和开发人员的诉求

一个App应该有如下特性:

功能可维护性

功能可用性

功能具有良好性能

功能可分析,可量化

功能可单元测试

开发人员希望协同开发中能够做到以下几点:

不希望被别人block住开发

依赖库版本、约定的接口要稳定

以最少侵入式代码来接入某个功能

代码隔离开发问题,通过Cocoapods得到解决,代码层面达到了分割,但逻辑功能上的耦合问题还是无法解决。开发人员希望在扩展业务的同时做到快速稳定,因此需要有一种App模块解耦方式来让开发人员中免受依赖关系的痛苦,于是让开发人员产生了打造一个全局基础框架的想法。

2. BeeHive的最佳实践

BeeHive的使用方法可以参考BeeHive的README:

https://github.com/alibaba/BeeHive

这里举一个实际开发中的例子。

2.1 3D-Touch例子

2.1.1 场景1:搭建3DTouch场景

iPhone 6s及以上的设备支持3D-Touch后,几乎所有应用都在适配其特性,按照惯例,在AppDelegate中包含如下代码:

-(void)application:(UIApplication *)application performActionForShortcutItem:(UIApplicationShortcutItem *)shortcutItem completionHandler:(void (^)(BOOL))completionHandler { .... }

这意味着AppDelegate要增长代码行数,实则QuickAction的功能没有必要写在AppDelegate中。利用BeeHive框架特性,创建3DTouch Pod,独立3DTouch相关业务功能。

-(void)modQuickAction:(BHContext *)context { .... //process context.shortcutItem }

2.1.2 场景2:3DTouch需要动态化,可量化

一个动态配置quickAction需求的到来,以往的做法需要引入配置Module,创建对应一系列调用流程,这时只需要调用配置Service即可,而且希望更早的更新quickActionItem,于是可以调用modInit来实现。

-(void)modQuickAction:(BHContext *)context { .... //update config by configCenter Service }

产品方还希望知道用户都用了哪些QuickAction,这时调用UserTrack Service即可,诸如此类的一个上层业务,开发人员要调用Log,Cache等等服务,采用BeeHive Service形式后只需一行调用即可。

2.1.3 场景3:3DTouch需要做到个性化

在没有服务端的情况下,如何做到QuickAction个性化,注册并提供了3DTouchBHService,给其他业务调用比如某个功能页面

-(void)updateAccessTimesWithActionURL:(NSURL *)actionURL { .... // save view controller access times by cache service // update local quickAction Items by access times and any other element }

上面三个典型场景主要涉及的到BeeHive几大功能点:

Module的创建,感知App生命周期

对内引入、调用Service

对外提供Service

功能移植,无需copy,podfile中增加pod源

整个3DTouch开发过程中不涉及其他其他功能的具体实现,面向切片编程过程中,只要关心自己模块对应的需求即可。

3. BeeHive结构与原理解析

BeeHive借鉴了Spring Service、Apache DSO的架构理念,采用AOP+扩展App生命周期API形式,将业务功能、基础功能模块以模块方式以解决大型应用中的复杂问题,并让模块之间以Service形式调用,将复杂问题切分,以AOP方式模块化服务,举例来说日志、埋点模块采用AOP方式后,业务方不需要考虑日志、埋点的相关代码,只要以createService去声明调用Service即可。

相应的BeeHive架构如下:

BeeHive,一次 iOS 模块化解耦实践

Core + plugin的形式可以让一个应用主流程部分得到集中管理,不同模块以plugin形式存在,便于横向的扩展和移植。


(责任编辑:ioter)

用户喜欢...

iOS端一次视频全屏需求的实现

对于一个带有视频播放功能的app产品来说,视频全屏是一个基本且重要的需求。虽然这个需求看起来很简单,但是在实现上,我们前后迭代了三套技术方案。这篇文章将介绍这三种实现方案中...


iOS开源:DecouplingKit - iOS 模块化过程中模块间解耦方案

Podfile platform :ios, '7.0'pod 'DecouplingKit', '~ 0.0.2' DecouplingKit是一个用于模块之间解耦的方案。 当App团队的人数增长到一定人数之后会分出业务线,这样就会就行模块化工作来隔离开各个业务线,...


iOS开源:AntNest - 吸收了 Go 语言的 Interface 模型的 iOS App 模块化解耦编程的框架

AntNest 是吸收了 Go 语言的 Interface 模型的 iOS 的 App 模块化解耦编程的框架。 完全解耦的面向接口插件化模块开发运行框架 模块具体实现与接口调用分离 易扩展的模块生命周期、事件分发 设...


关于iOS 10锁屏界面交互的一次严肃分析

iOS说:“清晰度,咱俩分手吧” 以往的iOS锁屏界面非常简单直接,但是来到今年的iOS10,情况发生非常大的变化,在开始认真严肃地为大家分析(tucao)之前我想先说明一些东西: 分析并写下...