Android开发高手课
张绍文
前微信高级工程师，Tinker负责人
立即订阅
12609 人已学习
课程目录
已完结 61 讲
0/4登录后，你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 焦虑的移动开发者该如何破局？
免费
导读 (1讲)
导读 | 如何打造高质量的应用？
模块一 高质量开发 (25讲)
01 | 崩溃优化（上）：关于“崩溃”那些事儿
02 | 崩溃优化（下）：应用崩溃了，你应该如何去分析？
03 | 内存优化（上）：4GB内存时代，再谈内存优化
04 | 内存优化（下）：内存优化这件事，应该从哪里着手？
05 | 卡顿优化（上）：你要掌握的卡顿分析方法
06 | 卡顿优化（下）：如何监控应用卡顿？
06补充篇 | 卡顿优化：卡顿现场与卡顿分析
07 | 启动优化（上）：从启动过程看启动速度优化
08 | 启动优化（下）：优化启动速度的进阶方法
09 | I/O优化（上）：开发工程师必备的I/O优化知识
10 | I/O优化（中）：不同I/O方式的使用场景是什么？
11 | I/O优化（下）：如何监控线上I/O操作？
12 | 存储优化（上）：常见的数据存储方法有哪些？
13 | 存储优化（中）：如何优化数据存储？
14 | 存储优化（下）：数据库SQLite的使用和优化
15 | 网络优化（上）：移动开发工程师必备的网络优化知识
16 | 网络优化（中）：复杂多变的移动网络该如何优化？
17 | 网络优化（下）：大数据下网络该如何监控？
18 | 耗电优化（上）：从电量优化的演进看耗电分析
19 | 耗电优化（下）：耗电的优化方法与线上监控
20 | UI 优化（上）：UI 渲染的几个关键概念
21 | UI 优化（下）：如何优化 UI 渲染？
22 | 包体积优化（上）：如何减少安装包大小？
23 | 包体积优化（下）：资源优化的进阶实践
24 | 想成为Android高手，你需要先搞定这三个问题
模块二 高效开发 (9讲)
25 | 如何提升组织与个人的研发效能？
26 | 关于编译，你需要了解什么？
27 | 编译插桩的三种方法：AspectJ、ASM、ReDex
28 | 大数据与AI，如何高效地测试？
29 | 从每月到每天，如何给版本发布提速？
30 | 数据评估（上）：如何实现高可用的上报组件？
31 | 数据评估（下）：什么是大数据平台？
32 | 线上疑难问题该如何排查和跟踪？
33 | 做一名有高度的移动开发工程师
模块三 架构演进 (9讲)
34 | 聊聊重构：优秀的架构都是演进而来的
35 | Native Hook 技术，天使还是魔鬼？
36 | 跨平台开发的现状与应用
37 | 移动开发新大陆：工作三年半，移动开发转型手游开发
38 | 移动开发新大陆：Android音视频开发
39 | 移动开发新大陆： 边缘智能计算的趋势
40 | 动态化实践，如何选择适合自己的方案？
41 | 聊聊Flutter，面对层出不穷的新技术该如何跟进？
42 | Android开发高手课学习心得
练习Sample跑起来 (8讲)
练习Sample跑起来 | 热点问题答疑第1期
练习Sample跑起来 | 热点问题答疑第2期
练习Sample跑起来 | 热点问题答疑第3期
练习Sample跑起来 | 热点问题答疑第4期
练习Sample跑起来 | ASM插桩强化练习
练习Sample跑起来 | 唯鹿同学的练习手记 第1辑
练习Sample跑起来 | 唯鹿同学的练习手记 第2辑
练习Sample跑起来 | 唯鹿同学的练习手记 第3辑
特别放送 (7讲)
Android JVM TI机制详解（内含福利彩蛋）
专栏学得苦？可能是方法没找对
专栏学得苦？可能你还需要一份配套学习书单
Native下如何获取调用栈？
聊聊Framework的学习方法
Android工程师的“面试指南”
程序员修炼之路 | 设计能力的提升途径
结束语 (1讲)
结束语 | 移动开发的今天和明天
Android开发高手课
登录|注册
30 | 数据评估（上）：如何实现高可用的上报组件？
张绍文 2019-03-07
无论是“高效测试”中的实时监控，还是“版本发布”中的数据校验平台，我都多次提到了数据的重要性。
对于数据评估，我们的期望是“又快又准”。“快”，表示数据的时效性。我们希望在 1 小时内，甚至 1 分钟内就可以对数据进行评估，而不需要等上 1 天或者几天。“准”，表示数据的准确性，保证数据可以反映业务的真实情况，不会因为数据不准确导致做出错误的产品决策。
但是“巧妇难为无米之炊”，数据平台的准确性和时效性依赖客户端数据采集和上报的能力。那应该如何保证客户端上报组件的实时性和准确性？如何实现一个“高可用”的上报组件呢？
统一高可用的上报组件
可能有同学会疑惑，究竟什么是“高可用”的上报组件？我认为至少需要达到三个目标：
数据不会丢失。数据不会由于应用崩溃、被系统杀死这些异常情况而导致丢失。
实时性高。无论是前台进程还是后台进程，所有的数据都可以在短时间内及时上报。
高性能。这里主要有卡顿和流量两个维度，应用不能因为上报组件的 CPU 和 I/O 过度占用导致卡顿，也不能因为设计不合理导致用户的流量消耗过多。
但是数据的完整性、实时性和性能就像天平的两端，我们无法同时把这三者都做到最好。因此我们只能在兼顾性能的同时，尽可能地保证数据不会丢失，让上报延迟更小。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Android开发高手课》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(4)
Andy采样模块的算法有问题吧
上报用户 =（id_index == id_index）？
应该是id_index==time_index吧作者回复: 已经修正了，感谢提醒
2019-03-08 2
刘伟1. 不使用推送，可以在每次上报的时候，把最新的策略作为响应返回给客户端，告诉客户端在什么时候改更新策略。
2. 可以让上报进程来做，上报进程通过FileObserver 来监听每个进程日志文件的更改时间，如果指定时间内没有变化，则可以立马上报该进程的文件。作者回复: 👍，八九不离十，具体答案后面有公布
2019-03-07 2
奚岩对于采样策略的更新，可以在最新一次上报后带回，放入另一 FileObserver 中 ，Process A 获取使用；
对于 Process A 的崩溃，要主进程来上报么？作者回复: 1.策略更新，的确是最新上报带回。不过没有使用fileobserver，因为如果每个进程都加上他的代价有点大。用broadcast就可以
2. 这里是通过上报进程每隔一段时间监测+崩溃进程下次启动自检测，两个手段同时保证2019-03-07 2
DebugCat我相信大多数产品都有基本的埋点上报功能，但是估计自己研发一套高可用的上报组件的公司不是很多。工作两年多，我一直思考这种功能只有加入大公司的技术团队才有机会去做，还是发挥自己的积极主动性就能做出来。（客观说）感觉中小心公司一直是业务业务...基础架构投入不大，够用就行。我的疑惑哈，希望同行们解惑。作者回复: 的确跟平台很有所关系，但是核心还是靠个人
2019-03-07 2
收起评论