0°

移动架构这么多,如何一次搞定所有?

内容预览:
  • 乐乐有话说人生就像不停在用的铅笔,开始很尖,但慢慢的就磨的圆滑了~
  • 从移动端来谈架构,无非是让代码可以优雅一点,解决一下常见的耦合等问题~
  • Dispatcher保存了不同信号与接收器的对应关系, 以此完成消息的分发 上...~

始发于微信公众号: 程序员小乐

分享编程技能、互联网技术、生活感悟、打造干货分享平台,将总结的技术、心得、经验分享给大家,这里不只限于技术!还有职场心得、生活感悟、以及面经点击上方 “程序员小乐” ,选择“置顶公众号”,第一时间送达!


每日英文
The road ahead is still a long way, you may cry, but must go on, must not stop .Those who can’t lose will never win either.
前面的路还很远,你可能会哭,但是一定要走下去,一定不能停。输不起的人,往往就是赢不了。

乐乐有话说
人生就像不停在用的铅笔,开始很尖,但慢慢的就磨的圆滑了。不过,太过圆滑了,就差不多又该挨削了。

我是一个Android猴, 主要从Android端来谈一下对各种结构的看法,总结一下基础架构的核心是什么?因此,这篇文章对于对架构一词不是很了解,或者一知半解的朋友来讲, 梳理一下大局观;并且我觉得同样的作为移动开发,IOS与Android的架构差异化并不是很大。

从移动端谈架构,其实有点夸大了。因为移动端的项目往往不是很大,或者模块不是很大。一般架构这个词,可能用在Web端比较好一点,也更有效点,架构好了,意味这更稳健的运行效率, 更大体量。从移动端来谈架构,无非是让代码可以优雅一点,解决一下常见的耦合等问题。

从Android诞生至今,移动端的架构变更了很多次,从最初的MVC到MVP, 从冷门的Flutter(由RN引入到移动端)到Google的AAC/MVVM;好像架构的思想一直在变,但是大抵都是换汤不换药的,为什么这么说呢 ? 让我们来总结一下。

MVC
MVP
MVVM
Flutter
AAC

以上的架构中MVX系列先不说,剩下的两个是什么? 先来解释一下。

Flutter

此Flutter非目前炒得火热的Flutter, 而是由React Native衍生而来的,适用于移动端的框架。是的,这也是一种框架思想。Flutter的元素分为3种: View(不必多说), Model(也不必解释吧), Store(这个要说一下,用于处理Action的核心类,类似Presenter的作用), Dispatcher(Action路由), Action(事件)。该框架类似于MVP, 只是通信模块由接口,改为路由系统。

AAC([Android Architecture components]
不知道的可以查看一下官网:

https://developer.android.com/topic/libraries/architecture/guide.html

public class UserProfileViewModel extends ViewModel {
   private String userId;
   private User user;
   public void init(String userId) {
       this.userId = userId;
   }
   public User getUser() {
       return user;
   }
}

.

public class UserProfileFragment extends Fragment {
   private static final String UID_KEY = "uid";
   private UserProfileViewModel viewModel;
   @Override
   public void onActivityCreated(@Nullable Bundle savedInstanceState) {
       super.onActivityCreated(savedInstanceState);
       String userId = getArguments().getString(UID_KEY);
       viewModel = ViewModelProviders.of(this).get(UserProfileViewModel.class);
       viewModel.init(userId);
   }
   @Override
   public View onCreateView(LayoutInflater inflater,
               @Nullable ViewGroup container, @Nullable Bundle savedInstanceState) {
       return inflater.inflate(R.layout.user_profile, container, false);
   }
}

以上是来自官网的AAC-Demo的源码,看结构其实就清楚了,如果允许自己命名的话,或者我们可以称为MVVM了;ViewModel这个模块,是不是像极了Controller或者Presenter。

通过以上框架的分析, 我们应该可以得出结论:

局部的架构,为什么说是局部架构?因为项目级得架构肯定就是大结构的组件化与插件化。

1.分层

从代码的实现解耦。对于现在狭义上的架构,M和V是必然单独的两层,因为数据处理和UI嘛,界限很清楚。难以划分层次的就是逻辑实现,也就是我们的业务处理。而Controller, Presenter, VM这些模块的功能都是一致的

所以分层的维度几乎已经确定,就是 数据处理(Model), UI显示(View), 业务处理(X)

2.通信

不同的模块,好像层次划分都是一致的,虽然骚气的取了不同的名字。但是区别就在于通信方式。

MVC/AAC的通信方式是对象, View与Model的交互是完全通过对象来实现的,如下

public class Model {
   /**
    * 这是Model模块,负责数据处理。处理的方式不尽相同,但是本质一样。如网络请求, 数据库, 文件等等
    */

   public void postLogin(String username, String password, Callback callback) {
       // 执行登陆请求,验证帐号密码是否正确
       callback.onResponse("登录结果");
   }
   public interface Callback {
       void onResponse(String result);
   }
}

.

public class View {
   X controllerOrPresenter;
   public void onClick() {
       // 点击登录
       controllerOrPresenter.login("xxx", "xxx", new Model.Callback() {
           @Override
           public void onResponse(String result)
{
               if ("success".equals(result)) {
                   // 登录成功,则提示登录成功,保存信息
               } else {
                   // 登录失败,则提示失败
               }
           }
       });
   }
}

.

public class X {
   Model model;
   View view;
   public void login(String username, String password, Model.Callback callback) {
       // 验证帐号, 密码格式是否正确
       model.postLogin(username, password, callback);
   }
}

以上代码是MVC模式, 是不是这么处理的?通过持有对象来达到模块之间的通信。当时可能会觉得这样耦合度比较高,这样就出现了解决方案。于是MVC做成了MVP(哦,当然,那时候还不这么叫),通过接口的方式来通信,或许接口化没那么彻底而已。AAC通过绑定页面的周期做到随页面释放并包装

MVP的通信方式是完全接口式通信, V和P之间,甚至M和P之间也可以

MVP的方式来解释一下,V和P分别实现自己的接口, IV和IP。然后分别传如自己的接口达到调用目的。代码如下:

public interface IP {
   void login(String username, String password);
}

.

public interface IV {
   void loginSuccess();
   void loginFailed();
}

.

public class View implements IV{
   X iP;
   public void onClick() {
       // 点击登录
       iP.login("xxx", "xxx");
   }
   @Override
   public void loginSuccess() {
       // 保存信息
       // 提示登录成功了
   }
   @Override
   public void loginFailed() {
       // 提示登录失败
   }
}

.

public class X implements IP{
   /**
    * X 相当于MVP中的Presenter
    */

   Model model;
   IV iV;
   public void login(String username, String password) {
       // 验证帐号, 密码格式是否正确
       model.postLogin(username, password, new Model.Callback() {
           @Override
           public void onResponse(String result) {
               if("success".equals(result)) {
                   // 登录成功
                   iV.loginSuccess();
               }else {
                   // 登录失败
                   iV.loginFailed();
               }
           }
       });
   }
}

以上是MVP的通信方式,完全的接口相互调用。可能一些架构思维比较前卫的公司,在前期就把MVC改造成了如今的MVP,还是那句话,只是那时候不那么叫罢了。

Flutter是以路由机制来实现解耦通信

在现在组件化风行的时代,相信各位对路由没那么陌生了。就算不了解, 那么路由器总知道吧,那么先说路由器。

路由或路由器,分两个模式: 接收信号, 发出信号。分别是多对一和一对多的关系。

举个例子, 现实中的路由器,接收只有一个入口,但发出口有很多个,毕竟如果只有一个出口,那么路由器就没用了。在路由机制中,入口也可以有多个。所以就是上面说的,接收是多对一(一当然是路由器), 发出是一对多(一还是路由器)。

简单由一个图来说明一下路由机制,图不是很规整,明白就好。

移动架构这么多,如何一次搞定所有?在Flutter模式下,我们如何对应呢?

M/V/P或C不同模块之间不能有耦合,即不持有对象,且不持有接口,完全解耦。那么各模块怎么通信呢?通过向路由器发信号。所以M V P/C 都是上图的信号源

M/V/P或C 不同模块要交互,那么怎么得到信号呢? 这时候他们的角色就转变了,不仅可以发信号,也可以接口信号,来做对应处理。 所以M V P/C 也同样是上图的手机(信号接口器)

以上的解释, 不同模块既可以发出信号,也可以接收信号。和Android中的一个组件很相似,就是Handler. Handler既可以发出消息,同时消息又在里面处理。

既然有发送信号的, 有接收信号的,那么必然有一个路由器负责接收与发送,在Flutter中就是Dispatcher。Dispatcher保存了不同信号与接收器的对应关系, 以此完成消息的分发

上面都提到了消息,现在正式的介绍一下,消息是角色是Action

看一下Flutter的元素

Model
View                                      
Store(Controller或Presenter)   处理业务逻辑
Action 消息对象,带有动作与数据
Dispathcer 路由,管理消息与发送消息,保存有一张对应表

接下来通过代码了解一下

public class Model {
   public void postLogin(User user, Callback callback) {
       // 请求登录
       callback.onResponse(1);
   }
   public interface Callback {
       void onResponse(int result);
   }
}

.

public class User {
   public String username;
   public String password;
   public User(String username, String password) {
       this.username = username;
       this.password = password;
   }
}

.

public class View implements Dispatcher.IReceiver {
   public void onCreate() {
       Dispatcher.getDispatcher().register(this);
   }
   public void onDestroy() {
       Dispatcher.getDispatcher().unregister(this);
   }
   void onClick() {
       Dispatcher.getDispatcher()
               .sendEvent(
                       new Action("login", new User("xxx", "xxx")));
   }
   @Override
   public void onReceive(Action action) {
       if (action.name.equals("login-success")) {
           // 登录成功提示
       } else {
           // 登录失败提示
       }
   }
}

.

public class X implements Dispatcher.IReceiver{
   Model model;
   public X() {
       model = new Model();
       Dispatcher.getDispatcher().register(this);
   }
   public void clearX() {
       model = null;
       Dispatcher.getDispatcher().unregister(this);
   }
   @Override
   public void onReceive(Action action) {
       if(action.name.equals("login")) {
           model.postLogin((User) action.data, new Model.Callback() {
               @Override
               public void onResponse(int result) {
                   if(result == 1) {
                       // 登录成功
                       Dispatcher.getDispatcher().sendEvent(new Action("login-success", null));
                   }else {
                       // 登录失败
                       Dispatcher.getDispatcher().sendEvent(new Action("login-failed", null));
                   }
               }
           });
       }
   }
}

.

public class Action<T> {
   public String name; // 执行动作,比如“登录”
   public T data; // 数据,比如username, password
   public Action(String name, T data) {
       this.name = name;
       this.data = data;
   }
}

.

public class Dispatcher {
   private static Dispatcher dispatcher = new Dispatcher();
   private List<IReceiver> receivers = new ArrayList<>();
   private Dispatcher(){}
   public static Dispatcher getDispatcher() {
       return dispatcher;
   }
   public void register(IReceiver receiver) {
       if (receivers.contains(receiver)) {
           throw new IllegalStateException("receiver has been registerd yet!");
       } else {
           receivers.add(receiver);
       }
   }
   public void unregister(IReceiver receiver) {
       if (receivers.contains(receiver)) {
           receivers.remove(receiver);
       }
   }
   public void sendEvent(Action action) {
       if (action != null && action.name != null && action.name.length() > 0) {
           for (IReceiver r : receivers) {
               if (r != null) {
                   r.onReceive(action);
               }
           }
       }
   }
   public interface IReceiver {
       void onReceive(Action action);
   }
}

解析一下以上代码, 首先我们说过, 所有模块既是消息发出者,也是消息接收者。代码中,View和X都分别发出了消息进行登录以及登录结果成功或失败;同时View和X也都注册了接收器的接口,在onReceiver中可以接收消息。这样做的好处是什么? View和X完全没有耦合,既不持有对象, 也不持有接口,中间的通信都是通过Dispatcher进行分发的,解耦已经很彻底了。Dispathcer就是路由器,负责接收,并分发消息,应该很好理解,哪个组件想接收消息,那么就注册一个接收器,这样有合适的消息自然就接收到了。

当然,以上的代码有点简陋,可以从不同组件再行封装,比如Action, 比如Dispatcher, 比如BaseView等等。我们可以通过给路由注册机制添加Group与Tag(Action name)概念来优化效率问题,这里只是说思想。

我们知道了什么?

1.我称移动端的架构思维为MVX,即是说按这个规则的分工被开发市场所接受了,我们不用费尽心思考虑狭义架构的分层问题了,就沿用Model-View-X来就可以。当然还可以自己加一些辅助的模块层,如Worker负责异步, Converter负责转换, Verify负责校验等

2.移动端目前的架构,差异化在于通信机制。通过以上说明,通信机制主要分为3种:

1) 对象持有
2) 接口持有
3) 路由

3.通信方式中,对象持有是比较原始的,解耦率最低,建议放弃; 接口持有是个不错的选择,极大程度上实现解耦的诉求,但是解耦不彻底,相互持有交互方的接口。 路由机制也是个不错的选择,可以实现完全解耦,就像组件化一样。但是路由机制的设计是个技术难点,怎么设计效率最高?更健壮?代码可查阅性更好?这些都是值得思考的问题。

4.对于路由机制的优化,阿里的ARouter(用于组件通信)中,采用了分组的模式,我们可以采用;其次可以根据AnnotationProcessor的处理,为每一个注册接收器的组件实现一个SupportActions来确保消息只发送给注册了指定类型的模块,也是个不错的选择。

通过以上分析与总结,可以看到,移动端的框架核心是一定的,只要理解了架构的核心思想,其实出多少新的框架,不过是加了一些解决部分问题的实现罢了。看懂了这篇文章,可能再出什么架构模式,或许看一眼就明白是怎么实现了呢?

如果您觉得不错,请别忘了转发、分享、点赞让更多的人去学习, 您的举手之劳,就是对乐乐最好的支持,非常感谢!


如何您想进技术群和大牛们交流,关注公众号在后台回复 “加群”,或者 “学习” 即可

来自:亓春杰

链接:https://www.jianshu.com/p/d77630d691dc

著作权归作者所有。本文已获得授权。欢迎投稿。

移动架构这么多,如何一次搞定所有?

推荐阅读


移动架构这么多,如何一次搞定所有?

看完本文有收获?请转发分享给更多人
关注「程序员小乐」,提升技能

以上就是:移动架构这么多,如何一次搞定所有? 的全部内容。

本站部分内容来源于互联网和用户投稿,如有侵权请联系我们删除,谢谢。
Email:[email protected]


0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论