一名一线开拓对付App架构和组件化的思索

写在前面

关于App架构、组件化，本文的内容不会涉及到详细代码层面，也不会先容奈何行使Cocoapods去做组件化;而是站在软件工程的角度上，团结本身多年一线开拓履历，去说明怎样做App架构，怎样全盘思量什么样的架构才是公道的，契合自身营业的，以及架构落地进程中应该规避哪些题目。

名词表明：本文中所提到的架构不是现实工程中代码架构(MVC、MVVM、MVP)，确切的说是一种应用分层架构。而MVC、MVVM、MVP本质是一种软件架构模式，是App实现进程中的一种编码模式可能编码类型。

iOS体系架构回首

如上图所示，经典的iOS体系架构分为四层，自下而上分为焦点操纵体系层、焦点处事层、媒体层、用户交互层。

Cocoa Touch：提供与用户交互的相干手段，包罗触摸等，最常用的UIKit库就在该层;除此之外尚有MapKit、Address BookUI、PhotosUI等。

Media Layer：提供图形与音视频相干成果的接口，譬喻Core Animation、OpenGL ES等。

Core Services：最常用的有Core Foundation、Foundation、CFNetwork、CoreData等。提供最基本的手段，好比数组、字典、HashMap、套接字等基本数据布局。

Core OS：包括Mach、Kernel、BSD、Socket以及Sandbox等，它首要提供了底层操纵的接口，对付应用开拓来讲直接用到的不是许多。

都说iOS体系牛逼，牛逼在哪?牛逼就牛逼在它有公道的架构分层，尚有公道的Api计划，让你可以或许躺着就能做iOS开拓，畅享丝滑!它牛逼的文件打点和文件断绝机制让你不必要过多思量iOS体系安详性题目，逆向开拓除外，由于它老是Bug般的存在????。

Q：iOS体系架构这四层之间是怎样举办通讯和交互的，是否公道?

A：直接引用头文件，挪用基层提供的Api举办交互。关于是否公道，我想说的是只要Api计划的足够公道，足够能应对将来一段时刻内SDK内部也许的变换，可能说SDK自己是一个很基本的库，好比Foundation库等，我认为直接引入头文件无感冒雅，详细的我们稍后再接头。

计一律个公道的应用分层架构

麻雀虽小五脏俱全，要想展翅高飞，每个环节缺一不行。

关于怎样计一律个公道的应用分层架构，这里我们拿盖楼这件事做比喻，笔者干过构筑搬过砖，以是对付盖楼流程相对来说较量认识。

第一步：打地基、支模板、灌溉水泥摆架子、搬砖垒墙，这是统统的基本，高楼要挺立不倒，必要这些模块的持久有力的支撑才行。抽象到应用架构内里，我们称之为基本模块，其首要提供给用最基本的手段。

第二步：铺地面、造门，个中门在寝室、餐厅都也许会用到。抽象到应用架构内里，我们称之为民众营业模块，它首要提供了一些通用的营业模块可能通用的组件。

第三步：给大楼赋能，寝室、餐厅、洗漱间等包罗万象，有了这些才气真正浮现盖大楼的意义。寝室等成果都要用到砖、墙、门等基本模块。在应用架构中，我们把寝室、厨房、洗漱等独立成果抽象为平凡营业模块，每个营业模块都代表一个详细的成果，营业模块间没有强关联相关。

Q：除了以上的部门，是否还弱点什么对象?

A：楼层跟楼层之间必要电梯毗连通讯，寝室和厨房之间也必要通道举办毗连。同样对付应用来讲，模块间的通讯也必要一个前言毗连起来，我们称之为总线(Bus)。后续会具体先容怎样实现一个总线，让你的模块各自分工，且模块间的通讯流畅无阻。

颠末说明梳理，我们很轻易可以或许画出如下的应用架构图，图中每层都标出了该层大抵包括哪些内容。

图中，我们凭证“盖大楼”的思绪，进一步抽象摆列出了一个App应该包括哪些布局。

应用架构实验落地

在iOS平台中，我们一样平常会通过Cocoapods去打点、集本钱身的组件。凭证工场化出产App的理念，团结Cocoapods我画出了如下的App集成图。

基本模块：因模块高度独立，且高频行使，若公司内部有多个App同时必要依靠，提议单独建设私有库Specs。

民众营业模块：成果相对独立，按照营业需求来抉择是否单独建设私有库Specs。

Cocoapods公有库：全部公司内部App，凶猛提议不要直接引入公有Specs。这样做有两点甜头：

1. 跟外部情形有用断绝，第三方库产生题目，公司内部可控。
2. 公有库太大，每次repo update耗时太长，海内的情形你懂的，没有科学上网，至少一个小时已往repo也未必更新完毕。以是通用的方案是，若公司内部引用了第三方库，凭证依靠倒置的原则，提议封装一层之后放到Basic Specs供营业方行使。在这里保举一个科学上网器材，可自行搭建VPS->Vultr 。

又来到了一年一度的QA环节。

Q：怎样掌握组件拆分粒度?

A：没有一个可权衡的尺度，必要团结详细营业场景，那些复用性高、成果相对独立就可以思量做拆分。尚有必要留意的是，组件拆分不必然要抽离成pod库，可以将有必然特征的一组通用组件打成一个pod库(暂时界说成CommonUIKit)。我们知道pod库最终都是天生静态库引用到主工程的，也就是最终城市颠末链接的进程，pod库过多会带来必然的App启念头能开销，其次pod库过多也会导致pod打点紊乱的题目。

Q：好比一个很小的成果，就一个弹框我必要去做解耦么，我抽成pod库别人直接引用不就得了?

A：在答复之前，我们先思索两个题目。弹框组件将来变换也许性有多大?你计划的Api是否公道，是否可以或许满意将来产物的需求?第二个题目，解耦带来的益处可以或许cover住这些也许的变换带来的破绽?想清晰这两个题目，我们就知道计一律个组件是否必要做解耦，是否必要用中间处事去除依靠了。

办理横向依靠

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!