MDCC_Android专场观后感
1.回归初心，从容器化到组件化
app 组件化：独立性，可替代性，互操作性 目的：解决耦合性 缺点：调用时候比较复杂，有一定的“契约”约束性，后向兼容性
独立性：团队的分工比较明确，可以分工操作提高效率，并行开发
组件化升级前提是应用内部必须要做到组建话才能做到不通过应用市场进行升级
通过package隔离，虽然很简单但只是一个简易的解耦
通过grade隔离，build起来成本会很高
通过multiple Apks
主流组件化方式：1.Multi-Dex 2.Container (容器，代理组件) 3.Semi-container
阿里项目：Atlas
建议：小团队：1.在项目成型初期做组件化是最佳时间。2.在团队创建初期最好不要自己做组件，投入回报比太低
大团队：1.在确定目标时就分工明确，避免使用纯容器话的组件
2.云信IM推送保障以及网络优化实践：
Instant:有新消息能立即收到推送无延迟
Messaging:稳定可靠安全不丢消息
功能实现方法：后台运行（有可能被杀掉）四种方式：
1.Sticky Service
2.Alarm
3.Receiver
4.JobScheduler
MIUI和EMUI有自己的一套系统级推送
Google本身有一套推送体系不过在国内被墙掉了
音视频优化：FEC，自适应初始化包频，动态包频喝码率调整，数据缓冲Buffer，音频plc丢包补偿，Temporcal Scalability视频编码防晒
文件传输：断点续传，图片预加载，pipeline，边录边传
3.微信Tinker热补丁
应用无需安装下载就自动更新
热更新两大流派：1.Native 2.java
tinker设计目标：稳定性兼容性，性能，易用性；“高可用”
减小安装大小，对特定有问题的用户推送补丁包，获取调试信息。
技术是用来解决问题的，明确需求：稳定兼容，性能，易总。
- 1.0 小试牛刀
- 基于 classloader 的方案
- preverify 问题，内存地址错乱，性能差，补丁包大
- 2.0 自创功法
- dex diff
- anr，dex 太大，分平台合成 dex，art 上合成小 dex。
- illegal access。
- 性能好，兼容性和稳定性差
- 3.0 修炼内功
- 异常、调试信息收集
- 4.0 内外兼修
- 提升易用性和稳定性
4.Fresco:
官方链接：
http://fresco-cn.org/
api支持18以上的版本 引入的aoi大小在260-300k左右
推荐使用Drawee，会在不用的时候把图片占用的缓存给去除，减轻app压力。还可以做到在展示图片前可以先下载下来选择不展示，需要展示的时候再展示。Memory节省是重点, 不然容易造成oor异常（ashmem共享内存会在很大程度上减轻压力）
drawee没准备继承imageview，在迁移的时候会麻烦一些
5.数盟如何打造可信赖的安卓设备ID
针对目前很多app可以找第三方刷数据，下载量。IMEI和MaC地址以及所有显性id都可以伪造
1.芯片级造假 2.模拟器造假 3.破解数据间接造假
应对方法：可100%识别模拟器id，做到排除模拟器，编译器级别的反编译方法
6.Android应用性能优化经验分享
相关学习资料：
（1）android 谷歌官方优化出到第六季有机会去看一下
（2）国内的话是安卓胡凯大神
现象：费电，应用启动慢，json库不合理应用使用卡顿，监听开机广播，导致开机后一段时间lancher严重卡顿，非静态内部类导致内存泄漏，四大组件不合理使用，io操作完成后没有关闭和回收，系统sdk导致的内存泄漏，在系统回调或频繁的使用代码块中创建新的实例，功耗问题明显（过度绘制，驯化动画，网络请求不合理，后台常驻服务）
性能优化流程：发现问题。定位问题。改善问题，验证问题
性能优化原则：不能凭感觉，有足够的测量，尽量使用低配置设备进行调试，权衡利弊，以稳定为主，改善后验证，不要导致新的问题出现。
性能优化指标：内存，启动速度，流畅度，功耗