Android系统发展至今已经比较成熟，从每年的Google I/O 大会也可以看出，Google I/O大会的主题，从原来的Mobile First到AI First转变，实际上近两年Android系统也没有什么重大更新，除了加入AI元素，更多的还是系统性能提升，以及一些细节优化。随着Android的成熟，Google也开始注重开发效率的提升，从Kotlin的推出到官方出品的各种组件库，以及最近的App Bundle可见一斑。

移动端App经过几年的发展，功能已经相对丰富和稳定，然而随之而来的是代码的臃肿，耦合，常常牵一发而动全身，严重影响开发效率以及项目的稳定。于是模块化这种古老的思想开始在移动端应用，分而治之，每个模块单独开发维护，模块间通过相对简单的方式进行通信，从而降低整个App的耦合度，复杂度，提高效率和稳定性。然而不幸的是，Android目前并没有官方支持的模块化开发方式(App Bundle刚出，限制也比较多)，各路Android大神各显神通，网上相关文章非常多，单其中一个问题的解决就可以找到几个库。JOOX目前正在对项目进行重构，对业界组件化相关的解决方案做了一下总结。

花了一天时间终于把博客从jekyll迁到hexo了。

一眨眼两年没没写过博客，实在是太懒了，年纪大了，记性越来越差了，以后还是要多写博客。

嗯，就这样。

Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub.

Quick Start

Create a new post

1

$ hexo new "My New Post"

More info: Writing

Run server

1

$ hexo server

More info: Server

Generate static files

1

$ hexo generate

More info: Generating

Deploy to remote sites

1

$ hexo deploy

More info: Deployment

最近在公司写了一篇总结，没有涉及什么内部数据，直接转到这里吧。如果需要转载，麻烦联系我。

  智能手机发展到今天已经有十几个年头，手机的软硬件都已经发生了翻天覆地的变化，特别是Android阵营，从一开始的一两百M到今天动辄4G，6G内存。然而大部分的开发者观看下自己的异常上报系统，还是会发现各种内存问题仍然层出不穷，各种OOM为crash率贡献不少。Android开发发展到今天也是已经比较成熟，各种新框架，新技术也是层出不穷，而内存优化一直都是Android开发过程一个不可避免的话题。 恰好最近做了内存优化相关的工作，这里也对Android内存优化相关的知识做下总结。

Android卡顿检测方案目前有两种：

1，基于Looper的检测方案。
2，基于Choreographer的帧率检测方案

分别简单介绍下这两种方案的基本实现原理。

部分内容来自网络。

1，建表优化

拆分数据表，可以通过外键等方式尽量减少数据条目。

2，建立索引

关于数据库索引的原理为什么建立索引可以加快查询速度请看 http://kb.cnblogs.com/page/45712/

建立索引的语句

1

CREATE INDEX index_name ON table_name;

创建单例索引

1

CREATE INDEX index_name ON table_name (column_name);

索引会额外增加空间，另外对插入，更新，删除等操作因为需要更新索引，所以反而导致性能问题。

Andorid LeakCanary内存泄露分析

LeakCanary是Square出的一个直接在移动端可视化查看分析内存泄露的库。