产品经理必须了解的App三大技术框架( 二 ) _App

文章插图

2.动效体验
由于Hybrid App的内容区大部分采用基于Html5的Web技术，对动效的解释和操作需要消耗大量的CPU性能，在设计时，要注意以下三个方面：
a. 不同的动效类型对CPU性能的消耗不同:对CPU性能要求低的动效类型能运行得更流畅，但如果当你的设计方案是非系统自带的动效类型时，就需要提前跟开发沟通可行性和对CPU性能的消耗问题。
b. 机型的性能差异：不同的手机机型的CPU性能相差较大，需要了解不同机型在你的App中的占比，因为即在iphone6上能完美运行的动效或交互动作，在iPhone6以下的手机上可能就会卡住不动了，所以不太适合用于CPU性能消耗较大的频繁渲染。
c. 网络的影响：如果你的动效在运动时，还需要加载内容，就要考虑网络较慢时，内容加载对动效流畅度的影响，这时可考虑先加载完内容，再开始动效或简化、压缩加载的内容量。

文章插图

3.平台兼容
由于Hybrid App的Web内容，是不同的平台共用同一套设计方案，所以为了更好地让设计方案兼容不同的平台特性和手机分辨率，所以建议文案和图形采用以下三种方式：
a. 系统默认字体：如果不是为了设计出特殊的字体样式， iOS、Android和windows Phone系统的默认字体是基本满足我们的需求，同时在不同平台上的显示效果也会比较好。

文章插图

b. SVG（可缩放矢量图形）：能够自由缩放大小来适应不同屏幕尺寸和分辨率，不会模糊变形。

文章插图

c. Iconfont来代替图标：能够自由变换大小和颜色。

文章插图

4.交互行为
由于Hybrid App主要是通过网页的css样式结构和JAVAScript程序语言来还原界面的设计和交互行为，所以跟纯Native App技术框架相比，需要通过更繁琐的代码和层级请求才能实现跟原生系统一样的交互方式，虽然也可模拟Native App的交互方式，但这样的模拟首先提高了开发成本，有悖于不影响性能和高效的原则，所以需要根据设计目标来合理选择是否需要跟系统交互保持一致。
如图所示，如果“每日赢宝箱”的页面是纯Native框架搭建的，则当用户点击“参与互动拿红包”的卡片后，下一个页面会采用iOS系统默认的自右向左切入的交互方式。

文章插图

然而，由于这里采用的是Hybirid App技术框架，所以会像网页一样，直接变换内容区的信息，因为这样的实现方式更高效和不影响性能，更重要的是如果该页面采用直接变换内容的方式不会影响到用户的使用体验，这里就可以考虑不需要跟系统交互保持一致。

文章插图

5.加载方式
对于Hybrid App框架的页面，由于同时存在Native和Web部分，所以在加载内容时，可以分开考虑加载方式：
A. Native部分：可以根据需要把常规内容存储在用户的手机上，加快加载的时间和减少重复加载相同内容的麻烦。
B. Web部分：Web内容区域是需要从网络上加载内容的，尤其在网络条件不好时，需要设计友好的等待状态，缓和用户的焦虑情绪。
如图所示，可以根据不同的框架，来设计不同的加载方式，让等待过程更短或更愉悦。

文章插图

四、设计与技术的权衡
1.明确设计方案的主流程
在技术面前，设计是否只能妥协呢？答案是否定的，在对应的App技术框架下，我们在考虑设计方案时，要明确设计方案的主流程和支流程，凡是会影响到方案核心的主流程的方案，即使开发的实现难度和成本较高，我们也要持续推动技术的突破，来为用户提供更好的使用体验，而对于方案的支流程，我们就可以跟开发协商不同的解决方案，明确哪些地方可以调整技术实现方式或换一种设计方案，哪些方案存在风险，需要有备选方案。