Android，我么用原生还是混合？

本文将从4个角度，讲解分析混合开发，与使用方式，希望给大家更多思路。

                       前言

        最近开发几个项目，牵涉到Android的几种开发模式。对于原生态开发、web 应用开发以及混合模式开发，本人认为并不是哪一种就是最好的，哪一种就是最差的，这个完全是根据项目的实际需求，选择一种合适的开发模式。他们同时具备自己的优点，同时也有自身的缺点，我们根据实际情况，取其中的优点，尽量避免掉缺点，才是最好的开发模式。下面，我们就一同看看，这三种开发模式，到底有什么区别。下面结合现有网上资料，感觉还是很不错，和大家分享一下。

一、原生应用 （也称本地开发 Native App） 

你使用过微软PowerPoint 或者 Word吧？这些可直接在你电脑上运行或者在智能手机上运行，简单来说，原生应用是特别为某种操作系统开发的，比如iOS、android、黑莓等等，它们是在各自的移动设备上运行的。 

优点： 

• 可访问手机所有功能（GPS、摄像头）；
• 速度更快、性能高、整体用户体验不错；
• 可线下使用（因为是在跟Web相对地平台上使用的）；
• 支持大量图形和动画; 容易发现（在App Store里面）和重新发现（应用图标会一直在主页上）；
• 应用下载能创造盈利（当然App Store抽取20-30% 的营收）。

• 开发成本高；
• 支持设备非常有限（一般是哪个系统就在哪个平台专属设备上用）；
• 上线时间不确定（App Store审核过程不一）；
• 内容限制（App Store限制）；
• 获得新版本时需重新下载应用更新。

• 支持设备广泛；
• 较低的开发成本；
• 可即时上线；
• 无内容限制；
• 用户可以直接使用最新版本（自动更新，不需用户手动更新）。

• 表现略差（对联网的要求比较大）；
• 用户体验没那么炫；
• 图片和动画支持性不高；
• 没法在App Store中下载、无法通过应用下载获得盈利机会；
• 要求联网；
• 对手机特点有限制（摄像头、GPS等）。

• 兼容多平台；
• 顺利访问手机的多种功能；
• App Store中可下载（Wen应用套用原生应用的外壳）；
• 可线下使用。

• 不确定上线时间；
• 用户体验不如本地应用；
• 性能稍慢（需要连接网络）；
• 技术还不是很成熟。

比如Facebook现在的应用属于混合应用它可以在许多App Store畅通无阻，但是掺杂了大量Web特性，所以它运行速度比较慢，而现在为了提高性能FB又决定采用原生应用。 

四、工具和框架

混合开发一些开发工具和框架其实很早就有了，比如AppCan、PhoneGap(Cordova)等，他们都主张一站式开发，简单的说，一个纯html5的开发人员就可以开发和发布Android和iOS的App了，不需要专门的Android和iOS开发人员。虽然感觉这样开发起来很快很简单，但是遇到问题和特殊需求的时候，就开始头疼了，再加上框架本身也存在一定的性能消耗，在Android 5.0和iOS 9.0以下，开发出来的App就显得很鸡肋。所以依我的经验来看，并不推荐找几个纯html5的开发人员就开始“干大事”。

1、努力做到原生部分占20%，html5部分占80%。

2、原生将实现：App主界面框架(可能含启动页面)、要求高性能的页面(如聊天/视频通话页面)、复杂算法/重要信息的存储或通信。

而目前这两年来说(2017~2018年)，大部分App只能做到35%左右的原生以及65%左右的html5。

一个混合App项目的前端开发人员的分布大概会是1:1:2.5，即：

小型项目：1个Android，1个iOS，2~3个html5

中大型项目：2个Android，2个iOS，4~6个html5

一般来讲，也是我目前知道的两种主流的方式就是

1. js调用Native中的代码
2. Schema：WebView拦截页面跳转

第2种方式实现起来很简单，但是一个致命的问题就是这种交互方式是单向的，Html 5无法实现回调。像云音乐App中这种点击跳转到具体页面的功能，Schema的方式确实可以简单实现，而且也非常适合。如果需求变得复杂，假如Html 5需要获取Native App中的用户信息，那么最好使用js调用的方式。

一、js和Native进行交互

上面讲到WebViewbe本身就是支持js调用Native代码的，不过WebView的这个功能在Android 4.2（API 17）一下存在高危的漏洞。这个漏洞的原理就是Android系统通过 WebView.addJavascriptInterface(Object o, String interface) 方法注册可供js调用的Java对象，但是系统并没有对注册的Java对象方法调用做限制。导致攻击者可以利用反射调用未注册的其他任何Java对象，攻击者可以根据客户端的能力做任何事情。 这篇文章 详细的介绍了这个漏洞

出于安全考虑，Android 4.2以后的系统规定允许被js调用的Java方法必须以 @JavascriptInterface 进行注解

二、Cordova的解决方案

Cordova是一个广泛使用的Hybrid开发框架，它提供了一套js和Native交互规范

在Cordova的 SystemWebViewEngine 类中可以看到

三、小众工具

Appium服务器被托管在Node服务器上。你可以通过触发一组Node命令来启动Appium服务器。使用Appium Standalone Application作为服务器(从Appium网站下载)，Inspector工具可对app的所有定位器提供查找/识别/操作的能力。

3)Robotium(Android )

Robotium是一个开源的测试框架，用于开发功能性，系统，和验收测试场景。它与Selenium非常相似，除了Robotium只适用于Android。它注册在Apache License 2.0下。

因为它不但简单，而且又具有创建强大又可靠的自动化场景的能力，因而它在自动化测试社区广泛流行。

它采用运行时绑定到GUI组件。它安装了一个测试用例套件作为在Android设备或仿真器上的应用程序，并提供用于执行测试的真实环境。

优点

容易在最短的时间内编写测试脚本。

预装自动化app是可能的。

自动跟随当前activity。

由于运行时绑定到GUI组件，所以相比Appium，它的测试执行更快，更强大。

不访问代码或不知道app实现，也可以工作。

支持Activities、Dialogs、Toasts、Menus、Context Menus和其他Android SDK控件。

缺点

不能处理flash和web组件。

支持Java开发。

在旧设备上会变得很慢。

由于不支持iOS设备,当自动化测试同时覆盖 android与iOS的情况时，测试会被中断。

没有内置的记录和回放功能. 使用记录功能需要 TestDroid 和 Robotium Recorder 这样收费工具。

4)Frank(iOS)

Frank是一个iOS app的自动化框架，允许使用Cucumber编写结构化英语句子的测试场景。

Frank要求测试时在应用程序内部编译，这意味着对源代码的改变是强制性的。这是一个使用Cucumber和JSON组合命令的工具，命令发送到在本地应用程序内部运行的服务器上，并利用UISpec运行命令。

优点

测试场景是在Cucumber的帮助下，用可理解的英语句子写的。

Symbiote——包含实时检查工具。

如果团队有关于web selenium和cucumber自动化框架的经验，也有效。

5)UIAutomator(Android)

UIAutomator是由谷歌提供的测试框架，它提供了原生Android app和游戏的高级UI测试。这是一个包含API的Java库，用来创建功能性UI测试，还有运行测试的执行引擎。该库自带Android SDK。有很多教程可供初学者上手。优点是它在运行访问不同的进程时，会给JUnit测试案例特权。虽然这对本地自动化app既好又更简单，但是它对web自动化视图非常有限或几乎没有任何支持。它仅支持使用API level 16及以上的设备，不过这也不算什么很大的因素，因为现在大多数的app支持API level 19及以上。

优点

简单易学的教程。

库由谷歌社区支持和维护。

第三方支付集成了基于云计算的测试管理。

缺点

仅支持android 4.1及以上。