前因其实我们这个7人iOS开发团队并不适合组件化开发。原因是因为性价比低，需要花很多时间和经历去做这件事，带来的收益并不能彻底改变什么。但是因为有2～3个星期的空档期，并不是很忙；另外是可以用在一个全新的App上。所以决定想尝试下组件化开发。
所谓尝试也就是说：去尝试解决组件化开发当中的一些问题。如果能解决，并且有比较好的解决方案，那就继续下去，否则就放弃。
背景脱离实际情况去谈方案的选型是不合理的。
所以先简单介绍下背景：我们是一家纳斯达克交易所上市的科技企业。我们公司还有好几款App，由不同的几个团队去维护，我们是其中之一。我们这个团队是一个7人的iOS开发小团队。作者本人是小组长。
之前的App已经使用了模块化（CocoaPods）开发，并且已经使用了二进制化方案。App已经在使用自动化集成。
虽然要开发一个新App，但是很多业务和之前的App是一样的或者相似的。
为什么要写这篇博客？想把整个过程记录下来，方便以后回顾。
我们的思路和解决方案不一定是对的或者是最好的。所以希望大家看了这篇博客之后，能给我们提供很多建议和别的解决方案，让我们可以优化使得这个组件化开发的...阅读全文

好久没有写博文了。一直在开发这个新App，然后又过年了。今天突然有人加我好友问我组件化的问题，我才想起来：好久没有写博客了。
写什么不重要。关键要持续写。那我现在随便扯点什么吧。。。
哈哈也不是随便啦，也很认真。
并不是都需要二进制化如果你是小厂，小团队，没有必要一上来就二进制化的。当时因为我们的项目中OC++代码，编译起来特别慢，不做二进制化不行，所以干脆就一口气全上了。
用router在业务组件间通信用router在业务组件间通信是完全能满足需求的。但是写起来有点烦，不够优雅。如果再有一个新App的话，我一定会使用协议的方式来试试。
版本的问题版本的问题在于，组件的版本没法对应主App的版本。追溯起来有点麻烦。而且当业务方让我们发个马甲包，而这个马甲包又是删减功能的App时，你的业务组件发版就有点麻烦了。尤其业务方喜欢历史版本。
动态化如果想要使用weex/react-native这种来搞动态化，没有什么比组件化的方式来做更合适了。可以把影响控制在范围之内。可以很容易的回滚或替换。
设计思路的变革在培养了团队成员组件化开发之后。大家在遇到新需求，设计的时候，都会首先定...阅读全文

以下讨论内容都基于这个方案
问题:没法使用closing issues via commit messages怎么办？1.测试人员不能准确知道bug需要发给哪个业务组件或是哪个弱业务组件，甚至有时候这个bug是基础功能组件造成的。 
2.因为原因1，所以导致测试人员需要把bug统一发给主App的git project。根据我们的CI流程，我们没有办法把某个业务组件的信息(比如某个commit里的message是：Fix#213)通过提merge request的方式带给主App。
解决这个问题并没有很好的解决。修复bug还是需要手动关闭issues。幸好的是，测试人员会即时通过邮件收到。
问题：发版效率低怎么办？1.package这一步要编译多个Architecture，造成CI流程耗时。 
2.发版lint这一步需要Test/Lint源码/Lint二进制，造成CI流程耗时。 
3.会同时有多个库需要跑CI。有些只是例行的Test，有些是走发版流程，有些是其他App的CI。尤其是在周五，大家都准备今天发个版回家，都集中在了一起。这种情况造成排队，需要等待长时间。 
4.g...阅读全文

NULL...阅读全文

需要在代码里面发邮件是很经常的事情，包括找回密码，通知用户领奖，监控报警等。
在Java里面实现比较简单，Oracle自己提供了JavaMail， 不过API比较底层，用起来不方便，可以自己封装下，也可以直接使用Apache的开源项目Commons Email。 下面的代码，可以以小马哥的名义给自己发邮件，该功能仅用于测试，请谨慎使用，产生的问题，本人概不负责。 /微笑
1234567891011121314151617181920212223242526272829303132333435363738394041import org.apache.commons.mail.EmailAttachment;import org.apache.commons.mail.EmailException;import org.apache.commons.mail.MultiPartEmail;import java.net.MalformedURLException;import java.net.URL;/** * Created by magicalli on 2015/7/6. *...阅读全文