可能很多人不知道，规模大的企业和IT预算多的企业的移动App大部分都是基于混合模式开发实现的。
很多做App开发的技术人员会存在一种偏见，觉得“采用混合模式，基于HTML5技术开发出来的App，体验以及功能会和原生模式开发的存在差距”，所以更愿意使用原生模式开发App。
其实市场上主流的App，绝大部分是基于混合模式开发的。典型的就是微信，除了聊天功能以外，包括公众号、小程序等都是由混合模式开发技术实现的。再比如电商领域的淘宝、京东等，旅游领域的携程，教育领域的VipKid，信息分类的58等不同应用范围的App，混合模式开发技术使其商品展示及线上市场活动的运营管理都变得非常灵活。此外，在航空、保险、银行等行业中，无论是服务客户的toC模式App，还是对员工进行管理的toE和toB的App，多是使用混合模式开发的，混合模式开发技术成为了绝对主力。
人们不禁要问“为什么这些公司和企事业单位，有着足够的预算和开发资源，还要选择混合模式App开发技术作为企业互联网化的支撑？”答案其实和企业的互联网化及数字化的需求有着直接的联系。以下4个方面，决定了越有实力的企业越需要混合模式App开发技术；同时，也是混合模式App开发技术形成不同行业解决方案的根本优势和企业选择的必要性所在。
速度的要求
“试错”这个词不但在互联网公司中广为流传，在传统公司的互联网化过程中也被广泛接受。
越来越多的CIO在谈各自企业移动战略的时候，都会提到“能否根据业务部门的一个想法，先在一周之内做个原型，快速实现，拿出去让大家看看，然后基于这个原型再修改”。这种快速发起、快速验证、快速调整的方法，已经非常流行。之所以要在短时间内先把业务从想法落到现实，哪怕App粗糙些，也要先实现出来，原因在于具有鲜明企业个性的业务的创新想法可能没有先例可循，很难考虑得特别完整。与其花费三五个月不停地思考业务需求，还不如用一两个星期先把基础的想法落实。哪怕短时间内做出的App并不能真正满足业务的需要，但是可以让业务人员的想法在这个过程中变得有据可依、有的放矢，从而为实现更完整且更切实可行的业务方案先行探索。
“业务部门的一个想法，IT部门一两周就做出来了！”这对于企业的信息化负责人而言，是很重要的褒奖。这种对速度的要求，恰恰是混合模式开发技术明显的特长和优势，一套代码可同步生成iOS与Android两个平台的App，甚至还能部分兼容微信公众号和小程序。一套代码，并不代表偷懒或工程技术的简化，而更多的是因其不仅节省了代码编写的时间，还避免了多个技术团队之间跨知识结构的协同问题，不再需要iOS与Android工程师们开会讨论差异性问题，更是大幅节省了App与服务器端联机调试的时间成本。但如果同样的功能，同样从零开始，使用传统的原生开发技术基本没有办法在一两个星期内完成有价值业务需求的实现，因为这个时间可能连不同终端碎片化和差异化的问题都不足以解决。所以，CIO为了满足业务发展的需求和数字化速度的要求，在移动战略中往往都会规划使用跨平台的混合模式App开发技术。
业务灵活性的要求
在PC时代的B/S架构中，想要实现IT系统的更新并不需要过多地考虑用户端的影响。因为作为用户入口的浏览器一直处于访问网络的状态，只要网络连通，用户随时访问网站都会获得新的功能和业务。对用户而言，并不真正地存在版本的概念。只要访问服务器，服务器的任何更新都可以随时展示到用户界面上，出现使用问题时，往往只需要清空一次浏览器Cookie基本就可以解决。
但是在移动时代，用户对版本的概念变得越发敏感。而对App的版本管理也成了CIO头痛的问题。通常因为软件开发商能力的制约，或者一些无法避免的bug，让一些已发布的App变得难用甚至会崩溃。此外，一些临时的市场活动、很少但重要的功能、一些不在规划内的产品需求调整等情况，都会直接引出同一个问题“用户必须更新一个版本，重新下载安装，才能满足上述需求”。这种看似日常的版本发布和用户更新，恰恰是传统企业信息化过程中面临的全新问题。
“能否像传统浏览器那样，用户打开的永远是新的服务和功能？”很多企业的CIO问出了相同的问题，于是大量的、不合规的软件服务商和IT程序员想出了一个“偷懒”的模式。在App中嵌入一些WebView，将一些功能采用传统网页的模式，访问服务器，动态获取。虽然表面上解决了版本更新的问题，实则产生了大量体验很差的App。
企业对业务灵活性的要求，本质是希望像微信小程序一样，可以随时发布一些新的功能，随时动态增改一些功能的入口，让用户任意使用，同时让用户的体验更好。这种对业务灵活性的需求其实需要像小程序一样有强大的混合模式App开发技术来支撑。从而达成“增量更新”“静默更新”“打开获得新功能和新体验”，而不是嵌套WebView，用网页模拟App的方法，以较差的用户体验的代价换取业务灵活的可行性。
当然，目前传统模式开发的App，特别是用Android开发的App也开始部分支持动态更新。这也恰恰说明，业务灵活性是企业互联网化、数字化进程的刚需。只是由于传统技术的制约以及软件开发团队或者服务商能力的限制，真正的原生动态更新始终没有办法大规模进入企业，实现商用。这也让企业对混合模式App开发技术的需求更为迫切，成为每个CIO的必备选项。
集中管理的要求
业务部门的互联网化意识是因为互联网的广泛普及被带动起来的。所以，传统的由IT部门主导企业信息化的态势发生了微妙的变化。过去，都是由IT部门发起信息化需求，但现在的IT部门越来越像“服务部门”。因为业务团队在不停地发起各种各样“业务+互联网”的信息化需求。这个时候，很多传统企业的IT部门领导，没认识到自己角色的转变，如果还存有拖延、不管不问、你们自己搞不定等类似的想法，就会导致当下很多企业的信息化面临的“各种移动App的彻底碎片化”“各个业务部门自己找软件开发商实现各自的需求”等问题。这不但架空了IT部门的信息化主导地位，更麻烦的是，让后续的集中管理变得艰难无比。几十家甚至上百家不同标准的服务掺杂在企业的核心系统中，甚至有些业务部门为了快速满足自己的需求而脱离了IT部门主导的传统PC核心系统，这些操作都是非常危险的。
IT部门在被业务部门要求满足业务的互联网化需求时，往往发现心有余而力不足。IT部门人手有限，实在没办法逐一满足所有业务部门的移动化需求。如果不管，就会产生前面所提到的“技术栈、开发商”碎片化的问题。这个时候，基于混合模式App开发技术的移动应用平台，就很好地解决了这二者之间的矛盾。
定标准，从而实现“集中管理”。如果企业能够制订一套统一的混合模式App开发技术和移动平台标准，各个业务部门就可以独立寻找自己的软件开发商，用各种方法满足自己的移动业务需求。平台的一致性可以带来标准化的统一。这其中包括技术标准化、开发流程标准化、代码管理标准化、项目管理标准化、验收标准化、管理和运营标准化等。
既要放，也要抓。这就是互联网时代企业信息化的要求，更是IT部门的职责。混合模式App开发技术，有望成为实现企业移动战略的利器之一。
信息化安全的要求
企业互联网化带来的根本转变就是，内网的信息化变成了外网的互联网化。
传统信息化一般包括内网、固定场所、固定网络环境和固定的设备等关键词。而移动战略背景下的企业互联网化，则同时包括外网、随时、随地、员工个人设备、4G和Wi-Fi等关键词。这些不起眼的变化，给企业的业务带来的却是天翻地覆的调整。
移动设备管理软件（Mobile Devices Management，MDM）曾风靡一时，但是购买了MDM的企业几乎无一例外地发现其很难推进。因为MDM伴随着员工自带设备（Bring Your Own Device，BYOD）。如果用企业的管理软件来管理员工个人设备，肯定会有很多人反对。所以，大部分的MDM终草草收场，只是管理了企业自己购买的一些移动设备。
企业移动化、互联网化的安全怎么保障？ 这要满足3个层面的安全，即设备安全、传统安全和云端安全。
混合模式App开发技术可以实现类似于企业应用商店（如微信公众号）的动态权限绑定和授权模式，能够支持特定设备、特定的人，也可以选择不同的子应用。此外，还可以实现随着用户工作内容的调整，根据设备编码和用户权限来实时分配全新子应用的功能。
这种基于企业移动应用商店的“子应用”模式，也是混合模式App开发技术成为企业移动战略支撑的关键。因为做得好的企业应用商店，不仅能够满足传统原生模式开发的App所不能赋予企业的、对各种安全性的需求，还实现了对业务灵活性的管理目的。
APICloud作为中国主流的混合模式App开发技术服务提供商，一直在以布道者的身份推进混合技术在国内的发展和应用。我们不仅提供技术，也提供商业服务，因此会更多地深入到大量的商业用户中去，如海尔、春秋航空、英特尔、中信证券、上汽等。我们的团队结合不同的商业场景和实际的商业客户需求，编写了《30天App开发从0到1：APICloud移动开发实战》，希望能够为不同规模的企业在移动信息化和互联网化进程中提供有价值的参考，同时也能够让从事App开发的技术人员有更多可借鉴的实战经验。
主要内容
本文从总体上介绍APICloud平台，包括APICloud应用的开发模式、设计思想、控制台使用流程等，并以一个HelloWorld App为例让读者体验一个完整的APICloud App的开发流程。
学习目标
（1）了解APICloud平台，了解APICloud相关的学习资源、入门资料和常见的问题。让没有接触过APICloud平台的读者，对平台有一个基础的了解；让学习过APICloud并且已掌握一部分技能的读者，通过本文的学习，可以快速找到需要的资料和解决问题的方法。
（2）学习如何在APICloud平台上创建、修改、调试、编译和运行一个简单的APICloud App。掌握APICloud App完整的开发流程。
要对APICloud平台做一个全面的介绍，需要花很长的时间和很多的篇幅来讲解每一个细节，而本文作者希望能用更多的篇幅来讲解一个App的实际开发过程，讲解具体的代码实现。所以，本文在介绍APICloud平台的时候，是通过抛出一个个问题，然后告诉读者应该到哪儿去找对应的学习资源，到哪儿能够找到解决问题的方案。
1.1 APICloud平台介绍
本文将从APICloud可以做什么，如何获取使用帮助，APICloud的技术、产品和生态等多个方面对APICloud平台加以介绍。
1.1.1 查看APICloud平台能力
开发者在接触一个开发平台的时候，通常个想法就是去查看这个平台的能力。特别是那些想做App的、有着明确需求的开发者，他们会非常关心自己的需求在这个开发平台上是否能够满足。所以，本文开篇就先来解决这个开发者普遍关心的问题，读者可以带着自己预先想好的需求来了解APICloud平台，昆山做app公司了解如何能够快速地在APICloud平台上查找相关的能力。
1．通过官方文档快速搜索功能模块
查看APICloud平台提供的能力，一个基础也是有效的方法就是查看APICloud的API文档。
APICloud官方网站中的文档页面如图1-1所示。如需要查看视频播放的功能，可以在文档中搜索“视频播放”，搜索结果如图1-2所示，可以看到在APICloud平台上有多种提供视频播放功能的模块，如videoPlayer（播放本地视频）、moviePlayer（播放网络视频）、polyvPlayer（保利威视播放器）、baiduPlayer（百度播放器）等。
图1-1
图1-2
点击其中一个搜索结果，查看模块的详细文档。比如点击“videoPlayer”之后可以看到这个模块对于视频播放提供了很多API，这些API基本覆盖了一个视频播放器所有常见的功能，如图1-3所示。
图1-3
再比如要查找支付功能，可以在文档中搜索“支付”，通过搜索结果可以看到在APICloud平台上有很多个提供支付功能的模块，如aliPay（支付宝）、wxPay（微信支付）、unionPay（银联支付）、paypal（PayPal支付）、iap（iOS应用内支付）等；也有ping++、beeCloud等第三方聚合类的支付模块。点击每个模块均可以查看具体的API详情。
读者想了解APICloud平台有哪些能力，简单的方法就是到APICloud官方文档中去搜索相应的功能，这样就可以一目了然地知道APICloud平台有没有相应的模块来支持自己想要的功能。
2． APICloud能力支撑体系
目前在APICloud平台上已经提供了600多个模块，上万个API。这些API基本可以覆盖一款App所需的所有常用功能，为方便表述，它们被分为“平台使用”“基础功能”“界面布局”“设备特性”“功能扩展”和“开放服务”六大类，其分类与具体包含内容如图1-4所示。
图1-4
1.1.2 开发模式、技术语言和平台定位
很多APICloud初学者会关心这些问题：APICloud App的开发模式是什么样的、使用什么技术语言、目前自己的开发团队是否适合使用APICloud开发App、整个APICloud的学习曲线是什么样的、入门简不简单等。
1．开发模式和技术语言
APICloud应用的开发模式是使用标准的HTML、CSS和JavaScript+APICloud扩展API来进行App开发，如图1-5所示。APICloud的App开发使用的是标准的HTML5技术，针对标准HTML5所不具备的功能或是用HTML5实现体验不好的功能（这些功能也是开发者在App开发过程中非常常用的功能）。APICloud提供了600多个扩展模块和上万个API，通过这些模块和API来扩展HTML5的功能，满足App的开发需求。
图1-5
2．扩展API调用方式
APICloud扩展API的调用方式与调用标准的JavaScript方法是完全一样的。APICloud引擎的核心API是放在window.api这个对象下面的，这个对象是APICloud在JavaScript全局作用域内扩展的唯一一个对象，可直接调用。如果想调用某个模块下面的方法，可以通过require的方式动态引入，通过在api.require方法的参数中指定某个模块的名称来引入相应的模块，然后调用模块下面的方法，具体演示如下。
1 //核心API在window.api对象下，可以直接调用 2 api.methodName(param, callback); 3 //扩展模块需要require引入，遵守CommonJS规范 4 var module = api.require('moduleName'); 5 module.methodName(param, callback); 6 param: {} //参数，是一个JSON对象 7 callback: function(ret, err){} //回调函数，是一个Function对象，异步方法调用的结果通过此函数返回
所有API的调用方式都是相同的，个参数是一个JSON对象，承载着要传递给模块的信息；第二个参数是一个callback函数。APICloud大部分的API调用都是异步方式，在调用的时候，要指定一个callback函数，当这个API操作完成时，操作结果将通过该callback函数回调。
一些常用的调用方式，比如打开一个新窗口，可以调用api.openWin()；打开通讯录可以调用api.openContacts()，录音、图片缓存等也是调用相应的方法。如果想去加载文件系统模块，可以通过api.require("fs")来加载fs模块，然后调用fs模块下面的方法。使用条码扫描模块也是类似的。示例如下。
● 打开新窗口：api.openWin()。
● 打开系统通讯录：api.openContacts()。
● 录音：api.startRecord()。
● 缓存网络图片：api.imageCache()。
● 加载fs模块：var fs = api.require('fs')。
● 新建一个文件：fs.createFile()。
● 加载二维码/条形码扫描模块：var scanner = api.require('FNScanner')。
● 打开二维码/条形码扫描：scanner.openScanner()。
APICloud技术是基于标准的HTML、CSS和JavaScript技术，并在标准的JavaScript基础上扩展了一个核心对象-api对象和数百个模块。这些模块可以使用api.require函数载入，并使用操作标准JavaScript对象的方式调用上述模块列举出方法。
3．扩展API的作用
读者可能会问，APICloud为什么要扩展这么多API呢？其实APICloud所扩展的API都是标准的JavaScript所不支持的方法，或是用标准HTML5来实现但体验不好的功能。读者可以把HTML5理解成一门技术、一门语言，但是它还没有达到一个平台的水平。这就是APICloud为什么要做这些扩展。APICloud所有的扩展主要是围绕以下这4个方面进行的。
兼容性：在PC互联网时代，浏览器具有多种内核，JavaScript框架产生的初原因就是为了实现JavaScript代码在各种浏览器上的兼容和适配。在移动互联网时代，虽然在主流的手机系统中，Android和iOS的浏览器内核都是webkit，但是出于商业原因，谷歌从webkit中建立了一个新的分支，叫blink。现在两个分支的主要贡献者分别是苹果和谷歌，所以未来这两个内核的兼容性问题会一直存在。
实用性：
Page不等于App，标准的HTML、CSS和JavaScript规范更多是用来定义网页和文档的，例如现在的一些框架都在讲SPA结构，它是以单页面为主的，很多HTML标签是针对于文本信息展示的；而App则不然，App更多是强调功能和体验，在原生系统中有很多的组件，HTML5标签和Native组件的设计规范是完全不同的。所以，想用标准的HTML5技术开发一个App是不现实的，人们不能直接把为WebPage所制定的规范直接搬到App上。
B/S架构与Client/Cloud架构：在PC互联网时代，终端产品的主要架构还是B/S架构；但是在移动互联网时代，终端产品的主要类型是App，而App是一个完整的Client/Cloud架构。在移动端，实现界面和功能，在云端提供数据和服务。页面布局是存放在移动端的，功能实现也是在移动端完成，所以用户在使用时可以感受到App的启动、页面渲染和布局展示是很快响应的。
速度、交互和体验：这3个问题是用HTML5技术直接开发App的大挑战。其实，如果使用HTML5技术实现一个界面，渲染之后显示出来，用户看到这个界面时并不能立刻分辨出它是用HTML5实现的还是用Native技术实现的。但是当用户做一个交互，点击一下，体验一下响应速度或者做一个手势，触发一个动画，这时用户就可以非常清楚地感受到，并能分辨出该界面是用Native技术开发的还是用HTML5开发的。所以速度、交互和体验也是使用HTML5技术开发App必须去解决的问题。
持续性、静态标准与动态标准：HTML5的定稿花了7年时间，并且整个标准的迭代是缓慢的；而Android和iOS每一次版本更新都会新增很多功能，这些新增的恰恰都是当前行业里需要的功能，但这些功能很难快速通过制定新的HTML5标准进行更新，并在各个浏览器里支持起来。那会是一个非常漫长的过程。
扩展性：在开发一款App的时候，开发人员需要扩展很多的功能，有时候要和行业特点结合，有时候还要跟硬件结合，这就会用到大量国内的开放服务，如推送、直播、智能识别等。所有的这些功能，标准的HTML5规范中都没有定义，所有的标准浏览器引擎也没有默认支持。
总的来说，APICloud扩展的所有功能都是标准HTML5所没有的，如果HTML5有并且在App中运行起来没有任何问题，APICloud平台也没有必要去做这个扩展。APICloud所有扩展的功能其实就是为了去解决HTML5在兼容性、实用性、持续性和扩展性等方面的问题。
AA57865ERT34GSD
