架构定义
1. model
2. model logic & validate
3. service model process and specific logic multi models
4. 流程其实是依赖管理，增加依赖中间层
5. validate 其实是基本的业务逻辑，或者是数据逻辑；可以靠数据验证和validate完成
6. service是具体的流程逻辑
7. 关于mvvm，进一步封装了model，隐藏了部分针对view的数据处理；可以视为针对特定view的cast，不过增加了model之间的依赖；可以考虑使用鸭子对象模拟；据说结合reactivecocoa会比较好
8. 其实mvc中c比较重的原因是各类委托实现、view相关展示等过程都在c中，c变成了各类代码的汇集地，导致过于庞大；其实c最好不要包含view的代码；可以控制view，但是不要写过多的view设置代码；也就是说可以控制view的生成逻辑和流程，但是不能控制具体的画的位置，包括动画等；其次考虑到view的生命周期低于c，这是个非常重要的因素，很多view的代理方法会设置到c上；好处是view占的内存可以被收掉，但是在ios6以后，view后台的layer会被回收，也就是说view相对占的内存会很少了；也就是view的代理方法放在view自身上；但是存在一个问题就是view本身一般不会继承，导致一些功能通过controller来驱动，controller更复杂了；view不会继承会采用另外一种方式，例如kvo或者一些运行时的代码，此类代码可以通过category等方式达到，但是带来另外一个问题就是代码过于动态化，过度依赖kvo或者运行时，容易起冲突，扩展复杂（因为在这个层面上修改，实际上等同于在全局层面修改，影响范围比较大；不过可以考虑通过设置开关达到部分影响的目的）。总的来说，1. 通用的逻辑代码通过抽象service达到 2. 常用的view功能可以通过自定义view达到，如果希望避免view自定义，可以考虑通过设置开关的方式达到运行时修改，又避免全局层面影响，减少冲突 3. model抽取及model验证逻辑抽取，还有model cast；其中model cast是个比较头疼的问题，因为model cast可能只有一部分需要修改，因为view的部分显示需求就cast，增加了model对象，如果view使用的model变更不大，cast反而显的多余；如果model变更大，cast作用还是很大的；这个问题需要衡量下，尤其如果cast过程涉及到部分逻辑，严格的讲，如果涉及到显示逻辑，需要view处理（但是往往view没有自定义，无法将该类代码放入，这也就引入了view model，但是view model有个问题就是它本身并不是view，生命周期不一样，如果view可以custom，其实view model反而不必要；不过可以考虑通过aop等方式处理）；实现考虑，定义基本的meta对象，然后每个对象继承基本的meta对象做相关处理；或者新建meta对象做相关cast
9. 通用分层
Io 、network，目前io层其实涉及比较少，flush层面数据的读入和写入都比较实时，不会造成卡具体一些性能数据如下：
https://www.mikeash.com/pyblog/performance-comparisons-of-common-operations-iphone-edition.html 及 http://forums.imore.com/iphone-4s/221365-iphone-4s-i-o-performance.html，给出的数据为Disk Write: 30.0 MB/s Disk Read: 106.9 MB/s 换成fps，1/60s为 write : 500KB read: 1.78M；也就是说基本上小数据量的读写基本不会阻塞主线程；不过底层io读写目前都是同步的，可能会浪费一部分时钟周期，不过考虑到cpu对一些指令乱序执行，同步执行也会加快。这里主要问题是：大概写入数据的量多大，尤其sqlite的瓶颈
搜到一篇关于sqlite的速度的：
http://stackoverflow.com/questions/1711631/how-do-i-improve-insert-per-second-performance-of-sqlite
初步看下来速度在50000 records/s左右，也就是1/60为833条，基本上每次插入条数在100条下不会影响性能，具体需要benchmark。本地建造数据库完全可行，甚至可以考虑内存数据库
接下来就是网络io，网络io没什么好说的，之前有篇文章分析了如何提高网络相关流量等方法，方法比较多，但是总体上可能提高的空间有限，我估计最多能减少一半；不过udp方式会很大程度上提高回应速度，实时视频等方式可以采用，主要是纠错问题；音频也会出现对不齐的问题
还有视频io/音频io，这两者的录制需要注意时间对齐问题，另外码率和帧率是压缩的大头，还有压缩算法，压缩算法这玩意国人自主的估计很少，目前国际上h265是爱立信提出的http://www.guokr.com/article/436664/ 同样的画质可以降低一倍的带宽 “
”
实在非常了不起，外国人的确厉害。另外gif可以考虑转成mp4. 这篇文章给出了相关分析：
http://cloudinary.com/blog/reduce_size_of_animated_gifs_automatically_convert_to_webm_and_mp4
不过h.265有专利问题，mpegla持有专利
http://www.philipstorry.net/thoughts/bpg-vs-jpeg-vs-webp-vs-jpeg-xr
UI层、Layer层
基本线程层
多版本层
数据层
相关库
其他暂时没有想法
