小笔记

笔记一：

平时放图片的时候我们尽量压缩一下再放入到mipmap文件夹中，对减少我们APK的大小多少有点用处，嘿嘿~
虽然这个活是UI同学的...对吧

有个图片压缩的网站挺好用的，推荐用一下：

压缩图片

---

笔记二：

项目中进行延时操作，
出现Thread.sleep的，最好使用Handler.postDelayed替换掉
①究其原因，Thread.sleep它是让线程挂起，然后到点唤起响应。
它的不好之处在于：它会占用系统的线程资源，使用这种方式在实现延时操作本身就是一种性能的浪费。如同占着茅坑不拉屎！线程是一种十分宝贵的资源，创建，销毁，切换 都是相当耗性能的。

当sleep的时候，就等于说：现在我不用，但是你也别想用。你要用？自己去创建一个Thread。

有的人说，Sleep的时候不占用CPU啊！对，是不占用CPU ，但是占着线程资源,阻碍系统的线程调度!
这里引用一段关于Thread的文章：

Threads are a limited resource, they take approximately 200,000 cycles to create and about 100,000 cycles to destroy. By default they reserve 1 megabyte of virtual memory for its stack and use 2,000-8,000 cycles for each context switch. This makes any waiting thread a huge waste.

可以参考下这文章:
为什么要放弃使用Thread.Sleep

②.Handler.postDelayed
放弃使用Thread.sleep，那就得找个方法替代它。
我们项目中使用的是Handler.postDelayed来替换。
因为....我叙述一遍Handler.postDelayed的流程你就知道了，人家就不是占着茅坑不拉屎的方式：
(1):postDelay()一个10秒钟的Runnable A，消息进队，MessageQueue调用nativePollOnce()阻塞，Looper阻塞；
(2):紧接着post()一个Runnable B，消息进队，判断现在A时间还没到，正在阻塞，把B插入消息队列的头部(A的前面)，然后调用nativeWake()方法唤醒线程；
(3):MessageQueue.next()方法被唤醒后，重新开始读取消息链表，第一个消息B无延时，直接返回给Looper；
(4):Looper处理完这个消息再次调用next()方法，MessageQueue继续读取消息链表，第二个消息A还没到时间，计算一下剩余时间（假如还剩9秒）继续调用nativePollOnce()阻塞，直到阻塞时间到或者下一次有Message进队；

详细过程看过来：
你真的懂Handler.postDelayed()的原理吗?

笔记三

ManifestPlaceholders - 动态配置AndroidManifest
我在做项目的时候，有一个需求点，就是靠短信里面的Url来启动APP，本来是个挺简单的需求。但是后端给的Url有点不一样，给了两个：

1、https://tklife.mobile.taikang.com/app?sxt_uri=https%3a%2f%2fw.url.cn%2fs%2fArM0bZt
2、tk://tklife/app?sxt_uri=https%3a%2f%2fw.url.cn%2fs%2fArM0bZt

第一个Url是直接短信可以启动APP，这个很好实现，只要在AndroidManifest里需要启动显示的Activity注册代码里面添加个intent-filter：

关键代码在data

未完待续