JTalk 第四期 Android 进阶之旅活动结束啦, 这次讲师带来了哪些干货? 有幸参与本次活动, 将本次 JTalk 讲师分享内容进行了一个小总结, 希望能帮到未能到场的同学们~ 受限本人水准, 总结可能稍有偏差或者不到位不清晰之处, 还望见谅并请指出~
R lab 移动端团队技术架构体系及演进 -> 子成 didi
技术演进的历史
activityfragment,viewcontrol=> 期望抹平 androidios 平台差异
动态下发 ui 组合配置 (不同国家不同地区等区分方式)
期望能下发业务逻辑
Nova 轮子
内部开发框架
代码高度复用
快速上线
Skeieton
反 fragment 联盟 (即是 view 又是 control)
概念: router-> 数据传递 / 序列化
目前大量处在 mvp-> 后期迁移为 mvvm
简化 activityfragment 生命周期
分层:
appication 层提供 router 等
service 基于数据展开
data access 网络, 存储
Dsl&compiler
使用注解的方式处理之前通过负载方法搞定的代码 - Java 的版本略显拙略 (Now)
在 Kotlin 的 Skeleton 版本中提供更合理的实现 (Future)
Router
界面之间解藕 (Now)
参考前段 Router 实践, 彻底实现 View 的无状态化 (Future)
- Thinking
- Ability Nova Foundation
- Principle Nova Skeieton
Utility supportdesignwidget 跨多项目使用
Engineering 多个项目统一构建管理
Business
goto 开发规划
other
思维纠偏
限制自己的是: 思考深度, 对业务的理解力
走出舒适区
逃离自己的舒适区, 拓展更多
思考本质
不能停留在 API 阶段, 深入思考理解内部底层设计及实现
理解业务, 助力业务
迁移
快速进入某个领域, 在于自己的知识迁移能力
机遇
发展和机遇有一定相关
QA
Q: 对测试的友好支持
Router 不同场景的入口, 方便测试
Q: 知识迁移
方法论概念的迁移
Q: 业务角度看 MVPMVVM 选型
数据量小: MVP 足够且方便用
大数据量: 电商等, 数据处理多, 很痛苦 MVVM 会较好
强数据和强交互的划分
Android 组件化的正确姿势 -> 张明庆 得到
高高山顶立, 深深海底行
组件化面临三座大山
业务开发时间太紧
业务过于庞大
隐藏的阻力
组件化: 需要站在更高的山去看他们
实施设计方案的态度
深深海底行 -> 沉入代码
为什么要组件化
用包来区分模块
用 module 区分模块
------ 以上胖体系 (巨大开发包袱 / 拖慢开发节奏 / 下班晚)------
组件化
插件化
组件化 / 插件化阵营
组件化使用的人多, 开源内容少
组件化设计时容易和业务强耦合
为什么不是插件化
除了动态添加, 组件化能实现插件化所有功能
组件化学习曲线更加平滑
插件话不可避免进行系统 Hook,9.0 以上前途未卜
高高山顶立
代码搬家, 隔离结偶
组件单独调试
避免资源冲突
组件生命周期
运行时动态打开组件 (加载)
运行时动态关闭组件 ->ABTest(卸载)
组件降维 H5(降维)
更庞大需要更多
交互互通有无
每个组件怎么提供服务
怎样做到更方便的服务发现
服务接口如何自动化与其他代码剥离
组件和组件之间的 Router
UI 跳转
是否支持 scheme 跳转
路由和传递仓鼠是否支持自动注解生成
是否可以生成清晰的路由 -> 路由表的生成自动
集成调试
任何组件能否充当 host
组件由 host 切换到 library 是否可以无感知的完成
代码和资源隔离
如何做到代码隔离
语法 | 旧语法 | 功能 | 支持类型 | 代码隔离效果 |
---|---|---|---|---|
implementation | compile | 编译期间对其他组件不可见,运行期间对其他组件可见 | jar aar | “隔代” 编译期间隔离 |
api | compile | 编译和运行期间都可见 | jar aar | 没有隔离 |
compileOnly | provided | 只参与编译 | jar | 没有隔离 |
runtimeOnly | apk | 编译期间不可见,运行期间可见 | jar aar | 编译期间隔离 |
compile 没法做到资源隔离
runtimeOnly 编译不可见, 运行可见其实也不行
可否做到编译期组件不可见, 但同时全部组件参与打包?
深深海底行
组件化过程一直都很痛苦
划分项目
host
组件
服务发现
业务依赖库
依赖库
怎么开始执行: 四部曲
依赖库先行, 业务依赖库初步抽离
寻找业务边界, 抽离边界清晰的业务模块
将造成组件依赖主项目的模块继续抽离
将主模块抽离成一个 host 壳子
万事开头难
走出舒适区, 做好充足的准备
组件化会长期停留在中间状态
你的 app 会长期很胖, 指望一次成功时不可的
基于组件完全平行, 集成交给 app 即成调试的方案时不可行的
这不是停滞的理由, 要抓紧一切时机
无止境的优化
四个维度的优化: 工程 组件 页面 类
组件内部: pin 分包结构, 页面级别隔离甚至内聚
页面内部: MVP MVVM 拆分
类: 单一职责拆分, 代码规范
看好护城河, 防止地道战
避免下沉: Event, 实现类, 公共资源
地道战: 广播 spdb
不知道该不该下沉: 不该, 明确下沉: 该
康威法则 组织架构和架构之间的映射关系
尽量贴近组织结构和产品业务
尽力去反响改变组织结构和产品业务
做不到, 回第一条
不要逆行
团队共识 就是: 我知道, 你知道, 我知道你知道, 你知道我知道
得到大多数人的支持
持续的输出正向结果
给更多人赋能, 让更多人入坑
建立配套的模块负责人制度等
得到组件化成果
实时多媒体 SDK 性能优化 Powerinfo 许建林
性能优化流程
测量, 分析, 优化 => 循环
RTC SDK 业务流程
采集 -> 预处理 -> 预览 -> 编码 -> 发送 -> 接收 -> 解码 -> 后处理 -> 渲染
优化
紧扣场景做优化
脱离场景谈优化, 都是耍流氓
推流首屏时间
屏到屏的延迟
cpu 占用
内存抖动优化
测量方法
首屏时间 视频慢动作录制会玩 视屏延迟
优化思路
多操作并行
预操作提前
智能 pos 架构演进 美团 闫飞
pos 机 -> 收银功能整合
客户端架构理解:
业务观: 时刻理解业务规则及特点
全局观: 关注上下游服务, 以全局的视角审视问题
视野观: 技术宽度不限于客户端 (某一块)
发展观: 架构是面临的问题一步步迭代出来的, 很少一步到位
运营观: 关注产品各项指标
演进
0.5 时代
资源缺乏 & 业务快速推进 -> 复杂事情简单化, 取得 0 的突破
架构本身就不是一步到位的事情, 如何在短时间内集中稀缺资源推动项目上线? 这势必要分清主次有所取舍, 将复杂事情简单化只有取得零的突破, 才有谈演进的资本
1.0 时代
面临着: 稳定性厂商对接复杂度多版本管理
索取主动权, 思考重新设计
建立硬件抽象层, 自研银行卡收银
银行卡收银分层模块化
异常处理: 充分暴露异常, 而不是试图消灭异常
下层收集异常, 上层处理异常 -> 异常处理模块统一对异常进行处理 埋点: 技术侧埋点与产品侧埋点
2.0 时代 拥抱开放
建立收银服务层
美团智能支付开放生态
总结
架构没有定义没有标准, 唯有深刻理解业务, 围绕业务不断思考不断迭代
技术离不开业务, 努力写简单代码
圆桌
Android 前景
1. 业务优先, 关注所做工作的上下游, 眼界不局限于客户端
2. 不要把自身局限于当前身份
1. 追本溯源, 当程序员的出发点享受红利的同时, 承担其风险 (技术变化快等)
2. 走出舒适区
3. 新技术, 去尝试大前端的趋势, 具体技术不能确定
1. 核心: 学习能力
面试
美团: 校招: 基础 (数据结构算法等), 解决问题能力 社招: 解决问题, 思考问题的能力
不要试图把握面试主动性: 睡个好觉直接去就行了
平常: 注重提升个人核心竞争力
面试是一个互动的过程, 不要拘束, 不要埋头想问题, 多互动交流
来源: https://juejin.im/post/5aba5ad5f265da23906c0c30