技术会过时,但是思想永远不会过时。
本书面广却不深,适合快读。书中基本都是作者自己工作中遇到的问题和坑,从实践而来,避免了空谈。
但是有些地方比如:Carsh异常分析这章,仅仅提供解决方案,缺少问题解决背后的思维过程:遇到什么问题?怎样分析,推理?最后如何发现解决方案?我觉得异常分析的思路和步骤远比罗列大篇幅的异常要更为重要。
如何打造一个高质量的 APP?
技术会过时,但是思想不会过时。打造一个高质量的 APP,是个永恒的主题,大致手段都是从以下几方面展开:
项目结构规划合理,按模块拆分;
模板方法模式拆分庞大的方法。比如 BaseActivity 定义操作的顺序和骨架,子类负责具体实现。实际上 Android 的生命周期函数,也是模板方法的重要体现, ActivityThread 的 main 函数被调用之后,依次执行 Activity 的 onCreate、onStart、onResume 函数,用户可以在 Activity 子类中复写这些生命周期方法做自定义操作;
页面跳转携带的数据一定要做好判空处理;
说到底就是一句话,服务端永远都不要信任客户端传递的数据,一定要做好校验。客户端永远都不要信任服务端给的数据,一定要做好容错处理;
网络请求这块,需要做好错误和 Token 过期的统一拦截处理,且需要预留重试机制;
-
支持线程集中管理,当页面退出,未完成的线程包括网络请求可以统一取消。这点可以参考 Glide 的巧妙实现原理,通过添加不可见的 Fragment 监听Activity的生命周期,从而实现当退出页面时未完成的图片请求统一取消。
实际上不可见的Fragment这个特性可以做很多有趣的事情,比如你可以让不可见的 Fragment 为 Activity 提供后台服务。或者可以使用这个特性让它包含改变其它 Fragment 的逻辑,而不是把这个逻辑放在 Activity 中。甚至 ActionBar 都可以交给这个没有 UI 界面的 Fragment 来专门管理;
用户登陆状态判断需要做统一拦截,对于需要登陆后自动执行未登陆前的操作,可以参考这篇 目标方法前置检验模型设计与实现。
更好的实现和补充
NativeCrash
本书中只介绍了 Java Crash 收集,bugly 平台还有 Native Crash 收集,异常发生时,CPU 通过异常中断的方式,触发异常处理流程。Linux 把这些中断处理,统一为信号量,可以注册信号量向量进行处理。具体做法是:注册监听信号处理,并开辟一块单独的栈控件单独处理崩溃信号,避免捕获不到栈溢出异常。
页面分发器
我不赞同采用文中这种方式实现页面分发器 —— iOS 和 Android 的对应映射直接写在 HTML 代码里。
其实H5并不需要关心原生层的系统,单单关注需要跳转的页面 pageCode 即可。更好的方式是通过服务端来实现集中配置管理映射关系,统一下发给客户端配置表。每个页面对应一个pageCode 作为key。
而且设计Hybrid交互模型时,最好是以接口为单位进行设计的,方式约定为API式交互更为简洁统一。我们来改造一下文中的例子:
//跳转h5页
<a onclick="https://XXXX.com/movieDetail.html?movieId=123"></a>
//和Native交互
<a onclick="native://movieDetail?movieId=123">
Native HTML 互换技术也是可以通过更新路由配置文件来做到。
所以说源码是最好的老师,本书里面很多经典场景设计和架构,在现在公司的项目里已经完全体现而且还设计得更优雅。
借鉴的思路
书中很多思路,是值得借鉴的,
- 比如资讯类 App,有数据缓存的需求,缓存数据需要考虑下是否有敏感数据?是否需要加密?既然缓存了,就需要预留强制更新的触发点。
- 流量优化方面,可以使用更好的数据传递协议。例如 ProtoBuffer。
- 减少包体积大小可以采用增量更新、ttf 图片、webp、Proguard 移除无用类和方法。
- 完整的广告引导链可以参考社区类和视频类 App,用户体验和活动运营我们可以参考电商类 App,高并发的架构设计可以调研社交类 App,推送服务的及时性和到达率我们可以向新闻类 App 学习。
最后我想谈谈项目管理和团队建设。
项管最重要的作用,就是同步。每天不厌其烦地和测试、开发、产品了解进度,把控风险点,同步到整个项目组。项管一定要对人员松管理,项目强管理。
团队建设方面,Code Review 和技术分享都是提高团队战斗力的手段。
Code Review 的好处我觉得不用多说了,但实际推行起来,有下面几个情况会让 Code Review 失去效果。
首当其冲的是 —— 团队成员能力不足,我经历过这样的情况,Code Review的过程中,大家大眼瞪小眼,没有什么好的想法,不知道什么是好的代码,什么是不好的代码。导致Code Review大多数都在代码风格上。对此,是时候让团队的人花时候阅读一下《代码大全》、《重构与模式》、《代码整洁之道》这些基础书籍了。
其次的原因是 —— 成员的态度问题,一方面就是懒,不想精益求精,只要干完活交差了事。对此,你更要大力开展Code Review了,让这种人写出来的代码曝光在更多人面前,让他为质量不好的代码蒙羞。另一方面,有人会觉得那是别人的模块,我不懂,也没时间去懂,不懂他的业务怎么做 Code Review ? 我只想说,如果你的团队里这样的自扫门前雪的事越多,那么这个团队也就越没主动性,没有主动性也就越不可能是个好团队,做的东西也不可能好。而对于个人来说,也就越不可能有成长。 Code Review实际上是一种沟通方式,你可以了解成员的代码水平、代码风格和思维方式,能让团队成员不光关注自己,也了解别人做了哪些代码改动。
技术分享同样容易面临成员态度问题的挑战,部分成员觉得分享已然成为一种负担,根本原因还是没有输入,无法输出,习惯用惯性思维不加思考地去做业务。
建议先培养出团队持续交流,持续输入的氛围,再端正成员的态度。教是最好的学,技术分享是在彼此表达的过程中去强化自己的记忆和理解,双赢的事情。为了让不明白的听众做到明白自己的分享内容,分享者必须要知道从明白到不明白究竟需要掌握哪些概念,这就迫使分享者对整个知识体系来个寻根究底,把自己知道的潜在概念或假设,自己不知道的潜意识,统统都挖出来。正是成员没有意识到做一场分享对自己 “串” 起知识关联的作用,才如此抗拒甚至逃避分享。