结合小米直播读微信架构有感
layout: post category : android开发 tagline: “工作记录” tags : [工作,android,记录] —
结合小米直播读微信架构有感
先把get到的点都记下来 ，在总结
目的
大的说更好维护代码，减少包大小 减少编译时间 加快并行开发效率，方便功能迭代
在编译期间约束住代码边界，防止架构劣化，不可调控
解耦 内聚
模块化了，未来才有可能应对各种变化。底盘稳了，才好掉头，大的方向不能错
代码审查应该是全员制的，不应该是leader的事，如何提高对代码的归属感，责任人制度
不可能大家都停下手头的活，开始重构的，节奏应该是重构 merge 分模块 重构 merge，先把账号 kernel弄好。
一. 先说直播中有哪些问题
- 解决项目没有模块化，没有拆分，中心化严重。
- 进程初始化流程复杂，启动过程还有些不明显的依赖，没人敢动这些代码。
- 我们需不需要模块有动态性，需不需要具备动态load的能力
- 模块之间数据复杂，模块间相互访问频繁
微信的逐渐出现的问题
- 模块边界被破坏
编译上隔离
二. 再说怎么一步步解决这些问题，解决这些问题有哪些技术难点
模块间通信的方式
Event
通信协议
B模块提供sdk方式通信
在common层依赖一些网络数据库账号等跟项目无关的库 在common上层之上有个livecommon
程序关键生命周期完整化
进程启动 账号完成 账号注销
主线程 可异步线程
目的提高app启动速度
plugin之间有依赖
授权基础模块
聊天基础模块
每个模块大体分为三大块 api implement library
写的时间多了，思考的时间少了。打造工具文化的团队
三. common里负责的module有哪些
milink imageloader log baseactivity fragment dialog view permisstion Database sharepre
还有哪些大的module lc_kernel auth module 账号授权，个人信息
chat module 聊天，无ui
android studio 工具 analyze dependencis
四. ARouter 的研究
支持多模块工程使用 支持添加多个拦截器，自定义拦截顺序 支持依赖注入，可单独作为依赖注入框架使用
blog comments powered by Disqus