简要回顾
从2012年底转行移动互联网以来，一路坎坷，当时选iOS，纯粹是看着和C比较像，并且是对象C，感觉这个很厉害。另外，XCode良好的编程体验也是一个原因。
“男怕选错行，女怕嫁错郎”。iOS也就是从2010年左右开始热起来，经典的iPhone4，到现在也就六七年左右，现在的iOS开发也已经体现出日薄西山的感觉。web前端将替代移动客户端，大前端趋势不可阻挡，JavaScript将一统前端。开发者为什么不能和睦相处，非要砸别人饭碗才好？
如果要做技术，Java后端才是王道，大前端基本都是打零工的职业，年轻人升级打怪用的。
这4年多来，亲身经历和见证了iOS从兴起到强盛再到现在的日渐式微，也算是经历过。
iOS相关技术选择的分歧比较大，以下观点只代表了个人观点。
Swift vs Object-C？
从
Swift出来的第一天，看了一个星期左右的资料，果断选择Swift，准备抛弃Object-C。不过到目前为止，还是Object-C用得多，人得面对现实。编程范式有面向过程，面向对象，面向函数三种。面向过程是基础，大家都有，这个没有争论。
Object-C专门的面向对象；Swift既可以面向对象，也可以面向函数。Swift更重视安全性，可选类型，guard关键字，defer关键字等等都是具体体现Swift对C++的兼容性不好，还离不开Object-C作为中间的胶水层。很多优秀的第三方库还是Object-C的。
现在，是时候从Object-C向Swift迁移了
老项目是
Object-C开发的，怎么办？
(1)将系统最低支持版本升级到iOS8，引入framework进行管理
(2)将网络访问，缓存，基础工具等功能模块独立出来，包装成framework，用Swift实现
(3)将一些逻辑模块独立出来，用framework包装，改造成Swift
(4)将界面层用Swift实现一遍，完成迁移
(5)如果需要保留Object-C的，也用framework包装起来，进行隔离，等时机成熟再改造至于新项目，当然直接上
Swift了，虽然没有runtime，只是麻烦一点，功能还是都能做到的。至于Object-C的第三方库什么的，用一个framework包装一下就好了。
故事版 vs 纯代码？
个人支持故事版，当然代码写界面是免不了的，不过能不用代码就不用代码。
没有代码就没有
bug，所见即所得，更直观至于模块划分，版本冲突问题，多用几个故事版就可以解决了
至于性能影响，这里还不是瓶颈，可以忽略。性能优化，还是从自己的代码找原因比较好。
Carthage vs CocoaPod？
个人喜换
Carthage，但是平时见得多的还是CocoaPodCarthage可以强化framework的使用Carthage耦合更松散，隔离性更好
Native vs JavaScript？
虽然大前端概念很热，本人还是坚持
Native，Swift的编码效率并不比JavaScript低。关键是安全，速度快，体验好。虽然
React Native和weex声称有Native的体验，不过实际上性能损失还是比较明显的。这样做的结果是将iPhone的体验和Android的体验做成一致，将一个良好的系统变成了一个普通的系统。动态化被过度强调，降成本是真实原因，所以
JavaScript被热捧用
React Native和weex来替代H5，做活动，在保持动态化的基础上提升体验，这个是支持的。用来替代Native，降成本，本人反对。这样的话，只要Android手机就可以了，还需要iPhone干什么？苹果禁止
JSPatch，只是投石问路，禁止React Native和weex才是目的。失去开发者，失去应用商店主导权，苹果怎么生存？阿里人多，做得也很讨巧，在上
weex的时候，H5的降级页面也是提供的。那天苹果要是禁了weex，只要降级到H5就可以了，对他没任何影响。React Native和weex两者一定要选一个的话，那么还是选weex。一方面，本人只接触了几个月的weex；另一方面，本人也大致看过两者，本质上差不多，不过weex做得比较彻底，支持ES6，支持vue2.0，更接近前端的编程
组件化怎么做？
对页面进行url编码
具体跳转写在
load函数中具体的
url写在集中文件中，最大程度公开可以考虑像
DNS一样，对url定义做一份对照表，取个有意义的名字，方便使用将体验做得像网页访问一样
参数传递尽量不要通过
url携带，应该在数据层或者逻辑层采用其他通讯方式。界面层尽量薄，只做显示。做侦听，提供页面刷新函数更新。
MVVM vs MVC？
个人偏向
MVVM，但是遇到的基本上是MVCViewModel只做显示逻辑，不承担数据和业务逻辑等功能，比如网络访问就不应该在这里做。这个只是将界面元素的接口。增加一个
xxxServiece，并且是模块级的，为页面提供逻辑和数据服务，同时为多个页面提供服务。Controller不做具体的业务，只是页面的生命周期，发起函数调用即可。
网络？
现在的
URLSession已经很好用了，完全可以自己写没信心的话，就选
AFNetworking好了JSON解析直接用系统的，不需要引入其他第三方库字典模型互转，可以考虑YYModel
字典转模型还是独立出来比较好，放在网络模块里反而不好管理。网络模块的输出，还是直接数组套字典比较好。
本地缓存？
不用数据库，更不用
CoreData
图片上传下载？
现在的
URLSession已经很好用了，完全可以自己写本地缓存可以用
YYCache图像解码，加快显示，这块自己写比较麻烦
可以选择YYImage
YYWebImage当然，选择
SDWebImage也是合理的
和H5通讯
目前还是
UIWebView比较成熟，WKWebView还有很多坑，不好用建议采用第三方库WebViewJavascriptBridge
iOS、Android、JavaScript三端都考虑到了用
JavaScript core也可以，毕竟weex框架有现成的例子参考
日志系统
推荐使用CocoaLumberjack
不要直接用阿里云接口，先传到自己的后台再说
上拉下拉
- 推荐使用MJRefresh
好几个地方遇到过
HUD
- 推荐使用SVProgressHUD
代码加限制
- 推荐使用Masonry
