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（邮件提醒）为1484、Star为22569，Fork为2652，火得一塌糊涂。但是热闹过后，又会有多少人真正关注？苹果官方给出了开源后的诸多好处和美妙的前瞻，这不过是官方的PR稿子，这不由得让我想起了.NET当初开源，也是叫好声一片，但实际效果并不理想，参见以下报道：

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

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

原文：http://www.cnblogs.com/pals/p/5100559.html