某周六线上运营报障，在部分用户的Android手机上个别地图图标未能正常显示，只有部分手机有问题(7.0及以下版本)有问题，诡异的是只有个别图标(1个)显示有问题，大部分图标显示并没有问题,开发介入验证后发现更诡异的是，只在release版本才有这个问题，开发debug版本上并没有问题。
低版本显示有问题还好理解，这应该是一个版本兼容相关的问题。release和debug上个别图标有差别就有点匪夷所思了，写篇博客记录下。
什么是aspectd？aspectd是闲鱼针对dart的AOP开源框架。https://github.com/alibaba-flutter/aspectd.git
阅读本文你将得到什么？
- 掌握aspectd的环境搭建，并如何在本地成功运行aspectd的demo
- 掌握有关aop的基础概念
- 了解aspectd的基础用法和原理
对内存问题的分析中一个必不可少的环节应该就是对hprof的分析了，常见的MAT和Leakcanry都是针对hprof文件的分析工具。这篇文章就记录下做内存分析的一般工具和分析步骤。
这里说的Android虚拟机指运行在Android平台上的虚拟机，即日常遇到的Dalvik和ART虚拟机。这篇文章记录了自己对Android虚拟机几个问题的理解。只是个人学习和理解过程的记录，如有不当之处万望指正，邮箱yangfan3687@163.com。也希望在面对下面这些所谓JVM常见问题时能给你带来不一样的思考。
- 问题1：如何理解JVM内存模型？
- 问题2：什么是GC ROOTS？
- 问题3：Android虚拟机有没有分代回收？
在实际的开发工程中，对视图增加圆角和阴影效果的绘制是比较常见的需求，Android系统提供了一系列的方法以帮助开发者实现基础的视图圆角和阴影效果，但在面对实际的视觉需求时，想要完美达到视觉设计师的设计要求就难免需要了解一些基础的绘图原理和绘图方法才能达到特殊的设计需求，这里就简单对比和总结了常见的圆角和阴影的绘图方法。
Application Not Responding（简称:ANR）指应用中一些特定的事件（如用户触摸事件、广播等）在应用的主线程没有在规定的时间内处理完，系统自动做出终止应用运行的响应。问题出现的原因主要是两个方面：
- 应用进程自身引起的，例如：主线程阻塞、挂起、死循环
- 应用进程的其他线程的CPU占用率高，使得主线程无法抢占到CPU时间片
常见的三种ANR类型：
- KeyDispatchTimeout(谷歌默认5s，MTK平台上是8s): 主要类型按键或触摸事件在特定时间内无响应
- BroadcastTimeout(10s): 主要是BroadcastRecevier在规定时间无法处理完成。前台广播超时时间是10s,后台广播超时是60s,这类超时没有提示框弹出。代码见AMS的
BROADCAST_FG_TIMEOUT和BROADCAST_BG_TIMEOUT。 - ServiceTimeout(20s): Service在规定时间内无法处理完成操作，即会报出服务超时，这类ANR同样没有提示框出现。超时时间，前台Service是20s，后台Service是200s。代码见ActivityServices的
SERVICE_TIMEOUT和SERVICE_BACKGROUND_TIMEOUT。
在移动端无痕埋点实践详解（一）这篇文章大致总结了移动端无痕埋点的基本原理。主要介绍了什么是无痕埋点，无痕埋点的基础数据流程以及在Android系统上总体思路。这篇文章着重总结下无痕埋点方案的实施过程中在Android和iOS系统上几个细节的解决方案。
Android插件化框架一直以来就是安卓平台上的一个重要技术方向，从携程的DynamicAPK到360RePlugin再到阿里巴巴的Atlas，甚至美团和滴滴的安卓团队都有自己的一套安卓插件化解决方案。面对业界如此热门的技术方向，在对比业界开源的插件化方案后，团队内部于去年10月份开始(2017.10)在项目中选择开源的Small插件化框架进行了尝试。鞋是否合适需要穿上脚才能知道。这篇文章总结了我在使用Small插件化框架后，自己对插件化的理解和思考。
不管是android、ios还是浏览器端的开发，在正常的产品迭代过程中HTTP网络请求都是高频使用的功能。以android端为例，在使用常见的http网络框架时，如HttpUrlConnection,HttpClient或者okHttp ，开发者都必须在此自身业务场景的基础上进行api的二次封装。一个功能强大且易用的网络框架不仅仅能够提高开发效率，起到事半功倍的效果，还能起到规范业务开发结果的作用。
希望通过这篇文章，总结下自己在设计和实现一个网络框架时的思考过程，也帮助团队同学了解现有网络框架的能力和不足。
用户数据埋点的一般解决思路是使用代码手动埋点。国内主要的第三方数据分析服务商，如百度统计、友盟、TalkingData等都提供这一方案。但是使用代码手动埋点的方式，投入资源大，往往很难能够有实际产出。其中一个很重要的原因其实是在分析实际业务数据之前，很难知道我真正想看什么样的数据。用代码手动的埋点方案经常会导致一个尴尬的解决，想要看的数据没有埋，埋了的数据不准。
用户数据埋点是少见的涉及到一个产品研发团队所有角色的项目。从运营的数据需求，到产品经理的抽象和规范，到移动端前端的手动采集数据，再到服务端和大数据的存储和转换，最终把结果反馈给运营和产品经理。埋点的实际产出涉及到几乎所有部门，如果按照链式的工作流来解决埋点问题，当任何一个环节出现问题，都会对整个项目结果的产出产生影响。这篇文章记录了无痕埋点方案的思路与其核心问题的解决方案。