iOS 混合开发 —— 方案分析

混合开发方案分析比较

Native、Hybird、React Native、Weex 方案分析

http://www.jianshu.com/p/20a3d10a4d57

  

Hybird

Cordova/PhoneGap：侧重于JS与原生的交互，开发简单，但性能差，如触摸时反应不灵敏。

AppCan：性能还行，使用简单，但要提交代码给AppCan的服务器才能打包，相信有追求的企业是不会把本身的代码提交给第三方，把打包权利交给第三方的。

Ionic Framework：在Cordova的基础上增长一些UI/JS方面的东西，样式还不错，但一样具备Cordova的不足。

此外还有 APICloud 等等

 

UI/JS 框架

jQuery Mobile：上手简单，组件丰富，但性能超级差，闪屏现象严重。

Senche Touch：简单看过，没有使用过，貌似UI很漂亮，学习成本高。

React Native：FB推出的，当年FB是最先尝试Hybrid的，但性能超差，因而APP放弃了Hybrid，走原生的道路。在你们都不看好H5时，FB暗中深刻挖掘H5，三年以后推出了这个框架，很是推荐各位去学习其中的思想。

GMU：百度推出的，这个不错。

 

UI/JS 库

jQuery、Zepto、Swiper、iScroll、RequireJS、AngularJS……

 

 

【开发方案奇技淫巧的分析】

1、开发类

Hybrid App按网页语言与程序语言的混合，一般分为三种类型：多View混合型，单View混合型，Web主体型。

一、多View混合型

　　即Native View和Web View独立展现，交替出现。2012年常见的Hybrid App是Native View与WebView交替的场景出现。这种应用混合逻辑相对简单。即在须要的时候，将WebView当成一个独立的View（Activity）运行起来，在WebView内完成相关的展现操做。这种移动应用主体一般是Native App，Web技术只是起到补充做用。开发难度和Native App基本至关。

二、单View混合型

　　即在同一个View内，同时包括Native View和Web View。互相之间是覆盖（层叠）的关系。这种Hybrid App的开发成本较高，开发难度较大，可是体验较好。如百度搜索为表明的单View混合型移动应用，既能够实现充分的灵活性，又能实现较好的用户体验。

三、Web主体型

　　即移动应用的主体是Web View，主要以网页语言编写，穿插Native功能的Hybrid App开发类型。这种类型开发的移动应用体验相对而言存在缺陷，但总体开发难度大幅下降，而且基本能够实现跨平台。Web主体型的移动应用用户体验的好坏，主要取决于底层中间件的交互与跨平台的能力。国外的appMobi、PhoneGap和国内的WeX五、AppCan和Rexsee都属于Web主体型移动应用中间件。其中Rexsee不支持跨平台开发。appMobi和PhoneGap除基础的底层能力更可能是经过 插件（Plugins）扩展的机制实现Hybrid。AppCan除了插件机制，还提供了大量的单View混合型的接口来完善和弥补Web主体型Hybrid App体验差的问题，接近Native App的体验。而WeX5则在揉合PhoneGap和Bootstrap等主流技术的基础上，对性能进一步作了深度优化，不但彻底具有Native App对本地资源的调用能力，性能体验也不输原生；WeX5所开发出来的app具有彻底的跨端运行能力，能够无需任何修改直接运行在各类前端环境上。

 

从分析可见，Hybrid App中的Web主体型只要可以解决用户体验差的问题，就能够变成最佳Hybrid App解决方案类型。

 

 

 

github地址: https://github.com/lc081200/hybirdApp

 

【关于最近疯狂的 热更新/混合开发被拒问题】：

Your app, extension, or linked framework appears to contain code designed explicitly with the capability to change your app’s behavior or functionality after App Review approval, which is not in compliance with App Store Review Guideline 2.5.2 and section 3.3.2 of the Apple Developer Program License Agreement.

This code, combined with a remote resource, can facilitate significant changes to your app’s behavior compared to when it was initially reviewed for the App Store. While you may not be using this functionality currently, it has the potential to load private frameworks, private methods, and enable future feature changes. This includes any code which passes arbitrary parameters to dynamic methods such as dlopen(), dlsym(), respondsToSelector:, performSelector:, method_exchangeImplementations(), and running remote scripts in order to change app behavior and/or call SPI, based on the contents of the downloaded script. Even if the remote resource is not intentionally malicious, it could easily be hijacked via a Man In The Middle (MiTM) attack, which can pose a serious security vulnerability to users of your app.

 

您的应用程序，扩展，或连接的框架彷佛包含代码明确设计的能力，应用程序审查批准后更改您的应用程序的行为或功能，这是否是在App Store审核指南2.5.2和3.3.2节的苹果开发者计划许可协议规。

此代码与远程资源相结合，能够方便地对应用程序的行为进行显著的更改，而不是对应用程序商店进行最初的审查。虽然您目前可能不使用此功能，但它有可能加载私有框架、私有方法，并启用未来的功能更改。这包括任何代码，经过任意的参数，如dlopen()，dlsym()，respondstoselector动态方法，performselector：，method_exchangeimplementations()，为了运行远程脚原本改变应用程序的行为和/或调用SPI，基于下载的脚本的内容。即便远程资源没有恶意，它很容易被劫持，经过中间人（MITM）攻击，这可能对你的应用程序的用户的一个严重的安全漏洞。