2015年，是移动领域新技术取得极大丰收的一年。

iOS篇

2015年，iOS有太多的事情发生，每一次事件都促进了iOS技术的一次飞跃。

---

首先是苹果宣布从2015年2月1日开始，全部上传至App Store官方商店的新iOS应用都必须支持64位。为此，全部的App在打包时要兼容32位和64位，虽然某些机型上速度快了很多，可是App的体积却大了很多。 
2015年应该是iOS的“瘦身年”。各大公司在发现本身的iOS App超过了50M以后，纷纷开始组织iOS团队对App进行减肥，而后咱们就会发现，体积变大，不光是兼容64位致使的，兼容64位只会致使.a文件的增长，而资源文件是致使体积变大的另外一个因素。 
先说资源文件，包括如下几点：

• 减小图片和音频文件的大小（这一点携程的App作的不错，每一个图片都不超过100k，甚至50-100k之间的图片都不多，而不少App之因此体积大，是由于其中有不少1M以上的图片）。
• 对于PNG图片，因为它内部保存了额外的分层和透明通道信息，统称为EXIF，因此它会比JPG图片大一些。App开发推荐使用PNG图片是由于XCode会在打包时压缩PNG图片的大小。咱们能够写一个脚本，在打包前，把PNG图片中这些多余的信息，删除掉。
• 单色图片使用使用字体文件。关于字体文件的技术，也就是IconFont，网上有不少例子，同时适用于Andorid和iOS，我这里就很少说了。
• 使用.9图。之所周知.9图是Android的技术，能极大减少图片的体积，却不知，iOS也有相似的实现方式。
• 动态下载表情包。把聊天时用到的表情图片，作成从服务器下载zip包的方式，而不是打包在App中。
• 清除再也不使用的图片。每次迭代作新需求，都会致使一些旧图片再也不使用了。XCode不提供检查未使用图片的功能，那咱们就须要本身写一个脚本，每次发版前，对整个工程检查一次。

再说.a文件。.a文件是编译文件，这个文件大，说明代码多。因而咱们检查项目中的代码，真的要写那么多行吗？其实有不少优化的空间。

• 冗余的类和方法。这些冗余仍然是由于作新需求致使的，忘记删除不用的类和方法，须要写脚本查找，按期删除。
• 类似度极高的代码片断。初级程序员在写代码时，喜欢把一段代码从A类粘贴到B类中，而后修改其中的几个变量名称，这个功能就算作完了。因而两段类似度极高的代码就产生了。 
  稍微懂得些面向对象思想的人，都知道这时候须要把这样的代码抽象出来，好比说在Utils类中新建一个方法，而后要用到这段逻辑的人调用Utils类的这个方法便可。 
  但并非全部的程序员都有这样的境界，即便是有几年经验的人，也会由于急着下班二人世界或者给孩子换尿布而采用复制粘贴大法敷衍了事。长此以往，冗余代码就多了，包的体积天然就大了。为此，咱们须要有一个检查代码类似度的工具。在iOS领域，我推荐Simian这个工具。有兴趣的读者能够尝试一下，对大家的项目使用一下这个工具，看能找出来多少类似的代码来
• 使用代码生成UI，而不是使用Xib或Storyboard。通过测试，对于同一个页面，使用代码而致使的.a文件增长的体积，大于Xib的体积。是时候该返璞归真，考虑使用Xib来布局了。Xib之因此广受诟病，是由于XCode这个IDE工具很烂，另外一个缘由是咱们使用的少，人老是会抵触陌生的事物，在使用Xib的过程当中遇到障碍了，就又转到写代码的路线了。
• 使用Hybird方案来代替iOS原生代码。我作过尝试，一个功能模块，致使.a文件增长3M，但使用Hybird却只有1-2M的样子，并且这1-2M中有一部分打包放在App中，另外一部分则作成增量下载，从而从总体上减小App包的大小。其中Hybird的增量包技术是关键。
• 编译选项的优化。好比说Strip Link Product设为Yes啊，Make Strings Read-Only设为Yes啊，去掉异常支持啊，都能减小包的大小。此外，常常检查LinkMap文件，也是控制瘦身的一个办法。

微信团队2015年9月中旬发布了iOS微信安装包的瘦身经验，其中有不少实际经验。文章地址以下： 
http://mp.weixin.qq.com/s?__biz=MzAwNDY1ODY2OQ==&mid=207986417&idx=1&sn=77ea7d8e4f8ab7b59111e78c86ccfe66&3rd=MzA3MDU4NTYzMw==&scene=6#rd

---

其次是春节期间，某款知名App的后门泄露事件。所谓后门，就是App开发期间，方便开发人员和测试人员的一些功能，好比说： 
开发人员和测试人员能够随意切换到任意服务器（线上环境、测试环境）进行开发测试工做。传统的作法，这些地址是写死的，每次打包出来的App只能在固定的一个环境下运行，咱们迫切须要一个后门页面，可以灵活配置。固然，线上用户是不能看到这个后门的，必须作一个相似于彩蛋的功能，好比在设置页的某个位置连续点100次，才会弹出一个密码输入框，只有输入正确了，才能进入后门页面配置服务器地址。 
考虑到发布到线上的App，存在这样的彩蛋是很是危险的。因而咱们须要一个Flag标记，在发布App时要把这个值设置为false，从而关闭后门入口。但人老是会犯错误的，即便有测试团队把关也仍是会有纰漏。因而，国内某款著名的App在春节期间就把这样的后门漏出来了，也许是开发或测试人员急着回家过年。这是此次无意之失，让咱们领略了这款App强大的后门里隐藏的功能。好比说，

• 服务器切换功能（上午已经介绍过）。
• 记录App的崩溃信息。有这样一种场景，测试人员在测试过程当中发现的一个崩溃，虽然也记录在Bug仓库中了，可是等开发人员去修复的时候，却难以再现这个崩溃了。若是能把崩溃记录到App本地，那么测试同窗提bug的时候，就能够把崩溃信息一块儿贴出来。
• 提供一个后门页面供Html5团队进行调试，该页面内置一个WebView，加载Html5团队正在开发的Html页面，要支持调试。
• 对App进行流量测试，统计某个页面所花费的流量，包括调用MobileAPI、下载图片、上传文件、XMPP聊天等等。其中，从App启动到首页加载完成所花费的流量是咱们关心的一个关键点，而手机待机时，App所花费的流量也是咱们所关心的。咱们须要这样一个后门页面，看到这些数据统计。
• 对App进行电池电量消耗测试。须要有个后门页面记录每次打开App和退出App的时间，以及这段时间内咱们的App所消耗的电量。为了确保数据的准确性，须要确保手机上只安装了一个App，并且处于相同的网络环境下，好比3G。
• 测试某个页面请求了哪些MobileAPI接口，打印出调用这些接口时输入的参数和返回JSON数据。这样就可以在线上App发现某个页面有问题时，及时在App后门中检查数据是否正常，而不用App开发人员和MobileAPI开发人员坐在一块儿逐行联调代码，极大的节省了人力。

在窥探到后门中这许多先进技术以后，各家无线团队纷纷在本身的App中增长相似的功能，只是不知道最初把后门漏出来的那个哥们离职了没有？

---

2015年最犀利的技术首推JSPatch，使用这门技术，iOS能够快速修复线上bug而不须要从新提交AppStore审核。 
这门技术最先起源于大众点评的屠毅敏的一个开源项目WaxPatch。它是经过重写runtime的class_replaceMethod方法，从而能够修改任何一个类的任何一个方法，该项目的GitHub地址为：https://github.com/mmin18/WaxPatch 
WaxPatch上支持的语言为Lua，也就是说，创建了一套Objective C和Lua语言之间大部分语法的映射关系，咱们只要熟记这些转换语法，就能快速把一个Objective C方法翻译为Lua方法。而后咱们把须要修改的Lua方法所在的类文件打包成zip，由App在启动的时候下载zip包并解压到本地目录，因而咱们会看到，当运行到旧的Objective C方法时，实际执行的是下载到的Lua方法。这一切都由于Objective是一门动态语言，咱们能够基于此制造一些“黑魔法”。 
可是WaxPatch从2013年10月起就再也不更新了。当2015年2月苹果宣布全部上传至App Store官方商店的新iOS应用都必须支持64位，这时咱们发现WaxPatch并不支持64位。这就间接致使了不少已经在项目中使用了WaxPatch的App，必须砍掉WaxPatch热修复功能，后来社区有人给出了WaxPatch的64位解决方案，才让热修复技术能继续向前发展，这个项目的的GitHub地址为：https://github.com/maxfong/WaxPatch_X64/commits/master 
尽管如此，WaxPatch仍是有不少局限性。好比说它不支持多线程、不支持Block，不支持结构体和结构体指针这两个类型，这就致使了当咱们在程序中使用了这些语法时，是没有机会把这些语法转换为Lua代码的。 
经过上文的分析，咱们知道，只要重写runtime的class_replaceMethod方法，就能够热修复Objective C中的任何类的任何方法，WaxPatch只不过使用了Lua做为新方法的语言载体，咱们彻底可使用Python、JavaScript这样的脚本再写出一个新的Patch。 
这时终于轮到JSPatch登场了，它是由腾讯的陈振焯（英文名Bang）于2015年5月编写的开源项目，从名字就能猜出来，它使用的是JavaScript语言做为新方法的语言载体，GitHub地址为：https://github.com/bang590/JSPatch。这个项目解决了上述WaxPatch所不支持的那些语法。目前这个项目还在每周持续更新中。 
JSPatch还有一个亮眼的功能，就是支持一键生成，把一个Objective C方法翻译为JavaScript的方法。按照这个思路再往前走一步，就是iOS的“插件化编程”。咱们能够把一个模块所涉及的全部页面都使用Objective C先实现了，而后一键生成JavaScript方法代码，打包成一个zip包，这就是插件化编程。不得不说的是，对大量的代码执行反射操做，性能是一个问题，究竟能往前走多远，2016年，咱们拭目以待。

---

2015年注定是iOS领域不平凡的一年，好比说，在9月份大规模爆发的XCodeGhost病毒。IDE也能携带病毒，这是我一个.NET出身、用惯了Visual Studio的程序员所不可理解的一件事。只要是非官方下载的XCode，都有可能经过CoreService库文件进行感染，使用有毒XCode开发的App，都会感染病毒。这就像给病人动手术，结果手术刀没消毒，病人就会有生命危险。 
关键是AppStore还没法检测出病毒，传闻将近800款App感染了这一病毒。 
尽管过后当即有人站出来，声明本身是XCodeGhost的做者，并宣称是个“苦X程序员的”、“无害的”、“实验”，同时认可本身出于私心，在代码里加入了广告功能，并说本身在10天前，已主动关闭服务器，并删除全部数据。 
但不少证据代表，这是一个蓄谋已久的恶性事件。 
当号称“封闭安全”的AppStore也再也不安全，咱们还能相信谁？

---

接下来介绍React Native。这是Facebook在React.js Conf 2015 大会上推出了基于JavaScript的开源框架。同时支持iOS和Android，Github地址为： 
http://facebook.github.io/react-native/ 
首先，React Native不是依赖于WebView的，因此它不是Hybird。React Native是把js翻译为Objective-C，却是与JSPatch有些渊源 
我一直在关注着这门技术的发展。但目前看起来，还很不成熟。尽管在2015年的各类技术大会上，React Native出尽了风头，但据我所示，目前也就BAT这种公司愿意烧钱让团队去尝试使用。 
有关React Native的更详细介绍，推荐你们看下面这两篇文章：

• 我对 React Native 的理解和见解：http://div.io/topic/851?utm_source=tuicool&utm_medium=referral
• React Native概述：背景、规划和风险：https://github.com/tmallfe/tmallfe.github.io/issues/18

---

2015年iOS的最后一件“振奋人心”的事情是Swift的开源。 
Swift从面世伊始，就号称要取代Obejctive C成为新的iOS开发语言，可是几年事后却仍是一个很小众的语言。没据说有哪家大公司的代码全都切换到Swift了。也许是我孤陋寡闻了，至少在App应用领域是这样。 
从2015年12月初Swift开源，截止到本文写做期间，这个项目的Watch（邮件提醒）为148四、Star为22569，Fork为2652，火得一塌糊涂。可是热闹事后，又会有多少人真正关注？苹果官方给出了开源后的诸多好处和美妙的前瞻，这不过是官方的PR稿子，这不禁得让我想起了.NET当初开源，也是叫好声一片，但实际效果并不理想，参见如下报道：

做为有着十多年编程经验的码农，我不能泼太多冷水。我不想浇灭刚入行的小朋友的社区热情。究竟Swift开源后能产生什么惊天地泣鬼神的做用，2016年，请用事实验证吧。