在Android发展的进程中，网格布局一直比较有热度，其中一个原因是对用户来说便捷操作，对app厂商而言也会带来很多的曝光量，对于很多头部app，展示网格菜单几乎是必选项。实现网格的方式有很多种，比如GridView、GridLayout，TableLayout等，实际上，由于RecyclerView的灵活性和可扩展性很高，这些View基本没必要去学了，为什么这样说呢？主要原因是基于RecyclerView可以实现很多布局效果，传统的很多Layout都可以通过RecyclerView去实现，比如ViewPager、SlideTabLayout、DrawerLayout、ListView等，甚至连九宫格解锁效果也可以实现。
SOLID 指导我们如何写出高质量代码，而组件设计原则（Component Priciples）指导我们如何合理地组织代码，实现代码目录的高内聚和低耦合。 组件（Component）这个词现在用得比较泛滥，组件设计原则的“组件”的定义来自《 Clean Architecture》，代表是一组业务相关的文件集合，在 Android 工程中，一个组件可以等价理解为一个模块（ Gradle Module）。所以本文讨论的就是如何更好的组织这些模块，让 Android 工程架构的模块化更合理
Android 最新的架构规范中，引入了 Domain Layer（常被译为领域层 or 网域层），建议大家使用 UseCase 来封装一些复杂的业务逻辑。 传统的 MVVM 架构中，我们习惯用 ViewModel 来承载业务逻辑，随着业务规模的扩大，ViewModel 变得越来越肥大，职责不清。
在Android领域，Binder作为进程间通信的核心机制，是每位Android技术人员都应该深入了解的重要知识点。本文将从面试官的角度出发，围绕Android Binder展开一系列高级疑难问题。通过问题分析与问题简答，旨在帮助大家更好的理解Binder，并在面试中游刃有余。
自2017年Google发布Kotlin语言之后，Android开发由原来的Java开始向Kotlin 过度，目前绝大部分Android开发岗位基本要求就是熟练使用Kotlin。事实上，很多有着多年历史的项目一开始是Java开发的，在Kotlin日渐趋于Android开发主流的过程中，混合开发成为许多项目的首选。我们的项目也是采用混合开发，面对拥有沉重历史包袱的代码，想用Kotlin重构却不得不考虑时间成本和人力成本，但又不想放弃Kotlin开发的优势，所以新业务均采用Kotlin开发。 Json就不过多介绍了，大家耳熟能详，相信很多伙伴项目中的Json解析依旧在使用FastJson或者Gson等第三方框架进行数据解析，当我们混合开发之后，你会发现Kotlin的数据类写起来很方便，但是将Json解析为数据类对象时出现的问题会让你很头大，尤其是开启混淆之后，各种各样的问题甚至程序崩溃随之出现，随着程序的崩溃，你的内心渐渐开始崩溃，不禁发出疑问，数据类不好用吗？
