转载请注明出处：https://lizhaoxuan.github.io

概述

如果你已经读完了前面的5章博客，相信你已经对APT整体已经比较熟悉了，所以，APT真的很简单对嘛？

但就像我前面提到过的，APT是一套非常强大的机制，它唯一的限制在于你天马行空的设计！

APT有着非常简单的技术实现，但其应用场景却着实有点尴尬。我一直期望可以探索出ButterKnife和EventBus以外的应用场景，却始终未能如愿。姑且把我目前总结的成果列举，共勉~

（本系列所讲APT均泛指编译时注解+代码生成，虽然运行时注解也属APT）

转载请注明出处：https://lizhaoxuan.github.io

概述

Android编译时注解框架从入门到项目实践。该系列将通过5篇博客一步步教你打造一个属于自己的编译时注解框架，并在之后开源出基于APT的编译时注解框架。

提到注解，普遍都会有两种态度：黑科技、低性能。而使用注解往往可以实现用非常少的代码作出匪夷所思的事情，比如这些框架：ButterKnife、Retrofit。

但一直被人诟病的是，运行时注解会因为java反射而引起较为严重的性能问题…

转载请注明出处：https://lizhaoxuan.github.io

概述

先讲一下编写《Android编译时注解框架》的初衷吧，APT其实并不难，可以说是简单且高效，但关于APT的资料却并不多，甚至很多人都不知道这么一个技术。国内关于APT的博客屈指可数，唯二找到的几篇初级讲解一个是用Eclipse写得，一个是用AndroidStudio加Intellij。刚开始着实踩了不少坑，但事实是，APT完全可以用AndroidStudio单独实现。光是项目搭建就如此麻烦了，更别提语法讲解了。资料匮乏无疑提高了APT的入门门槛。

正因为如此，这个系列博客就这样诞生啦~现在就教你用AndroidStudio一步步打造自己的APT框架。

转载请注明出处：https://lizhaoxuan.github.io

概述

因为编译时注解框架前期项目搭建部分需要较多的图文讲解，所以前一章《Android编译时注解框架-Run Demo》只是实现了最简单应用，或许注解信息，并没有生成代码。

本章将以生成代码为重点进行一个案例讲解。

转载请注明出处：https://lizhaoxuan.github.io

概述

因为有关APT的资料过少，又因为是Java Moudle +Android Moudle的使用方式，在项目编写过程中，会有一些匪夷所思的奇怪问题~入门阶段真的是步履维艰。

这篇博客就是编写《Android编译时注解框架》系列中，将所遇到的一些坑列举出来，并给出一些绕过坑的方法。（注意哦~是绕过，坑还在，没有填~因为不知道这坑咋来的……）

随时踩坑，随时更新~

转载请注明出处：https://lizhaoxuan.github.io

概述

本章内容主要对APT一些语法进行简单讲解。apt的学习资料真的太少了，我的学习方法基本上只能通过看开源库的源码猜、看源码注释猜、自己运行着猜……

这里对猜对的结果进行一个总结，让后来者可以更快的上手。

转载请注明出处：https://lizhaoxuan.github.io

前言

一个一般事实:只有当发现“严重”的性能问题时，我们才会开始着手进行性能优化，此时虽然可以针对性的解决程序严重性能问题。但在继续优化过程中，面对无数细小的“不良”代码，却又力不从心。相比得到的些微性能改善，庞大的工作量不得不令人放弃。

但同样不得不承认的是，无数细小的不良代码所累加的性能问题是不可忽视的。面对这样一个问题，也许最佳的解决办法便是从编码之初上着手进行。

转载请注明出处：https://lizhaoxuan.github.io

众所周知，java GC 是影响Android应用性能的主要因素之一。完全交给系统管理的GC往往不尽如人意，而开发者却也毫无办法，只能对着GC迎合啊迎合，想着办法把GC哄开心了呗~

网上也不乏众多的android 内存优化文章，成为开发者的编码守则。但不管怎么遵守，内存管理依然像一个黑盒子一样，反正我是写着不踏实。就比如下面这几种情况：

• System.gc(),真的是随叫随到？
• 软引用弱引用的错误使用
• 你觉得内存释放了，它就真的释放了么?

幸得Android Monitor 提供了内存监视器，起码打开了一个窗口可以让我们看看当前应用的内存到底是什么样的。 那么现在我们就来通过一个小Demo，看看android 的GC到底是怎么样吧。

转载请注明出处：https://lizhaoxuan.github.io

android真的被玩坏了，android界有一场永远停不下来的攻防战，攻和防都流氓

背景

做为用户，你肯定抱怨过手机上有太多杀不死的应用浪费你的内存，浪费内存就算了，他们还跑你的流量。OK，为了提供更好的用户体验，以MIUI为首的神隐模式（因为我只知道MIUI的叫神隐……就先以他为首吧，有了解谁先出的快告诉我），各个系统厂商都推出自己的XX模式。

在手机息屏后，未加入白名单的应用将会被禁止访问网络。

嗯……这个做的好！用户这回开心了呀:-D。（虽然好像有人抱怨神隐有Bug）。

可是开发者哭了啊，老板一定要让我完成这个需求啊，隔段时间上传或获取个数据呀，你给我断网了我咋办？系统级屏蔽的啊这是，我没法搞了啊……联系运营产品公关还有各种大BOSS!

转载请注明出处：https://lizhaoxuan.github.io

前言

本文主要对过度绘制和图形渲染做一个概念性的描述。

同时以案例方式列出一些简单适用的优化措施。

如果你已对过度绘制有过一些了解，那么你应该明白，仅是简单的层级优化对过度绘制的改善是很小的。所以，这时候你可以参考这篇文章：

优化Android过度绘制

另外如果你还想知道更多关于View优化原理，可以参考 Google 发布的 Android 性能优化典范