微信小程序应用场景是什么

微信小程序的应用场景是怎样的？以下是小编编写的微信小程序的应用场景是什么的内容。如果想了解更多微信小程序的应用场景。下面我们来看看小编整理的内容。希望对你有帮助。

1.微信小程序是什么？

微信内置的云应用不需要安装和，可以用完。

名称是：小程序，可以理解为“嵌入微信的app”

与订阅号、服务号、企业号属于同一级别系统。于是，小程序、订阅号、服务号、企业号形成了四个并行的微信生态系统。

3.小程序的应用场景

了解其功能和特点后，小程序适合哪些需求场景？请看下图：四象限需求层次图：

横轴=需求刚性，纵轴=需求频率，象限=需求类别。

3.1象限1:高频，按需

对于高频率和急需的使用场景，由于用户使用频率高，产品形式要求：

寻找产品的成本更低

性能和流畅度要求非常高

小程序不使用高频率的、仅需要的使用场景，因为小程序：

找产品成本高：每次都要在微信里重新搜一遍，成本比固定在手机上某个位置要高得多

性能和流畅度不如原生应用

结论：小程序不适合高频、按需的需求场景，这种场景应该使用原生应用。

3.2象限2:高频，不只是需要

对于高频率和非直接需要的使用场景，根据情况，涉及到多种类型的产品(内容类型、工具类型、社区类型和游戏类型):

娱乐需求(阅读、音乐、视频、游戏、社区)

基于内容的阅读产品

需要深度阅读环境和高度互动视觉体验，建议使用原生app

当然，您也可以先使用订购号或服务号进行分流

带有部分工具(如音乐和视频)的基于内容的产品

在满足功能和性能的前提下，基于开发成本和使用成本，建议采用小程序。

社区产品

由于微信有很强的关系链，建议使用小程序快速试错/作为入口，尝试成功后再将流量导入原生app

游戏产品

小程序不允许玩游戏。

日常工具产品

在满足功能和性能的前提下，建议采用基于开发成本和使用成本的小程序。

如果野心够大，有足够的战略布局成为平台级产品，比如美图秀秀，可以先做一个小程序，然后引导到原生app

具有部分操作或媒体属性的产品

根据张小龙对小程序的定义：当你用完的时候，可以预测微信对于小程序的推送消息和操作会非常克制。这不同于订阅号/服务号推送消息和应用推送消息。所以，如果你的产品以运营为主，或者是有一定媒体属性的产品，建议你还是优先考虑订阅号或者服务号(带发消息功能)，甚至是原生app。

特别提及：

由于高频和非急需场景市场已经被巨头垄断，很多创业者基本都会选择切入高频和非急需场景

与“原生app开发难度大、周期长、获取客户成本极高、推广成本极高”的现状不同，小程序在开发成本和性能体验上实现了微信沟通能力和客户获取能力的良好平衡，创业者应该通过小程序尝试mvp产品

结论

对于高频和非按需使用场景，根据产品形式测试，小程序主要适用于：

带有部分工具的基于内容的产品

日常工具产品

社区产品(作为分流功能)

企业家探索比较有价值产品的形式

3.3象限3:低频，不只是需要

对于低频非刚需需求，基本上是小众需求，一般有两种情况：

开发者自己的兴趣/专业级产品，在一定程度上面对专业用户

第二种情况，因为专业产品一般性能和交互体验更高，所以原生应用。

3.4象限4:低频，按需

对于低频率、按需需求场景，有大量长尾的生活服务需求，比如各种旅游需求，各种上门服务等等。这种长尾需求的现状是：

原生app:使用过于频繁(一个月只有一两次，甚至半年一次)的原生app，占用手机大量内存

subscriptionno。/serviceno .webapp的性能和流畅体验无法满足功能需求

没错，这种长尾需求的解决方案是在原生app和订阅号/服务号之间进退两难，applet是webapp和原生app之间的中间产品形态：在开发成本和性能体验之间取得了很好的平衡。

因此，小程序正是这种需求场景的解决方案。

结论：小程序非常适合低频长尾寿命服务。

3.5总结

小程序场景摘要：(按优先级顺序)

基本涵盖所有低频，只需长尾服务需求场景

初创企业探索产品模式

作为一个增量渠道，它对原生应用进行分流

少量高频和非急需场景

这是题目的开头。微信小程序数据库在哪里？标题到此结束

小程序数据库可以让数据的查询整理更加方便，也可以让数据和操作尽可能的接近，但是很多人反映找不到数据库，那么微信小程序数据库在哪里呢？

以前微信小程序不能直接连接数据库，应该通过小程序接口连接数据库。但是现在小程序的功能已经很完善了，小程序数据库就在小程序的后台。对于用户来说，他们只需要打开小程序就可以使用数据库，但是对于开发人员来说，他们应该更了解小程序数据库的编译。

如何编写“数据库小程序”:

你可能认为只要数据库支持函数语言或者过程语言，就可以写‘数据库小程序’。

这个想法是对的，但是要知道数据库提供的流程语言是比较简单的，包括oracle的pl/sql和postgresql的plpgsql。虽然它们功能强大，但无法与go、java、python、r等常见编程语言相比。尤其是一些非常专业的领域，可能会有非常专业的语言来支持，比如数据分析领域r语言首当其冲。

为了让“数据库小程序”承担真正的小程序功能，只支持数据库的“粗糙”语言似乎是不够的。以下是具体要求：

1支持地球语言

postgresql就是这样一个数据库。理论上，你可以使用小程序开发语言(只要是地球语言)作为它的数据库端编程语言。目前支持的语言好很多，都是以语言插件的形式提供的。

c，plpgsql，plpython，plperl，pltcl，plr，pljava，p8，我能说出名字的编程语言恐怕少了，其实支持的语言数不胜数。

除了编程语言的支持，我们还需要考虑别的吗？

2机箱坚固，扩展能力强(可靠性、ha、性能等。都是机箱技术)

postgresql的开放性不仅表现在编程能力的扩展上，而且在postgresql生态中有很多与业务密切相关的应用，如化学分子、图像、基因数据、文本(包括高效正则化、模糊性、全文检索、文本相似性查询等)的存储和处理。)，并访问外部数据源。

一些有趣的小程序数据库特性如下：

1.支持使用c、plpgsql、plpython、plperl、pltcl、plr、pljava、p8等常用语言编写数据库端函数。

同时还可以根据postgresql提供的扩展接口扩展更多的编程语言

https://www.postgresql.org/docs/devel/static/xplang.html

2.数据类型支持丰富，如数组、序列、uuid、jsonb、gis、文本、异构类型、键值类型(hstore)、全文检索、化学、图像、基因、外部数据源等。除了传统的数据类型，还支持用户定义的扩展类型

3.支持btree、hash、gin、gist、spgist、brin、rum和bloom等索引类型。

这些索引可以用来支持常用排序，如大于、小于、等于、任意列等于查询，也可以支持数组和全文搜索匹配、图文相似排序、重叠查询、地理位置操作、knn等异构类型。并支持块级索引(这在物联网场景中非常有用)。

同时允许用户自定义索引界面，支持更多的数据类型。

4.sql语法层支持2021年的大部分sql标准和扩展的sql用法：返回、游标、异步消息、ecpg、窗口查询、递归查询、分组集、向上跳转、跳过锁、adlock和其他语法。

5.连接，支持散列连接，合并连接，嵌套循环连接，6.优化器支持自定义成本因子、cbo、遗传算法等。

7.此外，gpu可以用于加速操作，包括隐式加速或显示加速。

隐式是指数据库本身提供的自定义扫描提供者编程接口，已经实现了插件。

explicit指的是程序语言和cuda的结合，比如pycuda。

8.多核处理也可以方便地用支持并行编程的语言实现(postgresql9.6已经支持内置并行计算(包括全表扫描、散列连接、散列聚合等)。)).

9.通过fdw接口访问几乎所有外部数据