5封装类成App的应用和原生应用有什么不一样？——一对比谈优缺点

大家好， 我是咕噜-凯撒，H5封装的app和原生开发的app有什么不一样？，不懂就要问，我能理解哈，虽然这个问题有点小白，但是我还是得认真回答，以防止我回答的不是很好，所以我科技了一下，所以今天我们来说一说如果这是同样这个问题在困扰着同学你，你改怎么办？在移动端开发中，有两种主要的方式来制作App：H5封装类应用（如React Native, Flutter等）和原生应用（如 iOS, Android）。两者之间的优缺点一直是个热门话题，今天我们将详细比较和探讨它们在不同方面的表现，了解哪种方式适合你的需求。

1. 开发速度和复用性

H5封装的App优势：一次编写，多平台运行。你只需要使用一种语言编写代码，就可以发布到不同的平台，降低开发成本。

原生应用优势：对于某个特定平台（如iOS或Android）的开发者，开发、维护、调试的速度可能会更快，因为他们可以使用专门针对这个平台的IDE和开发工具。

2. 性能

H5封装的App劣势：因为H5代码是通过WebView运行的，性能可能比原生应用要差一些。

原生应用优势：可以调用操作系统的API直接访问设备功能，性能较好。

3. 包大小

H5封装的App劣势：封装了整个 WebView 实例，所以文件大小通常较大。

原生应用优势：可以直接运行在设备上，包大小相对较小。

4. 设备特性访问

H5封装的App优势：享有平台所提供的一些原生组件库。例如，React Native 有 CameraRoll 组件可访问相机和图片库：

javascript

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

原生应用优势：可以直接访问设备的特性（如传感器、硬件加速等），提供更丰富的体验。

5. UI 和 UX

H5封装的App劣势：由于使用了跨平台的UI组件，可能无法完全匹配目标平台的设计规范，用户体验可能会受影响。

原生应用优势：可以完全根据iOS或 Android 的设计规范来定制UI和交互，提供更好的用户体验。

6. 框架和库支持

H5封装的App劣势：虽然有第三方库，但数量和功能可能无法与原生应用平台相媲美。

原生应用优势：拥有庞大的库和框架支持，可以快速实现复杂功能。

7. 社区和生态系统

H5封装的App劣势：相对于原生应用社区，跨平台技术的社区和生态可能更小，资源较少。

原生应用优势：iOS和Android社区庞大，资源丰富。

8. 线上更新

H5封装的App优势：可以像Web应用一样实时更新代码，无需通过应用商店进行发布。

原生应用劣势：必须经历应用商店审核流程。

9. 适用场景

H5封装的App优势：对于功能较简单、追求快速开发的项目，可以节省时间和成本。

原生应用优势：当需要更好的性能、深度集成设备功能或提供达到平台设计规范的用户体验时，原生应用更为合适。

同学们能力有限呀，只能想到这些了，如果你有不同的或者更好的见解评论区，私信我都可以哈，交流交流吧兄弟们，让这个行业在飞黄腾达一下哈哈，H5封装类应用和原生应用各有优劣，需根据具体需求和场景权衡选择。当然，技术的发展也在不断地弥补这两者之间的差距，未来也许会产生新的方式来解决当前存在的问题。

谨如程序员，时间久了还是会有一些"想当然"。不知不觉中就会掉进很多陷阱里。看看这些陷阱，你都中招了吗？

译文：

我对误解很感兴趣。以前我经常在酒吧里主持猜谜游戏（我们这里有的地方叫做“冷知识之夜”），参加过几次的人都知道，如果一道题看上去像是陷阱，那通常它就是陷阱。我的题目里有相当多的“似真似假”的题目，其中所有问题的答案都是假，但几乎没有任何人注意到这一点，因为每道题都是人们平常深信不疑的错误的事情。

等等，这跟编程有什么关系？别着急，继续读下去。

在Hacker News或Proggit上评论的程序员并不是从计算机行业随机选取的，而是这个行业中的精英部分。就像参加任何会议一样，参与评论的这些人都比一般程序员对编程更有热情。

然而，从许多评论中可以看出，许多很厉害的程序员也会有各种信仰和误解，这些信仰和误解虽然错得离谱，但却广为流传。下面是我收集的一些很有意思的误解，附有我的解释。

C语言就是快。

如果说哪个误解会招致差评、导致认知差异、甚至引起口水战？那很可能就是这一条了。

就像其他的误解一样，我对这一条完全不理解。

估计是因为我学C语言的那个时代，人们普遍认为C语言用于游戏编程等很慢，而汇编才是王道。或者是因为，程序都要编译成机器语言，而就像什么顺势疗法一样，汇编语言仿佛是水，能记住自己从哪儿来，从而使得CPU能执行得更快……于是就有了下一条误解。

垃圾回收语言就是慢。

这里说的垃圾回收指的是“跟踪式垃圾回收”。许多人都评论说，在真正的系统中编程时，跟踪是垃圾回收是多么不能忍。要是每条评论我能收一分钱的话，我现在就有好几块钱了。

我大概能理解这一条，因为四年前我也相信。

我还曾经相信后台会有小仙子自动帮我清理那些“明显”会导致程序变慢的代码。以后我会写一篇文章专门讲这个问题。

Emacs是个文本模式的程序。

每次有人说文本编辑器比不上IDE，就必然有人跳出来问，为啥非要用文本模式的编辑器。

我是个Emacs用户，我也不知道为啥他们都要用。类似地还有……

文本编辑器没办法也不应该拥有自动完成、查找定义等功能。

这一条通常会在讨论Emacs是终端程序的帖子里出现。通常还会伴随着一些人说IDE的上述功能是必要的。我也不用IDE编程，估计以后也不会。同样，我很少看到用编辑器用得很溜的人。

不记得多少次看到某人用vim打开一个文件，发现开错了，关掉vim，再打开另一个文件，再关掉……啊啊啊啊啊啊啊啊啊啊。

还有人“喜欢Eclipse”却不知道“查找定义”功能的……简直是奇迹。

由于C ABI是编程的通用语言，所以实现应该也用C语言。

在讨论二进制代码时C语言是真正的胶水语言。

这是有历史原因的，但不可否认在这方面C语言就是王者。但令我大跌眼镜的是，很多人把这句话理解为，如果API是C语言的，那么实现它的唯一语言就是C语言。也不想想Visual Studio的libc是用C++写的。

C和C++是同一种语言，真正的名字是C/C++。

而且没人把Objective C算进去（其实Objective C跟C++不一样，它实际上是C语言的超集），因为……啥原因呢？

C和C++有太多共通的地方，有时候当你想说一些适合两种语言的东西时，写成C/C++是有道理的。但许多时候人们并不是这样用……

在并发编程的容易性方面Rust是唯一的选择。

我估计所有使用Pony、D、Haskell、Erlang等语言的人都不明白这句话。Rust是不是比C++更安全？当然是，但这个标准也太低了。

我第一次用Rust时花了30分钟就死锁了。我感觉并不容易，或者应该说“不考虑数据冲突的话很容易”？反正是很容易上当.

内核只能用C语言。

显然Haiku和Redox被无视了，以及其他一切unikernel框架。

平台的字节序很重要。

这又是一条让我迷惑不解的理论。

我甚至都不知道为啥还有htons和ntohs这两个函数。完全搞不懂，而且更悲惨的是，我跟别人解释这个时，似乎他比我还明白。

我并不是说字节序不重要，而是说99.9%的情况下，人们认为它很重要，实际上却完全无所谓。我肯定会读一次IEEE浮点数的定义，但这并不意味着写任何程序都必须记住哪一部分才是尾数。

Haskell代码能通过编译就能跑！

嗯……不是的。

简单的语言能避免复杂性。

也称为“清扫地毯下面的尘土”迷信。

我并不明白这句话。我的意思是，一项任务的复杂度并不会因为使用了简单的语言而消失，甚至会变得更复杂。有许多负责搞笑的语言极其简单，但真用来写代码就简直是噩梦。

代码覆盖率是测试质量的标准。

我认为覆盖率很重要。我觉得，阅读一份漂亮的HTML覆盖率报告确实能够帮助书写高质量的软件。但我十分确信，追逐代码覆盖率的目标是有害的，而且毫无意义。下面是个很无聊的函数：

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

然后是测试套件：

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

100%的覆盖率。函数甚至连返回值都不对。好吧，其实应该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，多ＣＰＵ核心，缓存层次结构，缓存管线，内存预取，乱序执行，等等。至少现在有原子性了。

我不知道人们给量子计算机写代码的时候还会不会说C最接近硬件。听起来似乎很傻，但我还见过更傻的。

另外，Lisp机器从来没存在过，FPGA/GPA也不是硬件（别忘了Poe定律！Poe定律：只要不明确表明是讽刺，那么不管讽刺得多么夸张，总会有人信以为真）。

做某件事只能用某个语言。

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