原生APP，web APP , 純h5開發比較

1.目前APP開發有4中方式：a.純原生  b.純原生 + 遠端 h5頁面（目前採用策略） , c.H5 + 原生(內置) d.H5應用頁面

a.純原生(開發成本大)：

    優點：

1.提供最佳的用戶體驗，最優質的用戶界面，最華麗的交互 

2.每一種移動操做系統都須要獨立的開發項目，針對不一樣平臺提供不一樣體驗

3.可以與移動硬件設備的底層功能，可訪問本地資源

    劣勢：

1.維持多個版本的成本比較高

2.安卓碎片化嚴重，致使有可能不兼容的問題

3.移植性差

b.純原生 + 遠端 h5頁面（目前採用策略）

     優點：

1.H5頁面多設備一套UI，大大下降UI開發的成本。

2.因爲H5頁面在服務端，調試比較方便

     劣勢：

1.H5頁和原生頁面混搭使用。可能會形成相似於回退同樣的狀況(H5和原生交互少形成的混搭使用)

2.每次從服務端請求頁面，都會形成流量的消耗

3.流暢性不如原生

c.H5 + 原生(內置)

     優點：

1.H5頁面多設備一套UI，大大下降UI開發的成本。

2.因爲全部的UI都是由H5來實現的，讓手機端開發人員以及後端開發人員更加關注業務邏輯的功能實現

3.因爲UI組件都是內置的，所以能夠減小大部分的流量消耗。

4.向比b,d方案 用戶體驗更佳

5.可以與移動硬件設備的底層功能，可訪問本地資源

     劣勢：

1.調試的時候，雙前段可能比較麻煩。

2.流暢性不如原生

3.若是H5頁面做用於設備瀏覽器，將不適用.不適用的緣由：頁面中可能有3/1的事件是在調用原生的方法，不可能移植到第三方去

d.H5應用頁面

     優點：

1.只適合提供設備瀏覽器使用。

推薦使用c方案,若是使用c方案，將使用mui和zepto框架結合native來進行開發,APP開發人員則更多的是webapp框架的研發。

注：

1.本地圖片適配的問題？

答：圖片的尺寸採用向上靠的策略

2.IOS:頁面跳轉過多致使內存溢出？

答：採用js調用本地native方法進行跳轉。

3.JS文件是否增量更新？

答：是，只須要更新新增的JS文件便可.(說明:否，每次須要提交app store進行審覈)

固然，也可使用相似於appcan, phonegap, hbuilder, apicloud 等 webapp框架

appcan（免費） :

     優點：

1.蘋果在2014年10月20號發佈了一條消息：從2015年的2月1號開始，提交到App Store的應用必須支持64-bit。（已經支持，第三方SDK也已經支持）.注意事項：平臺支持64-bit ARM之後，適配的設備固件版本最低爲iOS 5.1.1

2.可根據本身須要寫擴展插件，適應不一樣的開發方向

3.已經開源，有在線中文文檔，應用內置了豐富的窗口 交互、UI控件庫、原生插件庫，本地化支持比較好，學習成本低。

4.懂HTML+CSS+Javascript就能開發，自帶的api還算比較全，開發週期短，開發成本低，並且跨平臺，可同時支持andriod和ios系統，不用開發兩次

5.Appcan模擬器，調式方便

6.相比phonegap流程度稍高點，請求數據速度高點

7.IOS審覈有優點

     劣勢：

1.要用就得用一套。

2.流暢度不夠。

apicloud（公測階段全免費） ：

優點:

1.流暢性超高，請求數據也快，和原生差很少

2.網上說該框架的內核比appcan的要高級，不知道是真是假

3.本地化支持

4.模擬器，調式方便

劣勢：

1.出現的時間不長

2.使用的人羣沒有其餘2個多

注：如今是免費的，好像是端開發 （開發移動應用）永久免費，雲服務如今是免費，後續會收費。不過能夠只用端開發，那就永遠不用給錢了

phonegap：

優點：

1.國外的東西

2.模擬器，調式方便

劣勢：

1.組件沒有appcan多，流暢度沒有appcan高，數據請求沒有appcan快

2.英文文檔，本地化支持不夠，出現問題比較難解決

hbuilder(mui的一個打包開發工具)：

優點：

1.輕量，小巧,流暢度比appcan高

2.模擬器，調式方便

劣勢：

1.不少組件都沒有，須要本身開發

---

目前當前項目中使用的策略爲b策略，發現不少問題，流程性不高，體驗性不高，請求數據慢， 最近項目組中在考慮換一種策略，以上是本身蒐集好了。也在以上的官網上下載了一些案例，測試下來以後得出的結論。發現這個apicloud很亮眼，決定本身先作一個小demo。最後再決定使用哪一個吧