应用背景

诸多业务场景下，都有使用kv型式存储数据供快速查询的需求。正常的做法有使用HashMap存入内存，或者存入外部的nosql KV数据库/缓存。

• 使用HashMap做KV存储，速度快，但是如果数据量达到百万及至千万级时，HashMap必将占用大量的java堆内存，给应用带来极大的内存回收压力。
• 外部kv存储，以堆外（offHeap）存储的方式让我们的应用免于内存回收之忧，但其查询性能往往低于内存map。假设采用外部db的方式作kv存储，就会引入服务之间的通信成本，以基于LR(逻辑回归)实现推荐系统的打分服务为例，每次打分，须执行近求成百上万次kv查询（lr参数的查询），如此的查询量对性能的要求是极高的，如果每一次查询都要查询外部服务，那么网络io势必占用大量的时间。

此外，在工作中会发现很多算法问题，都会被转换为一种追求效率的搜索问题，高效的内嵌式kv存储就会显得更有价值。

更多>>

CommonServiceManager 是一个使用方便、可扩展的服务接口管理库。
Github 地址：https://github.com/lollipopgood/CommonServiceManager

更多>>

Binder 是 Android IPC 的重要角色，在平时一般的工程中，知道 AIDL 的用法大抵都够用了，但如果要谈 Binder 的内部原理如调用效率、数据传输限制，或者 Binder 的其他用法如 pingBinder，再或者写一个自己的 ServiceManager，Binder 的深度原理就值得探究了，本系列从数据传输出发，逐步解开 Binder 的原理。

Parcel 在 Android 中扮演着跨进程传输的集装箱的角色，是数据序列化的一种手段，平时工程中获取的 Binder 对象接口就是靠它来跨进程传输的，本文来看 Parcel 对象的数据传输原理。

更多>>

《Android 中的自启行为浅析#Broadcast（一）》中的 1、2 节讨论了广播发送与接收流程，我们接着来说一些系统广播和优先级接收的问题。

更多>>

在 Android 越来越普及的当下，Android 手机在用户心里最尖锐的问题总结起来就是两个关键词：卡慢、费电，恰好本文系列讲述跟这两项都有关系，Android 的普通应用程序的自启动行为直接导致了内存紧张、CPU占用以至于手机 UI 卡慢、耗电快。这里我们说的 “自启动” 这个字眼实际上指的是：用户未有主动启动目标应用程序，目标应用程序进程却被启动的行为，说是自启动，其实是有其他进程把应用程序给带起来了。

本文将从 Broadcast 的角度来分析第三方应用是如何通过广播来自启的。

更多>>