Skip to content

Commit 86e420d

Browse files
Merge remote-tracking branch 'origin/master'
2 parents b26c114 + 9488ff7 commit 86e420d

File tree

1 file changed

+7
-6
lines changed

1 file changed

+7
-6
lines changed

docs/zh/q&a.md

Lines changed: 7 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,14 @@
11
# Q&A
22

3-
## 为什么不写成两个库
3+
## 为什么不分成标题栏库和缺省页库
44

5-
个人思考了非常久后才决定写成一个库,有以下考虑:
5+
个人深思熟虑了非常久才决定写成一个库,有以下考虑:
66

7-
1. 大多数情况下标题栏和缺省页关联性很强,因为缺省页往往是要在标题栏下方显示,如果每次都要使用两个库就比较麻烦。
8-
2. 支持给内容和缺省页添加头部,算是个附加功能,感觉没什么不妥。
9-
3. 即使写在一起,核心类不算上注释也才 200 行左右的代码,还要啥自行车?View 的缓存管理代码占了一部分,如果拆成两个库就需要各自去实现,代码加起来至少 300 行。
7+
- 支持给内容和缺省页添加头部,所以具有管理标题栏的应用场景,感觉没什么不妥。
8+
- 大多数情况下标题栏和缺省页关联性很强,因为缺省页往往是要在标题栏下方显示,如果分成两个库就经常需要调用两个工具类,使用起来更加麻烦。
9+
- 分成两个库可能会多一层无意义的布局嵌套。
10+
- 即使写在一起,核心功能的实现类才 200 多行代码,还要啥自行车。由于适配器和 View 的缓存代码能复用,在解耦缺省页后,仅加多几十行代码就能把标题栏给一起解耦了,何乐而不为。
1011

1112
## 可以在布局上预览标题栏吗?
1213

13-
不能,这可能是本库唯一的缺点,但是本库解耦标题栏的收益远大于在布局上预览标题栏的收益。
14+
不能,这可能是本库唯一的缺点,但是本库解耦标题栏的收益远大于在布局上预览标题栏的收益。

0 commit comments

Comments
 (0)