以下内容学习、摘录自《技术管理之巅》
8.1 移动产品开发那些事
8.1.1 移动开发团队的组织架构
对于初创型移动开发团队（人数少于30人），只要配齐产品设计、架构设计、用户体验设计、技术开发、移动开发、测试、运维等角色，进行简单分工就可以了。
到了中等规模的开发团队（人数超过30人），移动开发就要设置独立的机构，跟技术开发团队是平行关系。移动开发团队分成iOS、Android两个技术小组。这样的好处是，移动开发资源比较集中，有利于高效利用。这种设置符合该阶段的特点，即：移动业务整体占比不高、开发需求量不大，用户对移动体验要求不高。
随着移动业务的普及发展，比如在整体业务中的占比超过30%的时候，上面的组织架构就面临挑战了。因为业务需求越来越多，用户对移动应用体验要求越来越高，独立的移动开发团队在人手和对业务的熟悉度上都是受到限制的。所以，应该把移动开发团队拆散到技术开发团队中去，每个开发小组直接负责各自业务的移动化。但要保留一个小型精干的“移动架构”团队，它不参与具体业务应用的开发，而是负责更加抽象的移动技术框架的设计和维护工作。
8.1.2 移动应用的技术架构
移动互联官网的一个特点是“多屏”，即终端设备除了PC的各种浏览器，还有各种厂家各种型号的平板、手机。为此，提出了如下的要求：
1.在软件开发过程中，底层要稳固、健壮、具备高可用性；
2.接口层要丰富、兼容、保持相对稳定；
3.业务逻辑层要兼顾灵活性、可扩展性，以支持灵活多变业务的发展；
4.展示层要能适应各个终端的特点，拥有良好的用户体验。
为支撑以上要求，书中提到了3个需要特别重视的技术框架：
1.SOA架构
SOA（Service-Oriented Architecture，面向服务架构）。SOA可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。SOA将能够帮助软件工程师们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。较之以往，以SOA架构的系统能够更加从容地面对业务的急剧变化。
关于SOA，有很多资料、很多细节，就不赘述了。另外近年来提倡的“微服务”也是可选的技术框架。
2.MVVM框架
MVVM（Model-View-ViewModel，模型-视图-视图模型）。View层专注展示，ViewModel层专注业务，优点是业务逻辑集中、模块结构相对统一、好维护、容易做单元测试。跟传统的MVC模式相比，MVC中的C不可避免把视图逻辑和业务逻辑混杂，导致越来越“胖”、维护成本高、单元测试不好做。
MVVM的诞生
MVC（Model-View-Controller）是这样合理分配工作的：我们需要数据所以有了M，我们需要界面所以有了V，而我们需要找一个地方把M赋值给V来显示，所以有了C。然而我们忽略了一个很重要的操作：数据解析。在MVC出生的年代，手机APP的数据往往都比较简单，没有现在那么复杂，所以那时的数据解析很可能一步就解决了，所以既然有这样一个问题要处理，而面向对象的思想就是用类和对象来解决问题，显然V和M早就被定义死了，它们都不应该处理“解析数据”的问题，理所应当的，“解析数据”这个问题就交给C来完成了。
而现在的手机App功能越来越复杂，数据结构也越来越复杂，所以数据解析也就没那么简单了。如果我们继续按照MVC的设计思路，将数据解析的部分放到了Controller里面，那么Controller就将变得相当臃肿。
还有相当重要的一点：Controller被设计出来并不是处理数据解析的，它的职责是：1、管理自己的生命周期；2、处理Controller之间的跳转；3、实现Controller容器。这里面根本没有“数据解析”这一项，所以显然，数据解析也不应该由Controller来完成。
那么我们的MVC中，M、V、C都不应该处理数据解析，那么由谁来呢？这个问题实际上在面向对象的时候相当好回答：既然目前没有类能够处理这个问题，那么就创建一个新的类出来解决不就好了？所以我们聪明的开发者们就专门为数据解析创建出了一个新的类：ViewModel。这就是MVVM的诞生。
3.跨平台移动开发框架
移动平台的主流操作系统虽然只有iOS、Android两个，但已经使开发资源、开发工作量翻倍了。因为同一份需求几乎都要做两次，以适应两个平台。
所以，选择一款合适的“跨平台移动开发框架”是非常有必要的。书中提到的技术框架是“React Native”，一款Facebook推出的基于JavaScript的开源框架。据了解，近年还有类似的优秀框架出现。跨平台移动开发框架的建设目标是“Learning once， write anywhere.”。
8.1.3 移动应用怎么测试
有别于PC端应用测试的是，移动端应用有着更复杂的客户环境，因为用户的手机型号种类繁多。把移动应用特有的测试要点摘要如下：
1.界面测试
首先，检查界面显示内容。要关注完整性（数据长度自适应）、一致性（同一数据源时，保证一致）、准确性（所有字段都有其明确意义）。
其次，检查提示信息。某些重要信息在输入、修改、删除时应有“确认”提示，同时有“取消”来撤销误操作；无网络时给出友好提示；提示语言易懂、具有指导性；界面切换、加载数据时有动画提示。
再次，检查界面应用性。编辑界面，保证键盘的展开、收起，以及键盘上的字符符合编辑要求；按钮可点击、不可点击状态；用户可点击的触控区域合理性。
最后，检查界面处理。屏幕旋转是否影响界面布局，界面切换和跳转符合交互设计原则。
2.功能测试
首先，检查APP运行正常。在杀进程后重启、前后台切换、锁屏与解锁后、网络中断恢复、有来电或消息推送时、变更时区、变更日期、变更语言环境等情况下均无异常。
其次，检查授权。用到系统定位、相机、通讯录时，有授权提示；用户在不主动退出账户的情况下，支持自动登录。
最后，检查数据操作。根据业务规则和数据交换情况，有些地方实时更新数据、有些可以缓存数据，并支持手动刷新数据；在请求数据期间，允许/禁止用户做某些操作。
3.联合测试
由于客户端、接口和H5之间的依赖关系，应注意以下情况：
> 接口/H5主动上线，与客户端联测。验证已发布的客户端，客户端验证通过后上线；客户端验证不通过时，必须修改接口/H5来保证已发布客户端的质量。
>客户端上线。接口/H5应保证客户端质量，所以接口/H5需要在新版本客户端发布之前上线。
4.兼容测试
兼容性测试开展前，应调研用户的设备型号。兼容性测试除了关注iOS、Android的各种版本外，还应关注屏幕分辨率尺寸。
5.客户端崩溃
常见崩溃场景：客户端未对接口返回的异常数据做处理；数据量加载过大，内存溢出；未对客户端逻辑错误做异常捕获及处理。
必现的崩溃在测试覆盖较全的情况下，可以被发现、解决。然而还是有些特定场景下的崩溃不容易发现，此时可通过第三方产品，记录崩溃日志以便定位分析、解决问题。
8.1.4 移动应用的安全保障
移动应用的安全问题，主要分为三类：
1.应用自身的安全漏洞
主要是在应用开发过程中，没有重视安全问题，没有在设计、开发、测试、发布环节做好安全性检测工作。必须建立代码安全审计规则，如：平行权限、注入漏洞等，常见的安全问题都应该加入安全测试用例库中。还应关注客户端与服务器端之间数据传输的安全问题，敏感数据禁止明码传输，使用HTTPS协议进行加密传输。
2.应用被篡改
指的是应用被反编译后加入广告、木马等恶意代码，并发布给用户、诱骗用户上当。解决办法是，在应用发布之前做一些必要的“应用加固”处理，如：应用加壳、加密，但这只能对抗一般的静态分析和简单的逆向工程。可以找第三方的移动安全加固公司，购买专业应用加固服务。
3.木马威胁
当用户的手机被植入了木马后，用户的任何操作对于木马来说都是透明的，小到用户访问了什么应用，大到用户的网银帐号密码都可以被木马轻易获取。针对这类情况，应用程序必须有自己的输入模块，替代系统自带的输入模块。另外，还要防止木马程序从本地存储、网络通信上轻易获得用户数据，解决办法是加密后存储、传输。
当今的移动安全问题形势严峻，某应用安全调查报告显示，40%的移动应用存在严重安全问题。随着大家安全意识的培养，移动安全服务业务的兴起，会改善移动应用的安全性。
网友评论