2.用iOS SDK，實現熱更新比較麻煩。對於論壇來說，查閱這個模塊並修改它很容易，這是壹個令人頭痛的事情，所以H5非常適合。尤其是APP橫跨Android和iOS的時候，這種模塊如果直接用H5，會很好用。
H5 web App開發與純原生App的差距主要集中在以下幾個方面:
1，動畫
動畫有很多種，比如側邊欄菜單的滑入滑出，元素的響應動畫，頁面切換之間的剪切等等。H5下的許多實現方法無法實現純本機性能。壹般有幾種不同的選項:css3動畫、javascript動畫和原生動畫。
Css3動畫對性能的消耗很大。如果在css3動畫中使用壹個元素，可能不太明顯，但是大面積或者野外使用css3動畫，會讓app的低端手機體驗很差。最好的選擇壹般是通過框架調用底層動畫，但無論如何，相當於在原代碼上包裹了壹層，性能難免受到影響。
比如加載新頁面，調用底層動畫需要考慮兩個問題，壹個是自身資源頁面的渲染，壹個是遠程數據的獲取。即使這些動畫能快速響應，大量的css頁面也會造成渲染卡頓，滑入時可能會出現白屏/機卡。為了解決這些性能問題，有必要使用預加載或模擬動畫。即便如此，滑入滑出動畫在低端安卓機上還是有很多問題。如果服務器的數據處理方式不合適，“卡白屏”的現象會更嚴重。具體見以下數據采集方法。
2.獲取服務器數據
首先要接受的是，這裏的數據獲取是在資源頁面上異步完成的，因為只有這樣才能預加載或呈現這些資源頁面。但是異步獲取的數據在填充頁面時可能會涉及到DOM操作。眾所周知，DOM操作消耗了大量的性能。如果頁面小而精，頁面略大，數據略復雜。頻繁的DOM操作會導致明顯的閃爍。而且最重要的壹點是，如果頁面加載後數據更新速度過慢，也會讓頁面模板等待很長時間，對用戶體驗不友好。總不能每次打開都像瀏覽器壹樣等著刷新吧？
如果這個問題不解決，H5很難開發大規模數據的頁面，更難在其中頻繁切換。那麽肯定會有人想到用MVVM。其實我也寫過壹些基於MVVM的H5app開發。相對而言，他們獲取數據和更新數據的方式更加靈活和科學，但在寫作過程中，我們應該註意H5的許多獨特問題。這些問題將在下面的頁面切換中討論。
3.頁面切換
以上，我們看到了幾種不錯的實現方法，比如預加載和動畫模擬，甚至批量預加載，批量截圖動畫模擬等。雖然看似友好的解決了很多問題，但實際上，如果頁面足夠多，就會引發另壹個問題——頁面的生命周期。
試想壹下，如果向導頁或者主頁緩存了五個子頁的資源，那麽跳轉到響應子頁時，這些子頁的下層頁面的資源也會被緩存。這種重復肯定會占用大量內存，降低APP的體驗。那麽如何知道需要哪些頁面，最多緩存多少頁面，以及何時結束哪些頁面的生命周期呢？這些問題在我用過的H5APP的很多框架中都沒有完美的答案，所以在開發頁面多、內容多的APP時，可能會因為這些資源分配問題導致性能下降。
這時，讓我們回頭看看MVVM的數據加載問題。其實不管是哪個MVVM框架，寫過的人都知道，管理這個新前端代碼最重要的問題就是內存問題。妳不僅要保證代碼寫得足夠優雅，沒有任何內存泄漏的問題，還要考慮它們的控制器/頁面資源在頁面生命周期結束時是否被釋放，這對全局有沒有影響，在多個請求時合理分配資源，甚至重用這些父頁面的緩存資源等等。較小的應用程序可能沒有這些問題。如果妳想用純H5開發壹個大型app，很可能會浪費妳很多時間——而且結果也不會讓妳滿意。
4.Android和iOS的區別
很多人說兩個不同的app，Android/iOS，只需要開發壹次H5app就可以編譯，大大降低了成本。其實這種觀點本身就有問題。如果妳寫過這種APP，妳就能明白我在說什麽。它們既不方便也沒有很多bug，尤其是調試的時候。舉個簡單的例子，Android和iOS在返回上壹頁的方式上有明顯的區別，比如如何全屏處理iOS的頂欄，Android機出現智能欄時如何處理頁面的布局，調用底層硬件時如何區分不同的場景等等。妳需要寫壹個型號和系統的判斷，然後分別在Android和iOS下調試。最後妳發現沒用，累的要死卻什麽都沒學到，只有壹堆人不知道什麽時候會過時。
現在開發H5混合app的人很多，但是純H5很年輕，很多問題還沒有很好的解決。這些都是我做這些app時考慮最多的問題。最後，讓我們談談H5的壹個很少有人註意的優點。大家說起H5APP，都是說開發快、成本低、多平臺等等，但我覺得它和很多APP開發方式相比有壹個區別——圖文混合排版。正是這些復雜多變的CSS樣式消耗了性能，卻帶來了排版的多樣性，能夠細致到每個字的寬、高、樣式的像素級處理，才是H5的過人之處。