一种新的架构设计思路，用户行为驱动开发

　　昨日上午微信部分功能出现短暂故障，微信用户登录、消息会话、公众号、小程序、外部链接、文件发送等功能均受到不同程度的影响，持续时间约30分钟。腾讯公关总监张军表示此次bug事件“感觉像是给攻城狮敲了一记醒神棒，哪怕快过年了也别想放松”。

　　作者简介

　　明天就是周六啦，提前祝大家周末愉快!

　　本篇来自 Android_ZzT 的投稿文章，分享了自己一种开发思想，希望对大家有所帮助!

　　Android_ZzT 的博客地址：

　　https://juejin.im/user/57c819d65bbb500074d9f217

　　前提

　　用户行为驱动开发是什么?

　　它是一种适用前端的面向用户行为的开发思想，是一个用户行为的产生到执行，驱动数据的产生，再由数据流驱动渲染的流程。我认为，前端要完成的工作就是接收用户行为，解析用户行为，到给用户一个反馈。在各种用户行为形成一个序列后，在之后的开发中可以得到很多方便。

　　用户行为驱动开发是如何诞生的?

　　由于每个 App 都需要采集数据进行分析，需要进行数据埋点，这些数据往往都是一个用户行为加上一些业务数据，如果使用代码埋点的方式，就会导致 UI 代码中总要掺杂着一些额外的埋点逻辑，比如一个 button 的 onClick 中有一段获取业务数据并发送埋点事件的代码，久而久之，代码就会变得臃肿不堪。现在虽然有无痕埋点的方案，但是成本过高，小公司去开发不是很现实。

　　出了上面的问题后，我意识到用户行为是一个关键点，其实每一个需要采集的数据都由一个或几个用户行为拼凑出来的，比如用户点击了登录按钮，其实就是由两个 Action 组成，ButtonClick 和 LoginAction。再比如，用户上拉加载更多数据，其实就是产生了 PullUpToLoadMore 和 GetXXXDataAction 。

　　带着这样的思考，我就开始尝试了面向用户行为开发。

　　其他说明

　　我是 Android 开发，之后的一些例子可能更适用于移动端，但思路上适合各种前端的

　　观察者(订阅\发布)模式，解耦利器，用户行为驱动开发使用了大量的观察者模式，让每一个部分职责单一明确

　　本文不讲代码的具体实现，只讲思想，之后可能会写其他的文章具体讲实现

　　正文

　　一、UserAction 的类型

　　

　　如图，展示的是移动端的一些基本操作，左边四个是针对列表页面的操作，分别为「下拉刷新」「上拉加载更多」「Item 曝光」「Item 点击」。剩下四个为「PageView -> 浏览页面」「UseDomainService -> 使用业务服务」「 ButtonClick -> 按钮点击」「ComponentShowUp -> 组件展示」。

　　这里具体解释一下「使用业务服务」和「组件展示」

　　「使用业务服务」可以看做是用户在使用公司的业务，比如每个公司都会有登录注册，再比如公司中特殊的业务，如看视频或者获取一组新闻数据等

　　「组件展示」是指一个控件或组件弹出，比如 Android 中的 Dialog\Toast\PopupWindow 以及自定义的 Window 等

　　二、UserAction 驱动渲染的过程

　　首先说说，在一个简单的列表页中，UserAction 是怎样工作的

　　

　　首先不考虑数据是怎么获得的，只想 UserAction 如何应用在 UI 代码中，就是图中的 5 个步骤。 UI 只负责生产对应的 UserAction，然后观察它，它在执行后会产生对应的结果，UI 只需要使用结果去渲染。

　　所以 UI 的职责很明确：

　　产生 UserAction

　　执行 UserAction

　　接收数据，进行渲染

　　UI 中的代码大概就像这样：

　　//页面开始显示一个列表start() { observer = List result -> { render(result); } new GetXXXListAction().execute(observer);}//登录loginBtn.setOnClickListener(v -> { ButtonClickAction btnClickAction = new ButtonClickAction(); btnClickAction.enqueue(); LoginAction loginAction = new LoginAction(); loginAction.execute(observer, params);// observer 用于观察登录状态变化，参数为用户名密码})

　　三、UseDomainAction 的执行过程

　　

　　用户选择使用我们的 app，就是在使用我们提供的业务服务，所以业务逻辑处理是我们平时开发精力投放最多的一部分，我具体说一下「UseDomainService」是如何工作的。基于模块化开发，我们每个业务应该对一个模块，所以 action 执行时就是调用我们的业务模块的接口，这里针对业务模块的异步请求会再次使用观察者模式或是个 CallBack ，action 观察业务模块，然后接收模块返回的结果，再将结果发给执行 action 的页面。

　　下面是针对数据流向的一个图，可概括为UI -> Action -> Data -> ViewModel -> Render，UI 产生用户行为，用户行为驱动数据产生，数据驱动 UI 渲染

　　

　　四、其他 UserAction 的使用方式

　　「PageView」：可在 LifecycleManager 的 onActivityResumed 方法中进行创建，然后取到每个 Activity 的路由 url 或是类名，存放到 PageViewAction 中。如果你有一个 BaseActivity，也可写在 BaseActivity 的 onResume 方法中

　　「PullDownToRefresh/PullUpToLoadMore」: 可在列表刷新控件的 callback 中，创建这个 Action，例如继承 SmartRefreshLayout 然后重写 refresh 和 loadMore 方法，在里面加上对应的 Action

　　「ButtonClick」：和上面

标签：UserAction,架构设计,用户,UI,Action,驱动,思路,行为,埋点
来源： https://blog.csdn.net/weixin_44188140/article/details/87876220