笔记 - Android应用架构 (Android Dev Summit 2015)

尽快行动

• 早期的设计抉择对app的影响很大
• 基本架构会让你思考需要解决的问题变得更容易或困难。

哪种模式？

• MVC
• MVP
• Reactive
• Cairngorm
• Flux
• fdsafdsa
• MVVM
• CLEAN

这不是一个库的调查

• 很多很棒的libraries展示了思考app的不同方式
• 趋势迅速改变，但一些挑战是永恒的
• 久而久之 “熔岩流” 发生了

Lava Flow 熔岩流：解释一下，大致就是说一些因为种种状况写得不太好的代码，恩，比如产品/PM/某些开发老大等呵呵呵催进度的时候，被加入到实际生产环境，而其实际仍处于开发中的阶段，导致后期需要维护原先未完成状态的设计的兼容性，比如各种API/命名等。而在这种team里面，随着熔岩流的不断发生，人员的进进出出变动，系统内部各种设计的目的丢失，导致之后的工程师不仅不敢清理这些代码，反而只能继续增加它们的复杂性，把系统弄得越来越混乱。

如果你有一定工作经验，相信对这种状况一定不会陌生。:-D

为了用户体验（UX）的架构

用户不会关心你系统的架构，他们只在意用户体验。

接着我们看到了一个IM app的例子，用户发送了一个消息，然后就看到菊花转啊转，用户并不知道发生了什么。

非持久化的提示

见下图，view发送命令给view controller，然后controller请求网络，并等待网络response再更新view。

这样就会让用户觉得体验很差劲，如果我们试着再增加一个Model层（存储），如下图，当用户点击后，view controller并不会直接发送请求，而是先更改Model层状态，Model会先把更新后的状态回调给View Controller，更新View的UI，然后才去发送网络请求，并等待response，然后再次更新UI（其实这里的Model就是Repository层了，对上面屏蔽了数据来源，UGC/FEED流的app中这种体验很重要）。

这种设计下，我们就很容易可以造一种假feed（比如真实的是黑色，假的是灰色），等到网络response回来了，再变成真feed（黑色）。

这就是 非持久化的提示 。

缓存

第二个例子，当我们从详情页退出回到列表页，然后再次点击列表项进入刚才的详情页，数据竟然不见了。2秒前我还在这里，为什么当我再次回来的时候数据就没了呢。

因为数据不是持久化的！它只是一个短暂的存储，数据来源是网络。

于是我们就得到了上图这样的设计，这样一来我们一进页面就能看到数据，因为数据来自本地，Application Logic会在收到View Controller请求的时候同时请求Persistent Model和Network。

非持久化提示队列

再来个神奇的场景，见下图，当用户输入一条信息后，UI展示了假数据，但当他继续输入后，却没有更新新的假数据到界面，这其中发生了什么呢？

因为我们的架构是基于命令的！见下面的后台处理示意图：

当我们处理请求的时候，我们同时只能做2件事（想象一个一个max为2的线程池），当我们在一个线程抓取bitmap，另一个线程发送数据到服务器的时候，我们无法处理第三个命令（比如从磁盘读取评论）。这是一种很糟糕的情况，调度的优先级有问题，但设计者很难料到这种情况的发生，因为并不知道每一个命令要花多久，你并不能总是估算出来。

但我们可以分开这些东西。

见上图，我们把队列分为网络和本地队列，这样就不会出现刚才的情形了。就算网络出了问题，用户还是能看到本地的假反馈。

Activity状态机

小结

1. 为了离线设计（为了更好的UX不能责怪网络）

• UI是基于model的
• App Logic负责同步model和服务器
• 这两者不互相依赖（在必要的时候使用events和callbacks通知状态改变）

Application Logic - 应用逻辑

1. 解耦

• 如果有用的话，使用依赖注入（use it if it helps)
• 了解副作用（这不是那么容易的事，尤其是当你在只在自己桌上测试的时候，当你坐在那儿的时候一切都是在最佳状态）
• 为了更好的性能，避免反射（笔者看过一些项目在命令中心大肆使用反射，这真的很让我无语）

很多依赖注入框架有一个很重的运行期组件或者编译期组件。

比如Dagger2在编译期做这些事，从而达到更好的性能。所以要仔细看看这些库，权衡它们的优劣。

网络

1. API设计

• 为了你的用户设计后台（想到了一些后台API为了自己内部的解耦让app一个页面请求十几个接口）
• 在服务器尽量处理更多
• 传递metadata给客户端

比如有一张很大很大的图片：

{    "user":{   "name": "MarkZhai",   "photoUrl": "https://blog.zhaiyifan.cn/..."   }  }

{    "user":{   "name": "MarkZhai",   "photoUrl": {   "width" : 300,   "height" : 500,   "url" : "https://blog.zhaiyifan.cn/...",   "palette" : {}   }   }  }