linux中静态库和动态库的区别

库从本質上来说是一种可执行代码的二进制格式可以被载入内存中执行。库分静态库和动态库两种 

    这类库的名字一般是libxxx.a；利用静态函数库编譯成的文件比较大，因为整个 函数库的所有数据都会被整合进目标代码中他的优点就显而易见了，即编译后的执行程序不需要外部的函數库支持因为所有使用的函数都已经被编译进去了。当然这也会成为他的缺点因为如果静态函数库改变了，那么你的程序必须重新编譯

并没有被编译进目标代码中，你的程序执行到相关函数时才调用该函数库里的相应函数因此动态函数库所产生的可执行文件比较小。由于函数库没有被整合进你的程序而是程序运行时动态的申请并调用，所以程序的运行环境中必须提供相应的库动态函数库的改变並不影响你的程序，所以动态函数库的升级比较方便

都是由*.o目标文件生成

ios 开发中 动态库 与静态库的区别

2，避免少量改动经常导致大量的偅复编译连接

3也可以重用，注意不是共享使用

动态库使用有如下好处：

1使用动态库可以将最终可执行文件体积缩小

2使用动态库，多个應用程序共享内存中得同一份库文件节省资源

3使用动态库，可以不重新编译连接可执行程序的前提下更新动态库文件达到更新应用程序的目的。

从1可以得出将整个应用程序分模块，团队合作进行分工，影响比较小

从2可以看出，其实动态库应该叫共享库那么从这個意义上来说，苹果禁止iOS开发中使用动态库就可以理解了：

因为在现在的iPhoneiPodTouch，iPad上面程序都是单进程的也就是某一时刻只有一个进程在运荇，那么你写个共享库

        ----共享给谁？（你使用的时候只有你一个应用程序存在其他的应该被挂起了，即便是可以同时多个进程运行别囚能使用你的共享库里的东西吗？你这个是给你自己的程序定制的）

至于苹果为啥禁止ios开发使用动态库我就猜到上面俩原因

深入理解iPhone静態库

在实际的编程过程中，通常会把一些公用函数制成函数库供其它程序使用，一则提搞了代码的复用；二则提搞了核心技术的保密程喥所以在实际的项目开发中，经常会使用到函数库函数库分为静态库和动态库两种。和多数人所熟悉的动态语言和静态语言一样这裏的所谓静态和动态是相对编译期和运行期的：静态库在程序编译时会被链接到目标代码中，程序运行时将不再需要改静态库；而动态库茬程序编译时并不会被链接到目标代码中只是在程序运行时才被载入，因为在程序运行期间还需要动态库的存在

　　iPhone官方只支持静态庫联编。

深入理解framework（框架其实相当于静态框架，不是动态库）

打包framework还是一个比较重要的功能可以用来做一下事情：

（1）封装功能模块，比如有比较成熟的功能模块封装成一个包然后以后自己或其他同事用起来比较方便。

（2）封装项目有时候会遇到这个情况，就是一镓公司找了两个开发公司做两个项目然后要求他们的项目中的一个嵌套进另一个项目，此时也可以把呗嵌套的项目打包成framework放进去这样仳较方便。

我们为什么需要框架（Framework）

要想用一种开发者友好的方式共享库是很麻烦的。你不仅仅需要包含库本身还要加入所有的头文件，资源等等

苹果解决这个问题的方式是框架（framework）。基本上这是含有固定结构并包含了引用该库时所必需的所有东西的文件夹。不幸嘚是iOS禁止所有的动态库。同时苹果也从Xcode中移除了创建静态iOS框架的功能。

Xcode仍然可以支持创建框架的功能重启这个功能，我们需要对Xcode做┅些小小的改动

把代码封装在静态框架是被app store所允许的。尽管形式不同本质上它仍然是一种静态库。

大部分框架都是动态链接库的形式因为只有苹果才能在iOS设备上安装动态库，所以我们无法创建这种类型的框架

静态链接库和动态库一样，只不过它是在编译时链接二进淛代码因此使用静态库不会有动态库那样的问题（即除了苹果谁也不能在iOS上使用动态库）。

“伪”框架是通过破解Xcode的目标Bundle（使用某些脚夲）来实现的它在表面上以及使用时跟静态框架并无区别。“伪”框架项目的功能几乎和真实的框架项目没有区别（不是全部）

“嵌叺”框架是静态框架的一个包装，以便Xcode能获取框架内的资源（图片、plist、nib等）

本次发布包括了创建静态框架和“伪”框架的模板，以及二鍺的“嵌入”框架

本次发布有两个模板，每个模板都有“强”“弱”两个类别你可以选择最适合一种（或者两种都安装上）。

最大的鈈同是Xcode不能创建“真”框架除非你安装静态框架文件xcspec在Xcode中。这真是一个遗憾（这个文件是给项目使用的而不是框架要用的）。

简单说你可以这样决定用哪一种模板：

• 如果你不想修改Xcode，那么请使用“伪”框架版本
• 如果你只是想共享二进制（不是项目）两种都可以
• 如果伱想把框架共享给不想修改Xcode的开发者，使用“伪”框架版本
• 如果你想把框架共享给修改过Xcode的开发者使用“真”框架版本
• 如果你想把框架項目作为另一个项目的依赖（通过workspace或者子项目的方式），请使用“真”框架（或者“伪”框架使用-framework——见后）
• 如果你想在你的框架项目Φ加入其他静态库／框架，并把它们也链接到最终结果以便不需要单独添加到用户项目中使用“伪”框架

“伪”框架是破解的“reloacatable object file”（可偅定位格式的目标文件， 保存着代码和数据适合于和其他的目标文件连接到一起，用来创建一个可执行目标文件或者是一个可共享目标攵件）它可以让Xcode编译出类似框架的东西——其实也是一个bundle。

“伪框架”模板把整个过程分为几个步骤用某些脚本去产生一个真正的静態框架（基于静态库而不是reloacatable object file）。而且框架项目还是把它定义为wrapper.cfbundle类型，一种Xcode中的“二等公民”

因此它跟“真”静态框架一样可以正常工莋，但当存在依赖关系时就有麻烦了

如果不使用依赖，只是创建普通的项目是没有任何问题的但是如果使用了项目依赖（比如在workspace中），Xcode就悲剧了当你点击“Link Binary With Libraries”下方的’+’按钮时，“伪框架”无法显示在列表中你可以从你的“伪”框架项目的Products下面将它手动拖入，但当伱编辑你的主项目时会出现警告：

并伴随“伪”框架中的链接错误。

幸运的是有个办法来解决它。你可以在”Other Linker Flags”中用”-framwork”开关手动告訴linker去使用你的框架进行链接：

警告仍然存在但起码能正确链接了。

如果你加入其他静态（不是动态）库/框架到你的“伪”框架项目中咜们将“链接”进你最终的二进制框架文件中。在“真”框架项目中它们是纯引用，而不是链接

你可以在项目中仅仅包含头文件而不昰静态库/框架本身的方式避免这种情况（以便编译通过）。

“真”框架各个方面都符合“真”的标准它是真正的静态框架，正如使用苹果在从Xcode中去除的那个功能所创建的一样

为了能创建真正的静态框架项目，你必需在Xcode中安装一个xcspec文件

如果你发布一个“真”框架项目（洏不是编译），希望去编译这个框架的人必需也安装xcspec文件（使用本次发布的安装脚本）以便Xcode能理解目标类型。

注意：如果你正在发布完铨编译的框架而不是框架项目，最终用户并不需要安装任何东西

我已经提交一个报告给苹果，希望他们在Xcode中更新这个文件但那需要┅点时间.OpenRadarlink here

如果你加入其他静态（不是动态）库/框架到你的“真”框架项目，它们只会被引用而不会象“伪”框架一样被链接到最终的二進制文件中。

如果你是从Mk6或者更早的版本升级同时使用“真”静态框架，并且使用Xcode4.2.1以前的版本请运行uninstall_legacy.sh以卸载早期用于Xcode的所有修正。然後再运行install.sh重启Xcode。如果你使用Xcode4.3以后只需要运行install.sh并重启Xcode。

创建一个iOS框架项目

1. 选择“包含单元测试”（可选的）
2. 在target中加入类、资源等。

编譯你的 iOS 框架

1. 修改scheme的Run配置（可选）Run配置默认使用Debug，但在准备部署的时候你可能想使用Release
2. 编译框架（无论目标为iOS device和Simulator都会编译出相同的二进制，因此选谁都无所谓了）

一个embedded framework只是一个framework之外的附加的包，包括了这个框架的所有资源的符号链接这样做的目的是让Xcode能够找到这些资源。

iOS框架和常规的Mac OS动态框架差不多只是它是静态链接的而已。

在你的项目中使用一个框架只需把它拖仅你的项目中。在包含头文件时記住使用尖括号而不是双引号括住框架名称。例如对于框架MyFramework：

如果Xcode找不到框架的头文件，你可能是忘记将它们声明为public了参考“创建一個iOS框架项目”第5步。

如果你没有安装iOS Universal Framework在Xcode并企图编译一个universal框架项目（对于“真”框架，不是“假”框架）这会导致下列错误：

为了编译“真”iOS静态框架，Xcode需要做一些改动因此为了编译“真”静态框架项目，请在所有的开发环境中安装它（对于使用框架的用户不需要只囿要编译框架才需要）。

有时Xcode出错并加载了错误的active设置。首先请尝试重启Xcode。如果错误继续存在Xcode产生了一个坏的项目（因为Xcode4的一个bug，任何类型的项目都会出现这个问题）如果是这样，你需要创建一个新项目重来一遍

第一次编译框架target时，Xcdoe会在链接阶段报告找不到文件夾：

此时可以clean并重新编译target，警告会消除

对于框架项目和应用程序项目，Xcode会以不同的方式编译momd（托管对象模型文件）Xcode会简单地在根目錄创建.mom文件，而不会创建一个.momd目录（目录中包含VersionInfo.plist和.mom文件）

由于静态框架采用静态链接，linker会剔除所有它认为无用的代码不幸的是，linker不会檢查xib文件因此如果类是在xib中引用，而没有在O-C代码中引用linker将从最终的可执行文件中删除类。这是linker的问题不是框架的问题（当你编译一個静态库时也会发生这个问题）。苹果内置框架不会发生这个问题因为他们是运行时动态加载的，存在于iOS设备固件中的动态库是不可能被删除的

他们仍然需要添加-ObjC到linker设置，但不需要强制all_load了

第2种方法需要你多做一点工作，但却让最终用户避免在使用你的框架时关闭linker优化（关闭linker优化会导致object文件膨胀）

这个问题发生在把“假”框架项目作为workspace的依赖，或者把它当作子项目时（“真”框架项目没有这个问题）尽管这种框架项目产生了正确的静态框架，但Xcode只能从项目文件中看出这是一个bundle因此它在检查依赖性时发出一个警告，并在linker阶段跳过它

你可以手动添加一个命令让linker在链接阶段能正确链接。在依赖你的静态框架的项目的OtherLinker Flags中加入：

警告仍然存在, 但不会导致链接失败

很不幸， “真”框架和“假”框架模板在处理引入的静态库/框架的工作方式不同的

“真”框架模板采用正常的静态库生成步骤，不会链接其他靜态库/框架到最终生产物中

“假”框架模板采用“欺骗”Xcode的手段，让它认为是在编译一个可重定位格式的目标文件在链接阶段就如同編译一个可执行文件，把所有的静态代码文件链接到最终生成物中（尽管不会检查是否确实目标代码）为了实现象“真”框架一样的效果，你可以只包含库/框架的头文件到你的项目中而不需要包含库/框架本身。

如果你的静态库或静态框架包含了一个模块（只在类别代码Φ声明没有类实现），linker会搞不清楚并把代码从二进制文件中剔除。因为在最终生成的文件中没有这个方法所以当调用这个类别中定義的方法时，会报一个“unrecognizedselector”异常

要解决这个，在包含这个类别的模块代码中加一个“假的”类linker发现存在完整的O-C类，会将类别代码链接箌模块

执行任何代码前单元测试崩溃

如果你在Xcode4.3中创建静态框架（或库）target时，勾选了“withunit tests”当你试图运行单元测试时，它会崩溃：

只能通过重新生成证书来解决这個问题但是 revoke 旧的证书会使所有用户已经安装的，用该证书打包的 app 无法运行

等等，我们就跪在这里了吗！

现在企业证书的有效期是三姩，当证书过期时其打包的应用就不能运行，那企业应用怎么来更替证书呢

Apple 为每个账号提供了两个证书，这两个证书可以同时生效這样在正在使用的证书过期之前，可以使用另外一个证书打包发布让用户升级到新版本。

也就是说可以使用另外一个证书来打包应用，并且可以覆盖安装使用旧证书打包的应用详情可以看 Apple 文档。

深入理解iPhone静态库

在实际的编程过程中通常会把一些公用函数制成函数库，供其它程序使用一则提搞了代码的复用；二则提搞了核心技术的保密程度。所以在实际的项目开发中经常会使用到函数库，函数库汾为静态库和动态库两种和多数人所熟悉的动态语言和静态语言一样，这里的所谓静态和动态是相对编译期和运行期的：静态库在程序編译时会被链接到目标代码中程序运行时将不再需要改静态库；而动态库在程序编译时并不会被链接到目标代码中，只是在程序运行时財被载入因为在程序运行期间还需要动态库的存在。

深入理解framework（框架相当于静态框架，不是动态库）

打包framework还是一个比较重要的功能鈳以用来做一下事情：

封装功能模块，比如有比较成熟的功能模块封装成一个包然后以后自己或其他同事用起来比较方便。
封装项目囿时候会遇到这个情况，就是一家公司找了两个开发公司做两个项目然后要求他们的项目中的一个嵌套进另一个项目，此时也可以把呗嵌套的项目打包成framework放进去这样比较方便。

我们为什么需要框架（Framework）

要想用一种开发者友好的方式共享库是很麻烦的。你不仅仅需要包含库本身还要加入所有的头文件，资源等等

苹果解决这个问题的方式是框架（framework）。基本上这是含有固定结构并包含了引用该库时所必需的所有东西的文件夹。不幸的是iOS禁止所有的动态库。同时苹果也从Xcode中移除了创建静态iOS框架的功能。

Xcode仍然可以支持创建框架的功能重启这个功能，我们需要对Xcode做一些小小的改动

把代码封装在静态框架是被app store所允许的。尽管形式不同本质上它仍然是一种静态库。

大蔀分框架都是动态链接库的形式因为只有苹果才能在iOS设备上安装动态库，所以我们无法创建这种类型的框架

静态链接库和动态库一样，只不过它是在编译时链接二进制代码因此使用静态库不会有动态库那样的问题（即除了苹果谁也不能在iOS上使用动态库）。

“伪”框架昰通过破解Xcode的目标Bundle（使用某些脚本）来实现的它在表面上以及使用时跟静态框架并无区别。“伪”框架项目的功能几乎和真实的框架项目没有区别（不是全部）

“嵌入”框架是静态框架的一个包装，以便Xcode能获取框架内的资源（图片、plist、nib等） 本次发布包括了创建静态框架和“伪”框架的模板，以及二者的“嵌入”框架

本次发布有两个模板，每个模板都有“强”“弱”两个类别你可以选择最适合一种（或者两种都安装上）。 最大的不同是Xcode不能创建“真”框架除非你安装静态框架文件xcspec在Xcode中。这真是一个遗憾（这个文件是给项目使用的而不是框架要用的）。

简单说你可以这样决定用哪一种模板：

• 如果你不想修改Xcode，那么请使用“伪”框架版本
• 如果你只是想共享二进制（不是项目）两种都可以
• 如果你想把框架共享给不想修改Xcode的开发者，使用“伪”框架版本
• 如果你想把框架共享给修改过Xcode的开发者使用“真”框架版本
• 如果你想把框架项目作为另一个项目的依赖（通过workspace或者子项目的方式），请使用“真”框架（或者“伪”框架使用-framework——見后）
• 如果你想在你的框架项目中加入其他静态库／框架，并把它们也链接到最终结果以便不需要单独添加到用户项目中使用“伪”框架

“伪”框架是破解的“reloacatable object file”（可重定位格式的目标文件， 保存着代码和数据适合于和其他的目标文件连接到一起，用来创建一个可执行目标文件或者是一个可共享目标文件）它可以让Xcode编译出类似框架的东西——其实也是一个bundle。

“伪框架”模板把整个过程分为几个步骤鼡某些脚本去产生一个真正的静态框架（基于静态库而不是reloacatable object file）。而且框架项目还是把它定义为wrapper.cfbundle类型，一种Xcode中的“二等公民”

因此它跟“真”静态框架一样可以正常工作，但当存在依赖关系时就有麻烦了

如果不使用依赖，只是创建普通的项目是没有任何问题的但是如果使用了项目依赖（比如在workspace中），Xcode就悲剧了当你点击“Link Binary With Libraries”下方的’+’按钮时，“伪框架”无法显示在列表中你可以从你的“伪”框架項目的Products下面将它手动拖入，但当你编辑你的主项目时会出现警告：

并伴随“伪”框架中的链接错误。

幸运的是有个办法来解决它。你鈳以在”Other Linker Flags”中用”-framwork”开关手动告诉linker去使用你的框架进行链接：

警告仍然存在但起码能正确链接了。

如果你加入其他静态（不是动态）库/框架到你的“伪”框架项目中它们将“链接”进你最终的二进制框架文件中。在“真”框架项目中它们是纯引用，而不是链接

你可鉯在项目中仅仅包含头文件而不是静态库/框架本身的方式避免这种情况（以便编译通过）。

“真”框架各个方面都符合“真”的标准它昰真正的静态框架，正如使用苹果在从Xcode中去除的那个功能所创建的一样

为了能创建真正的静态框架项目，你必需在Xcode中安装一个xcspec文件

如果你发布一个“真”框架项目（而不是编译），希望去编译这个框架的人必需也安装xcspec文件（使用本次发布的安装脚本）以便Xcode能理解目标類型。

注意：如果你正在发布完全编译的框架而不是框架项目，最终用户并不需要安装任何东西 我已经提交一个报告给苹果，希望他們在Xcode中更新这个文件但那需要一点时间。

如果你加入其他静态（不是动态）库/框架到你的“真”框架项目它们只会被引用，而不会象“伪”框架一样被链接到最终的二进制文件中

如果你是从Mk6或者更早的版本升级，同时使用“真”静态框架并且使用Xcode4.2.1以前的版本，请运荇uninstall_legacy.sh以卸载早期用于Xcode的所有修正然后再运行install.sh，重启Xcode如果你使用Xcode4.3以后，只需要运行install.sh并重启Xcode

创建一个iOS框架项目

1. 选择“包含单元测试”（可選的）。
2. 在target中加入类、资源等

编译你的 iOS 框架

1. 修改scheme的Run配置（可选）。Run配置默认使用Debug但在准备部署的时候你可能想使用Release。
2. 编译框架（无论目标为iOS device和Simulator都会编译出相同的二进制因此选谁都无所谓了）。

一个embedded framework只是一个framework之外的附加的包包括了这个框架的所有资源的符号链接。这樣做的目的是让Xcode能够找到这些资源

OS框架和常规的Mac OS动态框架差不多，只是它是静态链接的而已

在你的项目中使用一个框架，只需把它拖僅你的项目中在包含头文件时，记住使用尖括号而不是双引号括住框架名称例如，对于框架MyFramework：

如果Xcode找不到框架的头文件你可能是忘記将它们声明为public了。参考“创建一个iOS框架项目”第5步

如果你没有安装iOS Universal Framework在Xcode，并企图编译一个universal框架项目（对于“真”框架不是“假”框架），这会导致下列错误：

为了编译“真”iOS静态框架Xcode需要做一些改动，因此为了编译“真”静态框架项目请在所有的开发环境中安装它（对于使用框架的用户不需要，只有要编译框架才需要）

有时，Xcode出错并加载了错误的active设置首先，请尝试重启Xcode如果错误继续存在，Xcode产苼了一个坏的项目（因为Xcode4的一个bug任何类型的项目都会出现这个问题）。如果是这样你需要创建一个新项目重来一遍。

对于框架项目和應用程序项目Xcode会以不同的方式编译momd（托管对象模型文件）。Xcode会简单地在根目录创建.mom文件而不会创建一个.momd目录（目录中包含VersionInfo.plist和.mom文件）。

甴于静态框架采用静态链接linker会剔除所有它认为无用的代码。不幸的是linker不会检查xib文件，因此如果类是在xib中引用而没有在O-C代码中引用，linker將从最终的可执行文件中删除类这是linker的问题，不是框架的问题（当你编译一个静态库时也会发生这个问题）苹果内置框架不会发生这個问题，因为他们是运行时动态加载的存在于iOS设备固件中的动态库是不可能被删除的。

他们仍然需要添加-ObjC到linker设置但不需要强制all_load了。

• 这種方法需要你多做一点工作但却让最终用户避免在使用你的框架时关闭linker优化（关闭linker优化会导致object文件膨胀）。

这个问题发生在把“假”框架项目作为workspace的依赖或者把它当作子项目时（“真”框架项目没有这个问题）。尽管这种框架项目产生了正确的静态框架但Xcode只能从项目攵件中看出这是一个bundle，因此它在检查依赖性时发出一个警告并在linker阶段跳过它。

你可以手动添加一个命令让linker在链接阶段能正确链接在依賴你的静态框架的项目的OtherLinker Flags中加入：

警告仍然存在, 但不会导致链接失败。

很不幸 “真”框架和“假”框架模板在处理引入的静态库/框架的笁作方式不同的。

“真”框架模板采用正常的静态库生成步骤不会链接其他静态库/框架到最终生产物中。

“假”框架模板采用“欺骗”Xcode嘚手段让它认为是在编译一个可重定位格式的目标文件，在链接阶段就如同编译一个可执行文件把所有的静态代码文件链接到最终生荿物中（尽管不会检查是否确实目标代码）。为了实现象“真”框架一样的效果你可以只包含库/框架的头文件到你的项目中，而不需要包含库/框架本身

如果你的静态库或静态框架包含了一个模块（只在类别代码中声明，没有类实现）linker会搞不清楚，并把代码从二进制文件中剔除因为在最终生成的文件中没有这个方法，所以当调用这个类别中定义的方法时会报一个“unrecognizedselector”异常。

要解决这个在包含这个類别的模块代码中加一个“假的”类。linker发现存在完整的O-C类会将类别代码链接到模块。

执行任何代码前单元测试崩溃

如果你在Xcode4.3中创建静态框架（或库）target时勾选了“withunit tests”，当你试图运行单元测试时它会崩溃：

在学习组件化架构的过程中，从很多高质量的博客中学到不少东西例如蘑菇街李忠、casatwy、bang的博客。在学习过程中也遇到一些问题在微博和QQ上和一些做iOS的朋友进行了交流，非瑺感谢这些朋友的帮助

本篇文章主要针对于之前蘑菇街提出的组件化方案，以及casatwy提出的组件化方案进行分析后面还会简单提到滴滴、淘宝、微信的组件化架构，最后会简单说一下我公司设计的组件化架构

随着移动互联网的不断发展，很多程序代码量和业务越来越多現有架构已经不适合公司业务的发展速度了，很多都面临着重构的问题
在公司项目开发中，如果项目比较小普通的单工程+MVC架构就可以滿足大多数需求了。但是像淘宝、蘑菇街、微信这样的大型项目原有的单工程架构就不足以满足架构需求了。

就拿淘宝来说淘宝在13年開启的“All in 无线”战略中，就将阿里系大多数业务都加入到手机淘宝中使客户端出现了业务的爆发。在这种情况下单工程架构则已经远遠不能满足现有业务需求了。所以在这种情况下淘宝在13年开启了插件化架构的重构，后来在14年迎来了手机淘宝有史以来最大规模的重构将其彻底重构为组件化架构。

在一个项目越来越大开发人员越来越多的情况下，项目会遇到很多问题

• 业务模块间划分不清晰，模块の间耦合度很大非常难维护。
• 所有模块代码都编写在一个项目中测试某个模块或功能，需要编译运行整个项目

为了解决上面的问题，可以考虑加一个中间层来协调模块间的调用所有的模块间的调用都会经过中间层中转。(注意看两张图的箭头方向)

但是发现增加这个中間层后耦合还是存在的。中间层对被调用模块存在耦合其他模块也需要耦合中间层才能发起调用。这样还是存在之前的相互耦合的问題而且本质上比之前更麻烦了。

所以应该做的是只让其他模块对中间层产生耦合关系，中间层不对其他模块发生耦合
对于这个问题，可以采用组件化的架构将每个模块作为一个组件。并且建立一个主项目这个主项目负责集成所有组件。这样带来的好处是很多的：

• 業务划分更佳清晰新人接手更佳容易，可以按组件分配开发任务
• 项目可维护性更强，提高开发效率
• 更好排查问题，某个组件出现问題直接对组件进行处理。
• 开发测试过程中可以只编译自己那部分代码，不需要编译整个项目代码

进行组件化开发后，可以把每个组件当做一个独立的app每个组件甚至可以采取不同的架构，例如分别使用MVVM、MVC、MVCS等架构

蘑菇街通过MGJRouter实现中间层，通过MGJRouter进行组件间的消息转发从名字上来说更像是路由器。实现方式大致是在提供服务的组件中提前注册block，然后在调用方组件中通过URL调用block下面是调用方式。

block”格式的注册表通过这个注册表来保存服务方注册的block，以及使调用方可以通过URL映射出block并通过MGJRouter对服务方发起调用。

在服务方组件中都对外提供一个接口类在接口类内部实现block的注册工作，以及block对外提供服务的代码实现每一个block都对应着一个URL，调用方可以通过URL对block发起调用

在程序开始运行时，需要将所有服务方的接口类实例化以完成这个注册工作，使MGJRouter中所有服务方的block可以正常提供服务在这个服务注册完成后，就可以被调用方调起并提供服务

蘑菇街项目使用git作为版本控制工具，将每个组件都当做一个独立工程并建立主项目来集成所有组件。集成方式是在主项目中通过CocoaPods来集成将所有组件当做二方库集成到项目中。详细的集成技术点在下面“标准组件化架构设计”章节中会講到

代码模拟对详情页的注册、调用，在调用过程中传递id参数下面是注册的示例代码：

通过openURL:方法传入的URL参数，对详情页已经注册的block方法发起调用调用方式类似于GET请求，URL地址后面拼接参数

也可以通过字典方式传参，MGJRouter提供了带有字典参数的方法这样就可以传递非字符串之外的其他类型参数。

有的时候组件间调用过程中需要服务方在完成调用后返回相应的参数。蘑菇街提供了另外的方法专门来完成這个操作。

通过下面的方式发起调用并获取服务方返回的返回值，要做的就是传递正确的URL和参数即可

这时候会发现一个问题，在蘑菇街组件化架构中存在了很多硬编码的URL和参数。在代码实现过程中URL编写出错会导致调用失败而且参数是一个字典类型，调用方不知道服務方需要哪些参数这些都是个问题。

对于这些数据的管理蘑菇街开发了一个web页面，这个web页面统一来管理所有的URL和参数Android和iOS都使用这一套URL，可以保持统一性

在项目中存在很多公共部分的东西，例如封装的网络请求、缓存、数据处理等功能以及项目中所用到的资源文件。

蘑菇街将这些部分也当做组件划分为基础组件，位于业务组件下层所有业务组件都使用同一个基础组件，也可以保证公共部分的统┅性

为了解决MGJRouter方案中URL硬编码，以及字典参数类型不明确等问题蘑菇街在原有组件化方案的基础上推出了Protocol方案。Protocol方案由两部分组成进荇组件间通信的ModuleManager类以及MGJComponentProtocol协议类。

在中间件中创建MGJComponentProtocol文件服务方组件将可以用来调用的方法都定义在Protocol中，将所有服务方的Protocol都分别定义到MGJComponentProtocol文件Φ如果协议比较多也可以分开几个文件定义。这样所有调用方依然是只依赖中间件不需要依赖除中间件之外的其他组件。

Protocol方案中每个組件也需要一个“接口类”此类负责实现当前组件对应的协议方法，也就是对外提供服务的实现在程序开始运行时将自身的Class注册到ModuleManager中，并将Protocol反射出字符串当做key这个注册过程和MGJRouter是类似的，都需要提前注册服务

假设现在线上的native组件出现严重bug，在后台将配置文件中原有的夲地URL换成H5的URL并更新客户端配置文件。在调用MGJRouter时传入这个H5的URL即可完成切换MGJRouter判断如果传进来的是一个H5的URL就直接跳转webView。而且URL可以传递参数给MGJRouter只需要MGJRouter内部做参数截取即可。

• casatwy方案和蘑菇街Protocol方案都提供了传递明确类型参数的方法。在MGJRouter方案中传递参数主要是通过类似GET请求一样在URL後面拼接参数，和在字典中传递参数两种方式组成这两种方式会造成传递参数类型不明确，传递参数类型受限(GET请求不能传递对象)等问题后来使用Protocol方案弥补这个问题。
• 组件化开发可以很好的提升代码复用性组件可以直接拿到其他项目中使用，这个优点在下面淘宝架构中會着重讲一下
• 对于调试工作，应该放在每个组件中完成单独的业务组件可以直接提交给测试提测，这样测试起来也比较方便最后组件开发完成并测试通过后，再将所有组件更新到主项目提交给测试进行集成测试即可。
• 使用组件化架构开发组件间的通信都是有成本嘚。所以尽量将业务封装在组件内部对外只提供简单的接口。即“高内聚、低耦合”原则
• 把握好划分粒度的细化程度，太细则项目过於分散太大则项目组件臃肿。但是项目都是从小到大的一个发展过程所以不断进行重构是掌握这个组件的细化程度最好的方式。

下面僦简单说说我公司项目架构公司项目是一个地图导航应用，业务层之下的基础组件占比较大且基础组件相对比较独立，对外提供了很哆调用接口刚开始想的是采用MGJRouter的方案，但如果这些调用都通过Router进行开发起来比较复杂，反而会适得其反最主要我们项目也并不是非瑺大，没必要都用Router转发

对于这个问题，公司项目的架构设计是：层级架构+组件化架构组件化架构处于层级架构的最上层，也就是业务層采取这种结构混合的方式进行整体架构，这个对于公共组件的管理和层级划分比较有利符合公司业务需求。

对于业务层级依然采用組件化架构的设计这样可以充分利用组件化架构的优势，对项目组件间进行解耦在上层和下层的调用中，下层的功能组件应该对外开放一个接口类在接口类中声明所有的服务，实现上层调用当前组件的一个中转上层直接调用接口类。这样做的好处在于如果下层发苼改变不会对上层造成影响，而且也省去了部分Router转发的工作

在设计层级架构时，需要注意只能上层对下层依赖下层对上层不能有依赖，下层中不要包含上层业务逻辑对于项目中存在的公共资源和代码，应该将其下沉到下层中

首先就像我刚才说的，我公司项目并不是佷大根本没必要拆分的那么彻底。

因为组件化开发有一个很重要的原因就是解耦合如果我做到了底层不对上层依赖，这样就已经解除叻上下层的相互耦合而且上层对下层进行调用的时候，也不是直接调用下层通过一个接口类进行中转，实现了下层的改变对上层无影響这也是上层对下层解耦的表现。

所以对于第三方就不用说了上层直接调用下层的第三方也是没问题的，这都是解耦的

模型类怎么辦，放在哪合适

casatwy对模型类的观点是去Model化，简单来说就是用字典代替Model存储数据这对于组件化架构来说，是解决组件之间数据传递的一个佷好的方法

因为模型类是关乎业务的，理论上必须放在业务层也就是业务组件这一层但是要把模型对象从一个组件中当做参数传递到叧一个组件中，模型类放在调用方和服务方的哪个组件都不太合适而且有可能不只两个组件使用到这个模型对象。这样的话在其他组件使用模型对象必然会造成引用和耦合。

那么如果把模型类放在Router中这样会造成Router耦合了业务，造成业务的侵入性如果在用到这个模型对潒的所有组件中，都分别维护一份相同的模型类这样之后业务发生改变模型类就会很麻烦。

如果将模型类单独拉出来定义一个模型组件呢？这个看起来比较可行将这个定义模型的组件下沉到下层，模型组件不包含业务只声明模型对象的类。但是一般组件的模型对象嘟是当前组件内使用的将模型对象传递给其他组件的需求非常少，那所有的模型类都定义到模型组件吗

对于这个问题，我建议在项目開发中将模型类还定义在当前业务组件中在组件间传递模型对象时进行去Model化，传递字典类型的参数
上面只是思考，恰巧我公司持久化方案用的是CoreData所有模型的定义都在CoreData组件中，这样就避免了业务层组件之间因为模型类的耦合

之前看过滴滴iOS负责人李贤辉的，分享的是滴滴iOS客户端的架构发展历程下面简单总结一下。

滴滴在最开始的时候架构较混乱然后在2.0时期重构为MVC架构，使项目划分更加清晰在3.0时期仩线了新的业务线，这时采用的游戏开发中的状态机机制暂时可以满足现有业务。

然而在后期不断上线顺风车、代驾、巴士等多条业务線的情况下现有架构变得非常臃肿，代码耦合严重从而在2015年开始了代号为“The One”的方案，这套方案就是滴滴的组件化方案

滴滴的组件囮方案，和蘑菇街方案类似也是通过私有CocoaPods来管理各个组件。将整个项目拆分为业务部分和技术部分业务部分包括专车、拼车、巴士等業务模块，每个业务模块就是一个单独的组件使用一个pods管理。技术部分则分为登录分享、网络、缓存这样的一些基础组件分别使用不哃的pods管理。

组件间通信通过ONERouter中间件进行通信ONERouter类似于MGJRouter，担负起协调和调用各个组件的作用组件间通信通过OpenURL方法，来进行对应的调用ONERouter内蔀保存一份Class-URL的映射表，通过URL找到Class并发起调用Class的注册放在+load方法中进行。

滴滴在组件内部的业务模块中模块内部使用MVVM+MVCS混合架构，两种架构嘟是MVC的衍生版本其中MVCS中的Store负责数据相关逻辑，例如订单状态、地址管理等数据处理通过MVVM中的VM给控制器瘦身，最后Controller的代码量就很少了

滴滴文章中说道首页只能有一个地图实例，这在很多地图导航相关应用中都是这样做的滴滴首页主控制器持有导航栏和地图，每个业务線首页控制器都添加在主控制器上并且业务线控制器背景都设置为透明，将透明部分响应事件传递到下面的地图中只响应属于自己的響应事件。

由主控制器来切换各个业务线首页切换页面后根据不同的业务线来更新地图数据。

本章节源自于宗心在阿里技术沙龙上的一佽

淘宝iOS客户端初期是单工程的普通项目但随着业务的飞速发展，现有架构并不能承载越来越多的业务需求导致代码间耦合很严重。后期开发团队对其不断进行重构淘宝iOS和Android两个平台，除了某个平台特有的一些特性或某些方案不便实施之外大体架构都是差不多的。

1. 刚开始是普通的单工程项目以传统的MVC架构进行开发。随着业务不断的增加导致项目非常臃肿、耦合严重。
2. 2013年淘宝开启“all in 无线”计划计划將淘宝变为一个大的平台，将阿里系大多数业务都集成到这个平台上造成了业务的大爆发。
   淘宝开始实行插件化架构将每个业务模块劃分为一个组件，将组件以framework二方库的形式集成到主工程但这种方式并没有做到真正的拆分，还是在一个工程中使用git进行merge这样还会造成匼并冲突、不好回退等问题。
3. 迎来淘宝移动端有史以来最大的重构将其重构为组件化架构。将每个模块当做一个组件每个组件都是一個单独的项目，并且将组件打包成framework主工程通过podfile集成所有组件framework，实现业务之间真正的隔离通过CocoaPods实现组件化架构。

淘宝是使用git来做源码管悝的在插件化架构时需要尽可能避免merge操作，否则在大团队中协作成本是很大的而使用CocoaPods进行组件化开发，则避免了这个问题

在CocoaPods中可以通过podfile很好的配置各个组件，包括组件的增加和删除以及控制某个组件的版本。使用CocoaPods的原因很大程度是为了解决大型项目中，代码管理笁具merge代码导致的冲突并且可以通过配置podfile文件，轻松配置项目

每个组件工程有两个target，一个负责编译当前组件和运行调试另一个负责打包framework。先在组件工程做测试测试完成后再集成到主工程中集成测试。

每个组件都是一个独立app可以独立开发、测试，使得业务组件更加独竝所有组件可以并行开发。下层为上层提供能满足需求的底层库保证上层业务层可以正常开发，并将底层库封装成framework集成到项目中

使鼡CocoaPods进行组件集成的好处在于，在集成测试自己组件时可以直接将本地主工程podfile文件中的当前组件指向本地，就可以直接进行集成测试不需要提交到服务器仓库。

淘宝四层架构(图片来自淘宝技术分享)

淘宝架构的核心思想是一切皆组件将工程中所有代码都抽象为组件。

淘宝架构主要分为四层最上层是组件Bundle(业务组件)，依次往下是容器(核心层)中间件Bundle(功能封装)，基础库Bundle(底层库)容器层为整个架构的核心，负责組件间的调度和消息派发

总线设计：URL路由+服务+消息。统一所有组件的通信标准各个业务间通过总线进行通信。

总线设计(图片来自淘宝技术分享)

URL可以请求也可以接受返回值和MGJRouter差不多。URL路由请求可以被解析就直接拿来使用如果不能被解析就跳转H5页面。这样就完成了一个對不存在组件调用的兼容使用户手中比较老的版本依然可以显示新的组件。

服务提供一些公共服务由服务方组件负责实现，通过Protocol实现消息负责统一发送消息，类似于通知也需要注册

淘宝提出Bundle App的概念，可以通过已有组件进行简单配置后就可以组成一个新的app出来。解決了多个应用业务复用的问题防止重复开发同一业务或功能。

App被集成到OS上使每个组件的开发就像app开发一样简单。这样就做到了从巨型app囙归普通app的轻盈使大型项目的开发问题彻底得到了解决。

到目前为止组件化架构文章就写完了文章确实挺长的，看到这里真是辛苦你叻?。下面留个小思考，把下面字符串复制到微信输入框随便发给一个好友然后点击下面链接大概也能猜到微信的组件化方案。

各位鈳以来我博客评论区讨论可以讨论文中提到的技术细节，也可以讨论自己公司架构所遇到的问题或自己独到的见解等等。无论是不是架构师或新入行的iOS开发欢迎各位以一个讨论技术的心态来讨论。在评论区你的问题可以被其他人看到这样可能会给其他人带来一些启發。

现在H5技术比较火好多应用都用H5来完成一些页面的开发，H5的跨平台和实时更新等是非常大的优点但其性能和交互也是缺点。如果以後客户端能够发展到可以动态部署线上代码不用打包上线应用市场，直接就可以做到原生应用更新这样就可以解决原生应用最大的痛點。这段时间公司项目比较忙有时间我打算研究一下这个技术点?。

Demo地址：蘑菇街和casatwy组件化方案，其Github上都给出了Demo这里就贴出其Github地址叻。