关键词：

小程序开发,App开发,爬虫公司,厦门爬虫科技,厦门App开发,厦门小程序开发

在互联网应用的早期，大多数都是采用的这种架构。项目所有代码打包在一个jar包中，并部署在价格昂贵的小型机上面。一个项目的服务器基本就只有一台小型机，数据库，应用都部署在上面。最早的App有很多采用这种架构，大多数尝试性的业务，一开始也是这样的架构。Web App架构又叫包壳架构，简单来说就是在Web的业务上包装一个App的壳，业务逻辑完全还是Web实现，App壳完成安装的功能，让用户看起来像是在使用App，实际上和用浏览器访问PC网站没有太大差别。

由于当时互联网用户并不是很多，所以这套架构还是可以支撑日常使用的，但随着互联网用户的爆发式增长，一台小型机的资源已经不足以支撑一个项目的日常运行（当时想对小型机加资源还是比较困难的，并且对于早期的jdk版本来说，内存过大会造成性能降低，并不能一味加内存来支撑更多的业务），这时候人们开始探索分布式的部署。

Web App虽然解决了“快速开发”和“低成本”两个复杂度问题，但随着业务的发展，Web App的劣势逐渐成为了主要的复杂度问题。因此，随着业务发展和技术演进，移动开发的复杂度从“快速开发”和“低成本”转向了“用户体验”，而要保证用户体验，采用原生App的架构是最合适的，这里的架构设计遵循“演化原则”。原生App解决了用户体验问题，没记错的话大约在2013年前后开始快速发展，那个时候的Android工程师和iOS工程师就像现在的人工智能工程师一样非常抢手，很多人也是那时候从后端转行到App开发的。

原生App很好的解决了用户体验问题，但业务和技术也在发展，移动互联网此时已经成为明确的大趋势，团队需要考虑的不是要不要转移动互联网的问题，而是要考虑如何在移动互联网更具竞争力的问题，因此各种基于移动互联网特点的功能和体验方式不断被创造出来，大家拼的竞争方式就是看谁更快抓住用户需求和痛点。因此，移动开发的复杂度又回到了“快速开发”，这时就发现了原生App开发的痛点：由于Android、iOS、Windows Phone（你没看错，当年确实是这三个主流平台）的原生开发完全不能兼容，同样的功能需要三个平台重复开发，每个平台还有一些差异，因此自然快不起来。为了解决“快速开发”的复杂度问题，大家自然又想到了Web的方式，但Web的体验还是远远不如原生，怎么解决这个问题呢？其实没有办法完美解决，但可以根据不同的业务要求选取不同的方案，例如对体验要求高的业务采用原生App实现，对体验要求不高的可以采用Web的方式实现，这就是Hybrid App架构的核心设计思想，主要遵循架构设计的“合适原则”。

想看更多的资讯内容可以点击 厦门App开发公司 | 爬虫公司 | 小程序开发公司