5封裝類成App的應用和原生應用有什么不一樣？——一對比談優(yōu)缺點

大家好， 我是咕嚕-凱撒，H5封裝的app和原生開發(fā)的app有什么不一樣？，不懂就要問，我能理解哈，雖然這個問題有點小白，但是我還是得認真回答，以防止我回答的不是很好，所以我科技了一下，所以今天我們來說一說如果這是同樣這個問題在困擾著同學你，你改怎么辦？在移動端開發(fā)中，有兩種主要的方式來制作App：H5封裝類應用（如React Native, Flutter等）和原生應用（如 iOS, Android）。兩者之間的優(yōu)缺點一直是個熱門話題，今天我們將詳細比較和探討它們在不同方面的表現(xiàn)，了解哪種方式適合你的需求。

1. 開發(fā)速度和復用性

H5封裝的App優(yōu)勢：一次編寫，多平臺運行。你只需要使用一種語言編寫代碼，就可以發(fā)布到不同的平臺，降低開發(fā)成本。

原生應用優(yōu)勢：對于某個特定平臺（如iOS或Android）的開發(fā)者，開發(fā)、維護、調試的速度可能會更快，因為他們可以使用專門針對這個平臺的IDE和開發(fā)工具。

2. 性能

H5封裝的App劣勢：因為H5代碼是通過WebView運行的，性能可能比原生應用要差一些。

原生應用優(yōu)勢：可以調用操作系統(tǒng)的API直接訪問設備功能，性能較好。

3. 包大小

H5封裝的App劣勢：封裝了整個 WebView 實例，所以文件大小通常較大。

原生應用優(yōu)勢：可以直接運行在設備上，包大小相對較小。

4. 設備特性訪問

H5封裝的App優(yōu)勢：享有平臺所提供的一些原生組件庫。例如，React Native 有 CameraRoll 組件可訪問相機和圖片庫：

javascript

.import { CameraRoll } from "react-native";
.CameraRoll.getPhotos({ first: 20 })
.  .then(images=> console.log(images))
.  .catch(error=> console.log(error));

原生應用優(yōu)勢：可以直接訪問設備的特性（如傳感器、硬件加速等），提供更豐富的體驗。

5. UI 和 UX

H5封裝的App劣勢：由于使用了跨平臺的UI組件，可能無法完全匹配目標平臺的設計規(guī)范，用戶體驗可能會受影響。

原生應用優(yōu)勢：可以完全根據(jù)iOS或 Android 的設計規(guī)范來定制UI和交互，提供更好的用戶體驗。

6. 框架和庫支持

H5封裝的App劣勢：雖然有第三方庫，但數(shù)量和功能可能無法與原生應用平臺相媲美。

原生應用優(yōu)勢：擁有龐大的庫和框架支持，可以快速實現(xiàn)復雜功能。

7. 社區(qū)和生態(tài)系統(tǒng)

H5封裝的App劣勢：相對于原生應用社區(qū)，跨平臺技術的社區(qū)和生態(tài)可能更小，資源較少。

原生應用優(yōu)勢：iOS和Android社區(qū)龐大，資源豐富。

8. 線上更新

H5封裝的App優(yōu)勢：可以像Web應用一樣實時更新代碼，無需通過應用商店進行發(fā)布。

原生應用劣勢：必須經歷應用商店審核流程。

9. 適用場景

H5封裝的App優(yōu)勢：對于功能較簡單、追求快速開發(fā)的項目，可以節(jié)省時間和成本。

原生應用優(yōu)勢：當需要更好的性能、深度集成設備功能或提供達到平臺設計規(guī)范的用戶體驗時，原生應用更為合適。

同學們能力有限呀，只能想到這些了，如果你有不同的或者更好的見解評論區(qū)，私信我都可以哈，交流交流吧兄弟們，讓這個行業(yè)在飛黃騰達一下哈哈，H5封裝類應用和原生應用各有優(yōu)劣，需根據(jù)具體需求和場景權衡選擇。當然，技術的發(fā)展也在不斷地彌補這兩者之間的差距，未來也許會產生新的方式來解決當前存在的問題。

謹如程序員，時間久了還是會有一些"想當然"。不知不覺中就會掉進很多陷阱里。看看這些陷阱，你都中招了嗎？

譯文：

我對誤解很感興趣。以前我經常在酒吧里主持猜謎游戲（我們這里有的地方叫做“冷知識之夜”），參加過幾次的人都知道，如果一道題看上去像是陷阱，那通常它就是陷阱。我的題目里有相當多的“似真似假”的題目，其中所有問題的答案都是假，但幾乎沒有任何人注意到這一點，因為每道題都是人們平常深信不疑的錯誤的事情。

等等，這跟編程有什么關系？別著急，繼續(xù)讀下去。

在Hacker News或Proggit上評論的程序員并不是從計算機行業(yè)隨機選取的，而是這個行業(yè)中的精英部分。就像參加任何會議一樣，參與評論的這些人都比一般程序員對編程更有熱情。

然而，從許多評論中可以看出，許多很厲害的程序員也會有各種信仰和誤解，這些信仰和誤解雖然錯得離譜，但卻廣為流傳。下面是我收集的一些很有意思的誤解，附有我的解釋。

C語言就是快。

如果說哪個誤解會招致差評、導致認知差異、甚至引起口水戰(zhàn)？那很可能就是這一條了。

就像其他的誤解一樣，我對這一條完全不理解。

估計是因為我學C語言的那個時代，人們普遍認為C語言用于游戲編程等很慢，而匯編才是王道。或者是因為，程序都要編譯成機器語言，而就像什么順勢療法一樣，匯編語言仿佛是水，能記住自己從哪兒來，從而使得CPU能執(zhí)行得更快……于是就有了下一條誤解。

垃圾回收語言就是慢。

這里說的垃圾回收指的是“跟蹤式垃圾回收”。許多人都評論說，在真正的系統(tǒng)中編程時，跟蹤是垃圾回收是多么不能忍。要是每條評論我能收一分錢的話，我現(xiàn)在就有好幾塊錢了。

我大概能理解這一條，因為四年前我也相信。

我還曾經相信后臺會有小仙子自動幫我清理那些“明顯”會導致程序變慢的代碼。以后我會寫一篇文章專門講這個問題。

Emacs是個文本模式的程序。

每次有人說文本編輯器比不上IDE，就必然有人跳出來問，為啥非要用文本模式的編輯器。

我是個Emacs用戶，我也不知道為啥他們都要用。類似地還有……

文本編輯器沒辦法也不應該擁有自動完成、查找定義等功能。

這一條通常會在討論Emacs是終端程序的帖子里出現(xiàn)。通常還會伴隨著一些人說IDE的上述功能是必要的。我也不用IDE編程，估計以后也不會。同樣，我很少看到用編輯器用得很溜的人。

不記得多少次看到某人用vim打開一個文件，發(fā)現(xiàn)開錯了，關掉vim，再打開另一個文件，再關掉……啊啊啊啊啊啊啊啊啊啊。

還有人“喜歡Eclipse”卻不知道“查找定義”功能的……簡直是奇跡。

由于C ABI是編程的通用語言，所以實現(xiàn)應該也用C語言。

在討論二進制代碼時C語言是真正的膠水語言。

這是有歷史原因的，但不可否認在這方面C語言就是王者。但令我大跌眼鏡的是，很多人把這句話理解為，如果API是C語言的，那么實現(xiàn)它的唯一語言就是C語言。也不想想Visual Studio的libc是用C++寫的。

C和C++是同一種語言，真正的名字是C/C++。

而且沒人把Objective C算進去（其實Objective C跟C++不一樣，它實際上是C語言的超集），因為……啥原因呢？

C和C++有太多共通的地方，有時候當你想說一些適合兩種語言的東西時，寫成C/C++是有道理的。但許多時候人們并不是這樣用……

在并發(fā)編程的容易性方面Rust是唯一的選擇。

我估計所有使用Pony、D、Haskell、Erlang等語言的人都不明白這句話。Rust是不是比C++更安全？當然是，但這個標準也太低了。

我第一次用Rust時花了30分鐘就死鎖了。我感覺并不容易，或者應該說“不考慮數(shù)據(jù)沖突的話很容易”？反正是很容易上當.

內核只能用C語言。

顯然Haiku和Redox被無視了，以及其他一切unikernel框架。

平臺的字節(jié)序很重要。

這又是一條讓我迷惑不解的理論。

我甚至都不知道為啥還有htons和ntohs這兩個函數(shù)。完全搞不懂，而且更悲慘的是，我跟別人解釋這個時，似乎他比我還明白。

我并不是說字節(jié)序不重要，而是說99.9%的情況下，人們認為它很重要，實際上卻完全無所謂。我肯定會讀一次IEEE浮點數(shù)的定義，但這并不意味著寫任何程序都必須記住哪一部分才是尾數(shù)。

Haskell代碼能通過編譯就能跑！

嗯……不是的。

簡單的語言能避免復雜性。

也稱為“清掃地毯下面的塵土”迷信。

我并不明白這句話。我的意思是，一項任務的復雜度并不會因為使用了簡單的語言而消失，甚至會變得更復雜。有許多負責搞笑的語言極其簡單，但真用來寫代碼就簡直是噩夢。

代碼覆蓋率是測試質量的標準。

我認為覆蓋率很重要。我覺得，閱讀一份漂亮的HTML覆蓋率報告確實能夠幫助書寫高質量的軟件。但我十分確信，追逐代碼覆蓋率的目標是有害的，而且毫無意義。下面是個很無聊的函數(shù)：

int divide(int x, int y) { return x + y }

然后是測試套件：

TEST(divide) { divide(4, 2); }

100%的覆蓋率。函數(shù)甚至連返回值都不對。好吧，其實應該assert點啥東西：

TEST(divide) {
 assert(divide(4, 2)==2);
 assert(divide(6, 3)==2);
}
int divide(int x, int y) { return 2; }

100%覆蓋率。嗯……要不這樣？

TEST(divide) {
 assert(divide(4, 2)==2);
 assert(divide(9, 3)==3);
}
int divide(int x, int y) { return x / y; }

測試成功！當然，別給y傳0……

應該測量測試覆蓋率，閱讀報告，然后決定下一步該做什么。之前我也寫過著跟問題。

C能最接近地映射到硬件。

如果“硬件”的意思是PDP11或微型嵌入式設備，那么沒錯。但寫內核不能只用C不用匯編是有理由的。

而且還有這一堆東西：SIMD，多ＣＰＵ核心，緩存層次結構，緩存管線，內存預取，亂序執(zhí)行，等等。至少現(xiàn)在有原子性了。

我不知道人們給量子計算機寫代碼的時候還會不會說C最接近硬件。聽起來似乎很傻，但我還見過更傻的。

另外，Lisp機器從來沒存在過，F(xiàn)PGA/GPA也不是硬件（別忘了Poe定律！Poe定律：只要不明確表明是諷刺，那么不管諷刺得多么夸張，總會有人信以為真）。

做某件事只能用某個語言。

不管你說的某件事是啥，Lisp估計都能做。