工匠若水

什么是 Annotation Processor 构建问题写过自定义注解处理器的老司机们乍一看这个问题觉得挺简单，是的，因为网上基本通篇都在教你怎么打日志，但是你有没有想过如果连日志都打印不出来的时候你怎么定位呢？譬如如下代码：// 确认 META-INF/services/javax.annotation.processing.Processor 没问题// 确认构建脚本没问题，确认注解 Bridge 有被使用且有参与构建@AutoService(Processor.class)public c

背景Linux 的 tracepath 指令可以追踪数据到达目标主机的路由信息，同时还能够发现 MTU 值。它跟踪路径到目的地，沿着这条路径发现 MTU。它使用 UDP 端口或一些随机端口。它类似于 Traceroute，只是不需要超级用户权限，并且没有花哨的选项。Android 也是移植的它，其源码放置位置在platform/external/iputils/tracepath6.c。我们之所以直接移植tracepath6.c而不是tracepath.c的原因是 tracepath6 支持 IPV6

背景我们都知道，Application 初始化一直是安卓开发中被诟病最多的问题之一，尤其是 app 支持多进程且航母级应用场景下。随着业务迭代，初始化代码控制不到位的情况下是灾难性的，后人不敢随意挪动位置，或者说因为时机太早且为 app 启动必经之路，每次修改的影响面都很难评估，造成的启动性能影响也很严重。此时可能很多小伙伴觉得 Jetpack 的 App Startup 库就是解决上面这段话里的问题的，因为他们觉得官方库介绍里说：The App Startup library provides a s

背景上一篇文章《记录一次 AGP 调研过程中的思考，我从一个事故搞出了一个故事！》发布后有很多小伙伴表示看不懂，本来不想写这篇的，但是恰巧最近大组有同事在做另一个技术需求时他的 R 也炸了，只是他炸的是 javac 阶段，我上篇分析的场景是 ASM 生成字节码阶段，所以我让他将他的R.java文件发我，我尝试编译并与我的字节码做对比发现了一点我以前没意识到的点，所以自己觉得上篇博文还是不够深入，AGP 升级的 R 问题还能继续挖坟考古，所以想来个续集。鉴于有人上篇没看懂，这篇就循序渐进的图文并茂下。所以接

背景看过我博客的老铁应该知道，我在 18 年五月写过一个小 gradle 插件https://github.com/yanbober/app-tiny-R-gradle-plugin，其作用就是将 app 生成的 R 常量进行内联操作。对，就是前不久很火的滴滴 booster 和字节跳动 ByteX 提供的 R 资源 inline 原理。这两天因为项目要升级适配 AGP4.1.0 版本，顺手要调研 AGP 4.1.0 构建对子 module 及合成最终 app 的 intermediates 产物 R

工匠若水可能会迟到，但是从来不会缺席，最终还是觉得将自己的云笔记分享出来吧 ～背景项目规模航母级庞大，年代久远，导致很多模块迟迟没有完全 gradle 化，所以浪费了一定的开发效率。由于构建采用了类似 c 语言的宏定义概念控制，加上自定义的拆 dex 构建，对部分大型模块不熟悉，所以整个构建无比复杂，从而对完全 gradle 化带来了一些坑。本文仅以总结记录自己的落地经验，以便后续回忆分析。落地过程中的坑与解决方案整体迁移的思路是先依据各种 ant 构建自定义的 build.xml 翻译成对应规则的

关于Launcher是啥的问题我想这里就没必要再强调了。由于一些原因迫使最近开始需要研究一下Launcher3源码，为了不再像以前那么傻逼（研究Settings等代码没作笔记），故这里赶紧将阶段性的感悟整理成文章，方便日后回看。其实本文来源于我在项目组内部的一次分享活动的ppt。

最近有些乱，各种事情，各种交叉。好在还有一点上进心，于是继续将自定义这个系列的核心知识再梳理一下吧。关于自定义控件前面博文说过了，这里不会教你拿来主义，只授之以渔，如果你喜欢拿来主义，不好意思，请绕行，如果你喜欢得渔，那请继续。前面我们已经叙述过了几篇关于自定义View涉及的东西，大家可以自己回过头去看我之前的博客，譬如事件处理、坐标系、工具类等。下面我们还是继续补充一些常用的自定义控件工具类。

很多人可能不屑一顾Android的坐标系，但是如果你想彻底学会自定义控件，我想说了解Android各种坐标系及一些API的坐标含义绝对算一个小而不可忽视的技能；所谓Android自定义View那几大主要onXXX()方法的重写实质其实大多数都是在处理坐标逻辑运算，所以我们就先来就题重谈一下Android坐标系。

其实这篇文章可能有些小题大作，但回过头想想还是很有必要的，有点阴沟里翻船的感觉。相信大家都知道Android API Level 8开始提供了为应用程序备份和恢复数据的功能，此功能的开关可以通过应用程序中AndroidManifest.xml文件的allowBackup属性值进行配置，默认是True，所以用户可以对我们应用程序进行数据备份。

在我们App开发中大家可能都会有过如下痛疾（程序员和设计妹妹注意喽）：好多小的图标好烦人，又占体积还要考虑分辨率，一拉伸就模糊等。同一个图标不同状态还有不同颜色的多张。总是幻想IOS、Android、Web等对于一个图标只切一次图多好。如果你有过类似的痛疾那么下面讨论的故事就是一个完美的解决方案，当然了，采用下面方案对于重型应用或者固件级的优化才会十分明显，对于普通小应用那就要看自己了。

1 背景建议阅读本文之前先阅读《Android Studio入门到精通》和《Groovy脚本基础全攻略》及《Gradle脚本基础全攻略》三篇博客作为背景知识，这样才能更好、更系统的串起来。本文的核心就是下图：关于Gradle的Android插件本文不会过多的说明，只给一个抛砖引玉的提示，详细使用参见文档API及Gradle配置，其实个性化的构建配置一般都是Gradle与Groovy的编写，与Andr

1 背景其实有点不想写这篇文章的，但是又想写，有些矛盾。不想写的原因是随便上网一搜一堆关于性能的建议，感觉大家你一总结、我一总结的都说到了很多优化注意事项，但是看过这些文章后大多数存在一个问题就是只给出啥啥啥不能用，啥啥啥该咋用等，却很少有较为系统的进行真正性能案例分析的，大多数都是嘴上喊喊或者死记住规则而已（当然了，这话我自己听着都有些刺耳，实在不好意思，其实关于性能优化的优质博文网上也还是有很多

题外话：有段时间没有更新博客了，这篇文章也是之前写了一半一直放在草稿箱，今天抽空把剩余的补上的。消失的这段时间真的好忙，节奏一下子有些适应不过来，早晨七点四十就得醒来，晚上九点四十才准备下班，好像最近都与世隔离了一样；然而自己每天还要熟悉一大套自己不熟悉、各种协议差异的代码。其实换个角度考虑还是蛮好的，忙，但很充实，有新的挑战与收获。【工匠若水 http://blog.youkuaiyun.com/yanbob

前面分析那么多系统源码了，也该暂停下来休息一下，趁昨晚闲着看见一个有意思的需求就操练一下分析源码后的实例演练----自定义控件。

之所以要谈这个话题是因为你在开发App时可能会发现，Activity担负的责任非常之重，如果站在MVC框架角度看自己开发的App，一般xml布局文件科Activity的setContentView等充当了View角色，Activity其他代码充当了Controller角色，其他数据来源（数据库等）充当了Model角色。所以你会发现Activity违背单一职责原则，负担过重。同时如果要测试逻辑数据层会发现比较难编写测试

Drawable 是一个抽象类，提供了一些 API 方法去处理各种资源的绘制，但是又不具备 View 的事件与交互处理能力。额，再简单粗暴一点认为就是一个辅助绘制工具类，把各种东西都封装搞好以后直接给Canvas去画。既然是工具类，说白了就是个模板，你就把它类比 View 或者 Paint 来看吧。

由于工作需要，模拟一个signal变化量走势，所以需要绘制折线动态图，话说使用achartengine这个jar包就能实现各种图形绘制，but工程导入一个包在大小上毕竟是要付出代价的嘛，况且只是为了实现画一条动态曲线嘛，故就用重写View实现了下，还是惯例，直接上代码。最主要的实现类：package com.jesse.paintline1;import java.util.Array