常见问题
传统的MVC架构，单体型应用，Controller职责过重 -> 平台型架构，Controller减负，引入framework降低耦合度
绝对布局，屏幕适配工作比较繁琐 -> Auto Layout
iPad和iPhone用一套界面 -> 提供两套界面，size class
兼容模式，图片有拉伸 -> 高清模式，图片不拉伸
纯代码写界面 -> storyboard，xib，代码混合
编码风格有好几套，缺少统一规范 -> 引入编码规范，加强代码review
代码review流于形式 -> 固定时间，团队全员review
实现思路一人一个想法 -> 引入概要设计，在实施前团队充分讨论，观点PK；可以考虑一个iOS + 一个Android，“结对设计”
trunk、branch两个分支 -> trunk、branch、tag三个分支
开发版、正式版两种版本 ->开发版、内部试用版、正式版三种版本
只有人工的黑盒测试 -> 引入Jekin之类的工具，由测试人员和开发人员一起，写单元测试，自动打包，自动测试
没有做语言本地化处理 -> 考虑语言本地化，为多语言版本做准备
方案
以最小的改动在现有的基础上实现需求，尽量保持稳定
在当前的基础上逐步重构
Object-C + CocoaPods + Svn重写
Swift + Carthage + Git重写
iOS和Android统一编程方案
iOS先行开发，Android延迟1~3个月，无统一编程方案
iOS、Android、APP网关先讨论，共同开发，在概要设计，API设计上达到统一
将一部分内容用H5实现，混合架构，这部分两者公用
将公共部分用C实现，两个平台公用
Facebook的reactnative，阿里的weeks等JS方案
Swift，据说Android将支持Swift，服务端用Swift写已经有人开始探索
架构方面的考虑
Controller（场景scene生命周期），AppDelegate（应用App生命周期）只做调度者，不做具体的事，最好连表格的代理都不要做（代码写界面，用一个容器view代替controller的self.view）
以framework的形式进行模块划分，降低耦合度，这要求升级到iOS8
引入ViewModel概念，作为界面和具体逻辑之间的转换接口，隔离界面层，并且让界面层的代码尽量少，方便修改，快速应变
将跳转集中处理，比如第三方库routable-ios，借鉴url的做法对页面统一组织
引入“微服务”概念，包装一些只供外部模块调用的“基础组件”，比如网络，数据库，二维码扫描等等
引入“服务概念”，包装几个跟具体业务无关的“公共业务”，比如支付，登录注册，第三方登录，分享等等
引入“移动网关”概念，作为客户端的后端，后端的前端，并且集成H5、Android、iOS公用的逻辑，笔记日志、统计、黑白名单、安全等等
