基于路由机制设计的app架构思路

转载请注明出处:王亟亟的大牛之路

有差不多接近一个多月没发文了,最近事情比较多。各种会,写各种计划,解决各种问题,以及团队内部扩招那些事(每天邮箱各种简历眼花缭乱)

先安利:我的Git 之后会把内容都往git book等地方迁移,所以对我写的东西感兴趣的小伙们可以follow我的git,以获取最新内容!


对架构的理解

最近聊了许多小伙报价从高到低的各式各样的都有(这里只是举个例子,没有任何贬低的意思)

一提架构张嘴就来 MVC MVP MVVM等等等,如果简历写有大项目的架构经验并且要价偏高的我一般默认这样的小伙不是太可用(先看,别急后面有解释),或者说你之前的项目”不够大”。

如果要价不是很高,经验不是写的很丰富的话那我还可以理解。

为什么这么”默认”?

  1. 太笼统

    MVC那套从写Web时期就一直使用至今,你抓个写java web的也能给你说的头头是道,纸上谈兵没有实际意义

  2. 实用性不足

    每个”重量级”的项目都有不同的实现方式,简单的拿几个英文单词硬套是否真的合理,真的适合自己的应用场景

  3. 知识点滞后

    从国内android/iOS热更(组件化)大潮(15年)出现后各式各样基于分包,插件化等等的内容层出不穷,还指望一套架构吃死那是不可能了。


简易组件化设计

把共同属性的代码提取出来制作成各种基础库,把单独的功能封装成Library包,不同业务通过分包结构分到不同module下,组内每人开发自己的module。

把纯业务模块和非业务模块以及一些”刚需”的代码做了简易的分包,库与库之间的关系看似很完美

写各个模块的小伙伴们可以各做各的,没有任何交集

于是有一天,来了个不可描述的场景

(只是举例子)

直到有一天产品说,我们要集成 TalkingData,我们要Ui库的各个控件必须做埋点!

那怎么办?

ui库的小伙伴去依赖 第三方统计库,去写里面的埋点业务

还有,ui组件的细节我要计算(你别管合理不合理,产品就说要算,我们就模拟这是个必做的业务)

ui库还得去依赖工具库,然后这个架构图成了这样

这只是一轮迭代,后面还有各种不可描述的复杂姿势,导致最后你的项目又一团糟,可维护性又像所有代码在一个包里那样差了

基于”路由的架构设计”

经过重新设计后大致长这样

因为基础功能库确实是一个被依赖可能性极大的库所以我们让他依赖着”路由”库

所有的子包,包括主项目都去依赖这个库,而基础功能库依赖于工具库和”路由”库

工具库放进去的意义就不说了,贯穿整个app过程都有大概率调用工具类,无论是主项目还是子工程包

着重说一下这个”路由”体系对于各个包/内容的意义

对于页面:

提供统一的跳转规则,更可控的跳转拦截,更大的延展性等等等(这部分可以看我之前写的一篇关于ARouter的文章:http://blog.csdn.net/ddwhan0123/article/details/54409574)

对于子包:

所有的包之间的相互调用关系就不存在了,耦合性降低,所有的通信统一都交给路由来处理分发(并且持有规则),而注册工作则交由主工程去进行初始化。无论子包怎么变化(数量与内容),只要在统一的路由规则下都可以畅通无阻地运行,而不是改一处则动全身!

在子包的概念里,路由是规则是关系链

这么做的目的很简单

  • 可测试性增强–只测自己想测的包就行,根本不用管其他包的关系链
  • 复用性增强–类似的基础组件可以在不同的事业群下使用
  • 支持并行开发–你写你的我写我的
  • 耦合降低–除了基础库外,其他库没有了依赖关系

该设计不考虑多进程场景,庞大集群项目需另外考虑考虑

更多架构选择/知识点:

https://github.com/googlesamples/android-architecture

http://www.infoq.com/cn/articles/ctrip-android-dynamic-loading

http://www.open-open.com/lib/view/open1436316754208.html

http://keeganlee.me/post/architecture/20160222

有问题可以联系我:

时间: 2024-10-12 00:24:43

基于路由机制设计的app架构思路的相关文章

App架构师成长路线

点击关注 异步图书,置顶公众号 每天与你分享 IT好书 技术干货 职场知识 参与文末话题讨论,每日赠送异步图书 --异步小编 架构师,软件技术领域一个高大上的名词,业界有言"人人都是产品经理",却很少听到"人人都是架构师".其本身涉及的复杂庞大的跨领域知识体系除外,对于架构一词,其实很难去完整地定义,我们也没必要过于纠结,就如我们为什么要登山,因为山在那里,执着前行,或许还未曾知晓路在何方,抑或你都不曾思考要去何方,但至少你已经在路上,while(!(succeed

Hybrid APP 架构设计思路

关于Hybrid模式开发app的好处,网络上已有很多文章阐述了,这里不展开. 本文将从以下几个方面阐述Hybrid app架构设计的一些经验和思考. 原文及讨论请到 github issue 通讯 作为一种跨语言开发模式,通讯层是Hybrid架构首先应该考虑和设计的,往后所有的逻辑都是基于通讯层展开. Native(以Android为例)和H5通讯,基本原理: Android调用H5:通过webview类的loadUrl方法可以直接执行js代码,类似浏览器地址栏输入一段js一样的效果 webvi

Hybrid APP架构设计思路

原文:Hybrid APP架构设计思路 关于Hybrid模式开发app的好处,网络上已有很多文章阐述了,这里不展开. 本文将从以下几个方面阐述Hybrid app架构设计的一些经验和思考. 通讯 作为一种跨语言开发模式,通讯层是Hybrid架构首先应该考虑和设计的,往后所有的逻辑都是基于通讯层展开. Native(以Android为例)和H5通讯,基本原理: Android调用H5:通过webview类的loadUrl方法可以直接执行js代码,类似浏览器地址栏输入一段js一样的效果 webvie

Hybrid APP架构设计

通讯 作为一种跨语言开发模式,通讯层是Hybrid架构首先应该考虑和设计的,往后所有的逻辑都是基于通讯层展开. Native(以Android为例)和H5通讯,基本原理: Android调用H5:通过webview类的 loadUrl 方法可以直接执行js代码,类似浏览器地址栏输入一段js一样的效果 webview.loadUrl("javascript: alert('hello world')"); H5调用Android:webview可以拦截H5发起的任意url请求,webvi

从服务端架构设计角度,深入理解大型APP架构升级

随着智能设备普及和移动互联网发展,移动端应用逐渐成为用户新入口,重要性越来越突出.但企业一般是先有PC端应用,再推APP,APP 1.0版的功能大多从现有PC应用平移过来,没有针对移动自身特点考虑APP的架构.随着APP越来越复杂,功能和非功能要求越来越高,架构的先天不足逐渐成为大型APP升级的瓶颈. 本文作者结合大型移动应用的落地实践,从服务端架构设计角度,阐述如何进行升级优化,为后续APP做大做强奠定架构基础,供大家参考. 本文主要内容包括: V1架构 问题分析 V2架构 智能升降级 总结

移动App设计之分层架构+MVC(转)

场景分析:我们知道,一个移动设备的应用大多与网络有关,也就是说,我在移动设备上看到的数据,一般都是从Server上”拉“过来,显示在我们的移动设备(ios androiud.wpohone等)上.那我们就这个”拉“的过程分析,拉什么样的数据?去哪里拉?拉过来的数据怎么处理?用编程(开发)的思维看,就是定义什么实体(业务实体).发送请求.解析数据.当然这也只是大体的过程.但从软件架构设计上讲,定义实体.发送请求.解析数据都是具有单独意义的模块.那我们怎么处理这些模块呢? 场景应用:sina wei

android app 架构设计02

二:在开放的过程中,尽量把工具类,BaseActivity 放在指定的位置, DateFormat Bitmap Notification Shared Preference Environment Device 三: 2.2 Task管理 线程只是一种机制,保证我们要完成的任务不运行在UI线程(也就是说不阻塞UI),完成的任务才是我们关注的核心,因此,我们可以通过设计,把线程封装,让使用者根本感觉不到是线程,他只用关心他要做的事情就行了. 这里,我们可以设计一种"异步链式调用"的框架

移动App架构设计

移动App架构设计 本文主要总结了几种经常使用的架构模式, 基本是层层递进的转载请注名出处 http://blog.csdn.net/uxyheaven, 良好的排版在https://github.com/uxyheaven/阅读 假设认为本文不错, 请在csdn给个顶, github给个star. Native app的开发相比传统的项目迭代周期要短非常多, 需求的变化也频繁一些, 在开发的不同生命周期里採用不同的架构模式能够有效的节约开发时间, 提高开发效率, 这篇文章介绍几种经常使用的架构

品尝阿里云容器服务:用nginx镜像创建容器,体验基于域名的路由机制

在前一篇博文中我们了解了阿里云容器服务的路由机制: 请求 -> 负载均衡80端口 -> 容器主机9080端口 -> acsrouting路由容器80端口 --基于域名--> Web站点容器端口 在这篇博文中,我们用nginx镜像创建一个容器实际体验一下. 使用容器服务首先要创建一个集群(Cluster),比如这里我们创建一个名叫websites的集群(使用的是swarm mode): 创建好集群后,点击“管理”,进入集群管理页面 -> “负载均衡” -> “域名设置”,