@citian3094
2016-09-26T08:13:03.000000Z
字数 4143
阅读 1229
（扩展：可以结合谈谈智能生活中app的存在形式）
答：
手机上的App应该是现在的智能生活解决方案的一个重要部分。App把手机变成了一个高级的遥控器，除了替代传统遥控器的开关功能，App借助手机或者平板电脑的特性，在信息展示、设定和触达方面有天然的优势，确保了整体方案的用户体验。
在技术架构要求上，App在的产品功能设定上其实更纯粹，作为端的一部分，配合云端和设备端来完成整个链路的闭环。
大厂商的智能设备App在架构需要额外考虑的是作为“航母”接入外部三方功能的一系列架构挑战。 譬如我们当时做的app，为了方便厂商或者独立ISV进行自行开发和接入，以便于他们来参与部分的定制工作，我们因此必须提供一套完善的插件框架，结合Hybrid的展现技术，暴露出Jscript的访问控制API。整个App有点像小型的应用商店，因此必须解决一整套的开发，测试，安全检测，沙盒控制，功能上下架等功能。这又是前端后端的一整套方案，只看App应用就显得不够完整了。
至于对技术知识的要求，如果有良好的接口设计和模型定义，那么云端设备端和应用端的三端开发人员是可以不用知晓对方太多的底层细节知识的。当然有少部分人必须要同时具备三端的经验，否则设计整个系统的时候就有很大的问题。
我个人而言，一直比较运气。在工作一开始就从事服务端开发，做了一些企业应用和框架中间件产品；07年以后第一次接触iPhone应用开发，到最近几年都有机会参与一些重要的App开发工作；而电子电路则是自己从初中开始的兴趣爱好，多年来一直在学习提高，从原理上来看这些不同知识背后道理其实都是相通的。
答：作为早期的iOS原生应用开发者，还是有过一段傲娇的时期的。早期没有应用商店和开发文档，都是靠一个修改过的class-dump工具和苹果Cocoa桌面版的API文档来进行摸索开发。有必要的话，还会去逆向iOS自带的应用来了解API的调用方式。这导致了那时候App开发有相当的门槛，因此有一定的技术自豪感。那时候早期的开发者都混一个叫做什么锋的论坛：）还有一个内部的QQ群。而且我还清楚的记得，那时候Holly发布说可以有一个原生键盘的中文输入法放出来，很多人纷纷回帖说是骗子。
而自从iOS 2.0开始苹果逐步开放SDK以后，这些技术门槛就逐步消除了，同时应用商店的审核对于第一批的“自由”开发者来说，存在不小的限制，因为很多私有API你看得到，但是不能使用了。因此兴趣更多的转移到App的产品设计上了。
（扩展：这个趋势而言第三方独立开发者是否没有机会了？ 您认为App最终会消失吗？）
答：我对这个问题的理解，可能换一种说法更贴切：某些app逐步沉淀成为大而全的航母应用，而独立开发者做的app因为这些平台的存在而做的更加轻巧，功能更加单一。 这可能是超出了苹果和谷歌的意料之外的一种现象。这也是为什么大厂商要推动自己的混合应用框架，挟诸多开发者以令OS？我个人还是认为手机App的初心还是在原生应用，但是我们必须混合多种开发技能，毕竟需求和应用场景各不相同。另外，我是不是说了太多了？
答：我能观察到的就是前端技术的渗入，原来只能应用到浏览器上的技术，现在纷纷出现在原生应用的开发阵营。另外一个就是后端一些模式和概念（或其变形）渗入到应用前端开发过程中。这种前端后端技术的互相渗透，一定程度上模糊了客户端和后端的逻辑边界。我们还可以看到一些原本出现在服务端的API调用编排及数据格式转换等技术（参见淘宝的TQL及FB家的GraphQL），都纷纷出现在手机应用开发上。而移动化浪潮也是直接促进了通讯协议的升级，譬如千年不变的HTTP 1.1到2.0升级,这些在我看来都是很好的证据，说明前后端是互相交织促进，滚动发展的。
另外，随着终端和网络能力的提升，系统和中间件的成熟，移动架构设计走向了容器化、模块化、动态化。
近几年客户端、服务端表现出几个趋势：
a). 基础中间件走向成熟：网络加速、IM、Push、图片、数据统计、分享、社区、Crash分析、安全加固等云端结合的基础服务提供方逐步集中到几个有实力社区或企业中。
b). App云端一体化：诸如FireBase、LeanCloud、AWS Mobile Hub的MBaaS架构极大的提升了端直接操纵云的能力，服务端和客户端的角色也发生了调整，服务端专注于提供稳定、可靠的基础服务以及基础服务端组合编排的能力，客户端更灵活的编排这些服务实现功能。
c). 动态化：除H5外，ReactNative和WeeX的出现也提供了另一种动态化方式，客户端提供渲染引擎，服务端提供页面下发、更新、个性化的能力。
d). 个性化(智能化)：客户端采集更丰富的数据，服务端依托大数据和算法提供更加个性和智能的服务。
答：网络通道的优化涉及了云、管、端。除满足性能外还需考虑体验、安全和容灾的要求。
从客户端体验视角出发，移动端网络优化最有效的就是减少网络请求，客户端本地缓存(图片)、使用Push机制替换Pull获取数据(收藏夹、购物车)都是经典且有效的方法。
对于必不可少的网络请求我们希望每个请求都尽可能快的响应，典型的网络请求包括：DNS、TCP连接、安全通道建立、Request发送、Response接收，其中的每个阶段都有值得优化的空间：
a). 使用自建的HttpDNS服务替换运营商DNS服务，DNS异步化且结果客户端缓存，IP直连服务端的方式。不仅可以把请求中DNS等待耗时降为0，而且可以做到更加智能的调度，实现IDC按用户单元化部署、客户端就近就快接入、容灾快速切换。
b). 使用双工、多路复用的TCP长连接通讯协议(如SPDY、HTTP2)，不需要每次请求都建立TCP连接的同时，也对Request、Response的头和内容进行压缩。
c). 服务端TCP协议栈参数调优，优化慢启动和拥塞避免
d). 安全通道选用内置证书和能够0、1-RTT完成握手的算法(参考TLS 1.3)，保障安全的同时能够极大的降低TLS握手时间
e). 选用protobuf等二进制协议减小传输数据大小，使用ETag和304减少不必要的Response传输
基本上就这几个方面了，我们得针对各自场景，有选择性的进行调优。
（另外面对系统、设备的碎片化时您是如何应对的？）
答：设备碎片化颇令人头疼，尤其是安卓设备的碎片化。我能想到的主要还是通过iOS和安卓端统一架构，统一UI，使用统一且成熟的基础中间件，尝试ReactNative、WeeX等混合跨端方案来降低适配难度。底层基础组件可以使用C/C++编写，非核心业务内容使用H5编写做到多端复用。同时在界面设计上尽可能避免不同设备的兼容问题；根据应用安装的分布情况，对产品设备的支持程度进行取舍来解决这类问题。
（扩展：目前在服务治理有哪些新的痛点？）
答：首先，我觉得这是个不容易得出直接结论的问题，且很容易引起争论。
其次，我认为：架构腐化是不可避免的，而规模变大可能会让架构腐败变得更快而已。在没有服务治理概念的年代，依然可以找到设计良好的系统，而现在有了服务治理框架和工具，系统依然可能会腐化得很快。两者的关系就好比人的寿命长短和锻炼方式程度一样，其实并没有直接的联系。
记得我最初几年在做Dubbo的时候，参与过几个项目的服务化改造。当时的工作是通过梳理一个巨无霸应用的功能和范围边界，确定出一些核心的领域模型概念，基于这些概念，划分成子系统剥离出业务接口，然后利用Dubbo等RPC框架部署成独立的服务集群。因此这个阶段的服务治理，主要就是抽丝剥茧的分离大系统。
到了中后期，服务化被广泛使用后，我们就遇到了接口泛滥、版本控制、循环依赖等各种新的问题。
到了全民无线的时期，对服务化的新要求则是如何针对移动应用领域的的优化和支持了。
后来我在带领团队做一些重要的移动App的时候，因为多变的需求冲击，产品功能设计也不够充分，加上团队也比较嫩稚，所以那时候App的架构腐化得更快。到后来基本只能在原来代码上面堆砌功能，因为推倒重来的代价太大，因此非常痛苦。
结合我在两端开发不堪回首的经历，我认为：借助工具框架的力量，妥善做好应用功能分析分解，确保服务之间（或者应用内部功能模块之间）的模块化隔离解耦，也许能延缓一下架构腐化的速度。另外，团队的能力可能比这些方法论更重要哦。
（扩展：您倾向于高风险高回报还是保守稳妥发展？）
答：如果是小型团队，要快速的打造一个应用，我觉得怎么快怎么来就好。如果是中大型团队，并且要维持一个稳定的产品，那么还是要选择已经被证明的的技术方案。如果团队能力允许的话，尽可能对使用的新技术有一个充分的评估和了解，免费的东西最贵，开源的框架技术拿到手上，最好还是能多看一眼再用。
就个人偏好而言，我是偏保守的。举例来说：我现在的主力笔记本还在用Yosemite，等大家切换到了Sierra以后，我会开始升级到 El Capitan。另外一台测试机则利用开发者账号，第一时间升级最新的OS测试版本来体验把玩。