app消息通知是应用程序与用户通信并可能将用户带回应用程序的媒介之一。因此，app通知模型是应用程序设计的一个非常重要的部分。本篇文章将会介绍3种app消息通知模型，探索不同通知模型的使用场景，为你设计出更好的app消息通知，提供帮助。下面让我们来了解一些现有的最流行的通知模型，以及何时使用其中一种更有意义。
1. 通知中心
在通知中心这种消息推送通知模型中，你的所有app消息通知都会放置在一个已定义的位置。通知中心app通知模型，可以是专用屏幕或弹出窗口，具体取决于可用空间。在此通知模型中，所有app消息通知都锚定到通知中心，无论其来源如何。然后，你可以从通知中心导航到app消息通知的来源。这种app通知模式的最大优点是它的灵活性。这是一个可以容纳所有app消息通知的地方，无论是来自现有来源的还是新的东西。
通知中心使用场景
-
所有不同类型的app消息通知都必须经过深思熟虑，并且应该遵循相同的设计模式。在设计模式时，将可伸缩性视为我们的主要目标很重要。
-
如果你的app消息通知来源过多，此模型可能会开始显得有些混乱。如果有类似类型的app消息通知，你可以将它们组合在一起，这将有助于减少重复。例如，“张三和其他 3 人向你发送了好友请求”。
-
确保通知中心易于发现和访问。
注意事项
-
如果你的产品需要无法锚定到任何现有导航选项的通知，这可能是因为app消息通知与产品上的现有对象不一致，或者app消息通知不是源自信息架构中定义的任何来源。
-
可能的app消息通知来源比应用程序在登陆屏幕上所能容纳的要多。
-
当你时间不多的时候，比如在某些情况下，你可能需要在有时间考虑所有可能的通知场景并找到每个app消息通知的锚点之前发布一个功能。在这种情况下，通知中心可能让你柳暗花明又一村，因为它本质上非常灵活。
2. 来源锚定通知
在来源锚定通知的消息推送通知模型中，每个app消息通知都锚定到一个导航选项，该选项也很可能是通知的来源。你的所有app消息通知都没有一个集线器/中心。该模型在很大程度上取决于app的信息架构。
导航必须能够适应所有不同类型的app消息通知。与之前的模型一样，此处的已读通知和未读通知在视觉上有所不同也很重要。
来源锚定通知使用场景
-
确保每个app消息通知都可以锚定到登陆屏幕上的导航选项之一。随着应用程序复杂性的增加，通知源的数量也可能会增加。在这种情况下，你既可以选择通知中心，也可以考虑混合模型（即锚定模型和通知中心的组合）。
-
每个锚点都应该有一个它所容纳的内容的设计模式。确保你的app消息通知符合锚点的架构
-
确保锚点易于发现和访问。避免使用嵌套锚。
在以下情况下使用源锚定通知
当登陆页界面UI上可以容纳所有可能的app消息通知来源时。
3. 混合模式
该模型是两种模型的组合。混合模式的消息通知模型是最常用的模型。在这里，通知中心成为导航菜单中的选项之一，可用作不符合登陆屏幕条件的来源的锚点。
该app消息通知模型具有两种模型的优点，并且可以轻松适应大多数情况。尽管现在你可以将通知锚定到通知中心，但仍然必须考虑所有场景并优先考虑源锚定app消息通知可以适应的情况。就像源锚模型一样，这个模型也严重依赖导航菜单，现在也有通知中心作为选项。
混合模式通知模型使用场景
-
识别并排列产品架构中最重要的信息桶。对它们进行排名将允许你优先考虑哪些app消息通知应该锚定到源，哪些应该进入通知中心。
-
确保主锚点和通知中心作为登陆屏幕导航的一部分并很容易被发现。
注意事项
-
你已经考虑了app消息通知方案。你有一些app消息通知可以锚定到它们各自的源，但其他一些通知不能锚定到体系结构中的任何现有源。
-
你的导航中有嵌套的来源。
4. 专业的在线协同设计工具Pixso
Pixso是一款在线UI/UX设计工具，在APP移动UI设计、交互设计方面也是很方便的，并且它可以进行团队协作，查看相关反馈，这对于我们的设计师设计app通知栏来说非常有用。
除了以上基本的交互操作，Pixso还有很多非常实用的功能，比如说具备实时在线协作、一键交付、多功能文件导入、全局样式自动布局、团队协作等多个功能，通过低代码交付，所有图稿信息均可转化为代码，开发人员直接在代码面板中查看和复制代码。
通过这些Pixso设计工具能够有效解决以往设计中，团队沟通难、设计效率低、资源管理乱等痛点。因此，这里Pixso设计师强烈推荐大家试用一下，相信大家会有很多收获。
