1、Android组件化概念 组件化大致可分为功能组件化和业务组件化。功能组件化，常见的是将一些底层的公共功能模块进行独立化，如网络请求模块、登录注册模块等。业务组件化，即为业务模块独立化，彼此无关联，由一个项目工程拆分成若干个业务模块，由App主工程提供统一的入口，每个业务独立的模块共享项目的依赖库。
模块化和组件化的概念已经看的很多，也都不是新的概念了，很多项目也已经使用了模块化和组件化，本文对现有的模块化与组件化分析得比较深入的文章进行整理。
到了17年的今天，组件化实在不会是一个新名词。各种关于组件化、模块化的讨论层出不穷，具体实践方案也历经了好几代的演进，到了现在甚至已经有完善的组件化框架类如Small、Atlas等。那么回归初心：什么是组件化？
我之前在做业务需求的时候，很多的个性化需求并不能快速响应，实现后有时也很难保证系统的可阅读性。不过好消息是，我今年在做京东内容领域的组件化改造和能力输出，之前的问题或许会得到根本性的解决。那么，接下来我将分享一些个人对于组件化的认知，希望能帮助到你。
在之前我的一篇文章中，提到过关于组件化的一些概念，可以参考《GMTC移动开发者大会纪实（二）组件化只是一句口号吗》。接下来的几篇文章，主要会写下我们团队实施组件化的一些经历。
组件化作为Android客户端技术的一个重要分支，近年来一直是业界积极探索和实践的方向。美团内部各个Android开发团队也在尝试和实践不同的组件化方案，并且在组件化通信框架上也有很多高质量的产出。最近，我们团队对美团零售收银和美团轻收银两款Android App进行了组件化改造。本文主要介绍我们的组件化方案，希望对从事Android组件化开发的同学能有所启发。
在软件开发过程中，大到业务模块的划分，小到技术组件的开发，都属于组件化的思考范畴内。很多时候我们到网上搜索「组件化」关键词，都只会看到关于前端组件化的资料，而对于后台开发组件化的资料却很少，那这是不是代表后台组件化没有意义呢？ 后台组件化肯定是有非常大的价值的，对于业务开发人员也有非常大的效率提升。所以本文我将通过自己做组件化的一些经验，谈谈我对后端组件化的一些看法，以及如何进行组件化开发，希望对在一线开发的工程师们有所帮助。 希望通过组件化的方式，能帮助一线工程师们减少对于重复业务代码的编写，提高开发效率
首先我觉得”组件”在这里不太合适，因为按我理解组件是指比较小的功能块，这些组件不需要多少组件间通信，没什么依赖，也就不需要做什么其他处理，面向对象就能搞定。而这里提到的是较大粒度的业务功能，我们习惯称为”模块”，指较大粒度的业务模块。
Tech 导读 组件化渗透在开发的方方面面，本文主要从“为什么”、“是什么”、“怎样做”三方面来系统讲述前端组件化的相关知识。通过阅读本文，读者可以对组件化形成一个更加深入的认识和理解。在实现前端组件化的过程，大家可以更加关注组件化的目的，需求及其特点，了解前提才能结合项目来思考如何更好的拆分和实现组件化。 01 思考：为什么要实施前端组件化？ 在项目开发中，页面和功能大都拆分为多文件来实现，多文件管理逐渐暴露出以下问题： 1.相似的业务代码无法复用：X同事实现了一遍A页面，Y同事要实现一个和A页面类似
百度 App(大型 App) 复杂度来源 1. 业务规模大：百度 App 技术方向及子方向 70+，单端代码量 180w+； 目标：隔离各组件间影响避免故障蔓延，并控制整体 App 的复杂度； 2. 团队规模大：有代码权限的数百人 ; 目标：保障高效并行开发； 3. 公司内部接入业务多：30+, 非单纯基础库，与百度 App 关系复杂； 目标：处理接入业务与百度 App 架构及架构中各组件关系，保障快速高效接入与基础能力复用。 4. 迭代速度快：3 周一个版本，2 周开发 1 周测试； 目标：避免高速迭代情况下组件化程度劣化。 5. 技术形态多：H5、NA、Hybrid、Talos、Flutter 并存； 目标：保障基础能力复用，构建系统支撑。 另外启动速度、体积等准入流程的约束；以及目标的多样性也是大型 App 复杂度来源因素；由背景产生的目标是天生的技术需求，除此之外，百度 App 在不同阶段有不同的产品技术目标。
随着我们业务发展，参与业务开发的同学也逐渐增多。为了适应新要求，需要对旧的架构做一次升级。组件化是架构升级中的重要一步，将业务模块进行组件化，将各个业务的逻辑和依赖梳理清楚，才能有效降低业务迭代带来的复杂度，为后续更复杂的优化做铺垫。
原文地址: https://www.jianshu.com/p/f671dd76868f
随着业务系统的复杂性越来越高，系统之间的调用也越来越多，在微服务拆分和迭代过程中，是不断的拆分出新的独立的服务还是封装独立的组件以jar包依赖的方式提供服务是我们经常需要面对的问题，本文将详细探讨这两种不同的方式区别、各自的优劣势及适用的场景，希望能够对大家有所启发。
上次，我们讲了MVC、MVP、MVVM，其实从狭义上来讲，Android的架构概念就在这儿，无论怎么变，都是加加减减一些边边角角的东西，不足在意。
随着移动互联网的不断发展，很多程序代码量和业务越来越多，现有架构已经不适合公司业务的发展速度了，很多都面临着重构的问题。
一、前端为什么要做组件化 在大型软件系统中，web应用的前后端已经实现了分离，而随着REST软件架构的发展，后端服务逐步倾向于微服务，简单来说就是将一个大型后端服务，拆分成多个小服务，它们分别部署，降低了开发的复杂性，而且提高了系统的可伸缩性。而前端方面，随着技术的发展，开发的复杂度也越来越高，传统开发模式总是存在着开发效率低，维护成本高等的弊端。 传统开发方式效率低以及维护成本高的主要原因在于很多时候是将一个系统做成了整块应用，而且往往随着业务的增长或者变更，系统的复杂度会呈现指数级的增长，经常出现的情
前言 一位计算机前辈曾说过： Controlling complexity is the essence of computer programming. 随着前端开发复杂度的日益提升，组件化开发应运而生，并随着 FIS、React 等优秀框架的出现遍地开花。这一过程同样发生在美团，面临业务规模的快速发展和工程师团队的不断扩张，我们历经引入组件化解决资源整合问题、逐步增强组件功能促进开发效率、重新打造新一代组件化方案适应全栈开发和共享共建等阶段，努力“controlling complexity”。本文将介
随着公司业务的不断发展，团队不断壮大的同时，项目也随之臃肿起来，如何保障团队协作的高效，自然的想到了组件化这个话题。下面总结下本人的梳理和思考。
昨天的ApkBus Android开发者论坛上海站 本人分享了关于架构的东西，晚上有很多听众微信给我说“有没有具体的文章出来啊，PPT看的有点不过瘾”，本文以大会上分享的课题为蓝图，专门写个文章出来, 错过的朋友可以回顾一下！
前段时间由于工作需要，学习了关于组件化和插件化架构相关的知识。查阅了很多Android开发架构的资料，组件化自己写了个简单的Demo并且开始了原有项目的改造，插件化自己也尝试了滴滴的VirtualAPK框架。这篇记录一下架构方面的相关知识总结以及自己学习后对模块化、组件化和插件化这三化概念的理解。具体的搭建组件化方法可以看我写的这篇文章。Android组件化入门：一步步搭建组件化架构。
iOS 组件化介绍 随着应用需求逐步迭代，应用的代码体积将会越来越大，为了更好的管理应用工程，我们开始借助CocoaPods版本管理工具对原有应用工程进行拆分。但是仅仅完成代码拆分还不足以解决业务之间的代码耦合，为了更好的让拆分出去的业务工程能够独立运行，必须进行组件拆分并且实现组件服务化。 拆分组件 （1）基础功能组件 （2）基础UI组件 （3）产品业务组件 总结：组件化适用于业务稳定、逻辑复杂的app，能够解决项目模块间得耦合问题，有助于多人大团队的协同开发。方便组件的单独开发、单独测试。 为什么要组件
今天介绍下组件化开发方面的内容，在前面我讲解微服务的时候就已经谈到，实际上微服务本身就是传统的业务系统组件化开发的一个升级。懂得基础的组件化开发和技术架构设计是也是过渡到当前主流的微服务架构思想的基础。
知乎 Android 客户端最早使用的是最常见的单工程 MVC 架构，所有业务逻辑都放在了主工程 Module 里，网络层和一些公共代码分别被抽成了一个 Module。现在看来，当时的业务线、产品功能及研发团队都比不上现在的体量和丰富度，遇到的问题随时组内沟通就可以解决。所以在知乎稳步发展的前几年，并没有遇到什么大的问题。
参考资料: https://www.jianshu.com/p/60c1b9ddd8ab
近几年组件化大家吵的沸沸扬扬的，它其实也不是什么黄金圣衣，穿上立马让你的小宇宙提升几个档次，也不是海皇的三叉戟，入手就能呼风唤雨，它不过就是一种app的架构思路。其实真的很简单，如果你的项目从发布之初就是用组件化，那么在开发的过程当中势必会少很多麻烦，难点其实是对我们庞大古老的工程进行组件化的改造。
将一个程序按照其功能做拆分，分成相互独立的模块，以便于每个模块只包含与其功能相关的内容。模块我们相对熟悉,比如登录功能可以是一个模块,搜索功能可以是一个模块,汽车的发送机也可是一个模块。
虽然 iOS 组件化与路由的话题在业界谈了很久，但是貌似很多人都对其有所误解，甚至没搞明白“组件”、“模块”、“路由”、“解耦”的含义。
前端发展飞速，从最开始的静态页面到 JavaScript，再从 PC 端到移动端，随着大前端的复杂度不断提升，很多公司开始前后端分离，剥离出前、后端架构设计。那我们来看看，前端架构设计是什么？曾经非常简单的前端架构发展到现在有哪些问题，遇到前端代码体量巨大、跨团队协作效率、代码耦合、技术栈落后等问题又该怎么解决？
在该体育新闻详情页面，蓝色框选中的组件，是一个推荐其它相关新闻的跳转链接栏，用户点击其中的新闻标题可进入该新闻详情页，此时我们可以发现，它是不是可以单独进行一个组件的封装，因为它有着自己的业务逻辑在里面【HTML、CSS、以及发起网络请求获取新闻标题的和跳转的JavaScript逻辑】。但是呢，该组件不是一个具有复用性的组件，因此将此类组件分类为普通的业务组件，将其单独抽离成为一个模块，单独进行开发，以完成其相关的业务。
GitHub 地址 : https://github.com/han1202012/Componentization
国内Android动态化方案已经蓬勃发展数年之久，在React Natvie、Flutter这些跨平台方案未出现之前，类似Atlas、Replugin、DLA等Android动态化方案在业界独领风骚。在国内动态化方案也分为两个流派：组件化与插件化。比如Atlas自称为组件化方案，另外诸如Replugin、DroidPlugin等称为插件化方案。本文不具体说明组件化与插件化区别相关介绍文章已多入牛毛，这里就不再赘述。
组件化项目，通过gradle脚本，实现module在编译期隔离，运行期按需加载，实现组件间解耦，高效单独调试。
HTML页面 import React, {Component} from 'react'; class Communication extends Component { constructor(props) { super(props); this.getRequest = this.getRequest.bind(this); this.postRequest = this.postRequest.bind(this); }
ps:如果您看过atlas的官方介绍，本片文章可以略过，期待我们追溯源码的过程中有你的参与
关于iOS组件化网上资料太多，这里只是从个人观点说明一下怎么使用组件化和使用组件化的优点和缺点 首先下载CTMediatorDemo
在上一篇文章《组件化实践详解（一）》中我们介绍了组件化实践的目标和实践步骤，本文继续说说关于组件化实践遇到的问题及思考。
前端架构这一词，相信很多人的定义都不太一样；按照拆词的解释来看，我理解为“前端”+“架构”。前端是指，Web 端的前台页面，包括网页的内容、样式、脚本等，这三者通常封装在组件中，可能是模板引擎的文件模块，也可能是 MVVM 框架里的组件。“架构”就更好理解了，架构一词来自建筑行业，可以理解是房屋的整体结构、框架。结合前端和架构的概念，“前端架构”可以理解为，Web 页面组件的抽象和组织方式。
最近事情比较多，2个月没写文章了。看笔者圣诞节还在写技术文章，就知道程序猿的生活有多惨淡。
又一次的版本更新上架，心情容不得片刻舒缓，新的迭代任务又明白的摆在桌面上。今年上半年自己琢磨完ReactiveCocoa之后，对手上了项目做了MVVM架构的尝试，当时自我感觉效果还不错，代码之间的关系确实变得清楚了，并且有更加多的机会去进行单元测试，但是在新的一年，回头再去思考自己当时的架构，依旧会发现很多的问题，例如虽然逻辑清晰，但是并没有完全解耦，一些界面任务的处理，依旧通过RAC返回到View层去处理。只是Controller更干净了，心里自己觉得舒服罢了。
组件化由于它的解耦，独立，开发效率已经成为了被广泛使用的项目架构了，特别是大项目重构的首选，今天就一起来看看组件化开发。
大家好，又见面了，我是你们的朋友全栈君。 jquery和框架的区别 框架：数据和视图分离，以数据驱动视图，只关心数据变化，dom操作被封装。数据驱动 jquery： 依靠dom操作去组合业务
我们经常会听到组件化、插件化、模块化这三个概念，可是我们真的对这三个概念了解吗？明白它们三者之前的关系和区别吗？本文就我个人的理解做一下简单的总结，如有错误之处，请留言讨论，谢谢。
React如何实现组件化：在React中实现组件化的时候，根本没有 像 .vue 这样的模板文件，而是，直接使用JS代码的形式，去创建任何你想要的组件；
内容来源：2017 年 12 月 3 日，科大讯飞应用研发经理程坤在“IAS2017互联网架构峰会”进行《讯飞输入法Android架构演进与实践》演讲分享。IT 大咖说（微信id：itdakashuo）作为独家视频合作方，经主办方和讲者审阅授权发布。 阅读字数：3031 | 8分钟阅读 摘要 本次演讲将分享讯飞输入法Android版从最初开发到逐步发展成熟的过程中所面临的各种挑战以及经验，还有架构的逐步演进过程。最后提到了团队在组件化架构中的一些实践。 嘉宾演讲视频及PPT回顾：http://suo.im/
很多人以为存在时间很长的就是遗留系统，但这其实是个误区。时间长短并不能作为衡量遗留系统的标准。判断遗留系统的几个维度是：代码、架构、测试、DevOps以及技术和工具。代码质量差、架构混乱、没有测试、纯手工的 DevOps（或运维）、老旧的技术和工具，才是遗留系统的真正特点。
组件化思想并不是前端独有的，但却是前端技术的延伸 任何软件开发过程，或多或少都有那么一些组件化的需求。
企业微信本地部署版（下文简称为本地版）是从2017年起，脱胎于企业微信的一款产品。本地版的后台服务能独立部署在政府或者大型企业的本地服务器上。在一个已经迭代了7年的大型Android端工程中，企业微信本地版不可避免地会暴露出一些遗留系统的特点。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
