TechMix的博客

Android系统提供了多种日志缓冲区用于开发调试，包括main（应用/系统日志）、system（系统组件）、events（事件日志）、radio（通信相关）等。通过logcat命令可分别查看不同日志：logcat -b main查看应用日志，logcat -b events分析页面生命周期和进程状态，adb shell cat /proc/kmsg获取内核日志。这些日志分别用于定位应用问题、分析ANR/进程异常以及排查底层系统问题，是Android开发调试的重要工具。

帧率优化的首要工作——流畅性量化，本文总结日常进行帧率优化过程，帧率的三种计算方式，方便日常分析方向的确定。

TargetClass(value = “android.graphics.Bitmap”) 注解指定要插桩的类全路径，可以通过AS查找到这个类后鼠标放在类名上右键选择copy Reference就可以拿到该注解需要传入的参数值。因为加载Bitmap基本都要经过Bitmap.create()方法创建Bitmap对象，所以只需要hook掉所有Bitmap.createBitmap()方法的重载方法即可监控到图片的创建过程，在hook方法执行到时，通过。的方式就可以计算出bitmap的内存占用大小。

看红色框住的信息可以看到有注明线程进入Runnable状态是被谁唤醒的，这里是被pid=19180的进程的tid=23674，name=TVKPlayerManag的线程唤醒的，看到这里就能确认是因为主线程等待23674的某个条件满足导致进入sleeping状态，一般常见的比如线程同步锁，被子线程持有了，然后主线程也需要获取到同步锁才能继续下一行执行代码，也是会出现该现象。从以上信息我们只能知道是哪里进入sleep状态的，会持续多久，并不能知道是谁导致的进入sleep状态。

一、systrace基本介绍被弃用了？二、快捷键用法二、systrace命令用法三、systrace报告怎么看？3.1 CPU调度信息3.2 线程状态信息3.2.1 绿色 : 运行中（Running）3.2.1 蓝色：Runanble状态3.2.1 白色：Sleeping状态3.2.1 橘色：不可中断的睡眠态 （Uninterruptible Sleep - IO Block）3.2.1 紫色 : 不可中断的睡眠态（Uninterruptible Sleep）3.4 帧率信息3.5 应用启动耗时分析。

小程序的项目结构基本是按照前端最基础架构设计的，界面、逻辑、布局样式分别在不同的源文件中编写，但是和前端不同的是，微信小程序的源文件后缀都是被微信重新定义的。有点像某遥遥领先厂设计的，原本Android系统的Activity重新设计成了XXXAbility，实际上的指责是很类似的，因为实际上完成功能逻辑的架构模型是想通的，这个思想上并没有特别大的变化。

总结在日常开发中LiveData数据注册-更新的逻辑，什么时候更新和注意事项。

经过一番调研，最后选择使用较为常用的CountDownLatch配合线程池将无依赖的接口由串行改成并行，起初是使用同一个线程池，结果在拆分任务较多时，并发量大时出现了线程死锁问题，最后通过Android Studio自带的dump线程的功能，分析发现是在线程池的任务队列中死锁了。因为业务需求背景，某些功能页面会请求较多的网络接口，毕竟后端更多的是考虑业务的解耦，会造成客户端优化较多接口请求导致的等待耗时（转圈）问题，后端推动接口的合并困难，但是前端也是可以做一些优化的。

    GSON是Google提供的开源库，使用很便捷，但是在使用过程中也发现了其短板，在Bean类结构复杂时，进行反序列化耗时占比较高，尤其是很多在应用启动阶段需要反序列化一些内置的数据时，很让人头疼，通过抓Trace每次都能发现这货肯定是大头。    为了从正面优化这个问题，于是我翻看了GSON反序列化的源码，实现了能优化的方案，希望能帮助到同样面临该问题的同学们，如有问题也可以提出来。如上图GSON解析过程的耗时可以

1、协程基本概念，和进程线程的关系，协程的关键API总结2、挂起函数的作用和执行流程3、Android常见的协程使用场景写法4、几种协程调度器的适用场景总结5、如何取消协程

记录使用AudioManager#requestAudioFocus()之后调用abandonAudioFocusRequest反注册，仍然内存泄漏问题。因为存放OnAudioFocusChangeListener的Map的key是用AudioManager对象的toString()拼接listener.toString()构造的。

从源码角度分析Activity，Window和View的关系，总结学习经验，让您更加理解Android的GUI设计原理。

Service的ANR触发原理，是在启动Service前使用Handler发送一个延时的Message（埋炸弹过程），然后在Service启动完成后remove掉这个Message（拆炸弹过程）。如果在指定的延迟时间内没有remove掉这个Message，那么就会触发ANR（没有在炸弹爆炸前拆掉就会爆炸），弹出AppNotResponding的弹窗，让用户选择是继续等待还是直接退出应用程序。通过源码更深层次的理解ANR是这么产生的，从而在日常开发和实际ANR问题分析时能够游刃有余。

1. 追本溯源，清楚逻辑2. 代码未动，方案先行3. 及时记录改动点、影响面4. 改完一个点，要自测自测自测最小化commit，message要规范清晰