移动开发的跨平台实践及在企业中的应用
目录：
一、移动跨平台已成为必然
二、驱动原生是移动跨平台的最佳选择
三、以工程化的形式解决移动跨平台问题
四、普元在企业移动跨平台上的优秀实践
五、总结与展望
一、移动跨平台已成为必然
随着移动更加快速的发展，移动IT建设已经是企业不可回避的事情；在这过程中必然会面对如何快速的、低成本的开发出多平台使用的APP这样一个问题，所以首先我们就来说说是什么因素让移动跨平台开发成为大多数企业移动建设的一种首选。
我们一直在说移动跨平台，那跨平台到底应该是个什么样子？开发一套代码能打出多平台运行的安装包就算是移动跨平台了吗？那其实个人觉得不应当只是这么简单，它不仅仅是指能开发跨平台运行的APP，还应包含如下内容：
- 拥有集成的跨平台开发工具
- 同一套APP代码能够跨平台运行（业务代码）
- 能做到多屏适配
- 具有跨平台的消息推送能力
- 具有统一的跨平台开发调试能力
了解了跨平台的大致内容，那为什么我们要做移动跨平台？虽然说移动终端用户量、活跃量巨大并且仍在每年递增致使企业IT建设需要向移动化转型，这难道就意味着移动建设一定要跨平台？这个问题其实不太容易从正面回答，我们可以换个角度来想：如果不跨平台、对开发人员来说可能就意味着既要编写android代码又得会iOS，得忍受低下的调试效率，还得处理不同机型的样式、兼容性等问题；对企业而言如果不跨平台而又要保证应用按时上线则可能需要投入更多的人力成本（人员数量、人员质量）参与开发。（企业更希望的是希望降低成本、扩大收益）。
另外正面来看通过移动跨平台能给企业和开发人员带来了如下利好：
- 降低企业成本投入
- 提供统一稳定的接入平台
- 提供统一的版本管理，一套业务代码能多平台运行
鉴于这些，我们是需要进行移动跨平台建设的。
二、驱动原生是移动跨平台的最佳选择
既然需要移动跨平台，那应该如何建设呢？首先需要明确的是有哪些技术手段能支撑移动跨平台的实现，然后再考虑如何优化解决跨平台过程中的问题。
在技术支撑手段的选择上，当然这里大家看到标题已经知道了，那为什么说驱动原生是当下移动跨平台的最佳选择呢？
移动开发从web流经历原生到现在的跨平台开发，其中跨平台开发目前有两种技术实现手段：
1）Hybrid
2）驱动原生
驱动原生作为时下最领先的移动开发技术手段，它到底是什么？相比Hybrid混合开发其优势又何在？
首先驱动原生是一种运行态时，可动态的与操作系统直接交互，让操作系统提供原生UI渲染方式的移动开发技术。相比Hybrid （eg. Cordova），驱动原生不用Webkit 做UI渲染因此在性能和体验上更好，对网络依赖性相对更低，同时能提供更丰富的原生能力（指纹识别、蓝牙）和更方便的本地调用（数据库存储）；当然它也不是编译型原生（eg. Xamarin ），编写的代码无需编译成对应平台的二进制即可运行。
我们来看一下web、驱动原生型、原生这三种APP在性能上的对比（下图），可以看出驱动原生手段开发的APP在系统资源消耗上更接近原生APP，低于web形式的APP。因此在运行时驱动原生APP也就相对稳定、不会因为资源消耗过高而被操作系统关闭部分服务或者杀死。同时驱动原生开发的APP能实现多级热更新，不仅可以上APPStore进行大版本更新也可以只更新一个界面的内容；这样既提升了业务响应、更新、上线的速度也从更细的粒度上让应用变的更可控。
如果选择了驱动原生，那该如何去搭建他的框架？实现方式可能会有多种，我们普元选择的是一种称之为JavaScript Framework for Native Mobile的实现（可简单理解为JS驱动原生）。在2016年，Gartner将JavaScript Frameworks for Native Mobile列入“Advantage”（优势）技术，认为它能够支撑未来5到10年移动发展，目前该技术流派常见的只有我们普元、阿里的Weex和Facebook的ReactNative。所以无论从性能、体验、业务的快速响应上考虑还是从技术先进性上考虑，驱动原生都是目前移动跨平台建设更好的选择。
那到底该如何判断一个应用是不是通过操作系统渲染的呢，这里可以通过Android手机上【设置】-【开发者选项】-【显示布局边界】这个功能来查看；如果一个界面上，被Android划出边框来，就是原生渲染（当然这有两种方式实现，一种是原生语言开发的，一种是驱动原生的方式）。如果明明是个Button，却没有被识别出来（如上图的右侧），那就是Webkit做渲染,比如Hybrid型APP。通过研究你会发现：天猫、淘宝、京东等APP的主要操作的界面已经采用原生渲染了，而不是使用webkit做渲染了。
然后说一个大家比价关心的：小程序到底是不是用驱动原生做的？目前看来还不是（下图是上周所截），它仍然是采用web方式进行渲染的，它是驱动型但不是驱动原生。不过并不妨碍我们把他作为先进例子来说，为什么呢？因为他引入了我们接下来要说的重点内容：工程化。小程序封装了自己的DSL，可以隔离开发人员对底层技术的依赖，实现技术的可替换。那么到底什么是工程化？如何用工程化的思维去实现移动跨平台建设？
三、以工程化的形式解决移动跨平台问题
工程化通俗的理解大家可以认为是拿平台建设的思路去解决问题，即：不单单以完成一个项目的开发为目标而是希望通过平台框架将某一能力开放给开发者。在移动跨平台工程化过程中需要考虑的几点是：
1）用什么技术手段实现跨平台（前文已经介绍，驱动原生）
2）如何方便开发人员实现快速调试
3）如何处理应用更新做到业务快速响应、上线
4）如何做到技术的可替换
只有工程化的去解决这些考量点才能真正的降低成本投入；从这些考量点入手也就引出了移动跨平台建设所需要解决的问题：
正如上图所见是我列出的个人觉得移动跨平台面临的问题，为此工程化的移动跨平台应当具备（个人拙见）：
专业跨平台运行引擎（技术、性能考量）
跨平台的IDE开发工具
跨平台调试引擎
稳定、完备的服务接入层
统一的企业级应用管控商店
所以工程化的移动跨平台应当能为移动化提供从开发、调试、测试、部署、到上线的全生命周期管控与支持而非只针对一个项目或者一个开发过程而言。
那何为专业的跨平台引擎？我觉的不是仅仅的把驱动原生技术拿来用就行了，还应当考虑技术的可替换性、降低技术学习成本等问题，这一点就回到了前文所说：小程序是值得我们借鉴，他封装自己的DSL实现技术的可替换，以类web语法和基础js做开发降低了学习成本。
从上图的结构分析可以看出，封装DSL不仅降低开发人员对底层技术的依赖还能在更先进技术诞生后做到替换（红色框），提高业务代码的可重用度。
另外移动跨平台还需在引擎和工具层提供用户可扩展编程接口能力，对企业而言这有利于迭代集聚代码，缩短以后应用的开发周期。
在工程化解决提升开发效率的问题上，普元移动平台和小程序一样采用类web的开发语法并提供多屏快速调试能力，使得开发人员可以将更多精力专注于业务开发上。
在移动跨平台的后台处理上，为了避免移动化给原有PC端的IT系统带来较大的入侵；应当建设下图红框的集成接入平台，通过集成平台可以对外提供统一的消息推送、文档转换服务而不是在原有的每个系统中都加入消息推送、文档转换的能力（竖井架构）。
最后在工程化面对应用版本管控上，建设适合企业的应用商店是比较行之有效的手段。通过企业应用商店对微应用（组件模块）、H5应用、原生应用提供统一的发布、更新途径来解决多级应用版本管理的问题。
可以看出企业移动跨平台在工程化的过程中并不是那么简单，也包含了相当多的建设内容。接下来和大家分享普元在企业移动平台实践上的一些可借鉴经验。
四、普元在企业移动跨平台上的优秀实践
经验1：【大平台+微应用】组合
通过大平台能让企业各部门之间有统一的协同办公、交流平台；而微应用（加上权限管控）又能保证各条业务线或部门拥有自身的独立性、开发自身特色的业务。这中模式既方便了对下设部门的业务管理也能提升企业的精细化运营。
经验2：【企业级应用商店+多级应用发布】
建设企业级应用商店可以帮助企业管理多供应商开发APP发布的混乱局面，通过提供统一的更新、发布渠道并结合组织机构权限实现对的人看对的应用的目标。多级应用发布则可以保证业务测试到上线的平稳过渡，“让一部分人先用起来”既能满足小部分的急需也避免了测试覆盖不全导致上线后大面积瘫痪的尴尬。
五、总结与展望
说在最后：普元移动一直致力于以工程化的思维来解决企业关注的诸多跨平台问题并有着丰富的实践经验。
关于作者：
黄家伟
现任普元移动团队高级研发工程师
在移动安卓开发、微信接入开发、IDE开发领域有比较深的见解。曾参与过移动平台7.1微信构件、实时联调功能的研发。
