Android App架构, 技术选型,技术堆栈,工程架构分层设计,项目重构(!!!)

    在Android App中,哪些是我们需要的横切关注点?个人认为主要包括以下几个方面:Http, SharedPreferences, Json, Xml, File, Device, System, Log, 格式转换等。

Bob大叔 所说:“Architecture is About Intent, not Frameworks”

-- Android APP架构思考- https://blog.csdn.net/xiaxl/article/details/72593945
  从2011年到现在,做了几年的Android应用与Android平台上Opengl es应用开发,下面是关于Android APP开发架构的一些思考:构建框架的最终目的是增强项目代码的可读性 ,维护性 和方便测试 ,如果背离了这个初衷,为了使用而使用,最终是得不偿失的。

从根本上来讲,要解决上述的三个问题,核心思想无非两种:一个是分层 ,一个是模块化 。两个方法最终要实现的就是解耦,分层讲的是纵向层面上的解耦,模块化则是横向上的解耦。
  框架和通信方式:模块内部,采用观察者回调进行通信模块之间采用广播(或者其他进程间通信方式)进行通信.
- 以广播举例: 
+ 1、主模块内部采用事件回调进行通信; 
+ 2、主模块使用广播将事件传递给子模块;
+ 3、每个子模块内部采用事件回调进行通信;

-- 简洁架构 意味着产品系统中遵循一系列的习惯原则:
 1.框架独立性
 2.可测试
 3.UI独立性
 4.数据库独立性
 5.任何外部代理模块的独立性
 6.Entities:是指一款应用的业务对象
 7.Use cases:是指结合数据流和实体中的用例,也称为Interactor
 8.Interface Adapters: 这一组适配器,是负责以最合理的格式转换用例(use cases)和实体(entities)之间的数据,表现层(Presenters )和控制层(Controllers ),就属于这一块的。
 9.Frameworks and Drivers: 这里是所有具体的实现了:比如:UI,工具类,基础框架,等等。

   ClassLoader/泛型/反射/注解 .
   不要天天谈什么框架,什么库,框架每年层出不穷,可是扒下框架那层炫酷漂亮的外衣,里面还是那些最基础的知识和原理。就是这些算法,数据结构,计算机网络,计算机原理这些看似基础的东西。面试数据结构和算法,可以面出你的思维能力,思考能力,这个能力对于编程来说很重要。比如:如果面试你使用过什么框架吗?你说:会,使用过,然后你谈了谈使用这些框架的一些知识和遇到的坑,以及怎么解决的?通过这样的问题,不能看出的思维能力和编程能力,只能看出你确实会用这个东西。
   学习的最佳方式就是阅读,对程序员来说也是如此。如果你想成为一个更优秀的程序员,你必须阅读更多的代码,就是这么简单。书籍,博客,论坛在某种程度上都是有益的,但是没有什么能替代功能完善、代码详细的开源项目。整个app的所有相关资源都直接呈现在你面前。这些都是很好的学习素材,不管是代码设计、UI设计还是产品设计都值得我们学习和借鉴。
   2017年4月,随着流量分析工具 StatCounter 的报告,,Android 首次超越 Windows,成为用户访问互联网最常用的操作系统!Android 不仅在移动领域,在全操作系统内,都成为了当之无愧的霸主!

App架构经验总结- http://www.iteye.com/news/31472

-- 怎么架构一个APP?
  有些东西还是通用的,是所有架构师都需要考虑的,也是所有项目都会有的需求,比如API如何设计?架构如何分层?开发环境和生产环境如何分离?
 1.从API开始 ,一个App,最核心的东西,其实就是数据,而数据的主要来源,就是API。
 2.制定安全机制 ,设计API第一个需要考虑的是API的安全机制。保证API的调用者是经过自己授权的App;保证数据传输的安全。
 3.接口协议标准化 ,API返回的数据,一般都是采用JSON格式进行传输。
 4.接口版本控制 ,我们已经不止一次因为接口发生变动而导致旧版本的App出错的问题,而且变动不一定是修改了接口本身,有可能是底层增加了一种新的数据结构,接口把新数据也返回给客户端了,但客户端旧版本是解析不了的,从而就导致出错了。 
 为了解决接口的兼容性问题,需要做好接口版本控制。实现上,一般有两种做法: 
   a.每个接口有各自的版本,一般为接口添加个version的参数; 
   b.整个接口系统有统一的版本,一般在URL中添加版本号,比如http://api.domain.com/v2。 
 5.架构分层 , API的设计完成之后,接下来我就会考虑App项目的整体架构了。整体如何架构,我也曾经做过不少尝试。早期的时候,Android就是将所有操作都放在Activity里完成,包括界面数据处理、业务逻辑处理、调用API。后来发现Activity越来越臃肿,代码越来越复杂,很难维护。于是就开始思考如何拆分,如何才能做到松耦合高内聚。 
  从App对数据处理的角色划分出发,最简单的划分就是:数据管理、数据加工、数据展示。相应的也就有了三层架构:数据层、业务层、展示层。 从上往下:展示层,业务层,数据层。
 6.环境分离 , 每个App项目,至少都会有两个环境:测试环境和生产环境。多的甚至有四个环境:开发环境、测试环境、预生产环境和生产环境。开发人员经常需要在环境之间切换,测试人员也同样。
 7.应用层(MVC MVP等)-> 组件层(推送 社会化分享等)-> 基础层(网络通信、数据解析、日志记录等)-> 跨平台(消息处理 IO操作 线程等)。。。

 8.客户端架构,这一层是对APP的横向拆分,根据业务的特点,分为Native,H5,SDK三块。SDK化和SOA服务化的主要区别是解决思路的不同。SDK化是模块的横向切分,进行部门间、公司间协作。SOA服务化的思路是独立、单一、解耦、提高复用,最好是在分层之后再按模块分类。因为不同的层,分类的标准都有可能不同。
  将传统的APP分为三层。界面层只做界面相关的事情,和UI一起开发;数据层专门负责API接口的实现,和APP后台一起开发。业务逻辑层主要用来实现业务规则,做到与数据和界面无关,尽量提高复用度。

 9.对于一个App来说,不管大小,我们在开发的过程中或多或少,都会碰到下面罗列的各种模块,需要我们去处理。

业务处理,对用户输入的校验和展现判断等;
 统计处理,对当前App或者对业务的数据统计等;
 UI效果,包括主题配置,按钮,输入框,动画效果,自定义控件等;

 更新升级,当前App的检查更新等;

 服务器通信,与服务器通信获取数据,心跳连接等;

 数据解析,比如对json,对xml等的解析等;
 分享处理,分享到微信朋友圈;
 通知消息,Notification处理;
数据存储,包括SharedPerference和SQLiteDatabase;
 文件处理,对SDCard的读写;
 异常处理,对DefaultUncaughtExceptionHandler的使用

  Android的开发知识,Android的单元测试、代码规范、版本控制、重构、架构等。

10. 应用层(MVC MVP等)-> 组件层(推送 社会化分享等)-> 基础层(网络通信、数据解析、日志记录等)-> 跨平台(消息处理 IO操作 线程等)。。。

11.APP技术框架:需要了解业务;分包分module;详情页需要用到H5吗? 需要统计 需要bug收集,MVC还是MVP 哪些由原生做,哪些由H5做?分几个Tab 每个tab规划放什么内容;产品的定位,及要突出表现什么  APP的主体颜色?需要使用哪些框架 自己开发和使用第三方框架的衡量?

App 后台架构- https://blog.csdn.net/yangzhongxuan/article/details/77949315

> Android技术选型或整体框架图:如下

> android APP工程架构和框架
  分享些思想,抛砖引玉:1.GOF的设计模式;2.android APP工程架构:MVC MVP MVVP ;3.android APP框架(可自己来实现):基于注解 、基于ORM、基于代理、基于IOC AOP等
>  模块化开发
有赞 App 模块化实战经验总结- https://youzanmobile.github.io/2017/04/14/youzan-app-modularization/
Android 开发:由模块化到组件化(一)- http://blog.csdn.net/dd864140130/article/details/53645290
  将项目分为了四个层级:模型层、接口层、核心层、界面层。模型层定义了所有的模型;接口层封装了服务器提供的API;核心层处理所有业务逻辑;界面层就处理界面的展示。在Android Studio分为了相应的四个模块(Module):model、api、core、app。
  model为模型层,api为接口层,core为核心层,app为界面层。
  model、api、core这三个模块的类型为library,app模块的类型为application。
四个模块之间的依赖设置为:model没有任何依赖,接口层依赖了模型层,核心层依赖了模型层和接口层,界面层依赖了核心层和模型层。
  模块化就是将一个程序按照其功能做拆分,分成相互独立的模块,以便于每个模块只包含与其功能相关的内容。模块我们相对熟悉,比如登录功能可以是一个模块,搜索功能可以是一个模块,汽车的发送机也可是一个模块.
 模块化开发,模块化开发中最大的问题就是组件间通讯-->路由的概念,把项目模块化了, 那两个组件间进行通讯或者跳转, 我们一般构建Intent的方式就不再使用了。
  模块之间总是存在这一定的接口,从调用方式上看,可以分为三类:同步调用、回调和异步调用。同步调用是一种阻塞式调用,也是我们在写程序中经常使用的;回调是一种双向的调用模式,也就是说,被调用的接口被调用时也会调用对方的接口,这句话可能有点绕,等文章后面举例说明;异步调用是一种类似消息或事件的机制,解决了同步阻塞的问题。

-- App模块化分为5层模型:
(1)应用层是生成app和初始化操作的加载
(2)模块层,每个模块相当于一个业务,通过module来分隔开每个业务的逻辑。
(3)基础层,基础组件的整合,提供基础组件能力给业务层使用。
(4)组件层,通过图片加载,网络http,socket等基础功能划分为一层。
(5)基础库层,更加基础的库类依赖,此层非必须,例如(Rxjava,EventBus等一些代码结构优化的库),还有自己编写的封装类。

-- 插件化,研发阶段考虑的问题
(1)资源冗余解决,包括对于base module的依赖和库依赖
(2)混淆相关和资源冲突
(3)插件加载方式
(4)通信依赖,数据交互,事件触发

> 路由机制
模块化开发中最大的问题就是组件间通讯。
开源最佳实践:Android平台页面路由框架ARouter- https://yq.aliyun.com/articles/71687?t=t1#
Android平台页面路由框架ARouter的技术方案- https://github.com/alibaba/ARouter
 -- 路由的方案:
1.完全自己实现路由, 完全封装跳转参数
2.利用隐式意图跳转(Android原生支持,仅支持Activity, Service, BroadcastReceiver)
go web开发之url路由设计- http://blog.csdn.net/qibin0506/article/details/52614290
Android路由实现- http://blog.csdn.net/qibin0506/article/details/53373412

> 重构围绕一个老生常谈的概念「解耦」展开,设定几个目标:
1.清晰划分各模块的角色
2.明确架构层级及各个模块所在的层级
3.提高整个架构横向扩展的能力
4.提高编译效率,由于我们项目大量使用 Kotlin 开发和 AOP 技术,在编译上面个比较耗时,期望在架构调整后,在整个项目的编译效率上又一次大的提升
5.各模块独立开发,面向接口和协议编程
6.提高可维护性

充分考虑可拓展性和可维护性,把模块化、性能优化、用户体验等
关于App重构的几个方面- http://www.jianshu.com/p/1125f4be4cc3
Android重构记录及其模块化- http://blog.csdn.net/jonstank2013/article/details/56833462
Android项目重构之路:架构篇 - http://keeganlee.me/post/android/20150605
Android项目重构之路:界面篇 - http://keeganlee.me/post/android/20150619
Android项目重构之路:实现篇- http://keeganlee.me/post/android/20150629

> App架构设计
App架构设计经验谈:接口的设计     - http://keeganlee.me/post/architecture/20160107
App架构设计经验谈:技术选型         - http://keeganlee.me/post/architecture/20160114
App架构设计经验谈:数据层的设计 - http://keeganlee.me/post/architecture/20160120
App架构设计经验谈:业务层的设计 - http://keeganlee.me/post/architecture/20160214
App架构设计经验谈:展示层的设计 - http://keeganlee.me/post/architecture/20160222

Android中级第十二讲浅谈架构设计- http://blog.csdn.net/reboot123/article/details/51321248
内容型App的客户端架构之道- http://www.infoq.com/cn/presentations/content-type-app-client-architecture
Android开发框架大全- http://www.ctolib.com/topics-113373.html?ref=myread
平安好医生技术栈的分析(APP架构)- http://blog.csdn.net/caroline_wendy/article/details/51426837
基于RxJava+Retrofit精心打造的Android基础框架(源码)-http://download.csdn.net/detail/xiaoyaoyou1212/9755991
好客户端是怎样炼成的- http://blog.csdn.net/a345017062/article/details/45538187

程序的功能才是我做的所有工作中用户真正想要和关心的。架构能够满足应用的需要即可。
安居客 Android 项目架构演进- https://mp.weixin.qq.com/s/aizuJ2qZhP-lYANirXI1og

> App架构
详解Android主流框架不可或缺的基石- https://blog.csdn.net/lfdfhl/article/details/52673536
谈谈我理解的Android应用架构- https://www.jianshu.com/p/734d3693da02
Android架构:代码层面,主要是MVC和MVP的理解。项目层面,主要是怎么搭建整个项目,怎么划分模块。
-- 项目常见的架构方式应用层+业务层+基础库
  1、最底层是基础库,放置与业务无关的模块:比如基础网络请求,图片压缩等等,可以按需分为逻辑模块,通用UI模块和第三方库。(建议采用独立的svn分支)
  2、中间层是通用业务层,放置公司多个android项目的通用业务模块(和业务相关的),比如登录流程,文件上传/下载等。
  3、最上层就是应用层了,比如公司有三个android项目:LbBoss,BV和BVHD。我们还可以针对相似的项目再抽取通用层(比如这里的BV和BV PAD版,通用层为BVCommon)。

避免重复制造轮子,更要造特别的轮子。

-- APP的整体架构分层
从较高的层次将,一个APP的整体架构可以分为两层,即应用层和基础框架层。
  1.应用层专注于行业领域的实现,例如金融、支付、地图导航、社交等,它直接面向用户,是用户对产品的第一层感知。
  2.基础框架层专注于技术领域的实现,提供APP公有的特性,避免重复制造轮子,它是用户对产品的第二层感知,例如性能、稳定性等。
  基础框架层:这里所谓的基础框架,指多数App都必需的基础功能,是具体业务逻辑实现的基础。主要有网络请求功能、图片加载与缓存功能、SQLite数据库管理功能、Log管理功能等,当然根据对业务逻辑支持的不同,基础框架层的功能支持也不一定相同,上述几个应该是大部分App都要支持的,当然Crash监控与常用工具类也可归为该层次。 
  具体到每个基础框架的实现则没有任何限制,如网络功能可以使用Volley、OkHttp或者自己封装实现网络请求逻辑;对于图片管理功能则可以使用Glide、Fresco、Picasso,亦或自己实现……总之每个基础框架都要遵循一定的实现原则,保持功能模块的独立性,与具体业务解耦并对外提供良好的交互接口。
  3.业务逻辑层:如果把App架构比作高层建筑,那么上述两层就是地基。地基打好之后,就可以在上面任意发挥了,至于如何发挥,那就必须结合实际的业务需求,不同的应用往往有不同的业务功能模块。 
  4.另一方面,业务功能模块也并非完全是并列的级别,有一些业务逻辑也是可以抽象出来的,作为通用的功能模块,比如登录、分享、扫描、统计等,其他的业务模块可能会调用到这些功能。

-- 关于移动端架构的思考与总结- https://blog.csdn.net/uxiAD7442KMy1X86DtM3/article/details/79683582
  1. 移动端目前的架构,差异化在于通信机制。通过以上说明,通信机制主要分为3种:
      a.对象持有;b.接口持有;c.路由
  2. 通信方式中,对象持有是比较原始的,解耦率最低,建议放弃; 接口持有是个不错的选择,极大程度上实现解耦的诉求,但是解耦不彻底,相互持有交互方的接口。 路由机制也是个不错的选择,可以实现完全解耦,就像组件化一样。但是路由机制的设计是个技术难点,怎么设计效率最高?更健壮?代码可查阅性更好?这些都是值得思考的问题。
  3. 对于路由机制的优化,阿里的ARouter(用于组件通信)中,采用了分组的模式,我们可以采用;其次可以根据AnnotationProcessor 的处理,为每一个注册接收器的组件实现一个SupportActions来确保消息只发送给注册了指定类型的模块,也是个不错的选择。

没有更多推荐了,返回首页

私密
私密原因:
请选择设置私密原因
  • 广告
  • 抄袭
  • 版权
  • 政治
  • 色情
  • 无意义
  • 其他
其他原因:
120
出错啦
系统繁忙,请稍后再试

关闭