基于MVP原则，即最简可实行产品，希望通过最简洁的知识点，帮助Android开发初学者高效和快速的入门。

写了几年代码，发现写代码的能力好像越来越不是那么重要，技术人员追求的技术深度，也有流程或专门的团队攻克，业务开发新的方向是什么？

前言 现在，早上10点半，来到新公司的快三个月了，谈不上适应与否。正要打开 Studio 开始梳理新需求应该如何编排,就莫名的想停下来一会，写点东西，写点有关业务，但又不仅仅是业务的事情。 最近来到新

Android 业务逻辑应该如何写（第一篇） Android 业务逻辑应该如何写（第二篇）（本文） View的组织形式 先抛出一个问题，如下图为抖音的推荐流, 如果你是抖音的开发者，你将如何编写该页面

不仅只在面试中，在实际工作中，相信大多数的Android程序员也都在迷失在浩瀚的业务中，在一次次和产品的battle以及需求的deadline中丧失了对一个好的业务架构的思考，什么扩展性、通用性、解耦

面对三端并行开发带来的巨大复杂度，我们并不急于“全栈统一”，而是更关注架构的合理性与团队协作的可持续性。

各位 Android 开发者, 让我们坦率地说, 你们有多少次因为管理导航而抓狂? 这简直是一场噩梦, 对吧? 我们都曾编写自定义代码来适应我们的使用场景. 从现在起, 我们有了一个新的解决方案, 叫