技术会过时，但是思想永远不会过时。
本书面广却不深，适合快读。书中基本都是作者自己工作中遇到的问题和坑，从实践而来，避免了空谈。
但是有些地方比如：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 和 Androod 的对应映射直接写在 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实际上是一种沟通方式，你可以了解成员的代码水平、代码风格和思维方式，能让团队成员不光关注自己，也了解别人做了哪些代码改动。
技术分享同样容易面临成员态度问题的挑战，部分成员觉得分享已然成为一种负担，根本原因还是没有输入，无法输出，习惯用惯性思维不加思考地去做业务。
建议先培养出团队持续交流，持续输入的氛围，再端正成员的态度。教是最好的学，技术分享是在彼此表达的过程中去强化自己的记忆和理解，双赢的事情。为了让不明白的听众做到明白自己的分享内容，分享者必须要知道从明白到不明白究竟需要掌握哪些概念，这就迫使分享者对整个知识体系来个寻根究底，把自己知道的潜在概念或假设，自己不知道的潜意识，统统都挖出来。正是成员没有意识到做一场分享对自己 “串” 起知识关联的作用，才如此抗拒甚至逃避分享。
网友评论