《App研发录》读书笔记

最新推荐文章于 2022-05-05 17:15:56 发布

天盟

最新推荐文章于 2022-05-05 17:15:56 发布

阅读量1.1k

点赞数

分类专栏：读书笔记

本文链接：https://blog.csdn.net/masonblog/article/details/51324892

版权

读书笔记专栏收录该内容

1 篇文章 0 订阅

订阅专栏

这本书基本上涵盖了移动开发中常见的关注点，之所以用关注点而不用技术点这个词是因为这本书并没有讲到具体的技术实现，但提供了行之有效的解决方案。读这本书的时候非常有感触，它很多的框架设计和解决方案与我实际开发中都是不谋而合的（有点自夸的意思哈）。所以也非常感谢作者能这么详细的记录下来。这篇读书笔记是记录我在阅读过程中感觉需要重点强调的地方和自己的一些理解，也供大家能快速的浏览本书的章节。

关于重构

对于新项目，一开始就要把它设计好，因为产品留给我们的重构机会不多
对于老项目：

1、如果不重构带来的开发难度或者引发的bug 很严重，那么必须要跟产品商量了。

2、重构的代码一定的在本期迭代上线后，再合并到下期代码里。

3、重构计划要详细要拆分到几次迭代里，分期上线。
AndroidLib

搭建一套AndroidLib，或者叫Common，它里边封装了所有于业务无关的逻辑。这样做为后期的Android模块化和 Android插件化开发打下基础。（模块化开发和插件化开发是两个不同的概念）

这里有人可能会问把所有的与业务无关的逻辑封装在一起会不会耦合性太高？其实封装和解耦本来就是一对矛盾的概念，需要我们自己合理的把握设计，我们这里讲的AndroidLib只是为一个特定的App做框架支持，所以不存在耦合性，假如有多个App需要，则必须把AndroidLib拆分成更小的Lib以适应灵活的场景。
重构后的项目结构

在拆分package（iOS里Group）原则上，建议按照bu（业务单元）来分，而不是按照Class来分。因为一个App的bu是不断变化，不断增加的，而Class的类型随着API变化不会变化太大，例如Android上常用就是Activity、Fragment、Adapter等等。

网络底层的优化

我们需要做一个BaseCallback来做统一的onStart、onFinish、onFail、Cookie过期的处理，例如在onStart里进行showDialog、在onFinish里隐藏Dialog，在Cookie过期后调整登录页。这个地方是一个有争议的设计，因为网络请求的Callback从分层设计上应该属于Modle，不应该跟UI耦合在一起。在我个人而言更喜欢把BaseCallback看做一个Component，而不是单纯的一层Model，这样更好理解。

HTTP头的利用

我们在MobileAPI 设计的时候，一开始就要把当前App的信息通过Http Header告诉服务器，以便服务端调度Api。一般的做法是把App的package、platform、version等等放在UserAgent里告诉服务端。
对于手机系统时间不准的问题，该书也有提到，每次调用服务器api时，服务器api都在reponse header里返回服务器的时间，然后跟手机系统时间做时间差，然后每次本地获取时间就加上这个时间差。

App图片缓存设计

该书介绍了Fresco的三层缓存技术

1、Bitmap缓存，在Android5.0及以上Bitmap直接缓存于dalvik vm heap中，而在4.x 及以下bitmap缓存在 native heap （ashmem）中，因为dvm对heap大小是有限制的，如果超过这个限制就是OOM

2、内存缓存：内存缓存存储了图片的原始压缩格式，从内存缓存取出图片后需要先解码才能显示。这个地方会经常提到的Lru 和 SoftReference，SoftReference在2.3以后不再推荐了，因为垃圾回收机制做了修改。

3、磁盘缓存

网络流量的优化

API返回数据要使用gzip压缩，大于1kb才有必要进行压缩否则得不偿失
推荐使用ProtoBuffer，这种协议是二进制格式的，占空间更小。
减少API调用，一个页面尽量只发一个请求获取所需要的数据。
http1.x 是不支持多路复用，为了提升访问速度可以做TCP长连接或者使用http2.0，当然维护一套TCP长连代价也是不小的。
建立取消网络请求的机制，这个最新的retrofit2.0 原生支持推荐使用。
合理的重试机制
大数据列表的增量更新机制，当遇到一个很大的列表数据有改动时，最好使用增量更新机制来减少传输的数据量。

图片策略优化

做一套ImageServer，App请求图片url时会带上它需要的width、height、图片质量，然后由ImageServer对原始图片做压缩处理。目前有很多厂商提供这种服务，比如七牛。
App是不是需要把每个ImageView的width、height获取到呢，按照我的经验只需要给App定义大、中、小三套width、height基本就够用了。
在弱网情况下再定义一套图片质量（quality）的值，就会减少弱网下的流量。

App与H5的交互

定义一套App 和H5 之间跳转协议，可以通过JS 或者 OverrideUrl来实现。这个跳转协议里可以定义简单的数据类型，String不需要指定，对于int、double需要在值钱记上类似（int）这个的标记，这样App才能正常解析。

常见错误

JSONObject 和 JSONArray是不支持序列化的，所以最好是转换成相应的可序列化的Model再使用。

代码规范

在xml的文件名命名时最好加入module（或者叫bu）的名字，例如account_adduser_activity.xml
空格、tab、换行这些格式建议一个团队里统一规范，建议使用工具自动检查：AndroidCodeQuality
将代码里的常量抽取到string.xml中：这个也可以使用工具自动检查：AndroidLintPlus

安装包大小

png 和 jpg 的区别和使用场景

同样尺寸的图片，png要比jpg大很多，因为png是有透明通道、无损压缩的。但系统会对png进行硬件加速，所以同一张图，png体积大但加载速度却比jpg快。
从网络加载的图片考虑到流量和下载速度优先使用jpg，对于引导图，也倾向于使用jpg，减少包体积。对于iOS启动图必须是png，否则审核会被拒。

Google发布了压缩率更高的WebP,不过iOS想要支持这种格式需要单独引入WebP解码器。
单色的icon可以转换成字体文件，因为字体是矢量图拉伸不会失真，并且体积会很小。