first commit
This commit is contained in:
张乾
93
专栏/Android开发高手课/00导读如何打造高质量的应用？.md
Normal file
93
专栏/Android开发高手课/00导读如何打造高质量的应用？.md
Normal file
@ -0,0 +1,93 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
00 导读 如何打造高质量的应用？
|
||||
今年年初，我去上海参加一个移动技术会议，问了很多开发者最近在忙啥。令我非常惊讶的是，大家讲的最多的还是用户体验和应用质量。特别是出海东南亚的同学，面对一堆512MB内存的设备、无处不在的弱网络流下了无助的眼泪。
|
||||
|
||||
除了内存优化、弱网络优化，想做一款高质量的应用还远远不止这些。一方面，我们面对的环境越来越复杂。过去的iOS开发者可能做梦也想不到，现在也要开始适配屏幕和双卡双待了，更不用说Android那多如繁星的机型、厂家和系统。如果你的应用也要出海，那么还要面对几十个国家不同的语言、环境。
|
||||
|
||||
另一方面，我们的代码跟业务也越来越复杂了。先不说大量“年久失修”的历史代码，业务越来越复杂，如何管理好几十上百个模块？还要面对React Native、Flutter、TensorFlow等各种语言跟框架堆积在一起的情况，再加上复杂的环境和庞大的系统，想想做一款高质量的应用真的不容易。
|
||||
|
||||
从应用交付的流程说起
|
||||
|
||||
既然打造一款高质量的应用那么困难，我们可以先从哪里入手做些什么呢？我的方法是把应用当成一件商品，想象一下商品在流水线生产的过程，那么怎样在每个步骤做好“质检”呢？这就要从应用交付的流程说起。
|
||||
|
||||
在我看来，一个应用至少会经过开发、编译CI、测试、灰度和发布这几个阶段。每个阶段需要关注什么问题呢？
|
||||
|
||||
1.开发阶段。在面试的时候，常常有人说自己熟练掌握各种开发工具。但是，我们真的懂吗？就拿我们比较熟悉的耗时分析工具Traceview来说，它背后的实现原理是什么？能不能做一个完全没有性能损耗的Traceview？或者怎么样将它移植到线上使用？
|
||||
|
||||
2.编译CI阶段。如何防止代码不断地恶化？怎样进一步优化性能？d8与ReDex有什么神奇的黑科技？如何利用好Coverity、Infer这些静态分析工具？这部分可能需要一些编译原理的知识，你会发现移动开发也有很多值得深入研究的东西。
|
||||
|
||||
3.测试阶段。我们常说敏捷开发，用户是最好的测试。遇到问题在线上反复试错，对自己、对用户都十分痛苦。我们希望可以做到测试“左移”，尽可能早地发现问题。但是很多时候我们不是不想测试，而是发现测不出什么问题。那么怎样提升实验室发现问题的能力呢？如何尽可能地模拟用户的操作路径？做好测试并不容易，自动化测试结合AI或许可以帮助我们解决一些痛点。
|
||||
|
||||
4.灰度和发布阶段。动态部署流行起来之后，很多开发变得松懈起来。有问题发补丁，一个不行就两个，两个不行就十个。怎样去保证产品质量？很多线上问题概率很低，基本很难复现，比如对于一个印度的用户，我们希望有一个远程的听诊器，而不需要把用户拉到我们的手术台上。
|
||||
|
||||
对照应用的交付流程，我来介绍一下专栏的学习方法。专栏“高质量开发”模块主要对应的是开发阶段，你可以带着实践过程的困惑去深入学习开发需要的各种武器。专栏“高效开发”模块主要对应编译CI、测试、灰度和发布阶段，你可以结合实际工作全面提升整个应用交付的效率。另外，我认为一个好的架构可以减少甚至避免团队出错，也是打造一款高质量应用非常重要的一环，因此我会在最后的“架构演进”模块和你聊聊如何设计一个好的架构，以及架构该如何选型。
|
||||
|
||||
|
||||
|
||||
移动APM质量平台
|
||||
|
||||
请你思考一下，在应用交付的这几个阶段中，我们对高质量的目标和实现方式是否一样呢？开发阶段有开发人员，可能希望采集尽可能多的数据；测试阶段有测试人员，可能更针对实验室环境或与竞品对比进行测试；灰度和发布阶段可能也有专门的运维人员，策略会相对保守一些。很明显，不同阶段我们对高质量的目标跟手段可能不太一样。
|
||||
|
||||
一个公司有多套质量系统，这在大公司是非常普遍的现象。我们希望有一个统一的平台，整合应用的人员和开发流程，这就是我们常说APM质量平台。
|
||||
|
||||
APM的全称是“Application Performance Management”，即应用性能管理。据我了解，国内像阿里、腾讯、美团点评、饿了么、爱奇艺这些公司都在大力投入。Google今年也发力Android Vitals监控，新增了耗电、权限管理模块。那么APM质量平台究竟有着什么样的魅力呢？
|
||||
|
||||
1. 统一管理。A同学写了一个耗时监控工具，B同学写了一个内存监控工具，它们在不同的仓库，上报格式可能不太一样，各自都搭了一个简单的页面。如果想评估一个应用的质量，总是要去几个系统汇总数据，想想都费劲。
|
||||
|
||||
2. 统一三端。一个公司可能有多个应用，一个应用也可能有H5、iOS、Android多个端。我们希望它们只是采集数据方式有所不同，上报、后台分析、展示、报警都是共用的。随着技术的发展，我们可能会增加React Native、Flutter这些新模块的监控，这个平台应该是统一演进的。当然我们非常希望业界有一套开源的方案，大家可以一起优化。
|
||||
|
||||
|
||||
|
||||
那这个质量平台需要关注哪些问题呢？这需要看我们用户关心什么问题。有的问题可能是致命的，像崩溃、卡死、白屏。另一大类问题就是性能问题，安装包大小、启动、耗时、内存、耗电、流量都是这一个范畴。在这个专栏里，我并不会教你如何从头搭建一个APM平台，我会更期待你掌握背后所需要的知识，它们主要包括：
|
||||
|
||||
|
||||
|
||||
由于Android版本的碎片化和国内Android生态的乱象，或者换句话说，“Android开发者很苦，国内的Android开发者更苦”。在11月举办的Android绿色联盟开发者大会上推出的应用体验标准，有对应用的兼容性、稳定性、性能、功能和安全做了详细的定义。我贴张图，你可以看下。
|
||||
|
||||
|
||||
|
||||
在极致性能的同时，我们希望能更进一步地打造“绿色应用”。在这个过程中，一个全面而强大的APM质量平台会是我们坚实的后盾。当然对于大多数中小开发者来说，我们更建议选择成熟的第三方服务。但深入了解它们背后的原理，无论是对我们如何选择合适的服务，还是日常开发工作都会有很大的帮助。在学习完上面的这些内容之后，你也会觉得其实“性能优化”并不是那么“高不可攀”，我们也可以慢慢地迈向“性能优化专家”之路。
|
||||
|
||||
不过我们需要明确一点，虽然移动APM质量平台可以帮助我们快速发现和定位问题，但是监控并不能保证实现高质量，这里最关键的永远是人，而不是系统。为什么呢？我举两个小例子。
|
||||
|
||||
你在工作中可能总能遇到这样的场景，我管它叫反馈问题三连击：“是我的问题吗？”“能复现吗？”“你的测试靠谱吗？”。虽然通过APM质量平台可以减少推卸责任，但有些人的做法通常还是发现空指针加一个判空，发现并发问题加一个锁。这里的空指针真正原因是什么？这里判空了后面的逻辑是否还会运行正常？有没有更加好的方法或架构可以避免这个问题？我们真正应该反问的是这三个问题，把“质量观”深入骨髓，真正去想要得到个人成长，深挖背后的原因。
|
||||
|
||||
第二个例子是，我发现许多人都在问题无法忍受，或者说是老板无法忍受的时候才去开启各种优化专项，但事后又不了了之。我们很多时候都在用战术的勤奋掩盖战略的懒惰，性能优化的关键在于如何解决存量问题，同时快速发现增量问题。APM质量平台只可以协助我们，并不能解决组织内部的心态问题。
|
||||
|
||||
总结
|
||||
|
||||
看到这里可能你会有这样的疑问，我们在小公司根本没有机会学习到这些东西呀？确实如此，个人与公司一起成长是最快速，也是非常难得的事情，但并不一定人人都会有这样的机会。从我自己的经验来看，在搜狗、微信会遇到各种各样的疑难问题，也可以有很多时间去研究，让我在解决问题的过程中获得成长。
|
||||
|
||||
幸运的是现在大家都更加乐于去分享，在专栏和技术会议中，我们可以看到很多成熟的解决问题的经验和思路，在GitHub我们可以找到很多优秀的源代码。在这个环境下，我们需要耐得住寂寞，多抠一些细节，多深入研究，多停下来总结。
|
||||
|
||||
我来分享一个我的故事，2013年初我去面试微信，前面都不太理想，最后还是通过了。后来有一次跟面试官闲聊说起这个事情，他们认为有一件事情打动了他们。2012年的时候，LeakCanary还没开源，我在使用MAT做内存泄漏分析的时候总觉得很不爽。为什么不能做自动化？为什么看不到Bitmap的图片？我当时深入研究了内存文件Hprof的格式，做了几个小创新：
|
||||
|
||||
1.实现内存的自动化测试。在自动化测试后回到首页，这个时候获取应用的内存快照。自动分析内存中Activity实例，正常情况应该只存在一个，其他都认为是泄漏。为了支持正式包，还做了通过mapping文件反混淆Hprof文件的功能。
|
||||
|
||||
2.查看图片。自动将内存中重复的图片、比较大的图片转换成PNG格式输出到文件。
|
||||
|
||||
现在看起来这些功能并不是太难，但如果放到六年前，想到而且能做到的人相信并不多。讲这个故事还是希望你能在工作和实践中多停下来思考，多深入研究一些细节，很多看似不经意的思考和创新，可能在日后发挥更大的价值。
|
||||
|
||||
课后作业
|
||||
|
||||
“纸上得来终觉浅，绝知此事要躬行”，只有通过实践，运用到自己的项目里面，才会对知识有更深入地理解。
|
||||
|
||||
我为专栏的“课后作业”环节专门设计了可供你操作实践的Sample，并在GitHub新建了专栏的Group，后面会陆续将这些Sample放到上面。课后作业主要是根据Sample进行操作，需要你理解实现原理，并在极客时间App专栏文章下面的留言区提交你的学习总结和思考。我和极客时间为认真提交作业的同学准备了丰厚的学习加油礼包，里面包含我推荐的经典图书、极客时间周历、专栏阅码等礼品。我还会选出坚持参与学习并分享心得的同学，在专栏模块一、模块三结束时，分别送出2张2019年GMTC大会的门票。
|
||||
|
||||
为了更好地给同学们答疑，我邀请了我的朋友孙鹏飞作为课程的“学习委员”，他将不定期讲解我们Sample的实现原理。鹏飞是Android资深开发工程师，现在负责某知名网约车平台司机端的业务开发、性能优化等工作。我们的学习委员对系统框架、虚拟机、性能优化等都有很深入的理解，实战经验也很丰富，相信鹏飞的加入可以更好地帮助你掌握课程的要点，并能解决实践中的问题。
|
||||
|
||||
今天是课程导读，也正式开启了我们接下来3个多月的学习之旅，所以最后特别邀请你在留言区也做个自我介绍，介绍下自己，聊聊目前的工作、学习情况，或者说说遇到的具体问题和困惑，也可以写写自己对这个课程的期待，让我们彼此有更多了解。
|
||||
|
||||
希望你能够积极参与进来，咱们教学相长，共同进步。
|
||||
|
||||
欢迎你点击“请朋友读”，把今天的内容分享给好友，邀请他一起学习。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
45
专栏/Android开发高手课/00开篇词焦虑的移动开发者该如何破局？.md
Normal file
45
专栏/Android开发高手课/00开篇词焦虑的移动开发者该如何破局？.md
Normal file
@ -0,0 +1,45 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
00 开篇词 焦虑的移动开发者该如何破局？
|
||||
最近半年，常常有人问我两个问题：“现在学习移动开发还有前景吗？”“移动开发还有什么可以研究的？”。这两个问题其实对应着同一个现象，无论是准备入行或刚刚入行，还是比较资深的开发者，对于移动开发职业的未来，都有一些迷茫、一些焦虑。为什么会这样？
|
||||
|
||||
现在想想，移动互联网的发展不知不觉已经十多年了，Mobile First也已经变成了AI First。换句话说，我们已经不再是“风口上的猪”。移动开发的光环和溢价开始慢慢消失，并且正在向AI、区块链等新的领域转移。移动开发的新鲜血液也已经变少，最明显的是国内应届生都纷纷涌向了AI方向。
|
||||
|
||||
可以说，国内移动互联网的红利期已经过去了，现在是增量下降、存量厮杀，从争夺用户到争夺时长。比较明显的是手机厂商纷纷互联网化，与传统互联网企业直接竞争。另外一方面，过去渠道的打法失灵，小程序、快应用等新兴渠道崛起，无论是手机厂商，还是各大App都把出海摆到了战略的位置。
|
||||
|
||||
从技术的角度来看，今年移动端的技术变革也有点缓慢。大前端的概念虽然说了很久也很多，但React Native、PWA（Progressive Web App）的效果依然不尽人意。在插件化热潮之后，移动端的精品文章开始变少。去年“安利”完Kotlin之后，今年讲得比较多的还是Flutter。
|
||||
|
||||
这么看来，移动开发的前景不明朗，再加上竞争激烈以及技术变革放缓，我们感到迷茫、焦虑似乎就不难理解了。
|
||||
|
||||
带着同样的焦虑，2017年年底我选择离开了微信，目前在某知名互联网企业负责海外产品的技术工作。
|
||||
|
||||
回想一下自己的过去，经历了搜狗手机输入法用户从一千万到一亿，也见证了微信用户从一亿到十亿的增长。在快速成长的同时，让我感到更加快乐的是对社区还是做出了那么一点贡献。写了一些文章，建立并运营了WeMobileDev公众号，输出了一些技术干货和思考；拥抱了开源，Tinker、Mars、WCDB相继开源，特别是Tinker作为腾讯在GitHub的第一个开源产品，让我体会到了开源的魅力。
|
||||
|
||||
在进入新工作环境的这大半年里，我遇到了一些困难，也接受了很多新的挑战。慢慢明白，或许是移动互联网这个大环境变了，推动我们不得不跟着转变。移动端的招聘量变少，但中高端的职位却多了起来，这说明行业只是变得成熟规范起来了。竞争激烈，但产品质量与留存变得更加重要，我们进入了技术赋能业务的时代。大前端正在跨平台，移动开发者的未来更可能是跨终端，产品、运营、数据分析、后端，技多不压身。
|
||||
|
||||
那企业需要什么样的移动开发人才？移动开发还可以做些什么？我希望通过这个专栏来回答你这两个问题。专栏里，我会结合业界的现状，讲讲国内外各大公司的尝试，以及他们的发展方向。我会尽量少放源码，侧重结合工作上的实践经验，分享一些疑难问题的解决思路。整体来说，主要包括以下三个部分 （注：60%是Android相关的，40%是可以跨平台的）。
|
||||
|
||||
1. 高质量开发。在如今的竞争态势下，保证产品的基础用户体验尤为重要。最近国内外各大公司，对APM性能监控系统也越来越重视。我挑选了崩溃、内存、卡顿、启动、I/O、存储、网络、耗电、渲染、安装包体积等比较常见的关键点，为你全面梳理性能优化的经验技巧与方向，帮你学会如何解决已知的存量问题，同时也能及时发现增量问题。
|
||||
|
||||
2. 高效开发。持续交付、DevOps近年在国内非常火热，我们都在寻找内部突破，提升效率。一个应用从想法到成品，需要经历开发、编译CI、测试、灰度、发布等多个阶段，那怎样提升各个阶段的效率，也是你我比较关心的话题。跨平台开发可能是解决开发阶段的一个答案，动态部署可能是发布阶段的一个答案。头条和快手如何做到数据驱动式的开发，怎样才是高效的运营，在这个模块，我将围绕这些内容一一展开。
|
||||
|
||||
3. 架构演进。“君有疾在腠理，不治将恐深”，对于一个应用来说，架构一定是核心中的核心。在这个模块，我会讲到Google的一些架构演进，例如Android P、App Bundle、虚拟机、耗电等，也会讲到移动网络架构的一些选择，跨平台开发、动态化实践等热点知识。
|
||||
|
||||
在我看来，如今的移动开发开始冷下来了，或者有人说开始进入移动互联网的下半场了。其实，对于我们开发人员来说，不管是下半场还是上半场，我们重要的是要把技术做好做精做深。是的，现在移动开发已经不再是风口，但是，这并不是说移动开发已经被淘汰，而是说移动开发的发展进入了成熟期，就像Web技术一样。
|
||||
|
||||
如果说现在，你还只是能做好产品给过来的“需求”，我认为这是远远不够的。作为一个移动开发工程师，你我都需要深耕细作，都需要有工匠精神，把已有的事情从好做到更好。因为在迈向更好的过程中，你必然需要学习底层原理，你必然需要拓展知识面，你必然需要结合其他的技术，有了这么多必然，你也必然会变得更强。
|
||||
|
||||
所以，我在这里回答我一开始提出的那个让人焦虑的问题。首先，我认为，移动开发不等于App开发，所有新的技术浪潮其实都可以融入到移动开发的体系里，比如IoT、音视频、边缘计算、VR/AR，我们要做的，只是打好基础，随时准备战斗。其次，从心态上，我觉得我们千万不要把时间浪费在纠结问题上，而是应该放在解决问题上。“王者荣耀”“吃鸡”并不能解决我们的焦虑，拥抱变化，才能拥有未来，让我们共勉。
|
||||
|
||||
最后，我和极客时间一起，为你准备了丰厚的学习大礼包，听说礼包里面有GMTC大会的门票哦。今天先卖个关子，我会在下一节“导读”里给你揭晓。
|
||||
|
||||
希望通过这个专栏，可以在这个节骨眼上，给你一些启发和帮助。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
163
专栏/Android开发高手课/01崩溃优化（上）：关于“崩溃”那些事儿.md
Normal file
163
专栏/Android开发高手课/01崩溃优化（上）：关于“崩溃”那些事儿.md
Normal file
@ -0,0 +1,163 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
01 崩溃优化（上）：关于“崩溃”那些事儿
|
||||
在各种场合遇到其他产品的开发人员时，大家总忍不住想在技术上切磋两招。第一句问的通常都是“你们产品的崩溃率是多少？”
|
||||
|
||||
程序员A自豪地说： “百分之一。”
|
||||
|
||||
旁边的程序员B鄙视地看了一眼，然后喊到： “千分之一！”
|
||||
|
||||
“万分之一” ，程序员C说完之后全场变得安静起来。
|
||||
|
||||
崩溃率是衡量一个应用质量高低的基本指标，这一点是你我都比较认可的。不过你说的“万分之一”就一定要比我说的“百分之一” 更好吗？我觉得，这个问题其实并不仅仅是比较两个数值这么简单。
|
||||
|
||||
今天我们就来聊一聊有关“崩溃”的那些事，我会从Android的两种崩溃类型谈起，再和你进一步讨论到底该怎样客观地衡量崩溃这个指标，以及又该如何看待和崩溃相关的稳定性。
|
||||
|
||||
Android 的两种崩溃
|
||||
|
||||
我们都知道，Android崩溃分为Java崩溃和Native崩溃。
|
||||
|
||||
简单来说，Java崩溃就是在Java代码中，出现了未捕获异常，导致程序异常退出。那Native崩溃又是怎么产生的呢？一般都是因为在Native代码中访问非法地址，也可能是地址对齐出现了问题，或者发生了程序主动abort，这些都会产生相应的signal信号，导致程序异常退出。
|
||||
|
||||
所以，“崩溃”就是程序出现异常，而一个产品的崩溃率，跟我们如何捕获、处理这些异常有比较大的关系。Java崩溃的捕获比较简单，但是很多同学对于如何捕获Native崩溃还是一知半解，下面我就重点介绍Native崩溃的捕获流程和难点。
|
||||
|
||||
1.Native崩溃的捕获流程
|
||||
|
||||
如果你对Native崩溃机制的一些基本知识还不是很熟悉，建议你阅读一下《Android平台Native代码的崩溃捕获机制及实现》。这里我着重给你讲讲一个完整的Native崩溃从捕获到解析要经历哪些流程。
|
||||
|
||||
|
||||
编译端。编译C/C++代码时，需要将带符号信息的文件保留下来。
|
||||
|
||||
客户端。捕获到崩溃时候，将收集到尽可能多的有用信息写入日志文件，然后选择合适的时机上传到服务器。
|
||||
|
||||
服务端。读取客户端上报的日志文件，寻找适合的符号文件，生成可读的C/C++调用栈。
|
||||
|
||||
|
||||
|
||||
|
||||
2.Native崩溃捕获的难点
|
||||
|
||||
Chromium的Breakpad是目前Native崩溃捕获中最成熟的方案，但很多人都觉得Breakpad过于复杂。其实我认为Native崩溃捕获这个事情本来就不容易，跟当初设计Tinker的时候一样，如果只想在90%的情况可靠，那大部分的代码的确可以砍掉；但如果想达到99%，在各种恶劣条件下依然可靠，后面付出的努力会远远高于前期。
|
||||
|
||||
所以在上面的三个流程中，最核心的是怎么样保证客户端在各种极端情况下依然可以生成崩溃日志。因为在崩溃时，程序会处于一个不安全的状态，如果处理不当，非常容易发生二次崩溃。
|
||||
|
||||
那么，生成崩溃日志时会有哪些比较棘手的情况呢？
|
||||
|
||||
情况一：文件句柄泄漏，导致创建日志文件失败，怎么办？
|
||||
|
||||
应对方式：我们需要提前申请文件句柄fd预留，防止出现这种情况。
|
||||
|
||||
情况二：因为栈溢出了，导致日志生成失败，怎么办？
|
||||
|
||||
应对方式：为了防止栈溢出导致进程没有空间创建调用栈执行处理函数，我们通常会使用常见的signalstack。在一些特殊情况，我们可能还需要直接替换当前栈，所以这里也需要在堆中预留部分空间。
|
||||
|
||||
情况三：整个堆的内存都耗尽了，导致日志生成失败，怎么办？
|
||||
|
||||
应对方式：这个时候我们无法安全地分配内存，也不敢使用stl或者libc的函数，因为它们内部实现会分配堆内存。这个时候如果继续分配内存，会导致出现堆破坏或者二次崩溃的情况。Breakpad做的比较彻底，重新封装了Linux Syscall Support，来避免直接调用libc。
|
||||
|
||||
情况四：堆破坏或二次崩溃导致日志生成失败，怎么办？
|
||||
|
||||
应对方式：Breakpad会从原进程fork出子进程去收集崩溃现场，此外涉及与Java相关的，一般也会用子进程去操作。这样即使出现二次崩溃，只是这部分的信息丢失，我们的父进程后面还可以继续获取其他的信息。在一些特殊的情况，我们还可能需要从子进程fork出孙进程。
|
||||
|
||||
当然Breakpad也存在着一些问题，例如生成的minidump文件是二进制格式的，包含了太多不重要的信息，导致文件很容易达到几MB。但是minidump也不是毫无用处，它有一些比较高级的特性，比如使用gdb调试、可以看到传入参数等。Chromium未来计划使用Crashpad全面替代Breakpad，但目前来说还是 “too early to mobile”。
|
||||
|
||||
我们有时候想遵循Android的文本格式，并且添加更多我们认为重要的信息，这个时候就要去改造Breakpad的实现。比较常见的例如增加Logcat信息、Java调用栈信息以及崩溃时的其他一些有用信息，在下一节我们会有更加详细的介绍。
|
||||
|
||||
如果想彻底弄清楚Native崩溃捕获，需要我们对虚拟机运行、汇编这些内功有一定造诣。做一个高可用的崩溃收集SDK真的不是那么容易，它需要经过多年的技术积累，要考虑的细节也非常多，每一个失败路径或者二次崩溃场景都要有应对措施或备用方案。
|
||||
|
||||
3.选择合适的崩溃服务
|
||||
|
||||
对于很多中小型公司来说，我并不建议自己去实现一套如此复杂的系统，可以选择一些第三方的服务。目前各种平台也是百花齐放，包括腾讯的Bugly、阿里的啄木鸟平台、网易云捕、Google的Firebase等等。
|
||||
|
||||
当然，在平台的选择方面，我认为，从产品化跟社区维护来说，Bugly在国内做的最好；从技术深度跟捕获能力来说，阿里UC浏览器内核团队打造的啄木鸟平台最佳。
|
||||
|
||||
如何客观地衡量崩溃
|
||||
|
||||
对崩溃有了更多了解以后，我们怎样才能客观地衡量崩溃呢？
|
||||
|
||||
要衡量一个指标，首先要统一计算口径。如果想评估崩溃造成的用户影响范围，我们会先去看UV崩溃率。
|
||||
|
||||
UV 崩溃率 = 发生崩溃的 UV / 登录 UV
|
||||
|
||||
|
||||
只要用户出现过一次崩溃就会被计算到，所以UV崩溃率的高低会跟应用的使用时长有比较大的关系，这也是微信UV崩溃率在业界不算低的原因（强行甩锅）。当然这个时候，我们还可以去看应用PV崩溃率、启动崩溃率、重复崩溃率这些指标，计算方法都大同小异。
|
||||
|
||||
这里为什么要单独统计启动崩溃率呢？因为启动崩溃对用户带来的伤害最大，应用无法启动往往通过热修复也无法拯救。闪屏广告、运营活动，很多应用启动过程异常复杂，又涉及各种资源、配置下发，极其容易出现问题。微信读书、蘑菇街、淘宝、天猫这些“重运营”的应用都有使用一种叫作“安全模式”的技术来保障客户端的启动流程，在监控到客户端启动失败后，给用户自救的机会。
|
||||
|
||||
现在回到文章开头程序员“华山论剑”的小故事，我来揭秘他们解决崩溃率的“独家秘笈”。
|
||||
|
||||
程序员B对所有线程、任务都封装了一层try catch，“消化”掉了所有Java崩溃。至于程序是否会出现其他异常表现，这是上帝要管的事情，反正我是实现了“千分之一”的目标。
|
||||
|
||||
程序员C认为Native崩溃太难解决，所以他想了一个“好方法”，就是不采集所有的Native崩溃，美滋滋地跟老板汇报“万分之一”的工作成果。
|
||||
|
||||
了解了美好数字产生的“秘笈”后，不知道你有何感想？其实程序员B和C都是真实的案例，而且他们的用户体量都还不算小。技术指标过于KPI化，是国内比较明显的一个现象。崩溃率只是一个数字，我们的出发点应该是让用户有更好的体验。
|
||||
|
||||
如何客观地衡量稳定性
|
||||
|
||||
到此，我们讨论了崩溃是怎么回事儿，以及怎么客观地衡量崩溃。那崩溃率是不是就能完全等价于应用的稳定性呢？答案是肯定不行。处理了崩溃，我们还会经常遇到ANR（Application Not Responding，程序没有响应）这个问题。
|
||||
|
||||
出现ANR的时候，系统还会弹出对话框打断用户的操作，这是用户非常不能忍受的。这又带来另外一个问题，我们怎么去发现应用中的ANR异常呢？总结一下，通常有两种做法。
|
||||
|
||||
1. 使用FileObserver监听/data/anr/traces.txt 的变化。非常不幸的是，很多高版本的ROM，已经没有读取这个文件的权限了。这个时候你可能只能思考其他路径，海外可以使用Google Play服务，而国内微信利用Hardcoder框架（HC框架是一套独立于安卓系统实现的通信框架，它让App和厂商ROM能够实时“对话”了，目标就是充分调度系统资源来提升App的运行速度和画质，切实提高大家的手机使用体验）向厂商获取了更大的权限。
|
||||
|
||||
2. 监控消息队列的运行时间。这个方案无法准确地判断是否真正出现了ANR异常，也无法得到完整的ANR日志。在我看来，更应该放到卡顿的性能范畴。
|
||||
|
||||
回想我当时在设计Tinker的时候，为了保证热修复不会影响应用的启动，Tinker在补丁的加载流程也设计了简单的“安全模式”，在启动时会检查上次应用的退出类型，如果检查连续三次异常退出，将会自动清除补丁。所以除了常见的崩溃，还有一些会导致应用异常退出的情况。
|
||||
|
||||
在讨论什么是异常退出之前，我们先看看都有哪些应用退出的情形。
|
||||
|
||||
|
||||
主动自杀。Process.killProcess()、exit() 等。
|
||||
|
||||
崩溃。出现了Java或Native崩溃。
|
||||
|
||||
系统重启；系统出现异常、断电、用户主动重启等，我们可以通过比较应用开机运行时间是否比之前记录的值更小。
|
||||
|
||||
被系统杀死。被low memory killer杀掉、从系统的任务管理器中划掉等。
|
||||
|
||||
ANR。
|
||||
|
||||
|
||||
我们可以在应用启动的时候设定一个标志，在主动自杀或崩溃后更新标志，这样下次启动时通过检测这个标志就能确认运行期间是否发生过异常退出。对应上面的五种退出场景，我们排除掉主动自杀和崩溃（崩溃会单独的统计）这两种场景，希望可以监控到剩下三种的异常退出，理论上这个异常捕获机制是可以达到100%覆盖的。
|
||||
|
||||
通过这个异常退出的检测，可以反映如ANR、low memory killer、系统强杀、死机、断电等其他无法正常捕获到的问题。当然异常率会存在一些误报，比如用户从系统的任务管理器中划掉应用。对于线上的大数据来说，还是可以帮助我们发现代码中的一些隐藏问题。
|
||||
|
||||
所以就得到了一个新的指标来衡量应用的稳定性，即异常率。
|
||||
|
||||
UV 异常率 = 发生异常退出或崩溃的 UV / 登录 UV
|
||||
|
||||
|
||||
前不久我们的一个应用灰度版本发现异常退出的比例增长不少，最后排查发现由于视频播放存在一个巨大bug，会导致可能有用户手机卡死甚至重启，这是传统崩溃收集很难发现的问题。
|
||||
|
||||
根据应用的前后台状态，我们可以把异常退出分为前台异常退出和后台异常退出。“被系统杀死”是后台异常退出的主要原因，当然我们会更关注前台的异常退出的情况，这会跟ANR、OOM等异常情况有更大的关联。
|
||||
|
||||
通过异常率我们可以比较全面的评估应用的稳定性，对于线上监控还需要完善崩溃的报警机制。在微信我们可以做到5分钟级别的崩溃预警，确保能在第一时间发现线上重大问题，尽快决定是通过发版还是动态热修复解决问题。
|
||||
|
||||
总结
|
||||
|
||||
今天，我讲了Android的两种崩溃，重点介绍了Native崩溃的捕获流程和一些难点。做一个高可用的崩溃收集SDK并不容易，它背后涉及Linux信号处理以及内存分配、汇编等知识，当你内功修炼得越深厚，学习这些底层知识就越得心应手。
|
||||
|
||||
接着，我们讨论了崩溃率应该如何去计算，崩溃率的高低跟应用时长、复杂度、收集SDK有关。不仅仅是崩溃率，我们还学习了目前ANR采集的方式以及遇到的问题，最后提出了异常率这一个新的稳定性监控指标。
|
||||
|
||||
作为技术人员，我们不应该盲目追求崩溃率这一个数字，应该以用户体验为先，如果强行去掩盖一些问题往往更加适得其反。我们不应该随意使用try catch去隐藏真正的问题，要从源头入手，了解崩溃的本质原因，保证后面的运行流程。在解决崩溃的过程，也要做到由点到面，不能只针对这个崩溃去解决，而应该要考虑这一类崩溃怎么解决和预防。
|
||||
|
||||
崩溃的治理是一个长期的过程，在专栏下一期我会重点讲一些分析应用崩溃的方法论。另外，你如果细心的话，可以发现，在这篇文章里，我放了很多的超链接，后面的文章里也会有类似的情况。所以，这就要求你在读完文章之后，或者读的过程中，如果对相关的背景信息或者概念不理解，就需要花些时间阅读周边文章。当然，如果看完还是没有明白，你也可以在留言区给我留言。
|
||||
|
||||
课后作业
|
||||
|
||||
Breakpad是一个跨平台的开源项目，今天的课后作业是使用Breakpad来捕获一个Native崩溃，并在留言区写下你今天学习和练习后的总结与思考。
|
||||
|
||||
当然我在专栏GitHub的Group里也为你提供了一个Sample方便你练习，如果你没使用过Breakpad的话，只需要直接编译即可。希望你可以通过一个简单的Native崩溃捕获过程，完成minidump文件的生成和解析，在实践中加深对Breakpad工作机制的认识。
|
||||
|
||||
我要再次敲黑板划重点了，请你一定要坚持参与我们的课后练习，从最开始就养成学完后立马动手操作的好习惯，这样才能让学习效率最大化，一步步接近“成为高手”的目标。当然了，认真提交作业的同学还有机会获得学习加油礼包。接下来，就看你的了！
|
||||
|
||||
欢迎你点击“请朋友读”，把今天的内容分享给好友，邀请他一起学习。最后别忘了在评论区提交今天的作业，我也为认真完成作业的同学准备了丰厚的“学习加油礼包”，期待与你一起切磋进步哦。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
241
专栏/Android开发高手课/02崩溃优化（下）：应用崩溃了，你应该如何去分析？.md
Normal file
241
专栏/Android开发高手课/02崩溃优化（下）：应用崩溃了，你应该如何去分析？.md
Normal file
@ -0,0 +1,241 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
02 崩溃优化（下）：应用崩溃了，你应该如何去分析？
|
||||
在侦探漫画《名侦探柯南》中，无论柯南走到哪里都会遇到新的“案件”，这也很像程序员的“日常”，我们每天工作也会遇到各种各样的疑难问题，“崩溃”就是其中比较常见的一种问题。
|
||||
|
||||
解决崩溃跟破案一样需要经验，我们分析的问题越多越熟练，定位问题就会越快越准。当然这里也有很多套路，比如对于“案发现场”我们应该留意哪些信息？怎样找到更多的“证人”和“线索”？“侦查案件”的一般流程是什么？对不同类型的“案件”分别应该使用什么样的调查方式？
|
||||
|
||||
“真相永远只有一个”，崩溃也并不可怕。通过今天的学习，希望你能成为代码届的名侦探柯南。
|
||||
|
||||
崩溃现场
|
||||
|
||||
崩溃现场是我们的“第一案发现场”，它保留着很多有价值的线索。在这里我们挖掘到的信息越多，下一步分析的方向就越清晰，而不是去靠盲目猜测。
|
||||
|
||||
操作系统是整个崩溃过程的“旁观者”，也是我们最重要的“证人”。一个好的崩溃捕获工具知道应该采集哪些系统信息，也知道在什么场景要深入挖掘哪些内容，从而可以更好地帮助我们解决问题。
|
||||
|
||||
接下来我们具体来看看在崩溃现场应该采集哪些信息。
|
||||
|
||||
1.崩溃信息
|
||||
|
||||
从崩溃的基本信息，我们可以对崩溃有初步的判断。
|
||||
|
||||
|
||||
进程名、线程名。崩溃的进程是前台进程还是后台进程，崩溃是不是发生在UI线程。
|
||||
|
||||
崩溃堆栈和类型。崩溃是属于Java崩溃、Native崩溃，还是ANR，对于不同类型的崩溃我们关注的点也不太一样。特别需要看崩溃堆栈的栈顶，看具体崩溃在系统的代码，还是我们自己的代码里面。
|
||||
|
||||
|
||||
Process Name: 'com.sample.crash'
|
||||
Thread Name: 'MyThread'
|
||||
|
||||
java.lang.NullPointerException
|
||||
at ...TestsActivity.crashInJava(TestsActivity.java:275)
|
||||
|
||||
|
||||
有时候我们除了崩溃的线程，还希望拿到其他关键的线程的日志。就像上面的例子，虽然是MyThread线程崩溃，但是我也希望可以知道主线程当前的调用栈。
|
||||
|
||||
2.系统信息
|
||||
|
||||
系统的信息有时候会带有一些关键的线索，对我们解决问题有非常大的帮助。
|
||||
|
||||
|
||||
Logcat。这里包括应用、系统的运行日志。由于系统权限问题，获取到的Logcat可能只包含与当前App相关的。其中系统的event logcat会记录App运行的一些基本情况，记录在文件/system/etc/event-log-tags中。
|
||||
|
||||
|
||||
system logcat:
|
||||
10-25 17:13:47.788 21430 21430 D dalvikvm: Trying to load lib ...
|
||||
event logcat:
|
||||
10-25 17:13:47.788 21430 21430 I am_on_resume_called: 生命周期
|
||||
10-25 17:13:47.788 21430 21430 I am_low_memory: 系统内存不足
|
||||
10-25 17:13:47.788 21430 21430 I am_destroy_activity: 销毁 Activty
|
||||
10-25 17:13:47.888 21430 21430 I am_anr: ANR 以及原因
|
||||
10-25 17:13:47.888 21430 21430 I am_kill: APP 被杀以及原因
|
||||
|
||||
|
||||
|
||||
机型、系统、厂商、CPU、ABI、Linux版本等。我们会采集多达几十个维度，这对后面讲到寻找共性问题会很有帮助。
|
||||
|
||||
设备状态：是否root、是否是模拟器。一些问题是由Xposed或多开软件造成，对这部分问题我们要区别对待。
|
||||
|
||||
|
||||
3.内存信息
|
||||
|
||||
OOM、ANR、虚拟内存耗尽等，很多崩溃都跟内存有直接关系。如果我们把用户的手机内存分为“2GB以下”和“2GB以上”两个桶，会发现“2GB以下”用户的崩溃率是“2GB以上”用户的几倍。
|
||||
|
||||
|
||||
系统剩余内存。关于系统内存状态，可以直接读取文件/proc/meminfo。当系统可用内存很小（低于MemTotal的 10%）时，OOM、大量GC、系统频繁自杀拉起等问题都非常容易出现。
|
||||
|
||||
应用使用内存。包括Java内存、RSS（Resident Set Size）、PSS（Proportional Set Size），我们可以得出应用本身内存的占用大小和分布。PSS和RSS通过/proc/self/smap计算，可以进一步得到例如apk、dex、so等更加详细的分类统计。
|
||||
|
||||
虚拟内存。虚拟内存可以通过/proc/self/status得到，通过/proc/self/maps文件可以得到具体的分布情况。有时候我们一般不太重视虚拟内存，但是很多类似OOM、tgkill等问题都是虚拟内存不足导致的。
|
||||
|
||||
|
||||
Name: com.sample.name // 进程名
|
||||
FDSize: 800 // 当前进程申请的文件句柄个数
|
||||
VmPeak: 3004628 kB // 当前进程的虚拟内存峰值大小
|
||||
VmSize: 2997032 kB // 当前进程的虚拟内存大小
|
||||
Threads: 600 // 当前进程包含的线程个数
|
||||
|
||||
|
||||
一般来说，对于32位进程，如果是32位的CPU，虚拟内存达到3GB就可能会引起内存申请失败的问题。如果是64位的CPU，虚拟内存一般在3～4GB之间。当然如果我们支持64位进程，虚拟内存就不会成为问题。Google Play要求 2019年8月一定要支持64位，在国内虽然支持64位的设备已经在90%以上了，但是商店都不支持区分CPU架构类型发布，普及起来需要更长的时间。
|
||||
|
||||
4.资源信息
|
||||
|
||||
有的时候我们会发现应用堆内存和设备内存都非常充足，还是会出现内存分配失败的情况，这跟资源泄漏可能有比较大的关系。
|
||||
|
||||
|
||||
文件句柄fd。文件句柄的限制可以通过/proc/self/limits获得，一般单个进程允许打开的最大文件句柄个数为1024。但是如果文件句柄超过800个就比较危险，需要将所有的fd以及对应的文件名输出到日志中，进一步排查是否出现了有文件或者线程的泄漏。
|
||||
|
||||
|
||||
opened files count 812:
|
||||
0 -> /dev/null
|
||||
1 -> /dev/log/main4
|
||||
2 -> /dev/binder
|
||||
3 -> /data/data/com.crash.sample/files/test.config
|
||||
...
|
||||
|
||||
|
||||
|
||||
线程数。当前线程数大小可以通过上面的status文件得到，一个线程可能就占2MB的虚拟内存，过多的线程会对虚拟内存和文件句柄带来压力。根据我的经验来说，如果线程数超过400个就比较危险。需要将所有的线程id以及对应的线程名输出到日志中，进一步排查是否出现了线程相关的问题。
|
||||
|
||||
|
||||
threads count 412:
|
||||
1820 com.sample.crashsdk
|
||||
1844 ReferenceQueueD
|
||||
1869 FinalizerDaemon
|
||||
...
|
||||
|
||||
|
||||
|
||||
JNI。使用JNI时，如果不注意很容易出现引用失效、引用爆表等一些崩溃。我们可以通过DumpReferenceTables统计JNI的引用表，进一步分析是否出现了JNI泄漏等问题。
|
||||
|
||||
|
||||
5.应用信息
|
||||
|
||||
除了系统，其实我们的应用更懂自己，可以留下很多相关的信息。
|
||||
|
||||
|
||||
崩溃场景。崩溃发生在哪个Activity或Fragment，发生在哪个业务中。
|
||||
|
||||
关键操作路径。不同于开发过程详细的打点日志，我们可以记录关键的用户操作路径，这对我们复现崩溃会有比较大的帮助。
|
||||
|
||||
其他自定义信息。不同的应用关心的重点可能不太一样，比如网易云音乐会关注当前播放的音乐，QQ浏览器会关注当前打开的网址或视频。此外例如运行时间、是否加载了补丁、是否是全新安装或升级等信息也非常重要。
|
||||
|
||||
|
||||
除了上面这些通用的信息外，针对特定的一些崩溃，我们可能还需要获取类似磁盘空间、电量、网络使用等特定信息。所以说一个好的崩溃捕获工具，会根据场景为我们采集足够多的信息，让我们有更多的线索去分析和定位问题。当然数据的采集需要注意用户隐私，做到足够强度的加密和脱敏。
|
||||
|
||||
崩溃分析
|
||||
|
||||
有了这么多现场信息之后，我们可以开始真正的“破案”之旅了。绝大部分的“案件”只要我们肯花功夫，最后都能真相大白。不要畏惧问题，经过耐心和细心地分析，总能敏锐地发现一些异常或关键点，并且还要敢于怀疑和验证。下面我重点给你介绍崩溃分析“三部曲”。
|
||||
|
||||
第一步：确定重点
|
||||
|
||||
确认和分析重点，关键在于在日志中找到重要的信息，对问题有一个大致判断。一般来说，我建议在确定重点这一步可以关注以下几点。
|
||||
|
||||
1. 确认严重程度。解决崩溃也要看性价比，我们优先解决Top崩溃或者对业务有重大影响，例如启动、支付过程的崩溃。我曾经有一次辛苦了几天解决了一个大的崩溃，但下个版本产品就把整个功能都删除了，这令我很崩溃。
|
||||
|
||||
2. 崩溃基本信息。确定崩溃的类型以及异常描述，对崩溃有大致的判断。一般来说，大部分的简单崩溃经过这一步已经可以得到结论。
|
||||
|
||||
|
||||
Java崩溃。Java崩溃类型比较明显，比如NullPointerException是空指针，OutOfMemoryError是资源不足，这个时候需要去进一步查看日志中的 “内存信息”和“资源信息”。
|
||||
|
||||
Native崩溃。需要观察signal、code、fault addr等内容，以及崩溃时Java的堆栈。关于各signal含义的介绍，你可以查看崩溃信号介绍。比较常见的是有SIGSEGV和SIGABRT，前者一般是由于空指针、非法指针造成，后者主要因为ANR和调用abort() 退出所导致。
|
||||
|
||||
ANR。我的经验是，先看看主线程的堆栈，是否是因为锁等待导致。接着看看ANR日志中iowait、CPU、GC、system server等信息，进一步确定是I/O问题，或是CPU竞争问题，还是由于大量GC导致卡死。
|
||||
|
||||
|
||||
3. Logcat。Logcat一般会存在一些有价值的线索，日志级别是Warning、Error的需要特别注意。从Logcat中我们可以看到当时系统的一些行为跟手机的状态，例如出现ANR时，会有“am_anr”；App被杀时，会有“am_kill”。不同的系统、厂商输出的日志有所差别，当从一条崩溃日志中无法看出问题的原因，或者得不到有用信息时，不要放弃，建议查看相同崩溃点下的更多崩溃日志。
|
||||
|
||||
4. 各个资源情况。结合崩溃的基本信息，我们接着看看是不是跟 “内存信息” 有关，是不是跟“资源信息”有关。比如是物理内存不足、虚拟内存不足，还是文件句柄fd泄漏了。
|
||||
|
||||
无论是资源文件还是Logcat，内存与线程相关的信息都需要特别注意，很多崩溃都是由于它们使用不当造成的。
|
||||
|
||||
第二步：查找共性
|
||||
|
||||
如果使用了上面的方法还是不能有效定位问题，我们可以尝试查找这类崩溃有没有什么共性。找到了共性，也就可以进一步找到差异，离解决问题也就更进一步。
|
||||
|
||||
机型、系统、ROM、厂商、ABI，这些采集到的系统信息都可以作为维度聚合，共性问题例如是不是因为安装了Xposed，是不是只出现在x86的手机，是不是只有三星这款机型，是不是只在Android 5.0的系统上。应用信息也可以作为维度来聚合，比如正在打开的链接、正在播放的视频、国家、地区等。
|
||||
|
||||
找到了共性，可以对你下一步复现问题有更明确的指引。
|
||||
|
||||
第三步：尝试复现
|
||||
|
||||
如果我们已经大概知道了崩溃的原因，为了进一步确认更多信息，就需要尝试复现崩溃。如果我们对崩溃完全没有头绪，也希望通过用户操作路径来尝试重现，然后再去分析崩溃原因。
|
||||
|
||||
“只要能本地复现，我就能解”，相信这是很多开发跟测试说过的话。有这样的底气主要是因为在稳定的复现路径上面，我们可以采用增加日志或使用Debugger、GDB等各种各样的手段或工具做进一步分析。
|
||||
|
||||
回想当时在开发Tinker的时候，我们遇到了各种各样的奇葩问题。比如某个厂商改了底层实现、新的Android系统实现有所更改，都需要去Google、翻源码，有时候还需要去抠厂商的ROM或手动刷ROM。这个痛苦的经历告诉我，很多疑难问题需要我们耐得住寂寞，反复猜测、反复发灰度、反复验证。
|
||||
|
||||
疑难问题：系统崩溃
|
||||
|
||||
系统崩溃常常令我们感到非常无助，它可能是某个Android版本的bug，也可能是某个厂商修改ROM导致。这种情况下的崩溃堆栈可能完全没有我们自己的代码，很难直接定位问题。针对这种疑难问题，我来谈谈我的解决思路。
|
||||
|
||||
1. 查找可能的原因。通过上面的共性归类，我们先看看是某个系统版本的问题，还是某个厂商特定ROM的问题。虽然崩溃日志可能没有我们自己的代码，但通过操作路径和日志，我们可以找到一些怀疑的点。
|
||||
|
||||
2. 尝试规避。查看可疑的代码调用，是否使用了不恰当的API，是否可以更换其他的实现方式规避。
|
||||
|
||||
3. Hook解决。这里分为Java Hook和Native Hook。以我最近解决的一个系统崩溃为例，我们发现线上出现一个Toast相关的系统崩溃，它只出现在Android 7.0的系统中，看起来是在Toast显示的时候窗口的token已经无效了。这有可能出现在Toast需要显示时，窗口已经销毁了。
|
||||
|
||||
android.view.WindowManager$BadTokenException:
|
||||
at android.view.ViewRootImpl.setView(ViewRootImpl.java)
|
||||
at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java)
|
||||
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java4)
|
||||
at android.widget.Toast$TN.handleShow(Toast.java)
|
||||
|
||||
|
||||
为什么Android 8.0的系统不会有这个问题？在查看Android 8.0的源码后我们发现有以下修改：
|
||||
|
||||
try {
|
||||
mWM.addView(mView, mParams);
|
||||
trySendAccessibilityEvent();
|
||||
} catch (WindowManager.BadTokenException e) {
|
||||
/* ignore */
|
||||
}
|
||||
|
||||
|
||||
考虑再三，我们决定参考Android 8.0的做法，直接catch住这个异常。这里的关键在于寻找Hook点，这个案例算是相对比较简单的。Toast里面有一个变量叫mTN，它的类型为handler，我们只需要代理它就可以实现捕获。
|
||||
|
||||
如果你做到了我上面说的这些，95%以上的崩溃都能解决或者规避，大部分的系统崩溃也是如此。当然总有一些疑难问题需要依赖到用户的真实环境，我们希望具备类似动态跟踪和调试的能力。专栏后面还会讲到xlog日志、远程诊断、动态分析等高级手段，可以帮助我们进一步调试线上疑难问题，敬请期待。
|
||||
|
||||
崩溃攻防是一个长期的过程，我们希望尽可能地提前预防崩溃的发生，将它消灭在萌芽阶段。这可能涉及我们应用的整个流程，包括人员的培训、编译检查、静态扫描工作，还有规范的测试、灰度、发布流程等。
|
||||
|
||||
而崩溃优化也不是孤立的，它跟我们后面讲到的内存、卡顿、I/O等内容都有关。可能等你学完整个课程后，再回头来看会有不同的理解。
|
||||
|
||||
总结
|
||||
|
||||
今天我们介绍了崩溃问题的一些分析方法、特殊技巧、以及疑难和常见问题的解决方法。当然崩溃分析要具体问题具体分析，不同类型的应用侧重点可能也有所不同，我们不能只局限在上面所说的一些方法。
|
||||
|
||||
讲讲自己的一些心得体会，在解决崩溃特别是一些疑难问题时，总会觉得患得患失。有时候解了一个问题，发现其他问题也跟“开心消消乐”一样消失了。有时候有些问题“解不出来郁闷，解出来更郁闷”，可能只是一个小的代码疏忽，换来了一个月的青春和很多根白头发。
|
||||
|
||||
课后作业
|
||||
|
||||
在崩溃的长期保卫战中，你肯定有一些经典的漂亮战役，希望可以拿出来跟其他同学分享。当然也会有一些百思不得其解的问题，今天的课后作业是分享你破解崩溃问题的思路和方法，总结一下通过Sample的练习有什么收获。
|
||||
|
||||
如果想向崩溃发起挑战，那么Top 20崩溃就是我们无法避免的对手。在这里面会有不少疑难的系统崩溃问题，TimeoutException就是其中比较经典的一个。
|
||||
|
||||
java.util.concurrent.TimeoutException:
|
||||
android.os.BinderProxy.finalize() timed out after 10 seconds
|
||||
at android.os.BinderProxy.destroy(Native Method)
|
||||
at android.os.BinderProxy.finalize(Binder.java:459)
|
||||
|
||||
|
||||
今天的Sample提供了一种“完全解决”TimeoutException的方法，主要是希望你可以更好地学习解决系统崩溃的套路。
|
||||
|
||||
1.通过源码分析。我们发现TimeoutException是由系统的FinalizerWatchdogDaemon抛出来的。
|
||||
|
||||
2.寻找可以规避的方法。尝试调用了它的Stop()方法，但是线上发现在Android 6.0之前会有线程同步问题。
|
||||
|
||||
3.寻找其他可以Hook的点。通过代码的依赖关系，发现一个取巧的Hook点。
|
||||
|
||||
最终代码你可以参考Sample的实现，但是建议只在灰度中使用。这里需要提的是，虽然有一些黑科技可以帮助我们解决某些问题，但对于黑科技的使用我们需要慎重，比如有的黑科技对保活进程频率没有做限制，可能会导致系统卡死。
|
||||
|
||||
欢迎你点击“请朋友读”，把今天的内容分享给好友，邀请他一起学习。最后别忘了在评论区提交今天的作业，我也为认真完成作业的同学准备了丰厚的“学习加油礼包”，期待与你一起切磋进步哦。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
196
专栏/Android开发高手课/03内存优化（上）：4GB内存时代，再谈内存优化.md
Normal file
196
专栏/Android开发高手课/03内存优化（上）：4GB内存时代，再谈内存优化.md
Normal file
@ -0,0 +1,196 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
03 内存优化（上）：4GB内存时代，再谈内存优化
|
||||
在写今天这篇文章前，我又翻了翻三年前我在WeMobileDev公众号写过的《Android内存优化杂谈》，今天再看，对里面的一句话更有感触：“我们并不能将内存优化中用到的所有技巧都一一说明，而且随着Android版本的更替，可能很多方法都会变的过时”。
|
||||
|
||||
三年过去了，4GB内存的手机都变成了主流。那内存优化是不是变得不重要了？如今有哪些技巧已经淘汰，而我们又要升级什么技能呢？
|
||||
|
||||
今天在4GB内存时代下，我就再来谈谈“内存优化”这个话题。
|
||||
|
||||
移动设备发展
|
||||
|
||||
Facebook有一个叫device-year-class的开源库，它会用年份来区分设备的性能。可以看到，2008年的手机只有可怜的140MB内存，而今年的华为Mate 20 Pro手机的内存已经达到了8GB。
|
||||
|
||||
|
||||
|
||||
内存看起来好像是我们都非常熟悉的概念，那请问问自己，手机内存和PC内存有哪什么差异呢？8GB内存是不是就一定会比4GB内存更好？我想可能很多人都不一定能回答正确。
|
||||
|
||||
手机运行内存（RAM）其实相当于我们的PC中的内存，是手机中作为App运行过程中临时性数据暂时存储的内存介质。不过考虑到体积和功耗，手机不使用PC的DDR内存，采用的是LPDDR RAM，全称是“低功耗双倍数据速率内存”，其中LP就是“Lower Power”低功耗的意思。
|
||||
|
||||
以LPDDR4为例，带宽 = 时钟频率 × 内存总线位数 ÷ 8，即1600 × 64 ÷ 8 = 12.8GB/s，因为是DDR内存是双倍速率，所以最后的带宽是12.8 × 2 = 25.6GB/s。
|
||||
|
||||
|
||||
|
||||
目前市面上的手机，主流的运行内存有LPDDR3、LPDDR4以及LPDDR4X。可以看出LPDDR4的性能要比LPDDR3高出一倍，而LPDDR4X相比LPDDR4工作电压更低，所以也比LPDDR4省电20%～40%。当然图中的数据是标准数据，不同的生成厂商会有一些低频或者高频的版本，性能方面高频要好于低频。
|
||||
|
||||
那手机内存是否越大越好呢？
|
||||
|
||||
如果一个手机使用的是4GB的LPDDR4X内存，另外一个使用的是6GB的LPDDR3内存，那么无疑选择4GB的运行内存手机要更加实用一些。
|
||||
|
||||
但是内存并不是一个孤立的概念，它跟操作系统、应用生态这些因素都有关。同样是1GB内存，使用Android 9.0系统会比Android 4.0系统流畅，使用更加封闭、规范的iOS系统也会比“狂野”的Android系统更好。今年发布的iPhone XR和iPhone XS使用的都是LPDDR4X的内存，不过它们分别只有3GB和4GB的大小。
|
||||
|
||||
内存问题
|
||||
|
||||
在前面所讲的崩溃分析中，我提到过“内存优化”是崩溃优化工作中非常重要的一部分。类似OOM，很多的“异常退出”其实都是由内存问题引起。那么内存究竟能引发什么样的问题呢？
|
||||
|
||||
1.两个问题
|
||||
|
||||
|
||||
|
||||
内存造成的第一个问题是异常。在前面的崩溃分析我提到过“异常率”，异常包括OOM、内存分配失败这些崩溃，也包括因为整体内存不足导致应用被杀死、设备重启等问题。不知道你平时是否在工作中注意过，如果我们把用户设备的内存分成2GB以下和2GB以上两部分，你可以试试分别计算他们的异常率或者崩溃率，看看差距会有多大。
|
||||
|
||||
内存造成的第二个问题是卡顿。Java内存不足会导致频繁GC，这个问题在Dalvik虚拟机会更加明显。而ART虚拟机在内存管理跟回收策略上都做大量优化，内存分配和GC效率相比提升了5～10倍。如果想具体测试GC的性能，例如暂停挂起时间、总耗时、GC吞吐量，我们可以通过发送SIGQUIT信号获得ANR日志。
|
||||
|
||||
adb shell kill -S QUIT PID
|
||||
adb pull /data/anr/traces.txt
|
||||
|
||||
|
||||
它包含一些ANR转储信息以及GC的详细性能信息。
|
||||
|
||||
sticky concurrent mark sweep paused: Sum: 5.491ms 99% C.I. 1.464ms-2.133ms Avg: 1.830ms Max: 2.133ms // GC 暂停时间
|
||||
|
||||
Total time spent in GC: 502.251ms // GC 总耗时
|
||||
Mean GC size throughput: 92MB/s // GC 吞吐量
|
||||
Mean GC object throughput: 1.54702e+06 objects/s
|
||||
|
||||
|
||||
另外我们还可以使用systrace来观察GC的性能耗时，这部分内容在专栏后面会详细讲到。
|
||||
|
||||
除了频繁GC造成卡顿之外，物理内存不足时系统会触发low memory killer机制，系统负载过高是造成卡顿的另外一个原因。
|
||||
|
||||
2.两个误区
|
||||
|
||||
除了内存引起的异常和卡顿，在日常做内存优化和架构设计时，很多同学还非常容易陷入两个误区之中。
|
||||
|
||||
误区一：内存占用越少越好
|
||||
|
||||
VSS、PSS、Java堆内存不足都可能会引起异常和卡顿。有些同学认为内存是洪水猛兽，占用越少应用的性能越好，这种认识在具体的优化过程中很容易“用力过猛”。
|
||||
|
||||
应用是否占用了过多的内存，跟设备、系统和当时情况有关，而不是300MB、400MB这样一个绝对的数值。当系统内存充足的时候，我们可以多用一些获得更好的性能。当系统内存不足的时候，希望可以做到“用时分配，及时释放”，就像下面这张图一样，当系统内存出现压力时，能够迅速释放各种缓存来减少系统压力。
|
||||
|
||||
|
||||
|
||||
现在手机已经有6GB和8GB的内存出现了，Android系统也希望去提升内存的利用率，因此我们有必要简单回顾一下Android Bitmap内存分配的变化。
|
||||
|
||||
|
||||
在Android 3.0之前，Bitmap对象放在Java堆，而像素数据是放在Native内存中。如果不手动调用recycle，Bitmap Native内存的回收完全依赖finalize函数回调，熟悉Java的同学应该知道，这个时机不太可控。
|
||||
|
||||
Android 3.0～Android 7.0将Bitmap对象和像素数据统一放到Java堆中，这样就算我们不调用recycle，Bitmap内存也会随着对象一起被回收。不过Bitmap是内存消耗的大户，把它的内存放到Java堆中似乎不是那么美妙。即使是最新的华为Mate 20，最大的Java堆限制也才到512MB，可能我的物理内存还有5GB，但是应用还是会因为Java堆内存不足导致OOM。Bitmap放到Java堆的另外一个问题会引起大量的GC，对系统内存也没有完全利用起来。
|
||||
|
||||
有没有一种实现，可以将Bitmap内存放到Native中，也可以做到和对象一起快速释放，同时GC的时候也能考虑这些内存防止被滥用？NativeAllocationRegistry可以一次满足你这三个要求，Android 8.0正是使用这个辅助回收Native内存的机制，来实现像素数据放到Native内存中。Android 8.0还新增了硬件位图Hardware Bitmap，它可以减少图片内存并提升绘制效率。
|
||||
|
||||
|
||||
误区二：Native内存不用管
|
||||
|
||||
虽然Android 8.0重新将Bitmap内存放回到Native中，那么我们是不是就可以随心所欲地使用图片呢？
|
||||
|
||||
答案当然是否定的。正如前面所说当系统物理内存不足时，lmk开始杀进程，从后台、桌面、服务、前台，直到手机重启。系统构想的场景就像下面这张图描述的一样，大家有条不絮的按照优先级排队等着被kill。
|
||||
|
||||
|
||||
|
||||
low memory killer的设计，是假定我们都遵守Android规范，但并没有考虑到中国国情。国内很多应用就像是打不死的小强，杀死一个拉起五个。频繁的杀死、拉起进程，又会导致system server卡死。当然在Android 8.0以后应用保活变得困难很多，但依然有一些方法可以突破。
|
||||
|
||||
既然讲到了将图片的内存放到Native中，我们比较熟悉的是Fresco图片库在Dalvik会把图片放到Native内存中。事实上在Android 5.0～Android 7.0，也能做到相同的效果，只是流程相对复杂一些。
|
||||
|
||||
步骤一：通过直接调用libandroid_runtime.so中Bitmap的构造函数，可以得到一张空的Bitmap对象，而它的内存是放到Native堆中。但是不同Android版本的实现有那么一点差异，这里都需要适配。
|
||||
|
||||
步骤二：通过系统的方法创建一张普通的Java Bitmap。
|
||||
|
||||
步骤三：将Java Bitmap的内容绘制到之前申请的空的Native Bitmap中。
|
||||
|
||||
步骤四：将申请的Java Bitmap释放，实现图片内存的“偷龙转凤”。
|
||||
|
||||
// 步骤一：申请一张空的 Native Bitmap
|
||||
Bitmap nativeBitmap = nativeCreateBitmap(dstWidth, dstHeight, nativeConfig, 22);
|
||||
|
||||
// 步骤二：申请一张普通的 Java Bitmap
|
||||
Bitmap srcBitmap = BitmapFactory.decodeResource(res, id);
|
||||
|
||||
// 步骤三：使用 Java Bitmap 将内容绘制到 Native Bitmap 中
|
||||
mNativeCanvas.setBitmap(nativeBitmap);
|
||||
mNativeCanvas.drawBitmap(srcBitmap, mSrcRect, mDstRect, mPaint);
|
||||
|
||||
// 步骤四：释放 Java Bitmap 内存
|
||||
srcBitmap.recycle();
|
||||
srcBitmap = null；
|
||||
|
||||
|
||||
虽然最终图片的内存的确是放到Native中了，不过这个“黑科技”有两个主要问题，一个是兼容性问题，另外一个是频繁申请释放Java Bitmap容易导致内存抖动。
|
||||
|
||||
测量方法
|
||||
|
||||
在日常开发中，有时候我们需要去排查应用程序中的内存问题。对于系统内存和应用内存的使用情况，你可以参考Android Developer中 《调查RAM使用情况》。
|
||||
|
||||
adb shell dumpsys meminfo <package_name|pid> [-d]
|
||||
|
||||
|
||||
1. Java内存分配
|
||||
|
||||
有些时候我们希望跟踪Java堆内存的使用情况，这个时候最常用的有Allocation Tracker和MAT这两个工具。
|
||||
|
||||
在我曾经写过的《Android内存申请分析》里，提到过Allocation Tracker的三个缺点。
|
||||
|
||||
|
||||
获取的信息过于分散，中间夹杂着不少其他的信息，很多信息不是应用申请的，可能需要进行不少查找才能定位到具体的问题。
|
||||
|
||||
跟Traceview一样，无法做到自动化分析，每次都需要开发者手工开始/结束，这对于某些问题的分析可能会造成不便，而且对于批量分析来说也比较困难。
|
||||
|
||||
虽然在Allocation Tracking的时候，不会对手机本身的运行造成过多的性能影响，但是在停止的时候，直到把数据dump出来之前，经常会把手机完全卡死，如果时间过长甚至会直接ANR。
|
||||
|
||||
|
||||
因此我们希望可以做到脱离Android Studio，实现一个自定义的“Allocation Tracker”，实现对象内存的自动化分析。通过这个工具可以获取所有对象的申请信息（大小、类型、堆栈等），可以找到一段时间内哪些对象占用了大量的内存。
|
||||
|
||||
但是这个方法需要考虑的兼容性问题会比较多，在Dalvik和ART中，Allocation Tracker的处理流程差异就非常大。下面是在Dalvik和ART中，Allocation Tacker的开启方式。
|
||||
|
||||
// dalvik
|
||||
bool dvmEnableAllocTracker()
|
||||
// art
|
||||
void setAllocTrackingEnabled()
|
||||
|
||||
|
||||
我们可以用自定义的“Allocation Tracker”来监控Java内存的监控，也可以拓展成实时监控Java内存泄漏。这方面经验不多的同学也不用担心，我在今天的“课后作业”提供了一个自定义的“Allocation Tracker”供你参考。不过任何一个工具如果只需要做到线下自动化测试，实现起来会相对简单，但想要移植到线上使用，那就要更加关注兼容性、稳定性和性能，付出的努力要远远高于实验室方案。
|
||||
|
||||
在课后作业中我们会提供一个简单的例子，在熟悉Android Studio中Profiler各种工具的实现原理后，我们就可以做各种各样的自定义改造，在后面的文章中也会有大量的例子供你参考和练习。
|
||||
|
||||
2. Native内存分配
|
||||
|
||||
Android的Native内存分析是一直做得非常不好，当然Google在近几个版本也做了大量努力，让整个过程更加简单。
|
||||
|
||||
首先Google之前将Valgrind弃用，建议我们使用Chromium的AddressSanitize 。遵循“谁最痛，谁最需要，谁优化”，所以Chromium出品了一大堆Native相关的工具。Android之前对AddressSanitize支持的不太好，需要root和一大堆的操作，但在Android 8.0之后，我们可以根据这个指南来使用AddressSanitize。目前AddressSanitize内存泄漏检测只支持x86_64 Linux和OS X系统，不过相信Google很快就可以支持直接在Android上进行检测了。
|
||||
|
||||
那我们有没有类似Allocation Tracker那样的Native内存分配工具呢？在这方面，Android目前的支持还不是太好，但Android Developer近来也补充了一些相关的文档，你可以参考《调试本地内存使用》。关于Native内存的问题，有两种方法，分别是Malloc调试和Malloc钩子。
|
||||
|
||||
Malloc调试可以帮助我们去调试Native内存的一些使用问题，例如堆破坏、内存泄漏、非法地址等。Android 8.0之后支持在非root的设备做Native内存调试，不过跟AddressSanitize一样，需要通过wrap.sh做包装。
|
||||
|
||||
adb shell setprop wrap.<APP> '"LIBC_DEBUG_MALLOC_OPTIONS=backtrace logwrapper"'
|
||||
|
||||
|
||||
Malloc钩子是在Android P之后，Android的libc支持拦截在程序执行期间发生的所有分配/释放调用，这样我们就可以构建出自定义的内存检测工具。
|
||||
|
||||
adb shell setprop wrap.<APP> '"LIBC_HOOKS_ENABLE=1"'
|
||||
|
||||
|
||||
但是在使用“Malloc调试”时，感觉整个App都会变卡，有时候还会产生ANR。如何在Android上对应用Native内存分配和泄漏做自动化分析，也是我最近想做的事情。据我了解，微信最近几个月在Native内存泄漏监控上也做了一些尝试，我会在专栏下一期具体讲讲。
|
||||
|
||||
总结
|
||||
|
||||
LPDDR5将在明年进入量产阶段，移动内存一直向着更大容量、更低功耗、更高带宽的方向发展。伴随内存的发展，内存优化的挑战和解决方案也不断变化。而内存优化又是性能优化重要的一部分，今天我讲到了很多的异常和卡顿都是因为内存不足引起的，并在最后讲述了如何在日常开发中分析和测量内存的使用情况。
|
||||
|
||||
一个好的开发者并不满足于做完需求，我们在设计方案的时候，还需要考虑要使用多少的内存，应该怎么去管理这些内存。在需求完成之后，我们也应该去回归需求的内存情况，是否存在使用不当的地方，是否出现内存泄漏。
|
||||
|
||||
课后作业
|
||||
|
||||
内存优化是一个非常“古老”的话题，大家在工作中也会遇到各种各样内存相关的问题。今天的课后作业是分享一下你在工作中遇到的内存问题，总结一下通过Sample的练习有什么收获。
|
||||
|
||||
在今天文章里我提到，希望可以脱离Android Studio实现一个自定义的Allocation Tracker，这样就可以将它用到自动化分析中。本期的Sample就提供了一个自定义的Allocation Tracker实现的示例，目前已经兼容到Android 8.1。你可以用它练习实现自动化的内存分析，有哪些对象占用了大量内存，以及它们是如何导致GC等。
|
||||
|
||||
欢迎你点击“请朋友读”，把今天的内容分享给好友，邀请他一起学习。最后别忘了在评论区提交今天的作业，我也为认真完成作业的同学准备了丰厚的“学习加油礼包”，期待与你一起切磋进步哦。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
194
专栏/Android开发高手课/04内存优化（下）：内存优化这件事，应该从哪里着手？.md
Normal file
194
专栏/Android开发高手课/04内存优化（下）：内存优化这件事，应该从哪里着手？.md
Normal file
@ -0,0 +1,194 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
04 内存优化（下）：内存优化这件事，应该从哪里着手？
|
||||
在掌握内存相关的背景知识后，下一步你肯定想着手开始优化内存的问题了。不过在真正开始做内存优化之前，需要先评估内存对应用性能的影响，我们可以通过崩溃中“异常退出” 和OOM的比例进行评估。另一方面，低内存设备更容易出现内存不足引起的异常和卡顿，我们也可以通过查看应用中用户的手机内存在2GB以下所占的比例来评估。
|
||||
|
||||
所以在优化前要先定好自己的目标，这一点非常关键。比如针对512MB的设备和针对2GB以上的设备，完全是两种不同的优化思路。如果我们面向东南亚、非洲用户，那对内存优化的标准就要变得更苛刻一些。
|
||||
|
||||
铺垫了这么多，下面我们就来看看内存优化都有哪些方法吧。
|
||||
|
||||
内存优化探讨
|
||||
|
||||
那要进行内存优化，应该从哪里着手呢？我通常会从设备分级、Bitmap优化和内存泄漏这三个方面入手。
|
||||
|
||||
1. 设备分级
|
||||
|
||||
相信你肯定遇到过，同一个应用在4GB内存的手机运行得非常流畅，但在1GB内存的手机就不一定可以做到，而且在系统空闲和繁忙的时候表现也不太一样。
|
||||
|
||||
内存优化首先需要根据设备环境来综合考虑，专栏上一期我提到过很多同学陷入的一个误区：“内存占用越少越好”。其实我们可以让高端设备使用更多的内存，做到针对设备性能的好坏使用不同的内存分配和回收策略。
|
||||
|
||||
当然这需要有一个良好的架构设计支撑，在架构设计时需要做到以下几点。
|
||||
|
||||
|
||||
设备分级。使用类似device-year-class的策略对设备分级，对于低端机用户可以关闭复杂的动画，或者是某些功能；使用565格式的图片，使用更小的缓存内存等。在现实环境下，不是每个用户的设备都跟我们的测试机一样高端，在开发过程我们要学会思考功能要不要对低端机开启、在系统资源吃紧的时候能不能做降级。
|
||||
|
||||
|
||||
下面我举一个例子。我们知道device-year-class会根据手机的内存、CPU核心数和频率等信息决定设备属于哪一个年份，这个示例表示对于2013年之后的设备可以使用复杂的动画，对于2010年之前的低端设备则不添加任何动画。
|
||||
|
||||
if (year >= 2013) {
|
||||
// Do advanced animation
|
||||
} else if (year >= 2010) {
|
||||
// Do simple animation
|
||||
} else {
|
||||
// Phone too slow, don't do any animations
|
||||
}
|
||||
|
||||
|
||||
|
||||
缓存管理。我们需要有一套统一的缓存管理机制，可以适当地使用内存；当“系统有难”时，也要义不容辞地归还。我们可以使用OnTrimMemory回调，根据不同的状态决定释放多少内存。对于大项目来说，可能存在几十上百个模块，统一缓存管理可以更好地监控每个模块的缓存大小。
|
||||
|
||||
进程模型。一个空的进程也会占用10MB的内存，而有些应用启动就有十几个进程，甚至有些应用已经从双进程保活升级到四进程保活，所以减少应用启动的进程数、减少常驻进程、有节操的保活，对低端机内存优化非常重要。
|
||||
|
||||
安装包大小。安装包中的代码、资源、图片以及so库的体积，跟它们占用的内存有很大的关系。一个80MB的应用很难在512MB内存的手机上流畅运行。这种情况我们需要考虑针对低端机用户推出4MB的轻量版本，例如Facebook Lite、今日头条极速版都是这个思路。
|
||||
|
||||
|
||||
安装包中的代码、图片、资源以及so库的大小跟内存究竟有哪些关系？你可以参考下面的这个表格。
|
||||
|
||||
|
||||
|
||||
2. Bitmap优化
|
||||
|
||||
Bitmap内存一般占应用总内存很大一部分，所以做内存优化永远无法避开图片内存这个“永恒主题”。
|
||||
|
||||
即使把所有的Bitmap都放到Native内存，并不代表图片内存问题就完全解决了，这样做只是提升了系统内存利用率，减少了GC带来的一些问题而已。
|
||||
|
||||
那我们回过头来看看，到底该如何优化图片内存呢？我给你介绍两种方法。
|
||||
|
||||
方法一，统一图片库。
|
||||
|
||||
图片内存优化的前提是收拢图片的调用，这样我们可以做整体的控制策略。例如低端机使用565格式、更加严格的缩放算法，可以使用Glide、Fresco或者采取自研都可以。而且需要进一步将所有Bitmap.createBitmap、BitmapFactory相关的接口也一并收拢。
|
||||
|
||||
方法二，统一监控。
|
||||
|
||||
在统一图片库后就非常容易监控Bitmap的使用情况了，这里主要有三点需要注意。
|
||||
|
||||
|
||||
大图片监控。我们需要注意某张图片内存占用是否过大，例如长宽远远大于View甚至是屏幕的长宽。在开发过程中，如果检测到不合规的图片使用，应该立即弹出对话框提示图片所在的Activity和堆栈，让开发同学更快发现并解决问题。在灰度和线上环境下可以将异常信息上报到后台，我们可以计算有多少比例的图片会超过屏幕的大小，也就是图片的“超宽率”。
|
||||
|
||||
重复图片监控。重复图片指的是Bitmap的像素数据完全一致，但是有多个不同的对象存在。这个监控不需要太多的样本量，一般只在内部使用。之前我实现过一个内存Hprof的分析工具，它可以自动将重复Bitmap的图片和引用链输出。下图是一个简单的例子，你可以看到两张图片的内容完全一样，通过解决这张重复图片可以节省1MB内存。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图片总内存。通过收拢图片使用，我们还可以统计应用所有图片占用的内存，这样在线上就可以按不同的系统、屏幕分辨率等维度去分析图片内存的占用情况。在OOM崩溃的时候，也可以把图片占用的总内存、Top N图片的内存都写到崩溃日志中，帮助我们排查问题。
|
||||
|
||||
|
||||
讲完设备分级和Bitmap优化，我们发现架构和监控需要两手抓，一个好的架构可以减少甚至避免我们犯错，而一个好的监控可以帮助我们及时发现问题。
|
||||
|
||||
3. 内存泄漏
|
||||
|
||||
内存泄漏简单来说就是没有回收不再使用的内存，排查和解决内存泄漏也是内存优化无法避开的工作之一。
|
||||
|
||||
内存泄漏主要分两种情况，一种是同一个对象泄漏，还有一种情况更加糟糕，就是每次都会泄漏新的对象，可能会出现几百上千个无用的对象。
|
||||
|
||||
很多内存泄漏都是框架设计不合理所导致，各种各样的单例满天飞，MVC中Controller的生命周期远远大于View。优秀的框架设计可以减少甚至避免程序员犯错，当然这不是一件容易的事情，所以我们还需要对内存泄漏建立持续的监控。
|
||||
|
||||
|
||||
Java内存泄漏。建立类似LeakCanary自动化检测方案，至少做到Activity和Fragment的泄漏检测。在开发过程，我们希望出现泄漏时可以弹出对话框，让开发者更加容易去发现和解决问题。内存泄漏监控放到线上并不容易，我们可以对生成的Hprof内存快照文件做一些优化，裁剪大部分图片对应的byte数组减少文件大小。比如一个100MB的文件裁剪后一般只剩下30MB左右，使用7zip压缩最后小于10MB，增加了文件上传的成功率。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
OOM监控。美团有一个Android内存泄露自动化链路分析组件Probe，它在发生OOM的时候生成Hprof内存快照，然后通过单独进程对这个文件做进一步的分析。不过在线上使用这个工具风险还是比较大，在崩溃的时候生成内存快照有可能会导致二次崩溃，而且部分手机生成Hprof快照可能会耗时几分钟，这对用户造成的体验影响会比较大。另外，部分OOM是因为虚拟内存不足导致，这块需要具体问题具体分析。
|
||||
|
||||
Native内存泄漏监控。上一期我讲到Malloc调试（Malloc Debug）和Malloc钩子（Malloc Hook）似乎还不是那么稳定。在WeMobileDev最近的一篇文章《微信Android终端内存优化实践》中，微信也做了一些其他方案上面的尝试。
|
||||
|
||||
针对无法重编so的情况，使用了PLT Hook拦截库的内存分配函数，其中PLT Hook是Native Hook的一种方案，后面我们还会讲到。然后重定向到我们自己的实现后记录分配的内存地址、大小、来源so库路径等信息，定期扫描分配与释放是否配对，对于不配对的分配输出我们记录的信息。
|
||||
|
||||
针对可重编的so情况，通过GCC的“-finstrument-functions”参数给所有函数插桩，桩中模拟调用栈入栈出栈操作；通过ld的“–wrap”参数拦截内存分配和释放函数，重定向到我们自己的实现后记录分配的内存地址、大小、来源so以及插桩记录的调用栈此刻的内容，定期扫描分配与释放是否配对，对于不配对的分配输出我们记录的信息。
|
||||
|
||||
|
||||
开发过程中内存泄漏排查可以使用Androd Profiler和MAT工具配合使用，而日常监控关键是成体系化，做到及时发现问题。
|
||||
|
||||
坦白地说，除了Java泄漏检测方案，目前OOM监控和Native内存泄漏监控都只能做到实验室自动化测试的水平。微信的Native监控方案也遇到一些兼容性的问题，如果想达到灰度和线上部署，需要考虑的细节会非常多。Native内存泄漏检测在iOS会简单一些，不过Google也在一直优化Native内存泄漏检测的性能和易用性，相信在未来的Android版本将会有很大改善。
|
||||
|
||||
内存监控
|
||||
|
||||
前面我也提了内存泄漏的监控存在一些性能的问题，一般只会对内部人员和极少部分的用户开启。在线上我们需要通过其他更有效的方式去监控内存相关的问题。
|
||||
|
||||
1. 采集方式
|
||||
|
||||
用户在前台的时候，可以每5分钟采集一次PSS、Java堆、图片总内存。我建议通过采样只统计部分用户，需要注意的是要按照用户抽样，而不是按次抽样。简单来说一个用户如果命中采集，那么在一天内都要持续采集数据。
|
||||
|
||||
2. 计算指标
|
||||
|
||||
通过上面的数据，我们可以计算下面一些内存指标。
|
||||
|
||||
内存异常率：可以反映内存占用的异常情况，如果出现新的内存使用不当或内存泄漏的场景，这个指标会有所上涨。其中PSS的值可以通过Debug.MemoryInfo拿到。
|
||||
|
||||
内存 UV 异常率 = PSS 超过 400MB 的 UV / 采集 UV
|
||||
|
||||
|
||||
触顶率：可以反映Java内存的使用情况，如果超过85%最大堆限制，GC会变得更加频繁，容易造成OOM和卡顿。
|
||||
|
||||
内存 UV 触顶率 = Java 堆占用超过最大堆限制的 85% 的 UV / 采集 UV
|
||||
|
||||
|
||||
其中是否触顶可以通过下面的方法计算得到。
|
||||
|
||||
long javaMax = runtime.maxMemory();
|
||||
long javaTotal = runtime.totalMemory();
|
||||
long javaUsed = javaTotal - runtime.freeMemory();
|
||||
// Java 内存使用超过最大限制的 85%
|
||||
float proportion = (float) javaUsed / javaMax;
|
||||
|
||||
|
||||
一般客户端只上报数据，所有计算都在后台处理，这样可以做到灵活多变。后台还可以计算平均PSS、平均Java内存、平均图片占用这些指标，它们可以反映内存的平均情况。通过平均内存和分区间内存占用这些指标，我们可以通过版本对比来监控有没有新增内存相关的问题。
|
||||
|
||||
|
||||
|
||||
因为上报了前台时间，我们还可以按照时间维度看应用内存的变化曲线。比如可以观察一下我们的应用是不是真正做到了“用时分配，及时释放”。如果需要，我们还可以实现按照场景来对比内存的占用。
|
||||
|
||||
3. GC监控
|
||||
|
||||
在实验室或者内部试用环境，我们也可以通过Debug.startAllocCounting来监控Java内存分配和GC的情况，需要注意的是这个选项对性能有一定的影响，虽然目前还可以使用，但已经被Android标记为deprecated。
|
||||
|
||||
通过监控，我们可以拿到内存分配的次数和大小，以及GC发起次数等信息。
|
||||
|
||||
long allocCount = Debug.getGlobalAllocCount();
|
||||
long allocSize = Debug.getGlobalAllocSize();
|
||||
long gcCount = Debug.getGlobalGcInvocationCount();
|
||||
|
||||
|
||||
上面的这些信息似乎不太容易定位问题，在Android 6.0之后系统可以拿到更加精准的GC信息。
|
||||
|
||||
// 运行的GC次数
|
||||
Debug.getRuntimeStat("art.gc.gc-count");
|
||||
// GC使用的总耗时，单位是毫秒
|
||||
Debug.getRuntimeStat("art.gc.gc-time");
|
||||
// 阻塞式GC的次数
|
||||
Debug.getRuntimeStat("art.gc.blocking-gc-count");
|
||||
// 阻塞式GC的总耗时
|
||||
Debug.getRuntimeStat("art.gc.blocking-gc-time");
|
||||
|
||||
|
||||
需要特别注意阻塞式GC的次数和耗时，因为它会暂停应用线程，可能导致应用发生卡顿。我们也可以更加细粒度地分应用场景统计，例如启动、进入朋友圈、进入聊天页面等关键场景。
|
||||
|
||||
总结
|
||||
|
||||
在具体进行内容优化前，我们首先要问清楚自己几个问题，比如我们要优化到什么目标、内存对我们造成了多少异常和卡顿。只有在明确了应用的现状和优化目标后，我们才能去进行下一步的操作。
|
||||
|
||||
在探讨了内存优化的思路时，针对不同的设备、设备不同的情况，我们希望可以给用户不同的体验。这里我主要讲到了关于Bitmap内存优化和内存泄漏排查、监控的一些方法。最后我提到了怎样在线上监控内存的异常情况，通常内存异常率、触顶率这些指标对我们很有帮助。
|
||||
|
||||
目前我们在Native泄漏分析上做的还不是那么完善，不过做优化工作的时候，我特别喜欢用演进的思路来看问题。用演进的思路来看，即使是Google， 在时机不成熟时也会做一些权衡和妥协。换到我们个人身上，等到时机成熟或者我们的能力达到了，就需要及时去还这些“技术债务”。
|
||||
|
||||
课后作业
|
||||
|
||||
看完我分享的内存优化的方法后，相信你也肯定还有很多好的思路和方法，今天的课后作业是分享一下你的内存优化“必杀技”，在留言区分享一下今天学习、练习的收获与心得。
|
||||
|
||||
在文中我提到Hprof文件裁剪和重复图片监控，这是很多应用目前都没有做的，而这两个功能也是微信的APM框架Matrix中内存监控的一部分。Matrix是我一年多前在微信负责的最后一个项目，也付出了不少心血，最近听说终于准备开源了。
|
||||
|
||||
那今天我们就先来练练手，尝试使用HAHA库快速判断内存中是否存在重复的图片，并且将这些重复图片的PNG、堆栈等信息输出。最终的实现可以通过向Sample发送Pull Request。
|
||||
|
||||
欢迎你点击“请朋友读”，把今天的内容分享给好友，邀请他一起学习。最后别忘了在评论区提交今天的作业，我也为认真完成作业的同学准备了丰厚的“学习加油礼包”，期待与你一起切磋进步哦。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
258
专栏/Android开发高手课/05卡顿优化（上）：你要掌握的卡顿分析方法.md
Normal file
258
专栏/Android开发高手课/05卡顿优化（上）：你要掌握的卡顿分析方法.md
Normal file
@ -0,0 +1,258 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
05 卡顿优化（上）：你要掌握的卡顿分析方法
|
||||
“我的后羿怎么动不了！”，在玩《王者荣耀》的时候最怕遇到团战时卡得跟幻灯片一样。对于应用也是这样，我们经常会听到用户抱怨：“这个应用启动怎么那么慢？”“滑动的时候怎么那么卡？”。
|
||||
|
||||
对用户来说，内存占用高、耗费电量、耗费流量可能不容易被发现，但是用户对卡顿特别敏感，很容易直观感受到。另一方面，对于开发者来说，卡顿问题又非常难以排查定位，产生的原因错综复杂，跟CPU、内存、磁盘I/O都可能有关，跟用户当时的系统环境也有很大关系。
|
||||
|
||||
那到底该如何定义卡顿呢？在本地有哪些工具可以帮助我们更好地发现和排查问题呢？这些工具之间的差异又是什么呢？今天我来帮你解决这些困惑。
|
||||
|
||||
基础知识
|
||||
|
||||
在具体讲卡顿工具前，你需要了解一些基础知识，它们主要都和CPU相关。造成卡顿的原因可能有千百种，不过最终都会反映到CPU时间上。我们可以把CPU时间分为两种：用户时间和系统时间。用户时间就是执行用户态应用程序代码所消耗的时间；系统时间就是执行内核态系统调用所消耗的时间，包括I/O、锁、中断以及其他系统调用的时间。
|
||||
|
||||
1. CPU性能
|
||||
|
||||
我们先来简单讲讲CPU的性能，考虑到功耗、体积这些因素，移动设备和PC的CPU会有不少的差异。但近年来，手机CPU的性能也在向PC快速靠拢，华为Mate 20的“麒麟980”和iPhone XS的“A12”已经率先使用领先PC的7纳米工艺。
|
||||
|
||||
评价一个CPU的性能，需要看主频、核心数、缓存等参数，具体表现出来的是计算能力和指令执行能力，也就是每秒执行的浮点计算数和每秒执行的指令数。
|
||||
|
||||
当然还要考虑到架构问题， “麒麟980”采用三级能效架构，2个2.6GHz主频的A76超大核 + 2个1.92GHz主频的A76大核 + 4个1.8GHz主频的A55小核。相比之下，“A12”使用2个性能核心 + 4个能效核心的架构，这样设计主要是为了在日常低负荷工作时，使用低频核心更加节省电量。在开发过程中，我们可以通过下面的方法获得设备的CPU信息。
|
||||
|
||||
// 获取 CPU 核心数
|
||||
cat /sys/devices/system/cpu/possible
|
||||
|
||||
// 获取某个 CPU 的频率
|
||||
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
|
||||
|
||||
|
||||
随着机器学习的兴起，现代芯片不仅带有强大的GPU，还配备了专门为神经网络计算打造的NPU（Neural network Processing Unit）。“A12”就使用了八核心的NPU，每秒可执行五万亿次运算。从CPU到GPU再到AI芯片，随着手机CPU 整体性能的飞跃，医疗诊断、图像超清化等一些AI应用场景也可以在移动端更好地落地。最近边缘计算也越来越多的被提及，我们希望可以更大程度地利用移动端的计算能力来降低高昂的服务器成本。
|
||||
|
||||
也因此在开发过程中，我们需要根据设备CPU性能来“看菜下饭”，例如线程池使用线程数根据CPU的核心数，一些高级的AI功能只在主频比较高或者带有NPU的设备开启。
|
||||
|
||||
拓展了那么多再回到前面我讲的CPU时间，也就是用户时间和系统时间。当出现卡顿问题的时候，应该怎么去区分究竟是我们代码的问题，还是系统的问题？用户时间和系统时间可以给我们哪些线索？这里还要集合两个非常重要的指标，可以帮助我们做判断。
|
||||
|
||||
2. 卡顿问题分析指标
|
||||
|
||||
出现卡顿问题后，首先我们应该查看CPU的使用率。怎么查呢？我们可以通过/proc/stat得到整个系统的CPU使用情况，通过/proc/[pid]/stat可以得到某个进程的CPU使用情况。
|
||||
|
||||
关于stat文件各个属性的含义和CPU使用率的计算，你可以阅读《Linux环境下进程的CPU占用率》和Linux文档。其中比较重要的字段有：
|
||||
|
||||
proc/self/stat:
|
||||
utime: 用户时间，反应用户代码执行的耗时
|
||||
stime: 系统时间，反应系统调用执行的耗时
|
||||
majorFaults：需要硬盘拷贝的缺页次数
|
||||
minorFaults：无需硬盘拷贝的缺页次数
|
||||
|
||||
|
||||
如果CPU使用率长期大于60% ，表示系统处于繁忙状态，就需要进一步分析用户时间和系统时间的比例。对于普通应用程序，系统时间不会长期高于30%，如果超过这个值，我们就应该进一步检查是I/O过多，还是其他的系统调用问题。
|
||||
|
||||
Android是站在Linux巨人的肩膀上，虽然做了不少修改也砍掉了一些工具，但还是保留了很多有用的工具可以协助我们更容易地排查问题，这里我给你介绍几个常用的命令。例如，top命令可以帮助我们查看哪个进程是CPU的消耗大户；vmstat命令可以实时动态监视操作系统的虚拟内存和CPU活动；strace命令可以跟踪某个进程中所有的系统调用。
|
||||
|
||||
除了CPU的使用率，我们还需要查看CPU饱和度。CPU饱和度反映的是线程排队等待CPU的情况，也就是CPU的负载情况。
|
||||
|
||||
CPU饱和度首先会跟应用的线程数有关，如果启动的线程过多，容易导致系统不断地切换执行的线程，把大量的时间浪费在上下文切换，我们知道每一次CPU上下文切换都需要刷新寄存器和计数器，至少需要几十纳秒的时间。
|
||||
|
||||
我们可以通过使用vmstat命令或者/proc/[pid]/schedstat文件来查看CPU上下文切换次数，这里特别需要注意nr_involuntary_switches被动切换的次数。
|
||||
|
||||
proc/self/sched:
|
||||
nr_voluntary_switches：
|
||||
主动上下文切换次数，因为线程无法获取所需资源导致上下文切换，最普遍的是IO。
|
||||
nr_involuntary_switches：
|
||||
被动上下文切换次数，线程被系统强制调度导致上下文切换，例如大量线程在抢占CPU。
|
||||
se.statistics.iowait_count：IO 等待的次数
|
||||
se.statistics.iowait_sum： IO 等待的时间
|
||||
|
||||
|
||||
此外也可以通过uptime命令可以检查CPU在1分钟、5分钟和15分钟内的平均负载。比如一个4核的CPU，如果当前平均负载是8，这意味着每个CPU上有一个线程在运行，还有一个线程在等待。一般平均负载建议控制在“0.7 × 核数”以内。
|
||||
|
||||
00:02:39 up 7 days, 46 min, 0 users,
|
||||
load average: 13.91, 14.70, 14.32
|
||||
|
||||
|
||||
另外一个会影响CPU饱和度的是线程优先级，线程优先级会影响Android系统的调度策略，它主要由nice和cgroup类型共同决定。nice值越低，抢占CPU时间片的能力越强。当CPU空闲时，线程的优先级对执行效率的影响并不会特别明显，但在CPU繁忙的时候，线程调度会对执行效率有非常大的影响。
|
||||
|
||||
|
||||
|
||||
关于线程优先级，你需要注意是否存在高优先级的线程空等低优先级线程，例如主线程等待某个后台线程的锁。从应用程序的角度来看，无论是用户时间、系统时间，还是等待CPU的调度，都是程序运行花费的时间。
|
||||
|
||||
Android卡顿排查工具
|
||||
|
||||
可能你会觉得按照上面各种Linux命令组合来排查问题太麻烦了，有没有更简单的、图形化的操作界面呢？Traceview和systrace都是我们比较熟悉的排查卡顿的工具，从实现上这些工具分为两个流派。
|
||||
|
||||
第一个流派是instrument。获取一段时间内所有函数的调用过程，可以通过分析这段时间内的函数调用流程，再进一步分析待优化的点。
|
||||
|
||||
第二个流派是sample。有选择性或者采用抽样的方式观察某些函数调用过程，可以通过这些有限的信息推测出流程中的可疑点，然后再继续细化分析。
|
||||
|
||||
这两种流派有什么差异？我们在什么场景应该选择哪种合适的工具呢？还有没有其他有用的工具可以使用呢？下面我们一一来看。
|
||||
|
||||
1. Traceview
|
||||
|
||||
Traceview是我第一个使用的性能分析工具，也是吐槽的比较多的工具。它利用Android Runtime函数调用的event事件，将函数运行的耗时和调用关系写入trace文件中。
|
||||
|
||||
由此可见，Traceview属于instrument类型，它可以用来查看整个过程有哪些函数调用，但是工具本身带来的性能开销过大，有时无法反映真实的情况。比如一个函数本身的耗时是1秒，开启Traceview后可能会变成5秒，而且这些函数的耗时变化并不是成比例放大。
|
||||
|
||||
在Android 5.0之后，新增了startMethodTracingSampling方法，可以使用基于样本的方式进行分析，以减少分析对运行时的性能影响。新增了sample类型后，就需要我们在开销和信息丰富度之间做好权衡。
|
||||
|
||||
|
||||
|
||||
无论是哪种的Traceview对release包支持的都不太好，例如无法反混淆。其实trace文件的格式十分简单，之前曾经写个一个小工具，支持通过mapping文件反混淆trace。
|
||||
|
||||
2. Nanoscope
|
||||
|
||||
那在instrument类型的性能分析工具里，有没有性能损耗比较小的呢？
|
||||
|
||||
答案是有的，Uber开源的Nanoscope就能达到这个效果。它的实现原理是直接修改Android虚拟机源码，在ArtMethod执行入口和执行结束位置增加埋点代码，将所有的信息先写到内存，等到trace结束后才统一生成结果文件。
|
||||
|
||||
在使用过程可以明显感觉到应用不会因为开启Nanoscope而感到卡顿，但是trace结束生成结果文件这一步需要的时间比较长。另一方面它可以支持分析任意一个应用，可用于做竞品分析。
|
||||
|
||||
但是它也有不少限制：
|
||||
|
||||
|
||||
需要自己刷ROM，并且当前只支持Nexus 6P，或者采用其提供的x86架构的模拟器。
|
||||
|
||||
默认只支持主线程采集，其他线程需要代码手动设置。考虑到内存大小的限制，每个线程的内存数组只能支持大约20秒左右的时间段。
|
||||
|
||||
|
||||
Uber写了一系列自动化脚本协助整个流程，使用起来还算简单。Nanoscope作为基本没有性能损耗的instrument工具，它非常适合做启动耗时的自动化分析。
|
||||
|
||||
Nanoscope生成的是符合Chrome tracing规范的HTML文件。我们可以通过脚本来实现两个功能：
|
||||
|
||||
第一个是反混淆。通过mapping自动反混淆结果文件。
|
||||
|
||||
第二个是自动化分析。传入相同的起点和终点，实现两个结果文件的diff，自动分析差异点。
|
||||
|
||||
这样我们可以每天定期去跑自动化启动测试，查看是否存在新增的耗时点。我们有时候为了实现更多定制化功能或者拿到更加丰富的信息，这个时候不得不使用定制ROM的方式。而Nanoscope恰恰是一个很好的工具，可以让我们更方便地实现定制ROM，在后面启动和I/O优化里我还会提到更多类似的案例。
|
||||
|
||||
3. systrace
|
||||
|
||||
systrace是Android 4.1新增的性能分析工具。我通常使用systrace跟踪系统的I/O操作、CPU负载、Surface渲染、GC等事件。
|
||||
|
||||
systrace利用了Linux的ftrace调试工具，相当于在系统各个关键位置都添加了一些性能探针，也就是在代码里加了一些性能监控的埋点。Android在ftrace的基础上封装了atrace，并增加了更多特有的探针，例如Graphics、Activity Manager、Dalvik VM、System Server等。
|
||||
|
||||
systrace工具只能监控特定系统调用的耗时情况，所以它是属于sample类型，而且性能开销非常低。但是它不支持应用程序代码的耗时分析，所以在使用时有一些局限性。
|
||||
|
||||
由于系统预留了Trace.beginSection接口来监听应用程序的调用耗时，那我们有没有办法在systrace上面自动增加应用程序的耗时分析呢？
|
||||
|
||||
划重点了，我们可以通过编译时给每个函数插桩的方式来实现，也就是在重要函数的入口和出口分别增加Trace.beginSection和Trace.endSection。当然出于性能的考虑，我们会过滤大部分指令数比较少的函数，这样就实现了在systrace基础上增加应用程序耗时的监控。通过这样方式的好处有：
|
||||
|
||||
|
||||
可以看到整个流程系统和应用程序的调用流程。包括系统关键线程的函数调用，例如渲染耗时、线程锁，GC耗时等。
|
||||
|
||||
性能损耗可以接受。由于过滤了大部分的短函数，而且没有放大I/O，所以整个运行耗时不到原来的两倍，基本可以反映真实情况。
|
||||
|
||||
|
||||
systrace生成的也是HTML格式的结果，我们利用跟Nanoscope相似方式实现对反混淆的支持。
|
||||
|
||||
|
||||
|
||||
4. Simpleperf
|
||||
|
||||
那如果我们想分析Native函数的调用，上面的三个工具都不能满足这个需求。
|
||||
|
||||
Android 5.0新增了Simpleperf性能分析工具，它利用CPU的性能监控单元（PMU）提供的硬件perf事件。使用Simpleperf可以看到所有的Native代码的耗时，有时候一些Android系统库的调用对分析问题有比较大的帮助，例如加载dex、verify class的耗时等。
|
||||
|
||||
Simpleperf同时封装了systrace的监控功能，通过Android几个版本的优化，现在Simpleperf比较友好地支持Java代码的性能分析。具体来说分几个阶段：
|
||||
|
||||
第一个阶段：在Android M和以前，Simpleperf不支持Java代码分析。
|
||||
|
||||
第二个阶段：在Android O和以前，需要手动指定编译OAT文件。
|
||||
|
||||
第三个阶段：在Android P和以后，无需做任何事情，Simpleperf就可以支持Java代码分析。
|
||||
|
||||
从这个过程可以看到Google还是比较看重这个功能，在Android Studio 3.2也在Profiler中直接支持Simpleperf。
|
||||
|
||||
顾名思义，从名字就能看出Simpleperf是属于sample类型，它的性能开销非常低，使用火焰图展示分析结果。
|
||||
|
||||
|
||||
|
||||
目前除了Nanoscope之外的三个工具都只支持debugable的应用程序，如果想测试release包，需要将测试机器root。对于这个限制，我们在实践中会专门打出debugable的测试包，然后自己实现针对mapping的反混淆功能。其中Simpleperf的反混淆比较难实现，因为在函数聚合后会抛弃参数，无法直接对生成的HTML文件做处理。当然我们也可以根据各个工具的实现思路，自己重新打造一套支持非debugable的自动化测试工具。
|
||||
|
||||
选择哪种工具，需要看具体的场景。我来汇总一下，如果需要分析Native代码的耗时，可以选择Simpleperf；如果想分析系统调用，可以选择systrace；如果想分析整个程序执行流程的耗时，可以选择Traceview或者插桩版本的systrace。
|
||||
|
||||
可视化方法
|
||||
|
||||
随着Android版本的演进，Google不仅提供了更多的性能分析工具，而且也在慢慢优化现有工具的体验，使功能更强大、使用门槛更低。而Android Studio则肩负另外一个重任，那就是让开发者使用起来更加简单的，图形界面也更加直观。
|
||||
|
||||
在Android Studio 3.2的Profiler中直接集成了几种性能分析工具，其中：
|
||||
|
||||
|
||||
Sample Java Methods的功能类似于Traceview的sample类型。
|
||||
|
||||
Trace Java Methods的功能类似于Traceview的instrument类型。
|
||||
|
||||
Trace System Calls的功能类似于systrace。
|
||||
|
||||
SampleNative (API Level 26+) 的功能类似于Simpleperf。
|
||||
|
||||
|
||||
坦白来说，Profiler界面在某些方面不如这些工具自带的界面，支持配置的参数也不如命令行，不过Profiler的确大大降低了开发者的使用门槛。
|
||||
|
||||
另外一个比较大的变化是分析结果的展示方式，这些分析工具都支持了Call Chart和Flame Chart两种展示方式。下面我来讲讲这两种展示方式适合的场景。
|
||||
|
||||
1. Call Chart
|
||||
|
||||
Call Chart是Traceview和systrace默认使用的展示方式。它按照应用程序的函数执行顺序来展示，适合用于分析整个流程的调用。举一个最简单的例子，A函数调用B函数，B函数调用C函数，循环三次，就得到了下面的Call Chart。
|
||||
|
||||
|
||||
|
||||
Call Chart就像给应用程序做一个心电图，我们可以看到在这一段时间内，各个线程的具体工作，比如是否存在线程间的锁、主线程是否存在长时间的I/O操作、是否存在空闲等。
|
||||
|
||||
2. Flame Chart
|
||||
|
||||
Flame Chart也就是大名鼎鼎的火焰图。它跟Call Chart不同的是，Flame Chart以一个全局的视野来看待一段时间的调用分布，它就像给应用程序拍X光片，可以很自然地把时间和空间两个维度上的信息融合在一张图上。上面函数调用的例子，换成火焰图的展示结果如下。
|
||||
|
||||
|
||||
|
||||
当我们不想知道应用程序的整个调用流程，只想直观看出哪些代码路径花费的CPU时间较多时，火焰图就是一个非常好的选择。例如，之前我的一个反序列化实现非常耗时，通过火焰图发现耗时最多的是大量Java字符串的创建和拷贝，通过将核心实现转为Native，最终使性能提升了很多倍。
|
||||
|
||||
火焰图还可以使用在各种各样的维度，例如内存、I/O的分析。有些内存可能非常缓慢地泄漏，通过一个内存的火焰图，我们就知道哪些路径申请的内存最多，有了火焰图我们根本不需要分析源代码，也不需要分析整个流程。
|
||||
|
||||
最后我想说，每个工具都可以生成不同的展示方式，我们需要根据不同的使用场景选择合适的方式。
|
||||
|
||||
总结
|
||||
|
||||
在写今天的文章，也就是分析卡顿的基础知识和四种Android卡顿排查工具时，我越发觉得底层基础知识的重要性。Android底层基于Linux内核，像systrace、Simpleperf也是利用Linux提供的机制实现，因此学习一些Linux的基础知识，对于理解这些工具的工作原理以及排查性能问题，都有很大帮助。
|
||||
|
||||
另一方面，虽然很多大厂有专门的性能优化团队，但我觉得鼓励和培养团队里的每一个人都去关注性能问题更加重要。我们在使用性能工具的同时，要学会思考，应该知道它们的原理和局限性。更进一步来说，你还可以尝试去为这些工具做一些优化，从而实现更加完善的方案。
|
||||
|
||||
课后作业
|
||||
|
||||
当发生ANR的时候，Android系统会打印CPU相关的信息到日志中，使用的是ProcessCpuTracker.java。但是这样好像并没有权限可以拿到其他应用进程的CPU信息，那能不能换一个思路？
|
||||
|
||||
当发现应用的某个进程CPU使用率比较高的时候，可以通过下面几个文件检查该进程下各个线程的CPU使用率，继而统计出该进程各个线程的时间占比。
|
||||
|
||||
/proc/[pid]/stat // 进程CPU使用情况
|
||||
/proc/[pid]/task/[tid]/stat // 进程下面各个线程的CPU使用情况
|
||||
/proc/[pid]/sched // 进程CPU调度相关
|
||||
/proc/loadavg // 系统平均负载，uptime命令对应文件
|
||||
|
||||
|
||||
如果线程销毁了，它的CPU运行信息也会被删除，所以我们一般只会计算某一段时间内CPU使用率。下面是计算5秒间隔内一个Sample进程的CPU使用示例。有的时候可能找不到耗时的线程，有可能是有大量生命周期很短的线程，这个时候可以把时间间隔缩短来看看。
|
||||
|
||||
usage: CPU usage 5000ms(from 23:23:33.000 to 23:23:38.000):
|
||||
System TOTAL: 2.1% user + 16% kernel + 9.2% iowait + 0.2% irq + 0.1% softirq + 72% idle
|
||||
CPU Core: 8
|
||||
Load Average: 8.74 / 7.74 / 7.36
|
||||
|
||||
Process:com.sample.app
|
||||
50% 23468/com.sample.app(S): 11% user + 38% kernel faults:4965
|
||||
|
||||
Threads:
|
||||
43% 23493/singleThread(R): 6.5% user + 36% kernel faults：3094
|
||||
3.2% 23485/RenderThread(S): 2.1% user + 1% kernel faults：329
|
||||
0.3% 23468/.sample.app(S): 0.3% user + 0% kernel faults：6
|
||||
0.3% 23479/HeapTaskDaemon(S): 0.3% user + 0% kernel faults：982
|
||||
...
|
||||
|
||||
|
||||
今天的课后作业是，请你在留言区解读一下上面的信息，分享一下你认为这个示例的瓶颈在什么地方。之后能不能更进一步，自己动手写一个工具，得到一段时间内上面的这些统计信息。同样最终的实现可以通过向Sample发送Pull Request。
|
||||
|
||||
欢迎你点击“请朋友读”，把今天的内容分享给好友，邀请他一起学习。最后别忘了在评论区提交今天的作业，我也为认真完成作业的同学准备了丰厚的“学习加油礼包”，期待与你一起切磋进步哦。
|
||||
|
||||
|
||||
|
||||
|
||||
182
专栏/Android开发高手课/06卡顿优化（下）：如何监控应用卡顿？.md
Normal file
182
专栏/Android开发高手课/06卡顿优化（下）：如何监控应用卡顿？.md
Normal file
@ -0,0 +1,182 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
06 卡顿优化（下）：如何监控应用卡顿？
|
||||
“我在秒杀iPhone XS的支付页面卡了3秒，最后没抢到”，用户嘶声力竭地反馈了一个卡顿问题。
|
||||
|
||||
“莫慌莫慌”，等我打开Android Studio， 用上一讲学到的几个工具分析一下就知道原因了。
|
||||
|
||||
“咦，在我这里整个支付过程丝滑般流畅”。这个经历让我明白，卡顿跟崩溃一样需要“现场信息”。因为卡顿的产生也是依赖很多因素，比如用户的系统版本、CPU负载、网络环境、应用数据等。
|
||||
|
||||
脱离这个现场，我们本地难以复现，也就很难去解决问题。但是卡顿又非常影响用户体验的，特别是发生在启动、聊天、支付这些关键场景，那我们应该如何去监控线上的卡顿问题，并且保留足够多的现场信息协助我们排查解决问题呢？
|
||||
|
||||
卡顿监控
|
||||
|
||||
前面我讲过监控ANR的方法，不过也提到两个问题：一个是高版本的系统没有权限读取系统的ANR日志；另一个是ANR太依赖系统实现，我们无法灵活控制参数，例如我觉得主线程卡顿3秒用户已经不太能忍受，而默认参数只能监控至少5秒以上的卡顿。
|
||||
|
||||
所以现实情况就要求我们需要采用其他的方式来监控是否出现卡顿问题，并且针对特定场景还要监控其他特定的指标。
|
||||
|
||||
1. 消息队列
|
||||
|
||||
我设计的第一套监控卡顿的方案是基于消息队列实现，通过替换Looper的Printer实现。在2013年的时候，我写过一个名为WxPerformanceTool的性能监控工具，其中耗时监控就使用了这个方法。后面这个工具在腾讯公共组件做了内部开源，还获得了2013年的年度十佳组件。
|
||||
|
||||
|
||||
|
||||
还没庆祝完，很快就有同事跟我吐槽一个问题：线上开启了这个监控模块，快速滑动时平均帧率起码降低5帧。我通过Traceview一看，发现是因为上面图中所示的大量字符串拼接导致性能损耗严重。
|
||||
|
||||
后来很快又想到了另外一个方案，可以通过一个监控线程，每隔1秒向主线程消息队列的头部插入一条空消息。假设1秒后这个消息并没有被主线程消费掉，说明阻塞消息运行的时间在0～1秒之间。换句话说，如果我们需要监控3秒卡顿，那在第4次轮询中头部消息依然没有被消费的话，就可以确定主线程出现了一次3秒以上的卡顿。
|
||||
|
||||
|
||||
|
||||
这个方案也存在一定的误差，那就是发送空消息的间隔时间。但这个间隔时间也不能太小，因为监控线程和主线程处理空消息都会带来一些性能损耗，但基本影响不大。
|
||||
|
||||
2. 插桩
|
||||
|
||||
不过在使用了一段时间之后，我感觉还是有那么一点不爽。基于消息队列的卡顿监控并不准确，正在运行的函数有可能并不是真正耗时的函数。这是为什么呢？
|
||||
|
||||
我画张图解释起来就清楚了。我们假设一个消息循环里面顺序执行了A、B、C三个函数，当整个消息执行超过3秒时，因为函数A和B已经执行完毕，我们只能得到的正在执行的函数C的堆栈，事实上它可能并不耗时。
|
||||
|
||||
|
||||
|
||||
不过对于线上大数据来说，因为函数A和B相对比较耗时，所以抓取到它们的概率会更大一些，通过后台聚合后捕获到函数A和B的卡顿日志会更多一些。
|
||||
|
||||
这也是我们线上目前依然使用基于消息队列的方法，但是肯定希望可以做到跟Traceview一样，可以拿到整个卡顿过程所有运行函数的耗时，就像下面图中的结果，可以明确知道其实函数A和B才是造成卡顿的主要原因。
|
||||
|
||||
|
||||
|
||||
既然这样，那我们能否直接利用Android Runtime函数调用的回调事件，做一个自定义的Traceview++呢？
|
||||
|
||||
答案是可以的，但是需要使用Inline Hook技术。我们可以实现类似Nanoscope先写内存的方案，但考虑到兼容性问题，这套方案并没有用到线上。
|
||||
|
||||
对于大体量的应用，稳定性是第一考虑因素。那如果在编译过程插桩，兼容性问题肯定是OK的。上一讲讲到systrace可以通过插桩自动生成Trace Tag，我们一样也可以在函数入口和出口加入耗时监控的代码，但是需要考虑的细节有很多。
|
||||
|
||||
|
||||
避免方法数暴增。在函数的入口和出口应该插入相同的函数，在编译时提前给代码中每个方法分配一个独立的ID作为参数。
|
||||
|
||||
过滤简单的函数。过滤一些类似直接return、i++这样的简单函数，并且支持黑名单配置。对一些调用非常频繁的函数，需要添加到黑名单中来降低整个方案对性能的损耗。
|
||||
|
||||
|
||||
|
||||
|
||||
基于性能的考虑，线上只会监控主线程的耗时。微信的Matrix使用的就是这个方案，因为做了大量的优化，所以最终安装包体积只增大1～2%，平均帧率下降也在2帧以内。虽然插桩方案对性能的影响总体还可以接受，但只会在灰度包使用。
|
||||
|
||||
插桩方案看起来美好，它也有自己的短板，那就是只能监控应用内自身的函数耗时，无法监控系统的函数调用，整个堆栈看起来好像“缺失了”一部分。
|
||||
|
||||
3. Profilo
|
||||
|
||||
2018年3月，Facebook开源了一个叫Profilo的库，它收集了各大方案的优点，令我眼前一亮。具体来说有以下几点：
|
||||
|
||||
第一，集成atrace功能。ftrace所有性能埋点数据都会通过trace_marker文件写入内核缓冲区，Profilo通过PLT Hook拦截了写入操作，选择部分关心的事件做分析。这样所有systrace的探针我们都可以拿到，例如四大组件生命周期、锁等待时间、类校验、GC时间等。
|
||||
|
||||
不过大部分的atrace事件都比较笼统，从事件“B|pid|activityStart”，我们并不知道具体是哪个Activity的创建。同样我们可以统计GC相关事件的耗时，但是也不知道为什么发生了这次GC。
|
||||
|
||||
|
||||
|
||||
第二，快速获取Java堆栈。很多同学有一个误区，觉得在某个线程不断地获取主线程堆栈是不耗时的。但是事实上获取堆栈的代价是巨大的，它要暂停主线程的运行。
|
||||
|
||||
Profilo的实现非常精妙，它实现类似Native崩溃捕捉的方式快速获取Java堆栈，通过间隔发送SIGPROF信号，整个过程如下图所示。
|
||||
|
||||
|
||||
|
||||
Signal Handler捕获到信号后，拿取到当前正在执行的Thread，通过Thread对象可以获取当前线程的ManagedStack，ManagedStack是一个单链表，它保存了当前的ShadowFrame或者QuickFrame栈指针，先依次遍历ManagedStack链表，然后遍历其内部的ShadowFrame或者QuickFrame还原一个可读的调用栈，从而unwind出当前的Java堆栈。通过这种方式，可以实现线程一边继续跑步，我们还可以帮它做检查，而且耗时基本忽略不计。代码可以参照：Profilo::unwind和StackVisitor::WalkStack。
|
||||
|
||||
不用插桩、性能基本没有影响、捕捉信息还全，那Profilo不就是完美的化身吗？当然由于它利用了大量的黑科技，兼容性是需要注意的问题。它内部实现有大量函数的Hook，unwind也需要强依赖Android Runtime实现。Facebook已经将Profilo投入到线上使用，但由于目前Profilo快速获取堆栈功能依然不支持Android 8.0和Android 9.0，鉴于稳定性问题，建议采取抽样部分用户的方式来开启该功能。
|
||||
|
||||
先小结一下，不管我们使用哪种卡顿监控方法，最后我们都可以得到卡顿时的堆栈和当时CPU运行的一些信息。大部分的卡顿问题都比较好定位，例如主线程执行一个耗时任务、读一个非常大的文件或者是执行网络请求等。
|
||||
|
||||
其他监控
|
||||
|
||||
除了主线程的耗时过长之外，我们还有哪些卡顿问题需要关注呢？
|
||||
|
||||
Android Vitals是Google Play官方的性能监控服务，涉及卡顿相关的监控有ANR、启动、帧率三个。尤其是ANR监控，我们应该经常的来看看，主要是Google自己是有权限可以准确监控和上报ANR。
|
||||
|
||||
对于启动和帧率，Android Vitals只是上报了应用的区间分布，但是不能归纳出问题。这也是我们做性能优化时比较迷惑的一点，即使发现整体的帧率比过去降低了5帧，也并不知道是哪里造成的，还是要花很大的力气去做二次排查。
|
||||
|
||||
|
||||
|
||||
能不能做到跟崩溃、卡顿一样，直接给我一个堆栈，告诉我就是因为这里写的不好导致帧率下降了5帧。退一步说，如果做不到直接告诉我堆栈，能不能告诉我是因为聊天这个页面导致的帧率下降，让我缩小二次排查的范围。
|
||||
|
||||
1. 帧率
|
||||
|
||||
业界都使用Choreographer来监控应用的帧率。跟卡顿不同的是，需要排除掉页面没有操作的情况，我们应该只在界面存在绘制的时候才做统计。
|
||||
|
||||
那么如何监听界面是否存在绘制行为呢？可以通过addOnDrawListener实现。
|
||||
|
||||
getWindow().getDecorView().getViewTreeObserver().addOnDrawListener
|
||||
|
||||
|
||||
我们经常用平均帧率来衡量界面流畅度，但事实上电影的帧率才24帧，用户对于应用的平均帧率是40帧还是50帧并不一定可以感受出来。对于用户来说，感觉最明显的是连续丢帧情况，Android Vitals将连续丢帧超过700毫秒定义为冻帧，也就是连续丢帧42帧以上。
|
||||
|
||||
因此，我们可以统计更有价值的冻帧率。冻帧率就是计算发生冻帧时间在所有时间的占比。出现丢帧的时候，我们可以获取当前的页面信息、View信息和操作路径上报后台，降低二次排查的难度。
|
||||
|
||||
正如下图一样，我们还可以按照Activity、Fragment或者某个操作定义场景，通过细化不同场景的平均帧率和冻帧率，进一步细化问题排查的范围。
|
||||
|
||||
|
||||
|
||||
2. 生命周期监控
|
||||
|
||||
Activity、Service、Receiver组件生命周期的耗时和调用次数也是我们重点关注的性能问题。例如Activity的onCreate()不应该超过1秒，不然会影响用户看到页面的时间。Service和Receiver虽然是后台组件，不过它们生命周期也是占用主线程的，也是我们需要关注的问题。
|
||||
|
||||
对于组件生命周期我们应该采用更严格地监控，可以全量上报。在后台我们可以看到各个组件各个生命周期的启动时间和启动次数。
|
||||
|
||||
|
||||
|
||||
有一次我们发现有两个Service的启动次数是其他的10倍，经过排查发现是因为频繁的互相拉起导致。Receiver也是这样，而且它们都需要经过System Server。曾经有一个日志上报模块通过Broadcast来做跨进程通信，每秒发送几千次请求，导致系统System Server卡死。所以说每个组件各个生命周期的调用次数也是非常有参考价值的指标。
|
||||
|
||||
除了四大组件的生命周期，我们还需要监控各个进程生命周期的启动次数和耗时。通过下面的数据，我们可以看出某些进程是否频繁地拉起。
|
||||
|
||||
|
||||
|
||||
对于生命周期的监控实现，我们可以利用插件化技术Hook的方式。但是Android P之后，我还是不太推荐你使用这种方式。我更推荐使用编译时插桩的方式，后面我会讲到Aspect、ASM和ReDex三种插桩技术的实现，敬请期待。
|
||||
|
||||
3. 线程监控
|
||||
|
||||
Java线程管理是很多应用非常头痛的事情，应用启动过程就已经创建了几十上百个线程。而且大部分的线程都没有经过线程池管理，都在自由自在地狂奔着。
|
||||
|
||||
另外一方面某些线程优先级或者活跃度比较高，占用了过多的CPU。这会降低主线程UI响应能力，我们需要特别针对这些线程做重点的优化。
|
||||
|
||||
对于Java线程，总的来说我会监控以下两点。
|
||||
|
||||
|
||||
线程数量。需要监控线程数量的多少，以及创建线程的方式。例如有没有使用我们特有的线程池，这块可以通过got hook线程的nativeCreate()函数。主要用于进行线程收敛，也就是减少线程数量。
|
||||
|
||||
线程时间。监控线程的用户时间utime、系统时间stime和优先级。主要是看哪些线程utime+stime时间比较多，占用了过多的CPU。正如上一期“每课一练”所提到的，可能有一些线程因为生命周期很短导致很难发现，这里我们需要结合线程创建监控。
|
||||
|
||||
|
||||
|
||||
|
||||
看到这里可能有同学会比较困惑，卡顿优化的主题就是监控吗？导致卡顿的原因会有很多，比如函数非常耗时、I/O非常慢、线程间的竞争或者锁等。其实很多时候卡顿问题并不难解决，相较解决来说，更困难的是如何快速发现这些卡顿点，以及通过更多的辅助信息找到真正的卡顿原因。
|
||||
|
||||
就跟在本地使用各种卡顿分析工具一样，卡顿优化的难点在于如何把它们移植到线上，以最少的性能代价获得更加丰富的卡顿信息。当然某些卡顿问题可能是I/O、存储或者网络引发的，后面会还有专门的内容来讲这些问题的优化方法。
|
||||
|
||||
总结
|
||||
|
||||
今天我们学习了卡顿监控的几种方法。随着技术的深入，我们发现了旧方案的一些缺点，通过不断地迭代和演进，寻找更好的方案。
|
||||
|
||||
Facebook的Profilo实现了快速获取Java堆栈，其实它参考的是JVM的AsyncGetCallTrace思路，然后适配Android Runtime的实现。systrace使用的是Linux的ftrace，Simpleperf参考了Linux的perf工具。还是熟悉的配方，还是熟悉的味道，我们很多创新性的东西，其实还是基于Java和Linux十年前的产物。
|
||||
|
||||
还是回到我在专栏开篇词说过的，切记不要浮躁，多了解和学习一些底层的技术，对我们的成长会有很大帮助。日常开发中我们也不能只满足于完成需求就可以了，在实现上应该学会多去思考内存、卡顿这些影响性能的点，我们比别人多想一些、多做一些，自己的进步自然也会更快一些。
|
||||
|
||||
课后作业
|
||||
|
||||
看完我分享的卡顿优化的方法后，相信你也肯定还有很多好的思路和方法，今天的课后作业是分享一下你的卡顿优化的“必杀技”，在留言区分享一下今天学习、练习的收获与心得。
|
||||
|
||||
课后练习
|
||||
|
||||
我在上一期中提到过Linux的ftrace机制，而systrace正是利用这个系统机制实现的。而Profilo更是通过一些黑科技，实现了一个可以用于线上的“systrace”。那它究竟是怎么实现的呢？
|
||||
|
||||
通过今天这个Sample，你可以学习到它的实现思路。当你对这些底层机制足够熟悉的时候，可能就不局限在本地使用，而是可以将它们搬到线上了。
|
||||
|
||||
当然，为了能更好地理解这个Sample，可能你还需要补充一些ftrace和atrace相关的背景知识。你会发现这些的确都是Linux十年前的一些知识，但时至今日它们依然非常有用。
|
||||
|
||||
1.ftrace 简介、ftrace使用（上）、frace使用（下）。
|
||||
|
||||
2.atrace介绍、atrace实现。
|
||||
|
||||
欢迎你点击“请朋友读”，把今天的内容分享给好友，邀请他一起学习。最后别忘了在评论区提交今天的作业，我也为认真完成作业的同学准备了丰厚的“学习加油礼包”，期待与你一起切磋进步哦。
|
||||
|
||||
|
||||
|
||||
|
||||
239
专栏/Android开发高手课/06补充篇卡顿优化：卡顿现场与卡顿分析.md
Normal file
239
专栏/Android开发高手课/06补充篇卡顿优化：卡顿现场与卡顿分析.md
Normal file
@ -0,0 +1,239 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
06补充篇 卡顿优化：卡顿现场与卡顿分析
|
||||
我们使用上一期所讲的插桩或者Profilo的方案，可以得到卡顿过程所有运行函数的耗时。在大部分情况下，这几种方案的确非常好用，可以让我们更加明确真正的卡顿点在哪里。
|
||||
|
||||
但是，你肯定还遇到过很多莫名其妙的卡顿，比如读取1KB的文件、读取很小的asset资源或者只是简单的创建一个目录。
|
||||
|
||||
为什么看起来这么简单的操作也会耗费那么长的时间呢？那我们如何通过收集更加丰富的卡顿现场信息，进一步定位并排查问题呢？
|
||||
|
||||
卡顿现场
|
||||
|
||||
我先来举一个线上曾经发现的卡顿例子，下面是它的具体耗时信息。
|
||||
|
||||
|
||||
|
||||
从图上看，Activity的onCreate函数耗时达到3秒，而其中Lottie动画中openNonAsset函数耗时竟然将近2秒。尽管是读取一个30KB的资源文件，但是它的耗时真的会有那么长吗？
|
||||
|
||||
今天我们就一起来分析这个问题吧。
|
||||
|
||||
1. Java实现
|
||||
|
||||
进一步分析openNonAsset相关源码的时候发现，AssetManager内部有大量的synchronized锁。首先我怀疑还是锁的问题，接下来需要把卡顿时各个线程的状态以及堆栈收集起来做进一步分析。
|
||||
|
||||
步骤一：获得Java线程状态
|
||||
|
||||
通过Thread的getState方法可以获取线程状态，当时主线程果然是BLOCKED状态。
|
||||
|
||||
什么是BLOCKED状态呢？当线程无法获取下面代码中的object对象锁的时候，线程就会进入BLOCKED状态。
|
||||
|
||||
// 线程等待获取object对象锁
|
||||
synchronized (object) {
|
||||
dosomething();
|
||||
}
|
||||
|
||||
|
||||
WAITING、TIME_WAITING和BLOCKED都是需要特别注意的状态。很多同学可能对BLOCKED和WAITING这两种状态感到比较困惑，BLOCKED是指线程正在等待获取锁，对应的是下面代码中的情况一；WAITING是指线程正在等待其他线程的“唤醒动作”，对应的是代码中的情况二。
|
||||
|
||||
synchronized (object) { // 情况一：在这里卡住 --> BLOCKED
|
||||
object.wait(); // 情况二：在这里卡住 --> WAITING
|
||||
}
|
||||
|
||||
|
||||
不过当一个线程进入WAITING状态时，它不仅会释放CPU资源，还会将持有的object锁也同时释放。对Java各个线程状态的定义以及转换等更多介绍，你可以参考Thread.State和《Java线程Dump分析》。
|
||||
|
||||
步骤二：获得所有线程堆栈
|
||||
|
||||
接着我们在Java层通过Thread.getAllStackTraces()进一步拿所有线程的堆栈，希望知道具体是因为哪个线程导致主线程的BLOCKED。
|
||||
|
||||
需要注意的是在Android 7.0，getAllStackTraces是不会返回主线程的堆栈的。通过分析收集上来的卡顿日志，我们发现跟AssetManager相关的线程有下面这个。
|
||||
|
||||
"BackgroundHandler" RUNNABLE
|
||||
at android.content.res.AssetManager.list
|
||||
at com.sample.business.init.listZipFiles
|
||||
|
||||
|
||||
通过查看AssetManager.list的确发现是使用了同一个synchronized锁，而list函数需要遍历整个目录，耗时会比较久。
|
||||
|
||||
public String[] list(String path) throws IOException {
|
||||
synchronized (this) {
|
||||
ensureValidLocked();
|
||||
return nativeList(mObject, path);
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
另外一方面，“BackgroundHandler”线程属于低优先级后台线程，这也是我们前面文章提到的不良现象，也就是主线程等待低优先级的后台线程。
|
||||
|
||||
2. SIGQUIT信号实现
|
||||
|
||||
Java实现的方案看起来非常不错，也帮助我们发现了卡顿的原因。不过在我们印象中，似乎ANR日志的信息更加丰富，那我们能不能直接用ANR日志呢？
|
||||
|
||||
比如下面的例子，它的信息的确非常全，所有线程的状态、CPU时间片、优先级、堆栈和锁的信息应有尽有。其中utm代表utime，HZ代表CPU的时钟频率，将utime转换为毫秒的公式是“time * 1000/HZ”。例子中utm=218，也就是218*1000⁄100=2180毫秒。
|
||||
|
||||
// 线程名称; 优先级; 线程id; 线程状态
|
||||
"main" prio=5 tid=1 Suspended
|
||||
// 线程组; 线程suspend计数; 线程debug suspend计数;
|
||||
| group="main" sCount=1 dsCount=0 obj=0x74746000 self=0xf4827400
|
||||
// 线程native id; 进程优先级; 调度者优先级;
|
||||
| sysTid=28661 nice=-4 cgrp=default sched=0/0 handle=0xf72cbbec
|
||||
// native线程状态; 调度者状态; 用户时间utime; 系统时间stime; 调度的CPU
|
||||
| state=D schedstat=( 3137222937 94427228 5819 ) utm=218 stm=95 core=2 HZ=100
|
||||
// stack相关信息
|
||||
| stack=0xff717000-0xff719000 stackSize=8MB
|
||||
|
||||
|
||||
疑问一：Native线程状态
|
||||
|
||||
细心的你可能会发现，为什么上面的ANR日志中“main”线程的状态是Suspended？想了一下，Java线程中的6种状态中并不存在Suspended状态啊。
|
||||
|
||||
事实上，Suspended代表的是Native线程状态。怎么理解呢？在Android里面Java线程的运行都委托于一个Linux标准线程pthread来运行，而Android里运行的线程可以分成两种，一种是Attach到虚拟机的，一种是没有Attach到虚拟机的，在虚拟机管理的线程都是托管的线程，所以本质上Java线程的状态其实是Native线程的一种映射。
|
||||
|
||||
不同的Android版本Native线程的状态不太一样，例如Android 9.0就定义了27种线程状态，它能更加明确地区分线程当前所处的情况。关于Java线程状态、Native线程状态转换，你可以参考thread_state.h和Thread_nativeGetStatus。
|
||||
|
||||
|
||||
|
||||
我们可以看到Native线程状态的确更加丰富，例如将TIMED_WAITING拆分成TimedWaiting和Sleeping两种场景，而WAITING更是细化到十几种场景等，这对我们分析特定场景问题的时候会有非常大的帮助。
|
||||
|
||||
疑问二：获得ANR日志
|
||||
|
||||
虽然ANR日志信息非常丰富，那问题又来了，如何拿到卡顿时的ANR日志呢？
|
||||
|
||||
我们可以利用系统ANR的生成机制，具体步骤是：
|
||||
|
||||
第一步：当监控到主线程卡顿时，主动向系统发送SIGQUIT信号。
|
||||
|
||||
第二步：等待/data/anr/traces.txt文件生成。
|
||||
|
||||
第三步：文件生成以后进行上报。
|
||||
|
||||
通过ANR日志，我们可以直接看到主线程的锁是由“BackgroundHandler”线程持有。相比之下通过getAllStackTraces方法，我们只能通过一个一个线程进行猜测。
|
||||
|
||||
// 堆栈相关信息
|
||||
at android.content.res.AssetManager.open(AssetManager.java:311)
|
||||
- waiting to lock <0x41ddc798> (android.content.res.AssetManager) held by tid=66 (BackgroundHandler)
|
||||
at android.content.res.AssetManager.open(AssetManager.java:289)
|
||||
|
||||
|
||||
线程间的死锁和热锁分析是一个非常有意思的话题，很多情况分析起来也比较困难，例如我们只能拿到Java代码中使用的锁，而且有部分类型锁的持有并不会表现在堆栈上面。对这部分内容感兴趣，想再深入一下的同学，可以认真看一下这两篇文章：《Java线程Dump分析》、《手Q Android线程死锁监控与自动化分析实践》。
|
||||
|
||||
3. Hook实现
|
||||
|
||||
用SIGQUIT信号量获取ANR日志，从而拿到所有线程的各种信息，这套方案看起来很美好。但事实上，它存在这几个问题：
|
||||
|
||||
|
||||
可行性。正如我在崩溃分析所说的一样，很多高版本系统已经没有权限读取/data/anr/traces.txt文件。
|
||||
|
||||
性能。获取所有线程堆栈以及各种信息非常耗时，对于卡顿场景不一定合适，它可能会进一步加剧用户的卡顿。
|
||||
|
||||
|
||||
那有什么方法既可以拿到ANR日志，整个过程又不会影响用户的体验呢？
|
||||
|
||||
再回想一下，在崩溃分析的时候我们就讲过一种获得所有线程堆栈的方法。它通过下面几个步骤实现。
|
||||
|
||||
|
||||
通过libart.so、dlsym调用ThreadList::ForEach方法，拿到所有的Native线程对象。
|
||||
|
||||
遍历线程对象列表，调用Thread::DumpState方法。
|
||||
|
||||
|
||||
它基本模拟了系统打印ANR日志的流程，但是因为整个过程使用了一些黑科技，可能会造成线上崩溃。
|
||||
|
||||
为了兼容性考虑，我们会通过fork子进程方式实现，这样即使子进程崩溃了也不会影响我们主进程的运行。这样还可以带来另外一个非常大的好处，获取所有线程堆栈这个过程可以做到完全不卡我们主进程。
|
||||
|
||||
但使用fork进程会导致进程号改变，源码中通过/proc/self方式获取的一些信息都会失败（错误的拿了子进程的信息，而子进程只有一个线程），例如state、schedstat、utm、stm、core等。不过问题也不大，这些信息可以通过指定/proc/[父进程id]的方式重新获取。
|
||||
|
||||
"main" prio=7 tid=1 Native
|
||||
| group="" sCount=0 dsCount=0 obj=0x74e99000 self=0xb8811080
|
||||
| sysTid=23023 nice=-4 cgrp=default sched=0/0 handle=0xb6fccbec
|
||||
| state=? schedstat=( 0 0 0 ) utm=0 stm=0 core=0 HZ=100
|
||||
| stack=0xbe4dd000-0xbe4df000 stackSize=8MB
|
||||
| held mutexes=
|
||||
|
||||
|
||||
总的来说，通过Hook方式我们实现了一套“无损”获取所有Java线程堆栈与详细信息的方法。为了降低上报数据量，只有主线程的Java线程状态是WAITING、TIME_WAITING或者BLOCKED的时候，才会进一步使用这个“大杀器”。
|
||||
|
||||
4. 现场信息
|
||||
|
||||
现在再来看，这样一份我们自己构造的“ANR日志”是不是已经是收集崩溃现场信息的完全体了？它似乎缺少了我们常见的头部信息，例如进程CPU使用率、GC相关的信息。
|
||||
|
||||
正如第6期文章开头所说的一样，卡顿跟崩溃一样是需要“现场信息”的。能不能进一步让卡顿的“现场信息”的比系统ANR日志更加丰富？我们可以进一步增加这些信息：
|
||||
|
||||
|
||||
CPU使用率和调度信息。参考第5期的课后练习，我们可以得到系统CPU使用率、负载、各线程的CPU使用率以及I/O调度等信息。
|
||||
|
||||
内存相关信息。我们可以添加系统总内存、可用内存以及应用各个进程的内存等信息。如果开启了Debug.startAllocCounting或者atrace，还可以增加GC相关的信息。
|
||||
|
||||
I/O和网络相关。我们还可以把卡顿期间所有的I/O和网络操作的详细信息也一并收集，这部分内容会在后面进一步展开。
|
||||
|
||||
|
||||
在Android 8.0后，Android虚拟机终于支持了JVM的JVMTI机制。Profiler中内存采集等很多模块也切换到这个机制中实现，后面我会邀请“学习委员”鹏飞给你讲讲JVMTI机制与应用。使用它可以获得的信息非常丰富，包括内存申请、线程创建、类加载、GC等，有大量的应用场景。
|
||||
|
||||
最后我们还可以利用崩溃分析中的一些思路，例如添加用户操作路径等信息，这样我们可以得到一份比系统ANR更加丰富的卡顿日志，这对我们解决某些疑难的卡顿问题会更有帮助。
|
||||
|
||||
卡顿分析
|
||||
|
||||
在客户端捕获卡顿之后，最后数据需要上传到后台统一分析。我们可以对数据做什么样的处理？应该关注哪些指标？
|
||||
|
||||
1. 卡顿率
|
||||
|
||||
如果把主线程卡顿超过3秒定义为一个卡顿问题，类似崩溃，我们会先评估卡顿问题的影响面，也就是UV卡顿率。
|
||||
|
||||
UV 卡顿率 = 发生过卡顿 UV / 开启卡顿采集 UV
|
||||
|
||||
|
||||
因为卡顿问题一般都是抽样上报，采样规则跟内存相似，都应该按照人来抽样。一个用户如果命中采集，那么在一天内都会持续的采集数据。
|
||||
|
||||
UV卡顿率可以评估卡顿的影响范围，但对于低端机器来说比较难去优化卡顿的问题。如果想评估卡顿的严重程度，我们可以使用PV卡顿率。
|
||||
|
||||
PV 卡顿率 = 发生过卡顿 PV / 启动采集 PV
|
||||
|
||||
|
||||
需要注意的是，对于命中采集PV卡顿率的用户，每次启动都需要上报作为分母。
|
||||
|
||||
2. 卡顿树
|
||||
|
||||
发生卡顿时，我们会把CPU使用率和负载相关信息也添加到卡顿日志中。虽然采取了抽样策略，但每天的日志量还是达到十万级别。这么大的日志量，如果简单采用堆栈聚合日志，会发现有几百上千种卡顿类型，很难看出重点。
|
||||
|
||||
我们能不能实现卡顿的火焰图，在一张图里就可以看到卡顿的整体信息？
|
||||
|
||||
这里我非常推荐卡顿树的做法，对于超过3秒的卡顿，具体是4秒还是10秒，这涉及手机性能和当时的环境。我们决定抛弃具体的耗时，只按照相同堆栈出现的比例来聚合。这样我们从一棵树上面，就可以看到哪些堆栈出现的卡顿问题最多，它下面又存在的哪些分支。
|
||||
|
||||
|
||||
|
||||
我们的精力是有限的，一般会优先去解决Top的卡顿问题。采用卡顿树的聚合方式，可以从全盘的角度看到Top卡顿问题的各个分支情况，帮助我们快速找到关键的卡顿点。
|
||||
|
||||
总结
|
||||
|
||||
今天我们从一个简单的卡顿问题出发，一步一步演进出解决这个问题的三种思路。其中Java实现的方案是大部分同学首先想到的方案，它虽然简单稳定，不过存在信息不全、性能差等问题。
|
||||
|
||||
可能很多同学认为问题可以解决就算万事大吉了，但我并不这样认为。我们应该继续敲问自己，如果再出现类似的问题，我们是否也可以采用相同的方法去解决？这个方案的代价对用户会带来多大的影响，是否还有优化的空间？
|
||||
|
||||
只有这样，才会出现文中的方案二和方案三，解决方案才会一直向前演进，做得越来越好。也只有这样，我们才能在追求卓越的过程中快速进步。
|
||||
|
||||
课后作业
|
||||
|
||||
线程等待、死锁和热锁在应用中都是非常普遍的，今天的课后作业是分享一下你的产品中是否出现过这些问题，又是如何解决的？请你在留言区分享一下今天学习、练习的收获与心得。
|
||||
|
||||
我在评论中发现很多同学对监控Thread的创建比较感兴趣，今天我们的Sample是如何监控线程的创建。在实践前，给你一些可以参考的链接。
|
||||
|
||||
|
||||
Android线程的创建过程
|
||||
|
||||
java_lang_Thread.cc
|
||||
|
||||
thread.cc
|
||||
|
||||
编译脚本Android.bp
|
||||
|
||||
|
||||
对于PLT Hook和Inline Hook的具体实现原理与差别，我在后面会详细讲到。这里我们可以把它们先隐藏掉，直接利用开源的实现即可。通过这个Sample我希望你可以学会通过分析源码，寻找合理的Hook函数与具体的so库。我相信当你熟悉这些方法之后，一定会惊喜地发现实现起来其实真的不难。
|
||||
|
||||
欢迎你点击“请朋友读”，把今天的内容分享给好友，邀请他一起学习。最后别忘了在评论区提交今天的作业，我也为认真完成作业的同学准备了丰厚的“学习加油礼包”，期待与你一起切磋进步哦。
|
||||
|
||||
|
||||
|
||||
|
||||
219
专栏/Android开发高手课/07启动优化（上）：从启动过程看启动速度优化.md
Normal file
219
专栏/Android开发高手课/07启动优化（上）：从启动过程看启动速度优化.md
Normal file
@ -0,0 +1,219 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
07 启动优化（上）：从启动过程看启动速度优化
|
||||
|
||||
在超市排队结账，扫码支付启动十几秒都还没完成，只能换一个工具支付？
|
||||
|
||||
想买本书充实一下，页面刷出来时候十几秒都不能操作，那就换一个应用购买？
|
||||
|
||||
|
||||
用户如果想打开一个应用，就一定要经过“启动”这个步骤。启动时间的长短，不只是用户体验的问题，对于淘宝、京东这些应用来说，会直接影响留存和转化等核心数据。对研发人员来说，启动速度是我们的“门面”，它清清楚楚可以被所有人看到，我们都希望自己应用的启动速度可以秒杀所有竞争对手。
|
||||
|
||||
那启动过程究竟会出现哪些问题？我们应该怎么去优化和监控应用的启动速度呢？今天我们一起来看看这些问题该如何解决。
|
||||
|
||||
启动分析
|
||||
|
||||
在真正动手开始优化之前，我们应该先搞清楚从用户点击图标开始，整个启动过程经过哪几个关键阶段，又会给用户带来哪些体验问题。
|
||||
|
||||
1. 启动过程分析
|
||||
|
||||
|
||||
|
||||
我以微信为例，用户从桌面点击图标开始，会经过4个关键阶段。
|
||||
|
||||
|
||||
T1预览窗口显示。系统在拉起微信进程之前，会先根据微信的Theme属性创建预览窗口。当然如果我们禁用预览窗口或者将预览窗口指定为透明，用户在这段时间依然看到的是桌面。
|
||||
|
||||
T2闪屏显示。在微信进程和闪屏窗口页面创建完毕，并且完成一系列inflate view、onmeasure、onlayout等准备工作后，用户终于可以看到熟悉的“小地球”。
|
||||
|
||||
T3主页显示。在完成主窗口创建和页面显示的准备工作后，用户可以看到微信的主界面。
|
||||
|
||||
T4界面可操作。在启动完成后，微信会有比较多的工作需要继续执行，例如聊天和朋友圈界面的预加载、小程序框架和进程的准备等。在这些工作完成后，用户才可以真正开始愉快地聊天。
|
||||
|
||||
|
||||
2. 启动问题分析
|
||||
|
||||
从启动流程的4个关键阶段，我们可以推测出用户启动过程会遇到的3个问题。这3个问题其实也是大多数应用在启动时可能会遇到的。
|
||||
|
||||
|
||||
问题1：点击图标很久都不响应
|
||||
|
||||
|
||||
如果我们禁用了预览窗口或者指定了透明的皮肤，那用户点击了图标之后，需要T2时间才能真正看到应用闪屏。对于用户体验来说，点击了图标，过了几秒还是停留在桌面，看起来就像没有点击成功，这在中低端机中更加明显。
|
||||
|
||||
|
||||
问题2：首页显示太慢
|
||||
|
||||
|
||||
现在应用启动流程越来越复杂，闪屏广告、热修复框架、插件化框架、大前端框架，所有准备工作都需要集中在启动阶段完成。上面说的T3首页显示时间对于中低端机来说简直就是噩梦，经常会达到十几秒的时间。
|
||||
|
||||
|
||||
问题3：首页显示后无法操作。
|
||||
|
||||
|
||||
既然首页显示那么慢，那我能不能把尽量多的工作都通过异步化延后执行呢？很多应用的确就是这么做的，但这会造成两种后果：要么首页会出现白屏，要么首页出来后用户根本无法操作。
|
||||
|
||||
很多应用把启动结束时间的统计放到首页刚出现的时候，这对用户是不负责任的。看到一个首页，但是停住十几秒都不能滑动，这对用户来说完全没有意义。启动优化不能过于KPI化，要从用户的真实体验出发，要着眼从点击图标到用户可操作的整个过程。
|
||||
|
||||
启动优化
|
||||
|
||||
启动速度优化的方法和卡顿优化基本相同，不过因为启动实在是太重要了，我们会更加“精打细算”。我们希望启动期间加载的每个功能和业务都是必须的，它们的实现都是经过“千锤百炼”的，特别是在中低端机上面的表现。
|
||||
|
||||
1. 优化工具
|
||||
|
||||
“工欲善其事必先利其器”，我们需要先找到一款适合做启动优化分析的工具。
|
||||
|
||||
你可以先回忆一下“卡顿优化”提到的几种工具。Traceview性能损耗太大，得出的结果并不真实；Nanoscope非常真实，不过暂时只支持Nexus 6P和x86模拟器，无法针对中低端机做测试；Simpleperf的火焰图并不适合做启动流程分析；systrace可以很方便地追踪关键系统调用的耗时情况，但是不支持应用程序代码的耗时分析。
|
||||
|
||||
综合来看，在卡顿优化中提到“systrace + 函数插桩”似乎是比较理想的方案，而且它还可以看到系统的一些关键事件，例如GC、System Server、CPU调度等。
|
||||
|
||||
我们可以通过下面的命令，可以查看手机支持哪些systrace类型。不同的系统支持的类型有所差别，其中Dalvik、sched、ss、app都是我们比较关心的。
|
||||
|
||||
python systrace.py --list-categories
|
||||
|
||||
|
||||
通过插桩，我们可以看到应用主线程和其他线程的函数调用流程。它的实现原理非常简单，就是将下面的两个函数分别插入到每个方法的入口和出口。
|
||||
|
||||
class Trace {
|
||||
public static void i(String tag) {
|
||||
Trace.beginSection(name);
|
||||
}
|
||||
|
||||
|
||||
public static void o() {
|
||||
Trace.endSection();
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
当然这里面有非常多的细节需要考虑，比如怎么样降低插桩对性能的影响、哪些函数需要被排除掉。最终改良版的systrace性能损耗在一倍以内，基本可以反映真实的启动流程。函数插桩后的效果如下，你也可以参考课后练习的Sample。
|
||||
|
||||
class Test {
|
||||
public void test() {
|
||||
Trace.i("Test.test()");
|
||||
//原来的工作
|
||||
Trace.o()；
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
只有准确的数据评估才能指引优化的方向，这一步是非常非常重要的。我见过太多同学在没有充分评估或者评估使用了错误的方法，最终得到了错误的方向。辛辛苦苦一两个月，最后发现根本达不到预期的效果。
|
||||
|
||||
2. 优化方式
|
||||
|
||||
在拿到整个启动流程的全景图之后，我们可以清楚地看到这段时间内系统、应用各个进程和线程的运行情况，现在我们要开始真正开始“干活”了。
|
||||
|
||||
具体的优化方式，我把它们分为闪屏优化、业务梳理、业务优化、线程优化、GC优化和系统调用优化。
|
||||
|
||||
|
||||
闪屏优化
|
||||
|
||||
|
||||
今日头条把预览窗口实现成闪屏的效果，这样用户只需要很短的时间就可以看到“预览闪屏”。这种完全“跟手”的感觉在高端机上体验非常好，但对于中低端机，会把总的的闪屏时间变得更长。
|
||||
|
||||
如果点击图标没有响应，用户主观上会认为是手机系统响应比较慢。所以我比较推荐的做法是，只在Android 6.0或者Android 7.0以上才启用“预览闪屏”方案，让手机性能好的用户可以有更好的体验。
|
||||
|
||||
微信做的另外一个优化是合并闪屏和主页面的Activity，减少一个Activity会给线上带来100毫秒左右的优化。但是如果这样做的话，管理时会非常复杂，特别是有很多例如PWA、扫一扫这样的第三方启动流程的时候。
|
||||
|
||||
|
||||
业务梳理
|
||||
|
||||
|
||||
我们首先需要梳理清楚当前启动过程正在运行的每一个模块，哪些是一定需要的、哪些可以砍掉、哪些可以懒加载。我们也可以根据业务场景来决定不同的启动模式，例如通过扫一扫启动只需要加载需要的几个模块即可。对于中低端机器，我们要学会降级，学会推动产品经理做一些功能取舍。但是需要注意的是，懒加载要防止集中化，否则容易出现首页显示后用户无法操作的情形。
|
||||
|
||||
|
||||
业务优化
|
||||
|
||||
|
||||
通过梳理之后，剩下的都是启动过程一定要用的模块。这个时候，我们只能硬着头皮去做进一步的优化。优化前期需要“抓大放小”，先看看主线程究竟慢在哪里。最理想是通过算法进行优化，例如一个数据解密操作需要1秒，通过算法优化之后变成10毫秒。退而求其次，我们要考虑这些任务是不是可以通过异步线程预加载实现，但需要注意的是过多的线程预加载会让我们的逻辑变得更加复杂。
|
||||
|
||||
业务优化做到后面，会发现一些架构和历史包袱会拖累我们前进的步伐。比较常见的是一些事件会被各个业务模块监听，大量的回调导致很多工作集中执行，部分框架初始化“太厚”，例如一些插件化框架，启动过程各种反射、各种Hook，整个耗时至少几百毫秒。还有一些历史包袱又非常沉重，而且“牵一发动全身”，改动风险比较大。但是我想说，如果有合适的时机，我们依然需要勇敢去偿还这些“历史债务”。
|
||||
|
||||
|
||||
线程优化
|
||||
|
||||
|
||||
线程优化就像做填空题和解锁题，我们希望能把所有的时间片都利用上，因此主线程和各个线程都是一直满载的。当然我们也希望每个线程都开足马力向前跑，而不是作为接力棒。所以线程的优化主要在于减少CPU调度带来的波动，让应用的启动时间更加稳定。
|
||||
|
||||
从具体的做法来看，线程的优化一方面是控制线程数量，线程数量太多会相互竞争CPU资源，因此要有统一的线程池，并且根据机器性能来控制数量。
|
||||
|
||||
线程切换的数据我们可以通过卡顿优化中学到的sched文件查看，这里特别需要注意nr_involuntary_switches被动切换的次数。
|
||||
|
||||
proc/[pid]/sched:
|
||||
nr_voluntary_switches：
|
||||
主动上下文切换次数，因为线程无法获取所需资源导致上下文切换，最普遍的是IO。
|
||||
nr_involuntary_switches：
|
||||
被动上下文切换次数，线程被系统强制调度导致上下文切换，例如大量线程在抢占CPU。
|
||||
|
||||
|
||||
另一方面是检查线程间的锁。为了提高启动过程任务执行的速度，有一次我们把主线程内的一个耗时任务放到线程中并发执行，但是发现这样做根本没起作用。仔细检查后发现线程内部会持有一个锁，主线程很快就有其他任务因为这个锁而等待。通过systrace可以看到锁等待的事件，我们需要排查这些等待是否可以优化，特别是防止主线程出现长时间的空转。
|
||||
|
||||
|
||||
|
||||
特别是现在有很多启动框架，会使用Pipeline机制，根据业务优先级规定业务初始化时机。比如微信内部使用的mmkernel、阿里最近开源的Alpha启动框架，它们为各个任务建立依赖关系，最终构成一个有向无环图。对于可以并发的任务，会通过线程池最大程度提升启动速度。如果任务的依赖关系没有配置好，很容易出现下图这种情况，即主线程会一直等待taskC结束，空转2950毫秒。
|
||||
|
||||
|
||||
|
||||
|
||||
GC优化
|
||||
|
||||
|
||||
在启动过程，要尽量减少GC的次数，避免造成主线程长时间的卡顿，特别是对Dalvik来说，我们可以通过systrace单独查看整个启动过程GC的时间。
|
||||
|
||||
python systrace.py dalvik -b 90960 -a com.sample.gc
|
||||
|
||||
|
||||
对于GC各个事件的具体含义，你可以参考《调查RAM使用情况》。
|
||||
|
||||
|
||||
|
||||
不知道你是否还记得我在“内存优化”中提到Debug.startAllocCounting，我们也可以使用它来监控启动过程总GC的耗时情况，特别是阻塞式同步GC的总次数和耗时。
|
||||
|
||||
// GC使用的总耗时，单位是毫秒
|
||||
Debug.getRuntimeStat("art.gc.gc-time");
|
||||
// 阻塞式GC的总耗时
|
||||
Debug.getRuntimeStat("art.gc.blocking-gc-time");
|
||||
|
||||
|
||||
如果我们发现主线程出现比较多的GC同步等待，那就需要通过Allocation工具做进一步的分析。启动过程避免进行大量的字符串操作，特别是序列化跟反序列化过程。一些频繁创建的对象，例如网络库和图片库中的Byte数组、Buffer可以复用。如果一些模块实在需要频繁创建对象，可以考虑移到Native实现。
|
||||
|
||||
Java对象的逃逸也很容易引起GC问题，我们在写代码的时候比较容易忽略这个点。我们应该保证对象生命周期尽量的短，在栈上就进行销毁。
|
||||
|
||||
|
||||
系统调用优化
|
||||
|
||||
|
||||
通过systrace的System Service类型，我们可以看到启动过程System Server的CPU工作情况。在启动过程，我们尽量不要做系统调用，例如PackageManagerService操作、Binder调用等待。
|
||||
|
||||
在启动过程也不要过早地拉起应用的其他进程，System Server和新的进程都会竞争CPU资源。特别是系统内存不足的时候，当我们拉起一个新的进程，可能会成为“压死骆驼的最后一根稻草”。它可能会触发系统的low memory killer机制，导致系统杀死和拉起（保活）大量的进程，从而影响前台进程的CPU。
|
||||
|
||||
讲个实践的案例，之前我们的一个程序在启动过程会拉起下载和视频播放进程，改为按需拉起后，线上启动时间提高了3%，对于1GB以下的低端机优化，整个启动时间可以优化5%～8%，效果还是非常明显的。
|
||||
|
||||
总结
|
||||
|
||||
今天我们首先学习了启动的整个流程，其中比较关键的是4个阶段。在这4个阶段中，用户可能会出现“点击图标很久都不响应“”首页显示太慢“和”首页显示后无法操作“这3个问题。
|
||||
|
||||
接着我们学习了启动优化和监控的一些常规方法。针对不同的业务场景、不同性能的机器，需要采用不同的策略。有些知识点似乎比较“浅尝辄止”，我更希望你能够通过学习和实践将它们丰富起来。
|
||||
|
||||
我讲到的大部分内容都是跟业务相关，业务的梳理和优化也是最快出成果的。不过这个过程我们要学会取舍，你可能遇到过，很多产品经理为了提升自己负责的模块的数据，总会逼迫开发做各种各样的预加载。但是大家都想快，最后的结果就是代码一团糟，肯定都快不起来。
|
||||
|
||||
比如只有1%用户使用的功能，却让所有用户都做预加载。面对这种情况，我们要狠下心来，只留下那些真正不能删除的业务，或者通过场景化直接找到那1%的用户。跟产品经理PK可能不是那么容易，关键在于数据。我们需要证明启动优化带来整体留存、转化的正向价值，是大于某个业务取消预加载带来的负面影响。
|
||||
|
||||
启动优化是性能优化工作非常重要的一环，今天的课后作业是，在你过去的工作中，曾经针对启动做过哪些优化，最终效果又是怎样的呢？请你在留言区分享一下今天学习、练习的收获与心得。
|
||||
|
||||
课后练习
|
||||
|
||||
“工欲善其事必先利其器”，我多次提到“systrace + 函数插桩”是一个非常不错的卡顿排查工具，那么通过今天的Sample，我们一起来看一下它是如何实现的。需要注意的是Sample选择了ASM插桩的方式，感兴趣的同学可以课后学习一下它的使用方法，在后续我们也会有关于插桩的专门课程。
|
||||
|
||||
我们可以将Sample运用到自己的应用中，虽然它过滤了大部分的函数，但是我们还是需要注意白名单的配置。例如log、加解密等在底层非常频繁调用的函数，都要在白名单中配置过滤掉，不然可能会出现类似下面这样大量的毛刺。
|
||||
|
||||
|
||||
|
||||
欢迎你点击“请朋友读”，把今天的内容分享给好友，邀请他一起学习。最后别忘了在评论区提交今天的作业，我也为认真完成作业的同学准备了丰厚的“学习加油礼包”，期待与你一起切磋进步哦。
|
||||
|
||||
|
||||
|
||||
|
||||
221
专栏/Android开发高手课/08启动优化（下）：优化启动速度的进阶方法.md
Normal file
221
专栏/Android开发高手课/08启动优化（下）：优化启动速度的进阶方法.md
Normal file
@ -0,0 +1,221 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
08 启动优化（下）：优化启动速度的进阶方法
|
||||
专栏上一期，我们一起梳理了应用启动的整个过程和问题，也讲了一些启动优化方法，可以说是完成了启动优化工作最难的一部分。还可以通过删掉或延后一些不必要的业务，来实现相关具体业务的优化。你学会了这些工具和方法，是不是觉得效果非常不错，然后美滋滋地向老大汇报工作成果：“启动速度提升30%，秒杀所有竞品好几条街”。
|
||||
|
||||
“还有什么方法可以做进一步优化吗？怎么证明你秒杀所有的竞品？如何在线上衡量启动优化的效果？怎么保障和监控启动速度是否变慢？”，老大一口气问了四个问题。
|
||||
|
||||
面对这四个问题，你可不能一脸懵。我们的应用启动是不是真的已经做到了极致？如何保证启动优化成果是长期有效的？让我们通过今天的学习，一起来回答老大这些问题吧。
|
||||
|
||||
启动进阶方法
|
||||
|
||||
除了上期讲的常规的优化方法，我还有一些与业务无关的“压箱底”方法可以帮助加快应用的启动速度。当然有些方法会用到一些黑科技，它就像一把双刃剑，需要你做深入的评估和测试。
|
||||
|
||||
1. I/O 优化
|
||||
|
||||
在负载过高的时候，I/O性能下降得会比较快。特别是对于低端机，同样的I/O操作耗时可能是高端机器的几十倍。启动过程不建议出现网络I/O，相比之下，磁盘I/O是启动优化一定要抠的点。首先我们要清楚启动过程读了什么文件、多少个字节、Buffer是多大、使用了多长时间、在什么线程等一系列信息。
|
||||
|
||||
|
||||
|
||||
那么如何实现I/O的监控呢？我今天先卖个关子，下一期我会详细和你聊聊I/O方面的知识。
|
||||
|
||||
通过上面的数据，我们发现chat.db的大小竟然达到500MB。我们经常发现本地启动明明非常快，为什么线上有些用户就那么慢？这可能是一些用户本地积累了非常多的数据，我们也发现有些微信的重度用户，他的DB文件竟然会超过1GB。所以，重度用户是启动优化一定要覆盖的群体，我们要做一些特殊的优化策略。
|
||||
|
||||
还有一个是数据结构的选择问题，我们在启动过程只需要读取Setting.sp的几项数据，不过SharedPreference在初始化的时候还是要全部数据一起解析。如果它的数据量超过1000条，启动过程解析时间可能就超过100毫秒。如果只解析启动过程用到的数据项则会很大程度减少解析时间，启动过程适合使用随机读写的数据结构。
|
||||
|
||||
|
||||
|
||||
可以将ArrayMap改造成支持随机读写、延时解析的数据存储方式。同样我们今天也不再展开这部分内容，这些知识会在存储优化的相关章节进一步展开。
|
||||
|
||||
2. 数据重排
|
||||
|
||||
在上面的表格里面，我们读取test.io文件中1KB数据，因为Buffer不小心写成了1 byte，总共要读取1000次。那系统是不是真的会读1000次磁盘呢？
|
||||
|
||||
事实上1000次读操作只是我们发起的次数，并不是真正的磁盘I/O次数。你可以参考下面Linux文件I/O流程。
|
||||
|
||||
|
||||
|
||||
Linux文件系统从磁盘读文件的时候，会以block为单位去磁盘读取，一般block大小是4KB。也就是说一次磁盘读写大小至少是4KB，然后会把4KB数据放到页缓存Page Cache中。如果下次读取文件数据已经在页缓存中，那就不会发生真实的磁盘I/O，而是直接从页缓存中读取，大大提升了读的速度。所以上面的例子，我们虽然读了1000次，但事实上只会发生一次磁盘I/O，其他的数据都会在页缓存中得到。
|
||||
|
||||
Dex文件用的到的类和安装包APK里面各种资源文件一般都比较小，但是读取非常频繁。我们可以利用系统这个机制将它们按照读取顺序重新排列，减少真实的磁盘I/O次数。
|
||||
|
||||
类重排
|
||||
|
||||
启动过程类加载顺序可以通过复写ClassLoader得到。
|
||||
|
||||
class GetClassLoader extends PathClassLoader {
|
||||
public Class<?> findClass(String name) {
|
||||
// 将 name 记录到文件
|
||||
writeToFile(name，"coldstart_classes.txt");
|
||||
return super.findClass(name);
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
然后通过ReDex的Interdex调整类在Dex中的排列顺序，最后可以利用010 Editor查看修改后的效果。
|
||||
|
||||
|
||||
|
||||
我多次提到的ReDex，是Facebook开源的Dex优化工具，它里面有非常多好用的东西，后续我们会有更详细的介绍。
|
||||
|
||||
资源文件重排
|
||||
|
||||
Facebook在比较早的时候就使用“资源热图”来实现资源文件的重排，最近支付宝在《通过安装包重排布优化Android端启动性能》中也详细讲述了资源重排的原理和落地方法。
|
||||
|
||||
在实现上，它们都是通过修改Kernel源码，单独编译了一个特殊的ROM。这样做的目的有三个：
|
||||
|
||||
|
||||
统计。统计应用启动过程加载了安装包中哪些资源文件，比如assets、drawable、layout等。跟类重排一样，我们可以得到一个资源加载的顺序列表。
|
||||
|
||||
度量。在完成资源顺序重排后，我们需要确定是否真正生效。比如有哪些资源文件加载了，它是发生真实的磁盘I/O，还是命中了Page Cache。
|
||||
|
||||
自动化。任何代码提交都有可能改变启动过程中类和资源的加载顺序，如果完全依靠人工手动处理，这个事情很难持续下去。通过定制ROM的一些埋点和配合的工具，我们可以将它们放到自动化流程当中。
|
||||
|
||||
|
||||
跟前面提到的Nanoscope耗时分析工具一样，当系统无法满足我们的优化需求时，就需要直接修改ROM的实现。Facebook“资源热图”相对比较完善，也建设了一些配套的Dashboard工具，希望后续可以开源出来。
|
||||
|
||||
事实上如果仅仅为了统计，我们也可以使用Hook的方式。下面是利用Frida实现获得Android资源加载顺序的方法，不过Frida还是相对小众，后面会替换其他更加成熟的Hook框架。
|
||||
|
||||
resourceImpl.loadXmlResourceParser.implementation=function(a,b,c,d){
|
||||
send('file:'+a)
|
||||
return this.loadXmlResourceParser(a,b,c,d)
|
||||
}
|
||||
|
||||
|
||||
resourceImpl.loadDrawableForCookie.implementation=function(a,b,c,d,e){
|
||||
send("file:"+a)
|
||||
return this.loadDrawableForCookie(a,b,c,d,e)
|
||||
}
|
||||
|
||||
|
||||
调整安装包文件排列需要修改7zip源码实现支持传入文件列表顺序，同样最后可以利用010 Editor查看修改后的效果。
|
||||
|
||||
|
||||
|
||||
这两个优化可能会带来100～200毫秒的提高，我们还可以大大减少启动过程I/O的时间波动。特别是对于中低端机器来说，经常发现启动时间波动非常大，这个波动跟CPU调度相关，但更多时候是跟I/O相关。
|
||||
|
||||
可能有同学会问，这些优化思路究竟是怎么样想出来的呢？其实利用文件系统和磁盘读取机制的优化思路，在服务端和Windows上早已经不是什么新鲜事。所谓的创新，不一定是创造前所未有的东西。我们将已有的方案移植到新的平台，并且很好地结合该平台的特性将其落地，就是一个很大的创新。
|
||||
|
||||
3. 类的加载
|
||||
|
||||
在WeMobileDev公众号发布的《微信Android热补丁实践演进之路》中，我提过在加载类的过程有一个verify class的步骤，它需要校验方法的每一个指令，是一个比较耗时的操作。
|
||||
|
||||
|
||||
|
||||
我们可以通过Hook来去掉verify这个步骤，这对启动速度有几十毫秒的优化。不过我想说，其实最大的优化场景在于首次和覆盖安装时。以Dalvik平台为例，一个2MB的Dex正常需要350毫秒，将classVerifyMode设为VERIFY_MODE_NONE后，只需要150毫秒，节省超过50%的时间。
|
||||
|
||||
// Dalvik Globals.h
|
||||
gDvm.classVerifyMode = VERIFY_MODE_NONE;
|
||||
// Art runtime.cc
|
||||
verify_ = verifier::VerifyMode::kNone;
|
||||
|
||||
|
||||
但是ART平台要复杂很多，Hook需要兼容几个版本。而且在安装时大部分Dex已经优化好了，去掉ART平台的verify只会对动态加载的Dex带来一些好处。Atlas中的dalvik_hack-3.0.0.5.jar可以通过下面的方法去掉verify，但是当前没有支持ART平台。
|
||||
|
||||
AndroidRuntime runtime = AndroidRuntime.getInstance();
|
||||
runtime.init(context);
|
||||
runtime.setVerificationEnabled(false);
|
||||
|
||||
|
||||
这个黑科技可以大大降低首次启动的速度，代价是对后续运行会产生轻微的影响。同时也要考虑兼容性问题，暂时不建议在ART平台使用。
|
||||
|
||||
4. 黑科技
|
||||
|
||||
第一，保活
|
||||
|
||||
讲到黑科技，你可能第一个想到的就是保活。保活可以减少Application创建跟初始化的时间，让冷启动变成温启动。不过在Target 26之后，保活的确变得越来越难。
|
||||
|
||||
对于大厂来说，可能需要寻求厂商合作的机会，例如微信的Hardcoder方案和OPPO推出的Hyper Boost方案。根据OPPO的数据，对于手机QQ、淘宝、微信启动场景会直接有20%以上的优化。
|
||||
|
||||
有的时候你问为什么微信可以保活？为什么它可以运行的那么流畅？这里可能不仅仅是技术上的问题，当应用体量足够大，就可以倒逼厂商去专门为它们做优化。
|
||||
|
||||
第二，插件化和热修复
|
||||
|
||||
从2012年开始，淘宝、微信尝试做插件化的探索。到了2015年，淘宝的Dexposed、支付宝的AndFix以及微信的Tinker等热修复技术开始“百花齐放”。
|
||||
|
||||
它们真的那么好吗？事实上大部分的框架在设计上都存在大量的Hook和私有API调用，带来的缺点主要有两个：
|
||||
|
||||
|
||||
稳定性。虽然大家都号称兼容100%的机型，由于厂商的兼容性、安装失败、dex2oat失败等原因，还是会有那么一些代码和资源的异常。Android P推出的non-sdk-interface调用限制，以后适配只会越来越难，成本越来越高。
|
||||
|
||||
性能。Android Runtime每个版本都有很多的优化，因为插件化和热修复用到的一些黑科技，导致底层Runtime的优化我们是享受不到的。Tinker框架在加载补丁后，应用启动速度会降低5%～10%。
|
||||
|
||||
|
||||
应用加固对启动速度来说简直是灾难，有时候我们需要做一些权衡和选择。为了提升启动速度，支付宝也提出一种GC抑制的方案。不过首先Android 5.0以下的系统占比已经不高，其次这也会带来一些兼容性问题。我们还是更希望通过手段可以真正优化整个耗时，而不是一些取巧的方式。
|
||||
|
||||
总的来说，对于黑科技我们需要慎重，当你足够了解它们内部的机制以后，可以选择性的使用。
|
||||
|
||||
启动监控
|
||||
|
||||
终于千辛万苦的优化好了，我们还要找一套合理、准确的方法来度量优化的成果。同时还要对它做全方位的监控，以免被人破坏劳动果实。
|
||||
|
||||
1. 实验室监控
|
||||
|
||||
如果想客观地反映启动的耗时，视频录制会是一个非常好的选择。特别是我们很难拿到竞品的线上数据，所以实验室监控也非常适合做竞品的对比测试。
|
||||
|
||||
它的难点在于如何让实验系统准确地找到启动结束的点，这里可以通过下面两种方式。
|
||||
|
||||
|
||||
80%绘制。当页面绘制超过80%的时候认为是启动完成，不过可能会把闪屏当成启动结束的点，不一定是我们所期望的。
|
||||
|
||||
图像识别。手动输入一张启动结束的图片，当实验系统认为当前截屏页面有80%以上相似度时，就认为是启动结束。这种方法更加灵活可控，但是实现难度会稍微高一点。
|
||||
|
||||
|
||||
|
||||
|
||||
启动的实验室监控可以定期自动去跑，需要注意的是，我们应该覆盖高、中、低端机不同的场景。但是使用录屏的方式也有一个缺陷，就是出现问题时我们需要人工二次定位具体是什么代码所导致的。
|
||||
|
||||
2. 线上监控
|
||||
|
||||
实验室覆盖的场景和机型还是有限的，是驴是马我们还是要发布到线上进行验证。针对线上，启动监控会更加复杂一些。Android Vitals可以对应用冷启动、温启动时间做监控。
|
||||
|
||||
|
||||
|
||||
事实上，每个应用启动的流程都非常复杂，上面的图并不能真实反映每个应用的启动耗时。启动耗时的计算需要考虑非常多的细节，比如：
|
||||
|
||||
|
||||
启动结束的统计时机。是否是使用用户真正可以操作的时间作为启动结束的时间。
|
||||
|
||||
启动时间扣除的逻辑。闪屏、广告和新手引导这些时间都应该从启动时间里扣除。
|
||||
|
||||
启动排除逻辑。Broadcast、Server拉起，启动过程进入后台这些都需要排除出统计。
|
||||
|
||||
|
||||
经过精密的扣除和排除逻辑，我们最终可以得到用户的线上启动耗时。正如我在上一期所说的，准确的启动耗时统计是非常重要的。有很多优化在实验室完成之后，还需要在线上灰度验证效果。这个前提是启动统计是准确的，整个效果评估是真实的。
|
||||
|
||||
那我们一般使用什么指标来衡量启动速度的快慢呢？
|
||||
|
||||
很多应用采用平均启动时间，不过这个指标其实并不太好，一些体验很差的用户很有可能是被平均了。我更建议使用类似下面的指标：
|
||||
|
||||
|
||||
快开慢开比。例如2秒快开比、5秒慢开比，我们可以看到有多少比例的用户体验非常好，多少比例的用户比较槽糕。
|
||||
|
||||
90%用户的启动时间。如果90%的用户启动时间都小于5秒，那么我们90%区间启动耗时就是5秒。
|
||||
|
||||
|
||||
此外我们还要区分启动的类型。这里要统计首次安装启动、覆盖安装启动、冷启动和温启动这些类型，一般我们都使用普通的冷启动时间作为指标。另一方面热启动的占比也可以反映出我们程序的活跃或保活能力。
|
||||
|
||||
除了指标的监控，启动的线上堆栈监控更加困难。Facebook会利用Profilo工具对启动的整个流程耗时做监控，并且在后台直接对不同的版本做自动化对比，监控新版本是否有新增耗时的函数。
|
||||
|
||||
总结
|
||||
|
||||
今天我们学习了一些与业务无关的启动优化方法，可以进一步减少启动耗时，特别是减少磁盘I/O可能带来的波动。然后我们探讨了一些黑科技对启动的影响，对于黑科技我们需要两面看，在选择时也要慎重。最后我们探讨了如何在实验室和线上更好地测量和监控启动速度。
|
||||
|
||||
启动优化需要耐得住寂寞，把整个流程摸清摸透，一点点把时间抠出来，特别是对于低端机和系统繁忙的场景。而数据重排的优化，对我有非常大的启发，帮助我开发了一个新的方向。也让我明白了，当我们足够熟悉底层的知识时，可以利用系统的特性去做更加深层次的优化。
|
||||
|
||||
不管怎么说，你都需要谨记一点：对于启动优化要警惕KPI化，我们要解决的不是一个数字，而是用户真正的体验问题。
|
||||
|
||||
看完我分享的启动优化的方法后，相信你肯定也还有很多好的思路和方法。今天的课后作业是分享一下你“压箱底”的启动优化“秘籍”，在留言区分享一下今天学习、练习的收获与心得。
|
||||
|
||||
课后练习
|
||||
|
||||
今天我们的Sample是如何在Dalvik去掉verify，你可以顺着这个思路尝试去分析Dalvik虚拟机加载Dex和类的流程。
|
||||
|
||||
欢迎你点击“请朋友读”，把今天的内容分享给好友，邀请他一起学习。最后别忘了在评论区提交今天的作业，我也为认真完成作业的同学准备了丰厚的“学习加油礼包”，期待与你一起切磋进步哦。
|
||||
|
||||
|
||||
|
||||
|
||||
248
专栏/Android开发高手课/09I_O优化（上）：开发工程师必备的I_O优化知识.md
Normal file
248
专栏/Android开发高手课/09I_O优化（上）：开发工程师必备的I_O优化知识.md
Normal file
@ -0,0 +1,248 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
09 I_O优化（上）：开发工程师必备的I_O优化知识
|
||||
|
||||
250GB容量，512MB DDR4缓存，连续读取不超过550MB/s，连续写入不超过520MB/s。
|
||||
|
||||
|
||||
“双十一”在天猫看到一款固态硬盘有上面的这些介绍，这些数字分别代表了什么意思？
|
||||
|
||||
在专栏前面卡顿和启动优化里，我也经常提到I/O优化。可能很多同学觉得I/O优化不就是不在主线程读写大文件吗，真的只有这么简单吗？那你是否考虑过，从应用程序调用read()方法，内核和硬件会做什么样的处理，整个流程可能会出现什么问题？今天请你带着这些疑问，我们一起来看看I/O优化需要的知识。
|
||||
|
||||
I/O的基本知识
|
||||
|
||||
在工作中，我发现很多工程师对I/O的认识其实比较模糊，认为I/O就是应用程序执行read()、write()这样的一些操作，并不清楚这些操作背后的整个流程是怎样的。
|
||||
|
||||
|
||||
|
||||
我画了一张简图，你可以看到整个文件I/O操作由应用程序、文件系统和磁盘共同完成。首先应用程序将I/O命令发送给文件系统，然后文件系统会在合适的时机把I/O操作发给磁盘。
|
||||
|
||||
这就好比CPU、内存、磁盘三个小伙伴一起完成接力跑，最终跑完的时间很大程度上取决于最慢的小伙伴。我们知道，CPU和内存相比磁盘是高速设备，整个流程的瓶颈在于磁盘I/O的性能。所以很多时候，文件系统性能比磁盘性能更加重要，为了降低磁盘对应用程序的影响，文件系统需要通过各种各样的手段进行优化。那么接下来，我们首先来看文件系统。
|
||||
|
||||
1. 文件系统
|
||||
|
||||
文件系统，简单来说就是存储和组织数据的方式。比如在iOS 10.3系统以后，苹果使用APFS（Apple File System）替代之前旧的文件系统HFS+。对于Android来说，现在普遍使用的是Linux常用的ext4文件系统。
|
||||
|
||||
关于文件系统还需要多说两句，华为在EMUI 5.0以后就使用F2FS取代ext4，Google也在最新的旗舰手机Pixel 3使用了F2FS文件系统。Flash-Friendly File System是三星是专门为NAND闪存芯片开发的文件系统，也做了大量针对闪存的优化。根据华为的测试数据，F2FS文件系统在小文件的随机读写方面比ext4更快，例如随机写可以优化60%，不足之处在于可靠性方面出现过一些问题。我想说的是，随着Google、华为的投入和规模化使用，F2FS系统应该是未来Android的主流文件系统。
|
||||
|
||||
还是回到文件系统的I/O。应用程序调用read()方法，系统会通过中断从用户空间进入内核处理流程，然后经过VFS（Virtual File System，虚拟文件系统）、具体文件系统、页缓存Page Cache。下面是Linux一个通用的I/O架构模型。
|
||||
|
||||
|
||||
|
||||
|
||||
虚拟文件系统（VFS）。它主要用于实现屏蔽具体的文件系统，为应用程序的操作提供一个统一的接口。这样保证就算厂商把文件系统从ext4切换到F2FS，应用程序也不用做任何修改。
|
||||
|
||||
文件系统（File System）。ext4、F2FS都是具体文件系统实现，文件元数据如何组织、目录和索引结构如何设计、怎么分配和清理数据，这些都是设计一个文件系统必须要考虑的。每个文件系统都有适合自己的应用场景，我们不能说F2FS就一定比ext4要好。F2FS在连续读取大文件上并没有优势，而且会占用更大的空间。只是对一般应用程序来说，随机I/O会更加频繁，特别是在启动的场景。你可以在/proc/filesystems看到系统可以识别的所有文件系统的列表。
|
||||
|
||||
页缓存（Page Cache）。在启动优化中我已经讲过Page Cache这个概念了，在读文件的时候会，先看它是不是已经在Page Cache中，如果命中就不会去读取磁盘。在Linux 2.4.10之前还有一个单独的Buffer Cache，后来它也合并到Page Cache中的Buffer Page了。
|
||||
|
||||
|
||||
具体来说，Page Cache就像是我们经常使用的数据缓存，是文件系统对数据的缓存，目的是提升内存命中率。Buffer Cache就像我们经常使用的BufferInputStream，是磁盘对数据的缓存，目的是合并部分文件系统的I/O请求、降低磁盘I/O的次数。需要注意的是，它们既会用在读请求中，也会用到写请求中。
|
||||
|
||||
通过/proc/meminfo文件可以查看缓存的内存占用情况，当手机内存不足的时候，系统会回收它们的内存，这样整体I/O的性能就会有所降低。
|
||||
|
||||
MemTotal: 2866492 kB
|
||||
MemFree: 72192 kB
|
||||
Buffers: 62708 kB // Buffer Cache
|
||||
Cached: 652904 kB // Page Cache
|
||||
|
||||
|
||||
2. 磁盘
|
||||
|
||||
磁盘指的是系统的存储设备，就像小时候我们常听的CD或者电脑使用的机械硬盘，当然还有现在比较流行的SSD固态硬盘。
|
||||
|
||||
正如我上面所说，如果发现应用程序要read()的数据没有在页缓存中，这时候就需要真正向磁盘发起I/O请求。这个过程要先经过内核的通用块层、I/O调度层、设备驱动层，最后才会交给具体的硬件设备处理。
|
||||
|
||||
|
||||
|
||||
|
||||
通用块层。系统中能够随机访问固定大小数据块（block）的设备称为块设备，CD、硬盘和SSD这些都属于块设备。通用块层主要作用是接收上层发出的磁盘请求，并最终发出I/O请求。它跟VFS的作用类似，让上层不需要关心底层硬件设备的具体实现。
|
||||
|
||||
I/O调度层。磁盘I/O那么慢，为了降低真正的磁盘I/O，我们不能接收到磁盘请求就立刻交给驱动层处理。所以我们增加了I/O调度层，它会根据设置的调度算法对请求合并和排序。这里比较关键的参数有两个，一个是队列长度，一个是具体的调度算法。我们可以通过下面的文件可以查看对应块设备的队列长度和使用的调度算法。
|
||||
|
||||
|
||||
/sys/block/[disk]/queue/nr_requests // 队列长度，一般是 128。
|
||||
/sys/block/[disk]/queue/scheduler // 调度算法
|
||||
|
||||
|
||||
|
||||
块设备驱动层。块设备驱动层根据具体的物理设备，选择对应的驱动程序通过操控硬件设备完成最终的I/O请求。例如光盘是靠激光在表面烧录存储、闪存是靠电子擦写存储数据。
|
||||
|
||||
|
||||
Android I/O
|
||||
|
||||
前面讲了Linux I/O相关的一些知识，现在我们再来讲讲Android I/O相关的一些知识。
|
||||
|
||||
1. Android闪存
|
||||
|
||||
我们先来简单讲讲手机使用的存储设备，手机使用闪存作为存储设备，也就是我们常说的ROM。
|
||||
|
||||
考虑到体积和功耗，我们肯定不能直接把PC的SSD方案用在手机上面。Android手机前几年通常使用eMMC标准，近年来通常会采用性能更好的UFS 2.0/2.1标准，之前沸沸扬扬的某厂商“闪存门”事件就是因为使用eMMC闪存替换了宣传中的UFS闪存。而苹果依然坚持独立自主的道路，在2015年就在iPhone 6s上就引入了MacBook上备受好评的NVMe协议。
|
||||
|
||||
最近几年移动硬件的发展非常妖孽，手机存储也朝着体积更小、功耗更低、速度更快、容量更大的方向狂奔。iPhone XS的容量已经达到512GB，连续读取速度可以超过1GB/s，已经比很多的SSD固态硬盘还要快，同时也大大缩小了和内存的速度差距。不过这些都是厂商提供的一些测试数据，特别是对于随机读写的性能相比内存还是差了很多。
|
||||
|
||||
|
||||
|
||||
上面的数字好像有点抽象，直白地说闪存的性能会影响我们打开微信、游戏加载以及连续自拍的速度。当然闪存性能不仅仅由硬件决定，它跟采用的标准、文件系统的实现也有很大的关系。
|
||||
|
||||
2. 两个疑问
|
||||
|
||||
看到这里可能有些同学会问，知道文件读写的流程、文件系统和磁盘这些基础知识，对我们实际开发有什么作用呢？下面我举两个简单的例子，可能你平时也思考过，不过如果不熟悉I/O的内部机制，你肯定是一知半解。
|
||||
|
||||
疑问一：文件为什么会损坏？
|
||||
|
||||
先说两个客观数据，微信聊天记录使用的SQLite数据库大概有几万分之一的损坏率，系统SharedPreference如果频繁跨进程读写也会有万分之一的损坏率。
|
||||
|
||||
在回答文件为什么会损坏前，首先需要先明确一下什么是文件损坏。一个文件的格式或者内容，如果没有按照应用程序写入时的结果都属于文件损坏。它不只是文件格式错误，文件内容丢失可能才是最常出现的，SharedPreference跨进程读写就非常容易出现数据丢失的情况。
|
||||
|
||||
再来探讨文件为什么会损坏，我们可以从应用程序、文件系统和磁盘三个角度来审视这个问题。
|
||||
|
||||
|
||||
应用程序。大部分的I/O方法都不是原子操作，文件的跨进程或者多线程写入、使用一个已经关闭的文件描述符fd来操作文件，它们都有可能导致数据被覆盖或者删除。事实上，大部分的文件损坏都是因为应用程序代码设计考虑不当导致的，并不是文件系统或者磁盘的问题。
|
||||
|
||||
文件系统。虽说内核崩溃或者系统突然断电都有可能导致文件系统损坏，不过文件系统也做了很多的保护措施。例如system分区保证只读不可写，增加异常检查和恢复机制，ext4的fsck、f2fs的fsck.f2fs和checkpoint机制等。
|
||||
|
||||
|
||||
在文件系统这一层，更多是因为断电而导致的写入丢失。为了提升I/O性能，文件系统把数据写入到Page Cache中，然后等待合适的时机才会真正的写入磁盘。当然我们也可以通过fsync、msync这些接口强制写入磁盘，在下一其我会详细介绍直接I/O和缓存I/O。
|
||||
|
||||
|
||||
磁盘。手机上使用的闪存是电子式的存储设备，所以在资料传输过程可能会发生电子遗失等现象导致数据错误。不过闪存也会使用ECC、多级编码等多种方式增加数据的可靠性，一般来说出现这种情况的可能性也比较小。
|
||||
|
||||
|
||||
闪存寿命也可能会导致数据错误，由于闪存的内部结构和特征，导致它写过的地址必须擦除才能再次写入，而每个块擦除又有次数限制，次数限制是根据采用的存储颗粒，从十万次到几千都有（SLC>MLC>TLC）。
|
||||
|
||||
下图是闪存（Flash Memory）的结构图，其中比较重要的是FTL（Flash Translation Layer），它负责物理地址的分配和管理。它需要考虑到每个块的擦除寿命，将擦除次数均衡到所有块上去。当某个块空间不够的时候，它还要通过垃圾回收算法将数据迁移。FTL决定了闪存的使用寿命、性能和可靠性，是闪存技术中最为重要的核心技术之一。
|
||||
|
||||
|
||||
|
||||
对于手机来说，假设我们的存储大小是128GB，即使闪存的最大擦除次数只有1000次，那也可以写入128TB，但一般来说比较难达到。
|
||||
|
||||
疑问二：I/O有时候为什么会突然很慢？
|
||||
|
||||
手机厂商的数据通常都是出厂数据，我们在使用Android手机的时候也会发现，刚买的时候“如丝般顺滑”的手机，在使用一年之后就会变得卡顿无比。
|
||||
|
||||
这是为什么呢？在一些低端机上面，我发现大量跟I/O相关的卡顿。I/O有时候为什么会突然变慢，可能有下面几个原因。
|
||||
|
||||
|
||||
内存不足。当手机内存不足的时候，系统会回收Page Cache和Buffer Cache的内存，大部分的写操作会直接落盘，导致性能低下。
|
||||
|
||||
写入放大。上面我说到闪存重复写入需要先进行擦除操作，但这个擦除操作的基本单元是block块，一个page页的写入操作将会引起整个块数据的迁移，这就是典型的写入放大现象。低端机或者使用比较久的设备，由于磁盘碎片多、剩余空间少，非常容易出现写入放大的现象。具体来说，闪存读操作最快，在20us左右。写操作慢于读操作，在200us左右。而擦除操作非常耗时，在1ms左右的数量级。当出现写入放大时，因为涉及移动数据，这个时间会更长。
|
||||
|
||||
由于低端机的CPU和闪存的性能相对也较差，在高负载的情况下容易出现瓶颈。例如eMMC闪存不支持读写并发，当出现写入放大现象时，读操作也会受影响。
|
||||
|
||||
|
||||
系统为了缓解磁盘碎片问题，可以引入fstrim/TRIM机制，在锁屏、充电等一些时机会触发磁盘碎片整理。
|
||||
|
||||
I/O的性能评估
|
||||
|
||||
正如下图你所看到的，整个I/O的流程涉及的链路非常长。我们在应用程序中通过打点，发现一个文件读取需要300ms。但是下面每一层可能都有自己的策略和调度算法，因此很难真正的得到每一层的耗时。
|
||||
|
||||
|
||||
|
||||
在前面的启动优化内容中，我讲过Facebook和支付宝采用编译单独ROM的方法来评估I/O性能。这是一个比较复杂但是有效的做法，我们可以通过定制源码，选择打开感兴趣的日志来追踪I/O的性能。
|
||||
|
||||
1. I/O性能指标
|
||||
|
||||
I/O性能评估中最为核心的指标是吞吐量和IOPS。今天文章开头所说的，“连续读取不超过550MB/s，连续写入不超过520MB/s”，就指的是I/O吞吐量。
|
||||
|
||||
还有一个比较重要的指标是IOPS，它指的是每秒可以读写的次数。对于随机读写频繁的应用，例如大量的小文件存储，IOPS是关键的衡量指标。
|
||||
|
||||
2. I/O测量
|
||||
|
||||
如果不采用定制源码的方式，还有哪些方法可以用来测量I/O的性能呢？
|
||||
|
||||
第一种方法：使用proc。
|
||||
|
||||
总的来说，I/O性能会跟很多因素有关，是读还是写、是否是连续、I/O大小等。另外一个对I/O性能影响比较大的因素是负载，I/O性能会随着负载的增加而降低，我们可以通过I/O的等待时间和次数来衡量。
|
||||
|
||||
proc/self/schedstat:
|
||||
se.statistics.iowait_count：IO 等待的次数
|
||||
se.statistics.iowait_sum： IO 等待的时间
|
||||
|
||||
|
||||
如果是root的机器，我们可以开启内核的I/O监控，将所有block读写dump到日志文件中，这样可以通过dmesg命令来查看。
|
||||
|
||||
echo 1 > /proc/sys/vm/block_dump
|
||||
dmesg -c grep pid
|
||||
|
||||
.sample.io.test(7540): READ block 29262592 on dm-1 (256 sectors)
|
||||
.sample.io.test(7540): READ block 29262848 on dm-1 (256 sectors)
|
||||
|
||||
|
||||
第二种方法：使用strace。
|
||||
|
||||
Linux提供了iostat、iotop等一些相关的命令，不过大部分Anroid设备都不支持。我们可以通过 strace来跟踪I/O相关的系统调用次数和耗时。
|
||||
|
||||
strace -ttT -f -p [pid]
|
||||
|
||||
read(53, "*****************"\.\.\., 1024) = 1024 <0.000447>
|
||||
read(53, "*****************"\.\.\., 1024) = 1024 <0.000084>
|
||||
read(53, "*****************"\.\.\., 1024) = 1024 <0.000059>
|
||||
|
||||
|
||||
通过上面的日志，你可以看到应用程序在读取文件操作符为53的文件，每次读取1024个字节。第一次读取花了447us，后面两次都使用了100us不到。这跟启动优化提到的“数据重排”是一个原因，文件系统每次读取以block为单位，而block的大小一般是4KB，后面两次的读取是从页缓存得到。
|
||||
|
||||
我们也可以通过strace统计一段时间内所有系统调用的耗时概况。不过strace本身也会消耗不少资源，对执行时间也会产生影响。
|
||||
|
||||
strace -c -f -p [pid]
|
||||
|
||||
% time seconds usecs/call calls errors syscall
|
||||
------ ----------- ----------- --------- --------- ----------------
|
||||
97.56 0.041002 21 1987 read
|
||||
1.44 0.000605 55 11 write
|
||||
|
||||
|
||||
从上面的信息你可以看到，读占了97.56%的时间，一共调用了1987次，耗时0.04s，平均每次系统调用21us。同样的道理，我们也可以计算应用程序某个任务I/O耗时的百分比。假设一个任务执行了10s，I/O花了9s，那么I/O耗时百分比就是90%。这种情况下，I/O就是我们任务很大的瓶颈，需要去做进一步的优化。
|
||||
|
||||
第三种方法：使用vmstat。
|
||||
|
||||
vmstat的各个字段说明可以参考《vmstat监视内存使用情况》，其中Memory中的buff和cache，I/O中的bi和bo，System中的cs，以及CPU中的sy和wa，这些字段的数值都与I/O行为有关。
|
||||
|
||||
|
||||
|
||||
我们可以配合dd命令来配合测试，观察vmstat的输出数据变化。不过需要注意的是Android里面的dd命令似乎并不支持conv和flag参数。
|
||||
|
||||
//清除Buffer和Cache内存缓存
|
||||
echo 3 > /proc/sys/vm/drop_caches
|
||||
//每隔1秒输出1组vmstat数据
|
||||
vmstat 1
|
||||
|
||||
|
||||
//测试写入速度，写入文件/data/data/test，buffer大小为4K，次数为1000次
|
||||
dd if=/dev/zero of=/data/data/test bs=4k count=1000
|
||||
|
||||
|
||||
总结
|
||||
|
||||
在性能优化的过程中，我们关注最多的是CPU和内存，I/O也是性能优化中比较重要的一部分。
|
||||
|
||||
今天我们学习I/O处理的整个流程，它包括应用程序、文件系统和磁盘三个部分。不过I/O这个话题真的很大，在课后需要花更多时间学习课后练习中的一些参考资料。
|
||||
|
||||
LPDDR5、UFS 3.0很快就要在2019年面世，有些同学会想，随着硬件越来越牛，我们根本就不需要去做优化了。但是一方面考虑到成本的问题，在嵌入式、IoT等一些场景的设备硬件不会太好；另一方面，我们对应用体验的要求也越来越高，沉浸体验（VR）、人工智能（AI）等新功能对硬件的要求也越来越高。所以，应用优化是永恒的，只是在不同的场景下有不同的要求。
|
||||
|
||||
课后练习
|
||||
|
||||
学习完今天的内容，可能大部分同学会感觉有点陌生、有点茫然。但是没有关系，我们可以在课后补充更多的基础知识，下面的链接是我推荐给你的参考资料。今天的课后作业是，通过今天的学习，在留言区写写你对I/O的理解，以及你都遇到过哪些I/O方面的问题。
|
||||
|
||||
1.磁盘I/O那些事
|
||||
|
||||
2.Linux 内核的文件 Cache 管理机制介绍
|
||||
|
||||
3.The Linux Kernel/Storage
|
||||
|
||||
4.选eMMC、UFS还是NVMe？ 手机ROM存储传输协议解析
|
||||
|
||||
5.聊聊Linux IO
|
||||
|
||||
6.采用NAND Flash设计存储设备的挑战在哪里?
|
||||
|
||||
“实践出真知”，你也可以尝试使用strace和block_dump来观察自己应用的I/O情况，不过有些实验会要求有root的机器。
|
||||
|
||||
欢迎你点击“请朋友读”，把今天的内容分享给好友，邀请他一起学习。最后别忘了在评论区提交今天的作业，我也为认真完成作业的同学准备了丰厚的“学习加油礼包”，期待与你一起切磋进步哦。
|
||||
|
||||
|
||||
|
||||
|
||||
200
专栏/Android开发高手课/10I_O优化（中）：不同I_O方式的使用场景是什么？.md
Normal file
200
专栏/Android开发高手课/10I_O优化（中）：不同I_O方式的使用场景是什么？.md
Normal file
@ -0,0 +1,200 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
10 I_O优化（中）：不同I_O方式的使用场景是什么？
|
||||
今天是2019年的第一天，在开始今天的学习前，先要祝你新年快乐、工作顺利。
|
||||
|
||||
I/O是一个非常大的话题，很难一次性将每个细节都讲清楚。对于服务器开发者来说，可以根据需要选择合适的文件系统和磁盘类型，也可以根据需要调整内核参数。但对于移动开发者来说，我们看起来好像做不了什么I/O方面的优化？
|
||||
|
||||
事实上并不是这样的，启动优化中“数据重排”就是一个例子。如果我们非常清楚文件系统和磁盘的工作机制，就能少走一些弯路，减少应用程序I/O引发的问题。
|
||||
|
||||
在上一期中，我不止一次的提到Page Cache机制，它很大程度上提升了磁盘I/O的性能，但是也有可能导致写入数据的丢失。那究竟有哪些I/O方式可以选择，又应该如何应用在我们的实际工作中呢？今天我们一起来看看不同I/O方式的使用场景。
|
||||
|
||||
I/O的三种方式
|
||||
|
||||
请你先在脑海里回想一下上一期提到的Linux通用I/O架构模型，里面会包括应用程序、文件系统、Page Cache和磁盘几个部分。细心的同学可能还会发现，在图中的最左侧跟右上方还有Direct I/O和mmap的这两种I/O方式。
|
||||
|
||||
那张图似乎有那么一点复杂，下面我为你重新画了一张简图。从图中可以看到标准I/O、mmap、直接I/O这三种I/O方式在流程上的差异，接下来我详细讲一下不同I/O方式的关键点以及在实际应用中需要注意的地方。
|
||||
|
||||
|
||||
|
||||
1. 标准I/O
|
||||
|
||||
我们应用程序平时用到read/write操作都属于标准I/O，也就是缓存I/O（Buffered I/O）。它的关键特性有：
|
||||
|
||||
|
||||
对于读操作来说，当应用程序读取某块数据的时候，如果这块数据已经存放在页缓存中，那么这块数据就可以立即返回给应用程序，而不需要经过实际的物理读盘操作。
|
||||
|
||||
对于写操作来说，应用程序也会将数据先写到页缓存中去，数据是否被立即写到磁盘上去取决于应用程序所采用写操作的机制。默认系统采用的是延迟写机制，应用程序只需要将数据写到页缓存中去就可以了，完全不需要等数据全部被写回到磁盘，系统会负责定期地将放在页缓存中的数据刷到磁盘上。
|
||||
|
||||
|
||||
从中可以看出来，缓存I/O可以很大程度减少真正读写磁盘的次数，从而提升性能。但是上一期我说过延迟写机制可能会导致数据丢失，那系统究竟会在什么时机真正把页缓存的数据写入磁盘呢？
|
||||
|
||||
Page Cache中被修改的内存称为“脏页”，内核通过flush线程定期将数据写入磁盘。具体写入的条件我们可以通过/proc/sys/vm文件或者sysctl -a | grep vm命令得到。
|
||||
|
||||
// flush每隔5秒执行一次
|
||||
vm.dirty_writeback_centisecs = 500
|
||||
// 内存中驻留30秒以上的脏数据将由flush在下一次执行时写入磁盘
|
||||
vm.dirty_expire_centisecs = 3000
|
||||
// 指示若脏页占总物理内存10％以上，则触发flush把脏数据写回磁盘
|
||||
vm.dirty_background_ratio = 10
|
||||
// 系统所能拥有的最大脏页缓存的总大小
|
||||
vm.dirty_ratio = 20
|
||||
|
||||
|
||||
在实际应用中，如果某些数据我们觉得非常重要，是完全不允许有丢失风险的，这个时候我们应该采用同步写机制。在应用程序中使用sync、fsync、msync等系统调用时，内核都会立刻将相应的数据写回到磁盘。
|
||||
|
||||
|
||||
|
||||
上图中我以read()操作为例，它会导致数据先从磁盘拷贝到Page Cache中，然后再从Page Cache拷贝到应用程序的用户空间，这样就会多一次内存拷贝。系统这样设计主要是因为内存相对磁盘是高速设备，即使多拷贝100次，内存也比真正读一次硬盘要快。
|
||||
|
||||
2. 直接I/O
|
||||
|
||||
很多数据库自己已经做了数据和索引的缓存管理，对页缓存的依赖反而没那么强烈。它们希望可以绕开页缓存机制，这样可以减少一次数据拷贝，这些数据也不会污染页缓存。
|
||||
|
||||
|
||||
|
||||
从图中你可以看到，直接I/O访问文件方式减少了一次数据拷贝和一些系统调用的耗时，很大程度降低了CPU的使用率以及内存的占用。
|
||||
|
||||
不过，直接I/O有时候也会对性能产生负面影响。
|
||||
|
||||
|
||||
对于读操作来说，读数据操作会造成磁盘的同步读，导致进程需要较长的时间才能执行完。
|
||||
|
||||
对于写操作来说，使用直接I/O也需要同步执行，也会导致应用程序等待。
|
||||
|
||||
|
||||
Android并没有提供Java的DirectByteBuffer，直接I/O需要在open()文件的时候需要指定O_DIRECT参数，更多的资料可以参考《Linux 中直接 I/O 机制的介绍》。在使用直接I/O之前，一定要对应用程序有一个很清醒的认识，只有在确定缓冲I/O的开销非常巨大的情况以后，才可以考虑使用直接I/O。
|
||||
|
||||
3. mmap
|
||||
|
||||
Android系统启动加载Dex的时候，不会把整个文件一次性读到内存中，而是采用mmap的方式。微信的高性能日志xlog也是使用mmap来保证性能和可靠性。
|
||||
|
||||
mmap究竟是何方神圣，它是不是真的可以做到不丢失数据、性能还非常好？其实，它是通过把文件映射到进程的地址空间，而网上很多文章都说mmap完全绕开了页缓存机制，其实这并不正确。我们最终映射的物理内存依然在页缓存中，它可以带来的好处有：
|
||||
|
||||
|
||||
减少系统调用。我们只需要一次mmap() 系统调用，后续所有的调用像操作内存一样，而不会出现大量的read/write系统调用。
|
||||
|
||||
减少数据拷贝。普通的read()调用，数据需要经过两次拷贝；而mmap只需要从磁盘拷贝一次就可以了，并且由于做过内存映射，也不需要再拷贝回用户空间。
|
||||
|
||||
可靠性高。mmap把数据写入页缓存后，跟缓存I/O的延迟写机制一样，可以依靠内核线程定期写回磁盘。但是需要提的是，mmap在内核崩溃、突然断电的情况下也一样有可能引起内容丢失，当然我们也可以使用msync来强制同步写。
|
||||
|
||||
|
||||
|
||||
|
||||
从上面的图看来，我们使用mmap仅仅只需要一次数据拷贝。看起来mmap的确可以秒杀普通的文件读写，那我们为什么不全都使用mmap呢？事实上，它也存在一些缺点：
|
||||
|
||||
|
||||
虚拟内存增大。mmap会导致虚拟内存增大，我们的APK、Dex、so都是通过mmap读取。而目前大部分的应用还没支持64位，除去内核使用的地址空间，一般我们可以使用的虚拟内存空间只有3GB左右。如果mmap一个1GB的文件，应用很容易会出现虚拟内存不足所导致的OOM。
|
||||
|
||||
磁盘延迟。mmap通过缺页中断向磁盘发起真正的磁盘I/O，所以如果我们当前的问题是在于磁盘I/O的高延迟，那么用mmap()消除小小的系统调用开销是杯水车薪的。启动优化中讲到的类重排技术，就是将Dex中的类按照启动顺序重新排列，主要为了减少缺页中断造成的磁盘I/O延迟。
|
||||
|
||||
|
||||
在Android中可以将文件通过MemoryFile或者MappedByteBuffer映射到内存，然后进行读写，使用这种方式对于小文件和频繁读写操作的文件还是有一定优势的。我通过简单代码测试，测试结果如下。
|
||||
|
||||
|
||||
|
||||
从上面的数据看起来mmap好像的确跟写内存的性能差不多，但是这并不正确，因为我们并没有计算文件系统异步落盘的耗时。在低端机或者系统资源严重不足的时候，mmap也一样会出现频繁写入磁盘，这个时候性能就会出现快速下降。
|
||||
|
||||
mmap比较适合于对同一块区域频繁读写的情况，推荐也使用线程来操作。用户日志、数据上报都满足这种场景，另外需要跨进程同步的时候，mmap也是一个不错的选择。Android跨进程通信有自己独有的Binder机制，它内部也是使用mmap实现。
|
||||
|
||||
|
||||
|
||||
利用mmap，Binder在跨进程通信只需要一次数据拷贝，比传统的Socket、管道等跨进程通信方式会少一次数据拷贝过程。
|
||||
|
||||
|
||||
|
||||
多线程阻塞I/O和NIO
|
||||
|
||||
我在上一期说过，由于写入放大的现象，特别是在低端机中，有时候I/O操作可能会非常慢。
|
||||
|
||||
所以I/O操作应该尽量放到线程中，不过很多同学可能都有这样一个疑问：如果同时读10个文件，我们应该用单线程还是10个线程并发读？
|
||||
|
||||
1. 多线程阻塞I/O
|
||||
|
||||
我们来做一个实验，使用Nexus 6P读取30个大小为40MB的文件，分别使用不同的线程数量做测试。
|
||||
|
||||
|
||||
|
||||
你可以发现多线程在I/O操作上收益并没有那么大，总时间从3.6秒减少到1.1秒。因为CPU的性能相比磁盘来说就是火箭，I/O操作主要瓶颈在于磁盘带宽，30条线程并不会有30倍的收益。而线程数太多甚至会导致耗时更长，表格中我们就发现30个线程所需要的时间比10个线程更长。但是在CPU繁忙的时候，更多的线程会让我们更有机会抢到时间片，这个时候多线程会比单线程有更大的收益。
|
||||
|
||||
总的来说文件读写受到I/O性能瓶颈的影响，在到达一定速度后整体性能就会受到明显的影响，过多的线程反而会导致应用整体性能的明显下降。
|
||||
|
||||
案例一:
|
||||
CPU: 0.3% user, 3.1% kernel, 60.2% iowait, 36% idle\.\.\.
|
||||
案例二：
|
||||
CPU: 60.3% user, 20.1% kernel, 14.2% iowait, 4.6% idle\.\.\.
|
||||
|
||||
|
||||
你可以再来看上面这两个案例。
|
||||
|
||||
案例一：当系统空闲（36% idle）时，如果没有其他线程需要调度，这个时候才会出现I/O等待（60.2% iowait）。
|
||||
|
||||
案例二：如果我们的系统繁忙起来，这个时候CPU不会“无所事事”，它会去看有没有其他线程需要调度，这个时候I/O等待会降低（14.2% iowait）。但是太多的线程阻塞会导致线程切换频繁，增大系统上下文切换的开销。
|
||||
|
||||
简单来说，iowait高，I/O一定有问题。但iowait低，I/O不一定没有问题。这个时候我们还要看CPU的idle比例。从下图我们可以看到同步I/O的工作模式：
|
||||
|
||||
|
||||
|
||||
对应用程序来说，磁盘I/O阻塞线程的总时间会更加合理，它并不关心CPU是否真的在等待，还是去执行其他工作了。在实际开发工作中，大部分时候都是读一些比较小的文件，使用单独的I/O线程还是专门新开一个线程，其实差别不大。
|
||||
|
||||
2. NIO
|
||||
|
||||
多线程阻塞式I/O会增加系统开销，那我们是否可以使用异步I/O呢？当我们线程遇到I/O操作的时候，不再以阻塞的方式等待I/O操作的完成，而是将I/O请求发送给系统后，继续往下执行。这个过程你可以参考下面的图。
|
||||
|
||||
|
||||
|
||||
非阻塞的NIO将I/O以事件的方式通知，的确可以减少线程切换的开销。Chrome网络库是一个使用NIO提升性能很好的例子，特别是在系统非常繁忙的时候。但是NIO的缺点也非常明显，应用程序的实现会变得更复杂，有的时候异步改造并不容易。
|
||||
|
||||
下面我们来看利用NIO的FileChannel来读写文件。FileChannel需要使用ByteBuffer来读写文件，可以使用ByteBuffer.allocate(int size)分配空间，或者通过ByteBuffer.wrap(byte[])包装byte数组直接生成。上面的示例使用NIO方式在CPU闲和CPU忙时耗时如下。
|
||||
|
||||
|
||||
|
||||
通过上面的数据你可以看到，我们发现使用NIO整体性能跟非NIO差别并不大。这其实也是可以理解的，在CPU闲的时候，无论我们的线程是否继续做其他的工作，当前瓶颈依然在磁盘，整体耗时不会太大。在CPU忙的时候，无论是否使用NIO，单线程可以抢到的CPU时间片依然有限。
|
||||
|
||||
那NIO是不是完全没有作用呢？其实使用NIO的最大作用不是减少读取文件的耗时，而是最大化提升应用整体的CPU利用率。在CPU繁忙的时候，我们可以将线程等待磁盘I/O的时间来做部分CPU操作。非常推荐Square的Okio，它支持同步和异步I/O，也做了比较多优化，你可以尝试使用。
|
||||
|
||||
小文件系统
|
||||
|
||||
对于文件系统来说，目录查找的性能是非常重要的。比如微信朋友圈图片可能有几万张，如果我们每张图片都是一个单独的文件，那目录下就会有几万个小文件，你想想这对I/O的性能会造成什么影响？
|
||||
|
||||
文件的读取需要先找到存储的位置，在文件系统上面我们使用inode来存储目录。读取一个文件的耗时可以拆分成下面两个部分。
|
||||
|
||||
文件读取的时间 = 找到文件的 inode 的时间 + 根据 inode 读取文件数据的时间
|
||||
|
||||
|
||||
如果我们需要频繁读写几万个小文件，查找inode的时间会变得非常可观。这个时间跟文件系统的实现有关。
|
||||
|
||||
|
||||
对于FAT32系统来说，FAT32系统是历史久远的产物，在一些低端机的外置SD卡会使用这个系统。当目录文件数比较多的时候，需要线性去查找，一个exist()都非常容易出现ANR。
|
||||
|
||||
对于ext4系统来说，ext4系统使用目录Hash索引的方式查找，目录查找时间会大大缩短。但是如果需要频繁操作大量的小文件，查找和打开文件的耗时也不能忽视。
|
||||
|
||||
|
||||
大量的小文件合并为大文件后，我们还可以将能连续访问的小文件合并存储，将原本小文件间的随机访问变为了顺序访问，可以大大提高性能。同时合并存储能够有效减少小文件存储时所产生的磁盘碎片问题，提高磁盘的利用率。
|
||||
|
||||
业界中Google的GFS、淘宝开源的TFS、Facebook的Haystack都是专门为海量小文件的存储和检索设计的文件系统。微信也开发了一套叫SFS的小文件管理系统，主要用在朋友圈图片的管理，用于解决当时外置SD卡使用FAT32的性能问题。
|
||||
|
||||
当然设计一个小文件系统也不是那么简单，需要支持VFS接口，这样上层的I/O操作代码并不需要改动。另外需要考虑文件的索引和校验机制，例如如何快速从一个大文件中找到对应的部分。还要考虑文件的分片，比如之前我们发现如果一个文件太大，非常容易被手机管家这些软件删除。
|
||||
|
||||
总结
|
||||
|
||||
在性能优化的过程中，我们通常关注最多的是CPU和内存，但其实I/O也是性能优化中比较重要的一部分。
|
||||
|
||||
今天我们首先学习了I/O整个流程，它包括应用程序、文件系统和磁盘三部分。接着我介绍了多线程同步I/O、异步I/O和mmap这几种I/O方式的差异，以及它们在实际工作中适用的场景。
|
||||
|
||||
无论是文件系统还是磁盘，涉及的细节都非常多。而且随着技术的发展，有些设计就变得过时了，比如FAT32在设计的时候，当时认为单个文件不太可能超过4GB。如果未来某一天，磁盘的性能可以追上内存，那时文件系统就真的不再需要各种缓存了。
|
||||
|
||||
课后练习
|
||||
|
||||
今天我们讲了几种不同的I/O方式的使用场景，在日常工作中，你是否使用过标准I/O以外的其他I/O方式？欢迎留言跟我和其他同学一起讨论。
|
||||
|
||||
在文中我也对不同的I/O方式做了简单性能测试，今天的课后练习是针对不同的场景，请你动手写一些测试用例，这样可以更好地理解不同I/O方式的使用场景。
|
||||
|
||||
欢迎你点击“请朋友读”，把今天的内容分享给好友，邀请他一起学习。最后别忘了在评论区提交今天的作业，我也为认真完成作业的同学准备了丰厚的“学习加油礼包”，期待与你一起切磋进步哦。
|
||||
|
||||
|
||||
|
||||
|
||||
273
专栏/Android开发高手课/11I_O优化（下）：如何监控线上I_O操作？.md
Normal file
273
专栏/Android开发高手课/11I_O优化（下）：如何监控线上I_O操作？.md
Normal file
@ -0,0 +1,273 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
11 I_O优化（下）：如何监控线上I_O操作？
|
||||
通过前面的学习，相信你对I/O相关的基础知识有了一些认识，也了解了测量I/O性能的方法。
|
||||
|
||||
但是在实际应用中，你知道有哪些I/O操作是不合理的吗？我们应该如何发现代码中不合理的I/O操作呢？或者更进一步，我们能否在线上持续监控应用程序中I/O的使用呢？今天我们就一起来看看这些问题如何解决。
|
||||
|
||||
I/O跟踪
|
||||
|
||||
在监控I/O操作之前，你需要先知道应用程序中究竟有哪些I/O操作。
|
||||
|
||||
我在专栏前面讲卡顿优化的中提到过，Facebook的Profilo为了拿到ftrace的信息，使用了PLT Hook技术监听了“atrace_marker_fd”文件的写入。那么还有哪些方法可以实现I/O跟踪，而我们又应该跟踪哪些信息呢？
|
||||
|
||||
1. Java Hook
|
||||
|
||||
出于兼容性的考虑，你可能第一时间想到的方法就是插桩。但是插桩无法监控到所有的I/O操作，因为有大量的系统代码也同样存在I/O操作。
|
||||
|
||||
出于稳定性的考虑，我们退而求其次还可以尝试使用Java Hook方案。以Android 6.0的源码为例，FileInputStream的整个调用流程如下。
|
||||
|
||||
java : FileInputStream -> IoBridge.open -> Libcore.os.open
|
||||
-> BlockGuardOs.open -> Posix.open
|
||||
|
||||
|
||||
在Libcore.java中可以找到一个挺不错的Hook点，那就是BlockGuardOs这一个静态变量。如何可以快速找到合适的Hook点呢？一方面需要靠经验，但是耐心查看和分析源码是必不可少的工作。
|
||||
|
||||
public static Os os = new BlockGuardOs(new Posix());
|
||||
// 反射获得静态变量
|
||||
Class<?> clibcore = Class.forName("libcore.io.Libcore");
|
||||
Field fos = clibcore.getDeclaredField("os");
|
||||
|
||||
|
||||
我们可以通过动态代理的方式，在所有I/O相关方法前后加入插桩代码，统计I/O操作相关的信息。事实上，BlockGuardOs里面还有一些Socket相关的方法，我们也可以用来统计网络相关的请求。
|
||||
|
||||
// 动态代理对象
|
||||
Proxy.newProxyInstance(cPosix.getClassLoader(), getAllInterfaces(cPosix), this);
|
||||
|
||||
beforeInvoke(method, args, throwable);
|
||||
result = method.invoke(mPosixOs, args);
|
||||
afterInvoke(method, args, result);
|
||||
|
||||
|
||||
看起来这个方案好像挺不错的，但在实际使用中很快就发现这个方法有几个缺点。
|
||||
|
||||
|
||||
性能极差。I/O操作调用非常频繁，因为使用动态代理和Java的大量字符串操作，导致性能比较差，无法达到线上使用的标准。
|
||||
|
||||
无法监控Native代码。例如微信中有大量的I/O操作是在Native代码中，使用Java Hook方案无法监控到。
|
||||
|
||||
兼容性差。Java Hook需要每个Android版本去兼容，特别是Android P增加对非公开API限制。
|
||||
|
||||
|
||||
2. Native Hook
|
||||
|
||||
如果Java Hook不能满足需求，我们自然就会考虑Native Hook方案。Profilo使用到是PLT Hook方案，它的性能比GOT Hook要稍好一些，不过GOT Hook的兼容性会更好一些。
|
||||
|
||||
关于几种Native Hook的实现方式与差异，我在后面会花篇幅专门介绍，今天就不展开了。最终是从libc.so中的这几个函数中选定Hook的目标函数。
|
||||
|
||||
int open(const char *pathname, int flags, mode_t mode);
|
||||
ssize_t read(int fd, void *buf, size_t size);
|
||||
ssize_t write(int fd, const void *buf, size_t size); write_cuk
|
||||
int close(int fd);
|
||||
|
||||
|
||||
因为使用的是GOT Hook，我们需要选择一些有调用上面几个方法的library。微信Matrix中选择的是libjavacore.so、libopenjdkjvm.so、libopenjdkjvm.so，可以覆盖到所有的Java层的I/O调用，具体可以参考io_canary_jni.cc。
|
||||
|
||||
不过我更推荐Profilo中atrace.cpp的做法，它直接遍历所有已经加载的library，一并替换。
|
||||
|
||||
void hookLoadedLibs() {
|
||||
auto& functionHooks = getFunctionHooks();
|
||||
auto& seenLibs = getSeenLibs();
|
||||
facebook::profilo::hooks::hookLoadedLibs(functionHooks, seenLibs);
|
||||
}
|
||||
|
||||
|
||||
不同版本的Android系统实现有所不同，在Android 7.0之后，我们还需要替换下面这三个方法。
|
||||
|
||||
open64
|
||||
__read_chk
|
||||
__write_chk
|
||||
|
||||
|
||||
3. 监控内容
|
||||
|
||||
在实现I/O跟踪后，我们需要进一步思考需要监控哪些I/O信息。假设读取一个文件，我们希望知道这个文件的名字、原始大小、打开文件的堆栈、使用了什么线程这些基本信息。
|
||||
|
||||
接着我们还希望得到这一次操作一共使用了多长时间，使用的Buffer是多大的。是一次连续读完的，还是随机的读取。通过上面Hook的四个接口，我们可以很容易的采集到这些信息。
|
||||
|
||||
|
||||
|
||||
下面是一次I/O操作的基本信息，在主线程对一个大小为600KB的“test.db”文件。
|
||||
|
||||
|
||||
|
||||
使用了4KB的Buffer，连续读取150次，一次性把整个文件读完，整体的耗时是10ms。因为连读读写时间和打开文件的总时间相同，我们可以判断出这次read()操作是一气呵成的，中间没有间断。
|
||||
|
||||
|
||||
|
||||
因为I/O操作真的非常频繁，采集如此多的信息，对应用程序的性能会造成多大的影响呢？我们可以看看是否使用Native Hook的耗时数据。
|
||||
|
||||
|
||||
|
||||
你可以看到采用Native Hook的监控方法性能损耗基本可以忽略，这套方案可以用于线上。
|
||||
|
||||
线上监控
|
||||
|
||||
通过Native Hook方式可以采集到所有的I/O相关的信息，但是采集到的信息非常多，我们不可能把所有信息都上报到后台进行分析。
|
||||
|
||||
对于I/O的线上监控，我们需要进一步抽象出规则，明确哪些情况可以定义为不良情况，需要上报到后台，进而推动开发去解决。
|
||||
|
||||
|
||||
|
||||
1. 主线程I/O
|
||||
|
||||
我不止一次说过，有时候I/O的写入会突然放大，即使是几百KB的数据，还是尽量不要在主线程上操作。在线上也会经常发现一些I/O操作明明数据量不大，但是最后还是ANR了。
|
||||
|
||||
当然如果把所有的主线程I/O都收集上来，这个数据量会非常大，所以我会添加“连续读写时间超过100毫秒”这个条件。之所以使用连续读写时间，是因为发现有不少案例是打开了文件句柄，但不是一次读写完的。
|
||||
|
||||
在上报问题到后台时，为了能更好地定位解决问题，我通常还会把CPU使用率、其他线程的信息以及内存信息一并上报，辅助分析问题。
|
||||
|
||||
2. 读写Buffer过小
|
||||
|
||||
我们知道，对于文件系统是以block为单位读写，对于磁盘是以page为单位读写，看起来即使我们在应用程序上面使用很小的Buffer，在底层应该差别不大。那是不是这样呢？
|
||||
|
||||
read(53, "*****************"\.\.\., 1024) = 1024 <0.000447>
|
||||
read(53, "*****************"\.\.\., 1024) = 1024 <0.000084>
|
||||
read(53, "*****************"\.\.\., 1024) = 1024 <0.000059>
|
||||
|
||||
|
||||
虽然后面两次系统调用的时间的确会少一些，但是也会有一定的耗时。如果我们的Buffer太小，会导致多次无用的系统调用和内存拷贝，导致read/write的次数增多，从而影响了性能。
|
||||
|
||||
那应该选用多大的Buffer呢？我们可以跟据文件保存所挂载的目录的block size来确认Buffer大小，数据库中的pagesize就是这样确定的。
|
||||
|
||||
new StatFs("/data").getBlockSize()
|
||||
|
||||
|
||||
所以我们最终选择的判断条件为：
|
||||
|
||||
|
||||
buffer size小于block size，这里一般为4KB。
|
||||
|
||||
read/write的次数超过一定的阈值，例如5次，这主要是为了减少上报量。
|
||||
|
||||
|
||||
buffer size不应该小于4KB，那它是不是越大越好呢？你可以通过下面的命令做一个简单的测试，读取测试应用的iotest文件，它的大小是40M。其中bs就是buffer size，bs分别使用不同的值，然后观察耗时。
|
||||
|
||||
// 每次测试之前需要手动释放缓存
|
||||
echo 3 > /proc/sys/vm/drop_caches
|
||||
time dd if=/data/data/com.sample.io/files/iotest of=/dev/null bs=4096
|
||||
|
||||
|
||||
|
||||
|
||||
通过上面的数据大致可以看出来，Buffer的大小对文件读写的耗时有非常大的影响。耗时的减少主要得益于系统调用与内存拷贝的优化，Buffer的大小一般我推荐使用4KB以上。
|
||||
|
||||
在实际应用中，ObjectOutputStream和ZipOutputStream都是一个非常经典的例子，ObjectOutputStream使用的buffer size非常小。而ZipOutputStream会稍微复杂一些，如果文件是Stored方式存储的，它会使用上层传入的buffer size。如果文件是Deflater方式存储的，它会使用DeflaterOutputStream的buffer size，这个大小默认是512Byte。
|
||||
|
||||
你可以看到，如果使用BufferInputStream或者ByteArrayOutputStream后整体性能会有非常明显的提升。
|
||||
|
||||
|
||||
|
||||
正如我上一期所说的，准确评估磁盘真实的读写次数是比较难的。磁盘内部也会有很多的策略，例如预读。它可能发生超过你真正读的内容，预读在有大量顺序读取磁盘的时候，readahead可以大幅提高性能。但是大量读取碎片小文件的时候，可能又会造成浪费。
|
||||
|
||||
你可以通过下面的这个文件查看预读的大小，一般是128KB。
|
||||
|
||||
/sys/block/[disk]/queue/read_ahead_kb
|
||||
|
||||
|
||||
一般来说，我们可以利用/proc/sys/vm/block_dump或者/proc/diskstats的信息统计真正的磁盘读写次数。
|
||||
|
||||
/proc/diskstats
|
||||
块设备名字|读请求次数|读请求扇区数|读请求耗时总和\.\.\.\.
|
||||
dm-0 23525 0 1901752 45366 0 0 0 0 0 33160 57393
|
||||
dm-1 212077 0 6618604 430813 1123292 0 55006889 3373820 0 921023 3805823
|
||||
|
||||
|
||||
3. 重复读
|
||||
|
||||
微信之前在做模块化改造的时候，因为模块间彻底解耦了，很多模块会分别去读一些公共的配置文件。
|
||||
|
||||
有同学可能会说，重复读的时候数据都是从Page Cache中拿到，不会发生真正的磁盘操作。但是它依然需要消耗系统调用和内存拷贝的时间，而且Page Cache的内存也很有可能被替换或者释放。
|
||||
|
||||
你也可以用下面这个命令模拟Page Cache的释放。
|
||||
|
||||
echo 3 > /proc/sys/vm/drop_caches
|
||||
|
||||
|
||||
如果频繁地读取某个文件，并且这个文件一直没有被写入更新，我们可以通过缓存来提升性能。不过为了减少上报量，我会增加以下几个条件：
|
||||
|
||||
|
||||
重复读取次数超过3次，并且读取的内容相同。
|
||||
|
||||
读取期间文件内容没有被更新，也就是没有发生过write。
|
||||
|
||||
|
||||
加一层内存cache是最直接有效的办法，比较典型的场景是配置文件等一些数据模块的加载，如果没有内存cache，那么性能影响就比较大了。
|
||||
|
||||
public String readConfig() {
|
||||
if (Cache != null) {
|
||||
return cache;
|
||||
}
|
||||
cache = read("configFile");
|
||||
return cache;
|
||||
}
|
||||
|
||||
|
||||
4. 资源泄漏
|
||||
|
||||
在崩溃分析中，我说过有部分的OOM是由于文件句柄泄漏导致。资源泄漏是指打开资源包括文件、Cursor等没有及时close，从而引起泄露。这属于非常低级的编码错误，但却非常普遍存在。
|
||||
|
||||
如何有效的监控资源泄漏？这里我利用了Android框架中的StrictMode，StrictMode利用CloseGuard.java类在很多系统代码已经预置了埋点。
|
||||
|
||||
到了这里，接下来还是查看源码寻找可以利用的Hook点。这个过程非常简单，CloseGuard中的REPORTER对象就是一个可以利用的点。具体步骤如下：
|
||||
|
||||
|
||||
利用反射，把CloseGuard中的ENABLED值设为true。
|
||||
|
||||
利用动态代理，把REPORTER替换成我们定义的proxy。
|
||||
|
||||
|
||||
虽然在Android源码中，StrictMode已经预埋了很多的资源埋点。不过肯定还有埋点是没有的，比如MediaPlayer、程序内部的一些资源模块。所以在程序中也写了一个MyCloseGuard类，对希望增加监控的资源，可以手动增加埋点代码。
|
||||
|
||||
I/O与启动优化
|
||||
|
||||
通过I/O跟踪，可以拿到整个启动过程所有I/O操作的详细信息列表。我们需要更加的苛刻地检查每一处I/O调用，检查清楚是否每一处I/O调用都是必不可少的，特别是write()。
|
||||
|
||||
当然主线程I/O、读写Buffer、重复读以及资源泄漏是首先需要解决的，特别是重复读，比如cpuinfo、手机内存这些信息都应该缓存起来。
|
||||
|
||||
对于必不可少的I/O操作，我们需要思考是否有其他方式做进一步的优化。
|
||||
|
||||
|
||||
对大文件使用mmap或者NIO方式。MappedByteBuffer就是Java NIO中的mmap封装，正如上一期所说，对于大文件的频繁读写会有比较大的优化。
|
||||
|
||||
安装包不压缩。对启动过程需要的文件，我们可以指定在安装包中不压缩，这样也会加快启动速度，但带来的影响是安装包体积增大。事实上Google Play非常希望我们不要去压缩library、resource、resource.arsc这些文件，这样对启动的内存和速度都会有很大帮助。而且不压缩文件带来只是安装包体积的增大，对于用户来说，Download size并没有增大。
|
||||
|
||||
Buffer复用。我们可以利用Okio开源库，它内部的ByteString和Buffer通过重用等技巧，很大程度上减少CPU和内存的消耗。
|
||||
|
||||
存储结构和算法的优化。是否可以通过算法或者数据结构的优化，让我们可以尽量的少I/O甚至完全没有I/O。比如一些配置文件从启动完全解析，改成读取时才解析对应的项；替换掉XML、JSON这些格式比较冗余、性能比较较差的数据结构，当然在接下来我还会对数据存储这一块做更多的展开。
|
||||
|
||||
|
||||
2013年我在做Multidex优化的时候，发现代码中会先将classes2.dex从APK文件中解压出来，然后再压缩到classes2.zip文件中。classes2.dex做了一次无用的解压和压缩，其实根本没有必要。
|
||||
|
||||
|
||||
|
||||
那个时候通过研究ZIP格式的源码，我发现只要能构造出一个符合ZIP格式的文件，那就可以直接将classses2.dex的压缩流搬到classes2.zip中。整个过程没有任何一次解压和压缩，这个技术也同样应用到Tinker的资源合成中。
|
||||
|
||||
总结
|
||||
|
||||
今天我们学习了如何在应用层面监控I/O的使用情况，从实现上尝试了Java Hook和Native Hook两种方案，最终考虑到性能和兼容性，选择了Native Hook方案。
|
||||
|
||||
对于Hook方案的选择，在同等条件下我会优先选择Java Hook方案。但无论采用哪种Hook方案，我们都需要耐心地查看源码、分析调用流程，从而寻找可以利用的地方。
|
||||
|
||||
一套监控方案是只用在实验室自动化测试，还是直接交给用户线上使用，这两者的要求是不同的，后者需要99.9%稳定性，还要具备不影响用户体验的高性能才可以上线。从实验室到线上，需要大量的灰度测试以及反复的优化迭代过程。
|
||||
|
||||
课后练习
|
||||
|
||||
微信的性能监控分析工具Matrix终于开源了，文中大部分内容都是基于matrix-io-canary的分析。今天的课后作业是尝试接入I/O Canary，查看一下自己的应用是否存在I/O相关的问题，请你在留言区跟同学们分享交流一下你的经验。
|
||||
|
||||
是不是觉得非常简单？我还有一个进阶的课后练习。在io_canary_jni.cc中发现目前Matrix只监控了主线程的I/O运行情况，这主要为了解决多线程同步问题。
|
||||
|
||||
//todo 解决非主线程打开，主线程操作问题
|
||||
int ProxyOpen(const char *pathname, int flags, mode_t mode) {
|
||||
|
||||
|
||||
事实上其他线程使用I/O不当，也会影响到应用的性能，“todo = never do”，今天就请你来尝试解决这个问题吧。但是考虑到性能的影响，我们不能简单地直接加锁。针对这个case是否可以做到完全无锁的线程安全，或者可以尽量降低锁的粒度呢？我邀请你一起来研究这个问题，给Matrix提交Pull request，参与到开源的事业中吧。
|
||||
|
||||
欢迎你点击“请朋友读”，把今天的内容分享给好友，邀请他一起学习。最后别忘了在评论区提交今天的作业，我也为认真完成作业的同学准备了丰厚的“学习加油礼包”，期待与你一起切磋进步哦。
|
||||
|
||||
|
||||
|
||||
|
||||
200
专栏/Android开发高手课/12存储优化（上）：常见的数据存储方法有哪些？.md
Normal file
200
专栏/Android开发高手课/12存储优化（上）：常见的数据存储方法有哪些？.md
Normal file
@ -0,0 +1,200 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
12 存储优化（上）：常见的数据存储方法有哪些？
|
||||
通过专栏前面我讲的I/O优化基础知识，相信你肯定了解了文件系统和磁盘的一些机制，以及不同I/O方式的使用场景以及优缺点，并且可以掌握如何在线上监控I/O操作。
|
||||
|
||||
万丈高楼平地起，在理解并掌握这些基础知识的同时，你肯定还想知道如何利用这些知识指导我们写出更好的代码。
|
||||
|
||||
今天我来结合Android系统的一些特性，讲讲开发过程中常见存储方法的优缺点，希望可以帮你在日常工作中如何做出更好的选择。
|
||||
|
||||
Android的存储基础
|
||||
|
||||
在讲具体的存储方法之前，我们应该对Android系统存储相关的一些基础知识有所了解。
|
||||
|
||||
1. Android分区
|
||||
|
||||
I/O优化中讲到的大部分知识更侧重Linux系统，对于Android来说，我们首先应该对Android分区的架构和作用有所了解。在我们熟悉的Windows世界中，我们一般都把系统安装在C盘，然后还会有几个用来存放应用程序和数据的分区。
|
||||
|
||||
Android系统可以通过/proc/partitions或者df命令来查看的各个分区情况，下图是Nexus 6中df命令的运行结果。
|
||||
|
||||
|
||||
|
||||
什么是分区呢？分区简单来说就是将设备中的存储划分为一些互不重叠的部分，每个部分都可以单独格式化，用作不同的目的。这样系统就可以灵活的针对单独分区做不同的操作，例如在系统还原（recovery）过程，我们不希望会影响到用户存储的数据。
|
||||
|
||||
|
||||
|
||||
从上面的表中你可以看到，每个分区非常独立，不同的分区可以使用的不同的文件系统。其中比较重要的有：
|
||||
|
||||
|
||||
/system分区：它是存放所有Google提供的Android组件的地方。这个分区只能以只读方式mount。这样主要基于稳定性和安全性考虑，即使发生用户突然断电的情况，也依然需要保证/system分区的内容不会受到破坏和篡改。
|
||||
|
||||
/data分区：它是所有用户数据存放的地方。主要为了实现数据隔离，即系统升级和恢复的时候会擦除整个/system分区，但是却不会影响/data的用户数据。而恢复出厂设置，只会擦除/data的数据。
|
||||
|
||||
/vendor分区：它是存放厂商特殊系统修改的地方。特别是在Android 8.0以后，隆重推出了“Treble”项目。厂商OTA时可以只更新自己的/vendor分区即可，让厂商能够以更低的成本，更轻松、更快速地将设备更新到新版Android系统。
|
||||
|
||||
|
||||
2. Android存储安全
|
||||
|
||||
除了数据的分区隔离，存储安全也是Android系统非常重要的一部分，存储安全首先考虑的是权限控制。
|
||||
|
||||
第一，权限控制
|
||||
|
||||
Android的每个应用都在自己的应用沙盒内运行，在 Android 4.3之前的版本中，这些沙盒使用了标准Linux的保护机制，通过为每个应用创建独一无二的Linux UID来定义。简单来说，我们需要保证微信不能访问淘宝的数据，并且在没有权限的情况下也不能访问系统的一些保护文件。
|
||||
|
||||
在Android 4.3引入了SELinux（Security Enhanced Linux）机制进一步定义Android应用沙盒的边界。那它有什么特别的呢？它的作用是即使我们进程有root权限也不能为所欲为，如果想在SELinux系统中干任何事情，都必须先在专门的安全策略配置文件中赋予权限。
|
||||
|
||||
第二，数据加密
|
||||
|
||||
除了权限的控制，用户还会担心在手机丢失或者被盗导致个人隐私数据泄露。加密或许是一个不错的选择，它可以保护丢失或被盗设备上的数据。
|
||||
|
||||
Android有两种设备加密方法：全盘加密和文件级加密。全盘加密是在Android 4.4中引入的，并在Android 5.0中默认打开。它会将/data分区的用户数据操作加密/解密，对性能会有一定的影响，但是新版本的芯片都会在硬件中提供直接支持。
|
||||
|
||||
我们知道，基于文件系统的加密，如果设备被解锁了，加密也就没有用了。所以Android 7.0增加了基于文件的加密。在这种加密模式下，将会给每个文件都分配一个必须用用户的passcode推导出来的密钥。特定的文件被屏幕锁屏之后，直到用户下一次解锁屏幕期间都不能访问。
|
||||
|
||||
可能有些同学会问了，Android的这两种设备加密方法跟应用的加密有什么不同，我们在应用存储还需要单独的给敏感文件加密吗？
|
||||
|
||||
我想说的是，设备加密方法对应用程序来说是透明的，它保证我们读取到的是解密后的数据。对于应用程序特别敏感的数据，我们也需要采用RSA、AES、chacha20等常用方式做进一步的存储加密。
|
||||
|
||||
常见的数据存储方法
|
||||
|
||||
Android为我们提供了很多种持久化存储的方案，在具体介绍它们之前，你需要先问一下自己，什么是存储？
|
||||
|
||||
每个人可能都会有自己的答案，在我看来，存储就是把特定的数据结构转化成可以被记录和还原的格式，这个数据格式可以是二进制的，也可以是XML、JSON、Protocol Buffer这些格式。
|
||||
|
||||
对于闪存来说，一切归根到底还是二进制的，XML、JSON它们只是提供了一套通用的二进制编解码格式规范。既然有那么多存储的方案，那我们在选择数据存储方法时，一般需要考虑哪些关键要素呢？
|
||||
|
||||
1. 关键要素
|
||||
|
||||
在选择数据存储方法时，我一般会想到下面这几点，我把它们总结给你。
|
||||
|
||||
|
||||
|
||||
那上面这些要素哪个最重要呢？数据存储方法不能脱离场景来考虑，我们不可能把这六个要素都做成最完美。
|
||||
|
||||
我来解释一下这句话。如果首要考虑的是正确性，那我们可能需要采用冗余、双写等方案，那就要容忍对时间开销产生的额外影响。同样如果非常在意安全，加解密环节的开销也必不可小。如果想针对启动场景，我们希望选择在初始化时间和读取时间更有优势的方案。
|
||||
|
||||
2. 存储选项
|
||||
|
||||
总的来说，我们需要结合应用场景选择合适的数据存储方法。那Android为应用开发者提供了哪些存储数据的方法呢？你可以参考存储选项，综合来看，有下面几种方法。
|
||||
|
||||
|
||||
SharedPreferences
|
||||
|
||||
ContentProvider
|
||||
|
||||
文件
|
||||
|
||||
数据库
|
||||
|
||||
|
||||
今天我先来讲SharedPreferences和ContentProvider这两个存储方法，文件和数据库将放到“存储优化”后面两期来讲。
|
||||
|
||||
第一，SharedPreferences的使用。
|
||||
|
||||
SharedPreferences是Android中比较常用的存储方法，它可以用来存储一些比较小的键值对集合。
|
||||
|
||||
虽然SharedPreferences使用非常简便，但也是我们诟病比较多的存储方法。它的性能问题比较多，我可以轻松地说出它的“七宗罪”。
|
||||
|
||||
|
||||
跨进程不安全。由于没有使用跨进程的锁，就算使用MODE_MULTI_PROCESS，SharedPreferences在跨进程频繁读写有可能导致数据全部丢失。根据线上统计，SP大约会有万分之一的损坏率。
|
||||
|
||||
加载缓慢。SharedPreferences文件的加载使用了异步线程，而且加载线程并没有设置线程优先级，如果这个时候主线程读取数据就需要等待文件加载线程的结束。这就导致出现主线程等待低优先级线程锁的问题，比如一个100KB的SP文件读取等待时间大约需要50~100ms，我建议提前用异步线程预加载启动过程用到的SP文件。
|
||||
|
||||
全量写入。无论是调用commit()还是apply()，即使我们只改动其中的一个条目，都会把整个内容全部写到文件。而且即使我们多次写入同一个文件，SP也没有将多次修改合并为一次，这也是性能差的重要原因之一。
|
||||
|
||||
卡顿。由于提供了异步落盘的apply机制，在崩溃或者其他一些异常情况可能会导致数据丢失。所以当应用收到系统广播，或者被调用onPause等一些时机，系统会强制把所有的SharedPreferences对象数据落地到磁盘。如果没有落地完成，这时候主线程会被一直阻塞。这样非常容易造成卡顿，甚至是ANR，从线上数据来看SP卡顿占比一般会超过5%。
|
||||
|
||||
|
||||
讲到这里，如果你对SharedPreferences机制还不熟悉的话，可以参考《彻底搞懂SharedPreferences》。
|
||||
|
||||
坦白来讲，系统提供的SharedPreferences的应用场景是用来存储一些非常简单、轻量的数据。我们不要使用它来存储过于复杂的数据，例如HTML、JSON等。而且SharedPreference的文件存储性能与文件大小相关，每个SP文件不能过大，我们不要将毫无关联的配置项保存在同一个文件中，同时考虑将频繁修改的条目单独隔离出来。
|
||||
|
||||
我们也可以替换通过复写Application的getSharedPreferences方法替换系统默认实现，比如优化卡顿、合并多次apply操作、支持跨进程操作等。具体如何替换呢？在今天的Sample中我也提供了一个简单替换实现。
|
||||
|
||||
public class MyApplication extends Application {
|
||||
@Override
|
||||
public SharedPreferences getSharedPreferences(String name, int mode)
|
||||
{
|
||||
return SharedPreferencesImpl.getSharedPreferences(name, mode);
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
对系统提供的SharedPreferences的小修小补虽然性能有所提升，但是依然不能彻底解决问题。基本每个大公司都会自研一套替代的存储方案，比如微信最近就开源了MMKV。
|
||||
|
||||
下面是MMKV对于SharedPreferences的“六要素”对比。
|
||||
|
||||
|
||||
|
||||
你可以参考MMKV的实现原理和性能测试报告，里面有一些非常不错的思路。例如利用文件锁保证跨进程的安全、使用mmap保证数据不会丢失、选用性能和存储空间更好的Protocol Buffer代替XML、支持增量更新等。
|
||||
|
||||
根据I/O优化的分析，对于频繁修改的配置使用mmap的确非常合适，使用者不用去理解apply()和commit()的差别，也不用担心数据的丢失。同时，我们也不需要每次都提交整个文件，整体性能会有很大提升。
|
||||
|
||||
第二，ContentProvider的使用。
|
||||
|
||||
为什么Android系统不把SharedPreferences设计成跨进程安全的呢？那是因为Android系统更希望我们在这个场景选择使用ContentProvider作为存储方式。ContentProvider作为Android四大组件中的一种，为我们提供了不同进程甚至是不同应用程序之间共享数据的机制。
|
||||
|
||||
Android系统中比如相册、日历、音频、视频、通讯录等模块都提供了ContentProvider的访问支持。它的使用十分简单，你可以参考官方文档。
|
||||
|
||||
当然，在使用过程也有下面几点需要注意。
|
||||
|
||||
|
||||
启动性能
|
||||
|
||||
|
||||
ContentProvider的生命周期默认在Application onCreate()之前，而且都是在主线程创建的。我们自定义的ContentProvider类的构造函数、静态代码块、onCreate函数都尽量不要做耗时的操作，会拖慢启动速度。
|
||||
|
||||
|
||||
|
||||
可能很多同学都不知道ContentProvider还有一个多进程模式，它可以和AndroidManifest中的multiprocess属性结合使用。这样调用进程会直接在自己进程里创建一个push进程的Provider实例，就不需要跨进程调用了。需要注意的是，这样也会带来Provider的多实例问题。
|
||||
|
||||
|
||||
稳定性
|
||||
|
||||
|
||||
ContentProvider在进行跨进程数据传递时，利用了Android的Binder和匿名共享内存机制。简单来说，就是通过Binder传递CursorWindow对象内部的匿名共享内存的文件描述符。这样在跨进程传输中，结果数据并不需要跨进程传输，而是在不同进程中通过传输的匿名共享内存文件描述符来操作同一块匿名内存，这样来实现不同进程访问相同数据的目的。
|
||||
|
||||
|
||||
|
||||
正如我前面I/O优化所讲的，基于mmap的匿名共享内存机制也是有代价的。当传输的数据量非常小的时候，可能不一定划算。所以ContentProvider提供了一种call函数，它会直接通过Binder来传输数据。
|
||||
|
||||
Android的Binder传输是有大小限制的，一般来说限制是1~2MB。ContentProvider的接口调用参数和call函数调用并没有使用匿名共享机制，比如要批量插入很多数据，那么就会出现一个插入数据的数组，如果这个数组太大了，那么这个操作就可能会出现数据超大异常。
|
||||
|
||||
|
||||
安全性
|
||||
|
||||
|
||||
虽然ContentProvider为应用程序之间的数据共享提供了很好的安全机制，但是如果ContentProvider是exported，当支持执行SQL语句时就需要注意SQL注入的问题。另外如果我们传入的参数是一个文件路径，然后返回文件的内容，这个时候也要校验合法性，不然整个应用的私有数据都有可能被别人拿到，在intent传递参数的时候可能经常会犯这个错误。
|
||||
|
||||
最后我给你总结一下ContentProvider的“六要素”优缺点。
|
||||
|
||||
|
||||
|
||||
总的来说，ContentProvider这套方案实现相对比较笨重，适合传输大的数据。
|
||||
|
||||
总结
|
||||
|
||||
虽然SharedPreferences和ContentProvider都是我们日常经常使用的存储方法，但是里面的确会有大大小小的暗坑。所以我们需要充分了解它们的优缺点，这样在工作中可以更好地使用和优化。
|
||||
|
||||
如何在合适的场景选择合适的存储方法是存储优化的必修课，你应该学会通过正确性、时间开销、空间开销、安全、开发成本以及兼容性这六大关键要素来分解某个存储方法。
|
||||
|
||||
在设计某个存储方案的时候也是同样的道理，我们无法同时把所有的要素都做得最好，因此要学会取舍和选择，在存储的世界里不存在全局最优解，我们要找的是局部的最优解。这个时候更应明确自己的诉求，大胆牺牲部分关键点的指标，将自己场景最关心的要素点做到最好。
|
||||
|
||||
课后作业
|
||||
|
||||
下面是MMKV给出的性能测试报告，你可以看到跟系统的SharedPreferences相比，主要差距在于写的速度。
|
||||
|
||||
|
||||
|
||||
没有实践就没有发言权，今天我们一起来尝试测试对比MMKV与系统SharedPreferences的性能差异。请将你的测试结果和分析体会，写在留言区跟同学们分享交流吧。
|
||||
|
||||
今天的练习Sample是通过复写Application的getSharedPreferences方法替换系统默认实现，这种方式虽然不是最好的方法，不过它主要的优点在于代码的侵入性比较低，无需修改太多的代码。
|
||||
|
||||
欢迎你点击“请朋友读”，把今天的内容分享给好友，邀请他一起学习。最后别忘了在评论区提交今天的作业，我也为认真完成作业的同学准备了丰厚的“学习加油礼包”，期待与你一起切磋进步哦。
|
||||
|
||||
|
||||
|
||||
|
||||
259
专栏/Android开发高手课/13存储优化（中）：如何优化数据存储？.md
Normal file
259
专栏/Android开发高手课/13存储优化（中）：如何优化数据存储？.md
Normal file
@ -0,0 +1,259 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
13 存储优化（中）：如何优化数据存储？
|
||||
“将特定结构的数据转化为另一种能被记录和还原的格式”，这是我在上一期对存储下的一个定义。
|
||||
|
||||
再来复习一下数据存储的六个关键要素：正确性、时间开销、空间开销、安全、开发成本和兼容性。我们不可能同时把所有要素都做到最好，所谓数据存储优化就是根据自己的使用场景去把其中的一项或者几项做到最好。
|
||||
|
||||
更宽泛来讲，我认为数据存储不一定就是将数据存放到磁盘中，比如放到内存中、通过网络传输也可以算是存储的一种形式。或者我们也可以把这个过程叫作对象或者数据的序列化。
|
||||
|
||||
对于大部分的开发者来说，我们不一定有精力去“创造”一种数据序列化的格式，所以我今天主要来讲讲Android常用的序列化方法如何进行选择。
|
||||
|
||||
对象的序列化
|
||||
|
||||
应用程序中的对象存储在内存中，如果我们想把对象存储下来或者在网络上传输，这个时候就需要用到对象的序列化和反序列化。
|
||||
|
||||
对象序列化就是把一个Object对象所有的信息表示成一个字节序列，这包括Class信息、继承关系信息、访问权限、变量类型以及数值信息等。
|
||||
|
||||
1. Serializable
|
||||
|
||||
Serializable是Java原生的序列化机制，在Android中也有被广泛使用。我们可以通过Serializable将对象持久化存储，也可以通过Bundle传递Serializable的序列化数据。
|
||||
|
||||
Serializable的原理
|
||||
|
||||
Serializable的原理是通过ObjectInputStream和ObjectOutputStream来实现的，我们以Android 6.0的源码为例，你可以看到ObjectOutputStream的部分源码实现：
|
||||
|
||||
private void writeFieldValues(Object obj, ObjectStreamClass classDesc) {
|
||||
for (ObjectStreamField fieldDesc : classDesc.fields()) {
|
||||
...
|
||||
Field field = classDesc.checkAndGetReflectionField(fieldDesc);
|
||||
...
|
||||
|
||||
|
||||
整个序列化过程使用了大量的反射和临时变量，而且在序列化对象的时候，不仅会序列化当前对象本身，还需要递归序列化对象引用的其他对象。
|
||||
|
||||
整个过程计算非常复杂，而且因为存在大量反射和GC的影响，序列化的性能会比较差。另外一方面因为序列化文件需要包含的信息非常多，导致它的大小比Class文件本身还要大很多，这样又会导致I/O读写上的性能问题。
|
||||
|
||||
Serializable的进阶
|
||||
|
||||
既然Serializable性能那么差，那它有哪些优势呢？可能很多同学都不知道它还有一些进阶的用法，你可以参考《Java 对象序列化，您不知道的 5 件事》这篇文章。
|
||||
|
||||
|
||||
writeObject和readObject方法。Serializable序列化支持替代默认流程，它会先反射判断是否存在我们自己实现的序列化方法writeObject或反序列化方法readObject。通过这两个方法，我们可以对某些字段做一些特殊修改，也可以实现序列化的加密功能。
|
||||
|
||||
writeReplace和readResolve方法。这两个方法代理序列化的对象，可以实现自定义返回的序列化实例。那它有什么用呢？我们可以通过它们实现对象序列化的版本兼容，例如通过readResolve方法可以把老版本的序列化对象转换成新版本的对象类型。
|
||||
|
||||
|
||||
Serializable的序列化与反序列化的调用流程如下。
|
||||
|
||||
// 序列化
|
||||
E/test:SerializableTestData writeReplace
|
||||
E/test:SerializableTestData writeObject
|
||||
|
||||
// 反序列化
|
||||
E/test:SerializableTestData readObject
|
||||
E/test:SerializableTestData readResolve
|
||||
|
||||
|
||||
Serializable的注意事项
|
||||
|
||||
Serializable虽然使用非常简单，但是也有一些需要注意的事项字段。
|
||||
|
||||
|
||||
不被序列化的字段。类的static变量以及被声明为transient的字段，默认的序列化机制都会忽略该字段，不会进行序列化存储。当然我们也可以使用进阶的writeReplace和readResolve方法做自定义的序列化存储。
|
||||
|
||||
serialVersionUID。在类实现了Serializable接口后，我们需要添加一个Serial Version ID，它相当于类的版本号。这个ID我们可以显式声明也可以让编译器自己计算。通常我建议显式声明会更加稳妥，因为隐式声明假如类发生了一点点变化，进行反序列化都会由于serialVersionUID改变而导致InvalidClassException异常。
|
||||
|
||||
构造方法。Serializable的反序列默认是不会执行构造函数的，它是根据数据流中对Object的描述信息创建对象的。如果一些逻辑依赖构造函数，就可能会出现问题，例如一个静态变量只在构造函数中赋值，当然我们也可以通过进阶方法做自定义的反序列化修改。
|
||||
|
||||
|
||||
2. Parcelable
|
||||
|
||||
由于Java的Serializable的性能较低，Android需要重新设计一套更加轻量且高效的对象序列化和反序列化机制。Parcelable正是在这个背景下产生的，它核心的作用就是为了解决Android中大量跨进程通信的性能问题。
|
||||
|
||||
Parcelable的永久存储
|
||||
|
||||
Parcelable的原理十分简单，它的核心实现都在Parcel.cpp。
|
||||
|
||||
你可以发现Parcel序列化和Java的Serializable序列化差别还是比较大的，Parcelable只会在内存中进行序列化操作，并不会将数据存储到磁盘里。
|
||||
|
||||
当然我们也可以通过Parcel.java的marshall接口获取byte数组，然后存在文件中从而实现Parcelable的永久存储。
|
||||
|
||||
// Returns the raw bytes of the parcel.
|
||||
public final byte[] marshall() {
|
||||
return nativeMarshall(mNativePtr);
|
||||
}
|
||||
// Set the bytes in data to be the raw bytes of this Parcel.
|
||||
public final void unmarshall(byte[] data, int offset, int length) {
|
||||
nativeUnmarshall(mNativePtr, data, offset, length);
|
||||
}
|
||||
|
||||
|
||||
Parcelable的注意事项
|
||||
|
||||
在时间开销和使用成本的权衡上，Parcelable机制选择的是性能优先。
|
||||
|
||||
所以它在写入和读取的时候都需要手动添加自定义代码，使用起来相比Serializable会复杂很多。但是正因为这样，Parcelable才不需要采用反射的方式去实现序列化和反序列化。
|
||||
|
||||
虽然通过取巧的方法可以实现Parcelable的永久存储，但是它也存在两个问题。
|
||||
|
||||
|
||||
系统版本的兼容性。由于Parcelable设计本意是在内存中使用的，我们无法保证所有Android版本的Parcel.cpp实现都完全一致。如果不同系统版本实现有所差异，或者有厂商修改了实现，可能会存在问题。
|
||||
|
||||
数据前后兼容性。Parcelable并没有版本管理的设计，如果我们类的版本出现升级，写入的顺序及字段类型的兼容都需要格外注意，这也带来了很大的维护成本。
|
||||
|
||||
|
||||
一般来说，如果需要持久化存储的话，一般还是不得不选择性能更差的Serializable方案。
|
||||
|
||||
3. Serial
|
||||
|
||||
作为程序员，我们肯定会追求完美。那有没有性能更好的方案并且可以解决这些痛点呢？
|
||||
|
||||
事实上，关于序列化基本每个大公司都会自己自研的一套方案，我在专栏里推荐Twitter开源的高性能序列化方案Serial。那它是否真的是高性能呢？我们可以将它和前面的两套方案做一个对比测试。
|
||||
|
||||
|
||||
|
||||
从图中数据上看来，Serial在序列化与反序列化耗时，以及落地的文件大小都有很大的优势。
|
||||
|
||||
从实现原理上看，Serial就像是把Parcelable和Serializable的优点集合在一起的方案。
|
||||
|
||||
|
||||
由于没有使用反射，相比起传统的反射序列化方案更加高效，具体你可以参考上面的测试数据。
|
||||
|
||||
开发者对于序列化过程的控制较强，可定义哪些Object、Field需要被序列化。
|
||||
|
||||
有很强的debug能力，可以调试序列化的过程。
|
||||
|
||||
有很强的版本管理能力，可以通过版本号和OptionalFieldException做兼容。
|
||||
|
||||
|
||||
数据的序列化
|
||||
|
||||
Serial性能看起来还不错，但是对象的序列化要记录的信息还是比较多，在操作比较频繁的时候，对应用的影响还是不少的，这个时候我们可以选择使用数据的序列化。
|
||||
|
||||
1. JSON
|
||||
|
||||
JSON是一种轻量级的数据交互格式，它被广泛使用在网络传输中，很多应用与服务端的通信都是使用JSON格式进行交互。
|
||||
|
||||
JSON的确有很多得天独厚的优势，主要有：
|
||||
|
||||
|
||||
相比对象序列化方案，速度更快，体积更小。
|
||||
|
||||
相比二进制的序列化方案，结果可读，易于排查问题。
|
||||
|
||||
使用方便，支持跨平台、跨语言，支持嵌套引用。
|
||||
|
||||
|
||||
因为每个应用基本都会用到JSON，所以每个大厂也基本都有自己的“轮子”。例如Android自带的JSON库、Google的Gson、阿里巴巴的Fastjson、美团的MSON。
|
||||
|
||||
各个自研的JSON方案主要在下面两个方面进行优化：
|
||||
|
||||
|
||||
便利性。例如支持JSON转换成JavaBean对象，支持注解，支持更多的数据类型等。
|
||||
|
||||
性能。减少反射，减少序列化过程内存与CPU的使用，特别是在数据量比较大或者嵌套层级比较深的时候效果会比较明显。
|
||||
|
||||
|
||||
|
||||
|
||||
在数据量比较少的时候，系统自带的JSON库还稍微有一些优势。但在数据量大了之后，差距逐渐被拉开。总的来说，Gson的兼容性最好，一般情况下它的性能与Fastjson相当。但是在数据量极大的时候，Fastjson的性能更好。
|
||||
|
||||
2. Protocol Buffers
|
||||
|
||||
相比对象序列化方案，JSON的确速度更快、体积更小。不过为了保证JSON的中间结果是可读的，它并没有做二进制的压缩，也因此JSON的性能还没有达到极致。
|
||||
|
||||
如果应用的数据量非常大，又或者对性能有更高的要求，此时Protocol Buffers是一个非常好的选择。它是Google开源的跨语言编码协议，Google内部的几乎所有RPC都在使用这个协议。
|
||||
|
||||
下面我来总结一下它的优缺点。
|
||||
|
||||
|
||||
性能。使用了二进制编码压缩，相比JSON体积更小，编解码速度也更快，感兴趣的同学可以参考protocol-buffers编码规则。
|
||||
|
||||
兼容性。跨语言和前后兼容性都不错，也支持基本类型的自动转换，但是不支持继承与引用类型。
|
||||
|
||||
使用成本。Protocol Buffers的开发成本很高，需要定义.proto文件，并用工具生成对应的辅助类。辅助类特有一些序列化的辅助方法，所有要序列化的对象，都需要先转化为辅助类的对象，这让序列化代码跟业务代码大量耦合，是侵入性较强的一种方式。
|
||||
|
||||
|
||||
对于Android来说，官方的Protocol Buffers会导致生成的方法数很多。我们可以修改它的自动代码生成工具，例如在微信中，每个.proto生成的类文件只会包含一个方法即op方法。
|
||||
|
||||
public class TestProtocal extends com.tencent.mm.protocal.protobuf {
|
||||
@Override
|
||||
protected final int op(int opCode, Object ...objs) throws IOException {
|
||||
if (opCode == OPCODE_WRITEFIELDS) {
|
||||
...
|
||||
} else if (opCode == OPCODE_COMPUTESIZE) {
|
||||
...
|
||||
|
||||
|
||||
Google后面还推出了压缩率更高的FlatBuffers，对于它的使用你可以参考《FlatBuffers 体验》。最后，我再结合“六要素”，帮你综合对比一下Serial、JSON、Protocol Buffers这三种序列化方案。
|
||||
|
||||
|
||||
|
||||
存储监控
|
||||
|
||||
通过本地实验我们可以对比不同文件存储方法的性能，但是实验室环境不一定能真实反映用户实际的使用情况，所以我们同样需要对存储建立完善的监控。那么应该监控哪些内容呢？
|
||||
|
||||
1. 性能监控
|
||||
|
||||
正确性、时间开销、空间开销、安全、开发成本和兼容性，对于这六大关键要素来说，在线上我更关注：
|
||||
|
||||
|
||||
正确性
|
||||
|
||||
|
||||
在专栏第9期中我讲过，应用程序、文件系统或者磁盘都可以导致文件损坏。
|
||||
|
||||
在线上我希望可以监控存储模块的损坏率，在专栏上一期中也提到SharedPreferences的损坏率大约在万分之一左右，而我们内部自研的SharedPreferences的损耗率在十万分之一左右。如何界定一个文件是损坏的？对于系统SP我们将损坏定义为文件大小变为0，而自研的SP文件头部会有专门的校验字段，比如文件长度、关键位置的CRC信息等，可以识别出更多的文件损坏场景。在识别出文件损坏之后，我们还可以进一步做数据修复等工作。
|
||||
|
||||
|
||||
时间开销
|
||||
|
||||
|
||||
存储模块的耗时也是我非常关心的，而线上的耗时监控分为初始化耗时与读写耗时。每个存储模块的侧重点可能不太一样，例如在启动过程中使用的存储模块我们可能希望初始化可以快一些。
|
||||
|
||||
同样以系统的SharedPreferences为例，在初始化过程它需要读取并解析整个文件，如果内容超过1000条，初始化的时间可能就需要50～100ms。我们内部另外一个支持随机读写的存储模块，初始化时间并不会因为存储条数的数量而变化，即使有几万条数据，初始化时间也在1ms以内。
|
||||
|
||||
|
||||
空间开销
|
||||
|
||||
|
||||
空间的占用分为内存空间和ROM空间，通常为了性能的提升，会采用空间换时间的方式。内存空间需要考虑GC和峰值内存，以及在一些数据量比较大的情况会不会出现OOM。ROM空间需要考虑做清理逻辑，例如数据超过1000条或者10MB后会触发自动清理或者数据合并。
|
||||
|
||||
2. ROM监控
|
||||
|
||||
除了某个存储模块的监控，我们也需要对应用整体的ROM空间做详细监控。为什么呢？这是源于我发现有两个经常会遇到的问题。
|
||||
|
||||
以前经常会收到用户的负反馈：微信的ROM空间为什么会占用2GB之多？是因为数据库太大了吗，还是其他什么原因，那时候我们还真有点不知所措。曾经我们在线上发现一个bug会导致某个配置重复下载，相同的内容一个用户可能会下载了几千次。
|
||||
|
||||
download_1 download_2 download_3 ....
|
||||
|
||||
|
||||
线上我们有时候会发现在遍历某个文件夹时，会出现卡顿或者ANR。在专栏第10期我也讲过，文件遍历的耗时跟文件夹下的文件数量有关。曾经我们也出现过一次bug导致某个文件夹下面有几万个文件，在遍历这个文件夹时，用户手机直接重启了。需要注意的是文件遍历在API level 26之后建议使用FileVisitor替代ListFiles，整体的性能会好很多。
|
||||
|
||||
ROM监控的两个核心指标是文件总大小与总文件数，例如我们可以将文件总大小超过400MB的用户比例定义为空间异常率，将文件数超过1000个的用户比例定义为数量异常率，这样我们就可以持续监控应用线上的存储情况。
|
||||
|
||||
当然监控只是第一步，核心问题在于如何能快速发现问题。类似卡顿树，我们也可以构造用户的存储树，然后在后台做聚合。但是用户的整个存储树会非常非常大，这里我们需要通过一些剪枝算法。例如只保留最大的3个文件夹，每个文件夹保留5个文件，但在这5个文件我们需要保留一定的随机性，以免所有人都会上传相同的内容。
|
||||
|
||||
|
||||
|
||||
在监控的同时，我们也要有远程控制的能力，用户投诉时可以实时拉取这个用户的完整存储树。对线上发现的存储问题，我们可以动态下发清理规则，例如某个缓存文件夹超过200MB后自动清理、删除某些残留的历史文件等。
|
||||
|
||||
总结
|
||||
|
||||
对于优化存储来说，不同的应用关注点可能不太一样。对小应用来说，可能开发成本是最重要的，我们希望开发效率优先；对于成熟的应用来说，性能会更加重要。因此选择什么样的存储方案，需要结合应用所处的阶段以及使用场景具体问题具体分析。
|
||||
|
||||
无论是优化某个存储方案的性能，还是应用整体的ROM存储，我们可能对存储监控关注比较少。而如果这块出现问题，对用户的体验影响还是非常大的。例如我们知道微信占用的ROM空间确实不小，为了解决这个问题，特别推出了空间清理的功能，而且在ROM空间不足等场景，会弹框提示用户操作。
|
||||
|
||||
课后作业
|
||||
|
||||
今天的课后作业是，你的应用选择了哪种对象序列化和数据序列化方案？对数据的存储你还有哪些体会？请你在留言区写写你的方案和想法，与其他同学一起交流。
|
||||
|
||||
欢迎你点击“请朋友读”，把今天的内容分享给好友，邀请他一起学习。最后别忘了在评论区提交今天的作业，我也为认真完成作业的同学准备了丰厚的“学习加油礼包”，期待与你一起切磋进步哦。
|
||||
|
||||
|
||||
|
||||
|
||||
313
专栏/Android开发高手课/14存储优化（下）：数据库SQLite的使用和优化.md
Normal file
313
专栏/Android开发高手课/14存储优化（下）：数据库SQLite的使用和优化.md
Normal file
@ -0,0 +1,313 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
14 存储优化（下）：数据库SQLite的使用和优化
|
||||
我们先来复习一下前面讲到的存储方法的使用场景：少量的Key Value数据可以直接使用SharedPreferences，稍微复杂一些的数据类型也可以通过序列化成JSON或者Protocol Buffers保存，并且在开发中获取或者修改数据也很简单。
|
||||
|
||||
不过这几种方法可以覆盖所有的存储场景吗？数据量在几百上千条这个量级时它们的性能还可以接受，但如果是几万条的微信聊天记录呢？而且如何实现快速地对某几个联系人的数据做增删改查呢？
|
||||
|
||||
对于大数据的存储场景，我们需要考虑稳定性、性能和可扩展性，这个时候就要轮到今天的“主角”数据库登场了。讲存储优化一定绕不开数据库，而数据库这个主题又非常大，我也知道不少同学学数据库的过程是从入门到放弃。那么考虑到我们大多是从事移动开发的工作，今天我就来讲讲移动端数据库SQLite的使用和优化。
|
||||
|
||||
SQLite的那些事儿
|
||||
|
||||
虽然市面上有很多的数据库，但受限于库体积和存储空间，适合移动端使用的还真不多。当然使用最广泛的还是我们今天的主角SQLite，但同样还是有一些其他不错的选择，例如创业团队的Realm、Google的LevelDB等。
|
||||
|
||||
在国内那么多的移动团队中，微信对SQLite的研究可以算是最深入的。这其实是业务诉求导向的，用户聊天记录只会在本地保存，一旦出现数据损坏或者丢失，对用户来说都是不可挽回的。另一方面，微信有很大一批的重度用户，他们有几千个联系人、几千个群聊天，曾经做过一个统计，有几百万用户的数据库竟然大于1GB。对于这批用户，如何保证他们可以正常地使用微信是一个非常大的挑战。
|
||||
|
||||
所以当时微信专门开展了一个重度用户优化的专项。一开始的时候我们集中在SQLite使用上的优化，例如表结构、索引等。但很快就发现由于系统版本的不同，SQLite的实现也有所差异，经常会出现一些兼容性问题，并且也考虑到加密的诉求，我们决定单独引入自己的SQLite版本。
|
||||
|
||||
“源码在手，天下我有”，从此开启了一条研究数据库的“不归路”。那时我们投入了几个人专门去深入研究SQLite的源码，从SQLite的PRAGMA编译选项、Cursor实现优化，到SQLite源码的优化，最后打造出从实验室到线上的整个监控体系。
|
||||
|
||||
在2017年，我们开源了内部使用的SQLite数据库WCDB。这里多说两句，看一个开源项目是否靠谱，就看这个项目对产品本身有多重要。微信开源坚持内部与外部使用同一个版本，虽然我现在已经离开了微信团队，但还是欢迎有需要的同学使用WCDB。
|
||||
|
||||
在开始学习前我要提醒你，SQLite的优化同样也很难通过一两篇文章就把每个细节都讲清楚。今天的内容我选择了一些比较重要的知识点，并且为你准备了大量的参考资料，遇到陌生或者不懂的地方需要结合参考资料反复学习。
|
||||
|
||||
1. ORM
|
||||
|
||||
坦白说可能很多BAT的高级开发工程师都不完全了解SQLite的内部机制，也不能正确地写出高效的SQL语句。大部分应用为了提高开发效率，会引入ORM框架。ORM（Object Relational Mapping）也就是对象关系映射，用面向对象的概念把数据库中表和对象关联起来，可以让我们不用关心数据库底层的实现。
|
||||
|
||||
Android中最常用的ORM框架有开源greenDAO和Google官方的Room，那使用ORM框架会带来什么问题呢？
|
||||
|
||||
使用ORM框架真的非常简单，但是简易性是需要牺牲部分执行效率为代价的，具体的损耗跟ORM框架写得好不好很有关系。但可能更大的问题是让很多的开发者的思维固化，最后可能连简单的SQL语句都不会写了。
|
||||
|
||||
那我们的应用是否应该引入ORM框架呢？可能程序员天生追求偷懒，为了提高开发效率，应用的确应该引入ORM框架。但是这不能是我们可以不去学习数据库基础知识的理由，只有理解底层的一些机制，我们才能更加得心应手地解决疑难的问题。
|
||||
|
||||
考虑到可以更好的与Android Jetpack的组件互动，WCDB选择Room作为ORM框架。
|
||||
|
||||
2. 进程与线程并发
|
||||
|
||||
如果我们在项目中有使用SQLite，那么下面这个SQLiteDatabaseLockedException就是经常会出现的一个问题。
|
||||
|
||||
android.database.sqlite.SQLiteDatabaseLockedException: database is locked
|
||||
at android.database.sqlite.SQLiteDatabase.dbopen
|
||||
at android.database.sqlite.SQLiteDatabase.openDatabase
|
||||
at android.database.sqlite.SQLiteDatabase.openDatabase
|
||||
|
||||
|
||||
SQLiteDatabaseLockedException归根到底是因为并发导致，而SQLite的并发有两个维度，一个是多进程并发，一个是多线程并发。下面我们分别来讲一下它们的关键点。
|
||||
|
||||
多进程并发
|
||||
|
||||
SQLite默认是支持多进程并发操作的，它通过文件锁来控制多进程的并发。SQLite锁的粒度并没有非常细，它针对的是整个DB文件，内部有5个状态，具体你可以参考下面的文章。
|
||||
|
||||
|
||||
官方文档：SQLite locking
|
||||
|
||||
SQLite源码分析：SQLite锁机制简介
|
||||
|
||||
SQLite封锁机制
|
||||
|
||||
|
||||
简单来说，多进程可以同时获取SHARED锁来读取数据，但是只有一个进程可以获取EXCLUSIVE锁来写数据库。对于iOS来说可能没有多进程访问数据库的场景，可以把locking_mode的默认值改为EXCLUSIVE。
|
||||
|
||||
PRAGMA locking_mode = EXCLUSIVE
|
||||
|
||||
|
||||
在EXCLUSIVE模式下，数据库连接在断开前都不会释放SQLite文件的锁，从而避免不必要的冲突，提高数据库访问的速度。
|
||||
|
||||
多线程并发
|
||||
|
||||
相比多进程，多线程的数据库访问可能会更加常见。SQLite支持多线程并发模式，需要开启下面的配置，当然系统SQLite会默认开启多线程Multi-thread模式。
|
||||
|
||||
PRAGMA SQLITE_THREADSAFE = 2
|
||||
|
||||
|
||||
跟多进程的锁机制一样，为了实现简单，SQLite锁的粒度都是数据库文件级别，并没有实现表级甚至行级的锁。还有需要说明的是，同一个句柄同一时间只有一个线程在操作，这个时候我们需要打开连接池Connection Pool。
|
||||
|
||||
如果使用WCDB在初始化的时候可以指定连接池的大小，在微信中我们设置的大小是4。
|
||||
|
||||
public static SQLiteDatabase openDatabase (String path,
|
||||
SQLiteDatabase.CursorFactory factory,
|
||||
int flags,
|
||||
DatabaseErrorHandler errorHandler,
|
||||
int poolSize)
|
||||
|
||||
|
||||
跟多进程类似，多线程可以同时读取数据库数据，但是写数据库依然是互斥的。SQLite提供了Busy Retry的方案，即发生阻塞时会触发Busy Handler，此时可以让线程休眠一段时间后，重新尝试操作，你可以参考《微信iOS SQLite源码优化实践》这篇文章。
|
||||
|
||||
为了进一步提高并发性能，我们还可以打开WAL（Write-Ahead Logging）模式。WAL模式会将修改的数据单独写到一个WAL文件中，同时也会引入了WAL日志文件锁。通过WAL模式读和写可以完全地并发执行，不会互相阻塞。
|
||||
|
||||
PRAGMA schema.journal_mode = WAL
|
||||
|
||||
|
||||
但是需要注意的是，写之间是仍然不能并发。如果出现多个写并发的情况，依然有可能会出现SQLiteDatabaseLockedException。这个时候我们可以让应用中捕获这个异常，然后等待一段时间再重试。
|
||||
|
||||
} catch (SQLiteDatabaseLockedException e) {
|
||||
if (sqliteLockedExceptionTimes < (tryTimes - 1)) {
|
||||
try {
|
||||
Thread.sleep(100);
|
||||
} catch (InterruptedException e1) {
|
||||
}
|
||||
}
|
||||
sqliteLockedExceptionTimes++；
|
||||
}
|
||||
|
||||
|
||||
总的来说通过连接池与WAL模式，我们可以很大程度上增加SQLite的读写并发，大大减少由于并发导致的等待耗时，建议大家在应用中可以尝试开启。
|
||||
|
||||
3. 查询优化
|
||||
|
||||
说到数据库的查询优化，你第一个想到的肯定是建索引，那我就先来讲讲SQLite的索引优化。
|
||||
|
||||
索引优化
|
||||
|
||||
正确使用索引在大部分的场景可以大大降低查询速度，微信的数据库优化也是通过索引开始。下面是索引使用非常简单的一个例子，我们先从索引表找到数据对应的rowid，然后再从原数据表直接通过rowid查询结果。
|
||||
|
||||
|
||||
|
||||
关于SQLite索引的原理网上有很多文章，在这里我推荐一些参考资料给你：
|
||||
|
||||
|
||||
SQLite索引的原理
|
||||
|
||||
官方文档：Query Planning
|
||||
|
||||
MySQL索引背后的数据结构及算法原理
|
||||
|
||||
|
||||
这里的关键在于如何正确的建立索引，很多时候我们以为已经建立了索引，但事实上并没有真正生效。例如使用了BETWEEN、LIKE、OR这些操作符、使用表达式或者case when等。更详细的规则可参考官方文档The SQLite Query Optimizer Overview，下面是一个通过优化转换达到使用索引目的的例子。
|
||||
|
||||
BETWEEN：myfiedl索引无法生效
|
||||
SELECT * FROM mytable WHERE myfield BETWEEN 10 and 20;
|
||||
转换成：myfiedl索引可以生效
|
||||
SELECT * FROM mytable WHERE myfield >= 10 AND myfield <= 20;
|
||||
|
||||
|
||||
建立索引是有代价的，需要一直维护索引表的更新。比如对于一个很小的表来说就没必要建索引；如果一个表经常是执行插入更新操作，那么也需要节制的建立索引。总的来说有几个原则：
|
||||
|
||||
|
||||
建立正确的索引。这里不仅需要确保索引在查询中真正生效，我们还希望可以选择最高效的索引。如果一个表建立太多的索引，那么在查询的时候SQLite可能不会选择最好的来执行。
|
||||
|
||||
单列索引、多列索引与复合索引的选择。索引要综合数据表中不同的查询与排序语句一起考虑，如果查询结果集过大，还是希望可以通过复合索引直接在索引表返回查询结果。
|
||||
|
||||
索引字段的选择。整型类型索引效率会远高于字符串索引，而对于主键SQLite会默认帮我们建立索引，所以主键尽量不要用复杂字段。
|
||||
|
||||
|
||||
总的来说索引优化是SQLite优化中最简单同时也是最有效的，但是它并不是简单的建一个索引就可以了，有的时候我们需要进一步调整查询语句甚至是表的结构，这样才能达到最好的效果。
|
||||
|
||||
页大小与缓存大小
|
||||
|
||||
在I/O文件系统中，我讲过数据库就像一个小文件系统一样，事实上它内部也有页和缓存的概念。
|
||||
|
||||
对于SQLite的DB文件来说，页（page）是最小的存储单位，如下图所示每个表对应的数据在整个DB文件中都是通过一个一个的页存储，属于同一个表不同的页以B树（B-tree）的方式组织索引，每一个表都是一棵B树。
|
||||
|
||||
|
||||
|
||||
跟文件系统的页缓存（Page Cache）一样，SQLite会将读过的页缓存起来，用来加快下一次读取速度。页大小默认是1024Byte，缓存大小默认是1000页。更多的编译参数你可以查看官方文档PRAGMA Statements。
|
||||
|
||||
PRAGMA page_size = 1024
|
||||
PRAGMA cache_size = 1000
|
||||
|
||||
|
||||
每个页永远只存放一个表或者一组索引的数据，即不可能同一个页存放多个表或索引的数据，表在整个DB文件的第一个页就是这棵B树的根页。继续以上图为例，如果想查询rowID为N+2的数据，我们首先要从sqlite_master查找出table的root page的位置，然后读取root page、page4这两个页，所以一共会需要3次I/O。
|
||||
|
||||
|
||||
|
||||
从上表可以看到，增大page size并不能不断地提升性能，在拐点以后可能还会有副作用。我们可以通过PRAGMA改变默认page size的大小，也可以再创建DB文件的时候进行设置。但是需要注意如果存在老的数据，需要调用vacuum对数据表对应的节点重新计算分配大小。
|
||||
|
||||
在微信的内部测试中，如果使用4KB的page size性能提升可以在5%～10%。但是考虑到历史数据的迁移成本，最终还是使用1024Byte。所以这里建议大家在新建数据库的时候，就提前选择4KB作为默认的page size以获得更好的性能。
|
||||
|
||||
其他优化
|
||||
|
||||
关于SQLite的使用优化还有很多很多，下面我简单提几个点。
|
||||
|
||||
|
||||
慎用“select*”，需要使用多少列，就选取多少列。
|
||||
|
||||
正确地使用事务。
|
||||
|
||||
预编译与参数绑定，缓存被编译后的SQL语句。
|
||||
|
||||
对于blob或超大的Text列，可能会超出一个页的大小，导致出现超大页。建议将这些列单独拆表，或者放到表字段的后面。
|
||||
|
||||
定期整理或者清理无用或可删除的数据，例如朋友圈数据库会删除比较久远的数据，如果用户访问到这部分数据，重新从网络拉取即可。
|
||||
|
||||
|
||||
在日常的开发中，我们都应该对这些知识有所了解，再来复习一下上面学到的SQLite优化方法。通过引进ORM，可以大大的提升我们的开发效率。通过WAL模式和连接池，可以提高SQLite的并发性能。通过正确的建立索引，可以提升SQLite的查询速度。通过调整默认的页大小和缓存大小，可以提升SQLite的整体性能。
|
||||
|
||||
SQLite的其他特性
|
||||
|
||||
除了SQLite的优化经验，我在微信的工作中还积累了很多使用的经验，下面我挑选了几个比较重要的经验把它分享给你。
|
||||
|
||||
1. 损坏与恢复
|
||||
|
||||
微信中SQLite的损耗率在1/20000～1/10000左右，虽然看起来很低，不过意考虑到微信的体量，这个问题还是不容忽视的。特别是如果某些大佬的聊天记录丢失，我们团队都会承受超大的压力。
|
||||
|
||||
创新是为了解决焦虑，技术都是逼出来的。对于SQLite损坏与恢复的研究，可以说是微信投入比较大的一块。关于SQLite数据库的损耗与修复，以及微信在这里的优化成果，你可以参考下面这些资料。
|
||||
|
||||
|
||||
How To Corrupt An SQLite Database File
|
||||
|
||||
微信 SQLite 数据库修复实践
|
||||
|
||||
微信移动端数据库组件WCDB系列（二） — 数据库修复三板斧
|
||||
|
||||
WCDB Android数据库修复
|
||||
|
||||
|
||||
2. 加密与安全
|
||||
|
||||
数据库的安全主要有两个方面，一个是防注入，一个是加密。防注入可以通过静态安全扫描的方式，而加密一般会使用SQLCipher支持。
|
||||
|
||||
SQLite的加解密都是以页为单位，默认会使用AES算法加密，加/解密的耗时跟选用的密钥长度有关。下面是WCDB Android Benchmark的数据，详细的信息请查看链接里的说明，从结论来说对Create来说影响会高达到10倍。
|
||||
|
||||
|
||||
|
||||
关于WCDB加解密的使用，你可以参考《微信移动数据库组件WCDB（四） — Android 特性篇》。
|
||||
|
||||
3. 全文搜索
|
||||
|
||||
微信的全文搜索也是一个技术导向的项目，最开始的时候性能并不是很理想，经常会被人“批斗”。经过几个版本的优化迭代，目前看效果还是非常不错的。
|
||||
|
||||
|
||||
|
||||
关于全文搜索，你可以参考这些资料：
|
||||
|
||||
|
||||
SQLite FTS3 and FTS4 Extensions
|
||||
|
||||
微信全文搜索优化之路
|
||||
|
||||
移动客户端多音字搜索
|
||||
|
||||
|
||||
关于SQLite的这些特性，我们需要根据自己的项目情况综合考虑。假如某个数据库存储的数据并不重要，这个时候万分之一的数据损坏率我们并不会关心。同样是否需要使用数据库加密，也要根据存储的数据是不是敏感内容。
|
||||
|
||||
SQLite的监控
|
||||
|
||||
首先我想说，正确使用索引，正确使用事务。对于大型项目来说，参与的开发人员可能有几十几百人，开发人员水平参差不齐，很难保证每个人都可以正确而高效地使用SQLite，所以这次时候需要建立完善的监控体系。
|
||||
|
||||
1. 本地测试
|
||||
|
||||
作为一名靠谱的开发工程师，我们每写一个SQL语句，都应该先在本地测试。我们可以通过 EXPLAIN QUERY PLAN测试SQL语句的查询计划，是全表扫描还是使用了索引，以及具体使用了哪个索引等。
|
||||
|
||||
sqlite> EXPLAIN QUERY PLAN SELECT * FROM t1 WHERE a=1 AND b>2;
|
||||
QUERY PLAN
|
||||
|--SEARCH TABLE t1 USING INDEX i2 (a=? AND b>?)
|
||||
|
||||
|
||||
关于SQLite命令行与EXPLAIN QUERY PLAN的使用，可以参考Command Line Shell For SQLite以及EXPLAIN QUERY PLAN。
|
||||
|
||||
2. 耗时监控
|
||||
|
||||
本地测试过于依赖开发人员的自觉性，所以很多时候我们依然需要建立线上大数据的监控。因为微信集成了自己的SQLite源码，所以可以非常方便地增加自己想要的监控模块。
|
||||
|
||||
WCDB增加了SQLiteTrace的监控模块，有以下三个接口：
|
||||
|
||||
|
||||
|
||||
我们可以通过这些接口监控数据库busy、损耗以及执行耗时。针对耗时比较长的SQL语句，需要进一步检查是SQL语句写得不好，还是需要建立索引。
|
||||
|
||||
|
||||
|
||||
3. 智能监控
|
||||
|
||||
对于查询结果的监控只是我们监控演进的第二阶段，在这个阶段我们依然需要人工介入分析，而且需要比较有经验的人员负责。
|
||||
|
||||
我们希望SQL语句的分析可以做到智能化，是完全不需要门槛的。微信开源的Matrix里面就有一个智能化分析SQLite语句的工具：Matrix SQLiteLint – SQLite 使用质量检测。它根据分析SQL语句的语法树，结合我们日常数据库使用的经验，抽象出索引使用不当、select*等六大问题。
|
||||
|
||||
|
||||
|
||||
可能有同学会感叹为什么微信的人可以想到这样的方式，事实上这个思路在MySQL中是非常常见的做法。美团也开源了它们内部的SQL优化工具SQLAdvisor，你可以参考这些资料：
|
||||
|
||||
|
||||
SQL解析在美团的应用
|
||||
|
||||
美团点评SQL优化工具SQLAdvisor开源
|
||||
|
||||
|
||||
总结
|
||||
|
||||
数据库存储是一个开发人员的基本功，清楚SQLite的底层机制对我们的工作会有很大的指导意义。
|
||||
|
||||
掌握了SQLite数据库并发的机制，在某些时候我们可以更好地决策应该拆数据表还是拆数据库。新建一个数据库好处是可以隔离其他库并发或者损坏的情况，而坏处是数据库初始化耗时以及更多内存的占用。一般来说，单独的业务都会使用独立数据库，例如专门的下载数据库、朋友圈数据库、聊天数据库。但是数据库也不宜太多，我们可以有一个公共数据库，用来存放一些相对不是太大的数据。
|
||||
|
||||
在了解SQLite数据库损坏的原理和概率以后，我们可以根据数据的重要程度决定是否要引入恢复机制。我还讲了如何实现数据库加密以及对性能的影响，我们可以根据数据的敏感程度决定是否要引入加密。
|
||||
|
||||
最后我再强调一下，SQLite优化真的是一个很大的话题，在课后你还需要结合参考资料再进一步反复学习，才能把今天的内容理解透彻。
|
||||
|
||||
课后作业
|
||||
|
||||
在你的应用中是否使用数据库存储呢，使用了哪种数据库？是否使用ORM？在使用数据库过程中你有哪些疑问或者经验呢？欢迎留言跟我和其他同学一起讨论。
|
||||
|
||||
如果你的应用也在使用SQLite存储，今天的课后练习是尝试接入WCDB，对比测试系统默认SQLite的性能。尝试接入Matrix SQLiteLint，查看是否存在不合理的SQLite使用。
|
||||
|
||||
除了今天文章中的参考资料，我还给希望进阶的同学准备了下面的资料，欢迎有兴趣的同学继续深入学习。
|
||||
|
||||
|
||||
SQLite官方文档
|
||||
|
||||
SQLite源码分析
|
||||
|
||||
全面解析SQLite
|
||||
|
||||
图书《SQLite权威指南（第2版）》
|
||||
|
||||
|
||||
欢迎你点击“请朋友读”，把今天的内容分享给好友，邀请他一起学习。最后别忘了在评论区提交今天的作业，我也为认真完成作业的同学准备了丰厚的“学习加油礼包”，期待与你一起切磋进步哦。
|
||||
|
||||
|
||||
|
||||
|
||||
197
专栏/Android开发高手课/15网络优化（上）：移动开发工程师必备的网络优化知识.md
Normal file
197
专栏/Android开发高手课/15网络优化（上）：移动开发工程师必备的网络优化知识.md
Normal file
@ -0,0 +1,197 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
15 网络优化（上）：移动开发工程师必备的网络优化知识
|
||||
专栏前面我们已经学习过文件I/O和存储优化，相信你已经掌握了文件I/O和存储的性能分析以及优化思路。今天我们就再接再厉，继续学习系统中另外一种常见的I/O——网络I/O。
|
||||
|
||||
我在写今天的文章时，回想了一下大学期间学的那本几百页厚的《计算机网络》，当时学得也是云里雾里，网络的确涉及了方方面面太多的知识。那我们作为移动开发者来说，都需要掌握哪些必备的网络知识呢？文件I/O跟网络I/O又有哪些差异呢？
|
||||
|
||||
今天我们不谈“经典巨著”，一起来解决移动开发工程师面对的网络问题。
|
||||
|
||||
网络基础知识
|
||||
|
||||
现在已经很难找到一款完全不需要网络的应用，即使是单机应用，也会存在数据上报、广告等各种各样的网络请求。既然网络已经无处不在，我们必须要掌握哪些基础知识呢？
|
||||
|
||||
1. 无线网络
|
||||
|
||||
在过去十年，移动互联网的高速增长离不开无线网络的普及。无线网络多种多样，而且各有各的特点，并且适合使用的场景也不同。
|
||||
|
||||
下图是iPhone XS支持的无线网络类型，你可以看到WiFi、蜂窝网络、蓝牙、NFC这些都是我们日常经常使用的无线网络类型。
|
||||
|
||||
|
||||
|
||||
“千兆级LTE”指的是蜂窝网络在理论上速度可以达到光纤级别的1Gbps（125MB/s）。虽然基于4G标准，但通过MIMO（多输入多输出）、使用载波聚合的LAA等技术，现在已经发展到千兆级LTE。2020年我们也即将迎来5G的商用，它的理论传输速率可以达到20Gbps。目前5G的标准还没有完全release，关于5G的原理我推荐你看看这篇文章。
|
||||
|
||||
|
||||
|
||||
“802.11ac无线网络”指的是我们经常使用的WiFi。WiFi由IEEE定义和进行标准化规范，跟任何流行的技术一样，IEEE也一直在积极地发布新的协议。目前最常用的是802.11ac标准，它的理想速率可以达到866.7Mbps。
|
||||
|
||||
从硬件维度上来看，所有的无线网络都通过基带芯片支持，目前高通在基带芯片领域占据了比较大的优势。之前由于苹果和高通的专利诉讼，iPhone XS选用了英特尔的基带芯片，但同时也出现大量的用户投诉网络连接异常。
|
||||
|
||||
市面上有那么多的无线网络标准和制式，还有双卡双待等各种特色功能，因此基带芯片对技术的要求非常高。随着未来5G的商用与普及，国内也会迎来新的一波换机潮。这对各大芯片厂商来说是机遇也是挑战，目前高通、MTK、华为都已经发布了5G基带芯片。如果你对当前的5G格局感兴趣，可以阅读《全世界5G格局》。
|
||||
|
||||
2. Link Turbo
|
||||
|
||||
像5G这种新的标准，可以极大地提升网络速度，但缺点是它需要新的基站设备和手机设备支持，这个过程起码需要几年的时间。
|
||||
|
||||
手机厂商为了提升用户的网络体验，也会做各种各样的定制优化，华为最近在荣耀V20推出的Link Turbo 网络聚合加速技术就是其中比较硬核的一种“黑科技”。
|
||||
|
||||
|
||||
|
||||
从硬件角度来说，WiFi和蜂窝网络属于基带芯片的不同模块，我们可以简单的把它们理解为类似双网卡的情形。所谓的Link Turbo就是在使用WiFi的同时使用移动网络加速。
|
||||
|
||||
可能有人会疑惑，我都已经连接WiFi了，为什么还要使用收费的移动网络呢？有这个疑问的人肯定没有试过使用公司网络打“王者”团战卡成狗的情形，其实WiFi可能会因为下面的一些原因导致很不稳定。
|
||||
|
||||
|
||||
|
||||
事实上，双通道的技术也并不是华为首发。类似iPhone的无线网络助理、小米和一加的自适应WLAN，它们都能在侦测到WiFi网络不稳定时，自动切换到移动网络。iPhone在连接WiFi的时候，移动网络也是依然可以连接的。
|
||||
|
||||
而Link Turbo硬核的地方在于可以同时使用两条通道传输数据，而且支持TCP与UDP。其中TCP支持使用的是开源的MultiPath TCP（iOS 7也有引入），而UDP则是华为自研的MultiPath UDP。
|
||||
|
||||
当然这个功能目前比较鸡肋，主要是由于一是覆盖的用户比较少，当前只有V20一台机器支持，而且还需要用户手动开启；二是改造成本，双通道需要我们的后台服务器也做一些改造才能支持。
|
||||
|
||||
|
||||
|
||||
但是这项技术还是有一定的价值，一方面流量越来越便宜，很多用户不再那么care流量资费的问题。另一方面华为可以直接跟阿里云、华为云、腾讯云以及CDN服务商合作，屏蔽应用后台服务器的改造成本。目前爱奇艺、斗鱼和映客这些应用都在尝试接入。
|
||||
|
||||
|
||||
|
||||
讲到这里你可能会问，为什么今天我会花这么多时间来讲Link Turbo技术？并不是因为我收了广告费，而是我发现很多时候在优化到一定程度之后，单靠应用本身很难再有大的突破。这个时候可能要考虑跟手机厂商、芯片厂商或者运营商合作，因此我们要随时关注行业的动态，并且清楚这些新技术背后的本质所在。
|
||||
|
||||
网络I/O
|
||||
|
||||
在前面的专栏里，我讲了文件I/O的处理流程以及不同I/O方式的使用场景，今天我们再一起来看看网络I/O跟文件I/O有哪些差异。
|
||||
|
||||
1. I/O模型
|
||||
|
||||
“一切皆文件”，Linux内核会把所有外部设备都看作一个文件来操作。在网络I/O中系统对一个 Socket的读写也会有相应的描述符，称为socket fd（Socket描述符）。
|
||||
|
||||
如下图以Socket读取数据recvfrom调用为例，它整个I/O流程分为两个阶段：
|
||||
|
||||
|
||||
等待Socket数据准备好。
|
||||
|
||||
将数据从内核拷贝到应用进程中 。
|
||||
|
||||
|
||||
|
||||
|
||||
在《UNIX网络编程》中将UNIX网络I/O模型分为以下五种。
|
||||
|
||||
|
||||
|
||||
在开发过程中，比较常用的有阻塞I/O、非阻塞I/O以及多路复用I/O。关于UNIX网络I/O模型的更多资料，你可以参考《UNIX网络编程》第六章、《聊聊Linux五种I/O模型》、《Unix网络I/O模型及Linux的I/O多路复用模型》。
|
||||
|
||||
在查资料的时候我发现网上有很多文章的描述还是存在问题的，我们需要辩证地看。
|
||||
|
||||
|
||||
多路复用I/O一定比阻塞I/O要好？跟文件I/O一样，最简单的I/O并发方式就是多线程+阻塞I/O。如果我们同一时间活动的网络连接非常多，使用多路复用I/O性能的确更好。但是对于客户端来说，这个假设不一定成立。对于多路复用I/O来说，整个流程会增加大量的select/epoll这样的系统调用，不一定比阻塞I/O要快。
|
||||
|
||||
epoll一定比select/poll要好？如果同一时间的连接数非常少的情况，select的性能不会比epoll，很多时候会比epoll更好。
|
||||
|
||||
epoll使用了mmap减少内核到用户空间的拷贝？网上很多的文章都说epoll使用了mmap的技术，但是我查看了Linux与Android的epoll实现，并没有找到相关的实现。而且我个人认为也不太可能会这样实现，因为直接共享内存可能会引发比较大的安全漏洞。
|
||||
|
||||
|
||||
2. 数据处理
|
||||
|
||||
在下一期我还会跟你一起分析当前一些热门网络库的I/O模型，现在我们再往底层走走，看看底层收发包的流程是怎么样的。
|
||||
|
||||
|
||||
|
||||
跟文件I/O一样，网络I/O也使用了中断。不过网络I/O的中断会更加复杂一些，它同时使用了软中断和硬中断。通过硬中断通知CPU有数据来了，但这个处理会非常轻量。耗时的操作移到软中断处理函数里面来慢慢处理。其中查看系统软中断可以通过/proc/softirqs文件，查看硬中断可以通过/proc/interrupts文件。
|
||||
|
||||
关于网卡收发包的流程网上的资料不多，感兴趣的同学可以参考下面几篇文章：
|
||||
|
||||
|
||||
网卡收包流程
|
||||
|
||||
Linux网络 - 数据包的接收过程
|
||||
|
||||
Linux网络 - 数据包的发送过程
|
||||
|
||||
Illustrated Guide to Monitoring and Tuning the Linux Networking Stack: Receiving Data
|
||||
|
||||
|
||||
考虑到这块比较复杂，我在专栏里提供给你参考资料，有兴趣的同学可以进一步深入研究。
|
||||
|
||||
网络性能评估
|
||||
|
||||
我们常说的网络性能优化，通常都优化哪些方面呢？有的同学可能会关注网络的带宽和服务器成本，特别是直播、视频类的企业，这部分的成本非常高昂。虽然有的时候会做一些取舍，但是用户的访问速度与体验是所有应用的一致追求。
|
||||
|
||||
1. 延迟与带宽
|
||||
|
||||
如果说速度是关键，那对网络传输速度有决定性影响的主要有以下两个方面：
|
||||
|
||||
|
||||
延迟：数据从信息源发送到目的地所需的时间。
|
||||
|
||||
带宽：逻辑或物理通信路径最大的吞吐量。
|
||||
|
||||
|
||||
回想一下文件I/O性能评估似乎已经很复杂了，但是它至少整个流程都在手机系统内部。对于网络来说，整个流程涉及的链路就更加复杂了。一个数据包从手机出发要经过无线网络、核心网络以及外部网络（互联网），才能到达我们的服务器。
|
||||
|
||||
|
||||
|
||||
那延迟和带宽又跟什么因素有关呢？这里面涉及的因素也非常多，例如信号的强度、附近有没有基站、距离有多远等；还跟使用的网络制式，正在使用3G、4G还是5G网络有关，并且网络的拥塞情况也会产生影响，比如是不是在几万人聚集的大型活动场所等。
|
||||
|
||||
下面是不同网络制式的带宽和延迟的一般参考值，你可以在脑海里建立一个大致的印象。
|
||||
|
||||
|
||||
|
||||
当出现上面说到的那些因素时，网络访问的带宽要大打折扣，延迟会加倍放大。而高延迟、低带宽的网络场景也就是我们常说的“弱网络”，它主要特点有：
|
||||
|
||||
|
||||
|
||||
关于“弱网络”如何进行优化，我在微信时针对弱网络优化投入了大量的精力，这也是我在下一期所要讲的重点。不过我想说的是，即使未来5G普及了，但是各种各样的影响因素依然存在，弱网络优化这个课题是有长期存在的价值。
|
||||
|
||||
另外一个方面，不同的应用对延迟和带宽的侧重点可能不太一样。对于直播类应用或者“王者荣耀”来说，延迟会更重要一些；对腾讯视频、爱奇艺这种点播的应用来说，带宽会更加重要一些。网络优化需要结合自己应用的实际情况来综合考虑。
|
||||
|
||||
2. 性能测量
|
||||
|
||||
正如文件I/O测量一样，有哪些方法可以帮助我们评估网络的性能呢？
|
||||
|
||||
对于网络来说，我们关心的是下面这些指标：
|
||||
|
||||
|
||||
吞吐量：网络接口接收和传输的每秒字节数。
|
||||
|
||||
延迟：系统调用发送/接收延时、连接延迟、首包延迟、网络往返时间等。
|
||||
|
||||
连接数：每秒的连接数。
|
||||
|
||||
错误：丢包计数、超时等。
|
||||
|
||||
|
||||
Linux提供了大量的网络性能分析工具，下面这些工具是Android支持并且比较实用的，这些工具完整的功能请参考文档或者网上其他资料，这里就不再赘述了。
|
||||
|
||||
|
||||
|
||||
如果你对Linux底层更加熟悉，可以直接查看/proc/net，它里面包含了许多网络统计信息的文件。例如Android的TrafficState接口就是利用/proc/net/xt_qtaguid/stats和/proc/net/xt_qtaguid/iface_stat_fmt文件来统计应用的流量信息。
|
||||
|
||||
总结
|
||||
|
||||
从网络通信发展的历程来说，从2G到4G经历了十几年的时间，这背后离不开几百万个基站、几亿个路由器以及各种各样的专利支持。虽然网络标准不停地演进，不过受限于基建，它的速度看起来很快，但是又很慢。
|
||||
|
||||
那对我们自己或者应用会有哪些思考呢？HTTP 2.0、HTTP 3.0（QUIC）等网络技术一直在向前演进，我们需要坚持不懈地学习，思考它们对我们可以产生哪些影响，这是对网络“快”的思考。TCP和UDP协议、弱网络等很多东西在这二十多年来依然没有太大的改变，网络的基础知识对我们来说还是非常重要的，这是对网络“慢”的思考。
|
||||
|
||||
课后作业
|
||||
|
||||
在讲Link Turbo的时候我说过，iPhone的无线网络助理、小米和一加的自适应WLAN它们在检测WiFi不稳定时会自动切换到移动网络。那请你思考一下，它们是如何实现侦测，如何区分是应用后台服务器出问题还是WiFi本身有问题呢？今天的作业是在留言区写写你对这个问题的看法，欢迎留言跟我和其他同学一起讨论。
|
||||
|
||||
今天我推荐一本必读的网络书籍：《Web性能权威指南》，它里面第一句话就讲得非常好，我把它分享给你：“合格的开发者知道怎么做，而优秀的开发者知道为什么那么做”。
|
||||
|
||||
对于想进一步深入研究的同学，你可以研读这些书籍：
|
||||
|
||||
|
||||
《UNIX网络编程》
|
||||
|
||||
《TCP/IP详解 卷1：协议》
|
||||
|
||||
|
||||
欢迎你点击“请朋友读”，把今天的内容分享给好友，邀请他一起学习。最后别忘了在评论区提交今天的作业，我也为认真完成作业的同学准备了丰厚的“学习加油礼包”，期待与你一起切磋进步哦。
|
||||
|
||||
|
||||
|
||||
|
||||
271
专栏/Android开发高手课/16网络优化（中）：复杂多变的移动网络该如何优化？.md
Normal file
271
专栏/Android开发高手课/16网络优化（中）：复杂多变的移动网络该如何优化？.md
Normal file
@ -0,0 +1,271 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
16 网络优化（中）：复杂多变的移动网络该如何优化？
|
||||
在PC互联网时代，网络优化已经是一项非常复杂的工作。对于移动网络来说，弱网络、网络切换、网络劫持这些问题更加突出，网络优化这项工作也变得更加艰巨。
|
||||
|
||||
那作为一名移动开发者，面对复杂多变的移动网络我们该如何去优化呢？可能也有人会说，我只要用好AFNetworking/OkHttp这些成熟网络库就可以了，并不需要额外去做什么优化。那你确定你真的能用好这些网络库吗？它们内部是怎样实现的、有哪些差异点、哪个网络库更好呢？
|
||||
|
||||
虽然我们可能只是客户端App开发人员，但在关于网络优化还是可以做很多事情的，很多大型的应用也做了很多的实践。今天我们一起来看一下，如何让我们的应用在各种的网络条件下都能“快人一步”。
|
||||
|
||||
移动端优化
|
||||
|
||||
回想上一期我给出的网络架构图，一个数据包从手机出发要经过无线网络、核心网络以及外部网络（互联网），才能到达我们的服务器。那整个网络请求的速度会跟哪些因素有关呢？
|
||||
|
||||
|
||||
|
||||
从上面这张图上看，客户端网络库实现、服务器性能以及网络链路的质量都是影响网络请求速度的因素。下面我们先从客户端的网络库说过，看看应该如何进行网络优化。
|
||||
|
||||
1. 何为网络优化
|
||||
|
||||
在讲怎么去优化网络之前，我想先明确一下所谓的网络优化，究竟指的是什么？在我看来，核心内容有以下三个：
|
||||
|
||||
|
||||
速度。在网络正常或者良好的时候，怎样更好地利用带宽，进一步提升网络请求速度。
|
||||
|
||||
弱网络。移动端网络复杂多变，在出现网络连接不稳定的时候，怎样最大程度保证网络的连通性。
|
||||
|
||||
安全。网络安全不容忽视，怎样有效防止被第三方劫持、窃听甚至篡改。
|
||||
|
||||
|
||||
除了这三个问题，我们可能还会关心网络请求造成的耗电、流量问题，这两块内容我们在后面会统一地讲，今天就不再展开。
|
||||
|
||||
那对于速度、弱网络以及安全的优化，又该从哪些方面入手呢？首先你需要先搞清楚一个网络请求的整个过程。
|
||||
|
||||
|
||||
|
||||
从图上看到，整个网络请求主要分为几个步骤，而整个请求的耗时可以细分到每一个步骤里面。
|
||||
|
||||
|
||||
DNS解析。通过DNS服务器，拿到对应域名的IP地址。在这个步骤，我们比较关注DNS解析耗时情况、运营商LocalDNS的劫持、DNS调度这些问题。
|
||||
|
||||
创建连接。跟服务器建立连接，这里包括TCP三次握手、TLS密钥协商等工作。多个IP/端口该如何选择、是否要使用HTTPS、能否可以减少甚至省下创建连接的时间，这些问题都是我们优化的关键。
|
||||
|
||||
发送/接收数据。在成功建立连接之后，就可以愉快地跟服务器交互，进行组装数据、发送数据、接收数据、解析数据。我们关注的是，如何根据网络状况将带宽利用好，怎么样快速地侦测到网络延时，在弱网络下如何调整包大小等问题。
|
||||
|
||||
关闭连接。连接的关闭看起来非常简单，其实这里的水也很深。这里主要关注主动关闭和被动关闭两种情况，一般我们都希望客户端可以主动关闭连接。
|
||||
|
||||
|
||||
所谓的网络优化，就是围绕速度、弱网络、安全这三个核心内容，减少每一个步骤的耗时，打造快速、稳定且安全的高质量网络。
|
||||
|
||||
2. 何为网络库
|
||||
|
||||
在实际的开发工作中，我们很少会像《UNIX网络编程》那样直接去操作底层的网络接口，一般都会使用网络库。Square出品的OkHttp是目前最流行的Android网络库，它还被Google加入到Android系统内部，为广大开发者提供网络服务。
|
||||
|
||||
那网络库究竟承担着一个什么样的角色呢？在我看来，它屏蔽了下层复杂的网络接口，让我们可以更高效地使用网络请求。
|
||||
|
||||
|
||||
|
||||
如上图所示，一个网络库的核心作用主要有以下三点：
|
||||
|
||||
|
||||
统一编程接口。无论是同步还是异步请求，接口都非常简单易用。同时我们可以统一做策略管理，统一进行流解析（JSON、XML、Protocol Buffers）等。
|
||||
|
||||
全局网络控制。在网络库内部我们可以做统一的网络调度、流量监控以及容灾管理等工作。
|
||||
|
||||
高性能。既然我们把所有的网络请求都交给了网络库，那网络库是否实现高性能就至关重要。既然要实现高性能，那我会非常关注速度，CPU、内存、I/O的使用，以及失败率、崩溃率、协议的兼容性等方面。
|
||||
|
||||
|
||||
不同的网络库实现差别很大，比较关键有这几个模块：
|
||||
|
||||
|
||||
|
||||
那网络库实现到底哪家强？接下来我们一起来对比OkHttp、Chromium的Cronet以及微信Mars这三个网络库的内部实现。
|
||||
|
||||
3. 高质量网络库
|
||||
|
||||
据我了解业内的蘑菇街、头条、UC浏览器都在Chromium网络库上做了二次开发，而微信Mars在弱网络方面做了大量优化，拼多多、虎牙、链家、美丽说这些应用都在使用Mars。
|
||||
|
||||
下面我们一起来对比一下各个网络库的核心实现。对于参与网络库相关工作来说，我的经验还算是比较丰富的。在微信的时候曾经参与过Mars的开发，目前也在基于Chromium网络库做二次开发。
|
||||
|
||||
|
||||
|
||||
为什么我从来没使用过OkHttp？主要因为它并不支持跨平台，对于大型应用来说跨平台是非常重要的。我们不希望所有的优化Android和iOS都要各自去实现一套，不仅浪费人力而且还容易出问题。
|
||||
|
||||
对于Mars来说，它是一个跨平台的Socket层解决方案，并不支持完整的HTTP协议，所以Mars从严格意义上来讲并不是一个完整的网络库。但是它在弱网络和连接上做了大量的优化，并且支持长连接。关于Mars的网络多优化的更多细节，你可以参考Wiki右侧的文章列表。
|
||||
|
||||
|
||||
|
||||
Chromium网络库作为标准的网络库，基本上可以说是找不到太大的缺点。而且我们可以享受Google后续网络优化的成果，类似TLS 1.3、QUIC支持等。
|
||||
|
||||
但是它针对弱网络场景没有做太多定制的优化，也不支持长连接。事实上目前我在Chromium网络库的二次开发主要工作也是补齐弱网络优化与长连接这两个短板。
|
||||
|
||||
大网络平台
|
||||
|
||||
对于大公司来说，我们不能只局限在客户端网络库的双端统一上。网络优化不仅仅是客户端的事情，所以我们有了统一的网络中台，它负责提供前后台一整套的网络解决方案。
|
||||
|
||||
阿里的ACCS、蚂蚁的mPaaS、携程的网络服务都是公司级的网络中台服务，这样所有的网络优化可以让整个集团的所有接入应用受益。
|
||||
|
||||
下图是mPaaS的网络架构图，所有网络请求都会先经过统一的接入层，再转发到业务服务器。这样我们可以在业务服务器无感知的情况下，在接入层做各种各样的网络优化。
|
||||
|
||||
|
||||
|
||||
1. HTTPDNS
|
||||
|
||||
DNS的解析是我们网络请求的第一项工作，默认我们使用运营商的LocalDNS服务。这块耗时在3G网络下可能是200～300ms，4G网络也需要100ms。
|
||||
|
||||
解析慢并不是默认LocalDNS最大的“原罪”，它还存在一些其他问题：
|
||||
|
||||
|
||||
稳定性。UDP协议，无状态，容易域名劫持（难复现、难定位、难解决），每天至少几百万个域名被劫持，一年至少十次大规模事件。
|
||||
|
||||
准确性。LocalDNS调度经常出现不准确，比如北京的用户调度到广东IP，移动的运营商调度到电信的IP，跨运营商调度会导致访问慢，甚至访问不了。
|
||||
|
||||
及时性。运营商可能会修改DNS的TTL，导致DNS修改生效延迟。不同运营商的服务实现不一致，我们也很难保证DNS解析的耗时。
|
||||
|
||||
|
||||
为了解决这些问题，就有了HTTPDNS。简单来说自己做域名解析的工作，通过HTTP请求后台去拿到域名对应的IP地址，直接解决上述所有问题。
|
||||
|
||||
微信有自己部署的NEWDNS，阿里云和腾讯云也有提供自己的HTTPDNS服务。对于大网络平台来说，我们会有统一的HTTPDNS服务，并将它和运维系统打通。在传统的DNS基础上，还会增加精准的流量调度、网络拨测/灰度、网络容灾等功能。
|
||||
|
||||
|
||||
|
||||
关于HTTPDNS的更多知识，你可以参考百度的《DNS优化》。对客户端来说，我们可以通过预请求的方法，提前拿到一批域名的IP，不过这里需要注意IPv4与IPv6协议栈的选择问题。
|
||||
|
||||
2. 连接复用
|
||||
|
||||
在DNS解析之后，我们来到了创建连接这个环节。创建连接要经过TCP三次握手、TLS密钥协商，连接建立的代价是非常大的。这里我们主要的优化思路是复用连接，这样不用每次请求都重新建立连接。
|
||||
|
||||
在前面我就讲过连接管理，网络库并不会立刻把连接释放，而是放到连接池中。这时如果有另一个请求的域名和端口是一样的，就直接拿出连接池中的连接进行发送和接收数据，少了建立连接的耗时。
|
||||
|
||||
这里我们利用HTTP协议里的keep-alive，而HTTP/2.0的多路复用则可以进一步的提升连接复用率。它复用的这条连接支持同时处理多条请求，所有请求都可以并发在这条连接上进行。
|
||||
|
||||
|
||||
|
||||
虽然H2十分强大，不过这里还有两个问题需要解决。一个是同一条H2连接只支持同一个域名，一个是后端支持HTTP/2.0需要额外的改造。这个时候我们只需要在统一接入层做改造，接入层将数据转换到HTTP/1.1再转发到对应域名的服务器。
|
||||
|
||||
|
||||
|
||||
这样所有的服务都不用做任何改造就可以享受HTTP/2.0的所有优化，不过这里需要注意的是H2的多路复用在本质上依然是同一条TCP连接，如果所有的域名的请求都集中在某一条连接中，在网络拥塞的时候容易出现TCP队首阻塞问题。
|
||||
|
||||
对于客户端网络库来说，无论OkHttp还是Chromium网络库对于HTTP/2.0的连接，同一个域名只会保留一条连接。对于一些第三方请求，特别是文件下载以及视频播放这些场景可能会遇到对方服务器单连接限速的问题。在这种情况下我们可以通过修改网络库实现，也可以简单的通过禁用HTTP/2.0协议解决。
|
||||
|
||||
3. 压缩与加密
|
||||
|
||||
压缩
|
||||
|
||||
讲完连接，我们再来看看发送和接收的优化。我第一时间想到的还是减少传输的数据量，也就是我们常说的数据压缩。首先对于HTTP请求来说，数据主要包括三个部分：
|
||||
|
||||
|
||||
请求URL
|
||||
|
||||
请求header
|
||||
|
||||
请求body
|
||||
|
||||
|
||||
对于header来说，如果使用HTTP/2.0连接本身的头部压缩技术，因此需要压缩的主要是请求URL和请求body。
|
||||
|
||||
对于请求URL来说，一般会带很多的公共参数，这些参数大部分都是不变的。这样不变的参数客户端只需要上传一次即可，其他请求我们可以在接入层中进行参数扩展。
|
||||
|
||||
对于请求body来说，一方面是数据通信协议的选择，在网络传输中目前最流行的两种数据序列化方式是JSON和Protocol Buffers。正如我之前所说的一样，Protocol Buffers使用起来更加复杂一些，但在数据压缩率、序列化与反序列化速度上面都有很大的优势。
|
||||
|
||||
另外一方面是压缩算法的选择，通用的压缩算法主要是如gzip，Google的Brotli或者Facebook的Z-standard都是压缩率更高的算法。其中如果Z-standard通过业务数据样本训练出适合的字典，是目前压缩率表现最好的算法。但是各个业务维护字典的成本比较大，这个时候我们的大网络平台的统一接入层又可以大显神威了。
|
||||
|
||||
|
||||
|
||||
例如我们可以抽样1%的请求数据用来训练字典，字典的下发与更新都由统一接入层负责，业务并不需要关心。
|
||||
|
||||
当然针对特定数据我们还有其他的压缩方法，例如针对图片我们可以使用webp、hevc、SharpP等压缩率更高的格式。另外一方面，基于AI的图片超清化也是一大神器，QQ空间通过这个技术节约了大量的带宽成本。
|
||||
|
||||
安全
|
||||
|
||||
数据安全也是网络重中之重的一个环节，在大网络平台中我们都是基于HTTPS的HTTP/2通道，已经有了TLS加密。如果大家不熟悉TLS的基础知识，可以参考微信后台一个小伙伴写的《TLS协议分析》。
|
||||
|
||||
但是HTTPS带来的代价也是不小的，它需要2-RTT的协商成本，在弱网络下时延不可接受。同时后台服务解密的成本也十分高昂，在大型企业中需要单独的集群来做这个事情。
|
||||
|
||||
HTTPS的优化有下面几个思路：
|
||||
|
||||
|
||||
连接复用率。通过多个域名共用同一个HTTP/2连接、长连接等方式提升连接复用率。
|
||||
|
||||
减少握手次数。TLS 1.3可以实现0-RTT协商，事实上在TLS 1.3 release之前，微信的mmtls、Facebook的fizz、阿里的SlightSSL都已在企业内部大规模部署。
|
||||
|
||||
性能提升。使用ecc证书代替RSA，服务端签名的性能可以提升4～10倍，但是客户端校验性能降低了约20倍，从10微秒级降低到100微秒级。另外一方面可以通过Session Ticket会话复用，节省一个RTT耗时。
|
||||
|
||||
|
||||
使用HTTPS之后，整个通道是不是就一定高枕无忧呢？如果客户端设置了代理，TLS加密的数据可以被解开并可能被利用 。这个时候我们可以在客户端将“证书锁定”（Certificate Pinning），为了老版本兼容和证书替换的灵活性，建议锁定根证书。
|
||||
|
||||
我们也可以对传输内容做二次加密，这块在统一接入层实现，业务服务器也同样无需关心这个流程。需要注意的是二次加密会增加客户端与服务器的处理耗时，我们需要在安全性与性能之间做一个取舍。
|
||||
|
||||
|
||||
|
||||
4. 其他优化
|
||||
|
||||
关于网络优化的手段还有很多，一些方案可能是需要用钱堆出来的，比如部署跨国的专线、加速点，多IDC就近接入等。
|
||||
|
||||
除此之外，使用CDN服务、P2P技术也是比较常用的手段，特别在直播这类场景。总的来说，网络优化我们需要综合用户体验、带宽成本以及硬件成本等多个因素来考虑。
|
||||
|
||||
下面为你献上一张高质量网络的全景大图。
|
||||
|
||||
|
||||
|
||||
QUIC与IPv6
|
||||
|
||||
今天已经讲得很多了，可能还有小伙伴比较关心最近一些比较前沿的技术，我简单讲一下QUIC和IPv6。
|
||||
|
||||
1. QUIC
|
||||
|
||||
QUIC协议由Google在2013年实现，在2018年基于QUIC协议的HTTP更被确认为HTTP/3。在连接复用中我说过HTTP/2 + TCP会存在队首阻塞的问题，基于UDP的QUIC才是终极解决方案。
|
||||
|
||||
如下图所示，你可以把QUIC简单理解为HTTP/2.0 + TLS 1.3 + UDP。
|
||||
|
||||
|
||||
|
||||
事实上，它还有着其他的很多优势：
|
||||
|
||||
|
||||
灵活控制拥塞协议。如果想对TCP内部的拥塞控制算法等模块进行优化和升级，整体周期是相对较长的。对于UDP来说，我们不需要操作系统支持，随时可改，例如可以直接使用Google的BBR算法。
|
||||
|
||||
“真”连接复用。不仅解决了队首阻塞的问题，在客户端网络切换的时候也不需要重连，用户使用App的体验会更加流畅。
|
||||
|
||||
|
||||
既然QUIC那么好，为什么我们在生产环境没有全部切换成QUIC呢？那是因为有很多坑还没有踩完，目前发现的主要问题还有：
|
||||
|
||||
|
||||
创建连接成功率。主要是UDP的穿透性问题，NAT局域网路由、交换机、防火墙等会禁止UDP 443通行，目前QUIC在国内建连的成功率大约在95%左右。
|
||||
|
||||
运营商支持。运营商针对UDP通道支持不足，表现也不稳定。例如QoS限速丢包，有些小的运营商甚至还直接不支持UDP包。
|
||||
|
||||
|
||||
尽管有这样那样的问题，但是QUIC一定是未来。当然，通过大网络平台的统一接入层，我们业务基本无需做什么修改。目前据我了解，腾讯、微博、阿里都在内部逐步加大QUIC的流量，具体细节可以参考我给出的链接。
|
||||
|
||||
2. IPv6
|
||||
|
||||
运维人员都会深深的感觉到IP资源的珍贵，而致力于解决这个问题的IPv6却在中国一直非常沉寂。根据《2017年IPV6支持度报告》，在中国只有0.38%的用户使用v6。
|
||||
|
||||
|
||||
|
||||
IPv6不仅针对IoT技术，对万物互联的时代有着非常大的意义。而且它对网络性能也有正向的作用，在印度经过我们测试，使用IPv6网络相比IPv4连接耗时可以降低10%～20%。推行IPv6后，无穷无尽的IP地址意味着可以告别各种NAT，P2P、QUIC的连接也不再是问题。
|
||||
|
||||
在过去的一年，无论是阿里云还是腾讯云都做了大量IPv6的工作。当然主要也是接入层的改造，尽量不需要业务服务做太多修改。
|
||||
|
||||
总结
|
||||
|
||||
移动技术发展到今天，跨终端和跨技术栈的联合优化会变得越来越普遍。有的时候我们需要跳出客户端开发的视角，从更高的维度去思考整个大网络平台。当然网络优化的水还是非常深的，有时候我们需要对协议层也有比较深入的研究，也要经常关注国外的一些新的研究成果。
|
||||
|
||||
2018年随着工信部发布《推进互联网协议第六版（IPv6）规模部署行动计划》的通知，所有的云提供商需要在2020年完成IPv6的支持。QUIC在2018年被定为HTTP/3草案，同时3GPP也将QUIC列入5G核心网协议第二阶段标准（3GPP Release 16）。
|
||||
|
||||
随着5G、QUIC与IPv6未来在中国的普及，网络优化永不止步，它们将推动我们继续努力去做更多尝试，让用户可以有更好的网络体验。
|
||||
|
||||
课后作业
|
||||
|
||||
你的应用使用的是哪个网络库？对于网络优化，你还有哪些实践经验？欢迎留言跟我和其他同学一起讨论。
|
||||
|
||||
网络优化是一个很大的话题，在课后你还需要进一步扩展学习。除了今天文章里给出的链接，这里还提供一些参考资料给你：
|
||||
|
||||
|
||||
微信客户端怎样应对弱网络
|
||||
|
||||
阿里亿级日活网关通道架构演进
|
||||
|
||||
阿里巴巴HTTP 2.0实践及无线通信协议的演进之路
|
||||
|
||||
|
||||
欢迎你点击“请朋友读”，把今天的内容分享给好友，邀请他一起学习。最后别忘了在评论区提交今天的作业，我也为认真完成作业的同学准备了丰厚的“学习加油礼包”，期待与你一起切磋进步哦。
|
||||
|
||||
|
||||
|
||||
|
||||
244
专栏/Android开发高手课/17网络优化（下）：大数据下网络该如何监控？.md
Normal file
244
专栏/Android开发高手课/17网络优化（下）：大数据下网络该如何监控？.md
Normal file
@ -0,0 +1,244 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
17 网络优化（下）：大数据下网络该如何监控？
|
||||
通过上一期的学习，我们对如何打造一个高质量的网络已经有了一个整体的认识。但是这就足够了吗？回想一下，一个网络请求从手机到后台服务器，会涉及基站、光纤、路由器这些硬件设施，也会跟运营商和服务器机房有关。
|
||||
|
||||
不论是基站故障、光纤被挖断、运营商挟持，还是我们的机房、CDN服务商出现故障，都有可能会引起用户网络出现问题。你有没有感觉线上经常突发各种千奇百怪的网络问题，很多公司的运维人员每天过得胆战心惊、疲于奔命。
|
||||
|
||||
“善良”的故障过了一段时间之后莫名其妙就好了，“顽固”的故障难以定位也难以解决。这些故障究竟是如何产生的？为什么突然就恢复了？它们影响了多少用户、哪些用户？想要解决这些问题离不开高质量的网络，而高质量的网络又离不开强大的监控。今天我们就一起来看看网络该如何监控吧。
|
||||
|
||||
移动端监控
|
||||
|
||||
对于移动端来说，我们可能会有各种各样的网络请求。即使使用了OkHttp网络库，也可能会有一些开发人员或者第三方组件使用了系统的网络库。那应该如何统一的监控客户端的所有的网络请求呢？
|
||||
|
||||
1. 如何监控网络
|
||||
|
||||
第一种方法：插桩。
|
||||
|
||||
为了兼容性考虑，我首先想到的还是插桩。360开源的性能监控工具ArgusAPM就是利用Aspect切换插桩，实现监控系统和OkHttp网络库的请求。
|
||||
|
||||
系统网络库的插桩实现可以参考TraceNetTrafficMonitor，主要利用Aspect的切面功能，关于OkHttp的拦截可以参考OkHttp3Aspect，它会更加简单一些，因为OkHttp本身就有代理机制。
|
||||
|
||||
@Pointcut("call(public okhttp3.OkHttpClient build())")
|
||||
public void build() {
|
||||
}
|
||||
|
||||
@Around("build()")
|
||||
public Object aroundBuild(ProceedingJoinPoint joinPoint) throws Throwable {
|
||||
Object target = joinPoint.getTarget();
|
||||
if (target instanceof OkHttpClient.Builder && Client.isTaskRunning(ApmTask.TASK_NET)) {
|
||||
OkHttpClient.Builder builder = (OkHttpClient.Builder) target;
|
||||
builder.addInterceptor(new NetWorkInterceptor());
|
||||
}
|
||||
return joinPoint.proceed();
|
||||
}
|
||||
|
||||
|
||||
插桩的方法看起来很好，但是并不全面。如果使用的不是系统和OkHttp网络库，又或者使用了Native代码的网络请求，都无法监控到。
|
||||
|
||||
第二种方法：Native Hook。
|
||||
|
||||
跟I/O监控一样，这个时候我们想到了强大的Native Hook。网络相关的我们一般会Hook下面几个方法 ：
|
||||
|
||||
|
||||
连接相关：connect。
|
||||
|
||||
发送数据相关：send和sendto。
|
||||
|
||||
接收数据相关：recv和recvfrom。
|
||||
|
||||
|
||||
Android在不同版本Socket的逻辑会有那么一些差异，以Android 7.0为例，Socket建连的堆栈如下：
|
||||
|
||||
java.net.PlainSocketImpl.socketConnect(Native Method)
|
||||
java.net.AbstractPlainSocketImpl.doConnect
|
||||
java.net.AbstractPlainSocketImpl.connectToAddress
|
||||
java.net.AbstractPlainSocketImpl.connect
|
||||
java.net.SocksSocketImpl.connect
|
||||
java.net.Socket.connect
|
||||
com.android.okhttp.internal.Platform.connectSocket
|
||||
com.android.okhttp.Connection.connectSocket
|
||||
com.android.okhttp.Connection.connect
|
||||
|
||||
|
||||
“socketConnect”方法对应的Native方法定义在PlainSocketImpl.c，查看makefile可以知道它们会编译在libopenjdk.so中。不过在Android 8.0，整个调用流程又完全改变了。为了兼容性考虑，我们直接PLT Hook内存的所有so，但是需要排除掉Socket函数本身所在的libc.so。
|
||||
|
||||
hook_plt_method_all_lib("libc.so", "connect", (hook_func) &create_hook);
|
||||
hook_plt_method_all_lib("libc.so, "send", (hook_func) &send_hook);
|
||||
hook_plt_method_all_lib("libc.so", "recvfrom", (hook_func) &recvfrom_hook);
|
||||
...
|
||||
|
||||
|
||||
这种做法不好的地方在于会把系统的Local Socket也同时接管了，需要在代码中增加过滤条件。在今天的Sample中，我给你提供了一套简单的实现。其实无论是哪一种Hook，如果熟练掌握之后你会发现它并不困难。我们需要耐心地寻找，梳理清楚整个调用流程。
|
||||
|
||||
第三种方法：统一网络库。
|
||||
|
||||
尽管拿到了所有的网络调用，想想会有哪些使用场景呢？模拟网络数据、统计应用流量，或者是单独代理WebView的网络请求。
|
||||
|
||||
|
||||
|
||||
一般来说，我们不会非常关心第三方的网络请求情况，而对于我们应用自身的网络请求，最好的监控方法还是统一网络库。不过我们可以通过插桩和Hook这两个方法，监控应用中有哪些地方使用了其他的网络库，而不是默认的统一网络库。
|
||||
|
||||
在上一期内容中，我说过“网络质量监控”应该是客户端网络库中一个非常重要的模块，它也会跟大网络平台的接入服务共同协作。通过统一网络库的方式，的确无法监控到第三方的网络请求。不过我们可以通过其他方式拿到应用的整体流量使用情况，下面我们一起来看看。
|
||||
|
||||
2. 如何监控流量
|
||||
|
||||
应用流量监控的方法非常简单，一般通过TrafficStats类。TrafficState是Android API 8加入的接口，用于获取整个手机或者某个UID从开机算起的网络流量。至于如何使用，你可以参考Facebook一个历史比较久远的开源库network-connection-class。
|
||||
|
||||
getMobileRxBytes() //从开机开始Mobile网络接收的字节总数，不包括Wifi
|
||||
getTotalRxBytes() //从开机开始所有网络接收的字节总数，包括Wifi
|
||||
getMobileTxBytes() //从开机开始Mobile网络发送的字节总数，不包括Wifi
|
||||
getTotalTxBytes() //从开机开始所有网络发送的字节总数，包括Wifi
|
||||
|
||||
|
||||
它的实现原理其实也非常简单，就是利用Linux内核的统计接口。具体来说，是下面两个proc接口。
|
||||
|
||||
// stats接口提供各个uid在各个网络接口（wlan0, ppp0等）的流量信息
|
||||
/proc/net/xt_qtaguid/stats
|
||||
// iface_stat_fmt接口提供各个接口的汇总流量信息
|
||||
proc/net/xt_qtaguid/iface_stat_fmt
|
||||
|
||||
|
||||
TrafficStats的工作原理是读取proc，并将目标UID下面所有网络接口的流量相加。但如果我们不使用TrafficStats接口，而是自己解析proc文件呢？那我们可以得到不同网络接口下的流量，从而计算出WiFi、2G/3G/4G、VPN、热点共享、WiFi P2P等不同网络状态下的流量。
|
||||
|
||||
不过非常遗憾的是，Android 7.0之后系统已经不让我们直接去读取stats文件，防止开发者可以拿到其他应用的流量信息，因此只能通过TrafficStats拿到自己应用的流量信息。
|
||||
|
||||
除了流量信息，通过/proc/net我们还可以拿到大量网络相关的信息，例如网络信号强度、电平强度等。Android手机跟iPhone都有一个网络测试模式，感兴趣的同学可以尝试一下。
|
||||
|
||||
|
||||
iPhone：打开拨号界面，输入“*3001#12345#*”，然后按拨号键。
|
||||
|
||||
Android手机：打开拨号界面，输入“*#*#4636#*#*”，然后按拨号键（可进入工程测试模式，部分版本可能不支持）。
|
||||
|
||||
|
||||
|
||||
|
||||
为什么系统可以判断此时的WiFi“已连接，但无法访问互联网”？回想一下专栏第15期我给你留的课后作业：
|
||||
|
||||
|
||||
iPhone的无线网络助理、小米和一加的自适应WLAN它们在检测WiFi不稳定时会自动切换到移动网络。那请你思考一下，它们是如何实现侦测，如何区分是应用后台服务器出问题还是WiFi本身有问题呢？
|
||||
|
||||
|
||||
我看了一下同学们的回复，大部分同学认为需要访问一个公网IP的方式。其实对于手机厂商来说根据不需要，它在底层可以拿到的信息有很多。
|
||||
|
||||
|
||||
网卡驱动层信息。如射频参数，可以用来判断WiFi的信号强度；网卡数据包队列长度，可以用来判断网络是否拥塞。
|
||||
|
||||
协议栈信息。主要是获取数据包发送、接收、时延和丢包等信息。
|
||||
|
||||
|
||||
如果一个WiFi发送过数据包，但是没有收到任何的ACK回包，这个时候就可以初步判断当前的WiFi是有问题的。这样系统可以知道当前WiFi大概率是有问题的，它并不关心是不是因为我们后台服务器出问题导致的。
|
||||
|
||||
大网络平台监控
|
||||
|
||||
前面我讲了一些应用网络请求和流量的监控方法，但是还没真正回答应该如何去打造一套强大的网络监控体系。跟网络优化一样，网络监控不是客户端可以单独完成的，它也是整个大网络平台的一个重要组成部分。
|
||||
|
||||
不过首先我们需要在客观上承认这件事情做起来并不容易，因为网络问题会存在下面这些特点：
|
||||
|
||||
|
||||
实时性。部分网络问题过时不候，可能很快就丢失现场。
|
||||
|
||||
复杂性。可能跟国家、地区、运营商、版本、系统、机型、CDN都有关，不仅维度多，数据量也巨大。
|
||||
|
||||
链路长。整个请求链条非常长，客户端故障、网链障络、服务故障都有可能。
|
||||
|
||||
|
||||
因此所谓的网络监控，并不能保证可以明确找到故障的原因。而我们目标是希望快速发现问题，尽可能拿到更多的辅助信息，协助我们更容易地排查问题。
|
||||
|
||||
下面我分别从客户端与接入层的角度出发，一起来看看哪些信息可以帮助我们更好地发现问题和解决问题。
|
||||
|
||||
1. 客户端监控
|
||||
|
||||
客户端的监控使用统网络库的方式，你可以想想我们需要关心哪些内容：
|
||||
|
||||
|
||||
时延。一般我们比较关心每次请求的DNS时间、建连时间、首包时间、总时间等，会有类似1秒快开率、2秒快开率这些指标。
|
||||
|
||||
维度。网络类型、国家、省份、城市、运营商、系统、客户端版本、机型、请求域名等，这些维度主要用于分析问题。
|
||||
|
||||
错误。DNS失败、连接失败、超时、返回错误码等，会有DNS失败率、连接失败率、网络访问的失败率这些指标。
|
||||
|
||||
|
||||
通过这些数据，我们也可以汇总出应用的网络访问大图。例如在国内无论我们去到哪里都会问有没有WiFi，WiFi的占比会超过50%。这其实远远比海外高，在印度WiFi的占比仅仅只有15%左右。
|
||||
|
||||
|
||||
|
||||
同样的我们分版本、分国家、分运营商、分域名等各种各样的维度，来监控我们的时延和错误这些访问指标。
|
||||
|
||||
由于维度太多，每个维度的取值范围也很广，如果是实时计算整个数据量会非常非常大。对于客户端的上报数据，微信可以做到分钟级别的监控报警。不过为了运算简单我们会抛弃UV，只计算每一分钟部分维度的PV。
|
||||
|
||||
2. 接入层监控
|
||||
|
||||
客户端监控的数据会比接入层更加丰富，因为有可能会出现部分数据还没到达接入层就已经被打回，例如运营商劫持的情况。
|
||||
|
||||
|
||||
|
||||
但是接入层的数据监控还是非常有必要的，主要的原因是：
|
||||
|
||||
|
||||
实时性。客户端如果使用秒级的实时上报，对用户性能影响会比较大。服务端就不会存在这个问题，它很容易可以做到秒级的监控。
|
||||
|
||||
可靠性。如果出现某些网络问题，客户端的数据上报通道可能也会受到影响，客户端的数据不完全可靠。
|
||||
|
||||
|
||||
那接入层应该关心哪些数据呢？一般来说，我们会比较关心服务的入口和出口流量、服务端的处理时延、错误率等。
|
||||
|
||||
3. 监控报警
|
||||
|
||||
无论是客户端还是接入层的监控，它们都是分层的。
|
||||
|
||||
|
||||
实时监控。秒级或者分钟级别的实时监控的信息会相比少一些，例如只有访问量（PV）、错误率，没有去拆分几百个上千个维度，也没有独立访问用户数（UV），实时监控的目的是最快速度发现问题。
|
||||
|
||||
离线监控。小时或者天级别的监控我们可以拓展出全部的维度来做监控，它的目的是在监控的同时，可以更好地圈出问题的范围。
|
||||
|
||||
|
||||
下面是一个简单根据客户端、国家以及运营商维度分析的示例。当然更多的时候是某一个服务出现问题，这个时候通过分域名或者错误码就可以很容易的找到原因。
|
||||
|
||||
|
||||
|
||||
那在监控的同时如何实现准确的自动化报警呢？这同样也是业界的一个难题，它的难度在于如果规则过于苛刻，可能会出现漏报；如果过于宽松，可能会出现太多的误报。
|
||||
|
||||
业界一般存在两种报警的算法，一套是基于规则，例如失败率与历史数据相比暴涨、流量暴跌等。另一种是基于时间序列算法或者神经网络的智能化报警，使用者不需要录入任何规则，只需有足够长的历史数据，就可以实现自动报警。智能化报警目前准确性也存在一些问题，在智能化基础上面添加少量规则可能会是更好的选择。
|
||||
|
||||
如果我们收到一个线上的网络报警，通过接入层和客户端的监控报表，也会有了一个大致的判断。那怎么样才能确定问题的最终原因？我们是否可以拿到用户完整的网络日志？甚至远程地诊断用户的网络情况？关于“网络日志和远程诊断，如何快速定位网络问题”，我会把它单独成篇放在专栏第二模块里，再来讲讲这个话题。
|
||||
|
||||
总结
|
||||
|
||||
监控、监控又是监控，很多性能优化工作其实都是“三分靠优化，七分靠监控”。
|
||||
|
||||
为什么监控这么重要呢？对于大公司来说，每一个项目参与人员可能成百上千人。并且大公司要的不是今天或者这个版本可以做好一些事情，而是希望保证每天每个版本都能持续保持应用的高质量。另一方面有了完善的分析和监控的平台，我们可以把复杂的事情简单化，把一些看起来“高不可攀”的优化工作，变成人人都可以做。
|
||||
|
||||
最后多谈两句我的感受，我们在工作的时候，希望你可以看得更远，从更高的角度去思考问题。多想想如果我能做好这件事情，怎么保证其他人不会犯错，或者让所有人都可以做得更好。
|
||||
|
||||
课后作业
|
||||
|
||||
对于网络问题，你尝试过哪些监控方法？有没有令你印象深刻的网络故障，最终又是通过什么方式解决的呢？欢迎留言跟我和其他同学一起讨论。
|
||||
|
||||
今天我们练习的Sample是通过PLT Hook，代理Socket相关的几个重要函数，这次还增加了一个一次性Hook所有已经加载Library的方法。
|
||||
|
||||
int hook_plt_method_all_lib(const char* exclueLibname, const char* name, hook_func hook) {
|
||||
if (refresh_shared_libs()) {
|
||||
// Could not properly refresh the cache of shared library data
|
||||
return -1;
|
||||
}
|
||||
int failures = 0;
|
||||
for (auto const& lib : allSharedLibs()) {
|
||||
if (strcmp(lib.first.c_str(), exclueLibname) != 0) {
|
||||
failures += hook_plt_method(lib.first.c_str(), name, hook);
|
||||
}
|
||||
}
|
||||
return failures;
|
||||
}
|
||||
|
||||
|
||||
希望你通过这几次课后练习，可以学会将Hook技术应用到实践当中。
|
||||
|
||||
欢迎你点击“请朋友读”，把今天的内容分享给好友，邀请他一起学习。最后别忘了在评论区提交今天的作业，我也为认真完成作业的同学准备了丰厚的“学习加油礼包”，期待与你一起切磋进步哦。
|
||||
|
||||
|
||||
|
||||
|
||||
204
专栏/Android开发高手课/18耗电优化（上）：从电量优化的演进看耗电分析.md
Normal file
204
专栏/Android开发高手课/18耗电优化（上）：从电量优化的演进看耗电分析.md
Normal file
@ -0,0 +1,204 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
18 耗电优化（上）：从电量优化的演进看耗电分析
|
||||
曾经有一句笑话说的是“用Android手机的男人一定是个好男人，因为他每天必须回家充电，有时候还得1天2次”。
|
||||
|
||||
我们现在工作和生活都离不开手机，但是却很难找到一款可以完全信赖、可以使用一整天的手机。在十年前的功能机时代，诺基亚可以做到十几天的超长待机。而现在的智能机时代，7nm的CPU、8GB内存、512GB的闪存，硬件一直在飞速发展，为什么电池的发展就不适用摩尔定律，电池技术一直没有突破性的进展呢？
|
||||
|
||||
功耗是手机厂商一直都非常重视的，OPPO更是直接以“充电5分钟，通话2小时”作为卖点。省电优化也是每年Google I/O必讲的内容，那么Android系统都为省电做了哪些努力呢？我们可以怎么样衡量应用的耗电呢？
|
||||
|
||||
耗电的背景知识
|
||||
|
||||
回顾一下专栏前面的内容，我已经讲过内存、CPU、存储和网络这几块内容了。LPDDR5内存、7nm CPU、UFS 3.0闪存、5G芯片，硬件一直以“更快、更小”的目标向前飞速发展。
|
||||
|
||||
但是手机上有一个重要部件多年来都没有革命性的突破，被我们吐槽也最多，那就是电池。智能手机的发展就像木桶原理一样，扼住智能手机发展咽喉的终究还是电池。
|
||||
|
||||
电池技术有哪些重要的评判标准？电池技术这些年究竟又有哪些进展？下面我们一起来聊聊手机电池的知识。
|
||||
|
||||
1. 电池技术
|
||||
|
||||
我们先看看苹果和华为这两大巨头最新旗舰机的表现。苹果的iPhone XS Max内置锂离子充电电池，电池容量为3174mAh，30分钟最多可充至50%电量。
|
||||
|
||||
华为Mate 20 Pro升级到4200mAh高度大容量锂离子电池，并首次搭载40W华为超级快充技术，30分钟充电约70%，还有15W高功率无线快充和反向无线充电“黑科技”。而Mate 20 X更是把电池容量升级到5000mAh，还创造性地将石墨烯技术应用到智能手机中。
|
||||
|
||||
|
||||
|
||||
从上面两款旗舰机的电池介绍中，我们可以发现手机电池的一些关键指标。
|
||||
|
||||
|
||||
电池容量。更大的电池容量意味着更长的续航时间，我们可以通过增加电池的体积或者密度来达到这个效果。智能手机的大部分空间都贡献给电池了，以华为Mate 20为例，电池占了所有内部组件中48%的空间，电池容量制约了手机迈向更轻、更薄。
|
||||
|
||||
充电时间。如果电池容量不是那么容易突破，那只能曲线救国考虑如何用更短的时间把电池充满。这里就需要依靠快充技术了，OPPO“充电5分钟，通话2小时”指的是VOOC闪充技术。快充技术无非是增大电流或者电压，目前主要分为两大解决方案，一个是高压低电流快充方案，另一个是低压大电流快充方案。关于快充技术的盘点，你可以参考这篇文章。
|
||||
|
||||
寿命。电池寿命一般使用充电循环次数来衡量，一次充电循环表示充满电池全部电量，但是并不要求一次性完成。例如在之前电池充到了25%，如果再充75%，两次组合在一起算是一次充电周期。去年苹果因为“降速门”面临了多起诉讼，通过处理器限速来解决续航不足的问题。根据苹果官方数据，500次充电循环iPhone电池剩余容量为原来的80%。
|
||||
|
||||
安全性。手机作为用户随时携带的物品，安全性才是首要考虑的因素。特别是从三星Note 7爆炸以来，各大手机厂商都在电池容量方面更加保守。所以无论是电池的密度，还是快充技术，我们首要保证的都是安全性。
|
||||
|
||||
|
||||
从历史久远的镍铬、镍氢，到现在普遍使用的锂离子电池，还是被称为革命性技术的石墨烯电池，虽然达不到摩尔定律，但电池技术其实也在不停地发展，感兴趣的同学可以参考《手机电池技术进步》。
|
||||
|
||||
事实上Mate 20 X只是使用石墨烯技术用于散热系统，并不是真正意义上的石墨烯电池。根据最新的研究成果表明，使用石墨烯材料可以让电池容量增加45%，充电速度可以加快5倍，循环寿命更高达3500次左右。可能在未来，12分钟就能把我们的手机电池充满，如果能够实现普及的话，将是电池发展史上的一个重要里程碑。
|
||||
|
||||
2. 电量和硬件
|
||||
|
||||
1000mAh的功能机我们可以使用好几天，为什么5000mAh的智能机我们需要每天充电？这是因为我们现在的手机需要视频通话，需要打“王者”“吃鸡”，硬件设备的种类和性能早就不可同日而语。
|
||||
|
||||
但是“王者”“吃鸡”等应用程序不会直接去消耗电池，而是通过使用硬件模块消耗相应的电能，下图是手机中一些比较耗电的硬件模块。
|
||||
|
||||
|
||||
|
||||
CPU、屏幕、WiFi和数据网络、GPS以及音视频通话都是我们日常的耗电大户。坦白说，智能手机硬件的飞速提升，许多其实都是厂商叫卖的噱头。绝大部分硬件对于我们来说都已经处于性能过剩的状态，但多余的性能同时也在消耗电量。
|
||||
|
||||
所以资源调度机制是厂商功耗优化最重要的手段，例如在卡顿优化的时候我就讲过，CPU芯片会分大小核架构，会灵活地为不同任务分配相应的运算资源。手机基带、GPS这些模块在不使用时也会进入低功耗或者休眠模式，达到降低功耗的目的。
|
||||
|
||||
现在越来越多厂商利用深度学习的本地AI来优化资源的调度，对GPU、运行内存等资源进行合理分配，确保可以全面降低耗电量。厂商需要在高性能跟电量续航之间寻找一个平衡点，有的厂商可能倾向于用户有更好的性能，有的厂商会倾向于更长的续航。
|
||||
|
||||
功耗的确非常重要，我做手机预装项目时，发现厂商会对耗电有非常严格的规定，这也让我对功耗的认识更深刻了。但是为了为了保证头部应用能有更好的体验，厂商愿意给它们分配更多的资源。所以出现了高通的CPU Boost、微信的Hardcode以及各个厂商的合作通道。
|
||||
|
||||
但是反过来问一句，为什么厂商只把微信和QQ放到后台白名单，但没有把淘宝、支付宝、抖音等其他头部应用也一起加入呢？根据我的猜测，耗电可能是其中一个比较重要的因素。
|
||||
|
||||
3. 电量和应用程序
|
||||
|
||||
各个硬件模块都会耗电，而且不同的硬件耗电量也不太一样，那我们如何评估不同应用程序的耗电情况呢？
|
||||
|
||||
|
||||
|
||||
根据物理学的知识，电能的计算公式为
|
||||
|
||||
电能 = 电压 * 电流 * 时间
|
||||
|
||||
|
||||
对于手机来说电压一般不会改变，例如华为Mate 20的恒定电压是3.82V。所以在电压恒定的前提下，只需要测量电流和时间就可以确定耗电。
|
||||
|
||||
最终不同模块的耗电情况可以通过下面的这个公式计算：
|
||||
|
||||
模块电量(mAh) = 模块电流(mA) * 模块耗时(h)
|
||||
|
||||
|
||||
模块耗时比较容易理解，但是模块电流应该怎样去获取呢？Android系统要求不同的厂商必须在 /frameworks/base/core/res/res/xml/power_profile.xml 中提供组件的电源配置文件。
|
||||
|
||||
power_profiler.xml文件定义了不同模块的电流消耗值以及该模块在一段时间内大概消耗的电量，你也可以参考Android Developer文档《Android 电源配置文件》。当然电流的大小和模块的状态也有关系，例如屏幕在不同亮度时的电流肯定会不一样。
|
||||
|
||||
|
||||
|
||||
Android系统的电量计算PowerProfile也是通过读取power_profile.xml的数值而已，不同的厂商具体的数值都不太一样，我们可以通过下面的方法获取：
|
||||
|
||||
|
||||
从手机中导出/system/framework/framework-res.apk文件。
|
||||
|
||||
使用反编译工具（如apktool）对导出文件framework-res.apk进行反编译。
|
||||
|
||||
查看power_profile.xml文件在framework-res反编译目录路径：/res/xml/power_profile.xml。
|
||||
|
||||
|
||||
对于系统的电量消耗情况，我们可以通过dumpsys batterystats导出。
|
||||
|
||||
adb shell dumpsys batterystats > battery.txt
|
||||
// 各个Uid的总耗电量，而且是粗略的电量计算估计。
|
||||
Estimated power use (mAh):
|
||||
Capacity: 3450, Computed drain: 501, actual drain: 552-587
|
||||
...
|
||||
Idle: 41.8
|
||||
Uid 0: 135 ( cpu=103 wake=31.5 wifi=0.346 )
|
||||
Uid u0a208: 17.8 ( cpu=17.7 wake=0.00460 wifi=0.0901 )
|
||||
Uid u0a65: 17.5 ( cpu=12.7 wake=4.11 wifi=0.436 gps=0.309 )
|
||||
...
|
||||
|
||||
// reset电量统计
|
||||
adb shell dumpsys batterystats --reset
|
||||
|
||||
|
||||
BatteryStatsService是对外的电量统计服务，但具体的统计工作是由BatteryStatsImpl来完成的，而BatteryStatsImpl内部使用的就是PowerProfile。BatteryStatsImpl会为每一个应用创建一个UID实例来监控应用的系统资源使用情况，统计的系统资源包括下面图里的内容。
|
||||
|
||||
|
||||
|
||||
电量的使用也会跟环境有关，例如在零下十度的冬天电量会消耗得更快一些，系统提供的电量测量方法只是提供一个参考的数值。不过通过上面的这个方法，我们可以成功把电量的测量转化为功能模块的使用时间或者次数。
|
||||
|
||||
准确的测量电量并不是那么容易，在《大众点评App的短视频耗电量优化实战》一文中，为我们总结了下面几种电量测试的方法。
|
||||
|
||||
|
||||
|
||||
当测试或者其他人反馈耗电问题时，bug report结合Battery Historian是最好的排查方法。
|
||||
|
||||
//7.0和7.0以后
|
||||
$ adb bugreport bugreport.zip
|
||||
//6.0和6.0之前:
|
||||
$ adb bugreport > bugreport.txt
|
||||
//通过historian图形化展示结果
|
||||
python historian.py -a bugreport.txt > battery.html
|
||||
|
||||
|
||||
Android耗电的演进历程
|
||||
|
||||
虽然iPhone XS Max电池容量只有3174mAh，远远低于大部分Android的旗舰机，但是很多时候我们发现它的续航能力会优于大部分的Android手机。
|
||||
|
||||
仔细想想这个问题就会发现，Android是基于Linux内核，而Linux大部分使用在服务器中，它对功耗并没有做非常严格苛刻的优化。特别是国内会有各种各样的“保活黑科技”，大量的应用在后台活动简直就是“电量黑洞”。
|
||||
|
||||
那Android为了电量优化都做了哪些努力呢？Google I/O每年都会单独讲解耗电优化，下面我们一起来看看Android在耗电方面都做了哪些改变。
|
||||
|
||||
1. 野蛮生长：Pre Android 5.0
|
||||
|
||||
在Android 5.0之前，系统并不是那么完善，对于电量优化相对还是比较少的。特别没有对应用的后台做严格的限制，多进程、fork native进程以及广播拉起等各种保活流行了起来。
|
||||
|
||||
用户手机用电如流水，会明显感受到下面几个问题：
|
||||
|
||||
|
||||
耗电与安装应用程序的数量有关。用户安装越多的应用程序，无论是否打开它们，手机耗电都会更快。
|
||||
|
||||
App耗电量与App使用时间无关。用户希望App的耗电量应该与它的使用时间相关，但是有些应用即使常年不打开，依然非常耗电。
|
||||
|
||||
电量问题排查复杂。无论是电量的测量，还是耗电问题的排查都异常艰难。
|
||||
|
||||
|
||||
当然在Android 5.0之前，系统也有尝试做一些省电相关的优化措施。
|
||||
|
||||
|
||||
|
||||
2. 逐步收紧：Android 5.0～Android 8.0
|
||||
|
||||
Android 5.0专门开启了一个Volta项目，目标是改善电池的续航。在优化电量的同时，还增加了的dumpsys batteryst等工具生成设备电池使用情况统计数据。
|
||||
|
||||
|
||||
|
||||
从Android 6.0开始，Google开始着手清理后台应用和广播来进一步优化省电。在这个阶段还存在以下几个问题：
|
||||
|
||||
|
||||
省电模式不够省电。Doze低功耗模式限制得不够严格，例如屏幕关闭还可以获取位置、后台应用的网络权限等。
|
||||
|
||||
用户对应用控制力度不够。用户不能简单的对某些应用做更加细致的电量和后台行为的控制，但是其实国内很多的厂商已经提前实现了这个功能。
|
||||
|
||||
Target API开发者响应不积极。为了不受新版本的某些限制，大部分国内的应用坚持不把Target API升级到Oreo以上，所以很多省电的功能事实上并没有生效。
|
||||
|
||||
|
||||
3. 最严限制：Android 9.0
|
||||
|
||||
我在Android 9.0刚出来的时候，正常使用了一天手机，在通知栏竟然弹出了下面这样一个提示：微信正在后台严重耗电。
|
||||
|
||||
|
||||
|
||||
尽管经过几个版本的优化，Android的续航问题依然没有根本性的改善。但你可以看到的是，从Android 9.0开始，Google对电源管理引入了几个更加严格的限制。
|
||||
|
||||
|
||||
|
||||
通过应用待机分组功能，我们可以确保应用使用的电量和它们的使用时间成正比，而不是和手机上安装的应用数量成正比。对于不常用的应用，它们可以“作恶”的可能性更小了。通过省电模式和应用后台限制，用户可以知道哪些应用是耗电的应用，我们也可以对它们做更加严格的限制。
|
||||
|
||||
另一方面，无论是Google Play还是国内的Android绿色联盟，都要求应用在一年内更新到最新版本的Target API。电池续航始终是Android的生命线，我相信今年的Android Q也会推出更多的优化措施。
|
||||
|
||||
总结
|
||||
|
||||
今天我讲了应用程序、Android系统、手机硬件与电池之间的关系，也回顾了Android耗电优化的演进历程。那落实到具体工作时，我们应该如何去做耗电优化呢？下一期我们来解决这个问题。
|
||||
|
||||
在讲内存、CPU、存储和网络这些知识的时候，我都会讲一些硬件相关的知识。主要是希望帮你建立一套从应用层到操作系统，再到硬件的整体认知。当你的脑海里面有一套完整的知识图谱时，才能更得心应手地解决一些疑难问题，进而可以做好对应的性能优化工作。
|
||||
|
||||
课后作业
|
||||
|
||||
今天的课后作业是，在日常的开发过程中，你遇到过哪些耗电问题？遇到这些问题的时候，你一般通过哪些手段去定位和修复呢？欢迎留言跟我和其他同学一起讨论。
|
||||
|
||||
欢迎你点击“请朋友读”，把今天的内容分享给好友，邀请他一起学习。最后别忘了在评论区提交今天的作业，我也为认真完成作业的同学准备了丰厚的“学习加油礼包”，期待与你一起切磋进步哦。
|
||||
|
||||
|
||||
|
||||
|
||||
245
专栏/Android开发高手课/19耗电优化（下）：耗电的优化方法与线上监控.md
Normal file
245
专栏/Android开发高手课/19耗电优化（下）：耗电的优化方法与线上监控.md
Normal file
@ -0,0 +1,245 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
19 耗电优化（下）：耗电的优化方法与线上监控
|
||||
相比启动、卡顿、内存和网络的优化来说，可能大多数应用对耗电优化的关注不是太多。当然并不是我们不想做耗电优化，更多时候是感觉有些无从下手。
|
||||
|
||||
不同于启动时间、卡顿率，耗电在线上一直缺乏一个可以量化的指标。Android系统通过计算获得的应用耗电数据只是一个估算值，从Android 4.4开始，连这个估算值也无法拿到了。当有用户投诉我们应用耗电的时候，我们一般也无所适从，不知道该如何定位、如何分析。
|
||||
|
||||
耗电优化究竟需要做哪些工作？我们如何快速定位代码中的不合理调用，并且持续监控应用的耗电情况呢？今天我们就一起来学习耗电的优化方法和线上监控方案。
|
||||
|
||||
耗电优化
|
||||
|
||||
在开始讲如何做耗电优化之前，你需要先明确什么是耗电优化，做这件事情的目的究竟是什么。
|
||||
|
||||
1. 什么是耗电优化
|
||||
|
||||
有些同学可能会疑惑，所谓的耗电优化不就是减少应用的耗电，增加用户的续航时间吗？但是落到实践中，如果我们的应用需要播放视频、需要获取GPS信息、需要拍照，这些耗电看起来是无法避免的。
|
||||
|
||||
如何判断哪些耗电是可以避免，或者是需要去优化的呢？你可以看下面这张图，当用户去看耗电排行榜的时候，发现“王者荣耀”使用了7个多小时，这时用户对“王者荣耀”的耗电是有预期的。
|
||||
|
||||
|
||||
|
||||
假设这个时候发现某个应用他根本没怎么使用（前台时间很少），但是耗电却非常多。这种情况会跟用户的预期差别很大，他可能就会想去投诉。
|
||||
|
||||
所以耗电优化的第一个方向是优化应用的后台耗电。知道了系统是如何计算耗电的，那反过来看，我们也就可以知道应用在后台不应该做什么，例如长时间获取WakeLock、WiFi和蓝牙的扫描等。为什么说耗电优化第一个方向就是优化应用后台耗电，因为大部分厂商预装项目要求最严格的正是应用后台待机耗电。
|
||||
|
||||
|
||||
|
||||
当然前台耗电我们不会完全不管，但是标准会放松很多。你再来看看下面这张图，如果系统对你的应用弹出这个对话框，可能对于微信来说，用户还可以忍受，但是对其他大多数的应用来说，可能很多用户就直接把你加入到后台限制的名单中了。
|
||||
|
||||
|
||||
|
||||
耗电优化的第二个方向是符合系统的规则，让系统认为你耗电是正常的。而Android P是通过Android Vitals监控后台耗电，所以我们需要符合Android Vitals的规则，目前它的具体规则如下：
|
||||
|
||||
|
||||
|
||||
虽然上面的标准可能随时会改变，但是可以看到，Android系统目前比较关心后台Alarm唤醒、后台网络、后台WiFi扫描以及部分长时间WakeLock阻止系统后台休眠。
|
||||
|
||||
2. 耗电优化的难点
|
||||
|
||||
既然已经明确了耗电优化的目的和方向，那我们就开始动手吧。但我想说的是，只有当你跳进去的时候，才能发现耗电优化这个坑有多深。它主要有下面几个问题：
|
||||
|
||||
|
||||
缺乏现场，无法复现。用户上传某个截图，你的应用耗电占比30%。通过电量的详细使用情况，我们可能会有一些猜测。但是用户也无法给出更丰富的信息，以及具体是在什么场景发生的，可以说是毫无头绪。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
信息不全，难以定位。如果是开发人员或者厂商可以提供bug report，利用Battery Historian可以得到非常全的耗电统计信息。但是Battery Historian缺失了最重要的堆栈信息，代码调用那么复杂，可能还有很多的第三方SDK，我们根本不知道是哪一行代码申请了WakeLock、使用了Sensor、调用了网络等。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
无法评估结果。通过猜测，我们可能会尝试一些解决方案。但是从Android 4.4开始，我们无法拿到应用的耗电信息。尽管我们解决了某个耗电问题，也很难去评估它是否已经生效，以及对用户产生的价值有多大。
|
||||
|
||||
|
||||
3. 耗电优化的方法
|
||||
|
||||
无法复现、难以定位，也无法评估结果，耗电优化之路实在是不容易。在真正去做优化之前，先来看看我们的应用为什么需要在后台耗电？
|
||||
|
||||
大部分的开发者不是为了“报复社会”，故意去浪费用户的电量，主要可能有以下一些原因：
|
||||
|
||||
|
||||
某个需求场景。最普遍的场景就是推送，为了实现推送我们只能做各种各样的保活。在需求面前，用户的价值可能被排到第二位。
|
||||
|
||||
代码的Bug。因为某些逻辑考虑不周，可能导致GPS没有关闭、WakeLock没有释放。
|
||||
|
||||
|
||||
所以相反地，耗电优化的思路也非常简单。
|
||||
|
||||
|
||||
找到需求场景的替代方案。以推送为例，我们是否可以更多地利用厂商通道，或者定时的拉取最新消息这种模式。如果真是迫不得已，是不是可以使用foreground service或者引导用户加入白名单。后台任务的总体指导思想是减少、延迟和合并，可以参考微信一个小伙写的《Android后台调度任务与省电》。在后台运行某个任务之前，我们都需要经过下面的思考：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
符合Android规则。首先系统的大部分耗电监控，都是在手机在没有充电的时候。我们可以选择在用户充电时才去做一些耗电的工作，具体方法可查看官方文档《监控电池电量和充电状态》。其次是尽早适配最新的Target API，因为高版本系统后台限制本来就非常严格，应用在后台耗电本身就变得比较困难了。
|
||||
|
||||
|
||||
IntentFilter ifilter = new IntentFilter(Intent.ACTION_BATTERY_CHANGED);
|
||||
Intent batteryStatus = context.registerReceiver(null, ifilter);
|
||||
|
||||
//获取用户是否在充电的状态或者已经充满电了
|
||||
int status = batteryStatus.getIntExtra(BatteryManager.EXTRA_STATUS, -1);
|
||||
boolean isCharging = status == BatteryManager.BATTERY_STATUS_CHARGING || status == BatteryManager.BATTERY_STATUS_FULL;
|
||||
|
||||
|
||||
|
||||
异常情况监控。即使是最严格的Android P，系统也会允许应用部分地使用后台网络、Alarm以及JobSheduler事件（不同的分组，限制次数不同）。因此出现异常情况的可能性还是存在的，更不用说低版本的系统。对于异常的情况，我们需要类似Android Vitals电量监控一样，将规则抽象出来，并且增加上更多辅助我们定位问题的信息。
|
||||
|
||||
|
||||
耗电监控
|
||||
|
||||
在I/O监控中，我指定了重复I/O、主线程I/O、Buffer过大以及I/O泄漏这四个规则。对于耗电监控也是如此，我们首先需要抽象出具体的规则，然后收集尽量多的辅助信息，帮助问题的排查。
|
||||
|
||||
1. Android Vitals
|
||||
|
||||
前面已经说过Android Vitals的几个关于电量的监控方案与规则，我们先复习一下。
|
||||
|
||||
|
||||
Alarm Manager wakeup 唤醒过多
|
||||
|
||||
频繁使用局部唤醒锁
|
||||
|
||||
后台网络使用量过高
|
||||
|
||||
后台WiFi scans过多
|
||||
|
||||
|
||||
在使用了一段时间之后，我发现它并不是那么好用。以Alarm wakeup为例，Vitals以每小时超过10次作为规则。由于这个规则无法做修改，很多时候我们可能希望针对不同的系统版本做更加细致的区分。
|
||||
|
||||
其次跟Battery Historian一样，我们只能拿到wakeup的标记的组件，拿不到申请的堆栈，也拿不到当时手机是否在充电、剩余电量等信息。
|
||||
|
||||
|
||||
|
||||
对于网络、WiFi scans以及WakeLock也是如此。虽然Vitals帮助我们缩小了排查的范围，但是依然需要在茫茫的代码中寻找对应的可疑代码。
|
||||
|
||||
2. 耗电监控都监控什么
|
||||
|
||||
Android Vitals并不是那么好用，而且对于国内的应用来说其实也根本无法使用。不管怎样，我们还是需要搭建自己的耗电监控系统。
|
||||
|
||||
那我们的耗电监控系统应该监控哪些内容，怎么样才能比Android Vitals做得更好呢？
|
||||
|
||||
|
||||
监控信息。简单来说系统关心什么，我们就监控什么，而且应该以后台耗电监控为主。类似Alarm wakeup、WakeLock、WiFi scans、Network都是必须的，其他的可以根据应用的实际情况。如果是地图应用，后台获取GPS是被允许的；如果是计步器应用，后台获取Sensor也没有太大问题。
|
||||
|
||||
现场信息。监控系统希望可以获得完整的堆栈信息，比如哪一行代码发起了WiFi scans、哪一行代码申请了WakeLock等。还有当时手机是否在充电、手机的电量水平、应用前台和后台时间、CPU状态等一些信息也可以帮助我们排查某些问题。
|
||||
|
||||
提炼规则。最后我们需要将监控的内容抽象成规则，当然不同应用监控的事项或者参数都不太一样。
|
||||
|
||||
|
||||
由于每个应用的具体情况都不太一样，下面是一些可以用来参考的简单规则。
|
||||
|
||||
|
||||
|
||||
在安卓绿色联盟的会议中，华为公开过他们后台资源使用的“红线”，你也可以参考里面的一些规则：
|
||||
|
||||
|
||||
|
||||
2. 如何监控耗电
|
||||
|
||||
明确了我们需要监控什么以及具体的规则之后，终于可以来到实现这个环节了。跟I/O监控、网络监控一样，我首先想到的还是Hook方案。
|
||||
|
||||
Java Hook
|
||||
|
||||
Hook方案的好处在于使用者接入非常简单，不需要去修改自己的代码。下面我以几个比较常用的规则为例，看看如果使用Java Hook达到监控的目的。
|
||||
|
||||
|
||||
WakeLock。WakeLock用来阻止CPU、屏幕甚至是键盘的休眠。类似Alarm、JobService也会申请WakeLock来完成后台CPU操作。WakeLock的核心控制代码都在PowerManagerService中，实现的方法非常简单。
|
||||
|
||||
|
||||
// 代理PowerManagerService
|
||||
ProxyHook().proxyHook(context.getSystemService(Context.POWER_SERVICE), "mService", this)；
|
||||
|
||||
@Override
|
||||
public void beforeInvoke(Method method, Object[] args) {
|
||||
// 申请Wakelock
|
||||
if (method.getName().equals("acquireWakeLock")) {
|
||||
if (isAppBackground()) {
|
||||
// 应用后台逻辑，获取应用堆栈等等
|
||||
} else {
|
||||
// 应用前台逻辑，获取应用堆栈等等
|
||||
}
|
||||
// 释放Wakelock
|
||||
} else if (method.getName().equals("releaseWakeLock")) {
|
||||
// 释放的逻辑
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
|
||||
Alarm。Alarm用来做一些定时的重复任务，它一共有四个类型，其中ELAPSED_REALTIME_WAKEUP和RTC_WAKEUP类型都会唤醒设备。同样，Alarm的核心控制逻辑都在AlarmManagerService中，实现如下：
|
||||
|
||||
|
||||
// 代理AlarmManagerService
|
||||
new ProxyHook().proxyHook(context.getSystemService
|
||||
(Context.ALARM_SERVICE), "mService", this)；
|
||||
|
||||
public void beforeInvoke(Method method, Object[] args) {
|
||||
// 设置Alarm
|
||||
if (method.getName().equals("set")) {
|
||||
// 不同版本参数类型的适配，获取应用堆栈等等
|
||||
// 清除Alarm
|
||||
} else if (method.getName().equals("remove")) {
|
||||
// 清除的逻辑
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
|
||||
其他。对于后台CPU，我们可以使用卡顿监控学到的方法。对于后台网络，同样我们可以通过网络监控学到的方法。对于GPS监控，我们可以通过Hook代理LOCATION_SERVICE。对于Sensor，我们通过Hook SENSOR_SERVICE中的“mSensorListeners”，可以拿到部分信息。
|
||||
|
||||
|
||||
通过Hook，我们可以在申请资源的时候将堆栈信息保存起来。当我们触发某个规则上报问题的时候，可以将收集到的堆栈信息、电池是否充电、CPU信息、应用前后台时间等辅助信息也一起带上。
|
||||
|
||||
插桩
|
||||
|
||||
虽然使用Hook非常简单，但是某些规则可能不太容易找到合适的Hook点。而且在Android P之后，很多的Hook点都不支持了。
|
||||
|
||||
出于兼容性考虑，我首先想到的是写一个基础类，然后在统一的调用接口中增加监控逻辑。以WakeLock为例：
|
||||
|
||||
public class WakelockMetrics {
|
||||
// Wakelock 申请
|
||||
public void acquire(PowerManager.WakeLock wakelock) {
|
||||
wakeLock.acquire();
|
||||
// 在这里增加Wakelock 申请监控逻辑
|
||||
}
|
||||
// Wakelock 释放
|
||||
public void release(PowerManager.WakeLock wakelock, int flags) {
|
||||
wakelock.release();
|
||||
// 在这里增加Wakelock 释放监控逻辑
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
Facebook也有一个耗电监控的开源库Battery-Metrics，它监控的数据非常全，包括Alarm、WakeLock、Camera、CPU、Network等，而且也有收集电量充电状态、电量水平等信息。
|
||||
|
||||
Battery-Metrics只是提供了一系列的基础类，在实际使用中，接入者可能需要修改大量的源码。但对于一些第三方SDK或者后续增加的代码，我们可能就不太能保证可以监控到了。这些场景也就无法监控了，所以Facebook内部是使用插桩来动态替换。
|
||||
|
||||
遗憾的是，Facebook并没有开源它们内部的插桩具体实现方案。不过这实现起来其实并不困难，事实上在我们前面的Sample中，已经使用过ASM、Aspectj这两种插桩方案了。后面我也安排单独一期内容来讲不同插桩方案的实现。
|
||||
|
||||
插桩方案使用起来兼容性非常好，并且使用者也没有太大的接入成本。但是它并不是完美无缺的，对于系统的代码插桩方案是无法替换的，例如JobService申请PARTIAL_WAKE_LOCK的场景。
|
||||
|
||||
总结
|
||||
|
||||
从Android系统计算耗电的方法，我们知道了需要关注哪些模块的耗电。从Android耗电优化的演进历程，我们知道了Android在耗电优化的一些方向以及在意的点。从Android Vitals的耗电监控，我们知道了耗电优化的监控方式。
|
||||
|
||||
但是系统的方法不一定可以完全适合我们的应用，还是需要通过进一步阅读源码、思考，沉淀出一套我们自己的优化实践方案。这也是我的性能优化方法论，在其他的领域也是如此。
|
||||
|
||||
课后作业
|
||||
|
||||
在你的项目中，做过哪些耗电优化和监控的工作吗？你的实现方案是怎样的？欢迎留言跟我和其他同学一起讨论。
|
||||
|
||||
今天的课后练习是，按照文中的思路，使用Java Hook实现Alarm、WakeLock和GPS的耗电监控。具体的规则跟文中表格一致，请将完善后的代码通过Pull requests提交到Chapter19中。
|
||||
|
||||
欢迎你点击“请朋友读”，把今天的内容分享给好友，邀请他一起学习。最后别忘了在评论区提交今天的作业，我也为认真完成作业的同学准备了丰厚的“学习加油礼包”，期待与你一起切磋进步哦。
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user