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）攻擊，這可能對你的應用程序的用戶的一個嚴重的安全漏洞。