iOS相关感悟和观点

简要回顾

从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，但是平时见得多的还是CocoaPod

• Carthage可以强化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编码

• 引入MGJRouter

• 具体跳转写在load函数中

• 具体的url写在集中文件中，最大程度公开

• 可以考虑像DNS一样，对url定义做一份对照表，取个有意义的名字，方便使用

• 将体验做得像网页访问一样

• 参数传递尽量不要通过url携带，应该在数据层或者逻辑层采用其他通讯方式。界面层尽量薄，只做显示。做侦听，提供页面刷新函数更新。

MVVM vs MVC？

• 个人偏向MVVM，但是遇到的基本上是MVC

• ViewModel只做显示逻辑，不承担数据和业务逻辑等功能，比如网络访问就不应该在这里做。这个只是将界面元素的接口。

• 增加一个xxxServiece，并且是模块级的，为页面提供逻辑和数据服务，同时为多个页面提供服务。

• Controller不做具体的业务，只是页面的生命周期，发起函数调用即可。

网络？

• 现在的URLSession已经很好用了，完全可以自己写

• 没信心的话，就选AFNetworking好了

• JSON解析直接用系统的，不需要引入其他第三方库

• 字典模型互转，可以考虑YYModel

• 字典转模型还是独立出来比较好，放在网络模块里反而不好管理。网络模块的输出，还是直接数组套字典比较好。

本地缓存？

• 选YYCache

• 不用数据库，更不用CoreData

图片上传下载？

• 现在的URLSession已经很好用了，完全可以自己写

• 本地缓存可以用YYCache

• 图像解码，加快显示，这块自己写比较麻烦

• 可以选择YYImage
  YYWebImage

• 当然，选择SDWebImage也是合理的

和H5通讯

• 目前还是UIWebView比较成熟，WKWebView还有很多坑，不好用

• 建议采用第三方库WebViewJavascriptBridge
  iOS、Android、JavaScript三端都考虑到了

• 用JavaScript core也可以，毕竟weex框架有现成的例子参考

日志系统

• 推荐使用CocoaLumberjack

• 不要直接用阿里云接口，先传到自己的后台再说

上拉下拉

• 推荐使用MJRefresh
  好几个地方遇到过

HUD

• 推荐使用SVProgressHUD

代码加限制

• 推荐使用Masonry

键盘管理

• 推荐使用IQKeyboardManager