RLMZ基本框架浅谈
文章参照了《iOS应用架构谈》，对比自己的项目进行了总结。会持续修改，感谢《iOS应用架构谈》的作者。
RLMZiOS客户端架构看似简单，其实要考虑的事情也不少。
针对App进行要求
View层
View层是最接近业务底层的架构，影响业务层代码程度最深，所以View层一旦定性，改动空间最小。所以在View层不光要实现功能，还要考虑更多规范的东西，防止业务工程师的代码腐蚀View架构。
要点如下
所有的属相都使用getter和setter方法,@synthesize,@dynamic根据不同的情况，酌情使用，正确运用内存管理语义。
getter 和 setter全部都放在最后
每一个delegate都把对应的protocol名字带上，delegate方法不要到处乱写，写到一块区域里面。建议使用#pragma mark - 进行标明。button ,getsturRecognizer等响应事件放在一个区域里面，总之就是把delegate，event response,life cycle等方法都合理的分块放置。
对于view的布局，无论使用Frame还是使用Autolayout,都需要经过精心的设计，Autolayout可以考虑使用Masonry,Frame的话，一定要控制好可读性。
关于storyboard,nib和代码写View如果是简单视图，个人建议多使用code，对于简单界面，code一样简单，复杂界面，code比storyBoard更简单，所以个人更喜欢用code画View而不是其他。
对于业务抽象，建议还是MVC设计模式，M-model做的事包括（给viewcontroller提供数据，给viewcontroller存储数据提供接口，提供经过抽象的业务基本组件，供controller调度），C-Controller做的包括（管理view Controller的生命周期,负责生成所有view的实例，监听来自View与业务有关的事情，通过Model的合作，来完成对应事件的业务）,v-View做的事情（1.响应与业务无关的事件 ，并因此引发动画效果，点击反馈。2.界面元素表达）
也可以用MVCS，至于MVVM，理解尚欠，只肤浅的知道ReactiveCocoa。
调用网络API
iOS端，AFNetworking几乎已经成为了业界新项目的标配。
网络层跟业务对接部分的设计
以什么样的方式将数据交付给业务层
大多数App在网络层采用的方案大概有三种：Delegate，Notification，block。目前RLWapp采用的是Notification为主，delegate辅助的方式。RLMZapp采用的是block的方式。
比较两款app，根据以往经验和跟其他同学讨论，个人觉得，比较好的方式是Delegate为主，Notification为辅的方式。尽管我认为，最方便的，最炫的还是用block。
因为这样可以尽可能的减少跨层数据交流的可能，限制了耦合。（RLWNotification为主的方式，偶核性比较大，后来以Delegate方式辅助的原因也是为了降低耦合性）。
统一回调方法，便于调试和维护（RLW采用的是统一的回调方法，相比于瑞丽没赚，更易维护。）
在跟业务层对接的部分只采用一种对接手段，限制灵活性来换取更多的可维护性。
交付什么样的数据给业务层
RLMZApp网络层拿到的数据是JSON,然后将JSON转换成对应的对象模型，目前RLW，RLMZ都是采用的这种方式。这种做法是能够提高后续操作的可读性。当然Model转化过程成本很大。目前的两款app解析json都是采用的手动解析JSON 数据，优点是效率是最高的，缺点是费时间，转化之后的模型不能直接被展示，如果想展示，需要二次转化，调试的时候也不直观。但是目前没有找到更好的处理方法。
对于手动解析JSON，也可以利用github上的知名JSON直接转NSObject的三方库来进行处理。
对于API的调用，是使用集约型API调用方式还是使用离散型API调用方式
集约型API调用方式就是API的调用就用一个类，然后这个类接收API的名字，API参数还有回调着陆点（block,delegate）等作为参数。RLMZ在使用这种方式。
离散型API调用，就是一个API对应一个APIRequest。RLW在使用这种方式。
个人喜欢更熟练使用离散型API调用。
网络层的安全机制的实现
网络安全机制，目前主要考虑的就两点。
确保API的调用者是来自你我们自己的APP，防止竞争对手爬我们的API。
解决方法个人感觉让服务端给一个秘钥，调用API的时候使用这个秘钥+API名字+API参数算一个hash。如果我做，就用hash算法（md5）,请求的时候带上这个hash。服务端收到请求后，按照同样的秘钥同样的算法也算出一个hash。然后做一个比较，如果一致，就确认确实是自己的APP。（目前咱们这块应该是也没有完成。）
如果我们对外提供了需要注册才能使用的API平台。我们需要有个机制来识别是否注册用户调用了我们的API 。（感觉目前咱们用不到，没多研究）、
保证传输数据的安全
苹果目前已经要求使用Https，挺复杂的，了解不多。目前咱们用的是http协议。这方面有待学习。
网络层的优化方案
从App本身来做的优化
使用缓存手段，减少请求的发起次数。API调用请求来说，有些API请求所带来的数据的时效性是比较长的，比如RLMZ的试用，试用详情，试用报告，试用文章。都可以针对这些数据做本地缓存，
还有对图片的缓存，图片缓存的缓存策略一般都是利用比较知名的三方库，比如SDWebImage几乎成了苹果应用的标配。
试用策略来减少请求的发起次数，主要是针对重复请求策略的。
界面下拉刷新的这种请求，存在重复请求的情况。（比如下拉刷新的时候，在请求着陆之前，用户可能会不断执行下拉刷新操作，那么这个时候，后面重复的API请求就可以不必发送了）
如果是条件筛选这种，就要取消前面已经发送的请求。虽然很有可能这个请求已经被执行了，那么取消所带来的性能提升就基本没有了。但如果这个请求还在队列中待执行的话，那么对应的这次链接就可以省掉了。
数据本地持久化
动态部署方案
对App团队进行的要求
收集用户数据，给产品和运营提供参考
合理的组织各业务方开发的业务模块，以及相关基础模块
每日APP都需要打包，提供给QA工程师测试。
