因為近H5發(fā)展的不錯，在微信里可以看到很多活動，比如邀請函什么都是通過H5制作的，大家直觀的體驗都很不錯。在APP開發(fā)方面，Web版APP或者H5版APP開發(fā)速度更快，而且費用比傳統(tǒng)的外包原生APP便宜一些。因此很多人咨詢，我的APP是否可以采用Web（H5）APP的模式？

作為國內(nèi)大的APP在線制作方，應(yīng)用公園主打不懂編程也能自己制作原生APP，而且成本比Web（H5）APP還低，當(dāng)然具有一定的話語權(quán)。我們的平臺為什么不采用Web App 的模式開發(fā)呢？為什么還采用原生笨拙的方式去開發(fā)一個個功能？問題主要聚焦在以下幾個方面：

1、動畫

常見的H5頁面、APP都是比較小，市場上從沒有出現(xiàn)比較大的H5頁面或者APP。因為H5自身的不完善，使得加載動畫的時候，相應(yīng)比較慢，如果采用大量的css頁面，速度變快但是會導(dǎo)致渲染卡頓，出現(xiàn)白屏、閃退等情況。很多H5游戲，稍稍功能多一點，就容易奔潰。市面上的大多成功APP都是采用原生的。

應(yīng)用公園生成的原生APP，與市面上的大型APP性能是一樣的。

2、獲取服務(wù)端數(shù)據(jù)

Web（H5）版的APP，數(shù)據(jù)獲取都是在資源頁面上異步完成的，涉及DOM操作，不能與手機內(nèi)的配置同步，所以非常消耗手機性能。一不小心就會出現(xiàn)明顯的閃白。

而且重要的一點是，如果頁面加載進來之后數(shù)據(jù)更新的速度太慢，也會讓頁面模板等待很長時間，對用戶體驗又不友好，總不能每次打開都像瀏覽器一樣等待刷新是吧。生活我們也經(jīng)常遇到Web（H5）頁面突然就不見了，或者一直加載。

3、頁面切換

很多Web（H5）版的APP，為了動畫的加載，使用了很多工具來進行輔助，比如預(yù)加載等。雖然看起來很友好解決了不少問題，但事實上如果頁面足夠多就會引發(fā)另一個問題——頁面的生存周期。

試想一下，主頁面緩存了5個子頁面的資源，在跳轉(zhuǎn)到響應(yīng)的子頁面時又會緩存這些子頁面的下級頁面資源，如此反復(fù)肯定會占據(jù)大量內(nèi)存使APP的體驗下降。

單一頁面Web（H5）版的APP很不錯，但大型的往往適得其反。

4、Android/iOS的區(qū)別

很多人說H5 APP一次編寫就能編譯Android/iOS兩種不同的APP，但是有考慮過BUG嗎？事實證明，后期的修改調(diào)整真的即繁瑣又復(fù)雜，還不如一開始利用原生的老老實實去開發(fā)。舉一個很簡單的例子，Android和iOS在返回上一頁的處理方式上就有明顯的區(qū)別，調(diào)用底層硬件時怎樣區(qū)分不同的場景等等

而應(yīng)用公園采用純原生的結(jié)構(gòu)，可以實現(xiàn)一鍵生成ios和安卓雙版本的APP，這個是有專利的。

5、混合開發(fā)怎么樣？

現(xiàn)在做H5混合APP開發(fā)的人很多，但兩者真的可以適配嗎？只有在原生的基礎(chǔ)上，加入部分不重要的H5頁面可以，在H5基礎(chǔ)上可以加入原生嗎？

Web（H5）的優(yōu)勢在于圖文排版，而不在開發(fā)，更適合做輔助。

6、更新維護

Web（H5）版的APP，每次內(nèi)容、功能更新都需大動干戈，所消耗的人工、資金成本不亞于重新開發(fā)，而應(yīng)用公園原生平臺化，不懂編程的也能自己輕松維護，模塊化操作，也不需要重新上架審核，所以更新維護成本接近于零。

所以，不要因為一時的便宜而被開發(fā)公司忽悠選擇的Web（H5）版的APP，性能與原生的差別太大，而且價格方面，也沒有應(yīng)用公園這種平臺共享模式的便宜，后期的維護更是大坑，創(chuàng)業(yè)者要在選擇開發(fā)APP的時候，要留心這個常見大坑。