JTalk《0325第四期-Android进阶之旅》总结

JTalk第四期《Android进阶之旅》活动结束啦，这次讲师带来了哪些干货？ 有幸参与本次活动，将本次JTalk讲师分享内容进行了一个小总结，希望能帮到未能到场的同学们～ 受限本人水准，总结可能稍有偏差或者不到位不清晰之处，还望见谅并请指出～

R lab移动端团队技术架构体系及演进->子成 didi

技术演进的历史

• activity、fragment，view、control=>期望抹平android、ios平台差异

• 动态下发ui组合配置（不同国家不同地区等区分方式）

• 期望能下发业务逻辑

Nova轮子

内部开发框架

• 代码高度复用

• 快速上线

Skeieton

反fragment联盟（即是view又是control）

概念：router->数据传递/序列化

目前大量处在mvp->后期迁移为mvvm

简化activity、fragment生命周期

分层：

1. appication层。提供router等
2. service。基于数据展开
3. data access。 网络，存储

Dsl&compiler

1. 使用注解的方式处理之前通过负载方法搞定的代码-Java的版本略显拙略（Now）
2. 在Kotlin的Skeleton版本中提供更合理的实现（Future）

Router

1. 界面之间解藕（Now）
2. 参考前段Router实践，彻底实现View的无状态化（Future）

Thinking

1. Ability。 Nova Foundation
2. Principle。 Nova Skeieton
3. Utility。 support、design、widget跨多项目使用
4. Engineering。 多个项目统一构建管理
5. Business。

goto开发规划

other

1. 思维纠偏

   限制自己的是：思考深度，对业务的理解力

2. 走出舒适区

   逃离自己的舒适区，拓展更多

3. 思考本质

   不能停留在API阶段，深入思考理解内部底层设计及实现

4. 理解业务，助力业务

5. 迁移

   快速进入某个领域，在于自己的知识迁移能力

6. 机遇

   发展和机遇有一定相关

QA

Q: 对测试的友好支持

Router不同场景的入口，方便测试
复制代码

Q: 知识迁移

方法论、概念的迁移
复制代码

Q: 业务角度看MVP、MVVM选型

数据量小：MVP足够且方便用
大数据量：电商等，数据处理多，很痛苦MVVM会较好
        强数据和强交互的划分
复制代码

Android组件化的正确姿势 ->张明庆 得到

高高山顶立，深深海底行

组件化面临三座大山

1. 业务开发时间太紧

2. 业务过于庞大

3. 隐藏的阻力

组件化：需要站在更高的山去看他们

实施设计方案的态度

深深海底行->沉入代码

为什么要组件化

• 用包来区分模块

• 用module区分模块

------以上胖体系(巨大开发包袱/拖慢开发节奏/下班晚)------

• 组件化

• 插件化

• 组件化/插件化阵营

组件化使用的人多，开源内容少

组件化设计时容易和业务强耦合

• 为什么不是插件化
  1. 除了动态添加，组件化能实现插件化所有功能
  2. 组件化学习曲线更加平滑
  3. 插件话不可避免进行系统Hook，9.0以上前途未卜

高高山顶立

1. 代码搬家，隔离结偶

   组件单独调试

   避免资源冲突

2. 组件生命周期

   运行时动态打开组件（加载）

   运行时动态关闭组件->ABTest（卸载）

   组件降维H5（降维）

   更庞大需要更多

3. 交互互通有无

   每个组件怎么提供服务

   怎样做到更方便的服务发现

   服务接口如何自动化与其他代码剥离

   组件和组件之间的Router

4. UI跳转

   是否支持scheme跳转

   路由和传递仓鼠是否支持自动注解生成

   是否可以生成清晰的路由->路由表的生成自动

5. 集成调试

   任何组件能否充当host

   组件由host切换到library是否可以无感知的完成

6. 代码和资源隔离

   如何做到代码隔离

   语法	旧语法	功能	支持类型	代码隔离效果
   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，实现类，公共资源
  • 地道战：广播、sp、db
  • 不知道该不该下沉：不该，明确下沉：该

• 康威法则 组织架构和架构之间的映射关系

  • 尽量贴近组织结构和产品业务
  • 尽力去反响改变组织结构和产品业务
  • 做不到，回第一条
  • 不要逆行

• 团队共识 就是：我知道，你知道，我知道你知道，你知道我知道……

  • 得到大多数人的支持
  • 持续的输出正向结果
  • 给更多人赋能，让更多人入坑
  • 建立配套的模块负责人制度等

《得到》组件化成果

和讲师聊骚

实时多媒体SDK性能优化 Powerinfo 许建林。

性能优化流程

测量，分析，优化=>循环

RTC SDK业务流程

采集->预处理->预览->编码->发送->接收->解码->后处理->渲染

优化

紧扣场景做优化

脱离场景谈优化，都是耍流氓

• 推流首屏时间

• 屏到屏的延迟

• cpu占用

• 内存抖动优化

测量方法

首屏时间 视频慢动作录制。。。。会玩 视屏延迟

优化思路

多操作并行

预操作提前

智能pos架构演进 美团 闫飞

pos机->收银功能整合

客户端架构理解：

• 业务观：时刻理解业务规则及特点

• 全局观：关注上下游服务，以全局的视角审视问题

• 视野观：技术宽度不限于客户端（某一块）

• 发展观：架构是面临的问题一步步迭代出来的，很少一步到位

• 运营观：关注产品各项指标

演进

• 0.5时代

  资源缺乏&业务快速推进->复杂事情简单化，取得0的突破

  架构本身就不是一步到位的事情，如何在短时间内集中稀缺资源推动项目上线？这势必要分清主次、有所取舍，将复杂事情简单化。只有取得零的突破，才有谈演进的资本

• 1.0时代

  面临着：稳定性、厂商对接复杂度、多版本管理

  索取主动权，思考重新设计

  • 建立硬件抽象层，自研银行卡收银

  • 银行卡收银分层模块化

  • 异常处理：充分暴露异常，而不是试图消灭异常

  下层收集异常，上层处理异常->异常处理模块统一对异常进行处理 埋点：技术侧埋点与产品侧埋点

• 2.0时代 拥抱开放

  • 建立收银服务层
  • 美团智能支付开放生态

• 总结

  • 架构没有定义、没有标准，唯有深刻理解业务，围绕业务不断思考不断迭代

  技术离不开业务，努力写简单代码

圆桌

Android前景

1. 业务优先，关注所做工作的上下游，眼界不局限于客户端
2. 不要把自身局限于当前“身份”


1. 追本溯源，当程序员的出发点。享受红利的同时，承担其风险（技术变化快等）
2. 走出舒适区
3. 新技术，去尝试。大前端的趋势，具体技术不能确定

1. 核心：学习能力
复制代码

面试

美团： 校招：基础(数据结构算法等)，解决问题能力 社招：解决问题，思考问题的能力

不要试图把握面试主动性：睡个好觉直接去就行了

平常：注重提升个人核心竞争力

面试是一个互动的过程，不要拘束，不要埋头想问题，多互动交流