本文目录导航：
【探讨】请问icem和alias那个用得更广，更好使？？？
不一样吧，ICEM是公用来做有限元剖析的网络划分的。
ICEM_Surf是ProE的曲面插件，详细不太分明。
而Alias……你在这里逛逛就知道了，我就不评论了。
三者各属不同畛域。
ALIAS认证有必要吗
有这个认证在找Alias软件方面的上班时是有用的，例如汽车设计行业里的数字建模师，这是个很好的敲门砖。
然而假构想成为汽车设计师的话，认证是个不错的加分条件，但不是必要条件。
学历不限，认证分两个方向，Alias设计师和Alias工程师（即数字模型师）。
均有level1，level2，level3三个等级的考试。
前两个等级比拟便捷，三级考试有必定的难度，可以补考两次。
目前做alias培训比拟威望的上海有畅驭，无锡有思迪培训核心（思迪的教员比拟有名），学费这个会有变化，自己找最新的咨询吧。
另外，学习是把握技艺的形式，还有很关键的是在学习技艺的环节中接触这个行业中的晚辈，向他们了解行业状况，为以后务工做好铺垫，祝你顺利。
友盟-推送-Andorid-“Alias”是什么, 该如何经常使用？
不少开发者在经常使用友盟推送的时刻，对Alias的用法和经常使用场景不是太了解，这篇文章给大家遍及一下Alias相关的内容:咱们先从产品层面上对Alias的设计思维说起，这样能协助大家更好的了解和经常使用Alias。
在咱们官网文档外面，Alias的定义是: 设施别名，将别名与设施做绑定，便于局部App开发者经常使用自有账号或许第三方账号体系来做信息推送。
定义外面触及到几个关键的点:首先，Alias是和设施绑定的，友盟推送对设施的标识是device-token，也就是说，Alias与友盟device-token是绑定对应的。
从这个层面来讲，Alias可以是开发者的账号系统(包含第三方账号体系)，也可以是开发者自己对设施的标识体系(如安卓设施上的imei+mac)，或许是其它的开发者能保障惟一性的ID体系，这些都是由开发者自己选择的。
提问中问到能否可以把Alias了解为账号系统，狭义上讲可以这么了解，实践上，友盟推送赋予了Alias更多的灵敏性。
其次，联合到越来越多的App提供第三方社交平台账号登陆的特点，咱们在Alias的设计上也充沛思考到了账号的需求，所以在官网文档中，咱们提到在经常使用Alias的时刻，必定要关联一个alias_type, 假设是开发者自定义的alias(包含自有账号系统)，这个alias_type是可以随意定义的；假设是用了第三方账号系统，咱们预提供了20多种干流的开明平台的账号类型，如新浪微博(SINA_WEIBO), 微信(WEIXIN)等。
填写alias_type的作用是，友盟推送会和友盟社会化分享服务做数据上的买通，更好的从数据层面施展价值，为开发者服务。
说到这里，咱们再次准确一下Alias的概念，即别名(Alias)+别名类型(alias_type)与设施的绑定。
最后，咱们来聊聊Alias的用法，这个也是开发者们十分关心的。
咱们Alias的绑定操作是在SDK端提供的，开发者只有要在SDK端调用(alias, alias_type)这个接口，友盟推送SDK就担任把alias+alias_type与友盟的device-token做绑定，将绑定相关回传到友盟后端主机。
之后开发者就可以依据自有业务逻辑，调用友盟主机端接口，依据Alias来做共性化推送了。
由此来看，Alias的作用是能让开发者联合自有的账号(此处要求了解成狭义的账号)体系，来做更共性化、精细化的推送。
下图是一个简化的Alias架构，协助大家了解Alias的用法:对于Alias的相关接口，咱们的友盟信息推送Android文档提供了十分丰盛的接笔供开发者调用:[Java] 纯文本检查 复制代码?减少(, ALIAS__WEIBO); 移除(, ALIAS__WEIBO);留意，在App主机端调用友盟主机端接口做推送的时刻，必定不要忘了传入alias_type的参数。
对于Alias基本的话题差不多解释分明了，最后再和大家深化聊聊Alias用作账号系统触及到多账号多设施登陆的疑问，这个时刻，alias_type就派上用场了，置信看过这个章节后，大家会对咱们Alias的设计机制有更深化的了解:1. 多个账号登陆同一台设施，详细还要细分为两种case:假设是同一个alias_type，那么以最后绑定的alias为准。
举个例子: (alias_A, alias_type_A)先做了绑定，之后(alias_B, alias_type_A)后做了绑定，那么，假设这个时刻给alias_A发信息，设施是不会收到信息的，由于在友盟推送后盾device-token是和最后登陆的alias_B做绑定的。
这个在实践业务场景中也成立，最后一个登录的账号才是这台设施以后实在的用户。
假设不是同一个alias_type, 那么前后两个绑定的alias均失效。
举个例子: (alias_A, alias_type_A)先做了绑定，之后是(alias_B, alias_type_B)做了绑定，那么不论是给alias_A发信息，还是给alias_B发信息，设施均能收到信息。
由于alias_type变化之后，友盟推送后盾确定不了这是同一个用户(eg: 同一个用户经常使用不同平台的账号登录)，还是不同的用户(不同的用户，经常使用不同的账号登录)，友盟只能便捷的判定这两个不同alias_type的账号是两个不同的账号。
这种场景是要求特意留意的，倡导开发者在实践的集成环节中尽量防止这种经常使用场景。
2. 同一个账号登录多台设施:这种状况解决起来就比拟便捷了，即一个alias和多个device-token做绑定。
假设给这个alias发信息，咱们会给一切和这个alias绑定的设施都去推送信息。
开发者在详细经常使用环节中，或许会想到Alias做了绑定(addAlias)或许解除(removeAlias)之后,多长期间能在后端失效。
Alias接口，是一个实时的接口，不论是在“测试形式”下，还是在“正式形式”下，都是实时失效的。
不过在集成测试阶段，还是倡导开发者把手头的设施减少到测试形式下的测试设施汇合外面，对于“测试形式”的更多引见，请参考友盟推送“测试形式”引见。
