【51CTO.com原创稿件】最近被炒的很热的“iOS烂大街”风波还未平息，Android安全话题又被推向了风口浪尖，小程序又借势在中国掀起一篇惊涛骇浪，前途未卜。移动领域在近期动作频繁，究竟是市场导向还是技术改革导致？这个话题我们无法一笔定论，因为不同角度有不同的看法，不同人也有不同观点。
简单回顾一下整个移动开发领域的发展过程，iOS出现于2007年，Android诞生于2008年，而通常在国内的开发技术会晚3年左右，所以，国内的移动技术发展基本是从2010、2011年左右开始，在2012，2013两个系统达到热潮，2015年慢慢回落。
而面向企业的移动业务一般在2012年左右得到开辟，2013年左右已经成型了，2014之后已经很大程度上停在了拓展和维护上，基本很少看到产品的创新。在2013年创业潮其实也带来了一些新的移动产品，不过令人遗憾的是从2015年之后，只有一小部分的明星创业产品得到了收益，很多创业公司都相继倒闭。
如今，在移动APP需求上也仅剩下中小企业当中的一些政府项目，以及传统行业的需求，再者就是目前比较流行的IOT移动端开发。对于个人开发者和初创公司，客观从2012年左右移动开发门槛是最低的，不过学习成本和推广成本相对增加。相反，在2014年以后，互联网行业移动项目持续增长，门槛相对比以往提高了，但是学习成本相对降低，有不同的途径自我学习，或者选择第三方去完成主要开发工作。
饱和的移动应用市场
在移动领域，终究还是理性战胜了感性。对于目前来说，移动APP的推广成本远远大于开发成本，也许是因为前车之鉴，开发者在开发APP上线时，在运营、推广成本的压力上，基本都是知难而退。而对于有需求的企业，类似教育、直播、IOT这种业务驱动型的应用反而较为热门，据APICloud CTO邹达介绍，每天在APICloud上的需求就有几十个，整个定制平台每个月差不多有二十多个项目在实施。而对于个人、初创企业、或者凭着idea等方式开发移动APP的用户越来越少，因为没有业务的结合、完全凭一个idea，没有任何的经验或者资源，基本上已经没有存在。
物联网在2017年重围主要趋势
但是这两年由于小程序、流应用、微应用的爆发又重新点燃了开发者的热情，不但解决了技术学习成本的问题，在运营推广上，又有了全新的模式。这似乎对于开发者来说，确实有很强的诱惑力。无论是唱好唱衰，这些开发模式最终还是要结合业务，对于仅有idea的开发者来说，没有任何的基因去建立一个服务用户的纽带，第二是对于初创企业，在移动APP的开发需求、业务结合、客户对接上存在很多缺口，很难一步到位。
邹达也表达，APICloud从去年6月份开发到现在，没有任何一个客户想做小程序应用。从每个月差不多的20多个项目中，包括他们评估的小程序需求比例还不到1%。这也是由于需要紧密结合应用场景，主要的优势在业务之上，并非用来保存APP内容或者功能的体现。
模块定制为移动APP开启新模式
从2016年开始，一些前端框架已经趋于稳定，我们可以看到诸如 React 这样的框架在一些大型项目中的采用。除了这些常规的移动 Web 应用，在去年九月底微信小程序的火热，通过激活线下流量，连接线下场景，开启了移动 Web 的一扇新门；Google 推出的 PWA 也让越来越多的开发者看到了转型移动 Web 的更多可能性。从技术的角度，在移动上前端技术代替原生的趋势不可避免，包括H5、跨平台、JavaScript都会慢慢取代整个开发模式的转型。
但是从产品的角度，整个APP的形态、商业模式却很难撼动。恰好在2016年，资本寒冬席卷了整个互联网市场，创业者和企业如何从产品和商业模式的角度如何用合理的成本，在更短的周期内去验证创新的想法变得更加重要。“省”字当头，“省时间”更是重中之重。APICloud邹达认为移动应用市场从自主研发到App定制服务平台的转型正是充分发挥快速开发的优势，帮助这些创新从想法变成现实。
“App定制平台”的多重优势还解决了很多传统App定制服务的痼疾，通过“沟通不畅”“实施过程不透明”“失败风险高”“开发周期长导致无法挽回”“实施方能力弱”等等几个方面解决了中小企业和初创企业开发需求的问题：
1、 标准化技术：采用标准化的开发技术，实现高效率、低投入的开发模式。
2、 官方签约保上线：严格把控项目质量和开发周期，承诺每一个项目顺利上线至苹果和各大安卓应用市场。
3、 专业的管理体系：定制服务将App开发分为需求预评估、产品原型设计、UI设计、App端开发、服务端开发、接口联调、测试及验收7个阶段。
4、 完善的沟通方式：企业客户与项目负责人通过视频会议的方式进行交流，便捷、高效、可视化。
5、 严格的验收体系：通过开发团队严格按照标准化验收体系，将前后端源代码、需求文档、设计文档、操作说明、测试报告等十几项交付物完整递交给企业客户，方便项目的更新迭代。
安全隐患日益凸显
尽管APP定制服务在整个过程中的安全得以保证，但是网络速度正在变得越来越快，基于HTML5开发的跨平台应用也越来越多，背后隐藏的代码盗取问题也越来越严重，安全在今年的移动开发领域一直拥有极高热度。
根据 Gartner 的预测，75％ 的移动 app 甚至没有通过基本的安全测试
而苹果与FBI之间的激烈冲突也再次强调了保护用户隐私的重要意义。大型企业开始将重点转向提升核心组成部分的安全水平，苹果公司亦在WWDC大会上宣称其将在硬件层面确保设备拥有完整的安全防护机制。另外，加密机制在这一年中同样受到重视。
而目前很多企业所使用的代码保护解决方案中，对于网页代码保护的方式更是治标不治本，无法从根本上去实现真正的代码加密。
1、 JS、CSS代码压缩
通过互联网上提供的CSS、JS压缩工具，只起到了减少文件体积、提高加载速度，能够提升程序的执行性能，但是根本做不到加密，开发者完全可以利用很多方式进行还原。
2、 混淆HTML、JavaScript、CSS代码实现保护
这是最通常使用的方法，有很多代码混淆工具，如Packer、Javascript Compressor、JSObfuscator等，帮助开发者保护代码，然而代码混淆后会降低程序的执行性能。同时也不乏一些代码格式化工具的存在，如JSBeauty、VS的Javascript编辑器等，用工具将混淆的代码重新格式化后，代码全部恢复为明文，无法做到代码版权保护。
3、 仅对HTML文件加密，而对JavaScript和CSS文件不加密
仅对App中的HTML文件进行加解密处理是比较容易实现的，HTML文件可以经过加密后保存在App安装包中，而应用引擎在将HTML文件交给浏览器引擎解析之前可以先对加密的HTML文件进行解密，然后再将解密好的HTML文件交给浏览器解释执行，而在整个浏览器执行过程中，对JavaScript和CSS文件的解密处理时机还是比较难控制的。但是在一个实际App项目中，大量的功能实现都是放在JavaScript文件中的，所以，这种局部加密的方式还是存在较大的局限性。
4、原生应用的代码加固和加密厂商
由于Android应用使用Java语言开发，Java语言存在可以反编译源码的问题，所以行业中针对apk出现了加固、加壳产业，很多厂商可以提供加固服务，比如360、梆梆安全等加固产品。然而应用加固通常只能对原生代码进行加密加固保护，不能对HTML、JavaScript、CSS等网页代码进行加密保护。
邹达认为，无论应用如何进行加密，都很难保证绝对的安全，但是起码在自己的平台上做APP，起码要把我们能想到的都应该有相应的机制。
第一， 代码安全，因为目前基本上大部分的移动应用都基于H5开发；
第二， 数据安全，保护应用所有数据的稳定性；
第三， 功能安全，针对API的调用和控制，包括大企业API调用的限制。
而对于移动安全问题，苹果在去年也通过了禁止JSPatch热修复框架，其原理是通过JS脚本调用和替换任意OC方案，达到bug修复的目的。也许是为了提升安全和可控性问题，采用JSPatch热修复框架后，这种安全和可控性正在被挑战。
摘掉主流移动开发安全的帽子
通过代码加密功能可以从HTML源头开始，邹达给出了基于RC4加密算法提出了一套“全包”对称加密解决方案，可以在云编译的时候对安装包中的HTML、CSS、JS代码进行加密处理，从HTML5移动应用开发的源头开始，很大程度的保护源代码的知识产权。
1、一键加密，运行时解密：开发者只需要在APICloud上编译时选择代码加密，云服务器在编译App安装包时就会将该App的HTML、JavaScript、CSS代码自动加密，同时该App在运行过程中实时解密，App退出即焚，不留下解密痕迹；
2、零修改，零影响：APICloud的加密方式不改变代码量大小，不影响运行效率，针对代码的加密方案不会修改开发者的任何代码，加密后的代码不会比加密前多出一个字节，同时，端底层嵌入了特殊的处理方案，保证代码加密前后，App的运行效率、使用体验不受影响；
3、自动，智能，方便：开发者在APICloud平台开发App的过程中，无需针对代码的保护做特殊的处理，按照正常的开发流程进行即可；
4、安全盒子：在保护开发者代码的同时，针对App的各种潜在安全问题，APICloud定义了一个“安全盒子”，仅对盒子内代码进行加解密保护，盒子外代码灵活处理；
5、重新定义资源标准：APICloud底层在处理被保护代码时，重新分配了App资源的使用方式，统一资源管理，实现加速资源加载，节省系统开销，因此，加密代码后的App在运行过程中甚至能提速运行；
加密前
加密后
我们相信，这种代码加密的形态也会成为未来行业内非常重要的规避盗版的方式。
全端进入HTTPS协议的使用
除去上面这些内部因素，移动 Web 应用还饱受外部因素困扰。在2016年，我们发现越来越多的移动站点正深受运营商劫持的影响，由于 HTTP 协议是明文的，而流量都要经过运营商，因此运营商可以轻而易举地在页面中植入广告。这时，解决问题的有效办法就是全站使用 HTTPS。
邹达认为，现在移动端基本都走HTTPS服务器，支持和双向或者单向加密，通过握手阶段用来建立SSL/TLS连接，达到对通信加密效果。SSL/TLS协议是为了解决这三大风险而设计的：所有信息都是加密传播，第三方无法窃听；同时具有校验机制，一旦被篡改，通信双方会立刻发现；配备身份证书，防止身份被冒充。
互联网是开放环境，通信双方都是未知身份，这为协议的设计带来了很大的难度。而且，协议还必须能够经受所有匪夷所思的攻击，这使得SSL/TLS协议变得异常复杂。
HTTPS对于HTTP来说确实是安全的多，但是由于握手机制会导致速度有些缓慢，但是邹达认为，第一次握手会稍微慢点，但是过后就比较非常快。很多大企业以及内部都在使用，都是私有云，相当于每个应用都绑定了证书，而银行等金融行业，基本都是购买CI认证的证书。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
