iOS 组件化

昨天没写哈，还是要坚持，不要轻言放弃，养成习惯！

TODO：

1.针对iOS组件化写一篇文章

Actual：

1.职业思考

引用知乎上的人的一段，我觉得很有意思，广度和深度同样重要，个人认为适合的方式是先深入，在横向广度发展，程序员很容易陷入单一的思维和技术。

如果想在IT职业生涯长期发展下去，个人认为可以把 "深度->广度"作为一个基本周期单元很合适。

－－－－－－－－－－－－－－－－－－－－－－－

看到得了这么多票，实在不忍！而且题目改了，改成广度和深度了...

你遇到什么问题，就去研究，不要纠结于：这是深度还是广度？我本来是打算先发展深度还是先发展广度？我去解决这个问题，是否跟我原来的规划不符合？...那就跟纠结于先迈左脚还是先迈右脚一样了。

认真去解决每一个问题，时间长了，在深度和广度上都会有一定的积累。并不存在一定要谁先谁后的问题。

---------------------------------------------------------------------------

有时候你单纯的想要深入，深入，根本深入不下去的。没有广度的时候，很难深入下去。

有时候你想要广度也没有，不深入理解一些东西的时候，做不到触类旁通。

我很多年前意识到这个问题，不过我不大考虑深度，我当做高度来考虑。如果没有足够的广度，积木是垒不高的，很容易崩塌。

---------------------------------------------------------------------------

考虑收入，有深度可以很快把工资喊高。但是除非非常热门的行业，工资喊高了也是有价无市，面太窄了。所以，深度和广度得同时进行啊。

2.iOS 组件化思考

今天看了一下 iOS组件化方案，写的还不错，看得出作者在架构设计是有一定的深度的。整个组件化的技术实现：

        1.利用字符串的类名生成targetName.

        2.利用字符串的方法名生成actionName.

        3.利用NSDictionary传入通用参数

        4.CTMediator会利用OC Runtime生成对应的target , selector对象，然后使用NSInvocation填充参数完成接口调用

        5.为了防止CTMediator模块受到污染，将各个模块所依赖的具体方法申明实现放到了各自的CTMediator+A的分类中

整个架构图如图所示：

综合分析，个人觉得又缺各异，

优点：1.这一解决方案区分了远程模块和App内模块调用，为以后业务的拓展提高了灵活性。

            2.运行时懒惰加载模块的方式让App有了更好的可伸缩性

            3.各个模块申明自己的CTModerator分类，把HardCode的部分危害缩小到具体分类中。

缺点：1.由于作者推崇在Module间完全去Model化，势必导致Model申明的重复化，在复杂Model中尤为明显。    

            2.项目中虽然作者已经将HardCode的污染隔离到了CTModerator的分类中，但是由于包括方法名/类名的运行时调用，势必会失去编译时及时找出错误的机会，也就是说可维护性不太好。

总结：个人认为组件话的核心思想就是能够保证各个模块之间能够灵活地且松耦合地动态替换。比如基于XML组件配置启动，主要是能运用在多个团队的分工协作上。