大模型开启AI新范式, AIGC掀起行业新浪潮。 “2023京东寰球科技探索者大会暨京东云峰会” ，将于7月13日在北京举办。 本次大会，以 “逾越·产业智能” 为主题，聚焦大模型与产业深度交融，将重磅公布京东大模型，推出新一代数字基础设施，降级产品及解决方案，致力于服务千行百业逾越产业新智能。 新视角，新产品，新单干。本次大会，除上午主论坛外，下午并行京东技术实际、数字基础设施、数智批发、衰弱科技、供应链金融科技、物流数智时空、数字城市、数智金融、京东科技生态、数据智能10大专题论坛。 7月13日， “2023京东寰球科技探索者大会暨京东云峰会” ，用科技点燃产业烟火，用实干推动产业智能，京东邀请您从这里“逾越·产业智能”。
一 背景往年的618大促曾经如期而至，接下来我会从技术的角度，跟大家聊聊大促备战的底层逻辑和实战计划，心愿可能解答大家心中的一些纳闷。 首先，618大促为什么如此重要呢？先从数据的角度简略做一下剖析，以下表格列举了咱们历年大促GMV成绩单： 年份618销售额（亿元）年销售额（亿元）618销售额占比202237933315511.4%202134393297010.4%202026942612510.3%20192017208549.7%20181592167699.5%依据以上数据统计，咱们能够得出结论：每年的618大促销售额约占全年销售额的10%左右。以2022年618大促销售额为例，大促期间，每分钟的销售额均匀高达1463万元。因而，从技术角度来看，保障服务的稳定性是至关重要的。置信这些数据能够为您在大促期间制订工作优先级和做出决策提供有价值的参考。 二 挑战大促期间零碎的稳定性对于业务的失常经营如此重要，咱们须要探讨以下问题： • 影响零碎稳定性的因素都有哪些？ • 稳定性要求与日常对系统的高可用要求有哪些不同之处？ • 面对各种不稳固因素，咱们应该如何应答？ 上面咱们一起来剖析和探讨这些问题。 1. 影响零碎稳定性的因素有以下几个方面： • 流量大小：大促期间，流量往往是平时的几倍甚至几十倍，这对系统的稳定性提出了极高的要求，一个小问题，在流量放大后，往往调演变成大问题； • 数据量大：以2022年的订单为例，订单额达到了3.4万亿，在海量订单数据的场景下，一个简略的查问，都会变得十分具备挑战； • 场景简单：各类促销优惠、平台、商家、经营等各种营销玩法的叠加，使订单生产链路始终处于高负荷运算状态； • 交付链路长：各端的流量散发、促销计算、加车、结算、提单、领取、物流配送、客服、售后等各个流程节点都须要保持稳定。如果一个服务99.9%的可用率，那么100个相干服务节点组合起来，可用率就只能达到99.5%了，而那0.5%的不可用，对应的都是大量的订单散失； • 容忍度低：消费者要求良好的用户体验，商家须要促销疾速失效，平台则要缩小谬误和资损，爱护消费者和商家的利益。更高的冀望和关注，带来的是更低的急躁和容忍度； 2. 在大促期间，对系统的稳定性要求更高，但与平时对系统的高可用性要求不同。这次要体现在以下几个方面： • 工夫紧迫：大促期间须要在短时间内保障服务的稳定性，通常没有工夫深刻技术细节； • 视角不同：稳定性重视整体业务成果，而高可用性重视服务响应后果； • 维度不同：实现业务稳定性保障通常是建设在零碎高可用性的根底之上，并配合相干的服务经营策略，以实现更高维度的业务稳定性。 3. 接下来将重点围绕备战大促的相干思路和教训进行开展，以帮忙您应答挑战并确保零碎的稳定性。 三 稳定性保障以下列举了往年大促备战的局部措施： 上图里展现的各种备战我的项目，有方向性的领导，有流程上的标准，有落地层面的要求。上面我将从更细粒度的零碎执行层面登程，提供一些备战策略。 正如前文提到的，大促期间的稳定性保障个别属于应急策略。目标是在保证系统稳定性的前提下，对问题的疾速响应。咱们将从利用、存储、经营三个视角，来探讨零碎稳定性保障的应急措施。 3.1 利用视角3.1.1 单元化单元化部署是将利用拆分成多个独立的单元进行独立部署，有以下益处： • 升高整个利用因某个单元故障而导致服务中断的危险； • 升高故障排查的难度，因为能够疾速定位出问题的单元并进行修复； • 每个单元都能够独立保护和降级，这样能够升高整个利用因某个单元降级或保护而导致服务中断的危险； • 每个单元都能够独立扩大和缩减，这样能够依据理论需要动静调整利用的规模。 为了保障服务的可靠性，咱们须要在备战层面实现异地多活的能力，即要求服务进行异地多机房部署。思考到异地跨机房调用的网络延时问题（例如北京到上海的往返网络延时大概为12毫秒），黄金交易链路的所有服务都须要本地单元化部署。因而，倡议采纳本地单元化优先的部署架构，并与其余异地单元化互为灾备。 另外，也要留神流量负载平衡策略，防止出现分组的调用流量不平衡，造成局部分组因流量歪斜，导致性能体现不佳的状况呈现； 3.1.2 监控预警预防和发现问题的最间接形式，须要关注以下几个方面： • 监控粒度方面：监控依照层级分为底层中间件监控、依赖RPC监控、办法监控、机器监控、系统监控、业务监控、流程监控、整体的大盘监控； • 监控的灵敏度问题。灵敏度过低会导致局部问题被延时裸露甚至被暗藏，而灵敏度过高则会造成信息爆炸，难以分辨信息的主次。因而，在施行监控前须要提前做好功课，确定适合的灵敏度； • 监控的覆盖度方面：关注监控服务单元、监控指标梳理、监控触达办法。比方：监控须要笼罩容器数、资源指标、运行环境（JVM、线程池）、流量大小、限流值、上下游依赖、超时时长、异样日志、数据容量、模型规模、特色数量等，并能够进行工夫维度的纵向比照； • 监控的准确性方面：看可用率，须要看上游调用方的，可能200ms响应时长，对与调用方来说，曾经属于不可用的区间了。看CPU忙碌水平，不能只盯着利用率，还要联合容器核数和CPU负载来剖析； • 预警解除方面：接到预警音讯，及时排查并解决危险，切不可将小问题演变成大问题。先确认是单机硬件或网络问题，还是集群通用问题，如果是通用问题，是否通过服务调用链追踪技术疾速定位问题点，确认好问题起因，能力做好应答预案； 3.1.3 日志打印日志格局、日志级别、输入形式，归档策略，序列化形式，traceId策略等都须要进行正当设置，特地要限度反复日志和有效日志的输入，缩小日志对机器资源的占用。比方：业务异样堆栈日志不倡议间接打印，通过状态码统计后果就能够了； 3.1.4 疾速失败可能疾速地检测和响应故障，帮忙服务更快地恢复正常状态，从而进步零碎的可用性和稳定性。实现疾速失败，常见的技术手段如下： ...
在企业业务畛域，锦礼是针对福利、营销、激励等员工洽购场景的一站式解决方案，蕴含面向员工、会员等弹性激励SAAS平台。因为其间接面向公司整体员工，其服务的高可用尤其重要，本文将介绍锦礼商城大促前夕，通过混沌工程实战演习，升高利用的MTTR。 MTTR（均匀复原工夫）是从产品或系统故障中复原所需的均匀工夫。 这包含整个中断工夫——从零碎或产品呈现故障到其复原齐全运行为止。 如何在混沌演练的场景中升高利用的MTTR，必须须要依据监控定位，而后人工进行反馈进行解决吗？是否能够自动化，是否有计划能够升高混沌演练过程中的影响？以此达到疾速止血，进一步提高零碎的稳定性。 本篇文章将依据一些思考和实际来解答以上问题。 故障无处不在，而且无奈防止。咱们将从宿主机重启问题以及底层服务混沌演练的排查与动作说起。 背景【客户端视角】：呈现大量接口（包含提单）超时报错、可用率跳点，局部客户命中，产生客诉。 通过定位发现大促备战后期宿主机重启及底层服务混沌演练起因，较长时间影响我侧零碎可用率及性能。尤其是外围接口的部署利用，会大范畴的影响到多个接口的可用率，进一步影响洽购端客户的体验问题。 特地在TOB畛域，自身就存在大客户的口碑效应，如果恰好头部客户碰到该问题，那么极易被放大和激化。 长期动作一方面协同运维组确认宿主机重启未及时告诉的状况，另一方面与底层服务提供者同步演练影响，倡议其恪守演练准则最小化爆炸半径，管制影响范畴，保障演练是可控的。 除了以上协同内部的状况外，咱们外部也产生了思考，首先状况故障自身就是不可控的，无论宿主机还是混沌演练，实在场景也是有概率产生的（并且已产生）。那么咱们只能通过监控定位，而后手动摘除机器或者告诉服务提供者解决吗？是否能够自动化，是否有计划能够升高影响？以此达到疾速止血，进一步提高零碎的稳定性。 长期计划——JSF中间件能力实际既然无奈防止故障，那么就拥抱故障，通过一些技术手段来构建获取利用故障的能力，从而保障利用的高可用。 因为外部的调用90+%为（JSF）RPC调用，所以咱们还是把眼光放到了JSF中间件的容错能力上，以下次要介绍通过JSF中间件的超时与重试、自适应负载平衡、服务熔断来进行故障转移的实践与实际。 实际是测验真谛的唯一标准。对于超时和重试理论开发过程中，置信大家也见过太多因为超时未设置、设置有误导致的故障。当超时未设置或者设置不合理，会导致申请响应变慢，慢申请的一直累计叠加，就会引起连锁反应，甚至产生利用雪崩。 不仅咱们本身的服务，还有内部的依赖服务，不仅HTTP服务，还是中间件服务，都应该设置正当的超时重试策略，并且器重起来。 首先读写服务的超时重试策略也是大不相同的，读服务天生适宜重试（如设置正当超时工夫后重试两次），然而写服务大多是不能重试的，不过如果均是幂等设计，也是能够的。 另外设置调用方的超时工夫之前，须要先理解分明依赖服务的TP99响应工夫是多少（如果依赖服务性能稳定大，也能够看TP95），调用方的超时工夫能够在此基础上加50%Buff。当然服务的响应工夫并不是恒定的，在某些长尾条件下可能须要更多的计算工夫，所以为了有足够的工夫期待这种长尾申请响应，咱们须要把超时设置足够正当。 最初重试次数不宜太多（高并发时可能引发一系列问题（个别2次，最多3次），尽管重试次数越大，服务可用性越高，然而高并发状况下会导致多倍的申请流量，相似模仿DDOS攻打，重大状况下甚至于减速故障的连锁产生。因而超时重试最好是和熔断、疾速失败等机制配合应用，成果更佳，这个前面会提到。 除了引入伎俩，重要的是验证伎俩的有效性。模仿场景（后续另两个伎俩也是用该场景）计划：采纳故障注入（50%机器网络提早3000-5000ms）的形式模仿相似场景，并验证。 机器部署如下： 压测接口（QPS-300）及故障接口监控Key值： 1、压测接口：jdos_b2b2cplatform.B2b2cProductProviderImpl.queryProductBpMap 2、服务生产：jdos_b2b2cplatform.ActivityConfigServiceRPCImpl.queryActivityConfig 3、服务提供：jdos_b2b2cshop.com.jd.ka.b2b2c.shop.service.impl.sdk.ActivityConfigServiceImpl.queryActivityConfig 【留神】 网络场景不反对如下情景： 1、利用容器所在机房：lf04, lf05, lf07, ht01, ht02, ht05, ht07, htmysql, lfmysql02, yn02, hk02, hk03 2、物理机的内核版本：2.6x, 3.8x, 3.10x 失常状况（未注入故障） 注入故障——超时设置不合理状况下（超时2000ms，重试2） 注入故障——超时设置正当状况下（超时10ms，重试2）该接口TP99在6ms，设置超时10ms，重试2。即：jsf:methodname="queryActivityConfig"timeout="10"retries="2"/ 超时重试小结通过正当的超时重试，整体申请安稳，重试后的故障转移，大幅晋升接口可用率。 超时重试补充在接口维度拆分不合理的状况下，咱们能够更细粒度的应用办法维度的超时重试配置，不过这里有一个留神项JSF以后注解形式不反对办法维度的超时重试设置，仅反对接口维度，如已应用注解类，可进行迁徙XML形式进行配置应用， 对于自适应负载平衡对于shortestresponse自适应负载平衡设计目标是解决在 provider 节点能力不均的场景下，让解决能力较弱的provider少承受些流量，不会因个别性能较差的 provider 影响到 consumer 整体调用的申请耗时和可用率。 能者多劳拙者闲，智者多忧愚者无所虑。然而该策略下也是存在一些问题的： 流量的适度集中高性能实例，服务提供者的单机限流或成为瓶颈。response的工夫长短有时也并不能代表机器的吞吐能力。大多数的场景下，不同provider的response时长在没有非常明显的区别时，shortestresponse同random（随机）。现有的shortestresponse的实现机制，相似P2C（Power of Two Choice）算法，不过计算形式不是采纳以后正在解决的连接数，而是默认随机抉择两个服务提供者参加最快响应比拟计算，即：统计申请每个provider的申请耗时、访问量、异样量、申请并发数，比拟均匀响应工夫 * 以后申请数，用于最快响应负载计算。选取优胜者来防止羊群效应。以此自适应的掂量 provider 端机器的吞吐能力，而后将流量尽可能调配到吞吐能力高的机器上，进步零碎整体服务的性能。 <jsf:consumer id="activityConfigService" interface="com.jd.ka.b2b2c.shop.sdk.service.ActivityConfigService" alias="${jsf.activityConfigService.alias}" timeout = "3000" filter="jsfLogFilter,jsfSwitchFilter" loadbalance="shortestresponse"> <jsf:method name="queryActivityConfig" timeout="10" retries="2"/> </jsf:consumer>注入故障（设置自适应负载平衡） ...
明天咱们官宣一件小事：京东云开启中国云市场的首次公开比价流动，承诺“买贵就赔”！ 比价流动的底气，来源于京东云对技术降本的不懈谋求——京东二十年来大规模的场景实际，推动京东云继续加大自研技术投入，进步资源利用率，进而最大化降低成本。往年3月，京东云负责人在京东云城市峰会广州站上提出，极致性价比是下一代数字基础设施所必备的重要特色。 恰逢京东618行将开启，京东云此举将进一步升高用云门槛，助力中小企业在数字化降级过程中降本增效。
作者：京东批发 戴旭 京东小程序是一个凋谢技术平台，正在被越来越多的头部品牌抉择，用于站内私域流量的营销和经营。诸如各种日化、奢侈品等品牌对ARVR有较多的诉求，心愿京东小程序引擎提供一些底层能力，叠加品牌自主的个性化开发和定制，以反对更加丰盛的场景和玩法，比方AR试妆、试戴等。咱们小程序引擎联结ARVR团队，在单方产研测的致力和合作下，实现了相干能力的设计和开发。整体性能于京东APP11.6.6版本公布上线，期待为更多的商家和品牌赋能。 体验门路和成果（负责相干模块的产品小姐姐情谊录屏） 技术计划这里以人脸识别为例，先介绍整体的技术计划。 概念介绍技术关键词：相机、实时帧、AR算法、同层渲染、WebGL。 这几个关键词外面，前三个比拟好了解，人脸识别，会用相机采集人脸的实时帧数据，调用AR算法，获取计算结果，把数据传输给小程序前端。 前面两个关键词和小程序的场景有关系，WebGL技术是小程序为了反对游戏、ARVR等高性能渲染的需要，采纳原生的OpenGL实现了一套WebGL的接口。小程序页面是WebView渲染，而咱们既然提到了采纳OpenGL原生渲染，就须要把原生组件，正确的插入到Web的视图层级，同层渲染就是将原生组件和WebView DOM 元素放在一起进行混合渲染的技术，可能保障原生组件和 DOM 元素在渲染层级、滚动、触摸事件处理等方面保持一致。 总体流程小程序引擎在底层原生反对了相机、实时帧、AR、WebGL等能力，同时裸露了若干 js 的api。小程序开发者通过相干api的调用，执行开启相机、获取实时帧数据，调用AR接口，获取计算结果数据，进行WebGL渲染等操作。简要的流程如下： 分层设计从分层的角度看整个技术计划的设计，大抵如下： 其中在AR引擎这一层，分为内置和内部AR引擎，也是因为小程序自身是凋谢的技术平台，咱们采纳了接口协议化的设计，反对第三方宿主采纳自主的AR引擎，同时提供了相机、实时帧、WebGL等原子化能力，小程序服务商能够构建专有的AR引擎为下层业务赋能。 技术挑战WebGL技术原理的篇幅过大，它也不仅仅是为了ARVR这个场景服务，所以包含AR算法之内，都不在本篇的具体介绍范畴之内。 在这部分，咱们专一于小程序和ARVR叠加的畛域：内存和帧率的优化。 咱们晓得在观赏电视和电影画面时，只有画面刷新率达到24帧/秒，就能满足人们的需要，也就是说咱们至多要在中端甚至中低端的机器上达到24帧以上的帧率。 为了保障根本的画质，相机实时帧的分辨率设置为1280*720，以RBGA格局存储，那么每一帧的数据是1280*720*4=3686400Byte，约3.5MB，每秒24帧以上的帧率，这个是不小的数据量。总的来说，在性能优化上，咱们遇到的次要挑战如下： 挑战1，数据从原生传输到js，在从js传递到原生，如此大的数据量将会成为js和原生通信的瓶颈； 挑战2，在iOS平台上，相机output只能指定BGRA格局，因为原始相机实时帧 CMSampleBufferRef对象内蕴含CVPixelBuffer对象，CoreVideo对象不反对RGBA格局，参考官网文档 https://developer.apple.com/library/archive/qa/qa1501/_index.... 而WebGL规范的接口不反对BGRA格局，参考文档： https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderi...，数据格式的转换会减轻性能的累赘； 挑战3，即使以24帧为规范，每一帧的解决工夫大概只有41ms，须要经验原生相机生产、数据格式转换、数据双向传输、ar算法、webgl绘制等流程，每一环节都很重，咱们须要思考如何利用并发调度劣势，并且保障实时帧的时序不会产生错乱，因为时序一旦乱了，影像尽管始终在输入，然而视觉感触是凌乱的。 针对上述挑战，进行了一系列的优化，最终在中低端手机（iPhone8 Plus）上达到均匀26~27帧的帧率，整体体验较为晦涩，具体调优上面具体介绍。 性能调优1、数据传输优化原生和js之间传输大量的数据会成为性能的瓶颈，数据传输优化就是缩小数据传输频次，最好是数据保留一份，只传递数据的标记。 咱们设计了一个NativeBuffer缓存来优化这个问题。次要流程如下 然而在js环境中，最终还是要应用js对象，原生相机实时帧的数据须要被转换为js对象。那么如何做能力让数据只保留一份呢？ NO COPY iOS端抉择运行小程序的js框架是JavaScriptCore，JavaScriptCore提供了一些C语言的接口办法，能够以NO COPY的形式，把一个void类型的二进制数据指针作为backing store，创立绝对应的js对象，个别类型是ArrayBuffer或者TypeArray。也就是说原生和js对象背地的数据是同一份，共享这部分内存。 这样一来咱们只须要保障缓存的原始相机实时帧的数据不开释，那么js对象援用的这部分数据就会始终无效。那这部分数据要在什么时候去清理呢？ 销毁 在创立js对象的时候，能够指定一个C的函数指针作为入参。当JavaScriptCore检测到这个js对象销毁的时候，会主动触发该C函数的调用。咱们须要依照指定的函数原型实现一个C的办法，在这个函数里去做缓存的清理，能够看一下这个函数的原型： typedef void (*JSTypedArrayBytesDeallocator)(void* bytes, void* deallocatorContext);该函数有2个参数，第一个bytes是原始相机实时帧的二进制数据，第二个是上下文环境，这里咱们传的是NativeBuffer治理类的实例，在这个函数的具体实现中，咱们去匹配NativeBuffer治理的缓存地址，找到相干数据进行清理。 写入优化 后面咱们说过，数据流转是双向的。原生把相机的数据传输到js侧，js调用ARVR的人脸检测接口，还须要把这份数据在传输到原生。因为相机和人脸检测是互相独立的接口，js拿到相机数据不肯定非要调用人脸检测，调用人脸检测的数据也不肯定非要来自于相机，还能够是一个本地的图片。 绝对应的，咱们在NativeBuffer的设计中，提供数据双向传递的接口，getNativeBuffer：id和setNativeBuffer：id。在原生传递到js的数据中，咱们用了NO Copy的形式去做优化，那么在js传递到原生的数据，因为咱们不晓得数据起源，所以须要开拓一份新的内存空间，调用memcpy复制数据。然而实际上，咱们在做数据复制之前，能够用JavaScriptCore提供的接口，从js的ArrayBuffer对象中提取到实在数据的内存地址，而后在NativeBuffer缓存池中查找，如果找到了则无需再做数据复制。这样保障了数据始终只有一份。 数据类型 在实际的过程中，js端在抉择二进制对象的数据类型的时候，可能会用ArrayBuffer或者TypeArray。一旦js端进行了数据类型转换，比方ArrayBuffer转TypeArray，引擎在调用setNativeBuffer的时候，传递的是转换后的数据类型，将会导致setNativeBuffer外部的写入优化生效，进而在低端机上带来显著的卡顿。在这里，咱们对立应用统一的数据类型，不能随便的转换数据类型。 2、相机实时帧格局转换在技术挑战中咱们提到，iOS平台上，相机output只能指定为BGRA格局，而WebGL规范的接口不反对该格局。如果不进行格局转换，会导致红蓝色彩颠倒，红色物体出现蓝色，蓝色物体出现红色。所以在数据缓存和传输之前，要做格局转换，咱们须要找到一个疾速低成本的办法。 要想做数据格式转换，须要理解一些根本的图像数据在内存中的布局状况，如下图所示。 这里咱们选取的BGRA和RGBA格局都是32位，也就是每一个像素点是4个字节。 实在图像数据因为内存对齐的起因，大小并不一定是width*height*4个字节，CoreVideo框架提供了获取相机数据宽高的办法，咱们要计算出待处理的字节大小，每4个字节做一次循环，把第一位和第三位做一个调换，就能无需malloc内存，把BGRA转换为RGBA格局。 3、并发调度在技术挑战中还提到，每一帧的解决工夫大概只有41ms，须要经验原生相机生产、数据格式转换、数据双向传输、ar算法、webgl绘制等这么多流程，如何利用并发劣势，并且保障实时帧的时序不会产生错乱呢？ 咱们为了保障UI主线程的晦涩，要尽可能把更多的环节放到子线程执行，这个时候哪怕写入缓存这样一个轻量的操作放到主线程都可能会带来画面的卡顿。 实时帧的解决、AR算法别离放在不同的线程，为了保障实时帧时序，均采纳串行队列。 采纳了多线程之后，NativeBuffer数据的存储和清理须要加上线程平安爱护。 这样整体利用了多核的劣势，并保障了调用时序。线程调度和解决流转如下图所示： ...
作者：京东科技 冯建华 一、背景随着业务一直迭代更新，App的大小也在疾速减少，2019年~2022年期间一度超过了117M，期间咱们也做了局部优化如图1红色局部所示，但在做优化的同时面临着新的增量代码，包体积始终持续上升。包体积间接或间接地影响着下载转化率、安装时间、磁盘空间等重要指标，所以投入精力挖掘更深层次的安装包体积优化是十分必要的。依据谷歌商店的外部数据，APK体积每缩小10M，均匀可减少～1.5%的下载转化率，如图2所示： 图1 京东金融Android版本2019-2022体积变动过程 (红色局部是期间做的局部优化，然而很快就反弹回去了) 图2 谷歌商店利用转化率减少幅度 / 10M [1] 因而2022年9月开始咱们针对金融APP进行了瘦身专项整治，在不思考增量的状况，无删减业务代码的状况下实现从117M瘦身至74M，在本次安装包瘦身过程中咱们遇到了不少坑，同时也积攒了些教训，在此分享给大家。 二、APK剖析接下来咱们会简略剖析下 Apk内各组成部分，以及 Apk 作为 ZIP，其规范构造是什么样的，为包瘦身的指标设定及工作拆解提供数据撑持。 2.1 APK内容分析 图3 APK 构造 •classes.dex APK 中可能蕴含一个或多个 classes.dex 文件，应用程序内的 Java/Kotlin 源码最终会以字节码的形式存在于 classes.dex 文件中。 •resources.arscaapt工具在编译资源会将一些资源或者资源索引打包成resources.arsc。 •res/ 源码工程中 res 目录下除了 values 外的资源文件，这些文件门路同时会记录在 resources.arsc 中。 •lib/ nativeLibraries，即源码工程 jni 目录下的 so 文件，二级目录为 NDK反对的 ABI。 •assets/ 与 res/ 资源目录不同，assets/ 下的资源文件不会在 resources.arsc 中生成查问条目，且 assets/ 下的资源目录可齐全自定义，在程序中通过 AssetManager 对象来获取。 •META-INF/该文件夹下次要蕴含 CERT.SF 和 CERT.RSA 签名文件, 以及 MANIFEST.MF 清单文件。 ...