缘起

        产品新需求在首页增加一个banner位置，这个banner位置显示的其实是动态发下的H5代码。从而很好满足运营需要在首页灵活加入内容，配合线下活动。用开发的语言来说就是，以后点击banner中的一个按钮会跳转到预定义好的页面。项目刚开始，产品给了一份可能需要跳转的页面列表。项目进行到尾声，产品不断在列表中加入新页面。最后，产品提出是否可以唤起任何可能的原生页面。

       可以想象这样一来，特别类似于我们在浏览器里访问某个站点上的某个网页。

可行性的初步判断

因为iOS是一种动态语言，产品的需求应该是可以满足的。原理上，只要H5代码里指明需要唤起的页面，并传入需要的参数即可。这里要考虑的是Android端和iOS端都有对应的页面存在，并有同样的传参规则。

参考已有方案

印象中之前看过相关主题的文章，似乎是蘑菇街一个工程师和凯撒的激烈讨论。然后还有很多人对此进行解释，也发表了看法。见下

https://www.jianshu.com/p/afb9b52143d4

我的感悟

1，关于组件、模块、插件的概念：

组件和模块概念在很多文章里都是混用的：同篇文章里在混用这两个词；不同文章间对这两个词有不同的定义。阅读时一定要注意。之后在团队内，一定要对这两个概念有统一的，精准的定义。

插件化，我认为是一种单独可以编译通过，甚至可以作为单独应用的运行的模块。比方，支付宝里很多模块就是作为插件化存在。

2，页面路由！=组件化：

阅读文章的时候一直以为把每个页面分开就是组件化了，特别很多方案对应的代码都带有“router”关键字，更以为就是指页面路由。

直到在试探性用了mgjrouter和ctmediate之后，才猛然醒悟其实组件化的定义非常宽泛。也回想起文章里提到的，组件向外提供的是服务。这么来说，完全可以把网络API请求做成一个组件，向外提供网络请求服务。

3，组件化工具只是中间件：

无论是mgjrouter、ctmedate、还是其他组件化工具，都是一个中间件。它们的作用是将通过函数调用服务，改进为非常松散调用关系。如下，是我使用Routable用短链方式唤起优惠券页面。从中可以发现这个调用关系松散的什么程度？假设我并没有优惠券页面，代码编译也可以通过。在实际运行过程中，如果没有优惠券页面，副作用也就是无法跳转而已。再回顾我上面说的，组件化工具是中间件，目的是将服务调用关系松散化。

[[Routable sharedRouter] open:[NSString stringWithFormat:@"Coupon/%ld/NO",couponId]];

4，解决服务发现的问题：

因为服务调用关系松散化，所以究竟有什么服务可以使用，作为新手你是觉得不知道的。所以才有了蘑菇街的通过代码控制后台，提供服务的解释。也就出现了CTMediate里，每实现一个新服务，就必须提供一个新服务接口。这一定是组件化的副作用，同时一定需要个工具来解决这个副作用。CTMediate使用的是cocoapod管理工程，但对于团队合作却不是很有利。mgjrouter有专门开发工具后台来管理，但会导致某个需要的页面没有被导入工程中。

5，关于网上对于组件化方案的论战：

什么参数调用不灵活，什么必须注册耗费时间，什么安全性。以上统统不重要。重要的是：1，为自己的团队，为自己的项目选择合适的方案。2，明白组件化带来的好处，比方使得页面UI测试成为可控，降低代码编译时间... 3，仔细思考组件化实质是对工程的一次重构，重构的过程不能影响正常业务开发，不能引入新问题。

我的反思

花费了太多时间在研读大神们论战的文章。最后通过1天的探索性实践，在工程中尝试用了多种组件化中间件，才形成了自己的思考和选择。（阅读->实践>思考）其实最后我选择的是离我需求最近的routable，并还会在之后使用过程中按我的需求对其进行修改。

每次对工程的重构可类比公司对组织架构的调整。