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……

 

 

【開發方案奇技淫巧的分析】

一、開發類

Hybrid App按網頁語言與程序語言的混合，通常分為三種類型：多View混合型，單View混合型，Web主體型。

1、多View混合型

　　即Native View和Web View獨立展示，交替出現。2012年常見的Hybrid App是Native View與WebView交替的場景出現。這種應用混合邏輯相對簡單。即在需要的時候，將WebView當成一個獨立的View（Activity）運行起來，在WebView內完成相關的展示操作。這種移動應用主體通常是Native App，Web技術只是起到補充作用。開發難度和Native App基本相當。

2、單View混合型

　　即在同一個View內，同時包括Native View和Web View。互相之間是覆蓋（層疊）的關系。這種Hybrid App的開發成本較高，開發難度較大，但是體驗較好。如百度搜索為代表的單View混合型移動應用，既可以實現充分的靈活性，又能實現較好的用戶體驗。

3、Web主體型

　　即移動應用的主體是Web View，主要以網頁語言編寫，穿插Native功能的Hybrid App開發類型。這種類型開發的移動應用體驗相對而言存在缺陷，但整體開發難度大幅降低，並且基本可以實現跨平台。Web主體型的移動應用用戶體驗的好壞，主要取決於底層中間件的交互與跨平台的能力。國外的appMobi、PhoneGap和國內的WeX5、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）攻擊，這可能對你的應用程序的用戶的一個嚴重的安全漏洞。