App 组件化/模块化开发架构思路 随着业务的发展 App 开发技术也越来越成熟,对开发者来说 App 代码量也迅速地增长到一个数量级.对于如何架构 App 已经每个开发者面临的实际问题.好的架构可以提高开发者的效率,降低维护成本. 由于业务增长引起项目中代码量激增,以及历史遗留问题和结构混乱,作为一个有代码洁癖的程序员,很早就开始思考如何组织 App 架构的问题了.目前遇到的主要有以下几点问题: 代码量激增引起结构混乱 各个模块相互引用且耦合度高 无法独立开发或者调试组件代码 无法应对组件插拔

面对越来越复杂的 App 需求,Google 官方发布了Android 框架组件库(Android Architecture Components ).为开发者更好的开发 App 提供了非常好的样本.这个框架里的组件是配合 Android 组件生命周期的,所以它能够很好的规避组件生命周期管理的问题.今天我们就来看看这个库的使用. 通用的框架准则 官方建议在架构 App 的时候遵循以下两个准则: 关注分离 其中早期开发 App 最常见的做法是在 Activity 或者 Fragment 中写了大量

一.背景 随着项目逐渐扩展,业务功能越来越多,代码量越来越多,开发人员数量也越来越多.此过程中,你是否有过以下烦恼? 项目模块多且复杂,编译一次要5分钟甚至10分钟?太慢不能忍? 改了一行代码 或只调了一点UI,就要run整个项目,再忍受一次10分钟? 合代码经常发生冲突?很烦? 被人偷偷改了自己模块的代码?很不爽? 做一个需求,发现还要去改动很多别人模块的代码? 别的模块已实现的类似功能,自己要用只能去复制一份代码再改改? "这个不是我负责的,我不管",代码责任范围不明确? 只做了一

App 组件化/模块化之路——如何封装网络请求框架 在 App 开发中网络请求是每个开发者必备的开发库,也出现了许多优秀开源的网络请求库.例如 okhttp retrofit android-async-http 这些网络请求库很大程度上提高程序猿的编码效率.但是随着业务的发展,App 变得越来越大,我们将这些网络请求库加入到项目中直接使用,对我们业务类的入侵是非常强的.如果要进行业务分离时,这些网络请求代码将是一个阻止我们进一步工作的绊脚石.对开发者来说是非常痛苦的. 因此我们构建的网络请求框

在不久之前分享一篇<App 组件化/模块化之路——如何封装网络请求框架>文章介绍了我在项目中封装网络请求框架的思路.开发一个 App 会涉及到很多网络请求 API ,例如登录注册接口.用户信息接口.业务列表请求接口等等.而本文介绍的是如何模块化设计这些接口,使得项目中更好地复用代码.当然这仅仅是一家之言,欢迎留言拍砖. 问题 网络请求中最常见的莫过于用户授权登录模块了.现在以此模块为例,大概有以下接口 登录 sign_in 注册 sign_up 找回密码 find_password 获取短信验

什么是 Repository 模式 Repository 这个词直译过来仓库.仓储的意思.这个意思其实也能反应出 Repository 模式作用.App 开发中少不了对数据的操作,数据的来源可能有很多种:网络.数据库.文件以及内存中的缓存.而 Repository 就相当于一个仓库管理员,管理这些数据的存储.当业务层想要获取或者存储数据时,只需要通过 Repository 的管理员进行操作.这样的好处就是:屏蔽数据来源的操作接口.对于业务层来说不必关心数据存在哪里,以及如何存储的.而且也符合我们

问题 在已经开发过几个项目的童鞋,如果这时需要重新开发一个新项目,是否需要自己重新搭建框架呢,还是从老项目中拷贝粘贴? 我们是否可以封装一个底层的lib库,这个底层的公共基础库 包括了一些第三方库(如: okhttp, retrofit2, glide 等)的初始化及简单的封装和一些公共的base类.这样我们重新开发一个新项目只要依赖这个库就马上可以进行业务逻辑的开发了. 什么是组件化 组件化简单概括就是把一个功能完整的 App 或模块拆分成多个子模块, 每个子模块可以独立编译和运行, 也可以任

Android组件化项目地址:Android组件化项目AndroidModulePattern Android组件化之终极方案地址:http://blog.csdn.net/guiying712/article/details/78057120 1为什么要项目组件化 2如何组件化 3组件化实施流程 1组件模式和集成模式的转换 2组件之间AndroidManifest合并问题 3全局Context的获取及组件数据初始化 4library依赖问题 5组件之间调用和通信 6组件之间资源名冲突 4组件化

转载: iOS应用架构谈 组件化方案 简述 前几天的一个晚上在infoQ的微信群里,来自蘑菇街的Limboy做了一个分享,讲了蘑菇街的组件化之路.我不认为这条组件化之路蘑菇街走对了.分享后我私聊了Limboy,Limboy似乎也明白了问题所在,我答应他我会把我的方案写成文章,于是这篇文章就出来了. 另外,按道理说组件化方案也属于iOS应用架构谈的一部分,但是当初构思架构谈时,我没打算写组件化方案,因为我忘了还有这回事儿...后来写到view的时候才想起来,所以在view的那篇文章最后补了一点内容

组件:指的是单一的功能组件,如地图组件(MapSDK).扫码组件(QRCode).支付组件(AnjukePay).路由组件(Router)等等: 模块:指的是独立的业务模块,如新房模块(NewHouseModule).二手房模块(SecondHouseModule).即时通讯模块(InstantMessagingModule)等等: 模块相对于组件来说粒度更大. 模块化带来的好处: 结构清晰,各个模块的代码实现分离,不会搅在一起. 模块间解耦.重用: 协同开发的时候更灵活,不用再等同组其他同事的

前言 什么是组件化? 最初的目的是代码重用,功能相对单一或者独立.在整个系统的代码层次上位于最底层,被其他代码所依赖,所以说组件化是纵向分层. 为什么要使用组件化? 当我们的项目越做越大的时候,有时间就很难去维护,有时候让我们去改点东西,根本实现不了,与其让我们修修改改,还不如自己重新去写代码. 其实无论是大项目也好,或者是中小型项目也好,如果去使用组件化进行开发,那会使你很难割舍,因为它能在你开发中带来很多的便利,包括一些功能解耦和和一些功能的复用. 组件化的好处 组件,既可以作为librar

附:Android组件化和插件化开发 App组件化与业务拆分那些事 Android项目架构之业务组件化 Android组件化核心之路由实现 Android组件化开发实践

Android 组件化/模块化之路——在展示层搭建MVP结构 什么是MVP Model–View–Presenter (MVP) 源于 Model–View–Controller (MVC) 的结构设计模式,它是用于展示层(Presentation)的结构. MVP 中的 Presenter 是 “中间人”角色,它的功能是在 Model–View–Presenter 三者中起到连接和协作的作用.程序中的大部分的逻辑都应该在 Presenter 中实现. Model 定义了数据的访问接口.例如之前

在组件化之前,蘑菇街 App 的代码都是在一个工程里开发的,在人比较少,业务发展不是很快的时候,这样是比较合适的,能一定程度地保证开发效率. 慢慢地代码量多了起来,开发人员也多了起来,业务发展也快了起来,这时单一工程开发模式就会显露出一些弊端 耦合比较严重(因为没有明确的约束,「组件」间引用的现象会比较多) 容易出现冲突(尤其是使用 Xib,还有就是 Xcode Project,虽说有 脚本 可以改善) 业务方的开发效率不够高(只关心自己的组件,却要编译整个项目,与其他不相干的代码糅合在一起)

时隔第一次被UI思路激励,到现在1.0的粗糙版本发布,掐指一算整整半年了.半年之间,有些细节不断推翻重做,再推翻再重做.时隔今日,终于能先出来个东西了,这个版本很粗糙,主体功能大概能实现了,但是还是有很多很多的问题.不过有问题没事,可以进行修改完善,这是相对轻松的问题,最艰难的从无到有的创造才是最艰难的.好了,不废话了,我们直接进入正题 --- UI.js功能介绍. 首先介绍几个概念 分布式:原来的概念只有分布式计算,它研究如何把一个需要非常巨大的计算能力才能解决的问题分成许多小的部分,然后把这

Android 插件化 ——指将一个程序划分为不同的部分,比如一般 App的皮肤样式就可以看成一个插件 Android 组件化 ——这个概念实际跟上面相差不那么明显,组件和插件较大的区别就是:组件是指通用及复用性较高的构件,比如图片缓存就可以看成一个组件被多个 App共用 插件的方式只有三种:1,apk安装,2,apk不安装,3,dex包 滴滴插件化项目VirtualAPK开源!https://mp.weixin.qq.com/s?__biz=MzUxMzcxMzE5Ng==&mid=22474

Android 插件化 ——指将一个程序划分为不同的部分,比如一般 App的皮肤样式就可以看成一个插件 Android 组件化 ——这个概念实际跟上面相差不那么明显,组件和插件较大的区别就是:组件是指通用及复用性较高的构件,比如图片缓存就可以看成一个组件被多个 App共用 插件的方式只有三种:1,apk安装,2,apk不安装,3,dex包 滴滴插件化项目VirtualAPK开源!https://mp.weixin.qq.com/s?__biz=MzUxMzcxMzE5Ng==&mid=22474

表单配置项写法,表单写成JSON数组套对象,一行是一个数组单位,一列是一个对象单位,然后再写一个公共组件读取这个配置,循环加载slot,外层载入slot的自定义部分,比如input select等,这种写法就是把组件嵌套改为配置方式

首先我们要使用pod支持组件化开发 解决CocoaPods慢的方案(gem和pod repo换源) gem换源 $ gem sources --remove https://rubygems.org/ # 移除默认源 $ gem sources -a https://gems.ruby-china.org/ # 添加Ruby China镜像 $ gem sources -l  确保只有gems.ruby-china.org源 pod repo换源 $ pod repo 默认是GitHub源 ma

前言: 前面分析了APP的现状以及业务组件化的一些探讨(Android业务组件化之现状分析与探讨),以及通信的桥梁Scheme的使用(Android业务组件化之URL Scheme使用),今天重点来聊下子模块SubModule的拆分以及它们之间的路由Router实现.本篇涉及的相关知识比较多,阅读本篇之间需要大致了解一下Java的注解(Java学习之注解Annotation实现原理).Java的动态代理机制(Java设计模式之代理模式(Proxy))等.业务组件化是一个循序渐进的过程,一开始很难