【www.shanpow.com--热门范文】
微信开发协议一:微信公众平台开发者服务协议
欢迎你使用微信公众平台开发者服务！
为使用该项服务，你应当阅读并遵守《微信公众平台开发者服务协议》（以下简称“本协议”），以及《腾讯服务协议》、《腾讯微信软件许可及服务协议》、《微信公众平台服务协议》。本协议被视为《腾讯服务协议》及《腾讯微信软件许可及服务协议》的补充协议，是其不可分割的组成部分，与其构成统一整体。本协议与上述内容存在冲突的，以本协议为准。
本协议内容同时包括腾讯可能不断发布的关于本服务的相关协议、服务声明、业务规则及公告指引等内容（以下统称为“专项规则”）。上述内容一经正式发布，即为本协议不可分割的组成部分，你同样应当遵守。请你务必审慎阅读、充分理解各条款内容，特别是免除或者限制责任的条款，以及开通或使用某项服务的单独协议，并选择接受或不接受。限制、免责条款可能以加粗形式提示你注意。
除非你已阅读并接受本协议所有条款，否则你无权使用微信公众平台开发者服务。你对微信公众平台开发者服务的接受、提交资料和信息、使用等行为即视为你已阅读并同意本协议的约束。
如果你未满18周岁，请在法定监护人的陪同下阅读本协议及其他上述协议，并特别注意未成年人使用条款。
1. 术语含义
如无特别说明，下列术语在本协议中的含义为：
1.1 微信公众平台，是指由腾讯经营的域名为“mp.weixin.qq.com”的网站。
1.2 微信公众平台开发者服务：是指腾讯在微信公众平台提供给开发者对微信公众帐号功能进行开发的各项服务（以下简称“本服务”）。
1.3 开发者：是指利用本服务对其享有相应权利的微信公众帐号功能进行开发，并通过微信公众帐号的特定功能向其他用户提供各种服务的个人、法人或其他组织，简称为“你”。
1.4 用户数据：是指开发者向其他用户提供服务过程中产生的与其他用户相关的数据，包括但不限于其他用户提交的数据、其他用户操作行为形成的数据及各类交易数据等。“用户数据”的所有权及其他相关权利属于腾讯，且属于腾讯的商业秘密，但其他用户依法享有相关权利的除外。
1.5 开发者运营数据：是指开发者在微信公众帐号中产生的相关数据，包括但不限于开发者提交的数据、操作行为形成的数据及各类交易数据等。“开发者运营数据”的所有权及其他相关权利属于腾讯，且属于腾讯的商业秘密，但开发者依法享有相关权利的除外。
2. 开发者权利和义务
2.1 你保证：你使用本服务的微信公众帐号已经帐号资质审核成功；你具备使用本服务、接入和运营微信公众帐号、提供相关服务等行为的相关合法资质或已经过相关政府部门的审核批准；你向腾讯提供的主体资质材料、相关资质证明以及其他任何文件等信息真实、准确、完整，并在信息发生变更后，及时进行更新；你具备履行本协议项下之义务及各种行为的能力；你履行相关义务、从事相关行为不违反任何对你的有约束力的法律文件。否则，你应停止使用本服务，且应独自承担由此带来的一切责任及给其他用户、腾讯造成的全部损失。
2.2 你保证：你会依法或按照腾讯要求提交使用本服务所需的真实、准确、完整并经过你签章确认的主体资质材料以及联系人姓名（名称）、地址、电子邮箱等相关资料。
2.3 你保证：你通过你的微信公众帐号提供的各种服务，符合国家相关法律法规的规定及相关协议、规则，也不会侵犯任何人的合法权益，同时，你会依法、依约或按照腾讯的要求提供版权、专利权等相关证明文件。
2.4 你保证：你使用本服务对你的微信公众帐号进行开发、编辑、修改、测试、运营及维护等工作由你负责，并且自行承担相应的费用。
2.5 你理解并同意：腾讯有权制定本服务的具体使用规范及技术要求，同时部分服务有可能存在包括但不限于接口调用次数、功能使用次数及条数等限制。
3. 腾讯权利义务
3.1 在本服务范围内，腾讯会根据你选择的项目向你提供相应的服务。
3.2 腾讯会在现有技术和条件下尽最大努力保护你的信息，但非因腾讯因素给你造成的损害，你同意腾讯可以免责。
3.3 腾讯可将本协议项下的权利和义务部分或全部转让给他人，如果你不同意前述转让，则应停止使用本服务。
3.4 除另有约定外，腾讯无需为根据本协议获得的权益而向你支付任何费用。
3.5 本服务可能会使用第三方软件或技术（包括本服务可能使用的开源代码和公共领域代码等，下同），这种使用已经获得合法授权；同时，本服务如果使用了第三方的软件或技术，腾讯将按照相关法规或约定，对相关的协议或其他文件进行展示，它们可能会以“软件使用许可协议”、“授权协议”、“开源代码许可证”或其他形式来表达。前述通过各种形式展现的相关协议或其他文件，均是本协议不可分割的组成部分，与本协议具有同等的法律效力，你应当遵守这些要求。如果你没有遵守这些要求，该第三方或者国家机关可能会对你提起诉讼、罚款或采取其他制裁措施，并要求腾讯给予协助，你应当自行承担法律责任。如因本服务使用的第三方软件或技术引发的任何纠纷，应由该第三方负责解决，腾讯不承担任何责任。腾讯不对第三方软件或技术提供客服支持，若你需要获取支持，请与第三方联系。
4. 开发者管理规范
4.1 开发行为规范
4.1.1 你理解并同意：本服务中腾讯仅向你提供微信公众平台相关接口权限，由你按照本协议和开发者文档等规范和技术要求自行开发，你应对使用本服务所产生的内容自行独立承担责任，如因此造成腾讯损失的，你应当赔偿。
4.1.2 未经腾讯书面许可，你不得将本服务用于任何其他目的及用途，或委托、授权及泄漏给任何第三方为任何方式的使用。
4.1.3 你使用本服务所进行的开发全过程除应符合《微信公众平台公众帐号开发者文档》的明确要求外，还应符合相关法律法规、技术规范标准以及腾讯在技术、安全等方面的相关要求， 以确保相关微信公众帐号安全、稳定的运营。本协议使用规范同时包含本协议条款、《微信公众平台公众帐号开发者文档》以及其他相应接口的开发者文档，你使用本服务应当同时遵守上述规范，否则腾讯有权依照本协议采取处理措施。
4.1.4 你在使用本服务过程中不得从事以下行为，也不得为以下行为提供便利，该等行为包括但不限于： 4.1.4.1 删除、隐匿、改变微信公众平台显示或其中包含的任何专利、著作权、商标或其他所有权声明； 4.1.4.2 在未获得腾讯书面许可的情况下，以任何方式使用腾讯URL地址、本服务外的其他技术接口等； 4.1.4.3 在未经过其他用户同意的情况下，向任何其他用户及他方显示或以其他任何方式提供该用户的任何信息； 4.1.4.4 在没有获得其他用户同意的情况下，直接联系其他用户，或向其他用户发布任何商业广告及骚扰信息； 4.1.4.5 为任何其他用户自动登录到微信公众平台提供代理身份验证凭据； 4.1.4.6 提供跟踪功能，包括但不限于识别其他用户的操作行为； 4.1.4.7 自动将浏览器窗口定向到其他网页； 4.1.4.8 设置或发布任何违反相关法律法规、公序良俗、社会公德等的功能或内容； 4.1.4.9 公开表达或暗示你与腾讯之间存在合作关系，包括但不限于相互持股、商业往来或合作关系等； 4.1.4.10 利用本服务在你的公众帐号下开发任何形式的网络平台服务； 4.1.4.11 其他腾讯认为不应该、不适当的行为或内容。
4.2 其他用户及开发者运营数据规则
4.2.1 你使用本服务通过微信公众帐号向其他用户提供服务的过程中，对于其他用户数据的收集、保存、使用等必须满足以下要求： 4.2.1.1 你的服务需要收集其他用户任何数据的，必须事先获得其他用户的明确同意，且仅应当收集为运营及功能实现目的而必需的用户数据，同时应当告知其他用户相关数据收集的目的、范围及使用方式等，保障其他用户知情权和选择权； 4.2.1.2 你收集其他用户的数据后，必须采取必要的保护措施，防止用户数据被盗、泄漏等； 4.2.1.3 你在特定微信公众帐号中收集的用户数据仅可以在该特定微信公众帐号中使用，不得将其使用在该特定微信公众帐号之外或为其他任何目的进行使用，也不得以任何方式将其提供给他人。
4.2.2 如果腾讯认为你收集、使用用户数据的方式，可能损害用户体验，腾讯有权要求你删除相关数据并不得再以该方式收集、使用用户数据。
4.2.3 腾讯有权限制或阻止你获取用户数据及开发者运营数据。
4.2.4 开发者运营数据、用户数据等数据的全部权利，均归属腾讯，且属于腾讯的商业秘密，但开发者、其他用户依法享有相关权利的除外。未经腾讯事先书面同意，你不得为本协议约定之外的目的使用前述数据，亦不得以任何形式将前述数据提供给他人。
4.2.5 一旦你停止使用本服务，或腾讯基于任何原因终止你使用本服务，你必须立即删除全部因使用本服务而获得的数据（包括各种备份），且不得再以任何方式进行使用。
4.2.6 你应自行对因使用本服务而获得的各类数据和信息，采取合理、安全的技术措施，确保其安全性，并对自己的行为（包括但不限于自行安装软件、采取加密措施或进行其他安全措施等）所引起的结果承担全部责任。
4.3 你在运营相关微信公众帐号期间，你需向其他用户提供及时有效的客户服务，客户服务形式包括但不限于通过明确且合理的方式告知其他用户客户服务渠道、提供QQ/电话等，并自行承担客服费用。
5. 关于免责
5.1 微信公众平台仅向开发者提供信息存储空间、链接等中立的网络服务和技术支持服务，以供开发者自主运营其微信公众帐号。
5.2 腾讯并不参与开发者的微信公众帐号的运营，开发者及其运营的微信公众帐号应当依照《微信公众平台服务协议》、专项规则等规定对外独立承担全部责任，因开发者提供的服务产生的任何纠纷、责任，以及开发者违反相关法律法规或本协议约定引发的任何后果，均由开发者独立承担，与腾讯无关。如侵害到腾讯或他人权益的，开发者须自行承担全部责任和赔偿一切损失。
5.3 你理解并同意：鉴于网络服务的特殊性，腾讯有权在无需通知你的情况下根据微信公众平台的整体运营情况或相关运营规范、规则等，随时变更、中止或终止部分或全部的服务，若由此给你造成损失的，你同意放弃追究腾讯的责任。
5.4 你理解并同意：为了向你提供更完善的服务，腾讯有权定期或不定期地对提供本服务的平台或相关设备进行检修、维护、升级，此类情况可能会造成相关服务在合理时间内中断或暂停，若由此给你造成损失的，你同意放弃追究腾讯的责任。
5.5 你理解并同意：腾讯会尽最大努力在现有技术和条件下向你提供服务，并确保服务的连贯性和安全性；但腾讯不能保证其所提供的服务毫无瑕疵，也无法随时预见和防范法律、技术以及其他风险，故若由于对以下情形导致的服务中断或受阻，给你造成损失的，你同意放弃追究腾讯的责任： 5.5.1 受到计算机病毒、木马或其他恶意程序、黑客攻击的破坏； 5.5.2 你或腾讯的电脑软件、系统、硬件和通信线路出现故障； 5.5.3 第三方服务瑕疵、政府行为等原因可能导致的服务中断、数据丢失； 5.5.4 你操作不当； 5.5.5 你通过非腾讯授权的方式使用本服务； 5.5.6 其他腾讯无法控制或合理预见的情形。
5.6 你理解并同意：在使用本服务的过程中，可能会遇到不可抗力等风险因素，使本服务发生中断。不可抗力是指不能预见、不能克服并不能避免且对一方或双方造成重大影响的客观事件，包括但不限于自然灾害如洪水、地震、瘟疫流行和风暴等以及社会事件如战争、动乱、政府行为等。出现上述情况时，腾讯将努力在第一时间与相关单位配合，及时进行修复，若由此给你造成损失的，你同意放弃追究腾讯的责任。
6. 法律责任
6.1 你保证：你使用本服务及你的任何行为，不会侵犯任何人的合法权益，也不违反任何相关法律法规、本协议和相关协议、规则等。你理解并同意：如果腾讯发现或收到他人投诉你违反前述保证的，腾讯有权不经通知随时单方采取以下一项或多项措施:
6.1.1 要求你立即更换、修改侵犯他人合法权益及前述保证的相关功能或内容；
6.1.2 对相关违反前述保证情形的功能或内容进行删除，并视行为情节对相关微信公众帐号采取包括但不限于警告、限制或禁止使用本服务全部或部分功能、封禁直至注销等处理措施；
6.1.3 中止或终止向你提供本服务； 6.1.4 其他腾讯认为适合的处理措施。
6.2 你理解并同意，腾讯有权依合理判断对违反有关法律法规或本协议规定的行为采取处理措施，对违法违规的任何人士采取适当的法律行动，并依据法律法规保存有关信息向有关部门报告等，你应独自承担由此而产生的一切法律责任。
6.3 你理解并同意，因你违反本协议或相关的服务条款的规定，导致或产生的任何第三方主张的任何索赔、要求或损失，包括合理的律师费，你应当赔偿腾讯与第三方，并使之免受损害。
7. 服务的中止或终止
7.1 如发生下列任何一种情形，腾讯有权不经通知随时中止或终止向你提供本服务： 7.1.1 你的微信公众帐号认证被注销； 7.1.2 你书面通知腾讯不接受本协议或对其的修订； 7.1.3 因不可抗力因素导致你无法继续使用本服务或腾讯无法提供本服务的； 7.1.4 你违反本协议约定，腾讯依约终止向你提供本服务后，你后续再直接或间接，或以他人名义注册使用本服务； 7.1.5 其他中止或终止条件发生或实现。
7.2 如本协议或本服务因为任何原因终止的，你因使用本服务而存储在腾讯服务器中的数据等任何信息，包括服务终止前你尚未完成的任何数据，腾讯可保留或删除；你应自行处理好关于数据等信息的备份以及与你的其他用户之间的相关事项的处理等，由此造成腾讯损失的，你应负责赔偿。
8. 关于通知
8.1 腾讯可能会以网页公告、网页提示、电子邮箱、手机短信、常规的信件传送、微信公众平台的管理系统内发送站内信等方式中的一种或多种，向你送达关于本服务的各种规则、通知、提示等信息，该等信息一经腾讯采取前述任何一种方式公布或发送，即视为你已经接受并同意，对你产生约束力，若你不接受的，请你书面通知腾讯。
8.2 若由于你提供的电子邮箱、手机号码、通讯地址等信息错误，导致你未收到相关规则、通知、提示等信息的，一切后果及责任由你自行承担。
8.3 若你有事项需要通知腾讯的，应当按照本服务对外正式公布的联系方式书面通知腾讯。
9. 知识产权
9.1 腾讯在本服务中提供的信息内容（包括但不限于网页、文字、图片、音频、视频、图表等）的知识产权均归腾讯所有，依法属于他人所有的除外。 除另有特别声明外，腾讯提供本服务时所依托软件的著作权、专利权及其他知识产权均归腾讯所有。腾讯在本服务中所使用的“微信”、“WeChat”、“腾讯”、 “TENCENT”及企鹅形象等商业标识，其著作权或商标权归腾讯所有。上述及其他任何腾讯依法拥有的知识产权均受到法律保护，未经腾讯书面许可， 你不得以任何形式进行使用或创造相关衍生作品。
9.2 你仅拥有依照本协议约定合法使用本服务的权利，与本服务相关的著作权、专利权及其他知识产权等相关全部权利归腾讯所有。 未经腾讯书面许可，你不得违约或违法使用，不得向任何单位或个人出售、转让、转授权腾讯的代码及开发工具等。
10. 其他
10.1 本协议签订地为中华人民共和国广东省深圳市南山区。
10.2 本协议的成立、生效、履行、解释及纠纷解决，适用中华人民共和国大陆地区法律（不包括冲突法）。
10.3 若你和腾讯之间发生任何纠纷或争议，首先应友好协商解决；协商不成功的，双方均同意将纠纷或争议提交本协议签订地有管辖权的人民法院解决。
10.4 本协议所有条款的标题仅为阅读方便，本身并无实际涵义，不能作为本协议涵义解释的依据。
10.5 本协议条款无论因何种原因部分无效或不可执行，其余条款仍有效，对双方具有约束力。
微信开发协议二:微信通讯协议的学习
架构师（JiaGouX）我们都是架构师！
微信协议概览
微信传输协议，官方公布甚少，在微信技术总监所透漏PPT《微信之道—至简》文档中，有所体现。
微信从2011年1月发布以来，在一年之内实现了上亿用户，千万级在线，在苹果中国区App Store月下载量排行第一。 腾讯把微信的成功总结为“三位一体”，即产品的精准，项目的敏捷，以及技术的支撑。 敏捷就是试错法，用最快的迭代速度不断追求卓越。敏捷是一种态度，允许发布前十分钟的变更，并给予产品决策以最大的自由度。
微信使用的同步协议叫做SYNC，参考了微软的ActiveSync YNchronous ommunication：同步通信。没有数据发送时，传输线处于MARK状态。为了表示数据传输的开始，发送方先发送一个或两个特殊字符，该字符称为同步字符。当发送方和接收方达到同步后，就可以一个字符接一个字符地发送一大块数据，而不再需要用起始位和停止位了，这样可以明显地提高数据的传输速率。采用同步方式传送数据时，在发送过程中，收发双方还必须用一个时钟进行协调，用于确定串行传输中每一位的位置。接收数据时，接收方可利用同步字符将内部时钟与发送方保持同步，然后将同步字符后面的数据逐位移入，并转换成并行格式，供CPU读取，直至收到结束符为止。用一个Key来实现状态同步。这样一种协议在后台实现上比业界通用方案要复杂许多，但是能把客户端的实现大大简化，同时在很大程度上能够满足iPhone，安卓，塞班等多个操作系统的不同需求。
微信秉承“重后台轻客户端”的思路，因为客户端安装在用户手机上，变更成本很高；而后台则可以实现迅速的变更，在不发新版本的情况下实现新功能。以下是一个例子：微信的最初版本是不支持群聊的，第二个版本支持了群聊，但第一版客户端仍然可以在后台的变更处理之下参与群聊，只是不能够发起群聊而已。
其服务器端目前获知的几部分分别是三网专用网关服务器、登陆服务器组、负载均衡服务器组，主动推送服务器组、后台数据转换服务器组、存储阵列等几部分。由于目前没有任何能够直接从客户端保存至服务器端的功能，推测其服务方并没有用于数据记录的数据库服务器，而是在登陆服务器组中集成了用户数据库，用来记录用户授权。
因张小龙做邮箱Foxmail起家，继而又做了QQ Mail等，QQ Mail是国内第一个支持Exchange ActiveSync协议的免费邮箱，基于其从业背景，微信从一开始就采取基于ActiveSync的修改版状态同步协议Sync，也就再自然不过了。一句话：增量式、按序、可靠的状态同步传输的微信协议。
Microsoft Exchange Active Sync协议
Microsoft Exchange Active Sync协议，简称EAS，分为folderrsync(同步文件夹目录，即邮箱内有哪几个文件夹)和sync（每个文件夹内有哪些文档）两部分。
某网友总结的协议一次回话大致示范：
Client: synckey=0 //第一次key为0
Server: newsynckey=1235434 //第一次返回新key
Client: synckey=1235434 //使用新key查询
Server: newsynckey=1647645,data=*****//第一次查询，得到新key和数据
Client: synckey=1647645
Server: newsynckey=5637535,data=null //第二次查询，无新消息
Client: synckey=5637535
Server: newsynckey=8654542, data=****//第三次查询，增量同步
大致交换简图如下：
如何获取新数据呢：
服务器端通知，客户端获取
客户端携带最新的SyncKey，发起数据请求
服务器端生成最新的SyncKey连同最新数据发送给客户端
基于版本号机制同步协议，可确保数据增量、有序传输
SyncKey，由服务器端序列号生成器生成，一旦有新消息产生，将会产生最新的SyncKey。类似于版本号
服务器端通知有状态更新，客户端主动获取自从上次更新之后有变动的状态数据，增量式，顺序式。
微信的协议
为保证稳定，微信用了长链接和短链接相结合，微信划分了http模式（short链接）和 tcp 模式（long 链接），分别应对状态协议和数据传输协议
weixin.qq.com dns check （112.64.237.188 112.64.200.218）
weixin.qq.com dns check ( 112.64.237.186 112.64.200.240)
1）short.weixin.qq.com
是HTTP协议扩展，运行8080 端口，http body为二进制（protobuf）。主要用途（接口）：
用户登录验证;
好友关系（获取，添加）；
消息sync (newsync)，自有sync机制；
获取用户图像；
用户注销；
行为日志上报。
朋友圈发表刷新
2）long.weixin.qq.com
tcp长连接，端口为8080，类似微软activesync的二进制协议。主要用途（接口）：
接受/发送文本消息；
接受/发送语音；
接受/发送图片；
接受/发送视频文件等。
所有上面请求都是基于tcp长连接。在发送图片和视频文件等时，分为两个请求；第一个请求是缩略图的方式，第二个请求是全数据的方式。
3）数据报文方面
增量上传策略：每次8k左右大小数据上传，服务器确认；在继续传输。
图片上传：先传缩略图，传文本消息，再传具体文件
下载：先下载缩略图， 在下载原图，下载的时候，全部一次推送。
Sync 同样存在一些问题：
SyncKey 生成维护成本：SyncKey 在ActiveSync中为字符串，客户端不需要解析，但服务端实现要用数字自增，需要强一致性，且不能回退。
消息的订阅模式：采用类似Zookeeper的One time triggler 还是每条消息都推送一条通知能，ne time trigger能够避免并发通知时，获取消息时重复问题，但增加了交互成本，和客户端实现复杂性。
自己发的消息，SyncKey怎么获取，其要支持多端同步发消息，保证消息同步；也只好消息发完在给自己同步一遍(自己设备发的可以不带消息体）
消息推送延时加重：Sync 消息体获取方式：Notify – Ack – get – Mssage, 也就是至少第四个应用包才能返回消息，在移动网络下成本很高。
手机客户端不再Sync协议
抓包分析版本：wifi、gprs网络状况下都相同，客户端会依次尝试使用80、8080、443 端口连接服务器；消息发送、接收都使用长连接进行.
协议格式：
4byte Packet Len(包含4字节本身)
2byte Head Len(包含2字节本身) + 2byte Version(1) + 4byte Operation + 4byte SeqId + ….
(Packet Len – Head Len) Body
协议交互方式：
客户端请求（一应一答，通过seqid匹配）：seqid = 1 开始，依次递增，服务器回复相同的seqid 作为应答
服务器推送通知（单向）：seqid = 0，Operation = 7a, 客户端不需要应答
主要业务：
-心跳包：发起客户端请求，Operation = 0c，长度为16字节，算是最小的包
-发消息：发起客户端请求，Operation = ed；单点在线时发完消息后，应答携带SyncKey，不再同步，多点在线时，通过通知同步SyncKey。
-收消息：服务器推送消息，Operation = 7a, Body 中携带消息内容，抓包分析时，通过改变消息体大小，可能到接收方第一个包length 也会随之变化，可确认消息是push的。发起客户端单向请求，即消息的应答Ack。
-加密：未分析，一般来说像whatsapp那样，使用 hash(密码/OTP + 长连接第一个请求获取RandomCode) 做RC4 的密钥
APP抓包数据
1）初始连接记录
简单记录微信启动之后请求：
11:20:35 dns查询weixin.qq.com 返回一组IP地址
11:20:35 DNS查询 weixin.qq.com 返回一组IP地址，本次通信中，微信使用了最后一个IP作为TCP长连接的连接地址。
11:20:35 http://dns.weixin.qq.com/cgi-bin/micromsg-bin/newgetdns?uin=0&clientversion=620888113&scene=0&net=1 用于请求服务器获得最优IP路径。服务器通过结算返回一个xml定义了域名:IP对应列表。仔细阅读，可看到微信已经开始了国际化的步伐：香港、加拿大、韩国等。
11:20:35 获取到weixin.qq.com最优IP，然后建立到101.227.131.105的TCP长连接
11:21:25 POST http://short.weixin.qq.com/cgi-bin/micromsg-bin/getprofile HTTP/1.1 (application/octet-stream) 返回一个名为“micromsgresp.dat”的附件，估计是未阅读的离线消息
11:21:31 POST http://short.weixin.qq.com/cgi-bin/micromsg-bin/whatsnews HTTP/1.1 (application/octet-stream) 大概是资讯、订阅更新等
中间进行一些资源请求等，类似于GEThttp://wx.qlogo.cn/mmhead/Q3auHgzwzM7NR4TYFcoNjbxZpfO9aiaE7RU5lXGUw13SMicL6iacWIf2A/96，图片等一些静态资源都会被分配到qlogo.cn域名下面
POST http://short.weixin.qq.com/cgi-bin/micromsg-bin/downloadpackage HTTP/1.1 (application/octet-stream) 输出为dat文件。
11:21:47 GET http://support.weixin.qq.com/cgi-bin/mmsupport-bin/reportdevice?channel=34&deviceid=A952001f7a840c2a&clientversion=620888113&platform=0&lang=zh_CN&installtype=0 HTTP/1.1 返回chunked分块数据
11:21:49 POST http://short.weixin.qq.com/cgi-bin/micromsg-bin/reportstrategy HTTP/1.1 (application/octet-stream) 心跳频率约为5分钟，登陆之后，会建立一个长连接，端口号为8080
2）初始消息传输
个人资料、离线未阅读消息部分等通过 POST HTTP短连接单独获取。抽取微信某次HTTP协议方式通信数据，16进制表示，每两个靠近的数字为一个byte字节：
3）微信协议可能如下：
一个消息包 = 消息头 + 消息体
消息头固定16字节长度，消息包长度定义在消息头前4个字节中。单纯摘取第0000行为例，共16个字节的头部:00 00 00 10 00 10 00 01 00 00 00 06 00 00 00 0f16进制表示，每两个紧挨着数字代表一个byte字节。
微信消息包格式：
前4字节表示数据包长度，可变值为16时，意味着一个仅仅包含头部的完整的数据包（可能表示着预先定义好的业务意义），后面可能还有会别的消息包
2个字节表示头部长度，固定值，0x10 = 16
2个字节表示协议版本，固定值，0x01 = 1
4个字节操作说明数字，可变
序列号，可变
头部后面紧跟着消息体，非明文，加密形式
一个消息包，最小16 byte字节
4）新消息获取方式
TCP长连接接收到服务器通知有新消息需要获取
APP发起一个HTTP POST请求获取新状态消息，会带上当前SyncKey 地址为：http://short.weixin.qq.com/cgi-bin/micromsg-bin/reportstrategy HTTP/1.1，看不到明文
APP获取到新的消息，会再次发起一次HTTP POST请求，告诉服务器已确认收到，同时获取最新SyncKey 地址为：http://short.weixin.qq.com/cgi-bin/micromsg-bin/kvreport，看不到明文
接受一个消息，TCP长连接至少交互两次，客户端发起两次HTTP POST请求
服务器需要支持：状态消息获取标记，状态消息确认收取标记。只有被确认收到，此状态消息才算是被正确消费掉
多个不同设备同一账号同时使用微信，同一个状态消息会会被同时分发到多个设备上
5）发送消息方式
发送消息走已经建立的TCP长连接通道，发送消息到服务器，然后接受确认信息等，产生一次交互。
小伙伴接收到信息阅读也都会收到服务器端通知，产生一次交互等。
可以确定，微信发送消息走TCP长连接方式，因为不对自身状态数据产生影响，应该不交换SyncKey。
在低速网络下，大概会看到消息发送中的提示，属于消息重发机制
网络不好有时客户端会出现发送失败的红色感叹号
已发送到服务器但未收到确认的消息，客户端显示红色感叹号，再次重发，服务器作为重复消息处理，反馈确认
上传图片，会根据图片大小，分割成若干部分（大概5K被划分为一部分），同一时间点，客户端会发起若干次POST请求，各自上传成功之后，服务器大概会合并成一个完整图片，返回一个缩略图，显示在APP聊天窗口内。APP作为常规的文字消息发送到服务器端
上传音频，则单独走TCP通道，一个两秒的录制音频，客户端录制完毕，分为两块传输，一块最大5K左右，服务端响应一条数据通知确认收到。共三次数据传输。音频和纯文字信息一致，都是走TCP长连接，客户端发送，服务器端确认。
6）微信协议小结
发布的消息对应一个ID（只要单个方向唯一即可，服务器端可能会根ID判断重复接收），消息重传机制确保有限次的重试，重试失败给予用户提示，发送成功会反馈确认，客户端只有收到确认信息才知道发送成功。发送消息可能不会产生新SyncKey。
基于版本号（SynKey）的状态消息同步机制，增量、有序传输需求水到渠成。长连接通知/短连接获取、确认等，交互方式简单，确保了消息可靠谱、准确无误到达。
客户端/服务器端都会存储消息ID处理记录，避免被重复消费客户端获取最新消息，但未确认，服务器端不会认为该消息被消费掉。下次客户端会重新获取，会查询当前消息是否被处理过。根据一些现象猜测。
总体上看，微信协议跨平台（TCP或HTPP都可呈现，处理方式可统一），通过“握手”同步，很可靠，无论哪一个平台都可以支持的很好
微信协议最小成本为16字节，大部分时间若干个消息包和在一起，批量传输。微信协议说不上最简洁，也不是最节省流量，但是非常成功的。
若服务器检测到一些不确定因素，可能会导致微启用安全套接层SSL协议进行常规的TCP长连接传输。短连接都没有发生变化
现在版本的微信消息推送，并非Sync方式，而是推送+ack方式；从他们协议设计来看，应该最开始用的是Notify + Sync Req + Sync Rsp 方式，因为协议上是不支持服务器发起请求的；现在改成Sync消息+ 单向Ack Req 的push方式，虽然协议上怪异， 相比Sync 消息接收会更加及时。从以前看到的文章都是说用的Sync协议，应该是是后期版本做了修改，push方式更为高效、而且通过顺序的SyncKey也能够修复丢失的消息。
Web客户端使用比较标准的Sync协议
web微信客户端，使用的是比较标准的Sync协议，Sync协议也比较适合web长轮询模型。
移动客户端模式下，协议是二进制的而且有加密，很难分析；微信侧重手机端，web端主体协议应该保持与移动端一致，可通过web端推测整体协议实现，json也比较好分析。
接收一条消息后SyncKey变化：
synckey:1_624161340|2_624162225|3_624162051|11_624161867|201_1420112604|1000_1420104656
synckey:1_624161340|2_624162226|3_624162051|11_624161867|201_1420112631|1000_1420104656
可以看出：
Synckey 有多个，应该是应对不同业务，其中2为为所有个人消息、讨论组消息，其他可能是联系人、朋友圈、订阅号等，201 为当前时间戳。
SyncKey 的值为数字自增，不是从0开始，应该有个固定的初始值。
发消息时，发完需要自己给再自己同步回一下SyncKey。
消息增量同步结构，一堆要同步字段+是否修改FlagMask，同步协议变得很简洁。
Web抓包数据
1）发起GET长连接检测是否存在新的需要同步的数据，会携带上最新SyncKey
https://webpush.weixin.qq.com/cgi-bin/mmwebwx-bin/synccheck?callback=jQuery18306073923335455973_1393208247730&r=1393209241862&sid=s7c%2FsxpGRSihgZAA&uin=937355&deviceid=e542565508353877&synckey=1_620943725%7C2_620943769%7C3_620943770%7C11_620942796%7C201_1393208420%7C202_1393209127%7C1000_1393203219&_=1393209241865
返回内容：
window.synccheck={retcode:”0″,selector:”2″}
selector值大于0，表示有新的消息需要同步。据目测，心跳周期为27秒左右。
2）一旦有新数据，客户端POST请求主动获取同步的数据
https://webpush.weixin.qq.com/cgi-bin/mmwebwx-bin/webwxsync?sid=s7c%2FsxpGRSihgZAA&r=1393208447375
携带消息体：
{“BaseRequest”:{“Uin”:937355,”Sid”:”s7c/sxpGRSihgZAA”},”SyncKey”:{“Count”:6,”List”:[{“Key”:1,”Val”:620943725},{“Key”:2,”Val”:620943767},{“Key”:3,”Val”:620943760},{“Key”:11,”Val”:620942796},{“Key”:201,”Val”:1393208365},{“Key”:1000,”Val”:1393203219}]},”rr”:1393208447374}
会携带上最新的SyncKey，会返回复杂结构体JSON内容。但浏览端收取到消息之后，如何通知服务器端已确认收到了？Web版本微信，没有去做。
3）发送消息流程
发起一个POST提交，用于提交用户需要发送的消息
https://webpush.weixin.qq.com/cgi-bin/mmwebwx-bin/webwxsendmsg?sid=lQ95vHR52DiaLVqo&r=1393988414386
发送内容：
{“BaseRequest”:{“Uin”:937355,”Sid”:”lQ95vHR52DiaLVqo”,”Skey”:”A6A1ECC6A7DE59DEFF6A05F226AA334DECBA457887B25BC6″,”DeviceID”:”e937227863752975″},”Msg”:{“FromUserName”:”yongboy”,”ToUserName”:”hehe057854″,”Type”:1,”Content”:”hello”,”ClientMsgId”:1393988414380,”LocalID”:1393988414380}}
相应内容：
{“BaseResponse”: {“Ret”: 0,”ErrMsg”: “”},”MsgID”: 1020944348,”LocalID”: “1393988414380”}
再次发起一个POST请求，用于申请最新SyncKey
https://webpush.weixin.qq.com/cgi-bin/mmwebwx-bin/webwxsync?sid=lQ95vHR52DiaLVqo&r=1393988414756
发送内容：
{“BaseRequest”:{“Uin”:937355,”Sid”:”lQ95vHR52DiaLVqo”},”SyncKey”:{“Count”:6,”List”:[{“Key”:1,”Val”:620944310},{“Key”:2,”Val”:620944346},{“Key”:3,”Val”:620944344},{“Key”:11,”Val”:620942796},{“Key”:201,”Val”:1393988357},{“Key”:1000,”Val”:1393930108}]},”rr”:1393988414756}
响应的（部分）内容：
“SKey”: “8F8C6A03489E85E9FDF727ACB95C93C2CDCE9FB9532FC15B”
终止GET长连接，使用最新SyncKey再次发起一个新的GET长连接
https://webpush.weixin.qq.com/cgi-bin/mmwebwx-bin/synccheck?callback=jQuery1830245810089652082181393988305564&r=1393988415015&sid=lQ95vHR52DiaLVqo&uin=937355&deviceid=e937227863752975&synckey=1620944310%7C2620944348%7C3620944344%7C11620942796%7C2011393988357%7C10001393930108&=1393988415016
微信多点登陆
IM产品的多点登陆逻辑特别复杂，很难做到很好的用户体验。微信最开始并不支持多点登陆，后来陆续增加的Web版、Mac版，但并不是完整意义的客户端，要说只是辅助工具。微信允许：一个移动端(下面称之为主客户端) + 一个web/mac 同时在线(下面称之为从客户端)，web/mac 只能接收在线消息、发消息，不记录消息历史。这样多点逻辑就变得相对简单很多了。
1）存储
服务器不用保存完整消息历史，通过客户端对push消息的ack保证消息送达，协议保证消息至少一次推送到主客户端，然后消息即可删除；服务器只存储未下发到主客户端的消息。
多点时：主客户端依然采用Push推送消息(只是应该会保留一小段时间消息记录等待从Sync)，从客户端Sync消息；如果主不在线，消息记录不会删除，等主重新连上下载离线消息。
服务器不存储消息历史，一个是安全，再者节省硬件成本，大量短消息的存储和读取成本是非常高的，因为基本都是随机IO。whatapp 用500台机器，支撑1亿在线，100w/s 消息，只离线消息存储量是很少的。
2）未读数同步
这个很好解决，如果客户端知道自己处于多端在线情况下时，进入会话时，需要告诉服务器消息已读。消息已读也保存为一条消息，再通过Sync协议，同步到另外的客户端。web 微信会调用webwxstatusnotify 同步未读。未读变化也当成一条消息存储，且只在多端情况下存在，单点在线时未读数由客户端维护。
3）删除消息
不管是否多点在线任何删除消息操作都会同步到服务器，避免删除的消息下次有不小心同步回来了，服务器可能及时删除、也可能长期保存，客户端每次上报就没错了。移动客户端消息删除不会同步到 web版。
4）自己同步自己
每个操作(发消息、清未读等)，应答后，因为SyncKey 变化了，Sync协议上会产生一个空的Sync操作用于更新SyncKey。对于主客户端：
单点在线时，SyncKey通过应答，节省同步流量。
多点在线时，发消息和从客户端一样，也会自己同步自己。
来源：标点符
微信开发协议三:微信小程序开发教程！
备注
微信应用开放的服务和组件包含如下：
视图容器：视图(View)、滚动视图、Swiper
基础内容：图标、文本、进度条
表单组件：按钮、表单等等
操作反馈
导航
媒体组建：音频、图片、视频。
地图
画布
文件操作能力
网络：上传下载能力、WebSocket
数据：数据缓存能力
位置：获取位置、查看位置
设备：网络状态、系统信息、重力感应、罗盘
界面：设置导航条、导航、动画、绘图等等
开放接口：登录，包括签名加密，用户信息、微信支付、模板消息
审核：
根据《微信小程序平台服务协议》，里面有关描述如下：
2.4 为确保微信小程序平台、微信公众平台、其他用户等各方的安全、稳定及良好的用户体验，腾讯将对需要发布的小程序进行发布审核。
“发布审核”是指由用户发起，将其完成初始化开发的小程序提交至腾讯，由腾讯自行或委托第三方对该小程序的合法性、合理性、安全性、稳定性、可操作性、用户体验等各方面，采用包括但不限于开发信息核对、安全测试、UI测试、随机测试、动态测试、安全测试等方式，进行审查、甄别、试验与评估的过程。发布审核结果包括审核通过与审核不通过两种。审核不通过的，该小程序将无法发布。
之后小程序的审核极有可能采取和App store类似的策略，但相比微信其他平台的审核，各位严格和复杂。
教程：
微信应用号（小程序，「应用号」的新称呼）终于来了！
目前还处于内测阶段，微信只邀请了部分企业参与封测。想必大家都关心应用号的最终形态到底是什么样子？怎样将一个「服务号」改造成为「小程序」？
我们暂时以一款简单的第三方工具的实例，来演示一下开发过程吧。
OK，为了让大家尽快看到这份教程，博卡君注定要熬夜了！今晚开始更新，希望明天一早就能发布第一篇教程！记录开始！看看几天能完成变身吧！
序言
开始开发应用号之前，先看看官方公布的「小程序」教程吧！（以下内容来自微信官方公布的「小程序」开发指南）
本文档将带你一步步创建完成一个微信小程序，并可以在手机上体验该小程序的实际效果。这个小程序的首页将会显示欢迎语以及当前用户的微信头像，点击头像，可以在新开的页面中查看当前小程序的启动日志。
1. 获取微信小程序的 AppID
首先，我们需要拥有一个帐号，如果你能看到该文档，我们应当已经邀请并为你创建好一个帐号。注意不可直接使用服务号或订阅号的 AppID。 利用提供的帐号，登录 https://mp.weixin.qq.com ，就可以在网站的「设置」-「开发者设置」中，查看到微信小程序的 AppID 了。
注意：如果我们不是用注册时绑定的管理员微信号，在手机上体验该小程序。那么我们还需要操作「绑定开发者」。即在「用户身份-开发者」模块，绑定上需要体验该小程序的微信号。本教程默认注册帐号、体验都是使用管理员微信号。
2. 创建项目
我们需要通过开发者工具，来完成小程序创建和代码编辑。
开发者工具安装完成后，打开并使用微信扫码登录。选择创建「项目」，填入上文获取到的 AppID，设置一个本地项目的名称（非小程序名称），比如「我的第一个项目」，并选择一个本地的文件夹作为代码存储的目录，点击「新建项目」就可以了。
为方便初学者了解微信小程序的基本代码结构，在创建过程中，如果选择的本地文件夹是个空文件夹，开发者工具会提示，是否需要创建一个 quick start 项目。选择「是」，开发者工具会帮助我们在开发目录里生成一个简单的 demo。
项目创建成功后，我们就可以点击该项目，进入并看到完整的开发者工具界面，点击左侧导航，在「编辑」里可以查看和编辑我们的代码，在「调试」里可以测试代码并模拟小程序在微信客户端效果，在「项目」里可以发送到手机里预览实际效果。
3. 编写代码
点击开发者工具左侧导航的「编辑」，我们可以看到这个项目，已经初始化并包含了一些简单的代码文件。最关键也是必不可少的，是 app.js、app.json、app.wxss 这三个。其中，.js 后缀的是脚本文件，.json 后缀的文件是配置文件，.wxss 后缀的是样式表文件。微信小程序会读取这些文件，并生成小程序实例。
下面我们简单了解这三个文件的功能，方便修改以及从头开发自己的微信小程序。
app.js 是小程序的脚本代码。我们可以在这个文件中监听并处理小程序的生命周期函数、声明全局变量。调用 MINA 提供的丰富的 API，如本例的同步存储及同步读取本地数据。
//app.js
App({
onLaunch: function () {
//调用API从本地缓存中获取数据
var logs = wx.getStorageSync("logs") || []
logs.unshift(Date.now())
wx.setStorageSync("logs", logs)
},
getUserInfo:function(cb){
var that = this;
if(this.globalData.userInfo){
typeof cb == "function" && cb(this.globalData.userInfo)
}else{
//调用登录接口
wx.login({
success: function () {
wx.getUserInfo({
success: function (res) {
that.globalData.userInfo = res.userInfo;
typeof cb == "function" && cb(that.globalData.userInfo)
}
})
}
});
}
},
globalData:{
userInfo:null
}
})
app.json 是对整个小程序的全局配置。我们可以在这个文件中配置小程序是由哪些页面组成，配置小程序的窗口 背景色，配置导航条样式，配置默认标题。注意该文件不可添加任何注释。
{
"pages":[
"pages/index/index",
"pages/logs/logs"
],
"window":{
"backgroundTextStyle":"light",
"navigationBarBackgroundColor": "#fff",
"navigationBarTitleText": "WeChat",
"navigationBarTextStyle":"black"
}
}
app.wxss 是整个小程序的公共样式表。我们可以在页面组件的class属性上直接使用app.wxss中声明的样式规则。
/**app.wxss**/
.container {
height: 100%;
display: flex;
flex-direction: column;
align-items: center;
justify-content: space-between;
padding: 200rpx 0;
box-sizing: border-box;
}
3. 创建页面
在这个教程里，我们有两个页面，index 页面和 logs 页面，即欢迎页和小程序启动日志的展示页，他们都在 pages 目录下。微信小程序中的每一个页面的【路径+页面名】都需要写在 app.json 的 pages 中，且 pages 中的第一个页面是小程序的首页。
每一个小程序页面是由同路径下同名的四个不同后缀文件的组成，如：index.js、index.wxml、index.wxss、index.json。.js 后缀的文件是脚本文件，.json 后缀的文件是配置文件，.wxss 后缀的是样式表文件，.wxml 后缀的文件是页面结构文件。
index.wxml是页面的结构文件：
<view class="container">
<viewbindtap="bindViewTap" class="userinfo">
<image class="userinfo-avatar" src="{{userInfo.avatarUrl}}" background-size="cover"></image>
<text class="userinfo-nickname">{{userInfo.nickName}}</text>
</view>
<view class="usermotto">
<text class="user-motto">{{motto}}</text>
</view>
本例中使用了 <view/>、<image/>、<text/>来搭建页面结构，绑定数据和交互处理函数。
index.js 是页面的脚本文件，在这个文件中我们可以监听并处理页面的生命周期函数、获取小程序实例，声明并处理数据，响应页面交互事件等。
//index.js
//获取应用实例
var app = getApp()
Page({
data: {
motto: "Hello World",
userInfo: {}
},
//事件处理函数
bindViewTap: function() {
wx.navigateTo({
url: "../logs/logs"
})
},
onLoad: function () {
console.log("onLoad")
var that = this
//调用应用实例的方法获取全局数据
app.getUserInfo(function(userInfo){
//更新数据
that.setData({
userInfo:userInfo
})
})
}
})
index.wxss是页面的样式表：
/**index.wxss**/
.userinfo {
display: flex;
flex-direction: column;
align-items: center;
}
.userinfo-avatar {
width: 128rpx;
height: 128rpx;
margin: 20rpx;
border-radius: 50%;
}
.userinfo-nickname {
color: #aaa;
}
.usermotto {
margin-top: 200px;
}
页面的样式表是非必要的。当有页面样式表时，页面的样式表中的样式规则会层叠覆盖 app.wxss 中的样式规则。如果不指定页面的样式表，也可以在页面的结构文件中直接使用 app.wxss 中指定的样式规则。
index.json是页面的配置文件：
页面的配置文件是非必要的。当有页面的配置文件时，配置项在该页面会覆盖 app.json 的 window 中相同的配置项。如果没有指定的页面配置文件，则在该页面直接使用 app.json 中的默认配置。
logs的页面结构
<!--logs.wxml-->
<view class="container log-list">
<block wx:for-items="{{logs}}" wx:for-item="log">
<text class="log-item">{{index + 1}}. {{log}}</text>
</block>
</view>
logs 页面使用 <block/> 控制标签来组织代码，在 <block/> 上使用 wx:for-items 绑定 logs 数据，并将 logs 数据循环展开节点
//logs.js
var util = require("../../utils/util.js")
Page({
data: {
logs: []
},
onLoad: function () {
this.setData({
logs: (wx.getStorageSync("logs") || []).map(function (log) {
return util.formatTime(new Date(log))
})
})
}
})
运行结果如下：
4. 手机预览
开发者工具左侧菜单栏选择「项目」，点击「预览」，扫码后即可在微信客户端中体验。
目前，预览和上传功能尚无法实现，需要等待微信官方的下一步更新。
如你所见，微信官方给出的开发指南还非常简单，很多细节、代码和功能都没有明确的展示，所以接下来就到博卡君展示实力的时候啦！开发教程正式开始！
第一章：准备工作
做好准备工作很重要。开发一个微信应用号，你需要提前到微信的官方网站（weixin.qq.com）下载开发者工具。
1. 下载最新微信开发者工具，打开后你会看到该界面：
2. 点击「新建 web+」项目，随后出现如下画面：
3. 该页面内的各项内容需要注意——
AppID：依照官方解释来填。
Appname: 项目最外层文件夹名称，如你将其命名为「ABC」，则之后的全部项目内容均将保存在「/ABC/…」目录下。
本地开发目录：项目存放在本地的目录。
注：再次强调，如果你和团队成员共同开发该项目，则建议你们使用同样的目录名称及本地目录，以确保协同开发的统一性。如果你之前已有项目，则导入过程与以上内容近似，不再赘述。
4. 准备工作全部完成后，点击「新建项目」按钮，弹出框点「确定」。
5. 如上图所示，此刻，微信开发者工具已经为你自动构建了一个初始的 demo 项目，该项目内包含了一个微信应用项目所需具备的基本内容和框架结构。点击项目名称（图中即「cards」）进入该项目，就能看到整个项目的基本架构了：
第二章：项目构架
微信目前用户群体非常庞大，微信推出公众号以后，火爆程度大家都看得到，也同样推动着 Html 5 的高速发展，随着公众号业务的需求越来越复杂，应用号现在的到来也是恰到好处。
博卡君发现，微信提供给开发者的方式也在发生全面的改变：从操作 DOM 转为操作数据，基于微信提供的一个过桥工具实现很多 Html 5 在公众号很难实现的功能，有点类似于 hybrid 开发，不同于 hybrid 开发的方式是：微信开放的接口更为严谨，结构必须采用他提供给的组件，外部的框架和插件都不能在这里使用上，让开发者完全脱离操作 DOM，开发思想转变很大。
工欲善其事，必先利其器。理解它的核心功能非常重要，先了解它的整个运作流程。
生命周期：
在index.js里面：
开发者工具上 Console 可以看到：
在首页 console 可以看出顺序是 App Launch-->App Show-->onLoad-->onShow-->onReady。
首先是整个 app 的启动与显示，app 的启动在 app.js 里面可以配置，其次再进入到各个页面的加载显示等等。
可以想象到这里可以处理很多东西了，如加载框之类的都可以实现等等。
路由：
路由在项目开发中一直是个核心点，在这里其实微信对路由的介绍很少，可见微信在路由方面经过很好的封装，也提供三个跳转方法。
wx.navigateTo(OBJECT)：保留当前页面，跳转到应用内的某个页面，使用wx.navigateBack可以返回到原页面。
wx.redirectTo(OBJECT)：关闭当前页面，跳转到应用内的某个页面。
wx.navigateBack()：关闭当前页面，回退前一页面。
这三个基本上使用足够，在路由方面微信封装的很好，开发者根本不用去配置路由，往往很多框架在路由方面配置很繁琐。
组件：
此次微信在组件提供方面也是非常全面，基本上满足项目需求，故而开发速度非常快，开发前可以认真浏览几次，开发效率会很好。
其它：
任何外部框架以及插件基本上无法使用，就算原生的 js 插件也很难使用，因为以前的 js 插件也基本上全部是一操作 dom 的形式存在，而微信应用号此次的架构是不允许操作任何 dom，就连以前开发者们习惯使用的动态设置的rem.js也是不支持的。
此次微信还提供了 WebSocket，就可以直接利用它做聊天，可以开发的空间非常大。
跟公众号对比博卡君发现，开发应用号组件化，结构化，多样化。新大陆总是充满着惊喜，更多的彩蛋等着大家来发现。
接下来开始搞一些简单的代码了！
1. 找到项目文件夹，导入你的编辑器里面。在这里，博卡君使用了 Sublime Text 编辑器。你可以根据自己的开发习惯选择自己喜欢的编辑器。
2. 接下来，你需要根据自己的项目内容调整项目结构。在范例项目中，「card_course」目录下面主要包含了「tabBar」页面以及该应用的一些配置文件。
3. 示例项目的「tabBar」是五个菜单按钮：
4. 找到「app.json」文件，用来配置这个五个菜单。在代码行中找到「tabBar」：
你可以根据实际项目需求更改，其中：
「Color」是底部字体颜色，「selectedColor」是切换到该页面高亮颜色，「borderStyle」是切换菜单上面的一条线的颜色，「backgroundColor」是底部菜单栏背景颜色。文字描述较为抽象，建议你一一调试并查看其效果，加深印象。
「list」下的代码顺序必须依次放置，不能随便更改。
「pagePath」之后的文件名内，「.wxml」后缀被隐藏起来了，这是微信开发代码中人性化的一点——帮你节约写代码的时间，无须频繁声明文件后缀。
「iconPath」为未获得显示页面的图标路径，这两个路径可以直接是网络图标。
「selectedIconPath」为当前显示页面高亮图标路径，可以去掉，去掉之后会默认显示为「iconPath」的图标。
「Text」为页面标题，也可以去掉，去掉之后纯显示图标，如只去掉其中一个，该位置会被占用。
注意：微信的底部菜单最多支持五栏（五个 icons），所以在你设计微信应用的 UI 和基本架构时就要预先考虑好菜单栏的排布。
5. 根据以上代码规则，博卡君做好了示例项目的基本架构，供你参考：
6. 「Json」文件配置好后，「card_course」的基本结构入上图所示，不需要的子集都可以暂时删除，缺少的子集则需要你主动新建。删除子集时记得顺带检查一下「app.json」里的相关内容是否已经一并删除。
注意：博卡君个人建议你新建一个「wxml」文件的同时，把对应的「js」和「wxss」文件一起新建好，因为微信应用号的配置特点就是解析到一个「wxml」文件时，会同时在同级目录下找到同文件名的「js」和「wxss」文件，所以「js」文件需及时在「app.json」里预先配置好。
编写「wxml」时，根据微信应用号提供的接口编码即可，大部分就是以前的「div」，而现在就用「view」即可。需要用其它子集时，可以根据微信提供的接口酌情选择。
使用「class」名来设置样式，「id」名在这里基本没有什么用处。主要操作数据，不操作「dom」。
7. 以上是示例项目首页的「wxml」编码。从图中就可以看出，实现一个页面代码量非常少。
8. 「Wxss」文件是引入的样式文件，你也可以直接在里面写样式，示例中采用的是引入方式：
9. 修改代码后刷新一次，可以看到未设背景的「view」标签直接变成了粉色。
注意：修改「wxml」和「wxss」下的内容后，直接 F5 刷新就能直接看到效果，修改「js」则需点击重启按钮才能看到效果。
10. 另外，公共样式可以在「app.wxss」里直接引用。
11. 「Js」文件需要在「app.json」文件的「page」里预先配置好。为了项目结构清晰化，博卡君在示例项目中的「index」首页同级目录新建其它四个页面文件，具体如下：
经过以上步骤，案例中的五个底部菜单就全部配置完毕了。
