2017-05-24 21:07:00 來自于應(yīng)用公園
因為近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還低,當然具有一定的話語權(quán)。我們的平臺為什么不采用Web App 的模式開發(fā)呢?為什么還采用原生笨拙的方式去開發(fā)一個個功能?問題主要聚焦在以下幾個方面:
常見的H5頁面、APP都是比較小,市場上從沒有出現(xiàn)比較大的H5頁面或者APP。因為H5自身的不完善,使得加載動畫的時候,相應(yīng)比較慢,如果采用大量的css頁面,速度變快但是會導(dǎo)致渲染卡頓,出現(xiàn)白屏、閃退等情況。很多H5游戲,稍稍功能多一點,就容易奔潰。市面上的大多成功APP都是采用原生的。
應(yīng)用公園生成的原生APP,與市面上的大型APP性能是一樣的。
Web(H5)版的APP,數(shù)據(jù)獲取都是在資源頁面上異步完成的,涉及DOM操作,不能與手機內(nèi)的配置同步,所以非常消耗手機性能。一不小心就會出現(xiàn)明顯的閃白。
而且重要的一點是,如果頁面加載進來之后數(shù)據(jù)更新的速度太慢,也會讓頁面模板等待很長時間,對用戶體驗又不友好,總不能每次打開都像瀏覽器一樣等待刷新是吧。生活我們也經(jīng)常遇到Web(H5)頁面突然就不見了,或者一直加載。
很多Web(H5)版的APP,為了動畫的加載,使用了很多工具來進行輔助,比如預(yù)加載等。雖然看起來很友好解決了不少問題,但事實上如果頁面足夠多就會引發(fā)另一個問題——頁面的生存周期。
試想一下,主頁面緩存了5個子頁面的資源,在跳轉(zhuǎn)到響應(yīng)的子頁面時又會緩存這些子頁面的下級頁面資源,如此反復(fù)肯定會占據(jù)大量內(nèi)存使APP的體驗下降。
單一頁面Web(H5)版的APP很不錯,但大型的往往適得其反。
很多人說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,這個是有專利的。
現(xiàn)在做H5混合APP開發(fā)的人很多,但兩者真的可以適配嗎?只有在原生的基礎(chǔ)上,加入部分不重要的H5頁面可以,在H5基礎(chǔ)上可以加入原生嗎?
Web(H5)的優(yōu)勢在于圖文排版,而不在開發(fā),更適合做輔助。
Web(H5)版的APP,每次內(nèi)容、功能更新都需大動干戈,所消耗的人工、資金成本不亞于重新開發(fā),而應(yīng)用公園原生平臺化,不懂編程的也能自己輕松維護,模塊化操作,也不需要重新上架審核,所以更新維護成本接近于零。
所以,不要因為一時的便宜而被開發(fā)公司忽悠選擇的Web(H5)版的APP,性能與原生的差別太大,而且價格方面,也沒有應(yīng)用公園這種平臺共享模式的便宜,后期的維護更是大坑,創(chuàng)業(yè)者要在選擇開發(fā)APP的時候,要留心這個常見大坑。